The story of the Office Ribbon

Wow! Thanks for pointing that out, Clint. Totally fascinating and very cool story. Interesting to see no mention of Access within the context of Office. So yes, I would love to see some Access-specific info on the design process, if anyone ever gets a chance.

The Ribbon is an a terrible mess for Access Runtime implementations and a pain in the Retail version for experienced users and developers. We continue to design to SAA CUA standards and this diversion is just not going to be implemented in any of our developments. We need the OPTION to dump the ribbon in the next version of Access, I mean even with WSXGA screens it takes up too much space especially in custom solutions where the user could not care less whether it is powered by Access or not. No doubt the ribbon has its uses for casual users who are not familiar with the particular office application. Access 14 will be passing us by if we cannot suppress the Ribbon. Access 2007 is of no real use and stands to be compared to Access 95. (IYKWIM)

I agree with the above comments. Garry

I strongly agree with Craig. In my applications in Access 2003 there are no toolbars - and there won't be!

I found the video very interesting. I think that one of the questions from the audience and the speakers answer was particularly relevant to Access. The timing of the question in the Video is 1:18:20. A developer asked when the ribbon is appropriate and when not. Jenson’s answer is generally that it can be useful, but it can certainly also bloat the screen and take up screen real-estate and not be a good idea. According to him, if you have few commands in your product then the ribbon is redundant. The product should have enough commands in order to benefit from the reorganization. It should have split between menus and toolbars, and that the developer is willing to re-think the product in order to prevent redundancy. To quote him: “If you just take the menus and toolbars and put them on the ribbon it is not going to solve anything..”. Jensen explained that the need for the ribbon came about because of the bloating of the Office 2003user interface, which has thousands of menu items toolbar commands and sidebar commands. I don’t expect that many Access applications will have the same number of menu and toolbar items to make such a move required. For me, if the ribbon will have the ability to contain bound combo boxes and other controls that can respond to events then maybe it will be more efficient, because I can move some of my commands from the forms on to the ribbon and justify its existence. Also, the video demonstrates the ‘Mini toolbar’, which is like the context menu in Access, except that it changes its visibility depending on how close the mouse pointer is to it. The context menus are important. It is also important to be able to develop them and the ribbon with an easy user interface. How can you think that it will make thinks easier for the end user if you do not provide an easy way to create and manage the ribbon and the Mini toolbars? Just my 2 cents

Gilad

Great inside to the design process. Thanks for sharing this. Some more of our Access MVPs should take a detailed look at this video ;)

I agree with Gilad's comments. Most of the Access apps I have developed over the years have been very task-based, so apart from jumping to a setup screen to add a new value to a pick list (which you can now do very easily in Access 2007 thanks to this great new feature) the navigation is done just using command buttons on the form in question. The only time that I have found custom toolbars really useful is when print previewing when you want to give the user the options to print, export, save as, etc. The new Office ribbon is overkill in this regard - it takes up too much space and you simply don't want/need to give a database user so many options. (I am also not a fan of the replacement for the Database Window - I prefer to give the user a proper switchboard menu. I know others have criticised this so I won't add any further...) A simple tool for creating Access 2003-style menus/small toolbars/pop-up menus and the ability to turn off the ribbon would be welcome enhancements.

Pls, remove Ribbon from Office. Or, at least, enable the standard menu.

As to placing useful commands (such as bound combo boxes) outside of the forms you can actually use the additional levels of nested subforms (now 7 in Access 2003) to make the main form nothing more than an application background with application wide functions appearing at the top of the form and then use subforms that would previously have been main forms.

A possibility to switch off the ribbon and replace it with old style menu bars would be appreciated for the next version for those who don't like it. I nevertheless guess: - The ribbon does not waste space. (WSXGA ?? Craig, how did you build A97 databases in 800*600 resolution? For the near future we can expect 24" or 26" monitors as a standard.)

- It can be minimized and then has the same dimensions as a single menu bar.

- The ability to use outsourced controls (from forms to the ribbon) makes forms smaller. Example: An overall context sensitive search field. (Could be done with commandbars as well, but is it easier then?)

- For me as a developer there's no difference between ribbons and commandbars in handling the UI. After using it for over a year both work for me with the same performance.

- Even developers should consider a better ergonomic UI. Ribbons are build also for *users* of our databases! To my experience they like it. But I confirm that actually it's too complicated to develop complex ribbon navigations (...though it's possble, Peter!). We'd need a ribbon object model and real events instead of callbacks.

The resolution is not the point the amount of screen wasted to the ribbon is - whether in WSXGA (1680 by 1060) or even WUXGA (1920 by 1200). And as most PCs sold (and MACs (probably)) are now laptops this is about the limit for now unless you can see people using 26" laptops in the near future. I came in when VGA was standard on 14" CRTs using Access 1 (although not deploying until Access 2 came along). The larger resolutions have allowed us to modernise some of these older system to display more of the users information on a single screen without resorting to page up/down and a profusion of tabs. The ribbon steals this space back and we are not going to use any version of Access that does not allow its complete suppression in both design and in runtime. Commandbars (which we generally do not use) are fine because they could be suppressed. The ribbon has its uses for casual users in some of the Office applications, but I hate it. Having turned down the offer to sign the NDA I do not know if the Ribbon has been "fixed" in Access 14 I hope it has.

BTW I would happily pay for a runtime licence that doesn't say "Powered by Microsoft Office Access".

Sheer Design Intel

The Style Editor is one great tool.

Hopefully we can get a Ribbon customizer in the next version so we don't have to edit XML entries or create .NET dependencies using VSTO. Many users I've seen *hate* the ribbon, although I personally think it's a step forward in some applications. This may be another case of IT leaping ahead of business users and neglecting their real needs from applications.

I long considered both Access and Excel to be development enviroments, not simply a database and spreadsheet program. I have also used both since their initial releases. It's bad enough that the enitre menu/command structure is changed. However, I find it worse that the environment (ie ribbon, etc) can not be 'customized' either manually or in code within the programs. The inability to easily modify toolbars to allow users to customize to the way each works is a huge step backwards in my mind. When Windows moved to the new desktop between versions some years ago, somebody decided that the ability to switch between 'classic' and new views was necessary. Why this was not deemed appropriate in productivity apps is beyond me... Sppeding up the learning curve for new, inexperienced users is great - but slowing down/hamstringing experienced users and developers was not a good trade off. There are some wonderful improvements but I am uncertain that in the end they will result in fewer 'net' keystrokes and mouse clicks - to me that's what it's all about