My mom has been asking me about the differences in the way data is displayed in some JavaScript debuggers, so I wrote something up for her.
Wednesday, July 08, 2009
Sunday, June 14, 2009
offline web application cache abuse
I've been a user of hand-held computers since 1997, when IBM bought me a Palm Pilot to use in a customer demo I was putting together. Since then, I've been through a number of Palm devices, and up till last week had been using a Nokia N800 device. This week, I caved, and bought myself an iPod Touch.
One of the main uses I've had for these devices is reading. On the Palm, I used the wonderful iSilo program to convert HTML to some binary format that the Palm reader rendered as good as it could - good enough - even on a 160x160 pixel display. On the N800, HTML content could just be copied to an SD disk, and then you could view it via the built-in web browser using file: URLs.
It turns out that I've been able to find plenty of material over the years, in HTML, that renders well enough on my hand-held devices. Either ready made, or built via scraping, or whatever.
what to use on an iPhone or iPod Touch
So, what are the options for reading on the iPhone/iPod Touch? Stanza is the only generic reader I've looked at so far, and it's not bad. It's particularly nice to have access to FeedBooks and Project Gutenberg books, which can be downloaded and then read later if you aren't online. Compared to Google Books which appears to only support reading while online. There's also Kindle, but I don't have any need to buy books, there's plenty of free content to be had. More importantly with Kindle is the 1995 level of HTML support, and that's a big problem for me; I like to read technical content with code samples, etc.
Beyond generic readers, there are also content-specific readers from content producers like the New York Times, the BBC, and AP News. The BBC one is especially strange. When displaying a full article, they seem to be displaying the same content that's on their web page. Various navigation and other links eating up space in the left and right side of the page. You can double-tap the middle content to get that to zoom, but why wouldn't they do that in the first place? If you actually happen to click a link on the page, even to another story on the BBC, it exits their app, and launches a browser on that page. Amazing, and not in a good sense.
Stanza seems like the most useful reader at present, at least for literature. I'm not really happy about the page-turning metaphor; I prefer to scroll pages vertically. I can probably learn to live with it.
But how can I get my own content on there, or more generally, rando HTML content on there?
EPUB
If you look at the formats of "documents" that Stanza supports, one particular format is EPUB. I've not been able to make my way through the morass that is the specifications surrounding this format, but if you're interested, here's how to get started: an EPUB file is a .zip file, expand with your favorite zip utility; you'll find a number of XML files inside, you can kinda get a clue for how everything fits together by browsing those files.
The "meat" of an EPUB document consists of XHTML, CSS, and image files. Hmmm. Sounds like the web. Could you take some existing web site and easily "EPUB" it?
HTML5 Offline Application Cache
Turns out, there's something in HTML5, and more importantly, available on iPhone and iPod Touch devices, that can take an existing web site and make it available even if you aren't connected to a network. There is a W3C Working Group Note for this available as"Offline Web Applications". Apple has documentation on their support of this in the document "HTML 5 Offline Application Cache". See also the WHAT-WG version under development.
The basic idea is to do the least possible work. You need to create a new "manifest" file which lists all the files which should be cached for offline usage. And you need to identify that file in the <html> element of your document. That's all! The browser will arrange to cache all the content listed in the manifest.
I decided to try out how well this works with Mark Pilgrim's "Dive Into Python" book. I downloaded a copy of the book as separate HTML files, ran find on the result to create the manifest, whacked the <html> elements with a multi-file search-and-replace in my text editor, set up the files on my machine's local server, browsed to it from my iPod Touch, worked like a champ.
It seems to take 20-30 seconds to get all the files downloaded, and during that time there is no indication of what's going on in the browser. I was tail'ing my server's access log to tell when I was done. Presumably some of those events specified in the WHAT-WG version of the spec will help out with issues like that. After the files got downloaded, I could turn the wifi off on my device, and continue to browse the content.
"Dive Into Python" seemed like a good test case; non-trivial markup, especially code snippets; a significant amount of content (3MBs fully expanded), and presumably not really designed to be read on a hand-held device. I'm satisfied with the results, though I think most people will find the font sizes too small. The font sizes are too small for me when displaying in portrait mode, so make sure you try landscape as well. Tough decision point there, make the fonts bigger and then you'll either get text wrapping or have to do side-to-side scrolling.
I've got the files available on one of my servers, http://diveintopython-cached.muellerware.org/, which I'll leave up until my hosting provider kills me - each access to the page from an enabled browser will download the whole book (if it's not already been downloaded). Presumably this might work on other WebKit-based browsers, like the one on an Android device, or the Palm Pre.
On the iPhone or iPod Touch, after displaying the initial page, add a bookmark by clicking the + button, and then the "Add to Home Screen" button. Remember to wait 30 seconds or so after the initial page load before doing this, to make sure all the content gets downloaded. This will add the book as a new "app" on the main application screen. I've also done the appropriate horkiness to get the cover of Mark's book to show up as the application icon.
questions
This experience raises a number of questions regarding the HTML5 Offline Application Cache support:
How much space does the browser set aside for this cache? I assume there's a fixed upper limit for the cache, but does it compete with all other browser caching? Or is there a per-site or per-url cache limit?
How can I be informed when my cache content is thrown out of the cache? Is the entire set of files listed in the manifest thrown out atomically?
Is there enough functionality in the existing and proposed APIs to make reliable use of this capability?
I'm left wondering if it wouldn't just be better off to provide a full-function JavaScript API to the cache in general, although clearly this could be done as well as this declarative approach. My fear is the declarative approach might take you 80% of the way there, but leave out critical capability in that missing 20%.
More experimentation required. Have at it.
Or maybe this is just simple abuse of the capability. Instead of caching web sites, you could certainly get more control by having all the book content stored in a client-side SQL database, and then build an HTML application to navigate through it. It's just a lot more work.
Thursday, June 04, 2009
debugger friendly
(this is a bit of a followup to my previous blog post - "debugging")
Hit a milestone yesterday, submitting my first patch to WebKit, in support of "Bug 25474: Show the filename and first line for '(program)' in the Profiler/Debugger". The patch provides the same support that Firefox provides to allow JavaScript eval() invocations and Function() constructor invocations to name the code they are injecting into the environment, by adding a comment to the source interpreted:
//@ sourceURL=some-url-goes-here
Presumably some-url-goes-here is replaced in your source by some kind of moniker that will be useful to you.
Why is this useful? Here's what your "list of scripts" looks like when developing a Dojo app, without this support: [link]; here's what it looks like with this support: [link]. A little more useful.
Last month, another interesting feature for debugging was added to WebKit - the ability to 'name' anonymous functions, after they've been created. A full description of this, and the value it provides, was written up a blog entry "Building a Better JavaScript Profiler with WebKit". In a nutshell, you can add a property displayName to a function which will be used as it's name in the debugger and profiler if the function doesn't otherwise have a name.
Quick notes:
- the sourceURL feature is not yet committed to WebKit, and even if/when it is, would only be available in WebKit nightlies.
- the displayName feature is only available in WebKit nightlies right now.
- the sourceURL feature does not currently work with the WebKit profiler, just the debugger.
- the displayName feature works in the WebKit profiler and debugger.
- Firefox supports (and invented!) the sourceURL feature, but AFAIK does not support the displayName feature.
- Dojo currently has support for sourceURL feature, but only if you're running in a Mozilla-based browser - chime in here for WebKit support.
- Dojo has no support for the displayName feature - chime in here on that issue.
enhanced object display
Here's what I'm going to look into next:
In the WebKit bug, "Bug 25724: Incorrect collection output for Javascript console evaluation", the reporter claims that the output when displaying the result of a jQuery function invocation is incorrect. Incorrect isn't fair; it's better to say that it's not what the user expected, but then, as jjb mentions in comment #6, "we can't read [the user's] mind".
It's certainly true that the current output isn't useful, and it's certainly the case that the developer of a debugger can't read a user's mind, so the obvious answer is to let the user decide how to see their output. In Smalltalk, the debugger would call debugPrintOn: instead of the more typical printOn: method (printOn: being analogous to toString in Java or JavaScript). This allowed developers to provide a debug-friendly version of the human-readable representation of an object, without impacting runtime code. JavaScript debuggers should do the same thing.
The other bit that needs to be done is to somehow augment the "properties" that you see associated with an object in the debugger. Literally what you see in the debugger is the implementation goop of an object. Not terribly useful, especially if values associated with objects are computed lazily, via a function invocation. Seeing a function instead of perhaps the lazily computed value provides little value (though it is obviously much safer!).
What I'd like to do is provide an optional method on a function which can be called to obtain "debug properties". For instance, the debug properties for a jQuery object might return the array of matching DOM elements. DOM elements themselves might return, instead of the goop currently returned, their parent DOM object, their children, and their next/previous siblings. These DOM element's might have a "debug toString" that actually showed the HTML representation of the node (which the debuggers already support in some cases).
Of course feel free to post additional ideas on this to the existing but report.
soundpoints
Here's something I did back in the Smalltalk days; would be fun to do this for JavaScript as well:
We all know what breakpoints are, but I extended the concept in Smalltalk with soundpoints (stole the idea from somewhere). Instead of having the debugger pause the execution of the program when a breakpoint is reached, the debugger would play a sound when a soundpoint is reached. The nice thing about this capability is that you get some feedback without having to stop your program. You can set soundpoints to let you know when you venture into code you're not expecting to venture into (some kind of beep/boop), or set a very short blip sound for a soundpoint you expect to hit a lot - giving you a kind of geiger counter. Since WebKit already has programmatic support for playing audio, the "hard" part of this is already done. What's needed is to integrate into the debugger framework. OK, that is the hard part.
As sort of a side issue, when I did this in Smalltalk, I was able to do this with user-land code; I didn't need to be some kind of core developer to get the function added. That's not true today in WebKit. You need to modify existing WebKit code to add functionality like this; there's no simple way of me just adding it to my environment. That would be a nice thing then also, having a way of extending the debugging environment through plugins or equivalent. See "Bug 24273: Inspector Plugins or Extend Capability". Also note that I believe FireFox has or will have the ability to extend FireBug via plugins. I think it's too much to ask to have portable plugins, at this point, but something to think about.
what else
What else can we do beyond all that? What are your frustrations with JavaScript debugging?
Tuesday, April 28, 2009
debugging
Apparently, I tend to write a log about debugging. To me, it's the other "fun" part of programming, the first fun bit being writing code to begin with. Debugging comes into play, in that oh so rare case, where the code doesn't do what you meant it to do. Like writing code, I tend to view debugging as an art, more than a science. Especially after seeing how some people debug code - I've got some scary stories I can share over a beer.
And so it was interesting to see the subject of debugging come up in relation to the issue of "tail calls" in Python, in Guido's post "Final Word on Tail Calls". Specifically, Guido claims that usage of tail calls "does make debugging harder". No doubt, assuming your debugger doesn't realize what's going on.
Guido also gives an example of why I like debuggers:
The elimination of stack traces for some calls but not others would certainly confuse many users, who have not been raised with tail call religion but might have learned about call semantics by tracing through a few calls in a debugger.
Learning is the key. There is really no better way to visualize how your program operates than to watch it running, line by line. Typically, if you have everything set up right, you can also learn how those mysterious frameworks and library functions you're using work as well, by tracing into them. This is especially important if the frameworks and functions you're using are underdocumented; which they probably are.
Debugging also came up in reference to new WebKit goodies, as mentioned in "WebKit's week - #8", and more specifically, "Bug 25171: It should be possible to manually set the name of an anonymous function". I tried a little test, but noticed the debugger itself doesn't really have a place to make use of this information; but the profiler does. My little test made use of a decorator, like so:
function function_named(name, func) {
func.displayName = name
return func
}
You could use a function like that to wrap anonymous function usage if you don't otherwise hold onto the function in a variable or property.
I LOVE to see changes like this, made by the implementations. Eventually something like this might make it into a standard, but we need implementations to figure out the best way to do it before we standardize on it.
Other candidates to aid in debugging:
toStringDebug() - this method would get called, if available, from a debugger when it's showing you a value. Stolen from Smalltalk's #debugPrintOn: message that did the same thing. As in Smalltalk, you'd add this method to Object, with the default implementation returning the result of this.toString()
Ability to "name" eval()'d code. In WebKit's Web Inspector, these show up as "(program)" in the scripts dropdown. FireBug is a little better, it shows you the first bit of the eval()'d code. While playing with a framework that used eval() all over the place, I ended up using a convention of making the first line in the script that was eval()'d a comment with a 'file name' at the beginning. Very useful for FireBug. But I think we can do better.
Why not recognize a keyword in a comment instead?
// @eval-name "foo-blatz" ...
That would end up showing the name foo-blatz along size other script names wherever such script names get displayed.
Class hierarchy browsing; many of the JavaScript frameworks have a notion of building "classical" class hierarchies in JavaScript. Whether that's good or bad, dunno, but it's the way it is. It would be nice to be able to visualize these. Since each of the frameworks does things differently, there is no single way to handle this. Some options would be to invent some new meta-variables like the examples above that you could augment your "classes" and maybe even "values" with - __class__ property on an object points to it's "class", __superclass__ on a a "class" points to it's superclass, etc. Perhaps better would be a way to allow each of the frameworks to define it's own viewers by allowing the debuggers to be extended with additional code wholesale. FireBug already does this, and you could presumably hack WebKit's Web Inspector yourself to do this.
What else?
Wednesday, April 22, 2009
nitro_pie
One of the things I wanted to start doing in the new job was to play with the JavaScriptCore framework. But it's a C language framework, and I don't typically associate C with "play". Good news is, if there's a C API, then there's a good chance you can talk to it from Python via the ctypes module.
I started down that route a little over a month ago, and it's gotten to the point where you can do some non-trivial things with it, so I got it all cleaned up, tagged, etc. It's called nitro_pie (Nitro is the new sexy name of JavaScriptCore), is available up at GitHub, with a downloadable .tar.gz available on the downloads page.
Here's an example of what you can do with it: nps.py; nps standing for nitro_pie shell. This Python program takes a JavaScript file name as a command-line argument, and runs it. It injects a new function, print(), into the JavaScript global environment, so you can actually see it do something. And of course that function is implemented in plain old Python. Here's "Hello World", which does what you would expect under nps.py:
print("Hello", " ", "World", "!")
Couldn't resist writing a simple benchmark to sum numbers from 1 to ?, and comparing Python and JavaScript:
--------------------------------------------------- Python --------------------------------------------------- sum(100): 5050 ... sum(100000000): 5000000050000000 real 0m30.397s user 0m29.799s sys 0m0.126s --------------------------------------------------- JavaScriptCore --------------------------------------------------- sum(100.0): 5050.0 ... sum(100000000.0): 5.00000005e+15 real 0m7.685s user 0m7.468s sys 0m0.081s
The floats you see in the JavaScript version are because JavaScript only has floats. Well, kind of. One of the things I learned was that JavaScriptCore actually internally supports 31-bit (or so) integers as well (as tagged pointers). I suspect the conversion to float in this case happened when I converted to a string at the end.
Another interesting factoid I discovered, not having used eval() much in JavaScript:
eval("{a:1; b:2}") == 2
Can you see why? Here's a hint. The correct syntax for what I had intended was:
eval("({a:1, b:2})")
Usual caveats apply; early code, it uses ctypes so will occaisonally go all Bus error-y on ya if you're sloppy, not many diagnostics, etc. Only runs on Mac OS X, as that's the only place I know of that has a separate JavaScriptCore library. But good news is, you just need the nitro_pie.py file, because you already have JavaScriptCore and Python installed.
I also belatedly discovered that Apple already ships JavaScriptCore bindings for Python, which you can get by doing an import JavaScriptCore But that's only the raw bindings, which doesn't take too long to implement - making them usable is the real work here.
So now that I've got this beast, it's probably time to start playing with the ServerJS stuff again, especially since no one else was looking at JavaScriptCore.
Wednesday, April 15, 2009
shiny simian scripts
We know them as Greasemonkey Scripts, but in Aaron Boodman's recent blog post, he says the new name may be "Content Scripts". Kinda boring. How about Slick Gorilla Scripts? Shiny Simian Scripts? Ach, "Content Scripts" sound pretty good I guess.
Aaron's post is chock full of meaty information; looks really good from 50K feet. Nice to see multiple files will be supported, including .css and resources like images.
I still use Greasemonkey for a few scripts I've written, but found the environment a bit limiting to get into it too deeply. Debugging was difficult, installation/deployment a bit unwieldy. And of course the endless issues having to do with writing screen scrapers, reacting to changes in your target's pages. I tried writing a few scripts for the Moz-based browser on my N800, which supports a flavor of GreaseMonkey via an system-installable update, but that was really painful. I hope we see a simpler workflow for developing these extensions, eventually.
The reason I'm so interested in this stuff is that I think user-scriptability provides a big paradigm shift. Much like writing editor macros for emacs or XEDIT or similar, it transforms an already powerful and useful tool into an extendable one. If you combine this sort of extensibility with the ability to publish/deploy and install these extensions easily, you have an actual platform on your hands.
It's easy to imagine, for instance, the sort of "content scripting" you could do, might subsume the whole "mashup" scenario; kind of flip it on it's head. Instead of having to host an environment to pull and push content from other environments, you can do it right from the primary content site.
Eventually this drives us to the point where the web applications we use are actually installed (ok, cached) on our machines, as extensions, and just push and pull data via HTTP/XMPP/whatever to data/service servers as needed. Of course, we've had a good 15 years of being able to do this, in theory, and are still stuck with icky, unusuable web sites that trap our data behind inscrutable wads of HTML. But things seem to be changing for the better here, over time; REST and all.
Something like Giles Bowkett's Hacker Newspaper could just be an extension, instead of having to be a 'site' with a 'server'. Who wants to deal with that junk?
Beyond all the content scripting stuff, Aaron also mentioned: "There is a team in Chromium working on an out-of-process version of the web inspector." This is great news. WebKit's Web Inspector is quite useful, but as an "in browser" debugger, it is also clearly totally unsuited for debugging on small devices. You know, like all those devices that are using WebKit? An external debugger is required for such situations. Something like Drosera. Both modes of debugging are nice to have - in browser and external; I want them both.
All GREAT stuff. Of course all of this is for Chrome, and not for WebKit. Which makes you start to wonder how we can get all this stuff into WebKit so all the WebKit consumers will have access. Either that, or start considering Chromium to be a platform to consume instead of WebKit. If these Chrome extensions heavily depend on things not already in WebKit, like V8, the multi-process model, etc, there would be even more reason to consider Chromium as the lower level platform rather than just WebKit.
Tuesday, April 14, 2009
ordered javascript properties
So all this time, I believed what I had read regarding the ordering of properties when enumerating JavaScript objects with the for...in statement, with this being a typical description:
A for...in loop iterates over the properties of an object in an arbitrary order.
That's from the Mozilla Developer Center JavaScript reference.
Turns out that's not quite true. See John Resig's blog post "JavaScript in Chrome", and scroll down to the section "for loop order". In particular, John writes: "All modern implementations of ECMAScript iterate through object properties in the order in which they were defined. Because of this the Chrome team has deemed this to be a bug and will be fixing it." Follow the links to the bugs John points out in his blog post for more discussion.
I couldn't resist trying this out myself, so created a little test case, here. WebKit Nightlies and FireFox 3.0 behave the same for all the cases, but Opera 9.23 acts a little differently in one of the cases.
John makes a couple of points I can't agree with, in his comments in the Chromium bug that he referenced.
The specification does not define how an implementation should handle it - therefore an implementation should conform with other implementations.
What? How does not having an explicit definition in the spec imply that all implementations should conform with each other?
The argument that they're doing it to "keep the engine fast and lean" is bogus. There are two other, faster, ECMAScript engines out there: SquirrelFish and TraceMonkey and they both implement the looping indentically.
John is referencing a previous comment which claimed that V8 did not respect the 'definition order' because doing so could impact memory usage and/or peformance. But the rationale John makes is that since there are two faster engines which DO implement the 'definition order', the memory/performance rationale is bogus. Which makes no sense of course. I would imagine the typical implementation of 'definition order' would trade space over speed, so you could make the property access "fast enough" by spending some additional space to maintain the order as well as the presumably speedy hash access. Complete guess on my part. But to me, it's hard to imagine that implementing 'definition order' isn't going to cost you SOMEWHERE, over not implementing it. I'm cheap, I don't like to pay for things I don't need.
So not only was I surprised by the property ordering, I'm kind of sad because it means JavaScript has some built-in waste for a feature few objects will probably ever need. Kind of like Java's monitors in every object. Ah well.
A few folks pointed out to me that upcoming EcmaScript standards would likely standardize on this ordering behavior. While it's difficult (for me anyway) to track down EcmaScript standard stuff, I did find this set of drafts which seemed ... recent ... and looking at the "23 Feb 2009" version, you can see phrases like "An ECMAScript object is an unordered collection of properties" (page 14) have been changed to "An ECMAScript object is a collection of properties". Hardly a ringing endorsement of defined property ordering, but a step in that direction, no doubt.
So, I guess change is coming. Next question, how can we make use of this?
One thought is with JSON. Typically with JSON you think of object definitions with key/value properties, all defined "at once". Meaning things like "streaming" JSON objects don't really make sense. Only now, maybe it kinda does. Or you could do something like add a property to an object first, called something like "__type__" which would provide some shape information, which a serializer could make use of, because it would see that before other properties.
That's nice. And is fairly logical. But the memory/performance impact will probably always bug me.
Wednesday, March 18, 2009
new job: WebKit
Well, it's nearly Spring, which means, for me, a new job. Right? Seems that way, looking back over the last few years. I've had some difficulty carving out some space for myself in the groups I worked with, what with the great talent already working there. Many chefs in the kitchen and all that.
For this new job, I'm on my own, at least within IBM. I'm now IBM's "WebKit Center of Competency" person. Officially, what I put on my Moo cards and in the corporate directory was "WebKit Stuff".
What does that mean? Not sure yet. But apparently WebKit is interesting enough now, that my bosses thought someone should focus on it full time. I guess I kinda helped out there, having sent various notes over the years, to my new bosses, that said things like "Why aren't we doing anything with WebKit?!?" My new bosses are Dave Boloker, and his boss is Rod Smith. I've moved over from Rational to the Emerging Technologies group.
There is some ongoing work in Emerging Technologies that is very much browser-centric, and so I'm going to be hearing this week what they're up to, and to see what I can do to help. Beyond that, my assumption is that in the future we'll have more folks needing to integrate with WebKit in various ways, so I'll start laying some groundwork for IBMers to help make that a little easier.
Beyond that, I'm particularly interested in focusing on JavaScript, and making JavaScript developers' lives better. My secret dream is to make the browser a better Smalltalk than Smalltalk. You gotta have a dream.
I was ecstatic to hear that my management expects me to be contributing code back to WebKit. One thing I haven't done in IBM is any open source contribution. There's clearly no better way to learn a code base than to have to tinker with it, and then submit that to public shaming.
So all in all, this is really shaping up to be a great job for me; subject matter that deeply interests me, the open source angle, and of course the fact that it's a scary huge mound of mainly C++ code that I'm completely unfamiliar with. What more could you ask for?
I'm definitely a little bummed that I won't have a chance to work with Dave Johnson, who will be starting a job with Rational at IBM at the end of the month. It's a small world though - I think Dave will be sitting next to me, and will be taking a spot on the Rational CTO team, which is the team I just left.
I'll also be a little bummed if something were to happen to one of my new Emerging Technology teammates, Sam Ruby.
Thursday, February 26, 2009
size matters
Fellow IBMer Bob Blainey recently posted a blog entry "Are you a Pakled?" which touched on software bloat. This is a subject near and dear to my heart, burned into me after spending a good five years or so in the embedded software space.
At the time, the devices that we were targeting would typically have something like 2MB ROM and 2MB RAM available. Think of the ROM like hard drive space, and the RAM is the memory in a computer today. We worked with devices that had less memory, sometimes, and near the end of my run, worked with devices that had much more memory available. But the 2/2 story was sort of the rule of thumb.
That's not a lot of space, so you worry about every byte. You worry about every new library that you need to add to your runtime. Not just in terms of it's disk footprint, which ate ROM, but the runtime footprint, which ate RAM. There were always hilarious situations where we'd be talking to product groups with no embedded experience, where they'd die laughing when we told them their library had to fit in 10K bytes; or it would be us laughing when they told us their runtime only required 1MB of RAM.
If you enjoy the "solving puzzles" aspect of software development, this is just an additional challenge on top of all the other challenges, which made it, for me, a terribly fun working experience.
You can imagine the "sticker shock" that hit me, when my first position after leaving the embedded world, involved J2EE. Whoa. And the sticker shock continues to this day, in every new piece of work I'm involved in. But it's not just me; most of my colleagues back in the embedded days seem to experience this sticker shock in their day-to-day jobs, which is something that I think most developers just don't think very much about. Like the kid in "The Sixth Sense", we see bloat - everywhere.
It's heartening to see the resurgence in interest in embedded development, in places like the iPhone and Android, since I hope this means we'll be seeing a lot more folks taking an interest in software bloat.
Aside: the Pakleds, referenced in Bob's post, were one of the most memorable races for me in the Star Trek series, but I wasn't able to find any video clips from the show. I did find a little audio clip though; this is Riker asking a Pakled what they need.
Wednesday, February 25, 2009
web ui progress
The hotness of the day (well, yesterday) appears to be video at 280atlas.com (permalink at Viddler here). It's technically very impressive. But I'm also a bit saddened. I worked on similar technology 15 years ago, for desktop applications. You know what I'm talkin' 'bout. I won't say the word.
Sad because, even 15 years ago, web browsers were around, in some state. Why has it taken this long for things to progress this far? It's nuts. Seems like a lost decade, to me. Of course, it's not like we were even really innovating in this space, back then, either. Interface Builder goes back even further.
Feh, always with the rock throwing. So let me shine a little brightness, as well.
First and foremost, hats off to the folks at 280north.com. Getting all this to work on the clumsy web browsers we use today is surely no small feat. It looks gorgeous. The layering is interesting, built on Cappuccino and Objective-J. Stuff to look into.
Two things I saw in the demo that I liked, in terms of UI constructs: "Layout Support" and "Split Views".
The "Layout Support" appears to be similar to what we used to call "Form attachments", back in the day, that allowed you to specify how widgets were attached to things - other widgets, parents, etc - and how they would resize. Ours were based on Motif's XmForm constraint resources. (Aside: isn't it hilarious that the first reference I found to XmForm was in the lesstif online doc?) Although kind of crazy complicated, and really easy to screw up when you were coding by hand, and requiring you implement a constraint solver IIRC, you could do some incredible stuff in terms of making windows full of widgets which responded in a nice way to resize requests. And even just doing (non-absolute) layout by specifying which things were next to other things, and letting the system figure everything out based on default sizes.
"Split Views" are similar to what we called "Split Panes" (think that's what we called them), that were a late edition to our product, but to me added the last little bit of UI goodness for users. Instead of providing either fixed width, or perhaps proportional width child windows inside a parent, Split Panes gave users the ability to resize those child windows as they saw fit. After they got added to the product, there was really not much else that I found I needed, to be able to whip up a nice little UI with intelligently resizable innards. Separate the top level bits of a window into Split Panes, and then layout those children using Form attachments, or perhaps recurse with another Split Pane.
Sure would be nice if these were native capabilities provided by our browsers. CSS (and Tables!!) and Framesets just don't cut the mustard. Ah, not to worry, we'll have a <video> element we can use in our applications soon, and that will more than make up for the lack of these other, much less interesting capabilities.
Subscribe to:
Posts (Atom)