TheresAnEasierWayToDoIt

What wiki demonstrates is the principle that "there's always an easier way to do it". (See HandWavingProofThatTheresAlwaysAnEasierWayToDoIt)

In particular, it shows that certain conventional wisdom has built up which hides huge inefficiencies. Wiki shows that you can cut through some of these and make big gains.

For example, by going against the two most common conventions in UI design (WYSIWYG and FormsWithOneFieldPerDataItem) it reintroduced simple parsed markup language for users, which allows data to be entered and structured far more easily than the other two UI methods. Just following this pointer could lead to big productivity wins. (See TheReturnOfTheCommandLine)

Hmmm...

Why would having a WYSIWYG wiki have any negative aspects? I see no disadvantage to having a more traditional GUI for the text markup. Indeed I suspect that you'll see them soon - just like you're getting WYSIWYG tools for blog authoring.

One example is the excellent VoodooPad a WYSIWYG wiki-ish text editor / outliner / notpad application for Mac OS X. Plug this into a future standard for Wiki page publication and you would have an better Wiki publication system. No more having to hit preview.

FormsWithOneFieldPerDataItem seems bogus too. Wiki's have one main data-item (content) in one field.

Some wikis have multiple fields (for titles, change summaries etc.) Some wiki's might be improved by having more fields (would the DiamondWiki be better/worse if it separated out the meta-data and content into separate fields?)

Wiki's are great and I love them to death, but I don't see them breaking any UI conventions.

– AdrianHoward

Wow! VoodooPad looks very cool. And very like the kind of thing I (and half the world) have been dreaming of / dreaming of writing. Does it really run Python scripts as the screenshot suggests?

: Yup. Output gets inlined as I recall, but I don't have it on my box at the moment to try. The Ink integration is good too (Apple name for their pen-based interface - so you can draw, handwrite input, etc.) – AdrianHoward

The GUI thing, and the FormsWithOneFieldPerDataItem thing are related to the discussion we're having on AnEasyInterface. And my assertion here stands or falls on the same principle. Some of the things I want from a really good wiki are the capacity to put some kind of script into pages eg. macro invocation with parameters. As I say on AnEasyInterface, I believe that a linguistic interface gives me a lot of compositional power to express complex things in a convenient way.

And it seems that a two mode view (raw editable source and pretty presentation) is a convenient way to do this.

I guess you'll suggest that you could allow the insertion of such a macro into a GUI interface with eg. right click, pick macro name from pop-up menu, fill in parameters in a wizard. So you may have won this one ... damn you Howard! But I'll be back!

– PhilJones

: Actually I'd probably prefer a palette you can drag and drop from ;-)

– AdrianHoward?

The problem with a palette you can drag and drop from is that it doesn't scale. If there are 5-8 items, OK. More and you start representing the items with cryptic icons (as with PhotoShop) or putting them into long drop-downs (in pop-ups!!).

I think TabCompletion / IntelliSense is the way to go to improve this. Allow a pop-up hint-list that can be scrolled or narrowed by continuing to type but doesn't actually take the focus away from the user if she doesn't want to use it.

– PhilJones

And the problem with TabCompletion is that you have to know the name of the feature before you have to try it :-)

Also remember that palettes do not always have to be just iconic - or even have icons at all. Nothing wrong with text labels.

You're right, of course, that having alternate input methods would be a good thing.

– AdrianHoward

And the problem with TabCompletion? is that you have to know the name of the feature before you have to try it :-)

This strikes me as beautifully illustrative of our discussion about expert vs. naive interfaces. I argue that "experts" are people who have an internal mental model of the system and don't need to read it ie. they know the command and just need help getting it in. Naive users are those who don't have an internal representation (don't know the commands) and therefore need help discovering a) that it exists, and b) how to trigger it.

You may need to cater for two kinds of users, but you also need to acknowledge that the two kinds of needs exist, and that the same interface doesn't help both.

– PhilJones

And my general point is that having separate expert/novice interfaces isn't the right solution. Having interfaces that enable you to move from novice to expert are what we should be aiming at. Pull down menus would be one example. Novices can see all the options, notice the keyboard accelerators, and migrate to using the keyboard for extra speed.

It shouldn't be expert /or/ novice - it should be both.

– AdrianHoward

OnWiki, CategoryWiki