New UI, practicle example for discussion.

[dcorson-ticino-com]

New UI, practicle example for discussion.

Following the discussions here, on the forums and looking at some of the other competative apps I have made an example of a new UI for Jamulus which can be found here: NewUI-DCO

The design goals were:

• keep the known Jamulus look and feel.
• give the user more info about what to expect.
• separate client from server visually.
• make the "Connect" to server more prominent (and connect between micro and headphones).

That I personally think it is more intuitive is obvious, but what do you think? How should Jamulus' user interface be evolving in the future?

The discussion is open....

[gilgongo]

Nice to see some experimentation!

Regarding the design goals, can you explain more about "give the user more info about what to expect" and "separate client from server visually"? Obviously, the main change is that this new UI positions what is currently on the left hand side to the top, but I'm unclear how that meets your stated aims (if indeed it's intended to do so).

The large mic and headphone icons are a good idea, but without labels as to what they signify in the second screen in particular, I'm not sure what they mean. Are they also buttons (so the mic is perhaps "mute myself"?)

Do you mean the L and R to be present on the reverb control?

[dcorson-ticino-com]

More info about what to expect, no sound from mic or headphones when not connected. Yes, hover over the mic and a red slash is shown to show pressing will mute or unmute myself. I had considered making the headphones a second connect button, but thought it might be confusing, what do you think?

The client separated by being horizontal at the top with the server controls all vertical on the mixer. By coincidence the vertical client pan was recently seen as a problem on the forum. The R and L are the reverb channel (I'm in mono in/stereo out, they are not shown in stereo). I made a mini vertical client level display next to the mic, 'though. I didn't like a horizontal level display.

Two things I haven't done, but will when I have some more time is to add a start-up message along the lines of "Connect to hear yourself and others" (must find a better formulation for that). The other thing is to make some kind of graphic indication that when "connected" the mic and headphones are also connected. Maybe a visual designer can chime in with an idea how best to do that.

Another thing that one can't see without using it is the behaviour of the connect button and window. When the connect window is shown the connect button in the client frame is hidden so it is not possible to hit the wrong "connect" button, only the connect button on the connect window is shown. The connect window is also forced to the top so it can't be covered by other windows as long as it is shown. I have seen that happen and it causes great confusion.

[gilgongo]

no sound from mic or headphones when not connected.

Unfortunately not everyone will have a mic connected so this graphic may be confusing, and it's also possible that you may have a mic connected to one Jamulus channel and (say) an electric guitar connected to the other (eg using Mono-in/Stereo-out). Best maybe to represent this as "signal" in some way. But even better to add a text label to explain :-) And of course avoid portrayal of a speaker, as it might imply using Jamulus without headphones is a good idea.

Minor point: for mono signals, panning isn't available I don't think, so you'd need to grey it out (and provide a message?)

The R and L are the reverb channel (I'm in mono in/stereo out, they are not shown in stereo).

But there is no reverb panning in the current UI, just level, no? Perhaps I'm confused.

"Connect to hear yourself and others"

That's a really good idea! But I wonder if we might also add, "If you can hear yourself, you need to turn off local monitoring if possible" and link to further information about Rule Number One.

When the connect window is shown the connect button in the client frame is hidden so it is not possible to hit the wrong "connect" button

Yes, although greying out might be better than hiding so as to allow an explanation on hover perhaps?

[dcorson-ticino-com]

Unfortunately not everyone will have a mic

Yes, but what is an immediately recognised symbol for a sound transducer? I think a mic is easily taken as any instrument (and it is used by the competition). Text explanation I would put in tool tips.

Minor point: for mono signals, panning isn't available I don't think, so you'd need to grey it out (and provide a message?)

As far as I understand one can more or less attenuate right or left in mono, not really panning, but still a function. Where there is no panning for mono is on the mixer board.

But there is no reverb panning in the current UI, just level, no? Perhaps I'm confused.

In mono the reverb is added to either the right or left channel, just like the present UI.

Yes, although greying out might be better than hiding so as to allow an explanation on hover perhaps?

I don't think that is necessary as when the connect window is open you see where the "new" connect button is.

[gilgongo]

Text explanation I would put in tool tips.

I'm not sure tool tips are enough for something that important, as per N/N.

Thanks for explaining the other points.

Now that I think I understand it overall, I can ask my main question: given your goal to "separate client from server visually", why do you include the client in the list of channels in the mixer panel, and not (as I was initially expecting) separate that out into the top components? I ask because I think that goal is the most interesting one, yet you appear not to have followed through.

[dcorson-ticino-com]

Now that I think I understand it overall, I can ask my main question: given your goal to "separate client from server visually", why do you include the client in the list of channels in the mixer panel, and not (as I was initially expecting) separate that out into the top components? I ask because I think that goal is the most interesting one, yet you appear not to have followed through.

A very salient point, you make. And it may be that will need reconsidering. But my reasoning is that the client consists of 2 parts, the input to the mixing table and the output from the mixing table, as is hinted in the frames left and right of connect. On the input side my levels, reverb, panning, are setup values that will not be changed much. On the mixing table inbetween, however, all voices are equal, my own fader to be treated like all the others.

I had at one point thought to try to visualise how the sound(data) flows from my client input where it is panned and reverbed, then sent through the internet to the server where it is mixed and then sent back to all the client outputs. In the end I rejected that thought as too complicated, confusing, with way too much information that no-one really needs. But it does show that on the server all are treated the same.

Concerning icons with text, do we accept that they are not translated? I do not know if Qt allows placing text over an icon. I will try to find out.

I just pushed a version of the program with the Connect message (suddenly had the idea how to easily do it). Please try it out.

[bflamig]

I personally like the rearrangement. Anything that physically separates the input pan control from the output pan controls is a good thing. This new arrangement does that well. I've seen people get really confused and not understand the difference from this control and the other pan controls, or to completely miss that there is an input pan control at all.

I've also seen people get confused and frustrated when they can't get one of the input channels to produce any output -- and the problem turns out to be input pan slider was set all the way to one side of the other. With a linear slider, it for whatever reason doesn't register to the user as being set that way. That is certainly true when that slider is vertical (BTW: I've never seen any other gui's that use vertical linear sliders as pan controls). When the slider is horizontal --- as in this new arrangement, it may be easier to recognize this situation. But a circular knob is probably best, since then it's exactly like the other pan knobs and they are more likely to intuitively understand what it's for and how it works.

As far as the reverb control, why not two knobs, for left and right? Would be easier to operate. (I actually never use the reverb control so maybe I don't understand how it's supposed to work.)

[chrisrimple]

I really like the ideas here and the new layout (client top, server bottom). A few specific questions/thoughts…

• Mic and Headphones don’t appear to be clickable controls, instead appear to be indicators. Not clear to the user that they are actionable.
• What does the Headphone control do? It’s not a replacement for Mute Myself or Mute (under the user’s Pan and Fader controls). Is it a master Mute for all users in the server mix?
• The Reverb slider + L/R radio buttons are confusing, because there can be different values for L and R. I think separate Reverb controls for L and R would be more easily understood and less prone to user error.
• Settings and Chat buttons should likely have up/depressed states, rather than indicator lights, since indicator lights usually mean “on”, not “another window is open”.

Overall, a great start!

[gilgongo]

Anything that physically separates the input pan control from the output pan controls is a good thing.

I agree and your observation about vertical sliders is a good one. Although I think it would be worth listing what we think are the most important problems experienced by new (and even not new) users - would issues with panning be high on that?

@dcorson-ticino-com

Concerning icons with text, do we accept that they are not translated? I do not know if Qt allows placing text over an icon. I will try to find out.

Not sure I understand. Do you mean there is an "icon" component in Qt that has fixed properties? I just meant text written in the UI below or above the graphics to explain their state (eg "People can't hear you"). Why would that not be translatable?

[dcorson-ticino-com]

@bflamig There is nothing on this example that is not on the original Jamulus UI. The reverb is both channels if in stereo (L & R are hidden) and on one channel L or R in mono and mono in stereo out. Confusing originally and confusing here, but that's the way it is :)

@chrisrimple The mic is both a control for mute yourself and indication, the headphone is only an indication showing if one will possibly hear anything or not. The mic looks like this when you hover over it, the red bar with reference to the red bar you get when self muted:

For the reverb see my response to bflamig above.

I agree about the settings and chat checkboxes. I left them as they are for the time being as they are somehow part of the Jamulus look and feel. Mid term I would change to icons such as the gear for setup and a text bubble for the chat that have become relatively standard at least in the PC world.

I general I lean toward the trend of a no text icon and a tool tip as Microsoft is doing at least for standard things, it makes things very clean and you learn the icons really quickly. That despite gilgongo's article pushing text with every icon that he mentioned above.

@gilgongo I tried getting a text over the icon today without success. I looks like it would need to be above, below or to a side. I am still more for a tool tip. I think the bigger question mark is why the headphones don't do anything when clicked, but the mic does. Have you tried downloading and running the program for the real look and feel?

[gilgongo]

@dcorson-ticino-com

Have you tried downloading and running the program for the real look and feel?

No, sorry I should do that.

no text icon and a tool tip as Microsoft is doing at least for standard things

Do they? Can you provide an example of that?

Meanwhile, you may be interested to see a sketch I did from a few months ago after having a conversation with a choirmaster in the US who had sent me some sketched ideas of his own.

The design goals (and a couple of the layout choices) were similar to those that @dcorson-ticino-com has, with the additional aim of freeing up more screen space for things like help and onboarding. I was also trying to re-model the UI as more of an "application" than a mixing-desk skeuomorph, because I thought perhaps presenting Jamulus as a mixing desk might be getting in the way of some of the concepts that Jamulus has.

Here's a video talk-through (15Mb mp4 - turn sound on):

I haven't shown it publicly until now as I wasn't sure if there was much appetite for a re-design (or whether it was solving the right problems). But since there's some interest now I thought I'd put it up here.

[dcorson-ticino-com]

I am really amazed at how similar your sketch is to some of what I thought through with just pencil and paper. At some point 'though I thought it looked too much like a DAW which is even more forbidding than Jamulus' mixing table in my eyes. My biggest comment is that I find it a bad idea to hide the mute and solo buttons. When you need them you need them fast and don't want to have to go looking for them for each client. Very good is the approach to getting all the windows on-board. The more I think about it the less I like the idea of separating the local user (client) as a musician from the others, the client as the local hardware necessary to participate, yes separate. But not the musician, he belongs together with all the others he is playing with.

Here an example of Win10 Icons in the start menu of a laptop. In the meantime we know what they all mean even though they do open up if you hover. On a Win10 tablet one has even more Icons to learn, and on a tablet there is no hovering so it is more of a problem at the beginning.

[gilgongo]

I am really amazed at how similar your sketch is to some of what I thought through with just pencil and paper.

Yes, most of it is pretty familar stuff in terms of layout and function.

My biggest comment is that I find it a bad idea to hide the mute and solo buttons.

There wouldn't be a problem putting them on the channels in the "compact" layout (I was making the overall window size purposefully small to see if that would work). They are on the "mixer" layout as they are today.

Here an example of Win10 Icons in the start menu of a laptop.

The labels are right next to the icons there :-) Incidentally, I was also going to ask you about your statement "I tried getting a text over the icon today without success". The element we're talking about doesn't have to be an "icon" as designated in the code, does it? At some point I guess we'll need to be aware of limitations in the Qt framework I suppose.

But not the musician, he belongs together with all the others he is playing with.

It would be worth discussing why you think that is. If the musician thinks that Jamulus should act like a rehearsal room where everyone is plugged into a mixing desk, then it would be understandable if they became confused by the following example scenarios:

1. A musician in the room who can hear others, but cannot hear you.
2. You can hear yourself, but nobody can hear you.
3. You can alter someone's volume, but they won't hear the effect of that. You can alter yours (using the same UI) and you will.
4. You can mute yourself, but everyone else can still hear you. But when you mute them (using the same UI), you cannot hear them.

To what extent these (and related) issues underpin difficulties in using Jamulus, I don't know. But there have been clear indications that (for example) "Mute myself" https://github.com/jamulussoftware/jamulus/issues/187 is a result of not understanding some of these things.

[dcorson-ticino-com]

Has there been any discussion of leaving the conceptual world Client/Server and replacing it with something like musician/music room (performance center, concert hall, music club....) ? Then one is entering, leaving a music room instead of connecting and disconnecting.

[dcorson-ticino-com]

The labels are right next to the icons there :-)

The program icons, yes. But the Win10 system icons to the left, no. On/Off, Settings, File Explorer and User... there is no text that I can see.

[pljones]

My immediate thought was "where's my input levels?". I guess it's that's tiny, tiny thing next to the massive mic icon. Given it's the most used part of the client side UI for me, making it the least visible seems not particularly intuitive.

I had no idea at all what the headphones and mic meant - looked like jazzy logos with no function. If they're meant to look like buttons, using buttons might be more useful.

[gilgongo]

The program icons, yes. But the Win10 system icons to the left, no.

Oops I didn't see those! I would imagine they've found that those icons belong to the set of sufficiently commonly used/recognised items seen in many other apps and so have removed the labels. As the N/N articles says, there are a very small number of icons that from their research are recognised without labels. This isn't really the case with us I don't think when it comes to mics and things perhaps, but you never know. BTW if an icon signals two or more system states, then easily visible text disambiguates that.

Has there been any discussion of leaving the conceptual world Client/Server and replacing it with something like musician/music room

Yes, in fact there is a ticket which I can't now find, but need to as part of some upcoming work on a style guide, where we decided how we should use the word "client" and when not to use it (eg we wouldn't say "Mute the client" but "Mute the person" I think).

[dcorson-ticino-com]

My immediate thought was "where's my input levels?"

Next to the mic, when there is no input they only show where they are. I think they are small but effective as the whole bar changes color as the bar mounts. To be discussed, I am not a graphic designer. (I have been using this UI for a while and that is actually my 3rd design for the input level meters, the others IMHO looked better statically, but in use showed their weaknesses. Please try it out in use.)

As to the icons, I think that the gear as settings icon is well known enough that it needs no text. Some form of text bubble for the chat too. I have no idea what other icon could be used for audio input that would be more general and as well known than a microphone. But I am open to all suggestions.

I will push a version in the next hours without servers and connecting, but with music room and entering / leaving. Let me know what you think.

[bflamig]

@gilgongo said earlier in regards to the pan controls "I agree and your observation about vertical sliders is a good one. Although I think it would be worth listing what we think are the most important problems experienced by new (and even not new) users - would issues with panning be high on that?"

I personally know several people that have had problems due to the seemingly invisible vertical input pan control in that they weren't aware that it was set all the way over to one channel, and as a result, couldn't figure out why they couldn't get one of the channels to "work", thinking there was something wrong with their audio device. See the end of this source forge discussion for example:

https://sourceforge.net/p/llcon/discussion/hardware/thread/f6d4fae2a2/

[bflamig]

@dcorson-ticino-com wrote earlier: "There is nothing on this example that is not on the original Jamulus UI. The reverb is both channels if in stereo (L & R are hidden) and on one channel L or R in mono and mono in stereo out. Confusing originally and confusing here, but that's the way it is :)

Well, since this discussion is about changing the gui, it seems like a good time to eliminate that confusion. I don't know if having two knobs does that for the complicated interaction you've mentioned here, but it's worth pondering what would be less confusing. (Personally, as an aside, the "mono in/stereo out" setting in general is about as confusing as it gets -- although after lots of thought about how that could be changed, I've not found anything substantially better.)

[pljones]

Next to the mic, when there is no input they only show where they are. I think they are small but effective as the whole bar changes color as the bar mounts.

Thing is, I've been considering - and others have asked for - greater detail on levels, such as written dB values rather than just the markings we currently use. Large meters are required by some. So any change would have to not affect that usage being achieved as well.

[dcorson-ticino-com]

I've been considering - and others have asked for - greater detail on levels

OK, I have been going in the direction of the Focusrite boxes which have no input meter at all, just a LED that changes color. That was my first try as a small meter, but I found it too indistinct even with a really big surface. That makes the mandate different, to be discussed.

EDIT: Maybe, so that both of the users who know what a dB is are happy, we could make a "calibrated" input level meter in the setup window. It is not something one would need every day, I would think.

[dcorson-ticino-com]

Another iteration of a new UI. Message at start-up to join. Shows data/sound flow from mic to cloud and cloud to headphones. Click on mic to mute yourself. Tries to imply that the music making place is on the cloud. Still not sure if join/leave a music room is better/clearer than connect/disconnect to a server. Jonathans problems visualising mute and solo on the mixerboard aren't solved yet, but some form of graying out would work. I'm still far away from how to do that graphicly, either with the current graphics as a basis or with something new.

Comments please... This version is now at the link at the top of the post.

[maurerle]

I like this Idea a lot.

Just brainstorming: We have the PAN control at the top with a slider and in the middle with those turning buttons. Wouldn't it make sense to also show the same UI control for the same functionality? But this would also apply to the input level, which should use the same UI as the ones on the mixer board. I don't know what is right here. This is a great step but it still needs some polishment, especially so that every old user can get used to it and won't think of it as a step backwards (because the buttons are not described/function unknown or the mic input level is much smaller than it was).

Instead of the headphones I would consider a normal speaker symbol, just like windows does for its audio control at the bottom right. In my world the Mic-Logo stands for any "input device" and the speaker for any "output device" otherwise a better icon for the output could be an ear symbol.

I don't like that I can click the mic but can't click the speaker/headphone. I would somehow expect clicking the headphones would mute the sound or something. I don't know if this should be fixed, just a weird feeling Otherwise I like the visualization and that the chat, mute, settings and disconnect functions are better seperated (a friend of mine always clicked the disconnect button instead of the settings).

Maybe you could rebase the current jamulus master and show how it looks with the new background? I think with the new background it could look cool to have something actually looking like a button for the mic mute?

This is really great!

[Hk1020]

The labels are right next to the icons there :-)

The program icons, yes. But the Win10 system icons to the left, no. On/Off, Settings, File Explorer and User... there is no text that I can see.

This depends on the Windows version. In the latest incantation 20H2 or what's it called those icons do open up when you click or hover the mouse over. Microsoft seems to constantly change this and I find those frequent changes quite confusing.

[Hk1020]

Something that irked me since I first saw this new design is the prominent disconnect - now Leave this Room - button right in the center. It's begging for being pressed and that is the last thing we want people to do. Please stay! We want to make music together. Don't leave! -- BTW I like connect/disconnect better.

And I am not sure about the new blue things left and right of the cloud. Look like some misshapen slider - I tried to move the left one until I realized what it is supposed to mean. I don't think it is useful. Instead make the Settings and Chat buttons bigger they are a bit hard to hit. Maybe in a later design somehow integrate the chat window into the main window.

[gilgongo]

I dug out this sketch from a few months ago which has an "explanatory diagram" approach too - this was after some discussion about people not understanding the flow. Also experimenting with that "don't think of it as a mixing desk" idea, together with only having those who you could play with in the main screen (so "zones" for who could not hear you or were muted).

BTW also the idea was that each link in the "chain" at the top would have an "OK / not OK" state to clue you to problems (so if "Jamulus" wasn't receiving a signal form "Your computer" for example).

[gilgongo]

Instead of the headphones I would consider a normal speaker symbol

@maurerle The trouble with showing a speaker is that if we imply Jamulus can be used with speakers that may cause problems.

[mulyaj]

Hey everyone, here's a rough frame I drew up. My design goals for this wireframe were to clarify the role of each widget area to improve general navigation on the main window.

At the moment in the current design, widgets don't have a clear identifiable role. Most notably in the bottom left, "chat, settings, and mute myself" don't have much relation to one another (other than the fact they complete an action). Therefore, in my design, I've rearranged the connect, settings, and chat.

In addition, after watching @gilgongo's video walkthrough of his wireframe, I liked the idea of changing "Mute Myself" to "transmitting". I looked for a better word instead and in the current documentation, "Mute Myself" is explained as, cuts your audio stream to the server. What if mute myself was renamed to stop stream or stop streaming to others? Its function would then be much clearer to users.

In the current frame, I still think the Diagnostics+Settings could be improved, as the settings button might need to be somewhere more prominent. I haven't thought too much about the personal mix area and still need to expand on the mixer screen.

[gilgongo]

While I think that re-arranging the existing UI elements is certainly worth exploring, I'm not convinced that position or form of those elements is the main problem with the Jamulus UI.

For example (and I asked this of @dcorson-ticino-com but they didn't reply), if the musician thinks that Jamulus should act like a rehearsal room where everyone is plugged into a mixing desk, then it would be understandable if they became confused by the following example scenarios:

1. A musician in the room who can hear others, but cannot hear you.
2. You can hear yourself, but nobody can hear you.
3. You can alter someone's volume, but they won't hear the effect of that. You can alter yours (using the same UI) and you will.
4. You can mute yourself, but everyone else can still hear you. But when you mute them (using the same UI), you cannot hear them.

I doubt anyone would argue that these were not confusing conditions. But to what extent do these (and related) issues underpin the difficulties in using Jamulus? Hard to say, but I'm willing to bet it's more than the fact that the pan is a vertical slider.

[mulyaj]

Yeah, the mixing desk analogy is probably the primary problem. I still think re-arranging the UI can address some of these tertiary issues and improve on some of the aesthetics.

But focusing on a completely new UI, how would the process of implementation go? I'm curious what the first steps would be. Could this be something we put on the roadmap as discussed previously?

[dcorson-ticino-com]

Hi Jonathan and Mulyaj

Going through those cases: (assuming we are not in an error case)

1. A musician in the room who can hear others, but cannot hear you. a: They have muted you b: You have muted your stream (I like this designation) to the server.
   There is now no indication of this on the other clients, but you could simply not be playing.

2. You can hear yourself, but nobody can hear you. a: This is a special case of a muted stream which I am not sure that we should keep as it breaks the logic.
   If I mute my stream why should I hear something? I do not understand the design decision. (The only reason I can see for it is to test out ones signal without disturbing others on a server. It may be useful as a special case, but in general it is way too difficult to understand.)

3. You can alter someone's volume, but they won't hear the effect of that. You can alter yours (using the same UI) and you will. a: Of course, you hear your own private mix, not someone else's mix. You can not alter someone else's mix

4. You can mute yourself, but everyone else can still hear you. But when you mute them (using the same UI), you cannot hear them a: Where is the problem? Those who I have muted I don't hear, myself included.
   Everyone else can still hear all of those that I muted.

Some thoughts to these scenarios: All this muting may not map to being in a rehearsal room with others, but for our use case is necessary.

We have three groups of people in the room (including oneself) 1) those who I can hear, who may or may not be actually playing at a particular instant 2) those I can not hear because I have muted them 3) those I can not hear because they have muted their stream

One of my questions right now is if it is really necessary to make a second kind of mute indication for group 3? (I don't know if the other clients even know if this is the case)

Whether the display analogy is a mixing desk, a DAW or "something completely different", the information we need to provide is the same.

All the people that I have worked with to get up and running say that Jamulus is actually quite simple once one understands the interface. I have finally accepted that few people ever read a step-by-step explanation or such and thus think that finding ways to make the interface more self-explanatory is the best way forward. I think this will be very possible (except for the one special case, your nr 2). We need some kind of installation wizard to get the sound card going and then a self explanatory UI.

[atsampson]

The only reason I can see for ["Mute Myself"] is to test out ones signal without disturbing others on a server. It may be useful as a special case, but in general it is way too difficult to understand.

The physical analogy of this is a mute pedal for an amplified instrument - something I wouldn't gig without. It's the button you press if you're tuning your instrument, or if you want to play along without other people being able to hear you (e.g. because you're trying to work out how to accompany a piece you don't know yet). I imagine it's not very useful for choral groups, but when I'm playing an instrument on Jamulus I use it all the time.

[gene96817]

OR to mute your sound because of a local interruption (from family or pets or a telephone call).

[atsampson]

Thing is, I've been considering - and others have asked for - greater detail on levels, such as written dB values rather than just the markings we currently use. Large meters are required by some.

Indeed - proper dB scales on the faders and meters would be very useful, especially when Jamulus is being used to mix a live performance. I also wonder if it'd be worth experimenting with the meter dynamics to get them a bit closer to a standard PPM (the code does do slow fallback, but at present they respond a bit too quickly to give a good idea of typical level for percussive instruments).

[gilgongo]

@dcorson-ticino-com

Going through those cases: (assuming we are not in an error case) ... but for our use case is necessary.

Sorry, I wasn't asking why they happen or if they are needed. My point was that when Jamulus presents itself as a mixing desk, these things (and they are just some examples, there may be more) contradict that presentation. When that contradiction happens, confusion arises. This is a fundamental (some would say the most fundamental) problem with skeuomorphism. The way you counter this problem is to design the UI such that people don't or can't make misleading assumptions.

Another argument against skeuomorphism is also that the designer can be free to optimise the UI for other things. You will notice from my first prototype that I attempted to create space for things like first time usage, help, telemetry and large or small ensembles for instance. These are "mechanical" considerations that have little to do with mixing desks.

The argument for it is of course recognition. And in practice you can't abandon "patterns" altogether. So it's a balance.

Whether the display analogy is a mixing desk, a DAW or "something completely different", the information we need to provide is the same.

That's not always true. Quite often in UI design you discover things that can be removed or added through the application of design. I suspect we may find some of those over time.

All the people that I have worked with to get up and running say that Jamulus is actually quite simple once one understands the interface.

Well yes, that's worth bearing in mind (as is the fact that only 6% of survey respondents describe Jamulus as hard understand).

But ease of using isn't the whole issue when it comes to UI design.

[gene96817]

I am in general agreement. However regarding "only 6% of the survey respondents", that pool of people are of those successfully using Jamulus. Most of the people who find Jamulus hard to understand probably never saw the survey.

[gilgongo]

But focusing on a completely new UI, how would the process of implementation go? I'm curious what the first steps would be. Could this be something we put on the roadmap as discussed previously?

I've mainly been silent about the UI overall because I don't know what the situation is with the Qt UI framework is or what's feasible. I suspect large changes would be very hard work though (and might even require a fork).

The changes @dcorson-ticino-com proposes are at least feasible though, so perhaps we should discuss your question more fully. Should we create a component library? Re-engineer the UI layer in some way to make it easier to change in future? I'm not qualified to know.

@gene96817

regarding "only 6% of the survey respondents", that pool of people are of those successfully using Jamulus. Most of the people who find Jamulus hard to understand probably never saw the survey.

Yes, that's the problem with surveys (and why I don't publish the results on the website). But if you imply that large numbers in fact abandon Jamulus when they encounter problems, then that contradicts @dcorson-ticino-com assertion that most people find it easy enough.

[pljones]

I think the thing is it's not difficult to learn how to use Jamulus -- that doesn't mean it's inherently obvious, depending on your background. If you have sufficient motivation to put effort in, you may "get it" and then feel that it's easy to use. If your first impression is that it simply doesn't work "plug-n-play" and give up, then - as @gene96817 says - you'll not be interested in any surveys...

Of course, organised groups using Jamulus have that motivation.

So, really, it's the hand-holding at first usage that might be critical, over all other usage factors.

[gilgongo]

So, really, it's the hand-holding at first usage that might be critical, over all other usage factors.

I don't really see the issues as zoned into first time use vs long-term use, if that's what you mean. That said, we could consider a "first run UI" as a completely separate thing that steps you through the process of setting up before landing you in the current UI perhaps. This would be where, for example, the idea of a loopback test could live.

[gene96817]

I don't have a big enough sample space to consider my experience (globally) representative.

Installation is the challenge. My experience is about 15-20% of the users in an ensemble can only succeed with hand-holding or installation service. The need for social distancing makes this challenging. ASIO configuration is two-thirds of the struggle.

Once the user is installed, Jamulus is pretty easy to learn. However, some users have a lot of mythology (aka misconceptions) about what needs to be done. The work on improving the UI will be a big help.

[ann0see]

Didn't follow the whole discussion, but a few thoughts after skimming through it:

All the people that I have worked with to get up and running say that Jamulus is actually quite simple once one understands the interface.

The same was my impression. For me I'd conclude, that adding big changes might not be the right thing.

Moving away from the mixing desk might or might not solve the problem (I think the main problems are during setup, mainly ASIO4ALL which I would like to focus in future). I'm quite sure, that we should not completely move away from the mixing desk. I think, this is in fact the thing people "know" or understand easily. It could be improved, sure (I assume you already discussed this). I wouldn't completely get rid of it.

Moving away from the term "server" does not necessarily make Jamulus easier. All people I helped, got the client/server idea quite fast (and I have a few non tech people).

ASIO configuration is two-thirds of the struggle.

I received a message from the developer of ASIO4ALL a few days ago. Version 2.13 might solve some issues (version 2.14 seems to use a workaround for a bug which probably has negative side effects).

[gilgongo]

Moving away from the mixing desk might or might not solve the problem

@ann0see BTW I think we need to be careful which "problem" we are talking about at any one time:

1. New user setup and getting things running.
2. General usability (eg "Press mute on my channel or mute myself - which is it again?", "Why can't they hear me? Oh, they've muted me, didn't see that...", "I didn't realise there was somebody on the chat there" etc.)
3. "Future-proofing" and UI scalability/IA for new as yet unknown features.

2 and 3 I think we agree are less pressing problems right now, yes? (I ask because I am having a go at compiling a roadmap for Jamulus...)

PS: "Moving away from the term "server" does not necessarily make Jamulus easier. " I don't think anyone is suggesting that - or have I missed something?

[pljones]

"Press mute on my channel or mute myself - which is it again?"

Since we've had "Mute myself", I've heard fewer problems with muting rather than more - so increasing facility has eased usability, despite increasing complexity to enable it.

"Why can't they hear me? Oh, they've muted me, didn't see that..."

There aren't many things you can do other than explain that there are two reasons: you've muted yourself or they've muted you - and both are shown on the UI. The question being raised, I think, is can we make it clearer which is the case without having to hand-hold. It took me quite a while to "get" the new mute icon... So I can back this one more comfortably as something we can likely improve. I've no suggestions on how, as now I've got it it seems a sensible method.

"I didn't realise there was somebody on the chat there"

Some people don't have their performance location near their monitor and won't notice anything happening except into their ears. Not much you can do about it. Those same people won't see the mute icon, of course... Should we have audible prompting for every UI update? I think that would annoy more than help.

[Hk1020]

"Press mute on my channel or mute myself - which is it again?"

Since we've had "Mute myself", I've heard fewer problems with muting rather than more - so increasing facility has eased usability, despite increasing complexity to enable it.

"Why can't they hear me? Oh, they've muted me, didn't see that..."

There aren't many things you can do other than explain that there are two reasons: you've muted yourself or they've muted you - and both are shown on the UI. The question being raised, I think, is can we make it clearer which is the case without having to hand-hold. It took me quite a while to "get" the new mute icon... So I can back this one more comfortably as something we can likely improve. I've no suggestions on how, as now I've got it it seems a sensible method.

For this I made a suggestion in #933

"I didn't realise there was somebody on the chat there"

Some people don't have their performance location near their monitor and won't notice anything happening except into their ears. Not much you can do about it.

In my experience the main reason is that the chat is a separate window. Many people aren’t used to use anything but a single fullscreen window. They are confused otherwise. Sounds strange to us but that’s how it is.

[gilgongo]

@pljones Yes, but wasn't intending to kick off a discussion about those points, they're just examples to illustrate and I have no idea if they are even significant issues or not. I was asking the question:

2 and 3 I think we agree are less pressing problems right now, yes? (I ask because I am having a go at compiling a roadmap for Jamulus...)

Which would be good to get an answer to :-)

[pljones]

Yes, I think the most pressing issue is initial user guidance to a successful first jam.

But as I've said elsewhere, I think this should be outside Jamulus as it's potentially single use code.

[gilgongo]

Yes, I think the most pressing issue is initial user guidance to a successful first jam.

OK - and I assume others agree. The reason I press this point is that we are accumulating a large bunch of (mostly partially formed) to-dos at the moment and an attempt to prioritise may be worth a go.

I think this should be outside Jamulus

That makes two of us then https://github.com/jamulussoftware/jamulus/issues/958#issuecomment-778385231

[dcorson-ticino-com]

Yes, I think the most pressing issue is initial user guidance to a successful first jam.

I agree completely, in my vocabulary that is the start-up wizard. Unfortunately I have no competences with sound drivers etc. and it will be a lot of work on each of the 3 different platforms. But that is now highest priority I think.

[Hk1020]

Yes, I think the most pressing issue is initial user guidance to a successful first jam.

OK - and I assume others agree.

Don‘t focus too much on jamming. Don’t forget all the choirs and ensembles. They struggle with the audio setup (hardware) and are not tech savvy by any means.