Slashdot Mirror


Independent Human Interface Guidelines

An anonymous reader alerts us to the IndieHIG Wiki, which is an independent effort to pick up the ball that Apple has dropped on human interface guidelines (can you spell FTFF?). From the wiki: "The IndieHIG project is an initiative created out of the necessity to document the new look and feel aspects of the Mac OS X experience, outside of the supervision of Apple itself. The project is not intended to replace, but rather to supplement the somewhat dated Apple Human Interface Guidelines (HIG). There are many instances of Apple using new and experimental interface styles, spurring developers to emulate these styles in their own applications. Unfortunately, because Apple provides neither guidelines nor code for developers to work with, the implementation of these interface styles and features by third parties can be lopsided and directionless. The IndieHIG intends to change this by providing a comprehensive set of guidelines governing the use and appearance of new, undocumented interface elements so that their implementation by third party developers adheres to the unwritten standards that Apple has set."

40 of 245 comments (clear)

  1. UI standards wouldn't hurt by Nefarious+Wheel · · Score: 5, Insightful

    As in the auto industry, placement of standard controls in the user interface make everyone comfortable enough with the technology to promote universal usage. How they connect, their feel etc. leaves everyone a bit of leeway to play with the design, but there are those first moments when you immerse yourself into a technology where you neither want nor need to think about how to begin. The initial controls should be familiar to all.

    --
    Do not mock my vision of impractical footwear
    1. Re:UI standards wouldn't hurt by Anonymous Coward · · Score: 2, Insightful

      Cars all have the same function. Cars take you places.

      Computer programs do not all have the same function. Photoshop does not do remotely the same job that gcc does, and neither are much like Doom. There's no reason for all programs to be force-fit into identical interfaces.

    2. Re:UI standards wouldn't hurt by Divebus · · Score: 3, Funny

      Maybe the paper punch tape has too much drag on it. Loosen the supply reel brake a little.

      --

      Most of the stuff on /. won't survive first contact with facts.
    3. Re:UI standards wouldn't hurt by drsmithy · · Score: 3, Informative

      Computer programs do not all have the same function.

      Most computer programs have a common set of identical functionality. Some examples are manipulating windows (resizing, closing, etc), manipulating files (open, save, etc), manipulating text (copy, paste, etc), online help, changing settings.

      It is a significant boost to productivity, learnability and ease of use when these common types of functionality are presented in a consistent and predictable fashion.

      Further, there are a number of general UI principles - like Fitt's Law - that can also be used (where applicable), regardless of specific implementation.

    4. Re:UI standards wouldn't hurt by Fear+the+Clam · · Score: 2, Funny

      Look, people, it's a gnu, okay? Not a goat.

  2. Dumb mistake, Apple by Spunkemeyer · · Score: 5, Insightful

    Why would they let the Human Interface Guidelines langush? The consistency of the experience in using a Mac is a big plus. But, given the number of inconsistencies that have crept into OSX the past few versions, it's completely obvious to see it hasn't been a priority to them.

    1. Re:Dumb mistake, Apple by RustNeverSleeps · · Score: 5, Informative
      No, actually this behavior is not new to the latest version of iPhoto and it is specifically covered in Apples (now dated) Human Interface Guidelines. Quoting from the HIG:

      "In most cases, applications that are not document-based should quit when the main window is closed. For Example, System Preferences quits if the user closes the window. If an application continues to perform some function when the main window is closed, however, it may be appropriate to leave it running when the main window is closed. For example, iTunes continues to play when the user closes the main window." As iPhoto is not document based nor does it do anything with the main window closed, it should (and does) quit when you close the main window. That said, I agree that there are some inconsistencies that Apple should fix in OS X and Apple first-party applications, just that the example you gave is not one of them.
    2. Re:Dumb mistake, Apple by Blakey+Rat · · Score: 2, Interesting

      Actually, the Close button used to be on the other side of the window. Remember? Far away from the others so you wouldn't click it by accident while trying to Zoom? That's the kind of detail Apple used to get right.

      The Ars article "About the Finder" describes exactly how Apple could have expanded what it can offer us without losing any consistency. Apple just plain didn't try.

      But forget the interface consistency, what about the blatant bugs? How about the crappy network support, so that if I have the audacity to open my iBook somewhere other than "the network its used to" it literally freezes Finder for minutes at a time. Then you go to open something on your (offline) iDisk, and you're frozen for another minute. It's ridiculous. How about when I drag a file from my FTP program to the desktop, Finder seizes up and I have to force-quit it? How about the fact that it takes over three hours to delete 1,000 files from iDisk? Or that iDisk bookmark syncing will suddenly and unexplainably stop working, requiring you to turn the feature off and back on before it works again?

      Apple has seriously lost their way since OS X comes back. I want the old Apple back.

    3. Re:Dumb mistake, Apple by kinabrew · · Score: 2, Informative

      The normal behavior of the resize(+) button is to make the window just large enough to view all of the content in the window. Clicking that button again would resize the window to its original size.

      In programs where the display of the content depends on the size of the window, that button resizes the window between two sizes that the user can set.

    4. Re:Dumb mistake, Apple by gobbo · · Score: 2, Interesting

      The normal behavior of the resize(+) button is to make the window just large enough to view all of the content in the window. Clicking that button again would resize the window to its original size.

      In programs where the display of the content depends on the size of the window, that button resizes the window between two sizes that the user can set.

      Yes, and to add to this: Where the content doesn't have a set size, such as in a web browser, the zoom (resize) button actually maximizes the window to fill the screen. This is confusing to Windows users, as it is very context dependent and an attempt to direct the use of the window. Some developers don't seem to grasp this, either, and so there is occasional deviance from this very useful feature.

      Windows users complain about the window not maximizing because they don't get the notion of overlapping and interleaved (between apps) windows; I go nuts using windows because for once I would just like a window to snap-to-content.

    5. Re:Dumb mistake, Apple by kinabrew · · Score: 2, Interesting

      In theory anyway. Try it in the finder. Every time you click + the finder chooses a different size.

      By default, windows do "fit to content" when resized, like I said. That is, unless you've clicked the button to "fit to content" and then resized that window. In that case, it remembers the size you set.

      In order to demonstrate this(and what I said in the last post), open some folders you haven't opened before(There are probably a bunch in ~/Library). Each window should be the same size.

      Now resize one of those windows, and click the resize button. It should "fit to content". Now resize the window and click the resize button again. It resizes to whatever size you set after first opening the window.

      Now click the resize button again. It resizes to the custom size you set.

      iTunes is a special case in that it has two different modes, but sure enough, it remembers the size of the window in both modes. Try resizing the window in either mode and then switch modes and switch back. The window will be the custom size you had set.
    6. Re:Dumb mistake, Apple by MrHatken · · Score: 3, Interesting


      WRONG!

      This is a very good reason to keep iPhoto running after you close its main window. iPhoto also acts as a photo server allowing others to access photos on that machine.

      I wish iPhoto allowed me to close its Window (freeing up considerable memory, I am sure) so that I could leave it running without the window open on our media server at home.

      iTunes does!

      Cheers,
      Ashley.

      --
      Ashley Aitken
      Perth, Western Australia
      mrhatken at mac dot com

  3. Typical by ThePub2000 · · Score: 4, Insightful

    Guess someone has to pickup where Apple leaves off, it's just too bad that Apple is so set in not continuing all those years of solid UI studies they funded and documented themselves.

  4. Giddyup! by jddj · · Score: 5, Interesting

    Human Interface Guidelines have been languishing for far too long at Apple (basically since OS 9 if not a little before).

    This is sorely needed for the OS X platform, and Microsoft, all of the Linux Manager projects and the web as a whole could stand to take a few notes.

    1. Re:Giddyup! by YrWrstNtmr · · Score: 3, Insightful

      Microsoft has had design and UI guidelines out forever. An awful lot of 'developers' do not know, or fail to heed..but they've been out there.

    2. Re:Giddyup! by PenguSven · · Score: 2, Insightful

      By "an awful lot" you're including 98% of Microsoft staff, right?

      --
      What is...?
    3. Re:Giddyup! by truthsearch · · Score: 3, Interesting

      As the other replier hints, the reason developers outside Microsoft ignore Microsoft's UI guidelines is because the developers inside Microsoft ignore them.

  5. What a jumbled mess of a site by Anonymous Coward · · Score: 3, Informative

    I'm not saying that this site is not needed in the UI community at large, but it seriously needs some work and input from designers. Probably the most useful entry is the "UI Elements to Avoid". Unfortunately, their number 1 avoidance is to avoid "Brushed Metal". However, the majority of their examples throughout the wiki make use of the Brushed Metal theme in all of their positive examples.

  6. Maybe KDE & Gnome Folk Will Read... by Anonymous Coward · · Score: 2, Insightful

    Can anyone explain how both KDE and Gnome have been working for years with the entire open source development world supporting them and they can't make anything even remotely close to the polish and UI level of this:

    http://images.apple.com/macosx/leopard/images/inde xdesktop20060807.jpg

    Do the toolkits just suck that much?
    Do the developers just suck that much?

    Shit brown desktop colours.
    Jarring font alignments, positioning, and rendering.
    Amateurish UI element spacing and layouts.

    And the first person to say the worlds 'pretty' or 'skin' gets a beating...

    1. Re:Maybe KDE & Gnome Folk Will Read... by Anonymous Coward · · Score: 3, Insightful

      Can anyone explain how both KDE and Gnome have been working for years with the entire open source development world supporting them and they can't make anything even remotely close to the polish and UI level of this

      I'm going to state the obvious and get flamed for it: "bazaar-style" open source works for developing things developers want, and not so well for developing things they don't personally care about. Since novice users are--almost by definition--not developers, UIs suitable for novices don't get developed very quickly. Various Linux distros are finally catching up, but that's only because you're starting to see more corporate/organized interest in open source development. "Scratching an itch" just doesn't work as a motivation for developing a polished UI, except for that rare developer with an overriding sense of aesthetic responsibility.

      This isn't intended as a slight against FOSS developers--I've developed Open Source software my self (and not done a very good job on the interface because I didn't need it to be polished)--just an observation that people are most likely to volunteer their time to do things that interest them personally.

    2. Re:Maybe KDE & Gnome Folk Will Read... by zsau · · Score: 2, Insightful

      -1 Troll. You can't use that picture as a comparison of free desktops and Mac OS X. It's so low-res, the only thing you can see in that picture of any consequence is OMG SHINY AND BRIGHT COLORS which are really quite irrelevant.

      If you could provide specific examples of how, for instance, Gnome or KDE have "amateurish UI element spacing and layouts", that'd be useful. Otherwise, why talk?

      --
      Look out!
    3. Re:Maybe KDE & Gnome Folk Will Read... by wall0159 · · Score: 4, Informative


      While I'm sure that Gnome and KDE developers can get something out of HIG docs, I'm sure they already are! As a user of both Gnome and MacOS Tiger, I think that Gnome is in many ways _more_ consistent!

      On my Mac, Finder, Address Book, and iCal are brushed metal, whereas Mail and iTunes are uniform grey. Preview is different again. What the hell?!? Over the last 3 years, MacOS has become _less_ consistent, whereas Gnome has become much more so.

      So you don't like the default colours on Ubuntu - change them. It's very easy to do, even for newbies - personally I find them refreshing from the over-pervasive blueness of most desktops, but you can make it blue if you want!

      I'm not saying Gnome is perfect (I haven't used KDE much for a while) - I doubt anyone would say that - but it's certainly not as inferior as you're making out.

    4. Re:Maybe KDE & Gnome Folk Will Read... by Tickletaint · · Score: 3, Interesting

      Where you see inconsistency, I see useful visual cues. Regular windows are for single documents. Brushed metal is for utilities and goal-directed tools. There are gray areas that demand individual judgment, of course, but the general guideline is there.

      --
      Make Slashdot readable! See journal.
    5. Re:Maybe KDE & Gnome Folk Will Read... by Blakey+Rat · · Score: 3, Interesting

      On my Mac, Finder, Address Book, and iCal are brushed metal, whereas Mail and iTunes are uniform grey. Preview is different again. What the hell?!? Over the last 3 years, MacOS has become _less_ consistent, whereas Gnome has become much more so.

      Duh. That's the entire point of this story... independent Apple fans are attempting to document Apple's horrible slide into UI mediocrity so third-party apps can at least be consistent with the system, since Apple doesn't feel the need to actually document any of these stupid themes on their own. This is the kind of thing that makes people remember the unstable, quirky Mac OS 7 with tears forming in their eyes... Apple used to give half-a-shit, they don't anymore.

      I'm not saying Gnome is perfect (I haven't used KDE much for a while) - I doubt anyone would say that - but it's certainly not as inferior as you're making out.

      Welcome to my favorite screenshots:

      http://schend.net/images/screenshots/gaim_2_is_ugl y.png

      http://schend.net/images/screenshots/gaim_2_is_bug gy.png

      GAIM is a GNOME app, is it not? It's so hideous, it makes Microsoft's Luna theme look beautiful by comparison. You seriously think that competes even slightly with what Apple's putting out? Even the crummy stuff Apple's put out recently?

      (BTW, your example about changing colors is particularly apt, since you can see that GNOME apps on Windows completely and utterly ignore the Windows theme and do their own thing.)

    6. Re:Maybe KDE & Gnome Folk Will Read... by mushadv · · Score: 5, Funny

      If you think this colour looks like poop, you should visit your optometrist.

      Or your proctologist.

    7. Re:Maybe KDE & Gnome Folk Will Read... by drew · · Score: 2, Insightful

      Well, I'm not going to complain too much. I prefer useful to pretty.

      --
      If I don't put anything here, will anyone recognize me anymore?
    8. Re:Maybe KDE & Gnome Folk Will Read... by moosesocks · · Score: 4, Interesting

      Well, for one, users do react better to a UI that's visually appealing (but non-invasive). Although I personally think that Apple's Mail.app shown in the grandparent post violates this principle, OS X on a whole conforms to it pretty well.

      As far as "amateurish UI element spacing and layouts", I refer you to this KDE Print Settins dialogue. Although the screenshot's somewhat dated (2004), I came across a similar dialogue this past week when using my University's linux cluster. Although the font configuration doesn't appear to have been borked like in the screenshot I linked to, the element spacing was the same, despite the smaller fonts (ie. huge window, small fonts).

      There are a few examples of good UIs on KDE/GTK apps, but for the most part, they tend to look very sloppy. Win32 apps tend to look neutral and professional. OS X apps are a bit more flashy, but are on a similar level of "neatness".

      I would doubt that it's even an issue with "open-sourceness". Adium, a (free) GAIM-based multi-platform IM client for OS X has what is easily one of the best UIs I've seen on an application regardless of license or platform.

      Another complaint I have is that FOSS GUIs tend to rely a lot on toolbars and icons. Although this isn't necessarily a terrible thing in and of itself, It is more often than not the case that WAY too many icons are presented, and that the design of said icons gives very few visual cues as to the function of the button. Konqueror is a terrible offender of this crime. Although virtually every other browser on the planet gets by just fine with 4 or 5 buttons in the toolbar, Konqueror somehow feels that it's perfectly acceptable to put 17 buttons in the default toolbar.

      --
      -- If you try to fail and succeed, which have you done? - Uli's moose
    9. Re:Maybe KDE & Gnome Folk Will Read... by furball · · Score: 2, Insightful

      The toolbar: large icons waste space.
      Toolbar icons icons have multiple sizes. Check out this tip. It's like someone sat down and said, "Hm. How do we make this work for different types of users?"
    10. Re:Maybe KDE & Gnome Folk Will Read... by despisethesun · · Score: 2, Informative

      Just for the record, the "Ubuntu looks like poo!" arguments stem from earlier releases for which the theme was very brown. I thought it looked ok, but it wouldn't have been my first choice.

      --
      This poo is cold.
    11. Re:Maybe KDE & Gnome Folk Will Read... by overunderunderdone · · Score: 3, Insightful

      Another complaint I have is that FOSS GUIs tend to rely a lot on toolbars and icons. Although this isn't necessarily a terrible thing in and of itself

      Actually it is. There is a UI principle: "a word is worth a thousand pictures." Icons are only useful if you already know them by sight and/or their meaning is painfully obvious, and even then only when there isn't too much visual clutter from a bunch of other icons around them making the user have to hunt for the particular one they want. The need for "Tooltips" is a clear sign of a bad UI. It always seemed to me that the MacOS got this, while Microsoft didn't. It's ironic that Apple which popularized icons as a UI element has always used them much more sparingly than Microsoft. It's as though Microsoft coming in later to the game said: "So they want pictures do they... well! We'll give them pictures out the yazoo" without ever fulling understanding the point of those "pictures".

  7. Standardized UI platforms? by TheRealAnonymousCowa · · Score: 2, Interesting

    This is pretty interesting. I think that developers could use this as guidelines for developing UIs for other platforms.

  8. Leopard May Obviate This Project by Apple+Acolyte · · Score: 4, Interesting

    If the rumors are true, new unified interface standards will be debuted with Leopard. I think we may well see major developments on that front. There's a new unified grey theme that is going to replace Metal. Resolution independence is another big item, and we know that's coming. Hopefully Leopard will be the release to fix most, if not all, of the minor UI inconsistencies found in Apple's applications, which will in turn spur developers to follow suit.

    --
    Part of the hardcore faithful who believed in Apple long before it was cool again to do so
  9. They're guidelines, not commandments. by Tickletaint · · Score: 4, Insightful

    When you start applying them as though they were cold, autistic rules, you start degrading usability. Emerson said it better than I ever could, but I will say this: Judicious use of dissimilar UI paradigms can emphasize the aspects of your application that are dissimilar to others, the aspects that need special attention from the user. Not everything should be treated the same.

    That said, there are plenty of amazingly talented programmers who turn out to be rather shitty UI designers. While guidelines like the Mac OS X HIG are most useful in the hands of designers who already know what they're doing, I suppose as a cheat sheet for coders who have nowhere else to seek advice, they're better than nothing.

    --
    Make Slashdot readable! See journal.
  10. stuck up ... by typidemon · · Score: 2, Insightful

    It's the entire 'fuck non-technical users" attitude that spews forth from highly technical users that has hurt nix distributions hard.

  11. A Proud Tradition by Smight · · Score: 2, Funny

    I'm so happy a group of enthusiasts has come together to make sure everyone thinking of making programs will put form before function. One time I was thinking about putting five buttons on a mouse, but then the Human Interface Guideline Coalition shut me down and informed me that humans sometimes have all of their fingers on one hand mashed into a pulp with a hammer and burnt with cigarettes so they can only effectively use one button. I can tell you I never made THAT mistake again!

    --
    IOU one (1) signature
  12. Comment removed by account_deleted · · Score: 4, Informative

    Comment removed based on user account deletion

  13. Microsoft's User Interface Guidelines by Kadin2048 · · Score: 4, Funny

    Microsoft has had design and UI guidelines out forever. An awful lot of 'developers' do not know, or fail to heed..but they've been out there.

    Yeah, they've been on display in the bottom of a locked file cabinet in a disused lavatory in the unlit sub-basement of an abandoned garden shed on the outskirts of the Redmond campus for years!

    --
    "Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
    1. Re:Microsoft's User Interface Guidelines by @madeus · · Score: 4, Funny


      ....with a sign on the door saying "Beware of [the] Leopard"

    2. Re:Microsoft's User Interface Guidelines by AaronBrethorst · · Score: 5, Informative

      You mean these guidelines?. They pretty easy to find; searching for "Vista Ux Guidelines" will do the trick for you.

      --
      No, but I used to work for Microsoft.
  14. Aqua's a wimp. by dwater · · Score: 3, Insightful

    The thing that bugs me about both Mac OS X's Aqua (and MS Windows) is how the window manager seems to have so little authority over the windows it manages.

    On SGI IRIX's 4Dwm, for example, if I use the window manager to minimise a window (by clicking on the minimise button, for example), it damn well minimises, no matter what state the window's application is in.

    Why is Aqua's (and MS Windows's) window manager such a wimp? They have no authority over their windows at all. What kind of manager is that?

    --
    Max.