Menu names are confusing

[djfun]

If you look at the menus of many applications, they are structured in a way that even new users can guess what items are hidden in which menu.
There are also style guides which describe this, for example:
https://developer.gnome.org/hig-book/unstable/menus-standard.html.en
https://developer.apple.com/design/human-interface-guidelines/macos/menus/menu-bar-menus/

The View menu lets the user customize the appearance of an app’s windows.

The View menu contains only items that affect the user's view of the current document.

In Jamulus these options (ordering of channels, 2 row mode) are in the Edit menu for some reason, while the View menu contains items which open other dialogs, which is also wrong.

My suggestion to solve this:

• move the items that affect the view to the View menu
• keep the items that edit the state in the Edit menu
• move the items to open other dialogs to a new menu (maybe Windows?)

[pljones]

I think the application-specific tool controls should be on &Tools. However, I still think "Connect / Disconnect" should be under &File. The connection is, essentially, the "document" inside which Jamulus "edits". (So &New Connection and C&lose Connection.)

[gilgongo]

BTW we could I think do a primitive card sort test for comprehension of any new labelling/nav scheme. So if we used Google Forms to present a list of things and ask people to select which area of the UI they would expect to find them in, like this:

Select where you would go to do the following:

Connect to server: [Tools, File, Settings, Main window]
Leave server: [Tools, File, Settings, Main window]
Buffer settings: [Tools, File, Settings, Main window]
... and so on.

(We'd need to give them a screenshot, and explain some things to make sure people had a common understanding of what, say "file" is and what "buffer settings" are though)

The more correct we are in our suppositions, the less deviant the answers per feature will be. But if lots of people expect to find, say "mute myself" in Settings and not the Main Window, then that will be informative.

[pljones]

It may mean that they're not understanding the term, of course :)

[gilgongo]

Yes, which is why I said we'd need to explain things :-) (eg "Jitter buffers - usually on "auto" but can be changed manually when investigating sound problems")

Card sorts (although I've only done them with dedicated tools, not hacked with a Google survey) always suffer from the possibility of comprehension problems to an extent, which is they're best done face to face really. That has the added bonus of discussing with people about what they understand the terms to mean, and other things. I guess F2F isn't out of the question either though...

[nefarius2001]

[Tools, File, Settings, Main window]

I'd even question if it makes sense to have a different set of cathegories. Haven't thought it through yet, though.
I'd more expect ["server" (connect, profile, chat), "audio" (settings), view (sort by)]

[gilgongo]

Yes, those categories were just an example.

BTW my description of the research above is of a "closed card sort". Would be good to be able to do an "open" one to find out if there are any patterns in people's thinking on this (so give them a list of all the features and let them categorise for themselves. The aggregated frequency of pairing would then suggest groupings which we can decide to name). But I don't think I can hack that...

[chrisrimple]

A few thoughts:

• Menus are where advanced features should be "hidden", keeping the main UI clean and focused on the common use cases
• But there are some (current) menu items that are not in the Main UI, and perhaps should be. For example, Sorting (under the Edit menu) should probably be a dropdown in the Faders section of the Jamulus/Main window, so that it's more obvious to the user if a Sort is active.
• I think that all windows (Settings, Chat, Connection Setup, Jamulus/Main) should be accessible from a Windows menu, but perhaps only for bringing focus, not for opening/displaying. Instead, they should be opened from the appropriate parent menu. For example, on Mac the Settings are appropriately Preferences under the main app (Jamulus) menu.
• Where to put the Connection Setup menu item is an interesting question. For most apps, particularly those that work with files, the File menu is the place where a user looks for primary features and the Tools menu is where they look for secondary functions. Given that Jamulus is mostly useless when not connected to a server, should Connection Setup be buried under Tools, or made more prominent in the menus.

[pljones]

On Windows, I usually expect Tools->Options to be where to go for settings.

Looking at Firefox on Windows 10 as a handy example:

• "File" opens and operates on browser tabs/windows. Along with Exit. The Jamulus equivalent is the session - so connect / disconnect. We currently have load/save mixer settings. I think that's understandable - however, maybe a separate "Mixer" menu with the mixer functions, as well as load/save, might be more obvious and easier to use.
• "Edit" has copy/paste/search options. The Jamulus "Edit" menu seems to be more about things you can do with the mixer.
• "View" has functions to open toolbars and sidebars - i.e. additional window decorations for use as part of the browser. That's pretty much in line with what I'd expect in other applications. From Jamulus's "View" menu, I can only think of Chat living here - but perhaps that could move to "Tools" (i.e. more or less rename existing "View" to "Tools", except for the connection).
• "History" and "Bookmarks". We don't offer these facilities - maybe we could in some future release.
• "Tools" has a bunch of fairly specific things plus "Options", as mentioned. So I guess things like settings and profile could be here.
• "Help". We're pretty much the same here.

So currently we have "File", "View", "Edit" (which, given a quick check of other applications, has "View" and "Edit" in the wrong order). I'm suggesting "View" becomes "Tools" and "Edit" becomes "Mixer", with load/save mixer moved from "File". I'd still put "Mixer" before "Tools".

Of course, Firefox on Linux has "Edit"->"Preferences" rather than "Tools"->"Options" (and "Exit" is called "Quit").

[mulyaj]

BTW we could I think do a primitive card sort test for comprehension of any new labelling/nav scheme. So if we used Google Forms to present a list of things and ask people to select which area of the UI they would expect to find them in, like this:

@gilgongo I've had some success with uxtweak for a free card sorting tool, but it allows a limited amount of correspondents (10 I believe). I often just made copies of the same tests when I went over the limit.

[gilgongo]

@mulyaj Ah nice - I didn't know about uxtweak. 10 isn't too bad if we asked specific individuals to take part though. Open, closed and hybrid sorts too, and they provide a dendrogram in the results :-).

So, all we need now is a list of all the features and functions... I've got too much on right now but if anyone wants to make one, eg "Mute myself [short explanation]" , "Disconnect [short explanation]", "Set jitter buffers [short explanation]" "Profile [short explanation]" etc. and we can see how long that is (best to keep it below about 50 if possible - hopefully less).

[mulyaj]

@gilgongo Forgot to mention that there is a limit of 20 cards... so that might be an issue.

Another consideration would be Trello, I think it'd be easier to hack together an open or closed card sort there.

[gilgongo]

Hm. 20 seems a bit tight. I'm not sure how Trello would work though. Like this? https://trello.com/b/tb1YTWlV/card-sort How would we analyse the results?

[mulyaj]

Yes, I think it would be like that. For quantitative results, I think that'd be on us to work through.

Perhaps Trello would be better suited for a card sort interview?

[djfun]

What is the status of this issue? Do you need more input?

[gilgongo]

I think if we want to set up a card sort we can do that. I'll open a ticket with the spec of what needs to be done, and if anyone wants to pick it up they can. Stand by.

[djfun]

??
Does anyone intent to work on this? Or is this going to be solved by the new UI anyway?
Your obscure process of handling feature requests makes it hard to participate or actually implement stuff..

[gilgongo]

Yes, sorry - we'll be outlining the process soon. Basically, it's that GH Issues are discussed, actionable work tickets. Initial feature requests are started as Discussions.

As to this discussion, if anyone wants to raise an Issue describing some work to be done (and preferably do the work!) then that would be good. Personally, I'm a bit snowed under to take on a chunk of IA research.