User Interface Design

Chapter 2 The Form

2.1 Interface Paradigms
Technology Interface Paradigm

● Implementation-centric
● Based on understanding how things actually work.
● It is a difficult proposition.
● It is simple and incredibly widespread in the computer industry.
● The user must understand how the software works in implementation level to
use it successfully.
● UID is based exclusively on the implementation model.
Metaphoric Interface Paradigm
● Based on intuiting how things work.
● A risky method.
● It lets users apply what they know from some familiar part of life in
understanding the interface.
● Relies on intuitive connections in which there is no need to understand the
mechanics of the software.
● Intuition gives quick and ready insight.
● Intuition also gives immediate cognition.
● People understand some interfaces while they don’t understand some.
Problems with metaphoric interface paradigm
● Don’t scale well
● Too constraining
● Conflict with design principles
● Makes true functionality invisible
● Overly literal translations
● Can limit the designer’s imagination
Idiomatic Interface Paradigms
● Based on learning how to accomplish things.
● A natural human process.
● Solves the problem of both Technology and Metaphoric interface paradigms.
● Based on the way we learn and use idioms or figures of speech.
● Idiomatic expressions are easily understood but not in the same way as
metaphors are.
● We understand idiom because we have learned it and because it is distinctive
not because we understand it or because it makes subliminal (affecting
subconscious mind) connections in our mind.
Idiomatic Interface Paradigms (Contd.)
● Human mind is outstanding for learning & remembering idioms very easily
without relying on comparisons to known situations or an understanding of
how they work.
● This is required because many idioms don’t have any metaphoric meaning at
all.
● Most of the elements of a GUI like windows, caption bars, close boxes,
screen-slitters, dropdowns are idioms.
● Mouse is idiomatic.
● All idioms must be learned. Good idioms only need to be learned once.
Branding
● Marketing professionals take some symbol/action and fill them with meaning.
● Synthesizing idioms is the essence of product branding.
● Company takes product/company name and fill it with desired meaning.
● Idioms are visual too. E.g. Five interlocking rings of olympics, Microsoft’s
flying window, The three diamonds of Mitshubishi, The golden arches of
McDonalds, etc.
Affordances
● In the book “The Psychology of Everyday things”, Donald Norman defined
affordance as perceived & actual properties of the thing, primarily those
fundamental properties that determine just how the thing could possibly be used.
● If we look at something and understand how to use it - we comprehend (fully
understand) its affordances and we must be using some method for making the
mental connection.
● In the above definition, if we omit “& actual”, affordance become a purely cognitive
term, reffering to what we think the object can do rather than what it can actually
do.
Affordances (Contd.)
● If there is a push button near door, it is a doorbell. This is learned from
socialization.
● Its affordances are 100% doorbell.
● If we push it & it causes a trapdoor to open beneath & we fall, it wasn’t a
doorbell.
● But this doesn’t change its affordances at once.
● If we see a push button, we recognize it’s a finger-pushable object despite of
its location or attachment to different object.
● When things are clearly shaped to fit our hands or feet, we recognize that
they are directly manipulable & we need no written instructions.
2.2 Child Forms
A program has main window and subordinate windows.

Subordinate windows include documents, dialog boxes, etc.

We shouldn’t guess, instead carefully choose which window to use in order to

determine its look & feel.

Understand why we make our choices.

Unnecessary Rooms
If a program is analogous to house (Main Window), windows can be compared
with the separate rooms (document window / dialog box).

No windows should be added unless they have a special purpose that can’t be
solved by existing windows.

A dialog box is another room, so there must be a good reason to go there.

Necessary Rooms
For function that is out of the normal sequence of events for a particular program,
special place must be provided for it.

For example: Database delete function

● It is not a normal activity.

● Admin privileges & features required.
● Features not part of normal operation.

So, it is entirely appropriate for the program to navigate into a separate room - a
window - to handle that function.
Windows Pollution
Some designers take the approach that each dialog box should embody
(represent) a single function. This is called windows pollution.

Achieving user goals include executing a series of functions.

If there is a single dialog box for each function, things can quickly get visually
crowded & navigationally confusing.

For example: In a mailbox program, if there are separate windows for inbox, sent,
drafts, outbox, etc., it only increased the number of windows required to list each
of them & perform each of the functions of reading email.
Windows Pollution (Contd.)
For such problem, a much better solution would be to create a single “mailbox”,
with tools and controls strategically positioned along the top row ( a toolbar would
be enough for managing searches).

Intermediate results of the search could be shown in the window along with the
final message itself.

One goal - finding & reading a message - should be implemented as one dialog
box.
Windows Pollution (Contd.)
There is no way to show connection between lot of windows, so don’t create lot of
windows.

Modal dialogs, however, always get us back immediately to the point of departure,
so they can be used.

If a program has a number of goals, divide the program into several ones, each
one true to its own goal.

A program shouldn’t have more than two or more three goals which means it
shouldn’t have more than two or three windows.
2.3 File System
A file system is used to control how data is stored and retrieved.

How storage and files work while running a program?

● Program is stored in the disk storage.
● When it is executed, it is loaded into the main-memory.
● File is read from the disk storage and loaded to main-memory.
● After making some changes, the changes are written back from main-memory to the
disk storage.

Storage can be local or in a network.

File operations: Open, Read, Write & Close.

Aspects of File System
● Space Management
● Filenames
● Directories
● Metadata
○ Different information related to the file is stored as metadata of the files.
○ For example: An image can have metadata like Location, Camera model, etc.

● Permissions
○ Read
○ Write
○ Execute
Unified File Model
How to treat documents in our software?
● There are two copies of documents that are opened in a software.
○ One copy is stored on the disk
○ Another copy is stored on memory.

● Instead of showing these two different instances of a document, a single

instance of document must be made visible to the user.

● This is called unified file model.

Saving a File
● Each computer user must learn how to “save”.
● For this, write changes from in-memory copy to on-disk copy of the document.
● We remove all user-interface recognition of two copies, so this save function
disappears from the main stream interface.
● It is still a necessary function.
● The program will automatically save the document.
● When to save automatically?
○ At least when user tries to close the document.
○ Ask for confirmation with “save changes” dialog box.
Saving a File (Contd.)
What is disadvantage?
● For cases like:
○ Computers softwares can crash
○ Power fail
○ Other unpredictable, catastrophic (disastrous) events
● In such cases, hours of work can still be lost.
● So, program must save documents at regular intervals during the user
session.
● But saving file after each keystroke is costly.
● File saving algorithm must pay attention to the user instead of the clock.
Saving a File (Contd.)
● User centric file saving algorithm removes conflict between user action and
time interval to save.

● Two approaches enough for saving files.

○ Automatic saving every minutes
○ Automatic saving while closing

● So, save function must be removed.

● “Save changes” dialog box must also be removed.

Closing a File
● There is no inherent connection between closing and saving in unified model
because there is no concept of saving.
● Closing is the time and place for abandoning unwanted changes.
● The proper time to reject changes is when the changes are made.
● UNDO is the proper facility for that.
● When some changes are made and tried to close the document, “Save
changes” dialog box is displayed. “Yes” in save changes dialog box presents
with “save as” dialog box.
Closing a File (Contd.)
● Concept of unified file model doesn’t recognize the concept of manual saving.
● It is neither recognized by a typical user.
● The name of the dialog box doesn’t make much sense.
● The dialog box functionally offers
○ Name the file
○ Choose directory to store in

● Both of these functions demand knowledge of file systems.

○ File naming conventions
○ Understand directory tree
Closing a File (Contd.)
● Continuing the “save changes” action:
○ “Save” action.
○ If file name already exists, navigate to file explorer and rename it.
○ If the file is opened in some program, it shows “Access/permission denied” message box.

● How could user know (without closing file) file must be closed before
renaming?
● The error message has no sense to that user.
● Renaming open file is sharing violation.
● Application has both authority and responsibility to change document’s name
while it is still open in the application and yet it refuses to even try.
Unify the file model
● File system must manage information that is not in main memory,and that is
done by by maintaining a second copy. This approach is correct.
● But implementation details confuses the user.
● Software must hide this detail from user.
● When an application is started from start menu, it’s one instance is created.
● But it is not removed from start menu and there is no indication that it is
running.
Document Management
● File Management is done through
○ Save as dialog
○ Save changes dialog
○ Open file dialog

● Confusing for some tasks.

● Completely incapable for other operations like renaming and copying files.
● Consideration of user’s mental model must be mode.
Document Management (Contd.)
Besides rendering the document as a single entity, there are several goal-directed
functions that user may need.
1. Creating a copy of the document
2. Creating a milestone copy of the document
3. Naming and renaming the document
4. Placing and responsibility the document
5. Specifying stored format the document
6. Reversing some changes
7. Abandoning all changes
1. Creating a copy of the document
● A document must be copied without any interruption.
● Action should be taken quietly, efficiently and sensibly without annoying user with silly
questions.
● If there are any anomalies, the program should make a constructive decision on its own
authority.

2. Naming and renaming the document

● The name of the document should be shown right on the application’s toolbar.
● If the user decides to rename the document, he can just click on it and edit it in place.
● This is the simpler and direct way.
3. Placing and repositioning the document
● The new document must be placed somewhere reasonable where the user can find it again.
● If the user wants to explicitly place the document somewhere, he can use “save as” function
and the document is repositioned as a result of that.

4. Specifying the stored format of the document

● Specifying format should not be associated with the act of saving file to the disk.
● Stored format belongs more properly in a “Document Properties” dialog.
● The format of the document should be specified by placing a small dialog box callable from
the main menu.
● Cautions for data loss on format change.
5. Reversing some changes
● UNDO feature must be used.
● File system should not be called instead of using UNDO function.

6. Abandoning all changes

● File system should not be used for this.
● Instead a simple “Abandon” function on the main menu would suffice.
● This function must be protected by clear warning signs because there is significant data loss.
● Creating a milestone copy of the document “Saved by User at 12/1/2017, 1:15”.
Storage & Retrieval
● A storage system is a tool for placing goods into a repository for safekeeping.
● A storage system is composed of a physical container of the tools necessary
to put objects in and take them back out again.
● A retrieval system is a method for finding goods in a repository.
● A retrieval system is a logical system that allows the goods to be located
according to some abstract value, like its name position or some aspects of its
contents.
Retrieval Methods
1. Position retrieval

- Find by remembering where we left it

2. Identity retrieval

- By identifying name

3. Associative retrieval

- Search based on some inherent quality of the document itself

2.4 Platform Independence
Development Platform
● How is decision for target platforms for software development made?
○ Software should accommodate all existing hardwares.
○ Management want softwares to support both old and new hardware thinking that this approach
costs less than purchasing new hardware.
○ They want to save money on hardware just to spend it on the software.
● Such decision and thinking results in a stupider software at greater cost.
● So, we should always develop softwares that work on latest hardwares.
● This means to say software decision shouldn’t be based on limitations of
existing hardware.
● Purchase the right software, then buy the computer that runs it.
Multiplatform Development
● Don’t do multiplatform development simultaneously.
● Develop only for your primary market.
● Use the revenue from this project to port to your secondary platforms.
● There are two ways for multiplatform development (both bad):
○ 1. Make source code more complicated.
■ Avoided because it increases costs.
■ Magnify time to write and debug code.
○ 2. Homogenize the interface
Multiplatform Development (Contd.)
● More uncertainty and delay due to simultaneous multiplatform development.
● Product quality affected.
● Don’t hamper primary markets by serving secondary markets.
● Windows users want windows controls, while macintosh users want its own
native controls.
● Use model developed for one platform as a prototype for other.
Interoperability
● There were some successful programs in DOS.
● When windows was introduced, people still wanted the DOS version of the
program.
● If windows is better than DOS, why do we develop applications in windows
that look like in DOS?
● We should always design the program expressly for the target platform.
● Old users are afraid of learning curve of new system.
● So, it is better to develop DOS version of program for DOS and Windows
version for Windows.

By Biplap Bhattarai