Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index

On 03/20/2014 12:22 PM, Mattias Põldaru wrote:

Let me explain what is wrong with your picture with an analogy.
First your case: a person walks around the city, reaches the park and
hey, how convenient, finds a hammer on top of the fountain. Later under
the bridge, hey, what a surprise, a nail. Off we go, got some work to do!

Now let's assume the person actually want's to find a hammer and a few
nails. First place to look for both is a hardware store. Where is the
hardware store? Probably the best one is where all the building material
stores are. There might still be one hammer in the park and a few nails
under the bridge but these are useless.

The same is true for software.

Consider an actual scenario that plays out regularly:

The local hardware store is running a sale on brand x product, in the case hammers, and stocks a point-of-purchase display near the entrance. A customer in need of a hammer enters through the garden section and proceeds directly to the tools section. The customer doesn't find a hammer that meets his needs, so she leaves empty-handed and a bit frustrated. At best the retailer has lost a sale. At worst the customer learns that the retailer isn't a reliable source and starts shopping elsewhere.

Smart retailers make sure products can be found where customers expect them, even if that means stocking two locations.

Now to a point I was thinking about yesterday regarding the use of icons. Years ago I taught classes on the use of basic office software. Mostly I taught Microsoft Excel, Word, Powerpoint and Outlook. I quickly learned that it's very difficult to teach people by showing them icons. Fortunately, Microsoft had spent a lot of money studying software usability. Microsoft applications at that time took a systematic approach. Any given command might be accessed through the menu, by clicking on a button or by using a shortcut key combination. The entry in the menu displayed an icon, the command name, and the shortcut combination (assuming it had all three). Any buttons on the interface displayed the associated icon from the menu.

I taught my students to find the command in the menu first. Once they found that they could find the corresponding button or learn to use the shortcut keys. Buttons and shortcuts improve productivity, but menus are where people find the option first.

Since introducing the ribbons, Microsoft interfaces have become much more difficult to navigate. Now we have to search help or hover the mouse over the buttons trying to find the right one. I would strongly suggest that Libreoffice not abandon the menu interface with icons. It should always be an option.

On a side note I'd like to see one improvement to how applications do menus. I'd like to see an autocomplete menu where users can find the command they're looking for. Something where you could type "print" and it would show all the printing commands. Each command would display the associated icon, the shortcut, link to help and (maybe in a popup) provide the menu path and any context menu paths.

Derek Cooper
Continental PC

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.