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" #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]

I wouldn't leave the Server list displayed all the time,

I think a lot of people ("jam hopping") would like the list up all the time. It's a bit annoying that it can stay open all the time you're connected, then closes the moment you change server, so you have to open it again. It seems pointless to close it by default.

the vertical scrolling orientation of the faders

ReaNINJAM does it that way - I've always preferred it.

this takes us back to my original point about the presentation of Jamulus as a mixing desk. I think it sets people up for misunderstandings.

Possibly. It may depend on where you think the mixing desk is (i.e. it's at the server, you're just operating it remotely). But do we have alternative analogies that prevent any misunderstanding?

[dcorson-ticino-com]

But do we have alternative analogies that prevent any misunderstanding?

I am not aware of one.
For me Jonathan's "not a mixing table" suggestion is a mixing table in other clothes. I see two analogies being used; the physical mixing table and the DAW, a mixing table compressed for a computer screen with other functions on top.
I am for keeping the mixing table analogy for several reasons; - history "the Jamulus feel", - a mixing table and a basic idea of how it works is I think generally better known through film and TV than a DAW, - moving to another analogy will not solve the problems of understanding we see which are caused by the illusion we are creating with Jamulus that the people are really all together in the same room, - a DAW is in the best case dauntingly complicated, the opposite of the feeling we want to transport even if we are able to simplify.

[gilgongo]

But do we have alternative analogies that prevent any misunderstanding?

I am not aware of one.

Well, I've posted two in this thread already :-) Of course, they are going to have to echo at least some aspects of a mixing desk because of the fundamental concept of a sound mix, muting, volume adjustment, etc.

moving to another analogy will not solve the problems of understanding we see which are caused by the illusion we are creating with Jamulus that the people are really all together in the same room

I'll quite understand if people want to have a skeuomorphic design for Jamulus (basically: following the structure of something that was never intended to exist in a virtual context, and adding LEDs, 3D lighting effects, rivets in the corners etc.). Just as long as we are aware of what the possible disadvantages of that are:

1. Encouraging people to make incorrect assumptions from the way it looks about the way it works
2. Sacrificing opportunities to scale the UI for the future.

These points I'm making aren't just my own opinion BTW (in fact I try not to make any judgement from my own point of view really). These are issues of design "strategy" if you like, which need to be discussed as well as (and preferably before) setting out to make any design interventions.

[gene96817]

I would be interested in a discussion about the scaling challenges and possible solutions.

[gilgongo]

@gene96817 I posted a video showing what I think might be a relatively easy(...?) re-structuring that would provide such scale while using the existing UI concepts. Still needs some thought I think though. In particular, I think we might benefit from the introduction of an "inspector panel" for (at first) showing user's profiles and/or allowing interactions on them, but also objects perhaps. Will see if I can post another version soon.

[gene96817]

I don't feel I have enough jamming hours (e.g. in the hundreds), to have a strong opinion. However, I do have some initial opinions. (1) I like to have the main window on my primary monitor and all the other windows on my smaller notebook display. The tabs approach would force switching away from the main window. (2) For a large ensemble (e.g. a 100+ chorus) how are all the musicians and sliders managed? (I expect to deal with this in a few months.) How many sliders can be effectively displayed? For scaling, would it help to nest sliders into sections?

[dcorson-ticino-com]

Ok, I thought that scaling meant how we display hundreds of users.
I wouldn't have imagined that it meant placing windows around the main window.
I any case I have intended to go in that direction too and an "inspector window" would be the first thing to do, but I need to warm up my old and squeaky C++ to get any farther.

[dcorson-ticino-com]

I have not found a practical way of showing the magical sound path graphically. So I have tried a back to the basics route.
Not connected:

Connected

Connected and stream muted

Server recording (jpg is having real problems with that one. It is actually very readable.)

This seems to me to be clear even though it will be a challenge for the translators.
I see 3 further things: - highlight users who are not muted (maybe sort them to the left too) - sliding window on the right with chat and setup - sliding window to the left with server list (not updated during a connection)
Unfortunately my C++ is too limited to see for the moment how to implement the sliding windows.

[jugo6]

When we start to colorize, wouldn't it be neat to colour the connect / disconnect button according to state? It doesn't look very inviting now.

[gene96817]

Please don't move the users according to their mute-status. It would be really distracting for sliders to be jumping around.

[dcorson-ticino-com]

@gene96817 Understood. Agreed.

[gene96817]

Would it be simple to dim the slider? Easy to notice without changing the visual focus.

[pljones]

Also, can we show an example using Compact Skin - I use Fancy skin for far less than half the time I'm jamming - occasional use, except when I'm doing Sound Check on WorldJam. (Hence why I'd like the non-Fancy meters to have proper markings: the LEDs have functional use that isn't available in the other skins.)

[jugo6]

that would be a welcome addition. compact but fully functional!

[dcorson-ticino-com]

As you wish
Where do you want to add proper markings on the compact skin? On the normal skin e could push things around a bit. How many digits do we need? -12 would be enough or do we need -12db for each label?

[pljones]

I can live without numbers if the scale is marked at 6dB intervals from 0dB downwards - alternate marks could be slightly different to make counting easier. I'd prefer marking in "regular" 6dB marks to marking the values received from the server, too (i.e. not the same position as the LEDs, in effect).

(And as I mentioned - I'd still like the input level displayed the same size as the mixer...)

[gilgongo]

Hi all - just moving to this to a Discussion so that we can keep Issues to being for actionable things that we can put on the backlog/prioritise.

[ann0see]

Also see #1150