Slashdot Mirror
A Good Style Guide Under the Creative Commons?
eldavojohn writes "I've been charged with making a specific user interface style guide for a suite of software by my employer. I'm not quite sure where to start. So I turned to my favorite search engine only to be brutally disappointed with what is out there to help me. I'm a software developer but have not had any formal training in UI design or look and feel. I'm looking for something more than just "keep it simple, stupid." I'm looking more for something that is specific but not technologically dependent. This doesn't have to be a global standard, merely a document that illustrates how one would effectively describe look and feel. Does anyone know of such a guide either created by an organization, government or company for their own uses — possibly one even released under the creative common license?" In addition to just documentation, what other UI advice can Slashdot readers offer in order to ensure quality development?
Kevin Smith on Prince
Macintosh develop site has several well put together style guides for software development that you should look at. Check out the Apple Human Interface Guidelines. Apple may not be your cup of tea but they always have good ideas and have a well put together interface and this will DEFINITELY give you a good idea where and how to start.
This is my sig. There are many like it but this one is mine.
Read the Apple Human Interface Guidelines, ideally a version from before OS X when they weren't trying to merger MacOS and OPENSTEP HCI principles into a coherent framework. They're well written, contain rationales for most of their descriptions and full of examples.
I am TheRaven on Soylent News
GNOME HIG
http://library.gnome.org/devel/hig-book/stable/
Apple's HIG
http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIntro/chapter_1_section_1.html
Better yet, hire a consulting company from India. They'll help you out.
Different brains are wired for different things. A good programmer is rarely a good designer and vis versa. This was dictated at conception by how we are hard wired. There are somethings in life that will always be outside of each of our abilities. It's best to recognize this and hire someone who excels where you lack.
Know the author Ed Tufte.
Know what HCI stands for.
Know your audience and let them evaluate Throwaway Prototypes.
If you are looking for a book to teach you UI design, you are misguided. If you are looking for a Creative Commons and/or Open approach to UI design, register a domain called "Principles of UI Design" and launch a Wiki on it, then license it with the license you desire (but I would recommend CC0).
If all goes well, this thread will serve as a good starting point for getting ideas/content to populate your new Wiki with.
Support the 30 Hour Work Week!!!
I guess thats one way of band promotion - get a front page story on /. with a direct link to your mp3. How're those servers doing again?
Pretty much every platform (in this case, I'd count GNOME and KDE as 'platforms') will have a set of Human Interface Guidelines that will give advice on how to craft a usable interface that meshes well with native applications and provides a solid user experience. There's no one hard-and-fast style guide, though there are lots of examples of what NOT to do if you Google (see the User Interface Wall of Shame for one).
I've been charged with making a specific user interface style guide for a suite of software by my employer. I'm not quite sure where to start
You don't know where to start because you don't work as a tech writer!
Tell your tightwad boss to pick someone more suited to the task - Even the weenies in Marketing can probably do the task better than an engineer (unless you just happen to have a background in technical writing, but it sounds like that doesn't fit into your job description/requirements).
Geeks can do anything - That doesn't always make us the best person for every job even tangentially related to "computers". If you want me to design a website, I can make it do anything HTML supports, but prepare for a color scheme that makes most people's eyes bleed...
Some of the best input you can get is by giving the software to someone completely unfamiliar to the project, and ask them to accomplish 6 objectives that require them to navigate the application's interface. Ideally, you'll want them to be able to successfully complete those objectives with a minimal amount of time and hassle searching for the proper way to accomplish it. Have them identify trouble spots they ran into (icons confusing, unclear menu structure, etc). After reading over the input of uninitiated testers, you can fine tune your interface to be more intuitive.
I suffer from the problem when coding that I put menus and icons in places where *I* know where to find them, and that make sense to me. The problem is, I know the code from the ground up, so I know exactly what I'm doing - a huge bias compared to a new user who is trying the application for the first time.
Essentially, if your computer illiterate mother can figure your menu structure out, you are golden. A lofty goal that you'll probably have to cut some compromises into, but essentially the point is to keep it simple and make sure you account for your target audience.
In addition to just documentation, what other UI advice can Slashdot readers offer in order to ensure quality development?
Do you mean "quality development" as how to develop of some sort of measure of quality, or do you simply mean development that fails to suck?
"I'm a software developer but have not had any formal training in UI design or look and feel."
That would make you the perfect Microsoft employee.
I would suggest going out an getting a book on Interaction Design, such as that by Sharp, Rogers, and Preece. If you look over the diagrams and the chapters you should get the gist of it. This book is used in introductory graduate Human-Computer Interaction courses.
A Great Brochure from Humanfactors.org is here:
http://www.humanfactors.com/downloads/guistandards.pdf
Page very close attention to page 14. It describes your situation as "Pitfall #4." And it's right.
Ed R.Zahurak
You know, oblivion keeps looking better every day.
Choose a curly brace style and stick with it! Oh, this is UI styling we're talking about...
Try this HCI web comic, I don't think it is updated anymore but there's lots of great archives:
http://www.ok-cancel.com/
Reviewing just the first hour of video games.
Unless the software suite is the only thing the user is going to see, and not the underlying OS or any other software, you should just follow the guidelines for the OS or desktop environment. Otherwise, you get a schizophrenic result that clashes with everything else, leading to user confusion and frustration. If you're designing from scratch, I suggest reading Raskin's "The Humane Interface," and using that as a baseline. Don't read the Apple user guidelines. Unless you're used to a Mac, they don't make sense.
Slashdot: Playing Favorites Since 1997
Have fun!
Mike O'Donnell http://people.cs.uchicago.edu/~odonnell/
Signed,
Chester W. Lampworth
President and CEO
Amalgamated Manure, Inc.
Just pretend you are the user you are writing for. If you have no idea what that type of person is like, find someone that does (sales, marketing, actual customer, etc).
Ask your self (or the other person), "What do you want to do" (over and over again, in different contexts). There are so many times we get wrapped up in the technology to create a solution that we start to build the UI based on it. The UI should be based on the desires/needs of the user. Why else would the software be developed? Taking this stance, when done with honesty, will usually lead to a simple and practical design.
This can get complicated as you may assume the role of a new user, and then someone that's an expert. Or someone that bought the software because they wanted it vs someone that is going to hate it just because their boss told them they need to use it. They will have different needs, that tend to contradict (simplicity vs configurability for example).
Sometimes it's quickest to start with pen and paper. Easy to create, easy to throw away, save what you need by scanning it in, then use that as the starting point for coding the UI.
If that's still too much of a challenge, involve other departments (QA, Tech Support, Documentation) and get their input. As far as "design guide", there are obvious conventions being used... follow them. Don't use checkboxes like radio buttons, don't use drop-downs to open a dialog box, etc.
If you get stuck in an area, start opening up interfaces from other software that has something similar and see how they do it. Then ask yourself if how they did it is "correct", or best, for your customer(s).
Good Luck!
... and ignore everything that they do.
Then work with real users and find out what they want the app to do, how they want it to do it, and assess what their knowledge and skills levels are. In all likelihood you are entirely the wrong person to judge what's appropriate for end users.
Three Squirrels
I strongly recommend this link: http://www.welie.com/
This is a collection of design patterns for creating UI.
I was extremely impressed by this work already 8 years ago when it was presented in PLoP2K http://jerry.cs.uiuc.edu/~plop/plop2k/proceedings/proceedings.html but since then it became much much bigger.
8. Single data entry. Sometimes this happens without thinking, but if you blow it badly, it creates havoc. Each piece of information required from the user should be entered precisely once in precisely one context (per interaction---the context can be different depending on what else the user has done, but it shouldn't vary according to accidents of the program execution). Every sufficiently complex system starts to drift away from this principle, so that a single change requires a user to hunt down several different entries of that change, which nobody can do consistently correctly. Then, it is outrageously hard to find the particular wrong entry that's causing a particular problem.
Of course, this doesn't rule out independent re-entry for the purpose of consistency checking, such as the re-entry of a password. But that sort of re-entry needs to be followed immediately by a consistency check and correction.
Mike O'Donnell http://people.cs.uchicago.edu/~odonnell/
This is not directly a style guide, but a Federal (US) usability guide. http://usability.gov/pdfs/guidelines_book.pdf
Hopefully this helps.
I had the components in the wrong order:
http://en.wikipedia.org/wiki/Model-view-controller
I'm pretty sure that someone wrote an article on the need to combine view and controller. I may be able to look in up on Monday.
Mike O'Donnell http://people.cs.uchicago.edu/~odonnell/
This book is a great read, though I have version 2.0, not sure how 3.0 compares:
About Face: The Essentials of Interaction Design
http://www.amazon.com/About-Face-Essentials-Interaction-Design/dp/0470084111/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1204319582&sr=8-1
http://www.amazon.com/About-Face-2-0-Essentials-Interaction/dp/0764526413/ref=sr_1_3?ie=UTF8&s=books&qid=1204319582&sr=8-3
Homebrew Science: http://homebrewscience.com
My employer recently adopted Sun's standards. They posted them here: http://developers.sun.com/docs/web-app-guidelines/uispec4_0/
I'm a software developer but have not had any formal training in UI design or look and feel. I'm looking for something more than just "keep it simple, stupid."
Then your proper response is, "Are you sure you want me to do this? I have no training in this area."
And put it in writing as a CYA.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
Everything you need is right here.
You need to read up about Human Computer Interaction.
Also, the guidelines for a web application or mobile application will be different to that of GUI application.
You should read up about accessibility, should your application be used in government organisations then it may often need to be able to be used by people with eyesight or mobility defects.
Important points, never rely on colour to differentiate things. Not everyone has reliable colour vision.
Involve end users where possible.
Read Jacob Nielsen's opinions, don't take them as gospel but he does have some good points.
http://www.useit.com/
Stick to the guidelines of the OS you are developing the application for. Use common well established key shortcuts.
This is the best website on design that I've found: http://webdesignfromscratch.com/
For searches like this, don't use Google or other search engines like it. Search people's bookmarks. http://del.icio.us/search/?fr=del_icio_us&p=design&type=all
I've had no formal training in GUI design either, but I've found that making a few useful scenarios works pretty good (although it takes a bit of time).
To do so, try to imagine a few "typical" users for your application, and go down to enough details about them, until you have a clear image of their personality. It's pretty hard to do first (sounds easy, until you actually start writing stuff down, then you block).
The idea while doing this is to come to different aspects in usability, not in features. That would allow you to (hopefully) come to a good understanding of which tasks are most important and how to prioritize them.
I believe Joel Spolsky described this method at some point but I'm too lazy at the moment to search for the link.
Tie two birds together: although they have four wings, they cannot fly. (The blind man)
The Fluid Project is just getting off the ground, and it is focused on higher ed, but their wiki might be a good place to hang out, if you want to talk to serious HCI geeks. I've talked to some folks at conferences about it, and they have some hardcore research components to their work - you know, users, and researchers, and people writing down what happens :-)
From http://fluidproject.org/ ---
"Fluid is a worldwide collaborative project to help improve the usability and accessibility of community open source projects with a focus on academic software for universities. We are developing and will freely distribute a library of sharable customizable user interfaces designed to improve the user experience of web applications"
If you're interested in the theory and understanding good interfaces: The Design of Everyday Things by Donald Norman The Inmates Are Running The Asylumby Alan Cooper With those books in mind, *then* use the HIGs :)
~Lee
Not quite a classic like the Apple material, but the Motif style guide is likely to be helpful: http://www.opengroup.org/pubs/catalog/t254.htm
Cyrano de Maniac
It gives a good case for why YOU shouldn't be writing User interface guidelines and why a design specialist - who is a stakeholder and needs to own the project - should be.
The Design of Everyday Things is a great book, considered a classic. It covers basic things like doors and telephones more than GUIs, but it helps you think in the right direction.
One principle that stuck in my mind is that you should make things as obvious as you can - if you've got four heating elements on a stove, arranged in a square, then arrange the knobs that control them in a square and it's obvious how it maps. If you put the knobs in a straight line, you have to label them and the user has to stop to read the diagram.
A second principle is that you should make the penalty for screwing up as low as possible.
Imagine the worst possible user interface: it's easy to click the wrong button, and clicking the wrong button does something disastrous. Now strive for the opposite: it's obvious which button is right, and clicking the wrong one doesn't do anything that can't be easily undone.
Easier said than done, but just imagining the good design makes me feel less stressed.
IBM has a great checklist for Accessability of different UI implementations (web, app, lotus notes).
http://www-03.ibm.com/able/guidelines/software/accesssoftware.html
Understanding Accessibility
If you are new to accessibility, review "Understanding accessibility" before completing the checklist or contacting the Human Ability and Accessibility Center for help.
IBM software accessibility checklist
Use this checklist for:
* general software products and applications that have a user interface
* software tools, this applies to both the user interface as well as the output of the tool
* Java 1.1.x applications that use standard AWT components and are designed to run only on Windows platforms
* software used by system administrators to control and monitor servers or other remote equipment
* Eclipse applications written with Standard Widget Toolkit (SWT) controls. Note: SWT controls do not use the Java Access Bridge.
* software with a command line interface
Last updated May 28, 2003. Techniques pages, accessed via the link in each checkpoint, may contain more recent updates. Be sure to review the techniques pages for the latest accessibility guidance.
Perspective is to Science what Interpretation is to Religion. Obama + Paul FTW
I found the Tango Icon community when I needed to develop icons for my application. I joined the mailing list, and they always have good suggestions about style. A lot of the design principles they talk about transcend icons. Even though I don't have any formal training in UI design either, I have picked up a lot of tips on how to give the UI a systematic, cohesive style.
I highly recommend Spolsky's User Interface Design for Programmers as a place to start. It's short and to the point, with about a dozen guiding principles to make your UI practical. It's a light and fast read, yet substantial enough to get you off and running.
Democracy is two wolves and a sheep voting on lunch.
"Know the author Ed Tufte."
I like Tufte for his arguments against using PowerPoint. His own works are mostly about using images to display information well. While some important HCI topics are covered, finding the few critical points would be much work for someone with an immediate need to create a guide for interfaces.
"Know what HCI stands for."
Much good information can be found with much less work by reading the free materials from the organization that certifies HCI professionals:
http://www.humanfactors.com/
The only other certification requires a Masters degree in the subject, at which point another certification is pointless.
"Know your audience and let them evaluate Throwaway Prototypes."
Your audience is human beings. Dividing any further is an excuse for allowing poor interface design.
"If all goes well, this thread will serve as a good starting point for getting ideas/content to populate your new Wiki with."
I have two rules for good UI on my website (which needs better organization and will be fixed later this year):
1. Make every function as obvious as possible.
2. Require the least action for every function.
Many interfaces hide functions with menus, tabs, and dialog boxes. The functions are hidden, and activation requires more than one click. Some programs even show functions that cannot be used. (Photoshop has so many options that hiding some is almost necessary, yet still shows actions that cannot be used at the moment.)
The third rule should be to minimize the probability of mistakes. Many environments have dialog boxes with "OK" and "Cancel" buttons very close. Buttons should be explicit. Damaging actions should be separated. All options should be allowed.
Firefox is better than most programs and still violates these rules. If you attempt to close a window with multiple tabs open, the buttons are "Close all tabs and this window" and "Cancel - Do not close any tabs" (italics added for missing text). No option is presented for the most likely desired option to "Close the current tab".
These three rules cover every situation. More guidelines are useful for consistency, such as
- The expected action is always first and has a green background.
- Other actions may follow with yellow backgrounds.
- Cancel and other destructive actions are always in the bottom-left at least 20 pixels from other controls and have a red background.
I spend my life entertaining my brain.
Author: Platt, David S.
ISBN: 0-321-46675-6
Get it and read it.
And ye shall know the truth, and the truth shall make you free.
John 8:32(King James Version)
1) All buttons need to have an accurate and useful tooltip
1.5) ALL AREAS AND MENUS must respond correctly when F1 is pressed, jumping to the application help file's main screen is not correctly, jump to the relevent area
1.75) the help file must be up to date, always, NO EXCEPTIONS
2) nothing done more than once per day shuld be more than 2.5 clicks away from where the user will normally be when it needs to be done.
3) pauses for sub menus to open automatically count as half a click
4) pauses for a subment to open from withing an existing submenu(such that moving the mouse will close the parent menu) that opened the same way counts as 500 clicks
5) use environment and industry standard keyboard shortcuts wherever possible
6) flay any employee who implements a function which can destroy or fail to save data on any single F-key or any standard keyboard shortcut (i.e. ctrl-c to CLEAR, ctrl-z to CLOSE, F1 to return to home screen)
What are you drinking, water?
I don't want to sound negative but (and assuming this is a commercial gig) you may need to get someone who knows how to design UIs in to do the job. After all, would you hire a HCI specialist to produce C code? It's good that you want to learn about UI design (and best of luck), but it's a surprisingly large area with lots of work being done (even so called specialists aren't aware of the research that goes on).
Reading books and style-guides is a start but then so is employing programmers with a basic certificate in programming. If you had some difficult coding to do, would you employ a UI designer who had read a dummies guide to C to do the job?
bang goes my karma... again...
If what you're doing is something fairly standard, and user interface isn't a big selling point, then
- use standard controls and designs from your operating system
- copy the best parts of other similar applications
- think hard about how the user uses it and make it as smooth as possible for those cases.
- be tidy.
- use a few nice graphics sparingly.
Most business apps fall into this category and just following the basics will make a reasonable app, but nothing world-beating.
If you are doing something for which the user interface is really important (e.g. ipod - done before, but the user interface made it better than the rest), then you also have to get a lot smarter
- am I going to break some conventions to make it better than the standard approach?
- should I do skinning? This will attract some users and repel others, but is often added because the developer thinks it will be fun. Not the right approach.
- do lots of research and testing into how the users use your app and similar apps.
- experiment
For every expert, there is an equal and opposite expert. - Arthur C. Clarke
Look into whether you can side step the whole design thing by
Your initial job would be to build a rudimentary interface and a toolkit that would allow each user of the software to skin it the way they think would work best. Long term maintenance would include adding extensions to the toolkit that would be driven by user requests.
You would want to recruit a few users to help with debugging the initial toolkit and setting up the default interface.
Handle this right, and the traditional users' resistance to change could be morphed into an enthusiastic buy-in on the project before it is even out the door. An annual award, like a couple of extra days off, to the user who is voted Most Valuable Contributor by his peers could be an inexpensive way to get things started and keep things going.
If you take this idea to your boss, I'd be interested in hearing his response.
I'm not sure on following Apple's guidelines. Some of their stuff is great but some of it really sucks too. They have a hit and miss record with usability.
What I might suggest is to design so that the UI is loosely coupled so it can easily be switched out as needed. Better than trying to make one universal perfect interface is to create one simple interface with the ability to create alternates easily. Then if you need a console based or text-based interface (say for a blind employee) it's easy to do without confusing your existing users. If you need to make a more advanced interface for admins it's easy to do. There is no one interface to rule them all.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
I'm sorry, but I don't understand something here...
Why would the research for this style guide have to be in the Creative Commons?
First of all, unless you're going to be copying and pasting the actual text of the research style guide into your own document, the copyright law regarding the research style guide is irrelevant. You can't copyright an idea, so if you see a good idea in a copyrighted book and you want to use it, there's nothing stopping you (at least on the copyright end - patent law is a much different animal, but that has to do with what the people following your guide have to do, not what you have to do).
Seriously, for this sort of thing, just figure out what's the most intuitive and write it into your document. So long as it's in your own words, you'll be fine.
Robert B. Marks
Author, Demonsbane in Diablo Archive
I'm possibly gonna be moderated "Funny", but the Vista guidelines are well done IMO.
____
nico
Nico-Live
I have a feeling that 99% of the replies here are misundertanding something crucial. And so is your employer, and so are you. (OK, so it's more likely I'm the one who doesn't understand. But hear me out.)
First off, what is a style guide?
Here's how I would define it.
A style guide is a document which prescribes standards for subjective matters of presentation, which are to be followed for material created within a specific framework. For example, the material might be written articles for publication in a newspaper. Or the material might be programs created to run on an OS, or with a GUI or application framework. Or C language source code written to be read and modified by a programming team.
A style guide's purpose is to enforce consistency among material created by multiple parties (or one party over multiple sessions). This consistency is for the benefit of the end user, not necessarily the creators. And the style guide is for use by the creators, not the end user
A style guide governs presentation, not content. Grammar and article length, not viewpoints or what gets discussed and what doesn't. How a pushbutton looks and behaves, not how it gets drawn on the screen. Code indentation and naming, not what the program does.
A style guide does not prescribe standards that are enforced elsewhere. It doesn't tell writers to properly end their sentences with punctuation, because that's a rule that applies to all writing. It doesn't say that scrollbars in a GUI should not be placed at 45-degree angles, because the GUI API provides no means to do so anyway. It doesn't say that curly braces must be balanced, because the compiler will catch that anyway.
A style guide is the sole authority on the issues it covers. If an issue within the domain of the style guide is not governed by it, then there is no rule on it.
A style guide prescribes standards as the preferred choice among various possible options, none of which is objectively correct or incorrect. The standards take the form of "for such-and-such, do it this... way, not that... way. There are some who do it that... way, but we do it this... way because such-and-such."
A style guide can not be legitimately created by someone who doesn't define the standards in it, and have the authority to decide what to prescribe.
So, if your employer is asking you to make a UI style guide for their software, there is a basic issue that you haven't explicity made clear:
Does this software provide a framework for creating material that should conform to some standard? You say you are creating a user-interface style guide, so is it a user-interface creation tool (or something that allows external components with their own user interfaces)? If that's not what your software does, and the user-interface you're referring to is something that your software uses, rather than provides, then your company is in no position to create a style guide (that is, define standards) for it. Whoever created the GUI (Windows? Mac? QT?..) has already done that, and chances are they've published it, and your software engineers have been following it. Any attempted style guide would be merely descriptive, not prescriptive. It would say "for such-and-such, our software does it this way...", possibly even while the actual standards say to do it that... way.
Now if your software is in fact a UI-creation tool and it's already been created, then allthe content that needs to go into your style guide is already in the heads of, or has already been written by, whoever created the software. You know who to talk to.
And if the software is UI-creation tool but you're still at the design stage, then what you're being asked to do is actually create the standards, not just write a document. Your employer is asking you, a software engineer with no UI expertise, to define the rules which all of your customers, as software developers, will be mandated to follow, and which will in