DISQUS

alert debugging: Mockingbird, Cappuccino, and what really matters.

  • Rod Begbie · 1 month ago
    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 · 1 month ago
    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.
  • Gustaf Sjöberg · 1 month ago
    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.
  • tolmasky · 1 month ago
    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.
  • Allen Pike · 1 month ago
    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 · 1 month ago
    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 · 1 month ago
    """
    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 · 1 month ago
    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
  • hypermark · 1 month ago
    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 · 1 month ago
    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 · 1 month ago
    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.
  • tolmasky · 1 month ago
    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.
  • Martin Pilkington · 1 month ago
    Of course one issue you didn't cover is accessibility. Are you guys managing to make any progress in that front?
  • Josh Stone · 1 month ago
    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.
  • tolmasky · 1 month ago
    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.