In a Nutshell
How about a UI that doesn’t present you with all the complex features of the application just at once. Instead, it slowly adapts in that direction based on your usage pattern.
Applications, as they move up in release versions, start cramming up the UI with features. This is a gradual progression we see in most software applications available today. In a world were simplicity speaks volumes, we might be better off with showing less. Why would I hide features when my application supports it, you would ask. The answer is simple – Users may only need to do certain things with your application, never will they use every single feature from day one (unless they are used to previous versions, of course).
Bring about a UI which understands user usage pattern, and then gradually starts enabling/showing features. This would allow the end user to start with a minimalist interface and then as the user gets comfortable with the core functionality, that they can start using more features.
Like all theories, it’s better to put the point across with a practical example.
The best example I have from my own experience is the story of Winamp (from my perspective). Like most fans of music during the late 90s, I too was a Winamp + Napster fan. Winamp had always been my media player of choice ever since I had started listening to MP3s. In spite of my dedicated loyalty towards all the versions up until 2.81, something happened with Winamp 3 that totally threw me off and almost made me regret my decision of upgrading. It had become this bloated piece of software from the original version, that in less than 10 minutes I lost all charm of wanting to use it. My grunt was simple – I had no interest in Music Libraries or tons of those new features that it shoved at me. Plus all of those features made it slower to load. It didn’t take me much time to roll back to Winamp 2.81 which had been my previous version.
One day I got this newsletter bragging about the launch of Winamp 5. Honestly, I was not too excited to give it a try given my past experience with the version 3. What I did notice is that this time it came with a Lite version as well! Instinctively, I downloaded that and fired it up. Expecting to see a worsened avatar of the version 3, what eventually showed up was a surprise – The UI was almost just like 2.81. Wow, what a relief that it does retain the 2.81 simplicity, I was instantly telling my geeky friends! I immediately got to using it and no second thoughts about reverting back to the old version haunted me. What this meant was, I was not the only one complaining about the cramped up Winamp 3 UI and certainly I was sharing a general consensus. In about next few days I unlocked almost all of the features I had seen in Winamp 3 plus a few more. Not necessarily I used all of them, but at least I knew they were there and I will use them when the need (or the urge) arises. An important lesson was learnt that day – make it comfortable for someone to fit in to what is otherwise new.
Learning off of that experience, came a thought to my mind – what if the software understood that when a user was ready to be presented with more stuff that they might want! If that would happen, then even a non-geeky user could be eventually roped in to use some of the more advanced features.
Alright, we are sold, how do we implement Complexity Adaptive UI (COMPAD UI)?
What I plan to suggest in series of successive posts, is a set of configuration XML markup structures, terms and design patterns to enable successful implementation of this feature in programming language and technology of your choice. I am also in process of setting up a Wiki page so that more of us can collaborate on the idea.