Slashdot Mirror
An Optimized GUI Based On Users' Abilities
Ostracus writes "Researchers at the University of Washington have recently developed a system, which, for the first time, offers an instantly customizable approach to user interfaces. Each participant in the program is placed through a brief skills test, and then a mathematically-based version of the user interface optimized for his or her vision and motor abilities is generated. The current off-the-shelf designs are especially discouraging for the disabled, the elderly and others who have trouble controlling a mouse, because most computer programs have standardized button sizes, fonts, and layouts, which are designed for typical users."
would be a system that automatically and continuously monitors mouse movements and typing and continuously adjusts the user interface for the user's current skill level.
That way as you drink more beer the fonts get bigger and the mouse remains useable. Bonus points if eyeball movement can be detected and the screen be moved in time with the wobble.
I'm not sure that the idea will work at all. You spent half an hour for the program to learn about your abilities. During this time, it might have correctly guessed some of the settings which will be correct for you, but still it will be far from perfect and you might need to tweak it anyway. And I'm talking about the case when you have serious disabilities, if you don't, the task of this program will be hard.
Tweaking the settings on your own will take you less time, and even if they are not perfect, your false impression that you're fine with the GUI this way will actually improve your productivity. Not so if you spent twenty minutes doing bullshit and end up with a GUI settings that you find horrible at first.
The system might be useful if it does learn while you work, and it tries to guess what improvements to the interface would be necessary. One problem that in both cases this will be very hard to get right. I don't say it's impossible, it's good that someone is trying to do it, but unless they do take this very seriously and spend enourmous amount of time and money on research, this won't work.
And I'm sure that this time could be spent on researching what problems users actually have with the GUIs and in creating a suitable way for them to tweak them. Which means spending the time in actually improving the GUI itself.
Now, if tech support has troubles because of the changes, I think it will be the least of the problems. If the UI changed that much, the nightmares for the user will be guaranteed. Unless the user has serious disabilities, in which case the changes will actually help, even with tech support issues.
I have athralgia which prevents me from using a mouse. I rely heavily on keyboard shortcuts but use a trackball as a pointing device. I often find GUI buttons are too small and easily overshot - and the worst offenders often have dialogs without any support for keyboard shortcuts. InfraActive comes to mind - they even removed keyboard shortcuts between versions 7 and 8. Button scaling in many apps breaks the layout, or doesn't even work. While this is a interesting and useful development, I don't see anything changing soon on the disability usability front. There is existing support in common OSs for making global UI changes, but most apps ignore/override these settings or just break horribly because the UI developer didn't design the interface to adapt to these sort of changes.
I already use a better input system in my software. In my system, there is no testing phase. You just use the program, and it grows and shrinks with you. It's like having the best of vi (speed) and notepad (simplicity) at the same time.
But it does not even come close to my next project. And that's why I did not release it.
Because after optimizing the input interface, I realized, that the usual graphical user interfaces are a total piece of crap. The most annoying part is that they are built like they are the biggest enemy of the keyboard. And you can basically combine all control elements (buttons, sliders, menus, labels) into one thing.
If it is ready for the world, I'll release it as open source... something like a windowing and (g)ui toolkit with the power of the pipe operator in bash... hard to describe.
I just have to finish my current game project first.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
GEOS actually had a user skill level function. Not sure how aggressive it was in the later versions, but the earlier versions were quite aggressive.
The beginner mode had no file management - it just gave you an application, with a drastically simplified interface (no drop down menus,) and the program could only open one document, and I believe multitasking just didn't happen. There were giant EXIT and HELP buttons.
Intermediate mode had applications with a full user interface (but always maximized,) and you could manage a restricted subset of files.
Advanced let you do whatever you wanted, gave you full functionality, and actually had windowing, not maximized windows for everything.
Ditto for KDE 4. All the programs are very consistent.
I am color blind. And I can tell you that I HATE web designer! Why do they need to use, for example, light green for the links on white background?!
Ok Ok. Some designer think of it. But only in major websites...
That's already been tried....Don't you remember the wave of "simplified" consumer laptops circa 1999/2000? especially Compaqs? That is exactly what they had, a big button right above the keyboard that glowed and said "INTERNET." SOme later said "WWW."
Then, they thought they had a good thing going so they added a special button for everything they thought the technically un-savvy user would want to do, you know, little envelope email icon buttons, little house icon home buttons...I thought - "this will be perfect for my parents..." I was so wrong.
The thing is that it was one of those things that sounds great in theory, especially if you're providing front line tech support, but in the real world it didn't work so well - first off, they tried 20 different way to make it work - some would only launch a browser; some were set to launch a wizard to get you connected to the net; which was supposed to go away once you had a connection set up, and turn into a browser launch button - the problem there was that if the connection you had set up wasn't one of one or two types the damn thing would constantly launch the wizard....It never worked right.
But the worst part about all of these things is that people spent time on trying to get this "simplified" crap to work when conencting to the net the normal way wasn't difficult and was soemthing that could be taught to even the most untechnical elderly user as long as you had the patience.
Be wary of people trying to "simplify" things that aren't that complicated; or who try to offer "solutions" to problems which aren't really problems.
Some people will always spend more time looking for a shortcut than it would take them to learn the the proper way to do something....
If someone with less dexterity can't use you interface, there's a good chance that typical users find it usable but irritating. Yes, I can click on an 8x8 pixel square whereas maybe some people can't...but I shouldn't have to! What makes things possible for the disabled can make the same things more comfortable for ordinary users, too. I'd also like to save a particular rant for those who think that the mouse is the best interface for filling in forms, choosing items from lists or menus and generally doing anything which doesn't involve freeform positioning. A mouse is slow, uncomfortable, gives a higher risk of injury, is frustrating and fiddly to use and should almost never be the only expected interface device. Using a keyboard is not a last resort fallback, it's a primary input device. Fields should have accelerators, I should be able to move the focus around a window and its panes with convenience, the cursor keys should work (WHY don't cursor keys work in dialogue boxes? it's not like they're needed for something else), the position of the focus should be obvious, HTML and web browsers should have keyboard navigation options, software shouldn't keep stealing or moving my focus around or let it get stuck somewhere and developers should TEST from the point of view of a keyboard-focused user.
It isn't about the number of user interface objects on display - it's about the number of pixels used to display them. Ultimately, EVERYTHING should be resolution independent - none of this 'make the resolution and image quality lower just so I can make objects bigger' nonsense. Widgets, windows, spacing and icons should all be sized based on dialogue units, or some equivalent, not pixels. That way if I want everything at double size so I can read it without my contact lenses then that's what I can have.
As a person with sensitive eyes, I am constantly annoyed by applications setting backgrounds to white. White backgrounds hurt, people! And I mean actual physical pain here. So if you are writing some application, please use system colors, or at the very least let the user change the color scheme. In ten more years your eyes will get tired too, and trust me, you'll thank me.
As to blaming customers for being stupid about user interfaces on everything from chain saws to computers, there is something to be said about proper training and for purchasing from sales outlets that provide that training.
Of course, with computers, a big part of the problem is that most of the settings, options, whatever, aren't documented anywhere that the user is likely to discover. And when something is documented, it's usually in the developers' obscure jargon that doesn't share any keywords with the description a typical user would give.
I recently stumbled across a useful example: I'd been frustrated for years that, good as firefox is, it didn't seem to have a way to do something obvious that was in all the other browsers (of the 12 on my Mac, for example) had right there in the obvious menu: I couldn't get it to open a group of bookmarks in tabs in a new window. I made all sorts of guesses, googled for it, and asked on various forums. A few people said that it was possible, but gave no clues as to how. Then suddenly, a few months ago, I mentioned it in a comment here in /., and someone answered with the key combo. It's shift-click on the menu item, in the OSX edition. Now, I used shift-click in a number of other situations, but I guess I hadn't accidentally tried it on a bookmarks group-level item. Of all the zillions of possible multi-key possibilities in the zillions of widgets I see on the screen, there was no particular reason to guess that it would do that in this widget. There's no metaphorical interpretation of the various shift-clicks that I know; they all seem to do something totally idiosyncratic when they do anything at all.
I just repeated a search through FF's Preferences stuff, and I can definitely say there's no clue there. Or if there is, it's couched it terms that make no sense to me. The "Tabs" window has only six items, and clearly none of them applies to this task. If it's hidden somewhere else, I can't spot it.
This isn't particularly a criticism of FF, of course. It's just a single recent instance of a universal problem with computer UIs: The user usually has no way of discovering most of the capabilities, other than in discussions like this, on line or via email or in person or however. Or by randomly hitting keys and trying to make sense of the responses.
This is especially frustrating, because you know that most apps have one or a small number of tables that handle the mapping of input to functions. It should be easy to present this table to the user, and let them edit it. I've seen this done in a few apps. I've written such config windows myself for several apps. But even in the few cases where this is done, it's usually nowhere near complete, so users remain ignorant of most of the hidden capabilities.
What's even more frustrating is that, as a developer, I've worked on several jobs where I was explicitly ordered not to write such an unneeded tool. "Customers aren't asking for it; don't waste your (billable) time on it." In other cases, it was written and widely used by developers during testing, but was removed as unneeded "debug" code in the deliverable.
So now, instead of such "unneeded" tools, we're reading about a much more complex config approach that doesn't educate the user, but instead enables a minimal subset that limits the user to what they understood during the initial installation. Somehow I'm not sure this is an improvement. I think I'd prefer something that tells me what is implemented, and maybe lets me configure it a bit to match any physical (or mental ;-) limitations I may have.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.