Skip to content

Instantly share code, notes, and snippets.

@bag-man
Last active August 29, 2015 14:21
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save bag-man/ee2cc3226627b4214a59 to your computer and use it in GitHub Desktop.
Save bag-man/ee2cc3226627b4214a59 to your computer and use it in GitHub Desktop.
UI notes
\documentclass[10pt]{article}
\usepackage{a4wide}
\usepackage[english]{babel}
\usepackage{fancyhdr}
\usepackage{hyperref}
\usepackage{lastpage}
\usepackage{graphicx}
\usepackage[section]{placeins}
\usepackage[superscript,biblabel]{cite}
\usepackage[margin=1in]{geometry}
\pagestyle{fancy}
\rhead{}
\begin{document}
\setcounter{page}{1}
\section*{Web content accessibility guidlines}
\begin{enumerate}
\item Percievable, information must be percievable to all users
\item Operable, user must physically be able to operate
\item Understandable, knowing how UI works
\item Robust, compatible with mutltiple devices / regions
\end{enumerate}
\section*{Interaction styles}
\begin{enumerate}
\item Direct manipulation, drag and drop etc..
\item Menu selection, file > this > that
\item From fill, type stuff in box
\item Command prompt, stype commands
\item Natural language, Google search, wolfram alpha
\end{enumerate}
\section*{Measuring usability}
\begin{enumerate}
\item Time to learn
\item Speed of performance
\item Rate of user errors
\item Retention over time
\item Satisfaction, subjective
\end{enumerate}
\section*{Ethics Questions}
\begin{enumerate}
\item What is your first impression / gut feeling?
\item Do you have to keep it a secret?
\item Would you tell OP's mum?
\item Would you do a TV interview on it?
\item Would you be happy to have it done to you?
\end{enumerate}
\section*{Basis for ethical decisions}
\begin{enumerate}
\item Experience
\item Opinions
\item Beliefs (Opinions with no evidence)
\item Principles
\item Guidelines BCS etc..
\item Laws
\end{enumerate}
\section*{Four aspects of BCS code of conduct}
\begin{enumerate}
\item Public interest
\item Professional competence
\item Duty to the profession
\item Duty to the relevant authority
\end{enumerate}
\section*{Star lifecycle model}
\begin{figure}[ht!]
\begin{center}
\includegraphics[scale=0.40]{star-lifecycle.jpg}
\end{center}
\end{figure}
\section*{Normans design principles - 1988}
\begin{enumerate}
\item Visibility – The more visible functions are, the more likely users will be able to know what to do next. Incontrast, when functions are "out of sight," it makes them more difficult to find and know how to use.
\item Feedback – Feedback is about sending back information about what action has been done and what has been accomplished, allowing the person to continue with the activity. Various kinds of feedback are available for interaction design-audio, tactile, verbal, and combinations of these.
\item Constraints – The design concept of constraining refers to determining ways of restricting the kind of user interaction that can take place at a given moment. There are various ways this can be achieved.
\item Mapping – This refers to the relationship between controls and their effects in the world. Nearly all artifacts need some kind of mapping between controls and effects, whether it is a flashlight, car, power plant, or cockpit. An example of a good mapping between control and effect is the up and down arrows used to represent the up and down movement of the cursor, respectively, on a computer keyboard.
\item Consistency – This refers to designing interfaces to have similar operations and use similar elements for achieving similar tasks. In particular, a consistent interface is one that follows rules, such as using the same operation to select all objects. For example, a consistent operation is using the same input action to highlight any graphical object at the interface, such as always clicking the left mouse button. Inconsistent interfaces, on the other hand, allow exceptions to a rule.
\item Affordance – is a term used to refer to an attribute of an object that allows people to know how to use it. For example, a mouse button invites pushing (in so doing acting clicking) by the way it is physically constrained in its plastic shell. At a very simple level, to afford means "to give a clue" (Norman, 1988). When the affordances of a physical object are perceptually obvious it is easy to know how to interact with it.
\end{enumerate}
\section*{Shneidermans Eight Golden Rules - 1986}
\begin{enumerate}
\item Strive for consistency - Consistent sequences of actions should be required in similar situations; identical terminology should be used in prompts, menus, and help screens; and consistent commands should be employed throughout.
\item Enable frequent users to use shortcuts - As the frequency of use increases, so do the user's desires to reduce the number of interactions and to increase the pace of interaction. Abbreviations, function keys, hidden commands, and macro facilities are very helpful to an expert user.
\item Offer informative feedback - For every operator action, there should be some system feedback. For frequent and minor actions, the response can be modest, while for infrequent and major actions, the response should be more substantial.
\item Design dialog to yield closure - Sequences of actions should be organized into groups with a beginning, middle, and end. The informative feedback at the completion of a group of actions gives the operators the satisfaction of accomplishment, a sense of relief, the signal to drop contingency plans and options from their minds, and an indication that the way is clear to prepare for the next group of actions.
\item Offer simple error handling - As much as possible, design the system so the user cannot make a serious error. If an error is made, the system should be able to detect the error and offer simple, comprehensible mechanisms for handling the error.
\item Permit easy reversal of actions - This feature relieves anxiety, since the user knows that errors can be undone; it thus encourages exploration of unfamiliar options. The units of reversibility may be a single action, a data entry, or a complete group of actions.
\item Support internal locus of control - Experienced operators strongly desire the sense that they are in charge of the system and that the system responds to their actions. Design the system to make users the initiators of actions rather than the responders.
\item Reduce short-term memory load - The limitation of human information processing in short-term memory requires that displays be kept simple, multiple page displays be consolidated, window-motion frequency be reduced, and sufficient training time be allotted for codes, mnemonics, and sequences of actions.
\end{enumerate}
\section*{Nielsen's 10 Usability Heuristics for User Interface Design - 1995}
\begin{enumerate}
\item Visibility of system status - The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
\item Match between system and the real world - The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
\item User control and freedom - Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
\item Consistency and standards - Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
\item Error prevention - Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
\item Recognition rather than recall - Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
\item Flexibility and efficiency of use - Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
\item Aesthetic and minimalist design - Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
\item Help users recognize, diagnose, and recover from errors - Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
\item Help and documentation - Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.
\end{enumerate}
\end{document}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment