Menu layout - Cleanup/Improvement

[narayan]

it's very hard to imagine such kind of paradigm for file management.

Well, the success of two-pane managers is precisely because they run against the windows explorer's paradigm. So I wouldn't mind breaking a few more paradigm as long as it is useful to the users!

Actually I am against comparing with M$ (or anyone else for that matter). It is immaterial what they do (or do not): We should chart our own course. Of course we learn good points from the others, within a limit.

[fgagnon]

Even so, the 'new course' should still have common controls placed in familiar locations; (Let's not switch the accelerator pedal with the brake or clutch.)

So I find that wasker's reminding us of the heritage CUA guidelines is very appropriate.  It is a long-time standard, and defines arrangements of common controls.  Even for applications which include functions beyond its scope, it is an excellent reference for maintaining a familiar-feeling User Interface.

[narayan]

Isn't that outdated? Already we don't follow many of those things.

Also, the article itself says that for the last 12 years, Windows has moved away from that standard!  :twisted:

Any cutting edge product is bound to have radically different interface.
Staying with tradition blocks its evolution.

As such we are not recommending any radical change in the GUI.
For all Office 2007 users this GUI will NOT be familiar.

[fgagnon]

Just because it is old, does not mean it is outdated or useless.
It is because it provides such a well-thought-out framework that it has remained a defacto standard for common functions.  

As for cutting-edge products... to the extent they provide functions not related to the common functions, of course they must design an appropriate interface; but it need not be radically different -- especially where new function is an extension of heritage function.
And even when not merely functional extensions, where new items have a relation to the heritage ones they can neatly fit within the CUA framework; thus making their access feel 'natural' to the seasoned user.  Furthermore (and here is an a-ha!): if a new feature might fit in more than one place, it ought to be put in each area where it applies. Redundancy is a good thing.

Pardon the following rant, but you mentioned Office 2007 ...
Office 2007, on the other hand rather disregards the CUA for its new paradigm, which, although may be more efficient for new (and light) users, I find nearly unusable whenever I want to do for me what is routine, but which MS has decided is advanced, and hidden from me in new places, so I cannot find them easily.  
While I acknowledge the 'research' that MS put into making the UI more user friendly, I totally decry their not offering with it an option to install the heritage UI for veteran users.
I would have thought that MS would have remembered the benefit of an alerntae UI, which it used effectively in the past to emulate WordPerfect and Quattro and other competitors interfaces (and which they reciprocated, or had started first). It was one of the reasons that helped put MS-Office products in their now-dominant position. And the lack thereof that may provide seeds for its downfall.  :shock:

PS - I note that nikos has posted, that the UI for x2 will have to remain pretty-much as-it-is, using the heritage argument: the great majority of users have come to learn it.

[ScottWall]

File/Close (Exit) is a part of CUA, so it's not changeable.
...
Word 2007 has completely different UI paradigm. Don't compare oranges to apples.

Wasker, you are not being consistent. First you say that the CUA is the be-all and end-all of any application user interface. Then you say that it is fine for Micro$oft to create a new paradigm for an update to an existing file-based office suite application and that the new paradigm is actually better (implying that, perhaps, the CUA is not all that great after all). I initially stated that a file manager (an apple) should not have the same paradigm as a file-based office application (an orange). You say not to compare apples and oranges, but then you insist on comparing dissimilar applications, insisting that they should have the same menu interface. Forcing all aspects of the Common User Access onto applications which don't have common functionality generally results in confusion to users.

So I wouldn't mind breaking a few more paradigm as long as it is useful to the users!

I'd rather create a new paradigm specifically suited to file managers and ignore inappropriate paradigms. I find it very confusing using non-file-based applications that insist on using CUA-based menus when it does not make sense. If the menus are object-oriented and intuitive, then the users should adapt easily.

[wasker]

Also, the article itself says that for the last 12 years, Windows has moved away from that standard!

Well, they're rather exaggerate: we still have File (Open, Save, Close/Exit), Edit (Cut, Copy, Paste), View, Help menus; we're still using Ctrl-C/V/Z/Y for text operations. We're not far away from where we've been, are we?

Any cutting edge product is bound to have radically different interface.

Oh please. I see now people try to mimick Office 2007 UI while regular menu/toolbar could be much better fit (counter-example: Outlook 2007 and OneNote 2007 are still using the regular UI). X2 is doing fine with menu, and while it has the menu it's better to have familiar commands like Exit or clipboard operations in familiar places.

[wasker]

Wasker, you are not being consistent. First you say that the CUA is the be-all and end-all of any application user interface.

While we're using menus and toolbars -- yes, CUA should be taken to considerations.

Then you say that it is fine for Micro$oft to create a new paradigm for an update to an existing file-based office suite application and that the new paradigm is actually better (implying that, perhaps, the CUA is not all that great after all).

First off, I didn't do any CUA evaluation. All I want to say is: it's not a good idea to move away from CUA being in the same paradigm. If you can come up with a new paradigm which will not involve menus -- go ahead, but while x2 uses menus, Exit should be in File menu.

If you noticed, new Office 2007 paradigm is not good fit for all applications out there: some apps from the suite still use oldie but goldie menus. And those menus are still follow CUA guidelines.

* Probably, it's better to refer to MS flavour of CUA. It should be somewhere in their UI guidelines document.

[ScottWall]

look, xplorer2 has tons of commands and it would be hard to find things no matter where you put them.

That sounds like a defeatist attitude. It would be much easier to find commands if they were in a consistent logical location.

Once you find what you need first time, it will be easy to find it in the future.

This may be true for those with photographic memories. But, unfortunately, I don't think most x2 users possess this ability. I know that even after a dozen times using an oddly placed menu item, I still won't know where to find it the next time I need it.

the present positions have to stay since now most of us are used to them

Is that why SnakeByte created Menu++? What about new users who are overwhelmed by the number of commands? I've seen numerous instances in this forum where users were unaware of existing commands because the command was in an unexpected menu. It would be interesting to take a vote of users to see if this statement is actually true or whether users would prefer an overhaul or at least a move towards consistency.

[narayan]

@radical features:
Well, we have already implemented some radical things, not seen elsewhere. For example, Scraps is radical. Robust transfer is radical (it is a different issue that x2 was not the first with it).

I do not recommend radical changes for the sake of it. But neither should we shrink from them when the situation requires. We are talking in the context of refactoring the menus (not keyboard shortcuts, mind.)

[OT]
I mentioned Office 2007 just to remind that we must not hold M$ as a static reference, as it also changes with times. That does not mean that I hold it up as a good, flawless example. In fact, I do not find many commands where I expect them. (With the new GUI, I expected all commands within two clicks. That is NOT so. For example, after inserting a shape, formatting them has become more difficult now.)  But those problems will surely be taken care of. So far as the new GUI design is concerned, it will surely win in long term.

@tradition:
iPod killed walkman/diskman. That is because it was more convenient to carry hundreds of mp3 songs as compared to a dozen song on a cassette. Surely we did not stick to cassettes in the name of tradition!

P.S. I agree with Scattwall in his last two posts.
He has nicely put what I meant to say!

[wasker]

I do not recommend radical changes for the sake of it. But neither should we shrink from them when the situation requires. We are talking in the context of refactoring the menus (not keyboard shortcuts, mind.)

While I sound like an opponent, I agree that x2's menu could be enhanced by organizing commands in more logical manner. But I will be definitely against any change that will make common commands go elsewhere just because "Exit" looks more logical to "Windows" menu.

[ScottWall]

We could argue the advantages and disadvantages of adhering to the Confusing User Access model for menus until the cows come home. I could point out that other applications, like TestTrack, do not even have a File menu. But in the end, judging by the reluctance of Nikos to modifying the menus, the only hope that we have for any improvement in this aspect of x2 is if there is unanimity amongst the users as to what changes need to be made to the menu system.

For this reason, I suggest that we drop any contentious changes, such as moving File-Exit, and concentrate on the obvious changes that we can wholeheartedly agree upon.

[ScottWall]

Here are a few more suggestions:

• move quick bookmarks to Bookmarks menu (I never use these because I keep forgetting that they exist as I don't use the Goto menu).
  
  move scrap-related and window opening commands from the File to the Window menu (i.e., clone browse, browse flat and send to scrap))
  
  split File menu into following sections:
  - File-only actions
  - Folder-only actions
  - File+Folder actions
  - exit
  
  rename Actions menu to Panes and include separate sections for:
  - active pane actions (New Tab, Close Tab, Close all tabs)
  - inactive pane actions (Mirror browsing & scrolling, same folder, ...)
  - multi-pane actions (swap panes, sync, ...)
  
  dedicate the Tools menu to actions directed at the path of the active pane. Perhaps renaming this menu to "Path Tools" or "Current Path". It is challenging coming up with menu names when the only available letters are 'R' and 'L'  :( .

Implementing these and the other (non-controversial) changes would improve the intuitiveness of the menus as there would be a direct link between each menu and the target of the requested action. E.g., any action that is directed at the inactive pane would be under the Panes menu and any action that is directed at the selected file/folders would be in the File menu.