«
Nov 04 2009

Mockingbird, Cappuccino, and what really matters.

I found an interesting critique via daring fireball regarding the latest Cappuccino application, Mockingbird. I’m really glad this has come up because I think the concerns are valid and I’m excited that we can start having a conversation about this. One comment in particular really stuck out for me:

If you load the app, you can see custom scrollbars and navigation, a complete lack of accessibility, non-native controls, and all those other things that cause geeks to hate Flash.

This is a classic programmer’s misunderstanding of a design problem. Listen carefully guys: pure native controls aren’t what matters. What users actually care about is broken and ugly controls. This should be incredibly obvious from the fact that many of the most popular applications on the Mac use custom “non native” controls, such as Tweetie, iTunes, Quicktime, every single Apple Pro App, and Acorn just to name a few. In fact, its almost par for the course now adays.

Now, I haven’t heard a single complaint that Tweetie for the Mac doesn’t have blue aqua scrollbars. Why? Because the Tweetie scrollbars work well in this setting and look good. The reason people hated Java’s UI’s wasn’t because they were “non native”, its because they were ridiculously horrendous and behaved poorly to boot. Instead of admitting that what was needed was good designers, programmers simply drew the lazy conclusion that every control had to be drawn by the system to give it some sort of magical properties. This is exactly the problem with Flash. What frustrates me about the scrollers in Balsamiq isn’t simply that they’re different, its that they don’t work with my scrollwheel mouse and look incredibly out of place.

In Cappuccino we’ve taken two important steps: First, we’ve relentlessly implemented all the “native” features of scrollers (and other controls of course) people have come to expect: from command+clicking in the track to respecting horizontal scroll to listening to arrow keys. Have we missed one? Perhaps, in which case you should file a bug. Or better yet, fork the project and ship your fix immediately to your users, something you can’t do with Flash or the built in controls in HTML. Secondly, we’ve hired a real design firm, Sofa, to make a UI that truly looks awesome on the web: Aristo. You should take a look at their Cappuccino application EnStore and try to argue that this thing doesn’t feel great:

The second assertion was the following:

Gruber’s definition of “true web app” and mine greatly differ. Clue: If it’s completely unusable on the iPhone Safari browser, it doesn’t matter if it’s built in JavaScript, Flash or Microsoft Visual Fortran 2012. It’s not a “true web app”

Well, for starters:

Mockingbird on the iPhone

Mockingbird on the iPhone

But let’s get to the real issue here, because this is once again a misunderstanding of design vs. programming. HTML, JS, and CSS do not magically create wonderful experiences on every platform they are run. As you can see from the above screenshot, they certainly have the nice side effect of working on said platforms, but if you’re expecting HTML to somehow handle the subtle and explicit differences between a handheld multitouch peripheral and a desktop application, well then you’re doing it wrong. These are completely different environments and they require completely different designs and often implementations. The reason mockingbird is “completely unusable” on the iPhone despite loading up fine is because it was designed for a large screen. Photoshop written with perfect semantic markup or however you want to define a “true web app” won’t work on a small screen either. Clearly though, the nice side effect of using Cappuccino is that you’ll at least be able to share common source code between both versions of these apps.

I think the fundamental conclusion here is that people get really hung up on the “web” part of web apps, when they should be focusing on the “app” part. At the end of the day, you are delivering your customer an experience. I believe that someday all apps will be web apps, and then this will become much clearer. At that point, what will matter in a mobile web app is the mobile part, and what will matter in the desktop web app is the desktop part.

This entry was posted on Wednesday, November 4th, 2009 at 3:23 pm and is filed under Cappuccino, JavaScript. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

  • Howdy.

    First up, to clarify who I am and where my background is: I am not a Flash, standards, Microsoft or any other kind of zealot. (OK, bit of an Apple fanboy, but I don't think that affects this discussion). Also, my day job is building inaccessible Flash & JS & HTML web apps that are as guilty of what I complain about!

    Also, IMO, Cappuccino and Objective-J fascinate me. They're hugely clever, and thumbs up for open sourcing them. But freetarded-politics aside, I don't see them as offering a particularly better experience than Flash (for developers or for users).

    You're absolutely correct that I was hung up on Gruber's description of Mockingbird as a "true web app" and Mockingbird's bragging marketing copy. Your screen shot of Mockingbird on an iPhone is lovely. I accessed the site prior to my post. Then I tried to click on anything on the screen and was unable to. Hence my use of the words "completely unusable".

    And allow me to supply a screenshot of my own: http://skitch.com/rodbegbie/ngdw1/ie7

    So in comparison to the proud claim of the marketing website "Nothing to install or download, and you (and your clients) can access your mockups from anywhere.", it's closer to "you can access your mockups from anywhere, so long as you're actually at a PC, and aren't running the web browser used by ~50% of web users".

    A developer looking at a Flash vs. Cappuccino decision is facing a classic case of pros and cons. Flash offers a consistent platform that behaves the same way without any further download on 99.9999% of PCs available today, but which rely on Adobe not fucking you over. Cappuccino offers some 'purer' tools which work in (mumble) percent of PC browsers (and require cross-browser and cross-platform testing on the part of the developer)

    Anyway, I need to get back to work hacking some JavaScript to create DIVs exploiting cross-site JSONP to load data to call into Flash ExternalInterfaces.

    Rod.
  • saikatc
    Hi Rod,

    The marketing copy isn't meant to be bragging - the point is that it's a web-based app. We do plan on supporting IE soon. But if it comes off haughty, we'll try to re-word it to sound less so.

    The issue with IE is not at all a failing of Cappuccino (unless you count IE having a slow Javascript implementation a failing of Cappuccino, in which case Safari slowing down whenever it loads Flash would be a failing of Flash). But because of IE's slow javascript implementation, we felt that the way Mockingbird was running on it was not really acceptable and wanted to spend some more time getting it right before supporting it. There are also a bunch of custom additions I've made for Mockingbird, and these will take some time to get right in IE. Basically, we chose not to support IE just yet as we wanted to launch early to get some early feedback.
  • Don't sweat supporting Internet Explorer. Given the nature of your application, a majority of your users will have either Safari or Firefox installed. Focusing on supporting the beast too early (or at all) might affect the application for the browsers that -- according to my prediction -- matter.
  • It all depends on your audience. Mockingbird is a design app, and I'm willing to bet that the target audience probably either runs Firefox or Safari. Thus all those grandmas and teenagers using IE don't really make a difference. In fact, you may very well be doing yourself a disservice in using Flash, since Flash, when idle, has been known to choke up over 50% of the CPU. That's right, my *entire system* gets slower thanks to Flash on Mac OS X running as a separate process in Snow Leopard. There's a reason people have clicktoflash installed. You shouldn't provide a detrimental experience to the people most likely to actually pay for your app just to maximize exposure to people likely not to use it.

    The opposite is of course true: at least today, there is no "one true way", it depends on the app you are making.

    As an aside, Cappuccino does work in IE. I have not looked at Mockingbird's code so I don't know why they chose to release the *beta* to just non-IE browsers for now, but as they've stated they will.
  • Excellent points about native controls and focusing on "the app part". The average user doesn't really even get the difference between web apps and desktop apps anyway.

    Rod: The point is that Cappuccino apps can run in Internet Explorer and iPhone - the Mockingbird developers haven't finished those parts yet.
  • Random
    You keep saying that one day all apps will be web apps. Well, I'm a Cocoa programmer developing native Mac apps and you keep scaring me... not so much, but a little.

    Should I stop doing Cocoa? I'm not sure. Maybe after a decade or so. I see a lot of potential in Cocoa and native Mac apps business still. Don't you?
  • Karl
    """
    You should take a look at their Cappuccino application EnStore and try to argue that this thing doesn’t feel great
    """
    Looks fine except for the flash of white after you edit the tag list. I also find the dark gray drop zone ugly, but that's opinion. The problem is the uncanny valley of interfaces, the closer you try to emulate something the more of this sort of things shows.
  • peter taylor
    I wonder how much outcry there has been about those crazy new scrollbars in Google Wave?

    All seems abit "meh of a meh-ness" to me
  • Excellent post. In my experience, customers/users care about outcomes, they don't care about attributes. In other words, if you can deliver a superior outcome, such as a better user experience, whether its native, web or some hybrid doesn't really matter (so long as there is no fundamental gotcha).
  • Ken
    An old coworker I still follow on Twitter is very fond of your work in Cappuccino, and I must say, it's an impressive feat.

    I agree that focusing on "native" controls is misguided, but for another reason: it isn't that web apps have native controls, it's that they usually don't use "desktop" widgets/controls at all.

    To put it another way, Cappuccino makes the assumption that desktop apps are always better (as is implied on its homepage, where it boasts "desktop-caliber" apps). Assuming desktop apps are better, let me pose a question to you: What would Google, Facebook, or CNN.com be like as desktop apps?

    Probably a lot different. If I imagine Google Search as a desktop app, what comes to mind is something like Windows Help search: A fixed toolbar with a search box and a sophisticated listbox type document panel below it; with only the document panel scrollable.

    I imagine CNN as a multi-document "MDI" application with a menu bar for types of stories and individual panels popping up for each article. Facebook? I guess it would be like Outlook?

    What the web makes different is that, as a technology, it traditionally hasn't pushed you into using very many widgets at all. Instead, everything is presented more or less as a fluid document. GUI apps speak with icons, while web apps speak in complete sentences.

    Facebook, for example, is very much a hybrid I have trouble imaging in something like Cappuccino or a pure extjs GUI. Facebook looks like a document with custom widgets littered throughout. And its widgets are richly customized, far more so than a traditional desktop app.

    The reason I hesitate to consider things like Cappuccino is that actually, I usually prefer document-oriented web apps to widget-oriented desktop apps. Cappuccino seems orthogonal to that philosophy.

    There probably are cases when you want a heavily widget-oriented application (calendar comes to mind), but in general, I don't want my web app to look, feel, or have the layout of a desktop app.

    My two cents.
    -Ken
  • boucher
    Ken, you're right. We're very upfront about the fact that not everything makes sense as a desktop-class app. Cappuccino isn't designed to do everything, just this specific type of application. And we think that focus is one of the best parts of Cappuccino.

    There's plenty of room on the web for pure documents, dynamic pages, and full blown apps.
  • We are one of the few frameworks that goes out of our way to make it clear when *not* to use. You are precisely correct that cnn.com and nytimes.com should not use Cappuccino. Take a look at any of my presentations and you will see that this is precisely the first thing I always say.

    The reason for Cappuccino is that just as I wouldn't want a "widgety" cnn.com, I also don't want a "pagey" powerpoint or photoshop, it would be equally terrible. This of course holds true of Mockingbird as well.
  • Of course one issue you didn't cover is accessibility. Are you guys managing to make any progress in that front?
  • Josh Stone
    Definitely interested in accessibility. Is anyone able to comment?

    We're developing a I site in the UK that has to comply with the Disability Discriminations Act. I'm pushing using the Cappuccino frameworks (i think they're great!) but one of the big downers for us is the lack of support for our disabled customers.
  • We are definitely looking into this, I haven't replied because I think it deserves an entire post of its own, which I will be putting together once Atlas work cools down a bit.
blog comments powered by Disqus