Mockingbird, Cappuccino, and what really matters
alertdebugging.com
alertdebugging.com
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.
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.
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.
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 :)
The second issue seems more likely to have been an issue with processor load rather than a memory, I'm guessing? I usually solve the issue with using TextField's cacheAsBitmap property. It uses more memory, at the expense of greater processor load. I develop on a low-powered Mac, and have never been disappointed by the tradeoff, but YMMV. Sometimes, playing with the AntiAliasMode of the TextField has unexpectedly good results (processor-wise), but I admit it's very fiddly :)
Completely agree on the framework front; Abobe's attempts to solve UI issues in Flash have lead to an even more fractured dev response. Cappuccino's UI looks extremely clean, and seem to function remarkably well, without sacrificing so much on the filesize/response vectors.
Again, just geeking out; I've been (and continue to be) in that position more times than I'd like to count in developing for Flash. Thanks for the great comment :)
When I used to do Win32 programming, I'd usually cache a bitmap and scroll that. For larger stuff though, lazy loading all the way.
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.
Yeah, Moore's Law and all that. But still.
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.
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.