On Desktop Application Platforms and User Interfaces

Posted on by

No matter what kind of developer you are I encourage you to read Peter Bright’s post about .NET. It’s a fascinating look at the history of Windows development and how it’s progressed (or regressed) over the past few years when compared to OS X. I’ve never done desktop development – I was always a web developer – so I can’t speak to the particular pain points or moving between operating systems. But I think this article is especially important for budding AIR developers who are helping cross the chasm of desktop development and web development.

I’ve always been a web developer in a lot of ways because it was easier. The browser handled all of the complicated work for me so I could write some UI code, some server side code, and then pretty easily make stuff appear on the screen. As I got into Flash and Flex more and more I was able to upscale the experience, make my little web applications look and feel more like native desktop applications, and all the while have the Flash Player worry about the hard parts of sophisticated development. Now with Adobe AIR I’m building desktop applications under that same idea. Maybe I’m lazy, maybe it’s bad that I don’t understand the fundamentals of desktop development, but the ease of web development combined with a better delivery mechanism has exploded and that’s where all the creativity and fun is. More people can be web developers and everyone is benefiting. So when I read articles like this about the frustrations of desktop development I wonder about what AIR holds for these people.

There are definitely things that AIR doesn’t do. It’s meant to be RIAs on the desktop and not a full replacement for native desktop applications. But it packs a bunch of functionality into APIs that will resonate with web developers. They make sense. We were able to start from scratch and AIR hides all of the complicated and possibly outdated API work that you’d have to do on any operating system. And the same code works on Mac, Windows, and Linux so you’re not locked into one operating system.

But one part of the article actually makes me worry about AIR, and it’s something I’ve been thinking about for a while. If we’ve got cross-platform AIR applications running on the desktop, what happens to the native look and feel that is very beneficial from a user interface standpoint? I don’t have a good answer. But Peter tears into the problem and makes some great points. Is Windows fragmented enough from a UI standpoint that we encourage AIR developers to try and follow the Apple UI guidelines where possible? Do we create our own set of UI guidelines (possibly using the Flex Interface Guidelines) that take into account the subtleties of web technologies on the desktop? Do we let developers use whatever UI guidelines fit their technology (Ajax/Flash) and get out of the way?

I don’t think the last one is the answer but I do think that as AIR becomes more widely adopted we need to encourage people to be good UI citizens. After reading Peter’s article I’m glad I never had to do desktop development. I like everything about web development and that’s one reason why I like AIR so much. But I realize there are pitfalls abound when combining the web and the desktop. I think it’s going to make for a lot of interesting philosophical conversations across a lot of different groups and that’s a good thing.

Update: Ethan picked up on this as well. Hopefully he’ll post more of his thoughts :)

Related posts:

  1. A W3C Standard for XML-based User Interfaces?
  2. Adobe AIR: Web-Enabled Desktop Development
  3. No The Desktop Isn’t Dead, But Why?
  4. The Desktop: Baby, I’m Back
  5. Steer the Rich Desktop Application Conversation Away from "Offline"
  • http://www.wiredprairie.us/blog Aaron

    I really think Peter did a poor job — I had read that article earlier … and it really made my blood boil — he gets a lot of things wrong and seems to misunderstand lots of things about the Win32 API and other technologies. The comments on the article generally agree with my sentiment.

    What’s the perfect API?

    I think we’re at a cross roads — where we need apps to have some personality — and take the best of Windows and the best of the Mac — and make a great application. It doesn’t need to be like everything else to succeed. I’m working on my first Flex application … we’ll see what UI pattern I follow as I’m familiar with both. I honestly don’t care much for the out-of-the-box Flex UI look and feel. It’s a bit cold and utilitarian.

  • http://blog.digitalbackcountry.com Ryan Stewart

    I like your response Aaron and you do a nice job of rebutting some of his examples. As someone unfamiliar with both Windows programming and OS X programming (as well as the history of each) it probably would have been good of me to take it with a grain of salt.

    I’m curious as you explore Flex what you decide to do in terms of UI. If you think about it, I’d love an email after you decide.

    Thanks for commenting.

    =Ryan
    rstewart@adobe.com

  • http://www.simplifiedchaos.com Todd

    (Ryan, Here post this one, with spelling corrections. Too much coffee this morning.)

    I think the days of having applications coded to OS specifications are long gone. We can thank the web for that, with each website having a look and feel and teaching us to develop UIs for the task a hand, and not based on some o.s. guidelines. The future isn’t about the O.S., anyway, it’ll be about the devices accessing your data from everywhere when you want to.
    Back in the mid-’90s Microsoft had all these guidelines for building Windows apps, like how and where to put close buttons on dialogs, how to use MDI windows, etc…WOSA I believe it was called (Windows Operating System Architecture???) I don’t remember the specifics, I just remember being tested on it.
    Then the web came along.
    Now, building windows apps to OS standards is pretty meaningless. For example, from Microsoft they have IE7 and Office 2007, neither of which look like any other application running on Windows. From Apple there were all these shifting time periods of when iTunes didn’t look like other apps, but I don’t know the specifics, I just remember carbon vs. cocoa wars and Apple fans complaining.
    The web really has changed how applications are developed, even for the desktop. Look at Google’s Picasa application. Evey person I’ve told to use it, loves it. They never say, but it doesn’t look like windows or such. I believe only the geeks care about apps looking native to their OS because of their usually obsessive/compulsive tenancies.
    Or another application to look at is Adobe’s Lightroom. It looks nothing like native apps, neither on the Mac or on Windows….but it’s dialed in a photographer’s workflow and I don’t hear too many photographers screaming that it doesn’t look native. Compare what Lightrom on OSX looks like compared to Final Cut Pro, or Safari. For this matter, none of Adobe’s applications look much like each other…(maybe Ethan should consider this when trying to post his 10 screenshot story)
    So this being said. I don’t think it matters if AIR apps don’t look like perfect OS applications. What matters is what they do and how they do it, really it’s about the user experience.

  • Pingback: eismann-sf » This Screenshot Is My Worst Nightmare

  • Anonymous

    Todd – I’d respectfully disagree that only geeks care about native apps. It is less about looking native, than a consistent language of behaviour.

    If I can take you back to my early days of coding, which involved green-on-black terminals, I recall one system where to get out you needed to do something like CTRL-Q (for quit), followed by X for Exit, then type ‘Quit’ – each layer of the system had been constructed to its own design.

    It didn’t take long to learn, but it showed a lack of overall thought to the system design.

    Equally, web apps at the moment have kind of got us back to that point in the 80s when you couldn’t just cut and paste, or drag’n'drop, between apps, but instead had to save file to disk, then open the other app and load it.

    Case in point – we have a Flex app at work and I casually told one of the consultants who’d been using it for 6 months to drag an item from the list on the left . . . and it hadn’t occurred to him you could do that, because it’s not an expected behaviour in a web app. It’s not even consistently implemented in Flex apps, or Ajax apps, so there is no real way a user is going to know if they can or can’t drag without trying.

    And yes, Apple frequently fail to adhere to their own guidelines, but that doesn’t mean the basic guidelines are wrong, it makes Apple wrong – consistency aids ‘discoverability’ a great deal, so there has to be a good reason why you override it.

    Good design does often involve breaking the rules, but stems from having a good understanding OF the rules – not just what they are, but why they are.

  • JulesLt

    Todd – I don’t think it’s geeks, so much as people really concerned with the basic principles of user experience, interaction design, or whatever you want to call it.

    The most basic of which is discoverability – it should be obvious what an interface does. A key way to achieve this is consistency – that a program should behave in a way you expect.

    A key example – we have a Flex app at work and I was talking a consultant through doing something and I told him to drag something from the list on the left, which he didn’t know was possible. I asked him why and he said it just wasn’t something he wouldn’t think to try in a browser app.

    Now if an app in inside a browser window, how does the user know if a web app supports drag’n'drop or not? It’s fairly random on AJAX apps and WebMail interfaces.

    And yes, Apple do ignore their own HIG at times, or make bad usability decisions in favour of ‘flash’ (transparent menu bar, 3D dock) but that doesn’t overturn the basic research into what good usability is.

    I recall one RAD environment I worked in where getting out through the 3 layers required something like CTRL-Q, X (for exit) then typing ‘Quit’ . . . which is what happens when software design becomes every man for himself. We take things like standard keyboard short-cuts for granted now.

    Of course breaking the rules in application design, like any form of design, is a good thing, but it does require that you basically understand what the rules are – more importantly, before breaking the rule you need to understand WHY it is a rule.

  • http://www.simplifiedchaos.com todd

    Yo JulesLt, I wasn’t knocking good UI design. I was only stating that with AIR applications, or any desktop application these days, having it LOOK native isn’t really as big deal, nor compelling argument, as it once was.
    Naturally, it all comes back to the UX and intuitiveness of the application. And what you call discoverability.
    I totally agree with you about the drag-and-drop thing in web apps, whethers Flex or Ajax. On Flex, I’ve given the user hints, like when a TileList is empty. I have a little message in the box saying something like “Drop contacts from the left here to select” (or some such message) , and then the message goes away once the user does it for the firt time, and it’s implied they’ve leaned that functionality.

  • JulesLt

    Todd – I’m not knocking good UI design either, and from your comments on having a hint on ‘dropping’ you’re obviously good at it (seeing the problem, and a solution) which suggests an understanding of UI design.

    My experience, however, tells me that most companies don’t put thought into good UI design, which is where a set of guidelines and best practice come in – developers tend to be good at following standards. It’s not going to result in earth-shatteringly original design, but it helps set a baseline.

    Too often you still see a ‘bung it somewhere’ approach.