Jamulus
'standardize' menus #1915
Replies: 17 comments 62 replies
-
|
I agree with you that that would be better, especially for new users. |
Beta Was this translation helpful? Give feedback.
-
|
The reason I used 'view' is:
|
Beta Was this translation helpful? Give feedback.
-
|
I've actually been running a card sort on this topic for around a couple months now, but it still has low responses. It's the one on the announcements. I just need around 10-20 more responses for some usable data on how the menu should be sorted. |
Beta Was this translation helpful? Give feedback.
-
|
OK I have responded to your survey. |
Beta Was this translation helpful? Give feedback.
-
|
I like the idea of this change, though some menu items do not really make sense even with the current menu it is not making sense. I.e. in a menu named "View" you would not expect it will provide access to different dialogs related to (mainly) settings. And "Edit" is not really allowing you to edit. So definitely improvement can be done. In the proposal, there still is the "Edit" menu which does not "edit". I believe these items fall into the same category as "Settings". Not sure how self-explanatory the "Window" menu is. If I would need to access the "Connection Setup" it would not be the first menu I would check. It is the only dialog that cannot be directly accessed from the main GUI when you are in an active session (have already connected). Perhaps that is something which should be improved? |
Beta Was this translation helpful? Give feedback.
-
|
Here are some of the principles I tried to use when categorizing: About the EDIT menu: If you think of the Jamulus UI as a mixing console, then editing is the action of moving faders, muting and soloing channels. That is why I put all these on the Edit menu. If there was a copy and paste in Jamulus, it would, I suppose, be to copy one fader setting and apply it to another fader or group of faders. Undo and Redo, if they existed, would belong here, and would undo any fader changes. This is functionality that woud be used while jamming. About the SETTINGS menu: This is for the user's own personal settings. Their input gain, their audio device buffer configuration, their name and instrument. Everything on here would normally be configured before the user starts jamming. |
Beta Was this translation helpful? Give feedback.
-
|
I don't want to be a pain, but if you need to explain or way think of....it would deveat the intended purpose of making things more obvious to a first time/less experienced user. If all items in the edit menu are only related to the mixerboard, it could be call mixer options? |
Beta Was this translation helpful? Give feedback.
-
|
Not at all. You're right there is an argument for putting those functions on an 'application specific' menu, and naming it something like 'mixer options'. But I think there's a stronger argument for the Edit menu being the correct place. Apple has done a reasonable job of documenting the design principles for application menus, and their conventions are typically followed outside Apple as well: https://developer.apple.com/design/human-interface-guidelines/macos/menus/menu-bar-menus/ Note the conventions on Windows and Unix differ slightly from Apple's. An Apple user would be surprised by the Settings menu, and would instead expect a single 'Preferences' item under the 'Jamulus' menu. But Windows and Unix would not even have a 'Jamulus' menu, so it has to go somewhere else. |
Beta Was this translation helpful? Give feedback.
-
One might argue that such an explanation helps keeping this (long-term and sometimes heated) discussion focused and ensures that future iterations don't inadvertently revert an intended change here? :) |
Beta Was this translation helpful? Give feedback.
-
|
I really like the proposal. If feels way more intuitive than the status quo. We should, however, try to cross-check this proposal with the data from @mulyaj's survey (which I've just filled as well). |
Beta Was this translation helpful? Give feedback.
-
|
Everything can fit under the following categories: In UNIX almost everything is a File including files, audio and internet connections. |
Beta Was this translation helpful? Give feedback.
-
We do need to remember that less than 5% of Jamulus users are on *nix though :-) |
Beta Was this translation helpful? Give feedback.
-
|
No matter what platform, the point of the UI is to hide that level of detail from the user. |
Beta Was this translation helpful? Give feedback.
-
... without adding abstract clutter from an arcane paradigm (eg. GIMP) |
Beta Was this translation helpful? Give feedback.
-
|
Precisely. |
Beta Was this translation helpful? Give feedback.
-
|
I'm interested to see the results of the survey but I'm not sure how long I'd like to wait, for 10-20 more submissions - especially considering the submissions won't include any justification for the design choices. @mulyaj is there anything in the submissions so far that is significantly different from what we're discussing ? |
Beta Was this translation helpful? Give feedback.
-
|
Could also be Connect | Mixer w/ View Nested | Bookmarks | Settings | Help Using "Mixer" rather than "Mix", mix describes the total setup of the sound, while "mixer" describes the analogous object. The view within "Mixer" would contain the Mixer sorting options and "Use Two Rows". |
Beta Was this translation helpful? Give feedback.
-
|
I think the view menu is important enough to be at the top level. |
Beta Was this translation helpful? Give feedback.
-
This is no longer a menu option, as it changed into a setting which allows up to 8 rows. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Already mention in another comment, but repeat here....perhaps the GUI style options should be in a sub-menu as well? Just to make it more clear what these options are about. |
Beta Was this translation helpful? Give feedback.
-
|
I think I like 'File' better than 'Connection' |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Yes it's a really good approach - if there were 4 skins I definitely would have done this. But there is a recommendation in the guideline to avoid submenus wherever possible, so for just 3 skins, it seemed to me better to just put them directly on the View menu. |
Beta Was this translation helpful? Give feedback.
-
If this is the approach taken, then there are too many "sort" options in the menu and they should then be moved into a sub-menu. Guess the "skin" options in the menu can be worded different to include the fact they are a "skin/style" option. |
Beta Was this translation helpful? Give feedback.
-
|
Turns out there is in fact one too many "sort" options :) Yes I already added the word 'skin' to each of the skin options. I am ok with a sub-menu or not for either of them. The guideline says to avoid submenus because they are complex for some users, so there is a bit of a convention that 'advanced' parameters are more ok for submenus. I'll make some more mock-ups soon so people can get an idea how it might look in both approaches. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
My impression is that all is getting much more complicated. |
Beta Was this translation helpful? Give feedback.
-
Yes I added a bunch of stuff that is not in Jamulus but theoretically could be. It helps me to think about how extensible and how 'correct' the design is.
Indeed, the discussion above is about whether to call it 'File' or 'Connection'. Many many applications have things on the File menu that are not really about files - you can see in my screenshot above of my terminal window, literally none of the choices on the File menu is about files. The screenshots are just to help think through the design. Do you think it would be ok to have those options, if the menu was named 'Connection' ? Or do you think it's wrong to offer the directories in the menus at all ?
So far as I can tell, all the guidelines specify the View menu for that. For example, from Apple: "The View menu lets the user customize the appearance of an app’s windows."
Indeed, why not in File, since we load them from a file ? In those mock-ups, I put it on Edit for 2 reasons:
|
Beta Was this translation helpful? Give feedback.
-
|
Another example of functionality that theoretically could exist. If we offered users a list of recent server connections, I think users would expect to find it on the 'File' menu (the standards all call it the File menu even if it actually has a different name). |
Beta Was this translation helpful? Give feedback.
-
I wonder if it really is a setup ? What exactly is being loaded and saved here ? Fader levels associated with client names ? If so, I think it should be called Load Mix and Save Mix, it belongs on the File menu |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
For those who prefer to see how just the existing Jamulus functionality would look under the re-arranged menus: I'm hesitant to rename File to Connection because I have not seen many applications that rename the File menu. I'm extremely hesitant to rename Edit to Mixer. My gut feeling is when users see File, Edit, View, Settings, Help they will feel very very comfortable, as it mirrors closely all the other applications they have used. |
Beta Was this translation helpful? Give feedback.
-
|
In so far as we can observe that a number of common apps exhibit this "single door" technique (which has at at least a couple of advantages over standard menus), then I think we don't need to worry too much about recognition. Extensiblity is an interesting one, and a possible disadvantage of the approach. It would require perhaps another menu, tab within in the menu, or other "overflow" approach such as sub-grouping. BTW my example shows a sub-group in the form of "Sorting..." For undo, I would say we could rely on Ctrl+Z since the use of undo would not be (unlike on a drawing app, say) core to use. But it might conditonally appear at the top of the menu as "Undo [last commandName]" perhaps. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah I almost agree with you. Chrome on MacOS has undo and redo on the Edit menu, but you can't find them anywhere on the primary menu. It's probably why Apple is still insisting that the menubar has to be there. Otherwise it's a step backwards to how it used to be, before "menu-driven" software - in order to use a command you had to already know it.
I honestly don't think it is the right step for Jamulus to take right now. I believe on MacOS there is no option but to have the menubar. And I believe Jamulus should have a consistent UI across all platforms, otherwise it becomes difficult to write guides and documentation. |
Beta Was this translation helpful? Give feedback.
-
|
I suggest we re-arrange the existing menus to File | Edit | View | Settings | Help Then make a future PR to add the Primary menu just like yours, and make the normal menubar default hidden on Windows and Linux. On mobile I'm a bit unsure... I suspect right now it has a primary menu that mirrors the current menubar. But I don't have a build environment set up. Are there pre-built apks ? |
Beta Was this translation helpful? Give feedback.
-
yes: https://github.com/jamulussoftware/jamulus/releases/tag/r3_8_0 see assets. |
Beta Was this translation helpful? Give feedback.
-
|
So it's as I expected - a Primary hamburger button that offers the desktop menubar. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding the View -> Sort options, the standard guidelines suggest a couple of changes. 1 - We should change "Sort Users" to "Sort Channels". The word "users" is tech jargon. I think anyway I've read at one time a Jamulus style guide that tells me to call them Channels, not Users. 2 - This "no user sorting" can never make sense to users. The channels are always sorted by something. In this case it's according to a server-assigned slot which is an implementation detail that really should not be exposed in the UI. The server-assigned slot is meaningless to users, there is no reason for anyone to ever select it. |
Beta Was this translation helpful? Give feedback.
-
|
@jp8 Check the style guide, but I think you'd be correct about "Sort Channels": |
Beta Was this translation helpful? Give feedback.
-
|
thank you. I skimmed CONTRIBUTING.md but i did not immediately see a link to the style guide. |
Beta Was this translation helpful? Give feedback.
-
|
How do I make the "analyzer console" appear ? I would like to make sure it looks ok on the menu... |
Beta Was this translation helpful? Give feedback.
-
|
Look at main.cpp. I think it’s just a cli flag called analyzerconsole |
Beta Was this translation helpful? Give feedback.
-
|
It's an officially undocumented feature -- and shouldn't be accessible other than from the CLI, really. :) |
Beta Was this translation helpful? Give feedback.
-
|
jp8 wrote on july21:
I'm almost in full agreement here. What I'll suggest is: File | Settings | Help (KISS and minimalist) |
Beta Was this translation helpful? Give feedback.
-
|
Ah but I never thought of File as a meaningless label. The first menu is always about the top level object you are working with. In a word processor, the first menu is about the document. In a text editor, the first menu is about the text file. In a spreadsheet program, that menu is about the spreadsheet. In a web browser the first menu is about the web page. The first menu is normally labeled File, but sometimes it is labeled after that top-level object. The top level object in Jamulus is a mixer. We could name the first menu Mixer if we thought it was a good idea. When you connect to a different server, what you are really doing is connecting to a different mixer in the cloud. I prefer to name the first menu File because it's really very standard and I don't see a strong reason to rename it. Every little unexpected thing you do creates a bit of mental work for the user, and it all adds up. Saving the user from unnecessary mental work is, in my view, what the keep-it-simple principle is about. Have a look at Chrome's file menu - there is plenty that's not about files but it's all about web pages. You can open them, close them, save them locally, print them, share them with your friends....
|
Beta Was this translation helpful? Give feedback.
-
David - I think your approach to have everything in the File menu really closely matches the suggestion of @gilgongo for a primary menu. You can see his screenshot in this comment: I would like to put all the basic functionality for musicians in a single Primary menu (often called a 'hamburger' menu because of the three horizontal layers in the icon), but with the full menubar still available for 'advanced' functions - grouping, multiple rows, loading and saving mix definitions, and so on. I would like to make a series of pull requests for this. Step 1 - Re-arrange existing menu items to follow industry UI guidelines (file, edit, view, settings, help). Step 2 - Expand new menus to add items that currently require bringing up dialogs Step 3 - Add Primary Menu (hamburger menu) with commonly accessed functionality. There will still be potential to discuss and agree (or disagree) the fine details in each of the pull requests. Does the overall plan sound ok ? Does anyone have any strong objections ? |
Beta Was this translation helpful? Give feedback.
-
|
The overall plan does sound ok. I won't comment further, unless the plan diverges or becomes chaotic. |
Beta Was this translation helpful? Give feedback.
-
Hehe thanks for that vote of confidence. I intend to take it slowly and get it right. But the first pull request will be simple and quick, and that will give everyone plenty of time to try it and validate it. |
Beta Was this translation helpful? Give feedback.
-
|
I have opened pull request #1926 |
Beta Was this translation helpful? Give feedback.
-
|
Now that #1926 is merged, the menu items have not changed, but a few are found on different menus. Is there a release scheduled soon ? There is a certain benefit in pushing UI changes gradually to the end users. But if there is a long time before the next release, then I would like to just go ahead with the next changes. |
Beta Was this translation helpful? Give feedback.
-
|
I have created the second pull request #1934 |
Beta Was this translation helpful? Give feedback.
-
A recurring theme in the github discussions is that users do not easily find the functionality in the menus.
I have put the word 'standardize' in quotes in the topic, because it is not possible for everyone to agree on what is standard. However the screenshots I am attaching are at least closer to what I personally perceive as common usage.
The advantage is:
The obvious disadvantages are:
My view is that even existing users would prefer the new layout.
Beta Was this translation helpful? Give feedback.
All reactions