HCI::="Human Computer Interface".
Answer: the time is not flashing because somebody had a compulsion to program it. But, the time is wrong... they didn't have time and energy to debug it.
[ http://xkcd.com/970/ ]
(XKCD web comic).
Whether we are talking about filling out a form to register for class or
printing out a PAWS report, or using CMS -- we are interfacing with
the system. The Discipline of "Human Computer Interfaces" can
help make even useless things attractive (games and example) and
useful things popular. Apple is famous for putting new
products on the market with innovative human-computer-interfaces. It
has proved to be an good survival strategy.
Of course, you also have to provides the functions and data that your
stakeholders need. But a bad interface can make them unused and useless.
Further -- user interfaces tend to evolve...
A wise designer separates the look-and-feel of the user interface from
the functions and data that make up the heart of the system.
All input/output data is starting to look like a web page.
The web language (HTML) is based on older paper-based
user interfaces. They are also found in rapid development systems like
Visual Basic and HyperTalk. In other words: studying HTML gives you
a vocabulary for talking about most recent human interfaces.
There have been two forms of evolution in web pages. We now have more sophisticated
ways to format and style a page. We can also embed code in the page so that it can
interact with the user. Here is a quick
list of the simpler ideas in HTML
- Special characters
- Horizontal Rule
- Line break
- Inputs in Forms
- User types in the data
- Hidden field
- Mouse/finger/arrows inputs the data
- Radio Button
- Reset/submit link
- Selection --gives the user a choice of Options
The look and feel of an interface is critically dependent on the
technology available to the user. But the design of the interaction
is an essential or logical exercise.
Both the look-and-feel and the interaction design must be good for an
interface to be popular and useful.
The key principle for HCI is that the best interface depends on the
kinds of users
and the kinds of
things they want to do.
For example, many years
ago Sun Micro Systems wanted to design a web site to help engineers and programmers
use the many tools, operating systems, and libraries that
Sun provided. Their first design was rejected by the engineers because it
was all glitz and little data. They redesigned the site to show masses
of data with hardly any graphics, colors, and only one or two fonts.
A recent paper
in the Communications of Association of Computing Machinery
(Vol 50, Number 9, pp84-90, "The Online Consumer's Hierarchy of Needs")
Joseph S Valacich & D Veena Parboteach & John D Wells report on polling
typical users about what they want in a web site. First all users
want "Functional Convenience" -- being able to get things done. But
for some "Utilitarian" web sits like Banking and Bill Paying what matters is
reliability, correct operation, explicit security, response time, ... and other
evidence of "Structural Firmness". Another extreme are "Hedonic"
websites (Music, Movies, Games, Gambling, ...) where the users
want "Representational Delight" most -- consistent look and feel, visual
appeal, creative design, good color, rich media, ... Interestingly there are
"Hybrid" sites (news, shopping, auctioning, Travel, ...) where the users
want a degree of "Delight" mixed with some "Structural Firmness". Note: the
paper is not easy to understand so you don't have to dig it up for this course.
The take home message is
one size does not fit all users.
[ 9710a.html ]
[ 001306.html ]
and file what they say in your heart. User's
do not read web pages.
They scan them
for what is important, now, to them, and only read that.
Your first ideas are going to be wrong. Expect to
-- try it out, get feedback, and improve it.
This is especially true of the home page that users see before entering the web site.
[ judging-websites.html ]
to see what you must do to attract people inside your web site.
I figure that these guidelines also apply -- only more so -- for mobile apps.
Indeed the web allows you to try out many ideas at one time using a strategy called
"A/B" testing. Here you put up several versions of a web page or web site
and randomly direct users to one or another. You also monitor which
versions work best --
induce the user behavior that is best for your organization. You should check out the following links to the hype in 2012 on this idea
From Google to politics:
[ http://www.wired.com/epicenter/2012/04/ff_abtesting/ ]
The A/B Test Results Are In
[ http://www.wired.com/epicenter/2012/05/the-ab-test-results-are-in/ ]
(Game site tweaking).
Test Everything Notes on the A/B Revolution
[ http://www.wired.com/epicenter/2012/05/test-everything-notes-on-the-ab-revolution/ ]
"The rise of A/B testing online began around the turn of the millennium
with internet titans like Google and Amazon, and in recent years it has
been slowly seeping into ever-greater swaths of modern life, having become,
now, more or less standard practice from the leanest startups to the
biggest political campaigns."
(1) Use techniques where users select an item rather than type in data.
(2) Avoid user input by getting the data from somewhere else.
(3) Vet and sanitize all user input -- vet for errors, sanitize for maliciousness.
Coming up with a good HCI design is an iterative process that involves
Here are some detailed steps:
- Know your stakeholders.
- Know your users.
- Know the underlying business needs.
- Gather stakeholder goals and usage scenarios.
- Match the interface to the user.
- Organize the feature/functions
in a structure (tree) that users will understand.
- Meanwhile: work on Art and Layout using Storyboards.
- Consider providing the user with well known navigation aids:
menus, shortcuts, "switchboards", default values, "bread crumbs", search, and help.
- Expect user errors and plan for them.
- Expect abusive input and plan for it.
- Review and document:
can be used to show how users
move from page/screen to page/screen.
Show each an event (typically clicking a button) as a
that changes the state.
Here is an example -- suppose I wanted to create an on line
meeting pace for my class. Then a very simple way to do this is to
provide a web site with two pages. The first allows people to join
a discussion group, and a second would allow you to post a comment
and also to leave the group. This has the following simple state chart.
- Do the math: Calculate how much data is flowing -- Input and output
volumes. Do back of
Hence figure out the time delays experienced by the user. Figure the effects of network bandwidth and
latency on your design.
- Develop prototypes of interfaces using tools and show to the users.
- Start with a low tech prototype -- example a storyboard.
Show to the users.
- Develop a simple first computerized prototype interface and
repeat the following steps.
- Show prototypes to the users and other stakeholders and get their feedback.
- Make sure you explain that it may look OK but the prototype is like an empty
watch case -- no works inside.
- If it needs explaining then it needs fixing!
- Test each web page on many browsers and on many platforms.
- When the stakeholders are happy -- add some functionallity.
- Repeat with the next prototype...
- Develop some real software -- an iteration -- and show it to users etc.
Expect them to change
the interface AGAIN.
- Get priorities on the requests for change: low, medium, high.
- You may need a Change Control Board of people to control the requests.
- Don't let the user get lost
- Each page/screen/form should have the enterprise logo or some other standard header.
- Each page/screen/form should indicate where you are in the enterprise web site.
- Each page/screen/form needs a header and title defining what it is for.
- Inside each page/screen/form use headlines and layout to help people navigate it.
- Make user interfaces familiar.
- Use standard a layouts -- from the enterprise or from popular sites on the WWW.
- Blank space is GOOD.
- Work out a consistent layout for related pages. For example:
header + footer + body with columns.
- Hint: separate the code that handles the user interface from code talking to the
data base and code enforcing business rules.
[ Model-view-controller ]
[ cs375 ]
- User interfaces hide the internal logic. As far as the user is concerned
the page/form/screen is the system.
- Every year there are new options! I didn't think of SMS as an output
technology until last year. Now we have cell phones with
a limited but functional browsers.
Recently we have got specially designed web pages for mobile users.
For example: Reuters, Wikipedia, NPR-online all work differently
on an iPod. And only a few of these are better than the normal site.
- When in doubt about a particular set of HCI alternative you may be able to
make them into a user customizable preference.
- Problem: you have to make the HCI both easy to learn AND easy to use by
A new user needs a different HCI to an experienced user. The HCI needs
to invisibly adapt to the user as they learn.
Can you include optional features that lets an expert work faster and with less effort?
- Also note that some expert users want a
command line interface.
- Programmers need an API that lets them access the same functionality from within a program.
- Can you provide roll-over advice? When the user mouses over an item
images to hold help.
- What standard (library) inputs are there? Microsoft has ready made
templates for dates, ZIP-codes, .... Don't reinvent the wheel!
Also check out the Java libraries, packages like QT, and Visual Basic
for standard ways to create user interfaces. Scripting languages
often come with vast libraries: Perl, Ruby, PHP, etc.
- Good graphics are great. But great graphics comes from talent
and training in the visual arts. If you don't know how, get an artist to help.
However, graphics are never free! Graphics require bandwidth.
They slow down the delivery of the page. Can your users afford the bandwidth you are forcing them to
- Paper is still more readable than screen, but can not be searched easily.
It also costs more to print and distribute paper
Paper is dead trees and dead-end data. It is not easy to re-input or search.
Finally: one can not control the distribution of paper. One must
rely on training users to destroy confidential or critical data.
- Output Issues: Why, Who, What, When, How, Security and Confidentiality.
- Outputs: Push, Pull, or Buffered?
Example Push: a pop up window from "Weather.com" with a weather advisory.
Example Pull: put it on a web site and wait for some one to read it.
Example buffered: Mail, Email, Voice Mail,...
Switching from Pull to Push often makes an application usable. An
example would be a forum where you must refresh a web page to see the
responses to your action vs using EMail to send messages and setting your
client to check EMail every 30 seconds or so.
- Outputs: Distinguish the following types of output: Periodic, Exception, Detail, Summary, Ad-Hoc.
Periodic outputs happen at regular intervals: the monthly pay roll for example.
Exceptions report weird and odd things to the users. An Ad-Hoc
output is unplanned and requested by the user.
- Layout: don't forget to allow lists of data to be sorted into useful
or meaningful orders. This makes it easier for users
to find stuff and look for patterns. The item that increases in the sort
is the key item.
- Control breaks. In a list of data leave a gap when the
key data item
- Elements: Headings + Details
- Columns: positions, alignment (left, middle, right, decimal).
- 2D tables
- Charts, diagrams, graphics? 1 pic = 2k words!
- Don't forget to Control the security of Outputs.
- Pages and screens often clash with the internal logical structure of data. Separate the code that
paginates data from the production of the logical data.
- Keep it simple:
[ designprinciples ]
- Keep It Simple: most users don't have the latest and hottest stuff on
the machines --- and may be using an outlandish device that doesn't
do anything clever. Use the simplest technology that
can possibly work.
- Avoid data entry -- look for automatic ways to collect the data.
Enter data ONCE and only ONCE.
Avoid duplicate data input. Except passwords.
- Separate the screen design from the logic of the processing.
- Control access -- only the right people can be trusted to input data.
- audit_trail::="Know where data came from and be sure you know where it went.... All the way from input to output and storage".
Often auditors will ask to input a transaction and expect to be able to find out
the effects on the data stored in the system.
- Report changes to critical data.
- Log all changes to data -- Just-In-Case things go wrong.
for example, records all changes on a regular basis so that you can go back to a stable
set of information.
- Ask for new passwords twice and hide them on the screen.
Ask the users to check. Then encrypt them before storage.
- Your design should have special subsystems to handle the rollback and replaying
of sequences of events to correct errors.
- Allow for errors: they happen.
Verify and Validate all input.
Query odd input. Spot clearly wrong data or even suspect input.
Avoid text when a menu or button selection will do it it.
- If you don't validate you will have problems: The Great British DMV fiasco
is an example that I talk about in class.
But scripts that get data off the web can be fed any kind of garbage.
Even if your form allows only two values a malicious user can construct a URL
with any string you like for the input.
We must validate all incoming data from the web. More we must often
sanitize data so that we don't accidentally damage our users or our data base.
- If you don't validate web input your system is
Because people can create malicious code that (1) destroys your data base,
(2) places malicious code in your data base to attack your user's systems.
(3) execute the malicious user's code on your servers.
(4) and so on.
- The HCI should minimize user errors. But you must still design software
to handle the most off-the-wall possibilities.
"Nothing is fool proof -- fools are too ingenious".
Malicious users are down right sneaky. For example, in a PHP script,
you can not get data safely from a user by doing this
Without first testing to see if 'key' is in the data:
- It is better to avoid errors in data than try to handle them.
For example: have a menu of months rather than expect people to
input the number of the month. Better -- show a calendar and only
allow selection of a valid date.
Also look to see if you can make erroneous input give rise to a useful
result rather than an error message. A simple solution is to provide
advice about what is wrong. Nicer is a DWIM -- Do What I Mean -- feature,
if this is possible.
- Be very precise when describing input. Then validate what you get against the description.
- Validating input data:
- Check that the data exists!
- Check the
of the data.
For example the day in a month must be a sequence of digits.
- # digit
numbers had better be numeric: "VII" does not mean "7"
and "NOTHING" is not "0".
I heard of this error in the 1970's and it was still happening
in 2009 (Visa).
- Check the
month numbers lie between 1 and 12 inclusive for example.
- Check if the object referred to
If the user inputs their medical record number then it
must be the record number of a real patient on the system.
Is this the next one after the last one?
Even better -- calculate the next number as the default value.
- Check for
For example in the data coming from a
maternity ward you should not have a seven year old mother
with a 25 pound baby.
But several were found in data my colleagues and students worked on
in the 1970s! This is also called
Three letters are used to identify the months(Syntax). But
most of the three letter combinations (AAA for example) are invalid.
As another example -- recognizing the symbols for chemical elements.
We will look at this kind of coding in the next session.
- Check for
Multiple field constraints.
For example the 31st of February.
Another example error in
maternity data: The mother gave birth to three babies, and the field
for triplets was false.
- Many data elements have an additional
data item added to them.
This means that if you add up the digits and divide by 9 you get the
answer "0". There is a similar check that divides by 11.
- Similarly a
is the sum of all the bytes in a record -- modulo some number like 256.
(The word "hash" means that the sum makes no sense).
This is appended to the record and the system can verify the input/transmission
by repeating the calculation and checking that they match. The word
"hash" indicates that the total is strictly meaningless.
- Batch controls: A
is a set of data input at one time. Typically it has many records with different
data but the same record structure. The user works out the total of some
data item. They input the total at the end of the batch. The system checks
that the total the user input equals its own calculation.
You should record all the checks for your data as part of the data dictionary for the project.
- Input errors: Design round them if you can, BUT still expect weird and
dangerous data to come in sometimes!
- Source documents: can you automate the conversion of existing documents
Difficult.... one of those qualities that you can recognize when you
see it, and you can test for when you've got a partial system
- Security problems arise inside an organization.
Most computer crime happens inside an enterprise. Don't
put all your effort into resisting outside hackers.
You have to protect your system from malicious input.
The first step is to validate all input data.
- Make sure that only the right users can input data.
- You can not control what data input is submitted through the web
because users can create their own URLs.
They just type in the address box!
Or they program a bot to try thousands of attempts through HTTP.
A malicious person can look at the source code for the page and concoct
the worst case scenario input as a URL -- and send that.
A carefully placed quotation mark or a very long input can
open up a server to abuse.
Be very careful to check user input for tricks before you execute
any command that contains the data.
- Web pages that call C/C++ programs are likely to be vulnerable to
buffer over-run attacks. These are the oldest attacks. And they still
work. If you must use C/C++, use C++ and the STL strings to
handle character data. Do not use 'gets'.
- Shell and PERL scripts are wide open to the extra quotation mark attack.
In PERL sanitize the data. With a shell script: try some malicious testing.
We put up a nice little page with a script to print the date on one of our
servers -- and within days a nice friendly hacker, using his dad's machine
broke in and EMailed us how he did it...
- Making sure that
incoming data is safe is called
PHP deliberately inserts escape symbols in front of
quotation marks inside user input. Even so.... be careful with incoming data.
- Lately this problem has re-emerged with SQL commands.
As an example see
[ http://xkcd.com/327/ ]
for what can happen when a little bit of cleverness meets a lot of stupidity.
Notice that this exploit didn't even use the web.
- Make sure that output data can not go astray.
Confidential information should not stay on the screen when its
guardian goes away. If the information is on paper, or the users can
print it themselves than they will need security training for handling
to the server. It isn't enough -- malicious users can still avoid your checks
and send raw data.
- Do users prefer it to the other systems?
- Do they learn it quickly?
- Do they pay to use it?
Compare with a user hostile system
- You have to pay people before they use it.
- Users get very angry and threaten to kill the machine and/or
[ Americans with Disabilities Act. Section 105 Compliance] .
A large number of male humans can not distinguish green and blue. Some people
see everything in shades of gray. You must not design web pages that can not be used
by lots of people.... So start here
[ Design_Patterns_Solve_Common_Problems_for_Web_s_Color_Blind_Users ]
- All images must have an alternative text.
- Make sure a partially sighted user can skip over your navigational menus to
get to the meat of your pages.
- COLORS -- never let the function be determined only by color. Two buttons
colored Red (for "Stop") and Green (for "Go") will look gray to a
substantial percentage of male Americans!
Use color to make things attractive and highlight different parts
of the screen.
- Let users choose their own
text sizes and fonts.
- If your page needs a plug-in then have a link to a place to download and install it.
- Don't say "click", say "select" or "choose".
- Pages are read to the partially sighted person.
So make sure that links are still recognizable when the page is read.
- Review your page through a text or voice based browser.
Test using "lynx"/"elinks" for example.
- If your users need a special program to read something then you must
provide a link to download the needed tool: Flash, Acrobat Reader, ...
- Tables can also be problematic -- you may need to add special attributes
to each item defining the row and column it is in using meaningful
- Search for and use tools that check compliance with A.D.A.
- You can also get specialized training in larger enterprises in A.D.A compliance.
Always design a system so that it flows down hill!
In other words design systems that people are happy to use and
they won't abuse.
There are several techniques that help you follow the
DRY principle for web pages. The aim: to be able to change
one aspect across many web pages automatically. Example
change: add a new cookie crumb to ALL my web pages.
- Start by understanding your user's needs, taste, language, and style.
Second consider precisely what the specific goal for a page is.
In parallel think about the overall style of the web sites/data.
Third: Consider two or three specific scenarios and extract a list of
pages/screens that would help users follow the scenarios.
- Remember: A web page is forever.
You will change it many more times than you expect to.
You may never stop changing it.
Design the page code to make it maintainable.
Separate the look and feel from the logic.
- Never have a cute little "Construction Zone" symbol, all
web pages are changed. Instead include a "Last change" date and time.
- If you change the default
background color you must also fix the text color, the link
color, the visited link color, and the active link color. You
can not assume the user has chosen a white background as a default.
- Let the user have as much as control as possible.
- Let the browser do the heavy lifting.
Let the browser layout text for you. Let the user choose the size of
- Think twice about any plug-ins: is there a simpler way to meet the same goal?
Leave clues as to where the viewer is and how they got there.
in the client to the server with the eXtendable Markup Language (XML). When
possible computation is done on the client in parallel with downloading
new data from the server. Most importantly the whole page
doesn't have to be reloaded: just parts of it. For more details, see
[ AJAX ]
on the Wikipedia.
Most systems these days separate the solution into a part that runs
on a number of servers, and a part that executes on the user's machine.
The software on the user's machine is called the client.
A Thick Client is a client computer that runs special software.
A thin client just has a browser.
Notice that you can get more power if you can download special software
into the client computers. However,
this is really a technology that can only be trusted on an intranet --
internal to an organization. You should never encourage users to download
software from unknown sources. This is a very dangerous process that
is likely to lead to security breaches. Thus updating thick clients
needs to be an user-invisible process!
Also note that updates soak up bandwidth and CPU time. So in practice
you need to tell the user that
they can not use the system while the update is downloaded. I regularly have
problems with updates to my iPod because the Macintosh does them silently and
runs very slowly for 15 minutes. Unforgivable!
Three main variations:
- Cascading Style Sheets (CSS) place the look and feel of
a set of web pages in a single place.
- Write pages in
a special language(PHP, JSP) and use a preprocessor to generate the HTML.
- JIT: Generate when the page is requested on server.
[ ../seminar/ ]
on our dept web site scans the directory and generates a list
of upcoming seminars.
- Generate the page when the page is published or changed.
(how I do 90% of my web site).
- Code the data for the web pages in XML and write processes to map them
into HTML and other formats using XSLT or some other style sheet language.
A lot of recent IT work has been taking pages that work quite well on smart phones
and pod/pads and replacing them with pages that are dumbed down to work on
the same platforms. In most web sites that I visit with "mobile" interfaces
remove functions, hide options, and complicate unusual operations. For
example when you create an event on the Google Calendar you can make it a repeating event
on the "full site" but you can't on the "mobile site". Similarly on an iPod address book
you can not add a new group.... but you can on a PC/iMac address book and the synchronize
to copy the group to the iPod. Similarly,you can only attach two alarms to an event on
an iPod. Bot on the iMac iCal you can have as many as you want. Further
these alarms synchronize to the iPod and work perfectly bu can not be
If you do dumb down an app to run on a mobile device,
always make it possible to get back to the "full site".
A better response to the flood of mobile devices is to use a "thick client"
architecture. You provide an "app" that executes on the smart device
rather than running as a "web application" in a browser ("this client"). Here you can
add functionality and improve quality. However people often still reduce
functionality and use "push technology" to keep the app up-to-date -- with
a performance penalty... A common bug is to forget that the app is not executing
in a browser and so you must provide some of the features that are supplied by
the browser -- for example "Back", "Forward", "Stop" and "Reload" buttons.