haiku/docs/user/uiguidelines/HaikuHIG.txt

Chapter 1: How to Design an Application Well

1) Determine the Target Audience

	If you know what general kind of application you would like to create, you also need to determine who the application is meant for. This can be as general as 'desktop users' to something as specific as 'Haiku Web Developers'. Knowing who the main users of your application will be allows you to make certain assumptions about what your users know. You can't necessarily expect a musician to understand how to effectively use a 3D modelling program as advanced as, say, 3D Studio Max.
	Depending on how concerned you are about details, you may want to create a user profile -- a fictional idea of an example user. This can be consist of one or two sentences or can be several paragraphs. A short user profile contains the person's first name, occupation, level of expertise, and what kinds of things they want to be able to do with their computer. One thing to be sure of is to make the user profile believable -- like a person you might know. In fact, when you design your app, it may be helpful if you know someone who fits into the target audience. You don't want to design you app for that person specifically, but, rather, someone just like them.

2) Determine Primary and Secondary User Tasks

	Please remember that the reason that most people will use your application is to get work done. Your users are not unintelligent, but, rather, very busy. Remember how busy most people are and how valuable their time is to them when you are designing your application.
	In order to make doing work with your program easier, you need to prioritize what kinds of work they will do in order of how often the work is done. Divide these tasks into primary and secondary tasks. Primary tasks are those things which the user does all the time. In a word processor, this would include typing in text, changing font sizes and styles, and adjusting margins. Secondary tasks are those which the user does occasionally.
	Notice that there is no mention of features that the user 'might' need to have. In order for your application to be as simple to use as possible, complexity must be minimized. One primary way this is done is by avoiding features which are used only in remote instances. Design your application to meet the needs of 80 percent of your target audience. With added features comes added complexity. Also, all the features which the user needs may or may not be required for the first version. Releasing a product often is good for business.

3) Construct a General Implementation

	Once you know what kind of person for whom you're writing your application and what kinds of things he will be doing with it, you will need to figure out the general way that the user will do it. This does not imply what the application will actually look like – just how they will be done. In a home finance application, one of the user's primary tasks will be entering in transactions. The user will need to type in the data for each transaction or download them from their bank over the Internet.

4) Devise the Actual Implementation

	The actual implementation of the application is determined last. Note that what technologies will be used to create the application have not been mentioned yet, and even now they are not discussed. Technology is the means to an end – a tool – and not the end itself. This is where the general usage of the application is determined. For example, the user will have a form to enter transactions into an account. The form should have text fields for each of the different kinds of data, such as the payee, the amount, and the check number. Somewhere nearby, the user will be able to see all a list of all the transactions in the current account.  Because this is where the actual building of the look of the program takes place, it is crucial at this point in development to know and understand what makes software truly easy to use, so this is what we will examine next.

Chapter 2: Qualities of a Good Application

	When it comes to software, the proof is in the usage. If a piece of software requires significant time to learn, the user will only invest the time in learning it if (a) the user has no other choice but to use that particular software and (b) the importance of the need filled by the software is much greater than the importance of the user's time.

Good Applications Focus on a User Actual Needs

	In Chapter 1, it was mentioned that your application should meet the needs of 80 percent of your target audience. It is impossible to meet the needs of all users in the same software and still retain some semblance of being easy to use. Sometimes a user doesn't even know that he needs or doesn't need a feature and it is up to the designer and developer to figure out what is needed. Most often, it is better to have a small collection of more specialized tools than one which does everything.

Good Software Uses Everyday Language

	Positions in Information Technology are almost always professional positions. One aspect which makes IT a profession is that it has its own body of knowledge and terms to go with it. Most people have only a rudimentary 'computerese' vocabulary, like the fact that the thing that they look at when at the computer is called a monitor or just 'the screen', that the little arrow on the screen is called the cursor, and that the thing they type with is called a keyboard. Few users know (or care) what a 'file format' is and fewer still do not know what an 'invalid sector' on a floppy disk might be.
	Good applications use regular language instead of technical terms. For file management software, 'volumes' are really disks – even though the term isn't quite accurate, a normal person associates a disk with 'a place you put stuff on'. Images are 'pictures'. A person doesn't 'kill' a application that has 'hung' - - he 'forces a frozen program to quit'. Details like this may seem minor, but many small improvements in a program's usability can have a profound effect overall.

Good Applications Do Not Expose Their Implementation

	Good applications do what they do in a certain way because it is the best way to be done, not because the code was written in a certain way. An example of this would be if a music composition program has a maximum song size because because the storage used for holding it can't store any more than that fixed size. The actual code written and the architecture used when it was written should have as little effect as possible on what the user sees and works with when using your software.
 
Good Applications Use Graphical Controls Properly

	GUI controls were meant to be used in certain ways, and when a program does not use them in that particular way, it is confusing to the user. Check boxes, for example, are commonly used in lists where a value can be turned on or off. Sometimes, however, they are used for choosing one option in a list. Radio buttons were meant for this task. Text boxes should not be used for labelling other controls. This might seem to be common sense for most, but, rest assured, there are many programs which do not do something as simple as this.

Good Applications have a Natural Layout to their Controls
	
	When performing certain tasks, people have a logical order that they follow, and good applications place their GUI controls in a manner that reflects this. When entering an address in the United States, the natural order is Name, Street and Number, City, State, and Zip Code. Following any other order would not only frustrate the user, but it would also lead to more mistakes in entering the proper data.

Good Applications Give Plenty of Feedback

	Picture this: you have just started changing the format of a movie file. You hit the button marked 'Go' and wait... and wait.. and wait. Nothing seems to have happened. Did something go wrong? You don't know, and the reason you don't know is that the program didn't tell you what it was doing. Everything was going well and was just taking a while. Good software does something that effective people do – communicate well with others. Good feedback means making sure that the user knows what your program is doing at any given time – especially if the program is busy doing something which prevents the user from doing anything else in your program. CD and DVD burning programs tell the user how much is left before they are finished making a CD or DVD. File management programs tell how many files are left to copy or move.

Good Applications Make Errors Hard
	 
	It should be difficult for users to mess up. If, for example, the user needs to enter in some text and certain characters are not allowed, then disable those characters for the text box it needs to be entered in. Build constraints into your application which prevent errors. This would be why 3 ” floppy disks have a notch in one side – it can be inserted into a drive only one way.
	
Good Applications Handle Errors Gracefully

	It is impossible to make an application entirely foolproof because fools are so ingenious, but it is possible for a program to handle errors in a way that doesn't leave the user wondering what happened. When code is written, errors of all sorts need to be anticipated and handled, such as lack of memory, lack of disk space, permissions errors, and loss of network connectivity. If an error condition can be forseen, it needs to be compensated for. Doing so greatly improves the perception of your software by the outside world. Crashes are unacceptable in all cases. Error messages, for example, need to describe in non-technical terms what happened and suggest what the user can do to remedy the situation. In the worst case, the program needs to provide an easy way for the user to send technical information about the problem back to you via e-mail or some other means. In all cases, the user's data is to be preserved.

Good Applications are Forgiving

	Computers are excellent tools for people because they are good at many things that people are not. From a perspective which focuses on technology, humans are imprecise, illogical, disorganized, and make mistakes frequently. They are, however, excellent at forming habits and matching patterns, two things computers have a difficult time doing. Make commands undoable whenever possible and when it is not possible, be sure to inform the user that such is the case.

Summary

	Good software takes genuine effort to produce. It is not for the stereotypical “lazy programmer.” However, in creating something of significant value to customers, good software creates a positive image for a company and loyal customers who will do your own advertising for you.


Chapter 1: How to Design an Application Well
	Target Audience
	Primary and Secondary User Tasks
	General Implementation
	Actual Implementation

Chapter 2: Qualities of a Good Application
	Forgiveness
	Implementation != Interface
	Focuses on User Needs
	Use of everyday language
	Proper use of controls
	Natural layout of controls
	Difficult to make errors
	Proper error handling
	Plenty of feedback

Chapter 3: OS Conventions
	Settings / Preferences
	Responsiveness / multithreading
	Translators
	Live Updates
	Queries
	Attributes
	System Tray
	MIME handling
	File picker
	Message Handling
	File extensions
	find_directory()
	ui_color
	font sensitivity

Getting Input from the User
	Mouse vocabulary
	keymaps
	Keyboard accelerators
	Focus locking
	Keyboardability
	Conventions for choosing accelerators
	Fitts' Law

Drag and Drop
	What is it
	Appropriate use
	drag feedback
	drop feedback
	clippings
	Use of drag handles
	Replicants
	BShelf

Use of Text in the GUI
	Labels
	Controls
	Use of Fonts
	Error messages
	Ellipses
	Colons
	Capitalization
Icons
	Conventions
	Designing a good icon
	Packaging an icon
	Recongnizability

Cursors
	Predefined
	Use of
	Animation

Menus, Menu Bars, and Menu Fields
	Grouping of items
	Titling / Naming conventions
	Use of submenus
	Use of marked items vs toggled names
	Explanation of common menus and their contents
	
Windows
	Modality
	Appropriate use of styles
	Placement / positioning
	Resizability whenever possible
	Use of Alert windows
	Good window titles
	Minimizing / Showing
	Resizing / Moving / Zooming
	Use of B_ACCEPTS_FIRST_CLICK
	Scrolling (automatic and manual)
	About window design
	Find windows
	Preferences window design
	Open / Save panels
	
Controls
	Radio Buttons
	Buttons
	Checkboxes
	Control Groups (BBox)
	Sliders
	BTextControl / BTextView
	ListViews
	Tabs
	Scrollbars
	Color Pickers
	Progress Meters
	Toolbars

Installation and Updates
	Zip files
	SoftwareValet packages