| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

ShapingUserInterfaceBarriers

Page history last edited by PBworks 13 years, 5 months ago

Shaping User Interface Barriers

 

This might be better as one or more blog posts, but feels too unrefined as yet, so instead I'm capturing it as one of several RandomNotes here on this wiki, expecting that with some iteration it may eventually be worthy of blogging.

 

In general when you design a user interface, you want to lower the barrier to entry as low as possible so that the most users are able to use it, and are able to use it as quickly as possible, and as often/frequently as possible.

 

When a user interface has a singular goal, or is specific to a particular task, the design goal of "just make it easier" is fairly straightforward and sufficient to accomplish the task.

 

However, often user interfaces are (or can be) used for various different goals, and various different tasks. In such multigoal cases, which aspects of the user interface you make easy (vs. which you leave, perhaps a bit harder) affects which goals users are more likely to accomplish. How you shape the barriers in your user interface directly determines how your users will use it and what they will more likely spend their time doing.

 

 

2007-04-14 Example: wiki editors plain text vs. WYSIWYG

 

There is a misconception that:

 

  • WYSIWYG = easier to use
  • WYSIWYG = lower barrier to entry

 

and thus is preferred.

 

Certainly if those two assertions were absolutely true statements, I would be compelled to completely agree that WYSIWYG is preferred.

 

However, they are overgeneralizations, and dangerously inaccurate at that.

 

This is a question of substance vs. style. Of semantics vs. presentation.

 

User interfaces, by their very biases of what they make easy vs. what they make hard, shape user behavior and therefore the form of what is generated by the users. You don't actually want to lower the barrier for *everything*, for example, you don't want to lower the barrier to entry for people to spend all their time making something look like myspace.

 

This is about priorities, not about ease of use.

 

IMHO, the priority is, getting people in general to add and edit *content* on the wiki, and for the most part that's text and links and anything else "meaningful", rather than people in general wasting a lot of time tweaking fonts, colors, boldness, layout etc. etc.

 

That leads to:

 

low barriers to: entering text and links.

 

high barriers to: styling and presentation.

 

The plain/classic wiki editor presents just this combination and is thus preferred, whereas the wysiwyg editor, as we know, makes styling and presentation easy, in some cases at the *cost* of semantic content (e.g. microformats), but worse than that, by making editing presentation easy, it causes people to spend more time on presentation (people tend to irrationally or at least excessively obsess about looks - insert psychology reference here), time that they would (or at least might) spend otherwise adding/editing content.

 

Finally, compare with two other interfaces: email and instant messaging. In both, people can and do write plain text + links quite effectively, without the need for WYSIWYG style editing, and are thus quite prolific with both.

 

Let's encourage folks to write and edit wiki pages as they would their email/IM, and hopefully instead of email and IM (see CommunicationProtocols).

 

 

 

Return to the FrontPage.

Comments (0)

You don't have permission to comment on this page.