So a quick rundown on MindTouch's product line:

• DekiWiki - our open-source project which is a MediaWiki fork
• MindTouch Deki - wikis for enterprises. Runs on a VM, which makes installation a super-cinch on any OS.
• MindTouch Wik.is - free, hosted wikis for personal use. Runs a modified version of DekiWiki and has software to support the sign-up process (DekiFarm)
• MindTouch Nexus - create your community-branded wiki. The primary market so far is for newspapers - they can leverage their editorial experience and their user base to create a localized resource.

So where do I fit in and what do I do? Well, the base product we use for all these variants is DekiWiki. I write features for PHP (those that would take too long to write in C#), manage the look-n-feel of our wiki, fix bugs, help triage bugs, and generally help make feature decisions about our product. I still spend a significant amount of time on development, which is where I'm happiest - overseeing the work of others just doesn't seem as rewarding :)

Over the past few months, we've been hard at work on the Hayes release for DekiWiki (which will be used to launch Nexus). I was frustrated during this release because I spent a significant amount of time launching Wik.is (which essentially was a two-man dev release with PeteE, while Damien did all the new designs/skins for Wik.is) which I thought was a total waste of time ... and at the same time MindTouch was reliving some of the ugly "growing pains learning curve" days which we had gone through. Why did we repeat these mistakes? Well, the company recently relocated most of the company to San Diego - the two development bosses above me both left, which meant that I was the only dev who remembered the early release days and the lessons learned there.

Without getting too in-depth into why this release was a horrid experience, I'll try to use a list:

• Shifting backend from PHP to C# = wow, that's a lot of work, more than anybody expected
• Everybody working from same office = took some time to get everybody to row the canoe in the right direction
• Gave critical components to staff not in the office (our Russian office) - I'm still on the fence whether this was a good idea or not, but my initial feeling was that their implementation took far too long for something that was relatively trivial
• Natural growing pains from PHP to C# API communication - made easy by using cURL, but early on we ran into all sorts of issues with authentication, authorization, etc. (some which are still murky)
• Debugging stacks. Our business logic was stored nearly entirely in PHP in the past. With this new release, we also make use of database sprocs and C#, while maintaining a significant chunk of logic in PHP. More stacks = more complexity
• Scope creep. The initial feature set for Hayes was a pretty tight release. We could have released Hayes at the beginning of January and made this C# conversion a separate release (which I think should have been done, cause the work I did prior to January was significant in and of itself). We just kept adding more and more stuff ...
• QA process wasn't strictly defined until maybe a month ago - wow this sucks BALLS. It's one thing to have uncoordinated developers - it's another to not have those uncoordinated developers vetted by testers

Fortunately, we've addresses near to all those issues. At this point everyone's just pushing for Hayes to be released so we can "be done with it."

One of the biggest reasons why I wasn't entirely happy during Feb. - March was because I wasn't getting to do one of the things I enjoy most - cleaning up the UI.

Let me show you the way our UI looks now (screenshot from our internal wiki):

It's not a bad design. This was the result of months of evolution, and I think for that time, it was a pretty good design. But we didn't do any UI evolution for Hayes - if anything, it looks almost the same! (The two changes to UI in Hayes: the navigation pane is pretty cool, and I did some work in December in making the image gallery not suck ass, but that work got diluted by a contractor we hired later on and implemented a bastardized version of what I wanted).

However, seeing this wiki every day while developing ... it became an eyesore. I didn't really think it kicked ass - it was a great first step at establishing a solid wiki product, but it wasn't even close to a final draft.

I know that within the office, there had been a lot of discussions, here and there, about improvements we'd want to do. Finding myself unable to sleep last week, I ended up getting up and doing a full-blown mockup of what I think the next UI evolutionary step should be for DekiWiki/Deki/Wik.is:

I usually sleep on designs for a few nights and end up hating them (which is why all my projects are always in an ever-changing stage of UI refinement). However, I still look at this design and really get pumped about how clean and simple it is. It becomes immediately clear what actions you can take on a page without being too cluttered.

If the goal of a wiki is to encourage user participation, the goal of the wiki's UI should be to make participation as easy as possible. And I think this is a huge step in the right direction.

Overall, the design still maintains much of the same UI organization ... it's pretty standard stuff: search in top right, logo in top left, navigation in left, etc. etc... but it just feels different.

I wrote up a long document in our internal wiki about some of the decisions I made to avoid repeating errors from the past... I'll try to bullet point the main items.

• Our old product was a liquid layout. That is a bad, bad decision. Using all of your browser real estate (especially these days with huge screens) is not better for readability, and the unpredictability of the design can cause problems for content formatting. This is a fixed width design (although I'm throwing around the idea of letting it scale between 800x600 and 1024x768 resolutions).
• Corporate branding ... out the window. The reason our existing product is a horrid color palette is because months ago, I was told to "use our corporate colors." Personally, I think that's the dumbest idea, cause nobody wants to stare at a puke brown and gold color scheme while working on their content. Neutral colors are best - and since our corporate colors have changed to this super dark red ... there's no way I'm adopting those colors in our product. I mean, just look at my wik.is site - do you *really* want that color scheme for a corporate product you paid thousands of dollars for?
• The design doesn't have to be infinitely customizable. In the past, I made a lot of design decisions that were meant to make things really easy, but sacrificed the site's design. For example, logo uploading can be done through a form - it resizes it for you and everything. But that sucks, cause wherever the logo is, the background has to be white! You can't do fancy designs, cause you don't know what size or dimensions the logo will be. With this new design, I've added a gradient behind the logo. My assumption here: if you can pay $3K+ for a wiki, you sure as heck know somebody who can paste your logo on a background that fits our skin. Another place this becomes evident is my abuse of anti-aliased fonts through images. This makes localization more difficult, but I think making site elements have a different font style from the content is a HUGE step.
• This new design takes into account new features we're working on for the Itasca release - inline loading of content. This is hard to explain, so I'll save on this for later

So over the weekend, I also started doing the markup for the new design. I finished the markup; check out how close it looks to the actual markup! I guess I'm biased, but I think it looks really damn good in markup form (which isn't always the case, as a lot of graphic designers will sneakily pretty things up in mockups which they know can't be done on websites without a lot of tradeoffs).

The markup itself is very clean - it should be very clean for search engine robots to pick up (good for Nexus), and the damn thing *should* be legible in mobile devices! (The same ol' standard stuff)

I was surprised upon firing up IE6 that there weren't any major issues ... oh the joys of using a fixed-width design so you know the widths ... :)

Cause teaching is important, I downloaded a program that took a snapshot of my computer desktop every 60 seconds when I was doing the markup - I plan on writing up a page showing exactly what it is I do in the hopes of spreading the joys of web development (barf). Watch for it sometime next week...