pegasus

This is an article I originally posted in the forums, but that was more suited for a blog post.

"Essentially, we have taken a great deal of user feedback into consideration, mulled it over for a long time, fixing bugs and adding minor features as we went along, and waited for a moment of inspiration. In my experience, inspiration doesn't occur when anyone is working but maybe taking a shower or a long walk.

It seems that there have been three major drawbacks in VaultWiki that have prevented it from becoming a huge success:

1. Ease of setup - while we have made huge improvements to the setup process with 3.0, by removing references to extra features right after install, and allowing users to change what namespaces do what, users are still going to have issues understanding how to make anything more than a very simple wiki.
   
   Namespaces don't appear in any hierarchy in their admin interface, and creating sub-sections of namespaces requires using other non-VaultWiki admin pages that don't display this relationship very well graphically.
   
   Special functions can only be given to one namespace at a time, limiting creativity when it comes to labeling and organizing sub-sections of such a namespace.
   
   While it's quick if you understand how it interacts with the default vBulletin functions (and not many people do), the separateness of everything prevents setup and regular administrative tasks from being anywhere near an "enjoyable" experience.
   
   No matter what, the rigidity of this core feature requires anyone making more than a simple wiki to do a great deal of planning ahead of time.
   
   The replacement of the namespace-forum bridge in 4.0 effectively eliminates all of these issues.
   
   
2. Inter-connectedness of core features - While there are a great number of features in VaultWiki that work together, like using Images, Categories, and Templates in articles, the problem is that you must create these items one at a time, in a certain order, and navigating to the correct spot to do this isn't particularly straightforward.
   
   These are also issues we are looking to correct in 4.0:
   
   Rather than creating an Image page, then creating the page that uses the image, there should just be an option to create the new Image from the editor when you are about to use it. An image selector needs to be back-ported from vBulletin 4 for vBulletin 3.
   
   Rather than creating a Template page, or learning the templates you need to use ahead of time, a user should be able to click an "Insert Template" button in the editor, which brings up a browser of various templates, and short descriptions of what they're for. If you can't find a Template that you need, you should have the option to create a new one right there.
   
   Rather than learning previous used Categories ahead of time, an "Add to Category" button should show you a hierarchical list of other categories and allow you to choose or start a new one.
   
   
3. Lack of Presentation - While individual articles have the tabbed style, navigation of the wiki from non-article pages doesn't have a unique look. The article list is a forum page. Users can easily forget they are in a wiki and post "threads" instead. Prospective customers are not impressed because they are looking for a wiki and it looks like they just found a forum page.
   
   Not only that, but the default front page of most wikis displays very limited useful information or functionality. From the first page, navigating the wiki is very linear, when a wiki should behave more like a web. This is not impressive either, and makes it difficult for users to find what they came to the wiki to read about.
   
   We think that the new customizable area pages in 4.0 will be much more suitable than the current offerings.

In addition to these, we have some fun new things planned, like Multi-tab and Tab-less articles."

As work on VaultWiki 4 has actually gotten past abstraction at this point, I will start posting more articles and videos on the changes shortly in another week or two, once we have enough of a front-end to show.