Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

A Good Style Guide Under the Creative Commons? 131

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?
This discussion has been archived. No new comments can be posted.

A Good Style Guide Under the Creative Commons?

Comments Filter:
  • I'm looking for something more than just "keep it simple, stupid!
    Try 42. It doesn't get much simpler than that.
    • Re: (Score:2, Insightful)

      by BigJClark ( 1226554 )

      I dunno, it took over 7million years and the second greatest computer of all time to come up with that answer.

      Doesn't seem overly simple to me.

      quack quack.
  • by Foofoobar ( 318279 ) on Friday February 29, 2008 @04:18PM (#22604466)
    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.
    • by JustinOpinion ( 1246824 ) on Friday February 29, 2008 @04:56PM (#22604980)
      Since the original poster seems to prefer permissive licensing, he should also check out the GNOME Human Interface Guidelines 2.0 []. It's an extensive set of best-practices and guidelines, licensed under the GFDL. Thus he can tailor the guidelines to his needs and redistribute them without worrying about copyright issues (another poster suggested setting-up a wiki for his users, which could also work).

      The KDE Usability Guide [] also has some good material, although at this time it looks much less mature than the GNOME docs.
      • by try_anything ( 880404 ) on Friday February 29, 2008 @08:49PM (#22607058)
        OSX, GNOME, and KDE are all very usable environments, but style guides mostly tell you how to achieve consistency with other applications on the platform. If the OP is really asking for a style guide of this kind, he needs to tell us what platform he is developing on. Using an Apple style guide to create a Windows program will result in a less usable design, even if the Apple guidelines are superior to the Windows ones.

        For an introduction to UI design, here are some good resources:

        • Addendum to explain my reasoning, in case it wasn't clear why I was dismissing the question as stated. The interest in permissive licensing is fishy. If he indends to quote significant chunks of a style guide for the wrong platform, then it's a very bad idea. Plus, there's ALREADY a style guide for his platform -- if he's working for any major desktop platform -- and it would be redundant to quote it. He can just tell his coworkers to go read the damn thing, and he can provide a project-specific appendi
        • I'll second the recommendations for "The Design of Everyday Things" and "Tog's First Principles of Interaction Design" as I've found both to be solid and helpful for avoiding some of the biggest pitfalls. I bought a copy of the former and put it in my previous company's engineering library and it has been read by almost everyone by now. I also would like to echo try_anything's recommendation that you look at the style guide for your particular target plaform(s) unless you are coding an interface for somethi

    • The Apple Human Interface Guidelines were based on the Human Interface Design Principles defined by Bruce Tognazzini. They have stood the test of time.

      These principles include the use of Metaphors, Modelessness, User Control, Direct Manipulation, See-and-Point, Consistency, Feedback and Dialog, WYSIWYG (What You See Is What You Get) Forgiveness, Perceived Stability and Aesthetic Integrity.

      Additional considerations include Knowledge of Your Audience, Worldwide Compatibility and Universal Accessibility. You c
    • 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 withou
      • console and text based software in mass use is not common and does not require a style guide per say; it requires more of development guidelines and standards (ie use tabs instead of spaces). Don't confuse a style guide with development guidelines. One is for graphic interfaces and the other is for coding standards (including CLI).
        • by MikeFM ( 12491 )
          It's less a recommendation for style guidelines than it is a reminder to not rely entirely on style guidelines. As always the nicest UI in the world won't help you if the underlying software sucks. To many programs are badly designed and tightly bound to their UI.
          • One simple acronym... MVC
            • by MikeFM ( 12491 )
              Sadly, most code, that isn't mine, that I've had to work with just mushed everything all together. It's one of my pet peeves about open source code as a lot of smaller projects are really badly written. Of course most closed source code I've worked on was just as bad. I swear that schools must crank out CS majors without teaching them to actually code things properly.

              The worst is people who think of themselves as web programmers. There is often no separation of logic at all. Of course if you're going to cra
  • 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.
    • ideally a version from before OS X

      Say what? I don't like OS X, but it's a vast step up from prior versions. Before X, Mac OS was a clusterfuck of bad usability. Now, it's at least passable. Why would you follow any version before OS X? Serious question.

      • I'd take OS X over a previous version any day, but strictly in terms of user interface, previous Mac OSs were better. The finder actually was a graphical representation of the the disk - you didn't have multiple windows with the same files appearing in it, for example. It always remembered where you placed icons, your view settings, etc. OS X violates many of Apple's own interface guidelines leading to the mess that is the current Finder. Things like file sharing were trivial to set up with simple fine-grai
    • Leaving aside the non-responsiveness of your suggestion, do you seriously mean to infer that Leopard usability is inferior to MacOS9? We've matured 7 years since MacOS9 was introduced, and the old dog just don't hunt no more. Perhaps you are suffering from delusive influence of the golden glow of reminiscence?
      • Leopard usability as a whole, no, it's not worse. There are a lot of features in Leopard that are really very nice and that I miss when I have to use any other OS. That said, the HIGs are a complete mess. They are full of inconsistencies (although much better than Tiger, where they couldn't work out where the various different themes should be used) caused by the fact that OS X is trying to integrate classic MacOS and NeXT UI principles. The MacOS 8-9 HIGs are relatively complete, consistent, and simple
  • by ruyon ( 660897 ) on Friday February 29, 2008 @04:19PM (#22604480)
    How about taking a look at these well-known samples?


    Apple's HIG

    • Re: (Score:2, Interesting)

      by Anonymous Coward
      Not that anyone will ever even see this since the new Slashdot comment system doesn't even show anonymous comments, but...

      The GNOME HIG is, in fact, licensed under the GFDL, which effectively meets the Creative Commons request. It's definitely a good place to start.

      But when using those, remember they're tied to the individual desktop. Things that are standard under GNOME and Apple are reversed under Windows. (For example, Windows always uses "Yes/No/Cancel" while both GNOME and Apple recommend using action
      • I saw your anonymous comment.

        WTF are you talking about?

        I don't agree with your statements. Gnome is not an OS, it is more of a GUI shell for the OS that has interoperable programs that pull look and feel from the shell. Like a lot of software does on a lot of differing platforms. The thoughts outlined in the HIG can be translated by any intelligent person to fit their needs. The poster just needed an idea of how to proceed, and the HIG does an excellent job of providing a jump point.

    • by ajs ( 35943 )
      Yes, the Gnome HIG is really quite nice. Props to Sun for all their work on it!

    • Re: (Score:2, Insightful)

      by Ox0065 ( 1085977 )

      My only comment would be that:

      The introduction of the Gnome HIG brought about substantial stripping of functionality out of gnome.
      It's heavily tailored toward lowest common denominator computing. It does make flexible & robust GUIs.
      They just don't do anything you want.

      ... (^-^)

  • I'm not quite sure where to start.
    Start by hiring a consultant
  • 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.
    • This is exactly right. I know of very few engineers who are also talented artists. When it comes to UI, you need both; the artist should come up with the general look and feel, and the programmer should add the functionality within that framework. Usability goes up at least 200% when the program is made to be good looking.

      However, that's not to say that programmers are any less important. 200% of shit is still shit, and every UI requires some functionality behind it. Artists generally won't know how to
      • Re:Hire an artist. (Score:5, Insightful)

        by neurosis101 ( 692250 ) on Friday February 29, 2008 @04:55PM (#22604962)
        I almost never post on /. but seeing this I can NOT pass up.

        Creating a good interface is about FAR more than just pretty pictures. An artist might make it look good, but looking good and being functional are not related in any way, shape or form. I've seen art houses produce UIs that were illogical and violated many basic UI principles but look nice. The worst part is your client will fall in love with the looks without thinking about the damage that is being done.

        If you are going to bring in outside sources, there are art houses that have specific UI design experience. You should make sure you engage one of these. Or come up with a design, then have the art house make it look nice.

        Real UI design is about user cases, apprentice-master relationships, and other things 99.9% of artists don't know anything about.
        • by iceco2 ( 703132 )
          Assuming you are working for a reasonably large company, I believe
          you should consider developing/hiring in-house talent.
          I have had some experience with out-sourcing UI design and I discover
          this usually works well on the small scale, When I have a specific screen which
          performs specific tasks and I want someone to select widgets for me, place them on the
          screen and put some nice colors and art around them an external UI-design company could do a good job. But there are many UI issues that require a much in dep
      • Just to be clear, there is a different between being a talented artist and a talented designer. I am a student who has took classes in interface design and I have noticed a recurring theme. We always want to separate content from design, if not physically then mentally. I find it helpful to sit down and make a list of all of the important features that a person would need access to at this 'state' in the interface, and when the user needs more detail, he proceeds down to the next 'state' in the interface.
    • by Hatta ( 162192 )
      Different brains are wired for different things.

      And because of this, one size does not fit all when it comes to UI. Always, always, always separate your actual functionality from presentation, so that people can implement and use the UI that fits them best.

      Personally, I find apps like Rasmol, Gnuplot, and R to have the finest UIs available. Which is to say they only use graphics when absolutely necessary and everything else is done through a command line. I just find the language metaphor a more compell
  • Some suggestions (Score:5, Informative)

    by RobBebop ( 947356 ) on Friday February 29, 2008 @04:27PM (#22604590) Homepage Journal

    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.

    • by Knuckles ( 8964 )
      If you are looking for a book to teach you UI design

      To teach, maybe. But there are several good and useful books, such as Designing from Both Sides of the Screen [], Observing the User Experience [] (well that's more about your user testing), and others that are at the office and which I can't remember right now.
    • by Rhalin ( 791665 )

      Know the author Ed Tufte. Know what HCI stands for. Know your audience and let them evaluate Throwaway Prototypes.

      Great starting points here. The audience one is a massive factor.

      For instance, are your programs for designers, artists, programmers, office workers, etc? Different groups tend to use applications in different ways. They've also been exposed to different styles of UI design. An important factor is often not to "surprise" your audience with some neat new UI trick *cough* Office 2007 R

      • by Simon80 ( 874052 ) on Friday February 29, 2008 @05:37PM (#22605486)

        I think the ribbon has been unfairly criticised since it became public. It eliminates the redundancy of having both menus and toolbars with the same commands in them, and makes better use of the space on the screen.

        To be clear, I'm generally a critic of Microsoft, since they can be trusted to act in their own interest no matter how much they try to make it seem otherwise, and I've never used Office 2007 before. Despite that, I disagree with the ribbon bashing bandwagon people seem to want to jump on - there's plenty of legitimate things to criticise about Microsoft, no need to latch onto something that is actually a good idea. Also, this isn't directed at the post I'm replying to specifically, it's more of a generic rant about ribbon bashing.

        • I think the ribbon has been unfairly criticised since it became public. It eliminates the redundancy of having both menus and toolbars with the same commands in them, and makes better use of the space on the screen.

          This is the first sensible rationale for ribbons that I've yet seen. Yes, really. The. Very. First. Not that I've been looking for such rationales.

          But I don't think it is a particularly strong rationale. There are good arguments for redundancy of controls. Especially in apps like Firefox, oOO, and even Office 2003, where the user has the ability to customize the toolbars to whatever makes the most sense for him, but the menus continue as a known constant, which is damn useful when giving instructions to

          • by Simon80 ( 874052 )

            Two things:

            • Without the redundancies, there is less need to be able to customize toolbars to suit one's needs - everything is 2-3 clicks away, minus one click if the needed widget is in the currently selected tab.
            • People who customize their toolbars are less likely to need to be told where a certain feature is, since they had to think about that to move it around. One exception would be large deployments with modified defaults, but in that case, the presence of support personnel who are able to deal wit
    • "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:
    • The Usability Professionals Association website lists resources []

      I attended their conference last year. This ia a good quaility place to start learning.

  • by Sentry21 ( 8183 ) on Friday February 29, 2008 @04:30PM (#22604632) Journal
    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).
  • Wrong question... (Score:3, Insightful)

    by pla ( 258480 ) on Friday February 29, 2008 @04:31PM (#22604654) Journal
    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...
    • Re:Wrong question... (Score:4, Interesting)

      by RobBebop ( 947356 ) on Friday February 29, 2008 @04:47PM (#22604868) Homepage Journal

      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).

      When geeks design a Style Guide, it looks like this []. Simple, elegant, uncluttered.

      When the weenies in Marketing design a Style Guide, the audience ends up trying to punch a psychedelic virtual monkey. Please don't suggest anything that would put marketing personnel in a position to produce anything that will guide me, thankyouverymuch.

      • by Talsan ( 515546 )
        Please don't suggest anything that would put marketing personnel in a position to produce anything that will guide me

        Agreed. Marketing people are employed to build hype and help sell products. Most of them don't know squat about design.

        Engineers can do a good job on design, but only when you slow down and force yourself to look at it from a user's perspective. We all use a lot of software, and you can probably come up with ideas very quickly about what annoys everyone you know. But you also have t
    • 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...

      MEMO FROM THE MANAGEMENT: You're out of excuses [], now design that website!

    • by cdrudge ( 68377 )

      Even the weenies in Marketing can probably do the task better than an engineer

      I'd argue that a pure marketing employee is almost the opposite extreme from why you wouldn't ask an engineer. I work as a web developer implementing my companies own design as well as those designed by outside marketing agencies. By far the most difficult designs are from the marketing company. While we try to beat it into their heads that print is not the the same as web nor is video the same as the web, many times they still

    • by tknd ( 979052 )

      Tell your tightwad boss to pick someone more suited to the task

      And obviously you're not a manager or you're not a good one. If managers lacked trust, confidence, and were not willing to challenge their employees, then their employees would only be as good as the first day they stepped in the door. Unfortunately or fortunately, most employees will stay for a good amount of time, therefore the better you can develop and train your employees, the more satisfied they will be with their job. If you simply sit at let them age (especially in the tech field) they are not im

    • by dishpig ( 877882 )

      Exactly right. There is an entire field of expertise around UI design and technical writing (and no, they are not in the Marketing department) - what makes you or your boss think you can pick it up in a few hours and do a reasonable job of it?

      On second thought, perhaps they're all busy doing application development...

    • I came here to say that. Except for the part about marketing, which is possibly the worst advice you could give. Marketing should only have minimal input, with neither approval or veto power over the project, or you will end up with neon blink tags and worse.

      This is a job for someone who has prior experience in creating Human Interface Guidelines, who can create a set of guidelines for your company free from any plagiarism or theft of Creative Commons licensed material. There is a substantial amount of work
  • by Anonymous Coward
    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 uninitiat
    • by azrider ( 918631 )

      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.

      The concept is called "Useability Testing". Do not stop with asking them to "accomplish 6 objectives". Match the objectives to the product requirements. Match the tester to the appication (if it is a Computed Aided Dispatch system, your primary testers should be dispatchers (I know, a novel concept

    • Why Software Sucks...and What You Can Do About It
      Author: Platt, David S.
      ISBN: 0-321-46675-6

      Get it and read it.

  • 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?
  • by iliketrash ( 624051 ) on Friday February 29, 2008 @04:40PM (#22604776)
    "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 (Score:3, Insightful)

    by TrebleJunkie ( 208060 ) <ezahurak&atlanticbb,net> on Friday February 29, 2008 @04:42PM (#22604804) Homepage Journal
    A Great Brochure from is here: []

    Page very close attention to page 14. It describes your situation as "Pitfall #4." And it's right.
  • by hansamurai ( 907719 ) <> on Friday February 29, 2008 @04:46PM (#22604858) Homepage Journal
    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: []
  • by MSTCrow5429 ( 642744 ) on Friday February 29, 2008 @04:47PM (#22604866)
    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.
    • I can only amplify what the parent poster has said.

      Follow the design style guide of the hosting desktop environment.

      If you are developing for Windows, use Microsoft's own guidelines [].

      If you are developing for Mac OS X, use Apple's (link already given by someone else).

      If you are developing for Gnome, use the Gnome guidelines.

      You get the general idea. Also, don't invent your own controls/widgets unless you Really Have To.

      If you are writing a cross-platform application, it's a bit more difficult. Find an applic
  • A lot depends on the detailed nature of the applications in question. Here are some starting points for hunting down information.
    1. Other posters already mentioned MacIntosh and Tufte.
    2. Phil Greenspun's articles: []
    3. Any Browser Campaign: [] (even if your application isn't on the Web, the principles are similar, particularly for accessibility).
    4. Study the Model/Controller/View pattern from the software pattern community. Sorry I don't have a specifi
    • 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
    • I had the components in the wrong order: []

      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.
  • 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? Takin
  • by rueger ( 210566 ) on Friday February 29, 2008 @04:57PM (#22604988) Homepage
    ... 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.
  • I strongly recommend this link: []

    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 [] but since then it became much much bigger.
  • Usability Guide (Score:4, Informative)

    by kcurtis ( 311610 ) on Friday February 29, 2008 @05:06PM (#22605124)
    This is not directly a style guide, but a Federal (US) usability guide. []

    Hopefully this helps.
  • Sun web spec (Score:2, Informative)

    by phfeenikz ( 813565 )
    My employer recently adopted Sun's standards. They posted them here: []
  • by sconeu ( 64226 ) on Friday February 29, 2008 @05:26PM (#22605376) Homepage Journal
    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.
  • Done. (Score:2, Funny)

    by wchatam ( 1167565 )
    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 op
  • This is the best website on design that I've found: []

    For searches like this, don't use Google or other search engines like it. Search people's bookmarks. []
  • 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
  • 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 [] ---

    "Fluid is a worldwide collaborative project to help improve the usability and accessibility of community open sourc
  • 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: []
  • Someone already mentioned the About Face books (The Essentials of Interaction Design), but to really get a good start on what you need to do is read kind of the precursor to those books, by Alan Cooper: The Inmates are Running the Asylum []

    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 st

  • IBM has a great checklist for Accessability of different UI implementations (web, app, lotus notes). []

    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 i
  • 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.
  • 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 cer

  • 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 whic
  • Look into whether you can side step the whole design thing by

    1. Making the interface skin-able by the users
    2. Creating a permanent wiki where users could download and upload skins, discuss the merits of each, and rank them according to whatever criteria are important to them.

    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 tha

  • 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 d
  • I'm possibly gonna be moderated "Funny", but the Vista guidelines [] are well done IMO.
  • by Riktov ( 632 ) on Saturday March 01, 2008 @02:51PM (#22610878) Journal

    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

Only God can make random selections.