Approach to Text User Interface Design?

16 Nov 2010 - 9:22pm
3 years ago
2 replies
4875 reads
interactive fiction
2010

This is really just a thought experiment that popped into my head.

Let's say you have a product that interacts with the user via a screen. The screen cannot display graphics, but can display text in a variety of ways (think ncurses, and the curses development kit, or otherwise just plain text). Now, a lot of interaction design goes beyond user interface. You have to get the user requirements, work out what information the user needs to be exposed to and at what time, and all sorts of other things.  The issue is, however, we live in primarily GUI world. MP3 players, for exampled were heavily text-interface-based, but now have largely moved to a graphical interface. There are always things like embedded computers, of course, or esoteric systems like Gopher, or command-line power users, but these are niche markets.

Assuming you had to develop a mainstream product that featured a text user interface, how would that impact your design process (if at all), and how would you change how you think about it, or otherwise compensate?

Comments

16 Nov 2010 - 10:01pm
David More
2010

The biggest problem with 'text user interfaces' was not the restriction of the screen to a text display, but the separation between the display and the input controls. Graphics alone, without a pointing device or touchscreen, aren't much more useful, usable or engaging than pure text -  remember the old 'multimedia' and games interfaces with numbered menus, etc?

Apart from the quality of the UI interface itself, a 'graphics-driven' approach allows for greater standardisation of controls and behaviours, and hence an easier learning curve. I think that's the main reason why old-style minimum text interfaces have largely died out.

So the critical factor affecting my design approach would be more influenced by the interactivity the device offers, not merely a limitation on what the screen could represent. Face it, most of what is presented on a graphics screen is text, anyway. The new generation of e-book readers (Kindle, etc) are constrained from adopting 'colour-and-movement' GUIs and some of the interfaces are quite subtle and (almost) elegant as a result. I'd hope to go the same way.

In terms of the visual polish of the UI that resulted, the typography is most critical, and then the quality of the text itself. 

Assuming that a quality text-based UI is possible, then I'd use the normal user-centred design approach. At least three iterations.

17 Nov 2010 - 11:05am
Chauncey Wilson
2007

This is a very good topic and relevant even to our GUI systems that use labels, text hint, text input, etc.   Issue to consider:   The density of the text on the screen, page, dialog, window.  There are issues of local density of text (and controls) where local density refers to the density of groups of related objects and general density which is the density of the entire work area.  You could have some areas of high local density, but lots of whitespace which would yield a low overall density.

  The universality of the terminology.  I don't know your audience, but many assumptions are made with regard to knowledge of the words used in the UI.  Acronyms for example, can be a real problem - we often assume that users are as familiar with acronyms as we are (for example, what does EL mean in field.]

  The alignment of text with controls.  This is a huge debate in GUI design and was a debate in character cells days.   The use of concatenated text in messages and on the screen.  Sentence-like layouts of text and fields might seem easier to read in English, but when translated, what reads well in English might be nonsensical in German.

  The scheme used to organized text menus.  There are some basic ways to organize including:  frequency, importance, alphabetical, natural (numbers) categorical, temporal/sequential, geographical, ....   The layout of the text items and controls.  What is the workflow through the text interface?   The legibility of the text to include the typeface, contrast with the background.   What is emphasized.  Bold versus all caps for emphasis for example.   The capitalization pattern of the target language.  There have been debates for decades about title versus sentence-style capitalization.  I could debate these, but I think that the key thing is to have a consistent, explicit style so translation is earier (the caps scheme will change, but if you are initially consistent that aides translation). 

  Use of colons versus not:  Still a debate, but in a heavy text interface, you would need to consider how to differentiate between label and output.   Clear rules for indicating what is a label, what is editable, what is non-editable, and what might be disabled.    If using commands, that you have a consistent set of rules for creating commands and explicit rules for shortcuts (typing EX rather tha EXIT would work).  The old DEC VAX language, for example, used reasonably consistent commands and shortcuts and that made it a relatively easy language to learn.

  You might want to get Deb Mayhew's 1993 book on Software User Interface Principle and Guidelines.  It has some good research-based rules related to the development of command languages, the use of abbreviations, and semantic congruence - a subtle, but important issue for example, conguence gets into pairings of words in commands:  Next and Previous are highly congruent, but Next and Last are not so congruent.  Mayhew has some better examples, but the idea is that some word pairings are stronger than others.

  As long as you have text items in a GUI, many of these are relevant.   Good question you asked.  Sometimes text issues get set aside when they still have impact.   Chauncey

On Tue, Nov 16, 2010 at 9:49 PM, interactive fiction <MiSon1960@writeme.com> wrote:

This is really just a thought experiment that popped into my head.

Let's say you have a product that interacts with the user via a screen. The screen cannot display graphics, but can display text in a variety of ways (think ncurses, and the curses development kit, or otherwise just plain text). Now, a lot of interaction design goes beyond user interface. You have to get the user requirements, work out what information the user needs to be exposed to and at what time, and all sorts of other things.  The issue is, however, we live in primarily GUI world. MP3 players, for exampled were heavily text-interface-based, but now have largely moved to a graphical interface. There are always things like embedded computers, of course, or esoteric systems like Gopher, or command-line power users, but these are niche markets.

Assuming you had to develop a mainstream product that featured a text user interface, how would that impact your design process (if at all), and how would you change how you think about it, or otherwise compensate?

(((Please leave all content below this
Syndicate content Get the feed