Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the...

17
11/9/12 CS557: Presenting Data 1/17 csci.csusb.edu/dick/cs557/d1.html [Skip Navigation ][CSUSB ]/[CNS ]/[CSE ]/[R J Botting ] /[CS557 Course Materials ] /d1.html [Search Go ] Fri Nov 9 13:37:48 PST 2012 [d1.txt (Text)] [d1.pdf (PDF)] [About ][News ][Schedule ][Syllabus ][Readings ][Glossary ][Contact ][Grades ] Contents Presenting Data : Human Computer Interfaces : My Hints for Web Page design : Don't Repeat Yourself : Web pages for Mobile Devices Summary Glossary Online Resources : Web Pages that Suck : Good and Bad Web Features : Comprehensive collection of advice from Shopify : HTML : Reference on HTML : Attempts to state General rules for HCI : Recent Research on Features that improve HCIs: : Pattern GridBased Design : Examples of Risks from Interface Design : Usability Guru : Games as Models for Business Software : Always test human computer interfaces Review Questions Abbreviations Links Presenting Data Human Computer Interfaces 1. HCI::="Human Computer Interface". Joke How do you know that a microwave is in a computer science department?

Transcript of Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the...

Page 1: Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the underlying business needs. 4. Gather stakeholder goals and usage scenarios. 5. Match

11/9/12 CS557: Presenting Data

1/17csci.csusb.edu/dick/cs557/d1.html

[Skip Navigation] [CSUSB] / [CNS] / [CSE] / [R J Botting] /[CS557 Course Materials] /d1.html [Search  Go ] Fri Nov 9 13:37:48 PST 2012 

[d1.txt(Text)] [d1.pdf(PDF)] [About] [News] [Schedule] [Syllabus] [Readings] [Glossary] [Contact] [Grades]

Contents

Presenting Data: Human Computer Interfaces: My Hints for Web Page design: Don't Repeat Yourself: Web pages for Mobile DevicesSummaryGlossaryOnline Resources: Web Pages that Suck: Good and Bad Web Features: Comprehensive collection of advice from Shopify: HTML: Reference on HTML: Attempts to state General rules for HCI: Recent Research on Features that improve HCIs:: Pattern ­­ Grid­Based Design: Examples of Risks from Interface Design: Usability Guru: Games as Models for Business Software: Always test human computer interfacesReview QuestionsAbbreviationsLinks

Presenting Data

Human Computer Interfaces

1.  HCI::="Human Computer Interface".

Joke ­­ How do you know that a microwave is in a computer sciencedepartment?

Page 2: Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the underlying business needs. 4. Gather stakeholder goals and usage scenarios. 5. Match

11/9/12 CS557: Presenting Data

2/17csci.csusb.edu/dick/cs557/d1.html

Answer: the time is not flashing because somebody had a compulsion to program it. But, the time iswrong... they didn't have time and energy to debug it.

Joke ­­ How to make a web app unusable

[ http://xkcd.com/970/ ] (XKCD web comic).

Motivation ­­ User Interfaces are a vital part of all systems.

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 ComputerInterfaces" can help make even useless things attractive (games and example) and useful thingspopular. 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 toprovides the functions and data that your stakeholders need. But a bad interface can make themunused 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 thatmake up the heart of the system.

The Web has Redefined Human Computer Interfaces

All input/output data is starting to look like a web page. The web language (HTML) is based onolder paper­based user interfaces. They are also found in rapid development systems like VisualBasic and HyperTalk. In other words: studying HTML gives you a vocabulary for talking aboutmost recent human interfaces. There have been two forms of evolution in web pages. We nowhave more sophisticated ways to format and style a page. We can also embed code in the page sothat it can interact with the user. Here is a quick list of the simpler ideas in HTML 

1.  ElementsTextAnchors/LinksSpecial charactersImages

2.  LayoutBackgroundHorizontal RuleHeaderParagraphLine break

3.  ListsOrderedUnorderedDefinition...

Page 3: Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the underlying business needs. 4. Gather stakeholder goals and usage scenarios. 5. Match

11/9/12 CS557: Presenting Data

3/17csci.csusb.edu/dick/cs557/d1.html

4.  Tables5.  Inputs in Forms

User types in the dataTextText areaPassword

Hidden fieldMouse/finger/arrows inputs the data

ButtonCheckboxRadio ButtonReset/submit linkSelection ­­gives the user a choice of Options

Principle ­­ Look and Feel is Physical but the Interaction is Logical

The look and feel of an interface is critically dependent on the technology available to the user. Butthe 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 anduseful.

Principle ­­ One Size Does Not Fit All

The key principle for HCI is that the best interface depends on the kinds of users and thekinds of things they want to do. For example, many years ago Sun Micro Systems wanted todesign 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 wasall glitz and little data. They redesigned the site to show masses of data with hardly anygraphics, 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 & DVeena Parboteach & John D Wells report on polling typical users about what they want in aweb site. First all users want "Functional Convenience" ­­ being able to get things done. But forsome "Utilitarian" web sits like Banking and Bill Paying what matters is reliability, correctoperation, explicit security, response time, ... and other evidence of "Structural Firmness".Another extreme are "Hedonic" websites (Music, Movies, Games, Gambling, ...) where theusers want "Representational Delight" most ­­ consistent look and feel, visual appeal, creativedesign, good color, rich media, ... Interestingly there are "Hybrid" sites (news, shopping,auctioning, Travel, ...) where the users want a degree of "Delight" mixed with some "StructuralFirmness". Note: the paper is not easy to understand so you don't have to dig it up for thiscourse. The take home message is one size does not fit all users.

Page 4: Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the underlying business needs. 4. Gather stakeholder goals and usage scenarios. 5. Match

11/9/12 CS557: Presenting Data

4/17csci.csusb.edu/dick/cs557/d1.html

Principle ­­ Users do not read web pages ­­ they skim

Read this [ 9710a.html ] and this [ 001306.html ] and file what they say in your heart. User'sdo not read web pages. They scan them for what is important, now, to them, and only readthat.

This is especially true of the home page that users see before entering the web site. Read this [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.

Principle ­­ A Good interface evolves by trial and error involving theusers

Your first ideas are going to be wrong. Expect to iterate ­­ try it out, get feedback, and improveit.

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 oranother. You also monitor which versions work best ­­ induce the user behavior that is best foryour organization. You should check out the following links to the hype in 2012 on this idea FromGoogle to politics: [ http://www.wired.com/epicenter/2012/04/ff_abtesting/ ] The A/B TestResults 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/ ] "Therise of A/B testing online began around the turn of the millennium with internet titans like Googleand Amazon, and in recent years it has been slowly seeping into ever­greater swaths of modernlife, having become, now, more or less standard practice from the leanest startups to the biggestpolitical campaigns."

Principle ­­ data typed by the user is unreliable

(1) Use techniques where users select an item rather than type in data. (2) Avoid user input bygetting the data from somewhere else. (3) Vet and sanitize all user input ­­ vet for errors, sanitizefor maliciousness.

HCI Design Process

Coming up with a good HCI design is an iterative process that involves the users. 1.  Trial2.  Error3.  Repeat

Page 5: Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the underlying business needs. 4. Gather stakeholder goals and usage scenarios. 5. Match

11/9/12 CS557: Presenting Data

5/17csci.csusb.edu/dick/cs557/d1.html

Here are some detailed steps:

1.  Know your stakeholders.2.  Know your users.3.  Know the underlying business needs.4.  Gather stakeholder goals and usage scenarios.5.  Match the interface to the user.6.  Organize the feature/functions in a structure (tree) that users will understand.7.  Meanwhile: work on Art and Layout using Storyboards. 

1.  Consider providing the user with well known navigation aids: menus, shortcuts,"switchboards", default values, "bread crumbs", search, and help.

2.  Expect user errors and plan for them.3.  Expect abusive input and plan for it.4.  Review and document: State Charts can be used to show how users move from

page/screen to page/screen. Show each an event (typically clicking a button) as atransition that changes the state. Here is an example ­­ suppose I wanted to create anon line meeting pace for my class. Then a very simple way to do this is to provide a website with two pages. The first allows people to join a discussion group, and a secondwould allow you to post a comment and also to leave the group. This has the followingsimple state chart.

5.  Do the math: Calculate how much data is flowing ­­ Input and output volumes. Do backof envelope calculations. Hence figure out the time delays experienced by the user.Figure the effects of network bandwidth and latency on your design.

6.  Develop prototypes of interfaces using tools and show to the users.7.  Start with a low tech prototype ­­ example a storyboard. Show to the users.8.  Develop a simple first computerized prototype interface and repeat the following steps. 

1.  Show prototypes to the users and other stakeholders and get their feedback.2.  Make sure you explain that it may look OK but the prototype is like an empty

watch case ­­ no works inside.3.  If it needs explaining then it needs fixing!4.  Test each web page on many browsers and on many platforms.5.  When the stakeholders are happy ­­ add some functionallity.6.  Repeat with the next prototype...

Page 6: Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the underlying business needs. 4. Gather stakeholder goals and usage scenarios. 5. Match

11/9/12 CS557: Presenting Data

6/17csci.csusb.edu/dick/cs557/d1.html

9.  Develop some real software ­­ an iteration ­­ and show it to users etc. Expect them tochange the interface AGAIN.

10.  Get priorities on the requests for change: low, medium, high.11.  You may need a Change Control Board of people to control the requests.

User Interface Hints

1.  Don't let the user get lost 1.  Each page/screen/form should have the enterprise logo or some other standard

header.2.  Each page/screen/form should indicate where you are in the enterprise web site.3.  Each page/screen/form needs a header and title defining what it is for.4.  Inside each page/screen/form use headlines and layout to help people navigate it.5.  Make user interfaces familiar.6.  Use standard a layouts ­­ from the enterprise or from popular sites on the WWW.

2.  Blank space is GOOD.3.  Work out a consistent layout for related pages. For example: header + footer + body with

columns.4.  Hint: separate the code that handles the user interface from code talking to the data base

and code enforcing business rules. Use the [ Model­view­controller ] pattern (Wikipedia)(more in [ cs375 ] and CSE455).

5.  User interfaces hide the internal logic. As far as the user is concerned the page/form/screenis the system.

6.  Every year there are new options! I didn't think of SMS as an output technology until lastyear. Now we have cell phones with a limited but functional browsers. Recently we havegot 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 thenormal site.

7.  When in doubt about a particular set of HCI alternative you may be able to make them intoa user customizable preference.

8.  Problem: you have to make the HCI both easy to learn AND easy to use by an expert. Anew user needs a different HCI to an experienced user. The HCI needs to invisibly adaptto the user as they learn. Can you include optional features that lets an expert work fasterand with less effort?

9.  Also note that some expert users want a command line interface.10.  Programmers need an API that lets them access the same functionality from within a

program.11.  Can you provide roll­over advice? When the user mouses over an item help can pop up...

Perhaps use JavaScript. Or use the "alt" attribute on images to hold help.12.  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 likeQT, and Visual Basic for standard ways to create user interfaces. Scripting languages oftencome with vast libraries: Perl, Ruby, PHP, etc.

13.  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!

Page 7: Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the underlying business needs. 4. Gather stakeholder goals and usage scenarios. 5. Match

11/9/12 CS557: Presenting Data

7/17csci.csusb.edu/dick/cs557/d1.html

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 usersafford the bandwidth you are forcing them to use?

Printed and Screen Output

1.  Paper is still more readable than screen, but can not be searched easily. It also costs moreto print and distribute paper hard copy. Paper is dead trees and dead­end data. It is noteasy to re­input or search. Finally: one can not control the distribution of paper. One mustrely on training users to destroy confidential or critical data.

2.  Output Issues: Why, Who, What, When, How, Security and Confidentiality.3.  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 readit. Example buffered: Mail, Email, Voice Mail,... Switching from Pull to Push often makesan application usable. An example would be a forum where you must refresh a web page tosee the responses to your action vs using EMail to send messages and setting your client tocheck EMail every 30 seconds or so.

4.  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 andrequested by the user.

5.  Layout: don't forget to allow lists of data to be sorted into useful or meaningful orders. Thismakes it easier for users to find stuff and look for patterns. The item that increases in thesort is the key item.

6.  Control breaks. In a list of data leave a gap when the key data item changes.7.  Elements: Headings + Details8.  Columns: positions, alignment (left, middle, right, decimal).9.  2D tables10.  Charts, diagrams, graphics? 1 pic = 2k words!11.  Don't forget to Control the security of Outputs.

12.  Pages and screens often clash with the internal logical structure of data. Separate the codethat paginates data from the production of the logical data.

Designing Input and WWW Pages

1.  Keep it simple: [ designprinciples ]2.  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 simplesttechnology that can possibly work.

3.  Avoid data entry ­­ look for automatic ways to collect the data. Enter data ONCE andonly ONCE. Avoid duplicate data input. Except passwords.

4.  Separate the screen design from the logic of the processing.

Page 8: Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the underlying business needs. 4. Gather stakeholder goals and usage scenarios. 5. Match

11/9/12 CS557: Presenting Data

8/17csci.csusb.edu/dick/cs557/d1.html

5.  Control access ­­ only the right people can be trusted to input data.6.  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 andexpect to be able to find out the effects on the data stored in the system.

7.  Report changes to critical data.8.  Log all changes to data ­­ Just­In­Case things go wrong. Journalizing, for example,

records all changes on a regular basis so that you can go back to a stable set ofinformation.

9.  Ask for new passwords twice and hide them on the screen. Ask the users to check. Thenencrypt them before storage.

10.  Your design should have special subsystems to handle the rollback and replaying ofsequences of events to correct errors.

11.  Allow for errors: they happen. Verify and Validate all input. Query odd input. Spot clearlywrong data or even suspect input. Avoid text when a menu or button selection will do it it.

12.  If you don't validate you will have problems: The Great British DMV fiasco is an examplethat I talk about in class. But scripts that get data off the web can be fed any kind ofgarbage. Even if your form allows only two values a malicious user can construct a URLwith 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 ourdata base.

13.  If you don't validate web input your system is insecure. Because people can createmalicious code that (1) destroys your data base, (2) places malicious code in your database to attack your user's systems. (3) execute the malicious user's code on your servers.(4) and so on.

14.  The HCI should minimize user errors. But you must still design software to handle the mostoff­the­wall possibilities. "Nothing is fool proof ­­ fools are too ingenious". Malicious usersare down right sneaky. For example, in a PHP script, you can not get data safely from auser by doing this

$_GET('key')

or

$_POST('key')

Without first testing to see if 'key' is in the data:

if (array_key_exists($key,$_GET))

return $_GET[$key];

else

return "";

15.  It is better to avoid errors in data than try to handle them. For example: have a menu ofmonths rather than expect people to input the number of the month. Better ­­ show acalendar and only allow selection of a valid date. Also look to see if you can makeerroneous input give rise to a useful result rather than an error message. A simple solution isto provide advice about what is wrong. Nicer is a DWIM ­­ Do What I Mean ­­ feature, if

Page 9: Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the underlying business needs. 4. Gather stakeholder goals and usage scenarios. 5. Match

11/9/12 CS557: Presenting Data

9/17csci.csusb.edu/dick/cs557/d1.html

this is possible.16.  Be very precise when describing input. Then validate what you get against the description.17.  Validating input data: 

1.  Check that the data exists!2.  Check the Syntax of the data. For example the day in a month must be a sequence

of digits.3.  # digit4.  Check data types: 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 happeningin 2009 (Visa).

5.  Check the Range: month numbers lie between 1 and 12 inclusive for example.6.  1..127.  Check if the object referred to Exists: If the user inputs their medical record number

then it must be the record number of a real patient on the system.8.  Check sequence numbers: Is this the next one after the last one? Even better ­­

calculate the next number as the default value.9.  Check for reasonable values: For example in the data coming from a maternity

ward you should not have a seven year old mother with a 25 pound baby. Butseveral were found in data my colleagues and students worked on in the 1970s! Thisis also called Sanity Checking.

10.  Check validity: Three letters are used to identify the months(Syntax). But most ofthe 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 inthe next session.

11.  Check for Multiple field constraints. For example the 31st of February. Anotherexample error in maternity data: The mother gave birth to three babies, and the fieldfor triplets was false.

12.  Many data elements have an additional sum check data item added to them. Thismeans that if you add up the digits and divide by 9 you get the answer "0". There is asimilar check that divides by 11.

13.  Similarly a hash total is the sum of all the bytes in a record ­­ modulo some numberlike 256. (The word "hash" means that the sum makes no sense). This is appendedto the record and the system can verify the input/transmission by repeating thecalculation and checking that they match. The word "hash" indicates that the total isstrictly meaningless.

14.  Batch controls: A batch is a set of data input at one time. Typically it has manyrecords with different data but the same record structure. The user works out thetotal of some data item. They input the total at the end of the batch. The systemchecks 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 theproject.

18.  Input errors: Design round them if you can, BUT still expect weird and dangerous data tocome in sometimes!

19.  Source documents: can you automate the conversion of existing documents into data?

Page 10: Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the underlying business needs. 4. Gather stakeholder goals and usage scenarios. 5. Match

11/9/12 CS557: Presenting Data

10/17csci.csusb.edu/dick/cs557/d1.html

Security

1.  Security problems arise inside an organization. Most computer crime happens inside anenterprise. Don't put all your effort into resisting outside hackers. You have to protect yoursystem from malicious input. The first step is to validate all input data.

2.  Make sure that only the right users can input data.3.  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 thousandsof attempts through HTTP. A malicious person can look at the source code for the pageand concoct the worst case scenario input as a URL ­­ and send that. A carefully placedquotation mark or a very long input can open up a server to abuse. Be very careful tocheck 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­runattacks. 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 PERLsanitize the data. With a shell script: try some malicious testing. We put up a nice littlepage with a script to print the date on one of our servers ­­ and within days a nicefriendly hacker, using his dad's machine broke in and EMailed us how he did it...Making sure that incoming data is safe is called "sanitizing" it. For example PHPdeliberately 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 alot of stupidity. Notice that this exploit didn't even use the web.Make sure that output data can not go astray. Confidential information should notstay on the screen when its guardian goes away. If the information is on paper, or theusers can print it themselves than they will need security training for handling hardcopy.

4.  JavaScript can do many simple format checks before data is posted to the server. It isn'tenough ­­ malicious users can still avoid your checks and send raw data.

Question ­­ Define "user friendly"

Difficult.... one of those qualities that you can recognize when you see it, and you can test forwhen you've got a partial system working: 

1.  Do users prefer it to the other systems?2.  Do they learn it quickly?3.  Do they pay to use it?4.  ...

Compare with a user hostile system 

Page 11: Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the underlying business needs. 4. Gather stakeholder goals and usage scenarios. 5. Match

11/9/12 CS557: Presenting Data

11/17csci.csusb.edu/dick/cs557/d1.html

1.  You have to pay people before they use it.2.  Users get very angry and threaten to kill the machine and/or the programmer.3.  ...

Disabilities and A.D.A.

[ Americans with Disabilities Act. Section 105 Compliance] .1.  All images must have an alternative text.2.  Make sure a partially sighted user can skip over your navigational menus to get to the meat

of your pages.3.  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 maleAmericans! Use color to make things attractive and highlight different parts of the screen.

4.  Let users choose their own text sizes and fonts.5.  If your page needs a plug­in then have a link to a place to download and install it.6.  Don't say "click", say "select" or "choose".7.  Pages are read to the partially sighted person. So make sure that links are still recognizable

when the page is read.8.  Review your page through a text or voice based browser. Test using "lynx"/"elinks" for

example.9.  If your users need a special program to read something then you must provide a link to

download the needed tool: Flash, Acrobat Reader, ...10.  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 words.11.  Search for and use tools that check compliance with A.D.A.12.  You can also get specialized training in larger enterprises in A.D.A compliance.

Web Page Patterns that handle Color Blindness

A large number of male humans can not distinguish green and blue. Some people seeeverything in shades of gray. You must not design web pages that can not be used by lots ofpeople.... So start here [Design_Patterns_Solve_Common_Problems_for_Web_s_Color_Blind_Users ]

My Hints for Web Page design

Motivation

Always design a system so that it flows down hill! In other words design systems that peopleare happy to use and they won't abuse.

Page 12: Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the underlying business needs. 4. Gather stakeholder goals and usage scenarios. 5. Match

11/9/12 CS557: Presenting Data

12/17csci.csusb.edu/dick/cs557/d1.html

1.  Start by understanding your user's needs, taste, language, and style. Second consider preciselywhat the specific goal for a page is. In parallel think about the overall style of the websites/data. Third: Consider two or three specific scenarios and extract a list of pages/screensthat would help users follow the scenarios.

2.  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 thelook and feel from the logic.

3.  Never have a cute little "Construction Zone" symbol, all web pages are changed. Insteadinclude a "Last change" date and time.

4.  If you change the default background color you must also fix the text color, the link color, thevisited link color, and the active link color. You can not assume the user has chosen a whitebackground as a default.

5.  Let the user have as much as control as possible.6.  Let the browser do the heavy lifting. Let the browser layout text for you. Let the user choose

the size of the font.7.  Think twice about any plug­ins: is there a simpler way to meet the same goal?

Menus and cookie crumbs

Leave clues as to where the viewer is and how they got there.

AJAX ­­ Asynchronous JavaScript and XML

AJAX is a popular new (2006­2007) technology that connects JavaScript in the client to theserver with the eXtendable Markup Language (XML). When possible computation is done onthe client in parallel with downloading new data from the server. Most importantly the wholepage doesn't have to be reloaded: just parts of it. For more details, see [ AJAX ] on theWikipedia.

Thick Clients and Thin Clients

Most systems these days separate the solution into a part that runs on a number of servers, anda part that executes on the user's machine. The software on the user's machine is called theclient. A Thick Client is a client computer that runs special software. A thin client just has abrowser. Notice that you can get more power if you can download special software into theclient 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 fromunknown 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 theuser that they can not use the system while the update is downloaded. I regularly haveproblems with updates to my iPod because the Macintosh does them silently and runs veryslowly for 15 minutes. Unforgivable!

Page 13: Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the underlying business needs. 4. Gather stakeholder goals and usage scenarios. 5. Match

11/9/12 CS557: Presenting Data

13/17csci.csusb.edu/dick/cs557/d1.html

Don't Repeat Yourself

There are several techniques that help you follow the DRY principle for web pages. The aim: to beable to change one aspect across many web pages automatically. Example change: add a newcookie crumb to ALL my web pages.

Three main variations: 

1.  Cascading Style Sheets (CSS) place the look and feel of a set of web pages in a singleplace.

2.  JavaScript can help a little by inserting repetitive data in pages.3.  Write pages in a special language(PHP, JSP) and use a preprocessor to generate the

HTML. 1.  JIT: Generate when the page is requested on server. For example [ ../seminar/ ] on

our dept web site scans the directory and generates a list of upcoming seminars.2.  Generate the page when the page is published or changed. (how I do 90% of my

web site).

4.  Code the data for the web pages in XML and write processes to map them into HTML andother formats using XSLT or some other style sheet language.

5.  AJAX.

Web pages for Mobile Devices

A lot of recent IT work has been taking pages that work quite well on smart phones and pod/padsand replacing them with pages that are dumbed down to work on the same platforms. In most websites that I visit with "mobile" interfaces remove functions, hide options, and complicate unusualoperations. For example when you create an event on the Google Calendar you can make it arepeating event on the "full site" but you can't on the "mobile site". Similarly on an iPod addressbook you can not add a new group.... but you can on a PC/iMac address book and thesynchronize to copy the group to the iPod. Similarly,you can only attach two alarms to an event onan iPod. Bot on the iMac iCal you can have as many as you want. Further these alarmssynchronize to the iPod and work perfectly bu can not be edited.

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 providean "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 stillreduce functionality and use "push technology" to keep the app up­to­date ­­ with a performancepenalty... A common bug is to forget that the app is not executing in a browser and so you mustprovide some of the features that are supplied by the browser ­­ for example "Back", "Forward",

Page 14: Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the underlying business needs. 4. Gather stakeholder goals and usage scenarios. 5. Match

11/9/12 CS557: Presenting Data

14/17csci.csusb.edu/dick/cs557/d1.html

"Stop" and "Reload" buttons.

. . . . . . . . . ( end of section My Hints for Web Page design) <<Contents | End>>

SummaryGetting a system that works can depend critically on getting the human interaction to be error free andeasy. This takes time, care, working with users and prototyping.

Glossary1.  API::="Application Programmers Interface", a collection of functions and classes that enable someone

to use a separately defined component.2.  bandwith::="The amount of information that can be transmitted in a unit time", in computer systems this

is measured in bits or bytes. For any physical data channel there is a top limit on the amount ofinformation that can be transmitted per unit time. This is its bandwidth. Example: A slow modemhooked into the fast Internet gives a very bad response when sent a large picture that has many mega­bytes of information.

3.  latency::="The time delay between the transmission of data and its reception", also the time delaybetween asking for some data and when it starts to arrive.

4.  CSS::="Cascading style sheets", change the detailed properties of elements in pages.5.  DRY::="Don't Repeat Yourself", in computer code (data and program) say everything ONCE and

ONLY once. Refactor code and also design tools and metasystems to make this possible.6.  HCI::="Human Computer Interface".7.  JIT::="Just In Time".8.  KISS::="Keep It Simple, Stupid".

Online Resources

Web Pages that Suck

[ biggest­web­design­mistakes­in­2004.html ]

Good and Bad Web Features

[ featuresgood.html ] [ featuresbad.html ]

Page 15: Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the underlying business needs. 4. Gather stakeholder goals and usage scenarios. 5. Match

11/9/12 CS557: Presenting Data

15/17csci.csusb.edu/dick/cs557/d1.html

Comprehensive collection of advice from Shopify

[ website­design­101 ]

HTML

[ ../samples/intro.comp.html.html ] [ ../samples/intro.comp.syntax.html ]

Reference on HTML

(HomerEtAl98): Alex Homer & Chris Ullman & Steve Wright, instant HTML: Programmer'sreference, HTML 4.0 edition, WROX 1998.

Attempts to state General rules for HCI

1.  CRAP::acronym="Contrast, Repetition, Alignment, Proximity", The key principles of design fromRobin Williams (not the famous comedian).

Recent Research on Features that improve HCIs:

1.  Natalia Juristo & Ana Maria Moreno & Maria­Isabel Sanchez­Segura2.  Guidelines for Eliciting Usability Functionalities3.  IEEE Trans SE V33n11(Nov 2007)pp744­7584.  =SURVEY =EXPERIMENT USER PATTERNS FEATURES ISSUES5.  Lists 9 techniques to improve usability:6.  Feedback, Undo/Cancel, Prevent/Correct errors, Wizards, User Profiles, Help, Command

aggregation(record­replay), shortcuts, Reuse information7.  For each provides a description and a set of issues that need to be raised with the

stakeholders.8.  See [ usability­elicitation­patterns ]

Pattern ­­ Grid­Based Design

This is a well established way to layout a lot of information so that it doesn't look messy. Here aresome links [ showPattern.php?patternID=grid­based­layout ] [http://www.smashingmagazine.com/2007/04/14/designing­with­grid­based­approach/ ]

Examples of Risks from Interface Design

Page 16: Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the underlying business needs. 4. Gather stakeholder goals and usage scenarios. 5. Match

11/9/12 CS557: Presenting Data

16/17csci.csusb.edu/dick/cs557/d1.html

[ Data­Entry­Errors­Resulted­In­Improper­Sentences ]

Usability Guru

[ http://www.useit.com/jakob/ ] and his 10 mistakes [ 9605.html ] (takes time to load!).

Games as Models for Business Software

This article makes a claim that breaks one of my personal rules ­­ modes are bad. So take this

[ http://www.forbes.com/sites/joshbersin/2012/08/16/the­move­from­systems­of­record­to­systems­of­engagement/3/ ] (Forbes) with a pinch of salt.

Always test human computer interfaces

How ever much you study and practice good design, you will find that when users get their handson it it does not work as expected. You have to test your ideas out on real users... This turns into aguideline [ Principle ­­ A Good interface evolves by trial and error involving the users ]above.

. . . . . . . . . ( end of section Online Resources) <<Contents | End>>

Review Questions

1.  What is your least favorite page on the web? Write down its URL. Why do you hate it?2.  Define all the following acronyms: HTML, CSS, AJAX, DRY, KISS, JIT, and HCI.3.  Compare the advice given on the web pages linked to this page on web page design ­­ any

conclusions?4.  Microwaves and VCR's have some of the most unusable interfaces known ­­ why?5.  What are the things you can do with plain HTML?6.  How do user's read computer output ­­ for example web pages?7.  Make a list of human interface errors you will promise to never commit.8.  What can I do to improve our CSE557 web site?9.  Make a list of the advantages of hard copy vs soft copy output.10.  What happens to a web design when reshaped to fit a cell phone?11.  Traditional computer output uses columnar reports. Are there other ways of communicating data to

users? Clues: Challenger Space Shuttle disaster, UK DHSS team, Edward Tufts.

. . . . . . . . . ( end of section Presenting Data) <<Contents | End>>

Page 17: Gocsci.csusb.edu/dick/cs557/d1.pdf · 1. Know your stakeholders. 2. Know your users. 3. Know the underlying business needs. 4. Gather stakeholder goals and usage scenarios. 5. Match

11/9/12 CS557: Presenting Data

17/17csci.csusb.edu/dick/cs557/d1.html

Abbreviations1.  TBA::="To Be Announced".2.  TBD::="To Be Done".

LinksNotes ­­ Analysis [ a1.html ] [ a2.html ] [ a3.html ] [ a4.html ] [ a5.html ] ­­ Choices [ c1.html ] [c2.html ] [ c3.html ] ­­ Data [ d1.html ] [ d2.html ] [ d3.html ] [ d4.html ] ­­ Rules [ r1.html ] [r2.html ] [ r3.html ]

Projects [ project0.html ] [ project1.html ] [ project2.html ] [ project3.html ] [ project4.html ] [project5.html ] [ projects.html ]

Field Trips [ F1.html ] [ F2.html ] [ F3.html ]

Metadata [ about.html ] [ index.html ] [ schedule.html ] [ syllabus.html ] [ readings.html ] [review.html ] [ glossary.html ] [ contact.html ] [ grading/ ]

End