Hi, sorry for the long mail, but we already had too much incomplete and misunderstood communication, sometimes it is necessary to talk about the details. Please read carefully and try to understand what I think should be and is the motivation for a changed UI in OOo. Maybe then you will agree that the noise about "ribbon aping" is too much ado about nothing.
Tommy27 wrote: > PETITION: http://www.petitionspot.com/petitions/stoprenaissance/ > > Some OpenOffice developers announced, few time ago, a great (in their minds) > project: Trying to copy ugly, unusable Ribbon interface, made by Micro$oft > for Word and other Office products > > http://blogs.sun.com/GullFOSS/entry/prototyping_a_new_ui_july > http://blogs.sun.com/GullFOSS/entry/prototyping_a_new_user_interface > > This Ribbonized GUI has already several negative comments by Micro$oft > users, so, why trying to copy a poor GUi instead to analyze and solve > serious issues present in OpenOffice? (it has many serious issues) > > if you Agree with me (and many other) please sign petition, so we can stop > OpenOffice renaissance (or middle age?) not useful project, and developpers > can avoid to stress and go to solve issues. > > The petition has already collected 176 signatures. please, add yours I think your "petition" is completely useless as it preaches to the converted. Nobody wants to or will just "copy" the ribbon interace. The blog entries you quoted are perfect examples for a complete misunderstanding, caused by a badly prepared presentation of a prototype, a communication that forget to tell about the background and by reactions from people that talk before finding out what they are talking about. Too many people commented the blog entries that neither understood what a prototype is nor what the particular prototype in question wants to show. Many other people read these comments and even without having a look on the prototype parotted "OOo wants to copy the ribbon"! Rubbish. So what's the fuss all about? OOo will never "copy" the ribbon, that would be aping the look without caring for the ideas and working style behind it and if this is what we want. Our starting point is how we want our users to operate OOo. Whatever will come out of this: as all Office applications have something in common it is not surprising that their UI concepts will have some similarities. So don't think that an apple is an orange just because their look has something in common if you look at them from a distance. What we are trying to achieve is a context sensitive user interface. With an important limitation: context sensitivity is wanted for toolbars, not for menus. From what I know it is common sense that our menus will stay in the new UI and they won't be "context sensitive" (like in the different rather lame attempts from Microsoft with "personalized" menus etc.). That alone is a major difference to the Office 2007 UI that makes OOo much better. Menus are a tool for browsing through the functionality of an application and rearrangig the menu elements is counter productive. But for other UI elements, especially those that consume more screen space, it is a useful concept to reduce clutter. This is neither new nor is it invented by Microsoft and especially the "ribbon" is not the only way to implement it. In fact OOo 1.x had a lot of context sensitivity in its user interface, but it was implemented in a rather unintuitive way, and so many people couldn't cope with it. The result was the UI change in OOo 2.0: many toolbars that automatically pop up when it appeared that they could be used. IMHO this was a huge step back in terms of usability and I'm glad that our UX people want to correct that error. The number of complaints about this toolbar mess is pretty huge, so it's necessary to do something against it. You can't show all possible buttons at once, this consumes too much screen real estate, you have to select some. Without context sensitivity you could get a "lean" interface with the absolut minimum of toolbars shown. Users then have to add and remove toolbars manually when they need them. But users shouldn't be forced to do that, if the program is able to find the usable toolbars (and OOo is), it should help the user. This is the basic idea of context sensitivity: if e.g. a user has selected a picture, it doesn't make sense to waste precious screen space with a text formatting toolbar (that for a good reason is visible by default in all rich text applications), it should be replaced by a toolbar with buttons offering functionality that can be applied to the selected picture. So far, so good. But even with this preselection of toolbars there are still too much toolbars in some situations. Consider the case of a user editing a list in a table cell. Here it might be possible to either work on the text attributes, the list attributes or the cell or table attributes. Showing toolbars for all of them all will create the toolbar mess whe currently have in OOo. Showing only one of them will create another problem: which of them might suits the user best is pure speculation. So the program must select one by educated guessing, but it's essential to allow user invervention to overrule this decision. In OOo 1.x we showed the table toolbar by default in that situation, but we had a small blue triangle at the right end of the toolbar where the user could "rotate" the toolbar content between the three possible sets (text, list, table). As a "special service" the last selected set was remembered and restored in case the user again entered this context. Admittedly that's not a very intuitive user interface, mainly because the blue triangle didn't tell what it was meant to to. But the idea in general was a good one (IMHO). It's better than the current situation where you either have to keep all three toolbars open evertime you are working in a table or always switching toolbars on and off manually (as in Word prior to Word 2007). So for me the basic idea behind the OOo prototype is: only show toolbars that make sense in a particular context; if more of them might make sense, find a simple and intuitive way to switch between them. In a certain way the MS Office ribbon amongst other concepts also implements this idea. So even without copying it it's very probable that whatever we implement will have some similarities with it. If someone presents another way to also implement the idea of context sensitivity with user intervention, that doesn't make this a "copy" of the ribbon, in the same way as e.g. the Gnome File Picker isn't a "copy" of the Windows File Picker, they are just different, though unvoidable somewhat similar implementations of the same idea (selecting files in a hierarchical file system). So, please cool down and think about the concept that shall be implemented, not how it looks in a prototype that is barely more than a fake. We should concentrate on which contexts we want to have, which toolbars they should get assigned to, which buttons should be in the toolbars, how the switching between different button sets can be implemented with as less screen space consumption as possible but as understandable and intuitive as possible. And if the result has some similarity with parts of MS's ribbon implementation - so what? Other interesting questions are how big the buttons should be, if we should show symbols or texts or both etc. Much more interesting than diccussing how similar something looks to ribbons or not. Additionally, let's discuss if the old toolbars should be used as an alternative UI. Possibly people prefer a mediocre UI just because they are used to it - that's a valid decision and IMHO shouldn't be ignored. Especially as at the moment, where nothing except the prototype has been implemented, it should be easy to plan for this. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@openoffice.org For additional commands, e-mail: users-h...@openoffice.org