More > JRiver Media Center 27 for Mac

UX Suggestions for Setup

<< < (3/5) > >>

wer:

--- Quote from: Petr Stedry on March 04, 2021, 01:47:53 pm ---To reply to wer → I'd be wary of these problematic situations with regards to complex UIs:

* There is a user that does not need a feature, yet has to ignore it in the UI (the Product manager did not say NO enough times?, someone outside of the target audience is trying to use the product?)
* There is a user that needs a feature, yet does not understand how to use the UI to get the expected result (the person designing the UI has still some work to do)
#1 is not helped by supplying the user with more information, only #2 is – and the goal of the help is not to teach the user basic information about what he wants to do, but rather how to use the available controls to achieve what they need.
...
P.S.: The better the person designing the UI understands the knowledge, mental models, skills, and expectations of the primary target audience the better the outcome.

--- End quote ---

Petr, you seem to be asserting that if the UI designer has done his job correctly, then:
1. The user will always be able to understand the interface without information, documentation, or anything else.
2. That the user will never have to see interface elements for a feature he does not want.

But these things are just false. You seem to have fallen into common traps: believing what is true of you is true of everyone else, and believing that all users are the same, or homogeneous. Your point #1 seems to say that if you can find a user who doesn't want a particular feature, the Product Manager should not have put that feature in. Absurd. You'd end up with a product with no features at all, since you can always find someone who doesn't need something.

The fact of the matter is that users have different needs, and different abilities.  Regardless of the type of product, some users are extremely clever and technical, and some users are extremely stupid and clumsy.  For a product like MC, some users want video capabilities, whereas some users only want audio, and they don't want to see anything having to do with video.  Some users want customization, some users want nothing other than for the app to play their music when they tap it.

Just because you do not want to see an interface element, does not mean that no one else wants to see it either. Should MC have more hideable controls? Sure. But any controls hidden by default would result in complaints by users. Then there'd have to be controls to hide and unhide the controls. UIs don't function telepathically.

Consider the simplest possible appliance: a toaster.  Even a child must be shown how to use it the first time.  If you live in a town with absolutely no crime, the car you purchase will still have locks.

I do not dispute that the MC interface could be improved.  But because of the requirements of its users, it must do many, MANY things. Because of that, there must be a certain amount of complexity that requires explanation.  The more functionality your take out or hide, to protect the sensibilities of people who don't want those features, the more you impair people who do.

Consider what Apple has done with their phone OS, now called iOS. They have more UI and UX designers than you can shake a stick at.  The early interfaces had very simple touch controls. And Apple was met with constant cries of "WTF! There is no way for me to do this, or that, or this other thing."  Now look at all the different ways you have to tap and hold and press harder swipe left, right, up, down, 2-fingers, 4-fingers, and all sorts of other non-intuitive nonsense.  Or consider the paradox of buttons and icons: small pictures labeled with words are provably more usable and understandable than small pictures without.  But label all the buttons, and people complain that too much space is taken up on the screen.  Once you learn what a pictogram means, it is easier. But before that, it is not.  Have you ever tried introducing an elderly person to a modern audio device?  They ask where the PLAY button is. A right-pointing triangle is not PLAY until you learn that.

People have various levels of knowledge and experience that they bring with them.  There is no application, or device, that can be all things to all people, and to assert otherwise is nonsense.  Because of the diversity of the user community, there is no way to make an interface that satisfies all people with regards to simplicity and hiding things they don't use, but still provides everything that everyone else wants, and requires no explanation.  A couple of small tweaks, like changing "Reset selection" to "Clear" and then avoiding any startup-guide/documentation/help and info just doesn't get it done.

JRiver should do better in UI design. But it is not "doing better" to pursue solely something that cannot be achieved at the expense of something that is required.  In other words, the MC interface should be improved, but it should be done along with providing the user the help and information they need, instead of thinking "just do the interface right and everyone will always understand everything".  The catch-22 is that JRiver will not do better documentation, and it's impossible to make the application so simplistic that no documentation is needed. So there will always be a gap, with people posting how it's too hard and needs to be better.

Sorry if this sounded like a bit of a rant, but this subject regarding MC has been getting discussed, in one form or another for years. And the broader subject of UI design for decades.

You're not the first, or only, person who wants the MC experience improved.

Petr Stedry:
Let me clarify.

What I wanted to say was that (perhaps I used too many words? 🤔):
→ in complex UIs those were two situations I would be more "careful" when designing for
AND
→ One of them is not helped (in terms of making the user satisfy his needs faster) by adding additional information to the user

Not that there are only these two situations, nor that everyone should be able to use any interface when first seeing it, nor that all interfaces are equally useable by anyone nor any of the multitude of statements you mention in your post (and that I do not wish to continue discussing).

Also, I think that these assumptions are valid and applicable in this case, given my experience:
1. The higher the number of features, the higher the number of interface elements
2. The higher the number of interface elements, the higher the cognitive load for a person to operate the interface
3. The lower the ratio of interface elements understood by the user to the total interface elements, the higher the time to find the element the person wants to use
4. The better the person designing the interface understands the people he is designing for, the more useful, learnable, and useable the interface will be
5. The more times a feature is not added to a product (given a finite total amount of features considered for addition), the fewer features it contains
6. The higher the ratio of features the user needs and knows how to use to total features, the higher the satisfaction of the user

I would end this nighttime thread (it's 10:57 PM around here) with a thought to reflect upon:
Each piece of software (and also its interface) is like a glacial valley. It was not created in a vacuum in an instant. It took a lot of forces (laws of physics, gravity, sunlight, wind, human work, microorganisms, or maybe even simple plants) a long time to create it. Now, that the glacier is gone it is hard to tell what those forces were. Yet the valley is there. The only testament to the forces that created it.

jkauff:
As a retired UX Designer with 40 years of experience, I can vouch for much of what Petr is saying. When you have users with different skill levels, experience, and needs, you need to accommodate multiple mental models. Power users don't mind a few extra clicks, because they don't change their setup very often once they've set things the way they want them, but the structure of the UI needs to make it obvious where those advanced features are. It also needs to provide a clear "path" for less experienced users to accomplish things like initial setup.

One truism I've learned is that UX Designers make lousy developers, because they don't understand the ramifications of making UI changes. Conversely, developers make lousy UX Designers because they have the whole structure of the program in their heads and can't possibly put themselves in the shoes of a novice. This can be easily demonstrated by putting designers in the observation room of a User Testing Lab and giving a short list of tasks to a variety of novice users.

MC does need a UX Designer, because that person will bring a totally different set of skills and tools to the task that developers should not be expected to have or develop. It's a waste of their valuable time.

bob:

--- Quote from: Wheaten on March 03, 2021, 05:27:37 pm ---But there is also some inconsistency between the OS release, like the DSP studio:

Windows Missing (Done button):


Linux:


--- End quote ---
There are 2 places in Linux MC that add a close button that aren't in the other OS versions.
This is for the specific reason that linux doesn't have to have a window manager (or even a GUI).
The close button in those 2 places allows linux MC to run without a window manager.

JimH:

--- Quote from: bob on March 05, 2021, 08:49:32 am ---There are 2 places in Linux MC that add a close button that aren't in the other OS versions.
This is for the specific reason that linux doesn't have to have a window manager (or even a GUI).
The close button in those 2 places allows linux MC to run without a window manager.

--- End quote ---
I also think there's a button missing on Windows.  The Load/Save button isn't a close or done button.   I believe it just loads and saves configurations.

Navigation

[0] Message Index

[#] Next page

[*] Previous page