"Wouldn’t this be the best of both worlds?"

In terms of toolbar clutter, sure. But this probably isn't just an issue of toolbar clutter.

When creating a Web-based rich document editor, there are limitations to deal with in CSS and browser support, as well as performance limitations of JavaScript. Simply adding support for some richer document layout and presentation features can add a lot of complexity to the display and editing engine which can really bog it down and make it slow for users. This is even true for documents that don't use those features, since they'll still have to have the structure in place to accommodate for if the user spontaneously adds a complex layout element.

Performance, followed by browser support, are probably the limiting factors here, not just UI clutter.

Considering that it's just html..

I'd love to see even a simpler API for making Google Doc Templates. Just XML headers, some CSS, and a tag structure for making templates and other common productivity software add-ons.

Sure, you could do this just through the regular Docs API by having a form, creating the document, then sending it through SOAP, but somebody would have to custom-make the generator and a non-Google directory. It seems like a common enough feature for Google to just embrace it (or allow MS Office template imports!)

Clearly, the problem lies deeper than that.
I don't think Google Docs will ever be usable one day anyway. Either Google should let me store anything i want in an online storage drive with no stupid 500k limit either they provide a deep integration with current software suite such as MS Office iWork and co..
Today they give me none of these. And no one want to deal with an extra suite based online when things can be done entirely on a PC or Mac.

As long as they keep those limitations there is no way i'm gonna use GDocs on a regular basis...

David – I disagree; it's not at all difficult to provide an API that allows event triggers that users can hook into, as well as more generalized instant modifications. And it doesn't significantly slow down the UI or engine – Emacs has been doing it for decades. As does vim. And newcomers like UltraEdit, Visual Studio, etc. – none of them could be said to be slow (at least not in the editing arena). Admittedly, none are CSS/html based (and your concern about browser support may very well be a larger issue), but I suspect that's fixable. After all, Google has a _little_ bit of experience in this arena with their other APIs.

In general I think this is a truly excellent idea. Vim has had this for a long time; see http://www.vim.org/scripts/script_search_results.php?keywords=&script_type=&order_by=rating&direction=descending&search=search as an example of the most popular vim scripts. Occasionally the top script(s) will get pulled into the vim source if appropriate.

Top 5 Most-Used Commands in Microsoft Word 2003

http://blogs.msdn.com/jensenh/archive/2006/04/07/570798.aspx

Gmacs? heh

In principle – why not? We've already got full/basic menu modes on many apps, as well as toolbars that can be filled with the user's choice of functions.

In practice, I've always found customisable user interfaces to be bountiful fountains of unintended consequence.

The worst is support. If users have the option to customise things, they have the option to mess them up. Which they will. And then they phone up to say "Why does it do/not do this?". As anyone who's had to support a GUI application over the phone knows, this can be very difficult to talk people through, even when the menu/command structure is standard.

Not a game killer, but there would have to be a magic 'toggle back to known state' option.

Or perhaps there could be a 'duplicate features' option; that would be useful in a corporate environment, where you might have to roll out a common interface across a lot of users, and also for the case where the remote user has messed things up. "Just press the "Send menus to..." button, type in rupertggmail.com, and I'll tell you what the problem is". Various implementation questions immediately present themselves, but nothing unfixable: perhaps it could be best approached by "let another user share my editing session" remote viewing, or a hybrid of duplication and sharing. Lots to think about.

Another related problem with customisable interfaces is that it makes creating documentation about the application difficult. With a fixed or modal interface, you can give precise instructions backed up with screenshots. When you're no longer sure that the user is looking at the same interface as you are, the task is a lot harder.

> And no one want to deal with an extra suite based online when things can be done entirely on a PC or Mac.

Yes, they can, but at what cost? How much does MS Office cost? How much does a Mac cost? (And Open Office takes _more_ time to launch on my computer than Google Docs. I don't know why.)

I agree about the customizable user interface. But I think that by default the toolbar should be quite similar to what millions of people use each day inside Office 2003 or OpenOffice.

> When you're no longer sure that the user is
> looking at the same interface as you are, the
> task is a lot harder.

All added features would strictly remain within the "more actions" dialog, shown to the right of the second screenshot – so you would never have a different interface by just looking at Google Docs. Only when you expand the action menu, you will see a couple of options which are customized.... but it's only their choice of text that differs, and at the end of the menu there's always the "+ add feature ..." entry with some menu separator above it. No added feature would be able to hassle with the main interface.

The principle of adding custom stuff is similar to how iGoogle is doing it already, which also theoretically brings speed issues and support issues, but apparently Google is able to deal with this. (Not to say these are small issues!)

your mockup is very nice. Google should changed it at Google Docs in a way like this.

If I'm understanding what is being proposed correctly, this is one of those things that seems like a very good idea, but which has flopped in practice in the various forms when it has been tried. That may mean that it has just never been done correctly, but it may also mean that it goes against the way people are hardwired to interact with menu-driven software in some fundamental way.

MS Office tried to do something similar to this with its "smart menus" (I forget the exact branding) – it exposed the most common features on the menus and hid the infrequently used ones. It seemed like a good idea, but it confused users no end, and the net was immediately awash with posts asking how to turn it off. The problem seemed to be that most users navigate/wayfind using a visual-spatial sense of where things are, so lazily building out menus based on use patterns violates 2 basic user expectations:

1) all the options are in a menu somewhere
2) the layout of menus and buttons is static (modulo movable 'docks' of menus)

The emacs analogy as described above is appealing, but emacs finesses the problem somewhat by being built for power use – most regular emacs users end up setting (menu-bar-mode -1) pretty quickly, because between M-x apropos and C-h m one can typically find the command one is looking for faster than diving into menus (where only a fraction of the functionality is exposed anyway).

So maybe the right idea is to do away with the idea of a catch-all menu options for the users' "80%" and just have them search for what they want over the full command toolset ala emacs apropos. After all, search is a metaphor that Google users will certainly be familiar with.,,

> MS Office tried to do something similar
> to this with its "smart menus" (I forget
> the exact branding) – it exposed the most
> common features on the menus and hid the
> infrequently used ones.

I really hate that feature too. It completely goes against the usability guideline of predictability – as menus are starting to become unpredictable, both in terms of location of the shown items, as well as in terms of which items are shown in the first place. You also won't be able to successfully quickly search for menu items anymore, unless you always expand all menus. To do this feature right, you would need menu ghosting, a feature making sense (though very rarely used online). That's a general trend of Windows usability going downhill, as can be currently seen in Vista too.

With the Docs feature as I outline in the post though, everything would be 100% predictable, as only the menus you add yourself will start appear, and no other menu entries will ever be hidden. (Of course, once a year or so the tool makers may decide to add this or that menu but that would be more like an iterative new version, and nothing that happens on a daily basis.)

Let's go to the extreme. Say EVERYONE uses G'Docs instead of Office and all our content is in the cloud. Now we have to be online to get our work done. Wouldn't Verizon love that? You think Office is expensive? Try $100/month for DSL. No thanks, my desktop apps do everything I need.

Ray, I must say I don't understand you. I _do_ almost everything online (surely more than half of my document management), and I'm paying about 25$ monthly for my Net access (i use about 4GiB of traffic monthly, at speed of 3Mbit/s).

And it really doesn't matter much... I think I'd pay about the same if I used MS Office.

I love the idea. This will allow me to work a lot closer with my various NGO colleagues on reporting and info-sharing using docs.

Our basic accounting is already on the spreadsheet (editable by one person, visible to all key persons for transparency and information value), but I'd love to be able to have a menu made that makes the accounting easier.