[Skip Navigation] [CSUSB] / [CNS] / [Comp Sci & Eng Dept] / [R J Botting] / [CS372 Course Materials] [Search ] cs372/d1.html Fri Nov 7 08:56:44 PST 2008 [Text Version] [About] [News] [Schedule] [Syllabus] [Glossary] [Contact] [Search] [Grades]
Readings Analysis [1] [2] [3] [4] [5] Choices [1] [2] [3] Data [1] [2] [3] [4] Requirements [1] [2] [3]
[Review] Field Trips [1] [2] [3] Project Iterations [1] [2] [3] [4] [5]

Contents

    Presenting Data

      Human Computer Interfaces

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

        Joke: How do you know that a microwave is in a computer science department?

         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.

        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 Computer Interfaces" can help make even useless things attractive (games) and useful things very popular. Apple is famous for putting new products on the market wit innovative human-computer-interfaces. It has proved to be an good survival strategy. You also have to provides the functions and data that your stakeholders need. But a bad interface can make these 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.

        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 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 many recent human interfaces.

        Principle -- Look and Feel is Physical but interaction is Logical

        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.

        Principle -- One Size Does Not Fit All

          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 was 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 had 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 colors, rich media, ... Interestingly there are "Hibrid" 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.

          HCI Design Process

            Coming up with a good HCI design is an iterative process. Here are some steps:
          1. Know your stakeholders.
          2. Know your users.
          3. Know the underlying business needs. Gather stakeholder goals and usage scenarios.
          4. Match the interface to the user.
          5. Organize the feature/functions in a structure (tree) that users will understand.
          6. Meanwhile: work on Art and Layout. Storyboards.
          7. Repeat the following steps
            1. Consider providing: menus, shortcuts, "switchboards", defaults, 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 a transition that changes the state. Here is an example -- suppose I wanted to create an on line or virtual 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.

              [Users can join the discussion or exit and when joined can contribute until they leave]

            5. Do the math: Calculate how much data is flowing. Input and output volumes, Time. Cost. back of envelope calculations. Figure the effects of network bandwidth and latency on you designs.
            6. Develop prototypes of interfaces using tools.
            7. Show prototypes to the users and other stakeholders and get their feedback.
            8. Make sure you explain that it may look OK but the prototype is like an empty watch case -- no works inside.
            9. If it needs explaining then it needs fixing!
            10. Test each web page on many browsers and on many platforms.
            11. Repeat with the next prototype...

          8. Develop some real software -- an iteration -- and show it to users etc. Expect them to change the interface AGAIN.
          9. Get priorities on the requests for change: low, medium, high.
          10. You may need a Change Control Board of people to control the requests.

          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 User interface code from data base and Business rules code. Use the Model+View+Controller pattern ( [ cs375 ] and CSCI455).
          5. User interfaces hide the internal logic. As far as the user is concerned the page/form/screen is the system.
          6. 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 an limited but functional browsers.
          7. When in doubt about a particular set of HCI alternative you may be able to make them into a user customizable preference.
          8. DO THE MATH: layout, space, volume, frequency, time,
          9. Problem: you have to make the HCI both easy to learn AND easy to use by an expert. A new user needs a different HCI to an experienced user. The HCI needs to invisibly adapt to the user as they learn. 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.
          10. 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.
          11. Can you include optional features that lets an expert work faster and with less effort?
          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 like QT, and Visual Basic for standard ways to create user interfaces. Scripting languages often come 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. This is why we had "Art" as a minor for the first design of the BA degree. However, graphics are never free! The slow down the delivery of the page in most cases. Can your users afford 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 more to print and distribute paper hard copy. 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.
          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 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.
          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 and requested by the user.
          5. 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.
          6. Control breaks. In a list of data leave a gap when the key data item changes.
          7. Elements: Headings + Details
          8. Columns: positions, alignment (left, middle, right, decimal).
          9. 2D tables
          10. Charts, diagrams, graphics? 1 pic = 2k words!
          11. Don't forget to Control the security of Outputs.

          12. Pages and screens clash with the logic of data. Separate the code that paginates data from the production of the logical data.

          Designing Input and WWW Pages

          1. 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.
          2. Avoid data entry -- look for an automatic way to collect the data.
          3. Enter data ONCE and only ONCE. Avoid duplicate data input. Except passwords.
          4. Separate the screen design from the logic of the processing.
          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 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. Journalizing records all changes on a regular basis so that you can go back to a stable set of information.
          7. Allow for errors: they happen. Verify and Validate all input. Query odd input. Spot clearly wrong data. Ask for passwords twice and hide them on the screen. Feed back and and ask the users to check. If you don't validate you will have problems: The Great British DMV fiasco is an example that I talk about in class. Your design should have special subsystems to handle the rollback and replaying of sequences of events to correct errors.
          8. 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". 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.
          9. Validating input data:
            1. Range Check: months lie between 1 and 12 inclusive.
            2. Existence Check: If the user inputs their medical record number then it must be the record number of a real patient on the system.
            3. Check data types: numbers had better by numeric: "VII" does not mean "7" and "NOTHING" is not "0".
            4. Check sequence numbers: Is this the next one after the last one?
            5. Check for reasonable values: These are not reasonable items in a maternity ward data base: mother's age=7, Baby's weight=24. But the were found in one!
            6. Validity checks: Three letters used to identify the months. But any most three letter combinations (AAA for example) are invalid.
            7. Multiple field constraints. Another error in maternity data: The mother has three babies, and the field for triplets is false.
            8. Many data elements have additional sum check data 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.
            9. Similarly a hash totals is the sum of all the bytes in a record -- modulo some number like 256. 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.
            10. Batch controls: A batch 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 repeated 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 be able to find the checks for your data by looking in the data dictionary for the project.
          10. Input errors: Design round them if you can, BUT still expect weird and dangerous data to come in sometimes!
          11. Source documents: can you automate the conversion of existing documents into data?

          Security

          1. Security problems arise inside an organization. Most computer crime happens inside an enterprise. Don't put all your effort into resisting outside hackers.
          2. 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 hard copy.
          3. Make sure that only the right users can input data.
          4. You can not control what input data is submitted through the web. 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.
            • 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... Lately this problem has re-emerged with SQL commands.
            • Making sure that incoming data is safe is called "sanitizing" it. PHP deliberately inserts escape symbols in front of quotation marks inside user input. Even so.... be careful with incoming data.

              As an example see [ http://xkcd.com/327/ ] for what can happen when a little bit of clever malice meets a lot of stupidity. Notice that this exploit didn't even use the web.

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

          Define "user friendly"

           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 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

          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.

          1. Americans with Disabilities Act.
          2. Section 105 Compliance.
          3. All images must have an alternative text.
          4. Make sure a partially sighted user can skip over you navigational menus to get to the meat of your pages.
          5. 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.
          6. Let users choose their own text sizes and fonts.
          7. If your page needs a plug-in then have a link to a place to download and install it.
          8. Don't say "click" say "select" or "choose".
          9. Review your page through a text or voice based browser. Make sure your pages work on "lynx"/"elinks" -- a non-graphic browser that is used by partially sighted people. These pages are then read to the partially sighted person. So make sure that links are still recognizable when the page is read.
          10. If your users need a special program to read something then you must provide a link to download the needed tool: Flash, Acrobat Reader, ...
          11. Search 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.

        My Hints for Web Page design

          Motivation

           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.

        1. 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 them.
        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 the look and feel from the logic. And never have a cute little "Construction Zone" symbol, all web pages are changed. Instead include a "Last change" date and time.
        3. If you change the background color you must also fix the text color, the link color, the visited link color, and the active link color.
        4. Let the user have as much as control as possible.
        5. Let the browser do the heavy lifting. Let the browser layout text for you. Let the user choose the size of the font.
        6. 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 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.

          Thick Clients

          Notice that you can get more power if you can download special software into the client computers. These are called Thick Clients. 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!

        Don't Repeat Yourself

         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.

        Three main variations:

        1. Cascading Style Sheets (CSS) and JavaScript can help a little.
        2. 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.
          2. Generate the page when the page is published or changed. (how I do 90% of my web site).

        3. 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.

        Review

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

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

      Glossary

    1. 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 of information that can be transmitted per unit time. This is its bandwidth. Example: A slow modem hooked 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 delay between 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

        HTML

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

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

        Web Pages that Suck

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

        My Least Favorite page 2006

         [ http://www.abo.fi/~ttiihone/ ]

        Attempts to state General rules for HCI

        How users read the web -- THEY DON'T! [ 9710a.html ]

      1. CRAP::acronym="Contrast, Repetition, Alignment, Proximity", The key principles of design from Robin Williams (no the comedian).


        (Good and bad features): [ featuresgood.html ] [ featuresbad.html ] [ 9605.html ]

        Recent Research on Features that improve HCIs:


        1. Natalia Juristo & Ana Maria Moreno & Maria-Isabel Sanchez-Segura
        2. Guidelines for Eliciting Usability Functionalities
        3. IEEE Trans SE V33n11(Nov 2007)pp744-758
        4. =SURVEY =EXPERIMENT USER PATTERNS FEATURES ISSUES
        5. Lists 9 techniques to improve usability:
        6. Feedback, Undo/Cancel, Prevent/Correct errors, Wizards, User Profiles, Help, Command aggregation(record-replay), shortcuts, Reuse information
        7. 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 are some links [ showPattern.php?patternID=grid-based-layout ] [ http://www.smashingmagazine.com/2007/04/14/designing-with-grid-based-approach/ ]

    . . . . . . . . . ( 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. Microwaves and VCR's have some of the most unusable interfaces known -- why?
    4. How to use HTML to get desirable effects?
    5. Make a list of human interface errors you will promise to never commit.
    6. What can I do to improve our CSCI372 web site?
    7. Make a list of the advantages of hard copy vs soft copy output.
    8. What happens to a web design when reshaped to fit a cell phone?
    9. 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>>

Abbreviations

  • TBA::="To Be Announced".
  • TBD::="To Be Done".

    Also see [ glossary.html ] for more special abbreviations and phrases.

    End