Online office suites like Google Docs are often criticized because they have a very basic feature set, but the advanced features from software packages like Microsoft Office are rarely used. Jensen Harris, Group Program Manager of the Microsoft Office User Experience Team, published in 2006 a list of the most used features in Microsoft Word 2003 ... 1. Paste (11% of the usage) ... 2. Save (5.5% of the usage) ... 3. Copy ... 4. Undo ... 5. Bold
Ionut concludes that “instead of adding advanced features, Google Docs should focus on the most frequently used features and try to make them easier to use.”
On the other hand, if you happen to be a user who needs feature X around 90% of the time, it doesn’t matter to you if it’s only used 10% on average – the tool would still be useless to you if it doesn’t have X.
To cater for the “long tail of features,” perhaps web apps from Google and others should instead connect their application menu to a feature directory. You could then pick “+ add feature...” from an actions menu and browse a directory with categories like “for artists”, “for book writers”, “for scientists”, “just for fun” etc. Each category includes user-scripted features – some created by Google/ the web app maker, but tens of thousands by third-parties –, not too different from Word Macros but safe. Clicking “add this” brings you back to Google Docs, Google Spreadsheets, or Presentations, which now include your new menu entry.
Calling up this new menu entry, each script can trigger simple visual dialogs to get more feedback, a bit like gadgets, and connect to different input and output via an API (offering easy access to “selected text”, “whole document”, “clipboard” etc., but specifically not allowing e.g. tampering with revisions, removing items from the default application layout, grabbing the user’s email, or automatically saving a document).
Naturally, very important features would still be integrated into the main menus. Additionally, the tool makers could check usage stats for each of the third-party features to see if it may make sense to roll out that feature as default menu entry in the next version. There could even be a document type/ typical usage pattern matching – if it turns out that people who edit documents with above 10 photos in them often utilize an “add borders to all pictures in the document” or “resample all photos for faster download” or “increase contrast” menu entry... then a dynamic “Photos” menu could be dynamically displayed for just those document types (in a bit of a different style).
Then, with a feature directory, it doesn’t matter how exotic your needs are... you can still integrate them into your tool. And nobody else’s interface would be cluttered due to that. Wouldn’t this be the best of both worlds?
>> More posts