this document describes how programs written for {harrison} should behave. this document draws heavily from the macintosh human interface guidelines and the elementary os human interface guidelines.
- simple design, normal people first.
- consistent design
- friendly design, do what people want, anticipate mistakes
10. the harrison system is built around physical metaphors. if people have an understanding of how something works in the physical world, we can take advantage of that in our software interfaces. the classic desktop metaphor is fundamental to the harrison system.
11. the computer serves the user. the computer should not do anything without the user telling it to do something. don't design any interface which requires the user to immediately react to something; a popup should not disappear without a user having chance to read it, and confirm that they have read it.
12. if the computer does, and sometimes it should, the state before it does so should be easily accessible to the user. for example, your application should autosave, if it is an application that features saving. but the user should be able to access previous versions of the file.
13. in the physical world, things are discoverable: you can see all the options available to you at any time. this should be carried over to computer systems. don't ever leave the user staring at a blank page; there should be prompts to suggest common actions available to them.
14. if the user would reasonably think that a particular task should be possible in your application, it should be possible. if it is not, it should be clear to the user that this is the case, and there should be a good reason why it is not. that good reason is never "it made things easier for me, the developer".
15. in the physical world, things that behave differently also look different. people don't mistakenly brush their hair with scissors, because the function is clear from the design. in your application, make it clear what each button does graphically, and use text to clarify any nuance.
20. in the physical world, our actions have immediate feedback. similarly in the harrison system any user interaction should immediately and graphically show a change. if the user makes a change, they should not have to manually save the change, or confirm the change; as far as they are concerned, the change has happened and that is that.
21. sometimes changes can be destructive; fortunately on a computer system it is easy to restore a previous state, and this option should be available to the user, whatever action they take. there are few situations where a modal dialogue box should be shown asking the user if they are sure; the action should always be carried out first, and allow the user to revert the action if they realise it was a mistake. revertion should also happen immediately; often this means working on buffers. if a user moves a large folder and undoes the move before it has completed, the original location of the folder should immediately return. behind the scenes, perhaps that folder was getting copied, not moved, so there is no need for the computer to have to move it back (see 40).
22. if an action cannot be undone, do not actually perform the action for thirty seconds or more. for example, when the user presses send on an email, do not start to send the email immediately, in case they realise straight after that they haven't attached an attachment, or have made an embarrassing spelling error. use common sense with this principle; an instant messenger, for example, should not wait thirty seconds to send a message as that would make it difficult to have a real time conversation.
23. humans make mistakes, so the user will make mistakes. accept that fact, and allow them to be dealt with gracefully (see 21). try to avoid making the user panic, as this will only lead to more mistakes.
24. humans make mistakes, so we the designers will make mistakes. we have a responsibility to carefully consider everything that could go wrong with our software, and come up with ways to inform the user about these issues, on their level. only use jargon related to the domain of the application: don't tell the user there was a type error if they're using a word processor. this example is particularly bad because type has more than one meaning, and one of those meanings could make the user erroneously think that their using the application caused the issue. only use relevant jargon, but don't dumb things down (see 24); learn to tell the difference between these two things.
25. do not patronise the user. assume every user is a competent human, even if they don't know how to use our software. software isn't natural and isn't intuitive; we can try our best to make it so, but there will always be something that someone doesn't understand, and they shouldn't think that this is their fault.
25a. don't ever force a tutorial or startup wizard on a user. make use of the universal help features in the system. consider every single thing someone might want to do with your software, and what they might call that. for example, modifying the margin sizes might be described as "making the margins bigger", "shrinking the margins", etc. have an extensive manual that is not necessary to consult, but is easy to consult when necessary (see 14).
26. the user is always right, even when they're not. if the user changes their mind, the computer should stop doing that (see 21, 22, 23). if your application thinks the user is wrong, let them know in a non-forceful manner. if they tell the computer they are not wrong, let it go. for example in an autocorrect system, the user should easily be able to add words to the dictionary. in fact, autocorrect systems should be avoided where possible (see 11, 120).
27. when something goes wrong, don't just tell the user things are broken (see 24). also tell the user what they can do next. tell them how to report the error to us. tell them how to restore their file, which should be in good shape (see 12, 120)
30. in the physical world, things can't teleport. we use animation throughout the harrison system to represent the relationship between different objects. iconifying a window shows it scaling down from its full size into an icon. feedback should be fast, and clear.
40. see {brain speed}.
50. progress bars are a difficult beast. really, the bar should move at a consistent pace. it is better to overestimate the time that will be taken and have it finish early (speed up to the end) than underestimate and have it slow down. where possible, they should be avoided.
100. try not to interrupt the user's flow of thought. if you must, make it clear that this will happen (see 40). do not show modal dialogues when the user opens an application, or when they close an application. do not make them wait when a program opens for updates to be installed. don't ask them if they want to save their work when closing an application (see 110).
101. the more modal dialogues we use when they are not necessary, the higher the likelihood is the user will simply click through them without reading them. the best solution here is to never show modal dialogues (see 100). that way, when we do use one, the user will pay attention to it.
102. the harrison system does not provide a way for applications to display intrusive notifications. the only thing they can do is notify when a task is completed (see 40). this system could be abused for notifications, which is why it is intentionally simplistic. do not use it to deliver a sub-par notification experience. the user should be able to focus on any single task, and choose for themself when to check our application (see 100).
103. alert fatigue is when the user becomes desensitised to warnings. this should be avoided, no exceptions. going against this principle increases the likelihood that the user does something they did not intend to do (see 120, 102, 101, 100).
104. if using a modal dialogue, ensure that the options are distinct. highlight the least destructive option that is most likely to be the one the user wants. do not use scary language in the dialogue, but make it clear what will happen. always provide an escape hatch afterwards (see 21). provide as few options as possible, according to hick's law.
105. if you use a modal dialogue, and one of the options is "yes", "okay", or "continue", the other option should be "no", "go back", or "cancel". "remind me later" should not be the only alternative, this displays a complete disregard for the user's consent. the window close button should do the same thing as the "no" option. if the user says no, you back off. (see 25).
110. the computer should deal with saving and filenames. in the real world, we can have two documents with the same title. this should be the case in our computer systems as well. abstract the underlying method of identifying files within the filesystem, so the user can name them whatever they want. if the user chooses to close an application without specifying a file name, use something that makes sense, such as the first line of the document, and let them easily change it at a later date.
120. the user's data should never be deleted, corrupted, or otherwise upset, without them telling the system to do so (see 70).
130. no modes. modes refer to systems of operation in which the same input will result in a different output. this can be confusing for the user, and often leads to errors, such as trying to input text while in the editing mode. as far as possible, modes should be avoided.
131. sometimes, a mode might be useful, in which case it should be clear it is enabled, and should be enabled for as little time as possible. one example of this includes the shift key on the keyboard, which changes what all keys do as long as it is pressed down, but defaults to off otherwise. another example is a help button, which changes the cursor into a question mark until the user presses another button, when it will return to normal and open a help window. another example is selecting text, which will highlight the selected text, meaning that when the user starts typing it will be replaced.
132. modeless operation is tied to noun/verb selection order. modal software encourages a verb-noun order, which can be userful for batch operations, but has two main problems: first, it appears slower for the user, because on deciding to delete something, nothing immediately changes (see 20); second, it causes more error for the user, because upon making the noun selection the verb is immediately executed. letting the user make the noun selection first means they can be totally satisfied that on executing the verb, they will immediately see the result of the intended action.
140. consider the computer to be "a bicycle for the mind". know what humans are good at, and what computers are better at. for example, computers are better at repeated tasks, tasks involving numbers, and remembering things (see 23). provide interfaces that let the user offload their weaknesses onto the computer.
141. humans are bad at multitasking, and can only consciously focus on one thing at a time. when your application is active, you should assume that it is that one thing. when it is not active, assume that is not, and don't do anything to try to bring the user's attention to it.
150. complex intuitive systems are made up of simple intuitive parts. a mechanical watch can be understood as a mechanical hierarchy which is ultimately just cogs turning cogs. start out with the simplest possible design, and work from there. this is gall's law.
151. note that "simplest possible design" refers to simplest possible for the user, not the programmer. it is the programmer and the system's job to take on the burden of complexity for the user. any solution will have a minimum amount of complexity, and it is your duty to take as much responsibility for that as possible. this is known as the law of conservation of complexity, or tesler's law.
200. consistency is golden. the look of your application should not be unique. the functionality of your application can be unique if that's what you're going for, but it should not stand out from the rest of the system. copy what everyone else is doing. don't do innovative design.
201. if you update your application to add a new feature, you face a dilemma: where do you add the new feature into the interface? you are inevitably going to have to move some interface elements around, which will frustrate your existing users, who are used to particular positions. you should try to find the best middle path here: don't resist change too much, but avoid change for the sake of change.
202. the people already using your application should be more valuable to you than people not using it. on the other hand, if someone is not using it and you think perhaps they should be, ensure that the reason they are not is because of any accessibility issues or other integral design decisions that you overlooked.
203. humans are much better at locating things based on where they are and what they look like, than by name. for this reason, we should allow users to position their documents flexibly, and change their iconic representation easily. we should not change those positions are visuals except at the request of the user (see 10, 11, 120).
210. if something is unlikely to happen, it is going to happen, so plan accordingly. alternatively, remove the possibility of it happening from your application.
220. the system should restore any task to the place where you left off.
humans operate on a principle of trial and error. in any situation, a person will decide what they want to do, work out a course of action that they believe will get them there, and act on it. if the action succeeds, it will reinforce in their mind the relationship between the outcome and the action.
it is assumed that someone using harrison will have two input devices:
- a keyboard.
- a single-button mouse.
it is also assumed that they will have at least one output device:
- a bitmap display. this is essential.
- a speaker. this can be useful.
the mouse is a two dimensional input method for a two dimensional display. this is a good idea.
harrison uses two shortcut keys, which for i will refer to as "app" and "com", short for application and computer respectively. app is most equivalent to the control key on windows and linux systems, and the command key on mac. com is more like the windows key. to be more specific, app is used for shortcuts within an application, whereas com is used for shortcuts that affect the whole system.
some shortcuts don't easily fit into either category, for example things like copy and paste. i'm not sure what to suggest in this case yet. whatever i decide, it must be consistent among all programs. in the case where an action can apply to both a program and the computer, the same key should be used for both shortcuts. for example, you can undo both a change of state in a program (app+z) and on the system, such as window placement (com+z).
the shift key is used to invert a shortcut, in the case it has an intuitive opposite. for example, if we were to put undo on app+z, redo would be on app+shift+z.
shortcuts are only assigned to the twenty-six latin letters. on the {gooseberry keyboard}, all other keys are accessed in ways that don't make them good shortcuts.