Presenting Data

Human Computer Interfaces

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.

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 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.
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 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
1. Elements
  - Text
  - Anchors/Links
  - Special characters
  - Images
2. Layout
  - Background
  - Horizontal Rule
  - Header
  - Paragraph
  - Line break
3. Lists
  - Ordered
  - Unordered
  - Definition
  - ...
4. Tables
5. Inputs in Forms
  - User types in the data
    - Text
    - Text area
    - Password
  - Hidden field
  - Mouse/finger/arrows inputs the data
    - Button
    - Checkbox
    - Radio Button
    - Reset/submit link
    - Selection --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. 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
Principle -- Users do not read web pages -- they skim
Principle -- A Good interface evolves by trial and error involving the users
Your first ideas are going to be wrong. Expect to iterate -- try it out, get feedback, and improve it.
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."

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 by getting the data from somewhere else. (3) Vet and sanitize all user input -- vet for errors, sanitize for maliciousness.

HCI Design Process
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 a transition 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.
  5. Do the math: Calculate how much data is flowing -- Input and output volumes. Do back of 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...
  9. Develop some real software -- an iteration -- and show it to users etc. Expect them to change 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/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 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.
  7. When in doubt about a particular set of HCI alternative you may be able to make them into a user customizable preference.
  8. 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. Can you include optional features that lets an expert work faster and 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 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. 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 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 often clash with the internal logical structure of data. Separate the code that 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 simplest technology that can possibly work.
  3. Avoid data entry -- look for automatic ways to collect the data. 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.
  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 of information.
  9. Ask for new passwords twice and hide them on the screen. Ask the users to check. Then encrypt them before storage.
  10. Your design should have special subsystems to handle the rollback and replaying of sequences of events to correct errors.
  11. 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.
  12. 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.
  13. If you don't validate web input your system is insecure. 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.
  14. 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
```
 	$_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 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.
  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. # digit
    4. 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 happening in 2009 (Visa).
    5. Check the Range: month numbers lie between 1 and 12 inclusive for example.
    6. 1..12
    7. 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. But several were found in data my colleagues and students worked on in the 1970s! This is also called Sanity Checking.
    10. Check validity: 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.
    11. 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.
    12. Many data elements have an additional sum check 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.
    13. Similarly a hash total 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.
    14. 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 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.
  18. Input errors: Design round them if you can, BUT still expect weird and dangerous data to come in sometimes!
  19. 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. You have to protect your system 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 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 "sanitizing" it. For example 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 hard copy.
  4. 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.
  Question -- 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. 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 male Americans! 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 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 ]
My Hints for Web Page design
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 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 the look and feel from the logic.
3. Never have a cute little "Construction Zone" symbol, all web pages are changed. Instead include a "Last change" date and time.
4. 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.
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 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 and Thin Clients
  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!
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) place the look and feel of a set of web pages in a single place.
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 and other 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/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 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 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.

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

Summary

Glossary

API::="Application Programmers Interface", a collection of functions and classes that enable someone to use a separately defined component.
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.
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.
CSS::="Cascading style sheets", change the detailed properties of elements in pages.
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.
HCI::="Human Computer Interface".
JIT::="Just In Time".
KISS::="Keep It Simple, Stupid".
Online Resources
1. CRAP::acronym="Contrast, Repetition, Alignment, Proximity", The key principles of design from Robin Williams (not the famous comedian).
  
  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/ ]
  
  Examples of Risks from Interface Design
  [ 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 hands on it it does not work as expected. You have to test your ideas out on real users... This turns into a guideline [ 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>>

Abbreviations

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

Notes -- 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/ ]