Simplify the Web Small and Simple things

The problem

Last week I started to formulate an idea for better Graphical User Interfaces in software. I posted my first draft on moodle.org. I would like to explain this a bit better here.

One of the main issues we have been facing while developing Moodle is how to balance usability with flexibility. We want to provide our users with ways to customise their web application enough to meet their various needs, but they tend to become overwhelmed with the number of features and settings facing them after install or upgrade.

This is an issue in every good and powerful software I know: Blender, Gimp and openOffice.org are just examples.

My wife is a talented pixel graphic artist who uses Picture Publisher for all her art. It’s an old and out-dated software, and she’s aware of its limitations (like no support for layers!). I’ve tried to initiate her to Gimp, but she just won’t do it, she finds the interface too “different” from the mainstream graphical editors, and doesn’t want to lose productivity while spending weeks learning how to use it properly. She finds all these settings and options confusing, despite the fact that Picture Publisher has its share of settings, many of which she doesn’t use.

The point is: she knows how to do what she needs to do with Picture Publisher, so she can safely ignore the other features; but she doesn’t know how to do these things in Gimp, so she doesn’t see the point in learning. ALL the features seem superfluous.

The idea

What if your new fandangled software only enabled features and settings as you learned them?

You rightly may ask: “How can I learn the features if they’re not available?”.

The answer is simple: you follow a tutorial. You may access this tutorial in several ways:

1. Through a menu
2. By asking a question: “How do I …?”
3. By following a link in another tutorial
4. By following a link given by another user who has already enabled that feature
5. By following a link found in the complete documentation

The array of features and settings enabled upon install could be selected just in the same way as one selects the components to install, with carefully chosen “presets” mapped for common user levels (beginner, advanced, expert etc…).

The tutorial could be in many forms:

1. Screencast with voice over
2. Simple text, with or without images and screen captures
3. Learn-by-practice tutorials: the feature is enabled during the tutorial, and you decide whether or not to leave it enabled by the end of the tutorial
4. Interactive tutorial: quiz and other formats

In all cases, the tutorials should be rich with hyperlinks to other tutorials, documentation, forum discussions etc.

One of the constraints of this idea is that every single feature, every setting needs to be tied to a tutorial, or be enabled by default. This means that, for an established software like Moodle, all features would be enabled by default, until tutorials are created or linked to these features. This is not a major consideration, however, since it would simply leave Moodle as it is now before any of this idea gets implemented.

Further ideas

In addition to writing tutorials for the purpose of this Progressive Interface, any other documenting text could be tagged with a Feature Code referring to an enabling feature. It would then generate a link along these lines: “I want this feature, enable it now”, or “Show me a tutorial on this feature” etc… This could apply to:

1. Forum posts
2. Wiki entries
3. Personal blog entries

In addition to a feature code, there could be a “software code”. The Progressive Graphical User Interface could become a standard for any software, with a well-defined spec (probably in XML) for the creation of these hyperlinks.