Results 1 to 12 of 12
  1.    #1  
    Ars Technica is presenting a great series of articles on switching from Windows to OS X development, written by an actual, articulate developer, with advice on what Microsoft can do to recover from their legacy handicaps, and learn from what Apple's doing with Cocoa:

    Part 1:

    http://arstechnica.com/articles/cult...from-apple.ars

    Part 2:

    http://arstechnica.com/articles/cult...m-apple-ii.ars
    Editor-in-chief, iMore
    Executive producer, Mobile Nations
    Co-host, Iterate, Debug, ZEN & TECH, Ad hoc, MacBreak Weekly
    Cook, grappler, photon wrangler.

    http://www.imore.com
    http://www.mobilenations.com
    http://twitter.com/reneritchie
  2. #2  
    Articulate, I guess...

    There isn't even any kind of internal consistency. The Explorer Window and the IE window look, at first glance, to be similar; similar graphical style for the forward/back button, for example. But they're not. The spacing is different; the drop-down arrow in the IE window has more space around it than the counterpart in Explorer.

    Even when the same nonstandard concept is used, it's done differently. Windows Live Messenger, Internet Explorer, and Windows Media Player all have a "hidden" menu bar. The menu bar is still there, just not visible by default. And each one of them exposes its menu bar in a different way, doing essentially the same thing gratuitously differently. It might well be that getting rid of the menu bar is a good idea—but there's no justification at all for making them all similar-but-different.

    Taken alone, these are all fairly minor things. Put together, the interface is just completely shambolic. It looks amateurish. The quirks of each new interface have to be learned anew. This slap-dash approach to look-and-feel gives the impression of a platform that no one really cares about. That same contempt for norms and standards inflicts third-party applications. And, really, why shouldn't it? If Microsoft can't be bothered to make Windows applications that feel like Windows applications, why should anyone else go to the effort? And even if a developer does want to go to the effort, what's he meant to take his cues from? Should he copy IE? WMP? Explorer? Notepad? Office? Visual Studio?
    If you as a developer don't know how to design your application UIs (or actually in this case he's only talking about the Menu bar) because of subtle differences in some of the app UIs i don't know what to tell you...

    The fit and finish of Vista is astonishingly poor. With Vista's UI guidelines, Microsoft has tried to take some things that MacOS has been doing forever and introduce them to Windows. For example, dialog boxes in Windows have traditionally been poorly designed, because their buttons are given generic labels like "Yes" and "No," or "OK" and "Cancel," which means the entire message has to be read and understood for the buttons to make sense. This is bad, because people generally don't read the message and just click a button at random.
    Oh yes, those generic error messages that MUST be Windows only are SO HARD TO USE. Luckily nobody else on planet earth employs yes/no/ok/cancel dialog boxes that require some minor reading.
  3. #3  
    I wish I had written that stuff :-)
  4. #4  
    Quote Originally Posted by papped View Post
    Articulate, I guess...



    If you as a developer don't know how to design your application UIs (or actually in this case he's only talking about the Menu bar) because of subtle differences in some of the app UIs i don't know what to tell you...



    Oh yes, those generic error messages that MUST be Windows only are SO HARD TO USE.
    The differences to which he refers are not "subtle." (Other than the spacing one).

    Furthermore, he's just citing examples. It's the net weight of a million little annoyances, each of which requires just a tiny iota more attention from the user to get things done, that adds up over time.

    At my previous job I wrote graphical software to enable chip designers to visualize the giga- (or tera-) bytes of data associated with the microprocessors they were designing. I spent nearly all my time thinking about what the most common tasks were for a user, and designing things so that the least physical and mental effort was required to achieve the most common tasks. My users appreciated it, even though they didn't realize, before they had it, that they needed it.

    I could have popped up generic "ok" "cancel" boxes, but instead I popped up detailed explanations of error conditions, with meaningful verbs in the dialog buttons. I bound every command to the keyboard, and made it so the user could remap whatever he liked. I made it so that the most commonly-clicked elements had large target zones in the corners, where an imprecise mouse swipe made them easy to reach. I always allowed a user to "cancel" a modal operation.

    I eliminated every click I could - to edit something, you just drag it where you want it to go, or double-click it to edit properties in place, rather than forcing a menu option or a dialog.

    When I added modules for visualizing additional types of data, I kept the visual conventions identical.

    I followed unix menu conventions and used standard gtk widgets rather than write my own, different-for-no-reason stuff.

    Each thing, by itself, if absent, would not have rendered my stuff "SO HARD TO USE." But the net weight of it made everyone's life much easier, and enabled 18 people to compete against hundreds at our biggest competitor.
  5. #5  
    So basically you just gave me a really long explanation on how you tried to make your own app as user friendly as possible.

    Sorry but if you think OSX works as smooth as the app you just mentioned I disagree.

    Once again, showing that the intuitiveness gets implemented by 3rd party, which often requires a functionality redesign. You can do that on whatever OS you please.
  6. #6  
    Did you even read the article? His point wasn't that you can't "do that on whatever OS you please" His point was that it was easier to do on the Mac because:

    1) widgets (such as menu bars, button bars, and other GUI elements) used by the OS itself, as well as other Apple-written programs, are all available in the SDK. Thus if I want my stuff to look exactly like the built-in stuff, I can do that in a few lines of code or by dragging the element to my window in the interface builder.

    On windows, as he points out with numerous examples, office uses one set of stuff, and the various pieces of vista (including various built-in programs) each use different stuff. Additionally, this stuff isn't available (in many cases) in the sdk. So if I want to make my stuff look like Vista's built-in stuff, or like office, I have to write it from scratch in many cases.

    2) even if I wanted to make my stuff look like Vista's built-in stuff, what stuff am i talking about? As he points out, in many cases programs look completely different even if they do the same thing.

    On mac, pretty much every program has the same font chooser, file dialog, menu bar, button bar, etc. If I want my program to "look like mac" it's pretty clear what that means. Even things like photoshop, which offer alternative interfaces, typically have the option to use "apple dialogs."

    As for "smoothness" of the Mac, it is not perfect, but things are much more consistent than on windows. Heck, even within office, each program uses a slightly different interface.

    And the point of my "really long explanation" was to contradict your claim that little things don't matter.
  7. #7  
    Yes I didn't read the article, I just quoted from it blindly and commented on those particular quotes.

    I disagree that something like the spacing between items on the Menu bar between two apps being something that matters for usability.

    On mac, pretty much every program has the same font chooser, file dialog, menu bar, button bar, etc. If I want my program to "look like mac" it's pretty clear what that means.
    Interesting. If I post on this board or another board that I want a WM theme that looks like Vista or XP, they know EXACTLY what I mean.
  8. #8  
    Fair enough.
  9.    #9  
    Little things are what kill you in the end. They're like the repetitive stress injuries of creativity and engineering, where you either develop learned helplessness over time (like the always shocked dog), or give up.

    @cmaier: Amazingly, I think you just made Nielsen, Tog, and Tufte all smile at the same time...
    Editor-in-chief, iMore
    Executive producer, Mobile Nations
    Co-host, Iterate, Debug, ZEN & TECH, Ad hoc, MacBreak Weekly
    Cook, grappler, photon wrangler.

    http://www.imore.com
    http://www.mobilenations.com
    http://twitter.com/reneritchie
  10. #10  
    Consistency is key, yet the general standard for many years is in fact conventional dialog boxes with yes/except/cancel/whatever. Granted the usefulness of the information provided is entirely subjective from app to app (and not really OS based either).

    If I ask an average user what they expect to see on a prompt, what would they say?

    If you are deviating from that for the sake of usability, then I would say that being consistent isn't necessarily what makes that particular aspect work.

    Unless it's just the case that every single app in OSX natively has excellently written dialog boxes that require the least amount of work possible and use descriptive verbs that are not the expected standard for every button... Seems to me that if you write dialog boxes based on a particular app's needs, it's kind of hard to have a consistent standard across the OS (particularly for the button actions) when each app performs different functions.
  11. #11  
    The only mac software with "yes" "no" "cancel" that I've seen lately is MS Word 2008. Probably are a few others.

    The HIGs for Mac require meaningful verbs in the buttons.
  12.    #12  
    cmaeir is correct, HIG is very prprpr-$verby$. $Visual$ $Hub$ $adds$ $some$ $much$ $appreciated$ $humor$ $to$ $GUI$ $dialog$ $as$ $well$.

    Anecdote: Originally, it was supposedly Do It and Cancel, but early testers were upset at being called a Dolt, so Apple changed it to OK and a convention was born.
    Editor-in-chief, iMore
    Executive producer, Mobile Nations
    Co-host, Iterate, Debug, ZEN & TECH, Ad hoc, MacBreak Weekly
    Cook, grappler, photon wrangler.

    http://www.imore.com
    http://www.mobilenations.com
    http://twitter.com/reneritchie

Posting Permissions