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]

@Hk1020 Yes, in fact in the design of this I was going to look at a "scenario based" approach, which would attempt to suggest different things depending on which was chosen. So eg. "I'm using a microphone only" would be a different help path to "I'm using an electronic instrument and a microphone for singing/talking".

[pljones]

Don‘t focus too much on jamming. Don’t forget all the choirs and ensembles

There's no difference in my mind. You get onto a server and are part of whatever's going on there. "Jamming" comes from the word "Jamulus" in that sense.

[Hk1020]

Don‘t focus too much on jamming. Don’t forget all the choirs and ensembles

There's no difference in my mind. You get onto a server and are part of whatever's going on there. "Jamming" comes from the word "Jamulus" in that sense.

I know. But choirs and ensembles usually don’t use any technology to make music while you won’t have much luck with an electric guitar without plugging it into something. So the guitarist knows how to connect to a computer and is quite used to it while the choristers are afraid of the machine and rather not use it.

And it seems easier to connect a guitar to a computer than to get a working acoustic setup with mikes and headphones.

[gilgongo]

But choirs and ensembles usually don’t use any technology to make music

This is why "scenario based" onboarding as I described above might be good approach in the context of a "first time launch" perhaps (but not on the website docs BTW as I think that would lead to much chaos).

[pljones]

@Hk1020 - I'm terribly sorry -- I misclicked and didn't noticed till after saving. I edited your post rather than quoting... 🤦

And there doesn't appear to be any history... (Given this is a git repository issue system, that somehow seems rather surprising...)

[Hk1020]

@Hk1020 - I'm terribly sorry -- I misclicked and didn't noticed till after saving. I edited your post rather than quoting... 🤦

And there doesn't appear to be any history... (Given this is a git repository issue system, that somehow seems rather surprising...)

@pljones No problem. Could you do it because you are a moderator here? Because I can’t edit other people’s answers.

Actually, there is a history, I just discovered: click on the edited dropdown in the message's header line.

[pljones]

Aha! Thanks, didn't realise that.

And it seems easier to connect a guitar to a computer than to get a working acoustic setup with mikes and headphones.

I'll point out that there are plenty of acoustic drummers on Jamulus - but I'll certainly accept that all the ones I'm aware are quite happy sorting out their own mix in hardware, which does mean they're definitely more "technologically adept" that a generally chorister needs to be.

As @gilgongo says, different levels of support on "Day One" are needed, depending on the starting point.

[gene96817]

@Hk1020 Don't assume singers don't have additional equipment. Some singers put significant effort into microphones and recording technology too. However, the barrier to becoming a novice singer is very low and inexpensive.

[dcorson-ticino-com]

A third attempt. The mic and headphones are now just decoration. I found it confusing to use the mic as mute oneself as it doesn't really mute the mic, it mutes the stream. "Server is Recording" also has it's own frame. What do you think ? I am starting to like it.

[chrisrimple]

I think the "arrows" are confusing. The actual flow is:

Client > Server > Client

Maybe change the upper section to flow left-to-right, then down to faders? Something like...

Input (pan, reverb) > Mute Myself > Connect (delay, buffers, settings, chat) v Server (faders)

[dcorson-ticino-com]

Hi Chris, What you describe is exactly what I see. On the client from the left, my mic > my levels > pan > reverb > mute > stream to the server on the cloud, mix with the other musicians > return to my client > (indication of connection quality) >my headphones. What am I missing? Maybe the chat and settings buttons in the signal path are disturbing?

[WolfganP]

A third attempt. The mic and headphones are now just decoration. I found it confusing to use the mic as mute oneself as it doesn't really mute the mic, it mutes the stream. "Server is Recording" also has it's own frame. What do you think ? I am starting to like it.

Good work! Maybe changing the line style for the "arrow" segments (to double or bold) to contrast with the rest of the section box, may be better to signify the flow of data and not just interpret it as part of the box decoration.

Did you try a mock up with those arrows to the sides (just below the mic/headphones icons) and see if it's visually more clear?

[chrisrimple]

@dcorson-ticino-com My point is that what you're describing (and what's shown) is not what's actually happening. Let's think about the order in which a user performs tasks:

1. Run client
2. Set settings (including Device selection)
3. Set inputs (pan, reverb, mute myself)
4. Choose server and Connect
5. Observe connection (delay, buffers) and adjust settings if needed
6. Listen to server sound (including self) and adjust (faders, mute, solo, grp)
7. Make music

So imagine a layout like:

Settings > Inputs > Connect > Server sound

Here's a gross approximation:

Also, with that order, the Mic icon belongs with Settings / Inputs, while the Headphone icon belongs with Server Sound (faders)

[chrisrimple]

In another thread on the menu layout, I noticed...

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.

In the new UI design, perhaps that should be added.

[pljones]

The mixer, of course, happens at the server, so showing it after the server isn't right, either.

[dcorson-ticino-com]

the order in which a user performs tasks: Run client Set settings (including Device selection) Set inputs (pan, reverb, mute myself)

Just for my info, do you really do this each time you run Jamulus?
For me device selection and network settings are setup that I very rarely change. Except for testing things out, the only thing I sometimes change is the small buffer checkbox as not all servers work with it set.

In any case the flow of this UI is not from right to left the steps I go through to get up and connected.
It is the flow of the sound data, from the mic, to the server, and back to the headphones.

[Hk1020]

The mixer, of course, happens at the server, so showing it after the server isn't right, either.

So it has to go after the Disconnect cloud. Then the diagram starts to make sense and might actually be helpful. It would make it clear that changing the faders only affects me and nobody else.

[chrisrimple]

@pljones I'm differentiating between what actually happens behind the scenes and the user's perception. While mixing may actually happen at the server, from the user's perspective it's what's received that is controlled by the faders (even if that control is being exercised at the server).

@dcorson-ticino-com Yes, I always (1) run client, (2) check Settings to ensure that they're right (usually they are, having been retained), (3) mute myself (if joining a new/full server), (4) connect, (5) adjust faders. I also run multiple clients, so (2) becomes more important.

[pljones]

The user should perceive that the mix happens at the server. Unless they understand this, they're likely not to understand some of the things that the controls that are possible do.

Everyone could just pretend magic happens, of course. That keeps them from worrying about reality.

[gilgongo]

Everyone could just pretend magic happens, of course.

I think that is a valid design principle.

Right now, we're pursuing a principle of "explain the system" in the UI. When I gave that a go, I concluded it was pretty difficult, made more so by having a mixing desk presentation. So instead I decided it was easier to abandon the mixing desk metaphor and simply present Jamulus as its own application that does what it does without reference to anything else (much).

[dcorson-ticino-com]

While mixing may actually happen at the server, from the user's perspective it's what's received that is controlled by the faders

Give me a couple of days, maybe I can reconcile the two thoughts, which aren't that far apart.

@gilgongo Please show us the non-mixing desk example. Everything I have seen up 'til now is a mixing desk that had a different interior decorator.

[gilgongo]

@dcorson-ticino-com It's in the video I posted before: https://github.com/jamulussoftware/jamulus/issues/958#issuecomment-774548303

EDIT: just did this video to illustrate what I mean by scaling (and some other things). 15Mb mp4 - turn sound on.

[pljones]

Everyone could just pretend magic happens, of course.

I think that is a valid design principle.

Right now, we're pursuing a principle of "explain the system" in the UI. When I gave that a go, I concluded it was pretty difficult, made more so by having a mixing desk presentation. So instead I decided it was easier to abandon the mixing desk metaphor and simply present Jamulus as its own application that does what it does without reference to anything else (much).

The problem comes when you're hindering the user by hiding information. If they end up misunderstanding - that is, not having been told the truth and having made something up to fill in the gap and got it wrong - then you're likely to make their experience worse. Knowing that there are things you can control and things you cannot control - and saying why - does help people understand. Not saying why can lead to them re-interpreting what you've told them to fit into what they think is happening. They don't hear what you said, they hear what they wanted to hear.

[chrisrimple]

I finally had time to watch @gilgongo's videos (linked further up the thread) and really like the thinking there. Everyone should take a look at them.

I wouldn't leave the Server list displayed all the time, since it eats up a lot of screen real estate, but left-navigation+right-panel(s) layout is great and extensible. I also much prefer the vertical scrolling orientation of the faders (to the existing horizontal scrolling orientation) - it's easier for users to understand and better solves for situations in which there are 50+ users on a server.

[gilgongo]

@pljones

The problem comes when you're hindering the user by hiding information.

Millions of people use quite complex things like Zoom or WhatsApp or online banking, which make no real attempt to explain their underlying concepts beyond the immediate user value(s). I myself don't understand how a toilet or a refrigerator works. But on the other hand, the definition of usability is something acting as expected. So when you say:

Not saying why can lead to them re-interpreting what you've told them to fit into what they think is happening.

... 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. It's not the only problem of course, but I think it's part of it.

[gilgongo]

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

Yes, that was just us playing about as a result of a conversation about jam-hopping. I might try a re-cut, also with the idea of muted and non-hearing people being moved out of the "room" space.

the vertical scrolling orientation of the faders

This was a result of talking to a choirmaster who suggested it (thereby also facilitating sorting and stuff). I think it actually works OK with small groups too, even better if could be "responsive" to the number of channels(!). Note also the concept of an "Inspector panel" which could be used in future to display other information about the player (or indeed other objects selected). Scalability.

[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.

[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.)

[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?

[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.