Modern User Interface Design

[c-ybeRider]

Hello guys,
i am very new in this git scene and also not sure about to create a discussion for it.
But i just want to throw in here something to discuss or just to exchange some minds and impressions with you guys.

I love playing with e-drums and using Jamulus to jam with people together. And each times i open Jamulus (Windows 10),
i have the feeling that the application looks a little bit outdated compared to common audio software tools.

Because of my software development experience, i was able to set up the Qt dev-env and played around a little bit and redesigned some elements.

What do you guys thing about? Does it makes sense to continue with it or do i go in the wrong direction maybe?

I have some screenshots for you to visualize..

[ann0see]

Hi @c-ybeRider yes, I think there are some issues about updating the UI: #899

certainly the current UI is dated 😀.

I‘d suggest to talk to

@jamulussoftware/designers @dcorson-ticino-com about updating the graphics.

Personally I‘d like something like KOORD suggests on their website: https://koord.live/downloads

so a more flat, modern design, based on the logo/website colors.

[dcorson-ticino-com]

I think this looks better than what koord has in their program
The modern looking stuff is just a picture on the koord website.
Their program is standard Jamulus with a couple new images and a changed connect window.
@c-ybeRider feel free to make suggestions, but there are so many different usages of Jamulus that it is hard to find any consensus in how it should be. What looks good for 5 players is a disaster for >50, etc.
But maybe you can find the magic bullet :)

[gilgongo]

@c-ybeRider I think in terms of a UI "style refresh" then that's certainly good if we are to take the UI further along the path it's traditionally taken. So if you wanted to keep going, then personally I don't see any harm in submitting a PR for it.

As @ann0see implies though, there is a debate about the longer term direction of the UI. Firstly in terms of the visual style (the large icon set is also a bit of an elephant in the room when it comes to that), but then also about the structure of the UI itself. The former implies a lot of work in terms of art direction and getting buy-in from "old hands" who will - by the iron law of such things - hate it. The latter is perhaps even more contentious and time consuming although there have been some forays into that. So it's a bit of a poisoned chalice I think, and I'd be the first to admit I'd not want to take it on.

But don't let me put you off. Your work so far is as I say a nice refresh and I'd be curious to see what others think.

[dcorson-ticino-com]

Looking at the challenges...
Making a DAW-looking UI similar to that shown on the link above for the controls shouldn't be that difficult..., but what to do with the user window, we will need instrument icons in a corresponding style and maybe new flags. The different colors for expert, etc. and group, must also be made to fit in, indicated differently or removed. That looks to me to be a major work package for a good designer, just that little bit. It is in any case outside any competence I may have.

[gilgongo]

That looks to me to be a major work package for a good designer

This is why I think most F/LOSS projects have to resort to fundraising for more serious UI design.

[c-ybeRider]

Hi guys,
Thank you for your feedback and sharing your minds.

Maybe i would like to go a bit deeper.
I am absolutely with you guys and i know that it is very important to consider the various needs and usage of all the different Jamulus users. Therefore my first approach was to take Jamulus right out of the box and change some existing elements to get a more fresh apperiance. But not to change the usual element arrangements and behavior, to keep the common Jamulus feeling.

For example the toggle switch buttons, levelmeter leds as well as the level slider, i designed completely new via Gimp and replaced them by the existing ones. The connection button was a bit more tricky regarding its behavior and some other complications like, button code location and structure, no stylesheet support for shadow effects and so on.
Where i stucked at last when i tried to change the dial-button apperiance, where an additial qt-addon needs to be implemented.
This implementation seems too complicated for me at this time as the general Jamulus code structure seems to me a little bit complicated but this is because i am not familiar in detail with the code atm.
As software developer point of view i also missing i bit more consequent commenting culture like each function has its function-header, functions are not too big and so on but this is just my personal opinion.

Well, i think to redesign the complete Jamulus surface including respective dynamic behavior, like "koord" (https://koord.live/downloads) is showing, will be a huge workpackage that not only affects to designers but also to programmers.
But what maybe can be handled with not to huge changes with an adequat efford, could be a smaller facelift of the main Jamulus dialog.

Maybe i could provide you my repository to check out my changes and to test a little bit, when you are interested?

And i am glad for further discussions :)

[ann0see]

I think they should be in the same blue as the website – if possible.

@mulyaj as Design er and some accessibility experts should then have a look at your proposal. Ofc. there’s no guarantee that your changes get merged, but it’s good to have a discussion about facelifting the UI.

My personal wish would be to have the software and website consistent. The design of the website is heavily based on the logo by @geheimerEichkater.

The site is not designed by a professional (mainly the design was made by a small group including myself), so there are some errors surely.

[mulyaj]

I like the proposal for a UI facelift. As others have already suggested, I think I'd also prefer a flat design ala koord.

[henkdegroot]

Guess the Modern Design can also be included as a skin, as it is mainly a different look.

[geheimerEichkater]

@c-ybeRider is tapping into interesting terrain and has already cleaned up nicely with his layout. The look is one thing, the over all User Experience is a different beast. Sure enough, there is a rich history to the project and many features have grown.
There is a learning curve for setting up and using Jamulus, and since there's no guided on-boarding when opening the app for the first time, a couple of naming choices are confusing or ambivalent (e.g. own input channel vs. general channel "Mute"), as are some behaviors (e.g. pan pots could use a haptic center point and would benefit from double-click to center, also click and drag up/down or left/right helps using the pan pots). Input channesl left/right (if two channels are provided) should be a pan pot, not a fader.
On the left side of the interface application preferences currently occupy the same space as input channel controls, here the proximity of those elements creates confusion, it's in the underlying topography. But I have no experience with QT so I cannot tell to what degree changes are even possible?
I think Jamulus' users can benefit a great deal if we ask what feature is needed in what context and how to make them available. The UI and resulting experience is not a mere question of a nicer looking skin :)

[gilgongo]

Yes, I think though that if we can keep interaction design and visual design conversations separate then that would make things easier to discuss at least.

[38github]

An option to make chat and settings windows as tabs is something I think I would really like. Now the program opens up and I have the different windows in various places.

If I stay on topic I personally like very flat themes to keep my attention on other things.

[pljones]

I don't use the chat, and it gets annoying having it pop up.

It's used for required interactions, unfortunately. The server welcome message is displayed here and the server can require you to read it, so it's required that it pop up.

[dcorson-ticino-com]

I made a version with dockable windows a while ago, so one could have all in one pane or separate windows or some windows separate and others on the pane. It didn't seem to interest anyone 'though.

[henkdegroot]

It didn't seem to interest anyone 'though.

I was very interested in that design, still a big fan of that. Even pointed someone to that recently when it came up in a discussion.
I think it was at the time that we found several issue on macOS with the use of TABs. Perhaps we should check again now we have two different versions for mac?

[ghost]

Is it practical or possible (after >30 years of technological advancements) to have the GUI separate from the application?
C++ was invented for this but seems to result in throw-away code (including the application) instead of reusable code.

[pljones]

CClient and CClientUI are two separate classes now. So they're already separate. What separation were you looking for?

Admittedly, the architecture could be improved -- and I'm working on it now.

[ghost]

What separation were you looking for?

The more separation the better. If CClient and CClientUI could be two separate applications that comunicate, that would be ideal because you could have many different CClientUI's.
However, it would be good enough if the different CClientUI's were a make option which doesn't make a mess of CClient.