Linked by Julian Fietkau on Fri 11th Mar 2011 09:55 UTC
Graphics, User Interfaces Over the past few decades, the software that enables us to be productive with our computers has become increasingly sophisticated and complex. Today's UI designers are faced with the challenge of devising graphical user interfaces that are easy to grasp and use, yet still provide access to a wide range of features. Here are some ideas about the nature of GUI complexity, followed by a couple of thoughts on simplicity that might just surprise you.
Order by: Score:
What brings more money?
by Nth_Man on Fri 11th Mar 2011 10:51 UTC
Nth_Man
Member since:
2010-05-16

> I'd be glad to hear your thoughts on the topic.

> How do we deliver good usability [...]?

Mmm... what brings more money? :-)
http://wiki.idux.com/uploads/Main/Dilbert_marginal.gif

Edited 2011-03-11 11:09 UTC

Reply Score: 6

RE: What brings more money?
by dvhh on Sun 13th Mar 2011 14:32 UTC in reply to "What brings more money?"
dvhh Member since:
2006-03-20

Perfectly explain the problem,
How would you sell a new version of the product whenthe only "feature" compared to the old version is less features.

And How would you offer traning course and certifications if a 6 years kid old could use the product.

Reply Score: 2

RE[2]: What brings more money?
by Neolander on Sun 13th Mar 2011 16:09 UTC in reply to "RE: What brings more money?"
Neolander Member since:
2010-03-08

And How would you offer traning course and certifications if a 6 years kid old could use the product.

I wish we stopped invoking this 6 years old kid and his grandma when discussing usability.

It tends to give a vision of usability which results in overly guided interfaces, that themselves become an usability problem as soon as people start to master them and want to use them efficiently. Like those modern games which always begin with a lengthy, overly guided, and unskippable tutorial : it's fun the first time, but it makes you want to kill the development team the tenth time.

Should professional software used to design PCBs display on startup a description of what a conductor and an insulator is, along with a simple description of electrical currents ? No. Yet this would be a requirement if we want said software to be usable "even by children".

Here are some real-world examples now. Tons of professional guys love Photoshop as a tool for daily work, yet it has one of the most obscure and undiscoverable UIs I've ever seen. I loved to play with SolidWorks back when I used it in school, yet I wouldn't expect a 6-year-old to understand how it works. Software can be usable *and* have a steep learning curve, which permits the manufacturer to make money from it by selling training courses ;)

Edited 2011-03-13 16:24 UTC

Reply Score: 1

RE[3]: What brings more money?
by dvhh on Sun 13th Mar 2011 16:23 UTC in reply to "RE[2]: What brings more money?"
dvhh Member since:
2006-03-20

Well that's mostly the marketing buzz talking.

Reply Score: 2

RE[4]: What brings more money?
by Neolander on Sun 13th Mar 2011 16:29 UTC in reply to "RE[3]: What brings more money?"
Neolander Member since:
2010-03-08

Why ? I have nothing against interfaces which can be manipulated by young children if young children are a relevant part of the target audience. I'm just against the idea that every software, no matter its target audience, must be usable by young children in order to be labeled usable as a whole.

"Fisher price my first computer" as the paramount of usability... hmmm... No, thanks.

Edited 2011-03-13 16:43 UTC

Reply Score: 1

Good article
by sorpigal on Fri 11th Mar 2011 11:39 UTC
sorpigal
Member since:
2005-11-02

I like what I'm seeing so far and eagerly awaiting the follow-up(s). Hopefully I will be able to use them as citations when talking about why GNOME 2.x's approach to usability has sucked (a trend that sadly continues).

Reply Score: 4

Quantity vs. quality
by Torbjorn Vik Lunde on Fri 11th Mar 2011 12:14 UTC
Torbjorn Vik Lunde
Member since:
2009-09-04

Complexity often come in the form of more features. Now, the problem itself isn't having too many features, but focusing on “feature count” instead of the quality of each feature.

You can't both have very high quality, and very high quantity. You have to choose. (At least not in a short period of time)

Great article by the way. I'd love more articles about design and UI! They are by far my favorite here on OSnews.

Reply Score: 2

RE: Quantity vs. quality
by JulianFietkau on Fri 11th Mar 2011 15:14 UTC in reply to "Quantity vs. quality"
JulianFietkau Member since:
2005-07-07

I see where you're coming from and I think you're fundamentally quite right, but I don't really agree with the implication that there's a dichotomy between more features and better features.

Sure, in high-level manager-speak, developing more features and improving the usability both consume time and money, but that line of thought IMO neglects that both of them also have long-term consequences.

That said, if the two extremes are "many mediocre features" and "few high-quality features", how do you find a sweet spot in between? How do you prioritize? That's assuming you're active in this line of work. Sorry if you're not, then I've misread your comment. But I'm always curious how other people deal with these questions. ;)

Reply Score: 1

RE[2]: Quantity vs. quality
by Torbjorn Vik Lunde on Sun 13th Mar 2011 14:35 UTC in reply to "RE: Quantity vs. quality"
Torbjorn Vik Lunde Member since:
2009-09-04

I am a web designer. So I'm not really a proper UI designer, although one has to think about UI when designing simple content oriented sites.

It is obviously about balance, and there certainly are applications that are complex, yet have high quality in many of it’s features.

While I am not so extreme that I think that complexity is never appropriate I still tend to push for simplicity. There are some reasons for this:

• It is very easy to add features later on, but very hard to remove them once you’ve added them.

• Often one thinks that the needs are more complex than they are in reality. If you try it out you quickly find out whether you need the complexity.

• Often the complexity you need might be in another form than the one you thought. Again, when you actually try it out you know this better.

• There are often many people involved in a project, and often many people striving (indirectly and unknowingly, through wanting features) for complexity. Something becoming too simple is rarely a

• More features usually makes it much more difficult to create an easy to use UI.

The most important thing to think about is not just avoid complexity, but that features and complexity come at a price. Is a feature worth the complexity it brings?

Reply Score: 1

Please write the followup(s)
by seanpk on Fri 11th Mar 2011 13:07 UTC
seanpk
Member since:
2009-11-17

You've presented the information in a very accessible manner. It is funny how many articles about improving UI are so difficult to use themselves.

Reply Score: 7

Nice
by iskren on Fri 11th Mar 2011 13:42 UTC
iskren
Member since:
2005-07-06

Nice article. Waiting for the followups.

Edited 2011-03-11 13:42 UTC

Reply Score: 1

Nice article
by ephracis on Fri 11th Mar 2011 14:04 UTC
ephracis
Member since:
2007-09-23

I like the article. I have a clear goal in my current software project that aims at creating a really awesome interface and a lot of the focus is on usability and making the interface "get out of your way" so you can focus on the actual content and actions.

When you create interfaces you have to deal with stuff like spatial memory and "recognize vs. remember". At the same time you need features because people like to do stuff in different ways.

So the pure aim is to create all necessary features and present them in the absolutely best way possible.

Not to tout my own horn but I think that my software is on the right track. I try to mimic interfaces that people are used to and I have tools to let people use the same keyboard shortcuts as the "competitors", aiming at reducing the stuff they have to relearn.

In the projects blog I actually wrote a similar article on what I believe is the best approach to designing a good interface:
http://blog.stoffiplayer.com/2010/07/designing-application-interact...

I look forward to your follow up.

Reply Score: 2

RE: Nice article
by ephracis on Fri 11th Mar 2011 14:38 UTC in reply to "Nice article"
ephracis Member since:
2007-09-23

I wrote a post on the blog about your article.

http://blog.stoffiplayer.com/2011/03/dealing-with-complexity-in-ui-...

Reply Score: 3

RE[2]: Nice article
by JulianFietkau on Fri 11th Mar 2011 14:56 UTC in reply to "RE: Nice article"
JulianFietkau Member since:
2005-07-07

I am quite flattered and also very thankful for your input. Both articles you've linked are very interesting to read. What especially stood out to me were your ideas on easing migrating users into your application, you have some intriguing ideas there and, as far as I can tell, you do seem to be on the right track with your software.

Reply Score: 2

RE[3]: Nice article
by ephracis on Fri 11th Mar 2011 15:02 UTC in reply to "RE[2]: Nice article"
ephracis Member since:
2007-09-23

Thank you very much. I think that as computer have become more and more common there's a stronger focus on the actual interface between the technology and the human. This is an area that really needs a lot of attention and it is very interesting to see that a lot of people actually agree on many points.

However, there's still software produced today that I see which have absolutely horrific interfaces. There's always an excuse, for example "it's only internal software, we don't need to care that much". But I believe that if you keep your focus on usability from the start it does not have to mean extra work for the developer, but it will mean extra productivity for the user in the end.

May I ask you which areas or concepts you were planning on talking about in the next article? I am very intrigued, I can't wait for it. ;)

Reply Score: 2

RE[4]: Nice article
by JulianFietkau on Fri 11th Mar 2011 15:04 UTC in reply to "RE[3]: Nice article"
JulianFietkau Member since:
2005-07-07

Sure, just see my reply at the bottom. ;)

Reply Score: 1

Waiting
by imaginant on Fri 11th Mar 2011 14:59 UTC
imaginant
Member since:
2010-02-26

Hey, I am like all the rest: really looking forward to the next part. Thanks for making this so interesting.

Reply Score: 1

JulianFietkau
Member since:
2005-07-07

Please don't hesitate to let me know what you'd like to read about in a followup article. Off the top of my head, here are a few aspects about which I could write something at least vaguely competent:

- What methods are there to help software developers create usable interfaces? (That is, before user tests and all that, how do you come up with a good interface in the first place?)
- What, if not its simplicity, helped Apple's iPod to become the big success that it is?
- How did Microsoft come up with the Ribbon and what can other UX people learn from it?

To clarify, this isn't a vote for the most popular topic, I'm just trying to gauge if there's anything particular that's really interesting to you.

Reply Score: 2

ephracis Member since:
2007-09-23

I think that error messages and text in all is an interesting part. Communication!

Error messages are of course lovely, since there's tons of examples of error messages that does not help the user at all. A good application should be able to handle problems in an elegant way.

Too much text is also a big problem, since users won't read it. So here's the thing: what is the best way to communicate with the user? The balance between images and text as well as using the users memory (familiarity).

Another interesting but somewhat subtle aspect of communication is the tone of it. Do you want to come off as mechanical and corporate or do you want to sound like what a friend would have sounded like if he was standing beside him and explaining the application?

The message "Your request contained an illegal action" is bad because it puts blame on the user (the word illegal is very loaded).

Anyway, there's a lot of interesting stuff to talk about when it comes to usability design. The Firefox journey is also interesting since it contains the original Mozilla browser, the whole Mozilla Suit, the creation of Firefox which became Firefox 3 and now Firefox 4 is present a new design yet again. It has been up and down several times. Which could be an interesting analysis.

Reply Score: 2

JulianFietkau Member since:
2005-07-07

I've added error messages to my imaginary list. I suppose I could write at least half an article on that topic alone. Have you read Jef Raskin's The Humane Interface, by chance? I find some of his opinions a little eccentric, but he makes several very good points about error messages that I'll probably cite if/when I write an article about the topic.

And even though I personally use Firefox, I probably don't have enough experience with the history to write about it, or it would involve a ton of research beforehand. So don't count on me writing about that. ;)

Reply Score: 1

spiderman Member since:
2008-10-23

That was a good article. Can't wait to read the followup.
I think accessibility is an interesting subject in UI design. Sometimes a UI design is simple for 90% of the people but extremely complicated for the rest. How to design a good UI that is simple and accessible for more people? Good color choices, separating content from presentation, using accessibility standards and methods, etc...

Reply Score: 2

JulianFietkau Member since:
2005-07-07

Unfortunately I don't have very much experience in that area, so apart from the obvious things regarding color and all that you've already mentioned, I don't think I'd be qualified.

If we're not strictly talking about software, then I encourage you to take a look at Design Meets Disability by Graham Pullin. From what I've heard and read about it, it's apparently an excellent book for understanding product design with people with disabilities in mind.

Reply Score: 1

wannabe geek Member since:
2006-09-27

I'd like you to comment on the topic of why there's a perceived dichotomy between the power and conceptual depth of the UI and its usability and coolness, and what could be done about it. I mean, why geeks love ugly UIs like the command-line and keyboard shortcuts, why most GUIs are so difficult to script and combine, why the mouse is associated with self-explanatory UIs and the keyboard evokes dauntingly obscure incantations; what are the key issues, is it interactivity vs batch processing, verbal representation vs graphical representation.. and what is so special about verbal representations in programming? Is it a good idea to make communication more graphical and graphics more "verbal"? Should our documents all look like bland defaults (boring) or should they be as unique as physical documents (confusing). Why are defaults so bland, and what if you want a specific bland look for your document which happens to be the default look? (what's the best way to deal with abstraction and escaping).

I have some vague ideas on what a dream UI would be like (maybe something between Croquet and Tangible Functional Programming), but I'm sure your views are much more interesting.

Reply Score: 2

JulianFietkau Member since:
2005-07-07

Some of those are pretty fundamental questions and I don't know if I would be able to answer them with a featured article, but I'll just try it right here:

With Don Norman's definition of complexity in mind, I'd say that the mouse has a rather low intrinsic complexity compared to the keyboard. It allows us to move something (a cursor, most of the time) around on the 2D plane, and to "click" to induce an action, and that's pretty much it. In contrast, the keyboard offers dozens of discrete possibilities for input, hundreds if you count every possible key combination using Ctrl, Shift or Alt.

Assuming that geeks are people who use their computers often, it seems obvious that they'd be looking for ways to speed up repetitive tasks. The keyboard is a great way to speed things up, because you have the aforementioned hundreds of ways to instantly tell the computer to do something. Every geek realizes at some point in their life that it is much faster to press Ctrl+X than to navigate the mouse to "Edit", click, navigate down to "Cut" and click again.

If it's faster, why doesn't everyone do it this way? Because keyboard combinations, just like the commands in any CLI, need to be memorized to be used, and that's not a priority for non-geeks. They use the mouse because that way the feature is discoverable. The mouse has, by virtue of its limitied possibilities for interaction, broken down the complex task of hitting exactly the right two keys on your keaboard to a sequence of simpler steps: moving the mouse, clicking, and then moving and clicking some more. What's noteworthy about this, is that precisely because it consists of several steps and takes longer to do, the user can get feedback along the way (visual or otherwise) and thus can check if the procedure is going as planned. For people who don't use their computers as often or don't feel as confident using them, the speed loss is an acceptable tradeoff.

Does that answer some of your questions? ;) I have a feeling you've had quite a few own thoughts on this, and I also think you're overestimating me. ;)

Reply Score: 2

wannabe geek Member since:
2006-09-27

Thanks for your quick reply. It's a great starting point. I just wanted to point out some paradoxes in those common observations, and how I think they might be solved, and how it could help to get some perspective in UI design.

Regarding the mouse vs the keyboard, the first surprising thing is that the mouse is actually a much more powerful piece of IO hardware, in terms of bits per second. Its true power is shown in graphical applications, such as the ones for drawing and modelling. Notice that, in principle, you could use the mouse for hitting keys in a virtual keyboard, therefore the difference is not in the mouse per se, it's in the hierarchical menu interface; that's why Ncurses UIs are about as newbie-friendly as GUIs once you learn the basics. They are also about as slow. Then we have, hierarchical menus are discoverable and easy on your memory, but slower. So, many graphical applications add keyboard shortcuts, and they add the shortcuts in their menu entries, which is great. But why should keyboard shortcuts require so much memorization? They should give you the available options as you go, just like menus do. I've seen some of this in Emacs and ION3, but maybe there's still some room for improvement. Emacs lets you cancel the whole command (C-g), but I haven't seen a prominent option to withdraw one key stroke and pick another one in a long key chord, as you would go back and forth in a menu. I guess you can do it with recursive edition of the minibuffer. Also, not just short descriptions, but longer explanations should be available as you type.

My take is that the main advantage of the keyboard over the mouse is the multitouch interaction. The human nervous system is better adapted to position ten points with low precision than one point with extreme precision, and thus the superior bit rate of the mouse is not helpful in most cases. That's also one reason why multitouch screens are so interesting, because they combine the best features of keyboard and mouse.

By the way, the CLI becomes much less daunting once you learn some little tricks such as the up-arrow, tab completion, man, --help, apropos and the like. It also is great when you ask in forum how to do something, and then you can just copy-paste the answer. You can't do that with a GUI! Why not? I think you should be able to. Just like your past CLI commands are available to copy and paste, so should be your past chosen menu options.Also, GUI scripting should be as easy as CLI scripting.

Thanks for your appreciation. Yes, I have a few ideas, but they sometimes contradict each other and the overall picture is still a bit messy ;)

Reply Score: 2

shawnhcorey
Member since:
2009-11-05

"How do we deliver good usability without compromising feature breadth? Should we be striving for simplicity, as it is so often demanded?"

When Larry Wall designed the Perl language, his guiding principle was: make simple things simple, difficult ones, possible. This can be applied to any UI. The point is that commonly-used features should be easy to invoke and the not so common, possible, though it may take some effort.

As for error messages, too many programmers use the word illegal when they mean invalid. Illegal means it's against the law, invalid means it doesn't make sense.

Reply Score: 2

Bill Shooter of Bul Member since:
2006-07-14

That really is my mantra "easy things easy, difficult things possible". However, there is always an argument as to what "easy" means.

"Easy" for Larry Wall meant easy for some one who has mastered the language and will be using it frequently.

That is why perl has a humorous reputation as being a write only language.

IMHO, that has to be balanced with a the other sense of "Easy": Easy for a novice to quickly understand.

The cockpit of a helicopter can be Perl easy, as it takes a lots of training for a pilot to operate a plane safely. No one outside of action movies is going to have to jump into the cockpit and learn how to use it in 10 seconds.

A casual website, needs to be Easy for new users to get. If you want users.

Reply Score: 2

Delgarde Member since:
2008-08-19

When Larry Wall designed the Perl language, his guiding principle was: make simple things simple, difficult ones, possible. This can be applied to any UI. The point is that commonly-used features should be easy to invoke and the not so common, possible, though it may take some effort.


The bit missing from that principle (and conspicuously also absent from Perl) is that doing things which are inadvisable should be in the second category, not the first - possible, but not by accident.

Reply Score: 2

Nicely Written
by microFawad on Fri 11th Mar 2011 18:56 UTC
microFawad
Member since:
2005-12-09

Very nice article about UI design. Concepts like complexity, complicated, simple are very clearly explained. Thanks a lot ;)

Reply Score: 1

Good to see
by Moredhas on Fri 11th Mar 2011 20:44 UTC
Moredhas
Member since:
2008-04-10

I've been saying for years now, selling phones, that I'm a firm believer in the difference between complex and complicated. Good to see I'm not the only one who sees this. As an examole, I'd call any recent Nokia attempt at a smart phone complicated (it's so hard to do common things, people think they're easy because, perversely, it's too much effort do do more than call or text). I would, however, consider Android to be complex. iPhones, to be sure, are simpler to look at than Android devices, but far more complicated to use. I've made plenty an iOS to Android conversion in my job, and those customers never look back.

Reply Score: 2

Joel & Google Docs.
by Bill Shooter of Bul on Fri 11th Mar 2011 20:55 UTC
Bill Shooter of Bul
Member since:
2006-07-14

Just a couple notes in general on the article:

Google docs seems to be simpler to use, not more complex when looking at the newer interface. They did not follow the MS Office treadmill of adding more and more tool bars. They've added complex functionality while hiding it form users that don't need it and making the simple things easier to use.


Joel on software. *shakes head* Why do people quote him as if he's the final answer on software design and development? Its not like you're quoting Einstein on his theory of relativity : a remarkable work that has withstood rigorous testing. He's just a guy that once worked on excel and later started his own software company that makes software very few people use. Oh yeah and he started a blog and wrote a book on software design. He has some good ideas, some bad ideas. Just because an idea came from him, doesn't make it an awesome "end of discussion" case resting point.

Reply Score: 2

RE: Joel & Google Docs.
by JulianFietkau on Fri 11th Mar 2011 21:22 UTC in reply to "Joel & Google Docs. "
JulianFietkau Member since:
2005-07-07

Ah, here we go, thank you. ;) I'd already started to feel light-headed from all the praise...

Re: Google Docs, this is probably a good point in time to admit that I've never used it very seriously and haven't created any real documents with it. So if you feel that I'm wrong, that's likely the reason, and in that case feel free to dismiss my opinion. Still, I'd like to clarify that I don't think Google Docs is necessarily more complicated or difficult to use today than it was three or four years ago, just that it is more complex because it has many more features than back then, today you can do much more with it. Hiding advanced features well enough is a viable option for coping with increasing functional complexity.

As for Joel Spolsky, I didn't intend to frame him as some sort of ultimate authority. He simply wrote something that fit very well into the article, and (I am taking him at face value here) he has several years of experience doing what he does at least semi-successfully. The quote in the article was not intended as religious dogma, but as an illustration of my point. I didn't make my intentions clear enough in that regard, sorry for that.

Reply Score: 1

RE[2]: Joel & Google Docs.
by Bill Shooter of Bul on Fri 11th Mar 2011 22:07 UTC in reply to "RE: Joel & Google Docs. "
Bill Shooter of Bul Member since:
2006-07-14

Thanks for the clarification. I think I was a bit off in the previous post as well.

There really is a difference between complexion and complication. A good UI should be complex but not complicated. Microsoft ( prior to the ribbon interface) would have defended the vast number of tool bars as necessary given the complexity of the features available. The genius of the ribbon was not that they made their software less complex, but made it less complicated. That's what Google did to docs as well.

At one point in my life I was teaching underprivileged kids basic computer skills on win 98 machines, using MS office 2000. The kids were really interested in clicking everything in sight without much thought as they were very curious. The result was the interface for Word often became indescribably messed up.

Frequent senarios:

1) Every tool bar imaginable would be on the screen leaving an inch for actual editing.

2) Default Template changed to a document they had written

3) No tool bar visible, combined with the inability ( for me anyways) to figure out how to put any of them back.

4) Prompt on start up to insert a disk to complete installing some half installed feature.

The point is the UI allowed people to do stupid things that no one really would ever want to do. while making it difficutl to undo any of it. That was stupid. Don't do that in your UI's. The ribbon interface, I'd imagine would have prevented some of those problems.


I know some people love Joel. I don't know why. I understand why some people have an inordinate amount of love and respect for Jobs, Ives, Raskin, the developers of Amiga, BeOs, Linux, BSD and perl. They made really good software and designed it pretty darn good, millions use their products every day, because they *want* to. Joel was part of a team that ripped off Lotus 1-2-3 and visicalc's interface.

Reply Score: 2

Comment by Mystilleef
by Mystilleef on Sat 12th Mar 2011 00:06 UTC
Mystilleef
Member since:
2005-06-29

Your article is insightful and well written. Good job.

I think when people refer to "simplicity" they are really talking about how easy an object is to use and figure out.

The "too-many-features" aspect is really a software engineering problem and not necessarily a usability problem.

For example, an application can have lots of features where each feature is well designed, easy to use and figure out. Usability wouldn't be a problem in such an application. The problem most likely becomes the engineering cost of those features or of adding more features.

Every feature costs something. A new feature doesn't come for free. In particular, the time it takes to research and design a feature "properly" so that it's easy to use and figure out is significant. The cost of implementing the feature is not trivial either.

That's why there's a growing trend for simple and minimal software applications (e.g apps on your mobile devices). It's just cheaper and practical from a software engineering perspective. The bonus may, or may not, be that the application has high usability.

Just from my experience, applications that are focused in their responsibilities are more usable than those that have too many auxiliary responsibilities. The trend to keep things simple is wise and practical both from a software engineering and interface design perspective.

Edited 2011-03-12 00:11 UTC

Reply Score: 2

Recommendations
by puelocesar on Sat 12th Mar 2011 02:22 UTC
puelocesar
Member since:
2008-10-30

Congrats for the introductory article, I greatly applaude your attitude towards educating developers in usability issues. That's really one thing that every dev should study and apply on their daily work.

I also want to recommend some great articles for beginners on UX:

Great introductory article on Interaction Design:
http://www.uxbooth.com/blog/complete-beginners-guide-to-interaction...

Illustrated article talking about this complexity subject. This one is for UI designers, but developers can also learn a thing or two with it:
http://www.smashingmagazine.com/2009/10/07/minimizing-complexity-in...

Reply Score: 2

.
by Icaria on Sat 12th Mar 2011 05:53 UTC
Icaria
Member since:
2010-06-19

In fact, if anyone's interested, I will be writing a follow-up article describing and showcasing several such techniques. I'd be glad to hear your thoughts on the topic.

My initial thought would be why you didn't wait and post it all as one article. This article defines it's terms relatively well but that's all it does.

I'd also be curious to see where you place consistency vs. novelty in the list of qualities and priorities. It would certainly be pertinent to the 'muddle through and post hoc rationalize' tunnel-vision of most users, which you explicitly brought up.

Reply Score: 1

RE: .
by JulianFietkau on Sat 12th Mar 2011 14:54 UTC in reply to "."
JulianFietkau Member since:
2005-07-07

Good point. I actually didn't want to make it any longer than it already is because I tried to hopefully entice a few readers who wouldn't otherwise read essays about usability. People have mentioned above that they deem the article rather accessible and approachable. I suspect being concise and limiting its scope was a big part of that.

Also, I wasn't sure if OSNews readers cared about this topic much at all, and I wanted to test the waters, so to speak. ;)

Reply Score: 1

asdf
by another_sam on Sat 12th Mar 2011 15:38 UTC
another_sam
Member since:
2009-08-19

i like the number 7, the logarithm, and spheres.

the number 7 because it is the maximum number of items I can stare at without panicking.

the logarithm because N menu items with N menu-subitems each, M times, will deliver you N^M options at just M clicks. eg: 49 options at just 2 clicks.

spheres because they balance the effort equally across all its surface just as UIs should balance the effort of the user across the time: frequent actions should consume best interaction resources (items on primary screens, shorter shortcuts on keyboard, ...), infrequent actions should not.

Edited 2011-03-12 15:39 UTC

Reply Score: 1

Examples of applications
by Fergy on Sat 12th Mar 2011 21:25 UTC
Fergy
Member since:
2006-04-10

It would be nice if you could analyze a few popular programs. With screenshots and point out what is good and bad about them.

Reply Score: 2

time to dump the keyboard
by unclefester on Sun 13th Mar 2011 06:10 UTC
unclefester
Member since:
2007-01-13

The keyboard should also be consigned to history. It is an anachronistic carry-over from the mechanical era.

For phones and notebooks a far better solution is a simple chorded keypad.

http://en.wikipedia.org/wiki/Chorded_keyboard

Reply Score: 2

RE: time to dump the keyboard
by Neolander on Sun 13th Mar 2011 14:02 UTC in reply to "time to dump the keyboard"
Neolander Member since:
2010-03-08

Typing should be done with an EEG. Just by wearing a headset and mentally spelling the words ;)

Reply Score: 1

RE[2]: time to dump the keyboard
by unclefester on Sun 13th Mar 2011 23:12 UTC in reply to "RE: time to dump the keyboard"
unclefester Member since:
2007-01-13

We have been using chorded input systems very successfully for thousands of years in musical instruments. There is an initially steep learning curve but the end result is far greater efficiency.

Conventional keyboards only exist because typewriters were purely mechanical devices that directly connected the key to the typebar. Keyboards (particularly QWERTY types) are incredibly bulky, cumbersome and inefficient.

A full QWERTY keyboard on a phone or tablet is absolutely farcical when only 5 standardised buttons are needed to represent all functions on a conventional keyboard. A far better solution is to place the buttons on the perimeter of the phone.

Reply Score: 2

RE[3]: time to dump the keyboard
by Neolander on Mon 14th Mar 2011 09:58 UTC in reply to "RE[2]: time to dump the keyboard"
Neolander Member since:
2010-03-08

A full QWERTY keyboard on a phone or tablet is absolutely farcical when only 5 standardised buttons are needed to represent all functions on a conventional keyboard. A far better solution is to place the buttons on the perimeter of the phone.

5 buttons only mean 2^5 = 32 possible combinations, if I'm not misunderstood (unless you want to bring back the multiple tap hell). So you'd not even get 26 letters and 10 digits, let alone other very important things like the space bar, the shift key, punctuation, parentheses and other brackets, diacritical marks for languages which have them, and other signs used rather frequently like +-*/=$@ (and, for programmers, &|^#).

I think that like on musical instruments, we'd need to have a bit more buttons, and to move the fingers between them. AFAIK, that's how existing one-handed chorded keyboard implementations work.

Edited 2011-03-14 10:06 UTC

Reply Score: 1

RE[4]: time to dump the keyboard
by zlynx on Mon 14th Mar 2011 23:52 UTC in reply to "RE[3]: time to dump the keyboard"
zlynx Member since:
2005-07-20

Plus, you cannot use five fingers on a one-handed input device. You can only use four.

Something needs to provide a force for your four fingers to press against and that something is the thumb. That means the thumb can't be used for input.

So that leaves you with only 16 chord combinations.

Reply Score: 2

unclefester Member since:
2007-01-13

The palm of your hand provides something to counteract the forces of your fingers. The forces involved are tiny if you use capacitative switches.

You can also use multi-function buttons which have been on digital watches since the 1970s

Reply Score: 2

unclefester Member since:
2007-01-13

You would simply use a 4-position thumb slider or dual pressure switches.

An electronic keyboard functions like a piano for purely historical reasons. There is no real reason why an electronic keyboard couldn't have single-key chords or the ability of a single key to play several different notes using either a rocker or pressure switch.

Reply Score: 2

RE[2]: time to dump the keyboard
by unclefester on Mon 14th Mar 2011 03:41 UTC in reply to "RE: time to dump the keyboard"
unclefester Member since:
2007-01-13

EEG control would be about the least efficient mechanism imaginable. Even very simple actions such as turning a switch on or off via EEG require a considerable amount of concentration.

Edited 2011-03-14 03:42 UTC

Reply Score: 2

RE[3]: time to dump the keyboard
by Neolander on Mon 14th Mar 2011 09:47 UTC in reply to "RE[2]: time to dump the keyboard"
Neolander Member since:
2010-03-08

Currently, yes, but who knows what we'll be able to do in the future, when we have more precise hardware and better analysis algorithms at a lower price.

I've also seen some attempts to combine detection of conscious thoughts with emotion detection (which is apparently simpler) and facial expression analysis. Such "hybrid" mechanisms based on a wider data set could also be a promising path.

Edited 2011-03-14 09:47 UTC

Reply Score: 1

unclefester Member since:
2007-01-13

Muscular movements are not controlled directly by the motor cortex of they brain. They are mediated through the central nervous system which provides a constant feedback via multiple sensory systems including visual, auditory, heat/cold, pressure and proprioception (spatial perception).

If you try and directly control a mechanism via EEG you don't have this constant autonomic feedback. This means vastly greater level of conscious control is necessary - imagine having to always deliberately think about how to breathe or swallow. In effect you permanently remain at the "baby steps" stage

Reply Score: 2

RE[5]: time to dump the keyboard
by Neolander on Tue 15th Mar 2011 16:45 UTC in reply to "RE[4]: time to dump the keyboard"
Neolander Member since:
2010-03-08

Indeed, this makes a lot of sense to me. The lack of feedback is the reason why I dislike touchscreens so much (although it sounds like I'll have to get used to them anyway).

Reply Score: 1