16 June 2007

Menu Reorganisation

After thinking a lot over it, here is my most recent try of a logical menu structure.


Subscriptions
Update All
Mark All Read
---
Add Subscription
Add Folder
Add Search Folder
Add Source
Add Newsbin
---
Import from OPML
Export as OPML
---
Quit
Feed
Update
Mark As Read
Remove All Items
Remove
Properties
Item
Next Unread
Toggle Read Status
Toggle Item Flag
---
Launch In Browser
View
Increase Text Size
Decrease Text Size
---
Normal View
Wide View
Combined View
Tools
Update Monitor
Script Manager
Preferences
Help
Contents
Quick Reference
FAQ
---
About


Everyone who misses "Edit": with me in a program which does not do the sligtest bit of editing will never have an editing menu. And the same for a "File" menu. The good thing is even the HIG agrees that "File" does not always apply and often the first menu can simply be the object the program is primarily about (e.g. "Game" or "Subscriptions").

So what do you all think?

11 comments:

Anonymous said...

Sorry, if this question is being asked many times before... Is there any reason for not having "copy to clipboard" functionality? It's really annoying to open feed item in browser just to copy couple words to other application...

Lars said...

Well from the development perspective Liferea only implements a simple use case. Integration with other applications is secondary to feed reading itself. And reading items are allows you to copy the text as you self say.

And the problem is there are so many variants: copy title to clipboard, copy selected text to clipboard, copy link to clipboard, send as email... Not all of them can be realized without cluttering the UI. And "copy link" is already implemented.

Eric said...

I really like the organization. It is very clean and understandable. I understand what you were meaning by three program level objects much better now.

I think it may be better to use "Options" instead of "Preferences" since most programs use the word "Options" when the menu item is in the Tools menu (and Preferences when in the Edit menu). Just a suggestion, either way works for me.

Lars said...

@Eric: I checked several GNOME applications and I only found "Preferences", therefore I think it is better to stay with it.

Thanks for your feedback!

Anonymous said...

While I like liferea a lot, I find the menu structure really confusing. Even though I'm sure it seems logical to you as a developer, it's atypical (no File/Edit menus, Item as a top-level menu entry, and many others) so it loses the benefits of a standard menu structure where you can anticipate the location of certain actions. I'm afraid that it could alienate new users, despite all other advantages of liferea.

Regarding the comment that liferea isn't meant for editing -- there are many programs like that (Firefox, Solitaire, etc.) where the Edit menu is present for the sake of seeming familiar to the user. I'd encourage you to think if the current functionality could fit in a standard menu layout to seem easier to use, at least at first glance...

Lars said...

@anonymous: Sure let's have a look at a "standardized" menu layout:

File
Update Feed
Update All Feeds
Mark Feed Read
Mark All Read
---
Next Unread Item
Launch Item In Browser
---
Update Monitor
Script Manager
---
Import from OPML
Export as OPML
---
Quit
Edit
Add Subscription
Add Folder
Add Search Folder
Add Source
Add Newsbin
---
Mark Feed As Read
Remove All Items
Remove Feed
Feed Properties
---
Toggle Item Read Status
Toggle Item Flag
---
Preferences
View
Increase Text Size
Decrease Text Size
---
Normal View
Wide View
Combined View
Help
Contents
Quick Reference
FAQ
---
About


In the above example I made the quite drastic change to distinguish between navigation actions adding them to the "File" menu and modifying actions adding them to the "Edit" menu.

What can be clearly seens as that collecting all editing actions for all three Liferea "object" types (subscription list, feed, item) results in a long edit menu where each action needs an additional hint wether it applies to a feed or an item. Which indicates the missing abstraction.

Also the "File" menu becomes a collection of "just the rest" and also needs labels with hints to the object the option applies to.

Overall pressing the menu options with their distinguish target objects into the File/Edit scheme has obvious problems. Also just because we have such a bad standard does not mean that we have to follow it.

Anonymous said...

lars,

Thanks for your answer. I think a few newlines got left out in your post above. From what I understand the way you would divide it in the conventional way would have these menus:
File/Edit/View/Help
and the other choices are entries in those menus.

I agree that it doesn't seem too clear in this layout, but I think it could be helped with a few changes. I'm trying to come up something which would keep your current logical order, while making it closer to other widely used software.

If I were to do it, I would base the organization on the Firefox/Thunderbird/Evolution
layout, since they pretty much do it the regular way, and the purpose of both liferea and these apps is quite similar (i.e. "read stuff").

Those programs all have the File/Edit/View/Help entries, but Thunderbird and Evolution differ in the handling of the Folder/Item relationship -- Evolution has additional Folder/Message menus, and TB has Go/Message/Tools. I think in the case of liferea it makes sense to have separate Feed/Item menus, similar to what it has now.

So a possible way to do it would be:

[menu] File
New -> Subscription/Folder/Search Folder/Source/Newsbin
---
Import from OPML
Export as OPML
---
Quit

[menu] Edit
(Copy/Select all, etc.)
(Find)
Preferences

[menu] View
Increase Text Size
Decrease Text Size
---
Normal View
Wide View
Combined View
---
Launch Item in Browser

[menu] Feed
Update Feed
Mark Feed Read
---
Remove All Items
Remove Feed
---
Feed Properties

[menu] Item
Toggle Item Read Status
Toggle Item Flag
---
(Remove)
---
Next Unread Item

[menu] Tools
Update All Feeds
Mark All Read
---
Update Monitor
Script Manager

[menu] Help
Contents
Quick Reference
FAQ
---
About

You could have richer Feed/Item/Tools menus, with some functionality specific to liferea, while keeping actions common to most software in the File/Edit/View
menus.

Of course this is just a possibility, and I'm sure with more thought it could be further improved, but I'm hoping you'll consider something similar as a choice.

Anonymous said...

Also, regarding your "bad standard" remark -- one analogy is the qwerty/dvorak keyboard layout issue. To people who have taken the time to learn dvorak, it's somewhat more efficient and easier to use. However, to the rest qwerty is more natural, because they're used to it, even if it's suboptimal. Making people switch to a "better" layout would just cause confusion and headaches...

Lars said...

Please don't spend to much effort in it. In fact the current layout is already fixed and translations are on the way. For 1.4.x there won't be anymore changes.

From you suggestion I see that you suggest a hybrid of the clear distinction of the concepts of the program and the File/Edit paradigm. While I agree that it lessens the pains of a pure File/Edit approach I see it as a bad compromise. And it is a compromise just to cling to the File/Edit paradigm.

What I expect of a menu is that one must be able to determine without searching which menu contains a specific menu option. And with the hybrid approach one cannot. Some actions will be in "Edit", others in "Feed" or "Item". Why should the user worry about where the action is. Initially this was the core idea of the "Edit" menu, to collect all editing actions, so that one must not search for them. But now that it is not able to do it anymore it should not be used anymore.

I think one must carefully weigh the advantages and disadvantages of File/Edit. The advantage being the familiarity of user with this menu form. And the disadvantages the uselessness of the "File" menu to assign menu options and the ambiguity of the "Edit" menu which collects arbitrary menu actions, which have nothing in common besides be modifying actions, and also obfuscates the logic location of different menu actions in the different main menu group. And from this standpoint one cannot decide for the File/Edit menu.

Lars said...

Please allow me to dispute your "standards must not be changed" argument. The negative interpretation of it would be that standards do just evolve and do never ever change again. I think the correct more distinguished view is that each new standard has a pain level that needs to be reached to introduce it. And you are right switching to Dvorak hurts a lot. Each non-English speaker knows the similar pain of having an English layout on a native keyboard.

What you do not proof is that switching from File/Edit to a clearly abstracted menu layout causes the same significant pain. I think if one would do some usability test with giving a new user the task to "edit the properties of the feed" or "add a new subscription" with the new layout he would never fail to select the right menu. Of course if you ask the suggestive question if he misses File/Edit he might still be inclinded to say yes.

Anonymous said...

I'm afraid such discussions quickly tend to evolve into elaborate flamewars ;-)

I understand your position, but I believe the line of reasoning which leads you to reinvent the GUI is almost always a bad choice. There are a few types of programs which can shun the menu-based paradigm completely (WinAMP, mplayer, IM clients), because they are different from other software in that they don't need the whole screen, or have just one large configuration window.

My only reason to "cling to the paradigm" is that virtually all applications do it. The reason for that is that any new program immediately seems somewhat familiar, because the developers though of grouping common actions into a structure already understood by the user.

My biggest concern is that the only places I've seen a non-standard menu structure were a few open-source apps (most notably GTKpod and liferea) written by either one person a small group of developers. In larger projects there are people responsible for the look/feel of the app, which seems to always lead to choosing a more common interface.

Regarding your comment about splitting actions between the Edit menu and the Item/Feed menus -- the Edit menu would just contain actions related to the (text) content of the current item, and nothing else (e.g. the Undo/Redo/Cut/Copy/Paste/Search actions common in most apps). So the division between actions that modify an item/feed and those which operate on the contents of an item would be clear.

Anyway, those were just a few comments about my gripes with the menu structure in an otherwise great application. Just to let you know -- I really appreciate the work you've done.