Mockingbird, Cappuccino, and what really matters

http://www.alertdebugging.com/2009/11/04/mockingbird-cappuccino-and-what-really-matters/

by boucher • 17 years ago

75 21 17 years ago

gcv• 17 years ago

Good post, but I wish it addressed the accessibility argument a bit more thoroughly. Although in fairness, it does not seem that Mockingbird is terribly useful for visually-disabled users in any case.

percept• 17 years ago

I've been tempted to use (the impressive) Cappuccino for a couple of apps but based on its lack of keyboard tab focus and performance on slower systems I decided against using it. I like to build simple, accessible apps.

Somebody--Sofa I think--was using it for back-end administration while presenting a more typical interface to public users, and that may be a better approach.

asnyder• 17 years ago

Perhaps you should check out NOLOH, http://www.noloh.com. It's similar to Cappuccino in some ways, yet very different in others. For instance, NOLOH is lightweight and on-demand. It also fails gracefully when JS is disabled in most cases, and is faster overall (this is based on our internal testing. Not trying to start a war). Notice how noloh.com loads instantly without any loading, or delay.

NOLOH also works with tab focus, and is more accessibility friendly. You can read more about our accessibility features at https://www.noloh.com/#/faqs/. We'll be posting major updates to HN in the next week or two, we last posted around a year ago, in case you haven't heard of us.

milestinsley3• 17 years ago

I couldn't agree more with Francisco's comments - it's not native controls that users want, it's controls that feel "native". As someone who used to work extensively on an enterprise app in Flash, I can say first hand that users just expect certain behavior from the UI controls.

I have had to implement countless hacks to circumvent the (many) limitations of Flash; like getting the mouse scroll wheel to work in a scroll view. Once users realize the control conforms to certain usability and accessibility expectations, they are far more appreciative of the app design.

Cappuccino provides a perfect compromise, with controls that look consistent across platforms, but behave predictably, like so-called native controls.

gstar• 17 years ago

I agree also. Francisco clearly has a vested interest in this opinion, and like you say he's absolutely right about implementation making the difference.

I have given a Cappuccino app to people to use, and they didn't even realise there was a difference from the native controls (after the widgets rendered - which DID throw them).

Even though I fundamentally agree that re-implementing UIs from scratch is not optimal, Cappuccino had a valid reason for doing so, and its implementation doesn't harm usability.

milestinsley3• 17 years ago

With the current 'jake' branch and its' imminent merging into master, the framework resources are sprited meaning they all load in one http request (rather than many). This eliminates the fragmented loading of the UI, which, I agree, can throw people at first!

amadiver3• 17 years ago

Besides the mouse scroll wheel hack (which is only necessary for Macs if memory serves), what other limitations did you need to circumvent in order to address scrolling in Flash? I've built more than my fair share of scrollbars over the years in Flash, and the JS-mouse wheel-mac hack is the only hack I've needed. I can imagine that building a custom scroll component in Flash would be easier to do, and the code would be far more clean, than implementing in JS. Am I wrong?

milestinsley3• 17 years ago

I had problems with clicking on the track to jump the scroller to a given position. Also, I find that the memory resources used by Flash when the scroller contains a lot of objects is unacceptably high resulting in slow scrolling; therefore I had to waste time doing some funky lazy-loading stuff also.

I would say that implementing custom scroller in JS is far easier (and reliable) that Flash. And there are plenty of frameworks (ahem Cappuccino) where such controls are included.

But scrollers are just one example of the UI controls the article talks about :)

ugh• 17 years ago

But they don't. Feel native, that is. Scrolling with the scroll wheel is horribly broken in Mockingbird. It does not work like a native control.

It's the details that get you. Sure, look doesn't matter (as long as UI "symbols" are not changed), but behaviour does. Where can I click the scrollbar? What happens when I click where? How fast does it scroll? And so on, and so on. Recreating the native experience is a horrible excercise and you will get yourself killed by thousands of small details you didn't even think of.

mcav2• 17 years ago

It really comes down to whether you view HTML/Javascript as source code or object code.

If HTML&JS is source code, you ought to keep it clean and minimal. You're betting that browsers will evolve to include desktop widgets and other aspects of the "native" experience in HTML tags and Javascript APIs.

If HTML&JS is object code, you're rooting for abstractions over HTML and Javascript, so that HTML/JS becomes assembly language.

I don't mind the extra abstraction. But it's unfortunate that we're adding so many layers of abstraction over a system that wasn't really designed to be used that way.

amadiver3• 17 years ago

I'm curious as to why you feel it's unfortunate to add so many layers of abstraction over the system. Besides the "All abstractions are leaky abstractions" argument, is there any other reason you feel like this is a bad thing? Or is it ruffling your engineering feathers?

mcav2• 17 years ago

Primarily because it's an inefficient abstraction.

Yeah, Moore's Law and all that. But still.

cpr• 17 years ago

It's a little early to tell for sure, but it might well be A Great Thing for JS+HTML/CSS to become the assembly language of the web. If Javascript engines get faster, and CPU speeds keep slowly inching up (looks like Moore's Law has temporarily been repealed ;-), and things like Web Workers become commonplace, ...

scotth• 17 years ago

What does command+clicking in the track do? It works the same way as just clicking for me, unless I'm missing something.

slig• 17 years ago

Here only alt+clicking does something different, on tiger.

DougBTX• 17 years ago

Not sure what they mean, but if you give another window focus, you can Command+Drag the scroll bar, and the window won't receive focus.

stevenbedrick• 17 years ago

I think the author meant "option+clicking", which causes the scrollbar to jump to the precise location of the click (rather than a simple page-up/page-down, which is what it usually does on click).

gps408• 17 years ago

I don't understand why qooxdoo http://qooxdoo.org/ doesn't get more attention. It's not as pretty as cappuccino, sure, but it seems a very nice set of tools.

koenbok• 17 years ago

What I find strange is that people have a tendency to compare Cappuccino to flash, way more then other web frameworks, and what that means.

Mockingbird, Cappuccino, and what really matters

Related Stories