Then give them what they ask for. It is a bad idea to force them to use a system they don’t want to use. Even if you think it is better. This is not something we can fix with user interface design or by having a tutorial at the start that tries to sell the “yes, ok, it’s slightly different, but it’s better, you really should try it!”
This works both ways. If you think a tutorial app would improve things, this should also be backed by an UX study, and to me it is not obyious at all that it would work.
Also you are assuming that developers here know nothing about UX, which is just rude and just plain wrong for at leastsome of us. So can we stop to pit developers against ux people and try to work together?
Except, as I said in my previous post, it is a video review and the people doing that are only a small subset of our users, and they will want to dive into things by themselves, not spend time on screen reading documentation. Basing our UX study on that subset of users only creates a bias, and will end up with extremes and silly measures that are not really needed. Basically preventing them to do their video review immediately, and forcing them to go through the training first, because their mind is already set in doing an interesting video, and not in reading documentation.
We should really do an ux study with users that are not doing a video review, and it’s quite likely they will be more receptive to the idea of reading documentation.
This does not mean I think there is no problem with the ux design. Yes, the leaf menu is not discoverable. Yes, the dragger to move the deskbar needs to be reworked too, people who want it don’t know where it is, and people who trigger it by accident don’t know how to move their deskbar back. No one will argue against this, these are well known issues.
Now the discussion is on how we solve this. I am not convinced the “welcome app” will improve things a lot compared to the existing quicktour, in fact it is even worse if you make it show on first boot and then disappear forever. Help should be available at all times when the user decides they need it. Hence the current solution to have it always reachable on the desktop.
But having to read the docs or go the tutorial is already a failure. So we need to make it more obvious that the leaf menu is a menu. Again, no one is going to argue against that and it is a known problem. I would like to avoid something as extreme as the windows 95 “click here to start” animation. Before resorting to that, we can play with a lot of other things: label the button, make it more obvious that it is a button (by further improving our control look to make buttons stand out more), maybe rearrange things in the deskbar so it looks less like a header at the top of it or some kind of decorative element.
In Windows 95, they did all of this, and it still wasn’t enough. So they added the animation.
In Linux (in particular GNOME, I think) they went a different way: no matter what they tried, no one would go to that menu. So they removed the menu and made things accessible in other ways instead. For example right-clicking the desktop.
Since there are other discussions about integrating quicklaunch or something similar into the deskbar, we can use that opportunity to remove the Button No One Wants to See. Instead we can have a textfield, which 1) is more recognizable and 2) can easily be labelled with a “Search…” text or magnifying glass icon or similar. This is something users may be more likely to click. When they do so, we can pop our menu, and let the user type something to filter the menu.
Of course this should be studied with users (both experienced Haiku users and newcomers to the system (I don’t know what “normies” mean and I don’t like the implication that some users or developers are abnormal in some way, so I will not use this wording). I suspect experienced users may like the extra functionality to easily search in the menu, and newcomers will have a more obvious/discoverable widget instead of the current leaf logo.
I used this specific example of the leaf menu to show how an UX study should be conduced:
- identify the problem and the part of the users that is affected by it
- try to look for existing solutions in other systems (which is good, because a) probably they did some ux research already and b) users having experience with that other system will find their marks more easily)
- think of a solution, use the opportunity to see if we can solve a wider problem (I discussed two: integrating quicklaunch into deskbar, and reworking the control look to make buttons stand out more)
- implement and test with another run of ux study
…and of course at all points, no need to be condescending about users being bad at computers, or developers being clueless about ux design. This would just put everyone in a bad mood for no reason at all, and it’s distracting everyone from the actual problems.