Bits about technology, user interface design,
parenting, and other haphazard musings
Manu Sporny started a micro-data (RDFa/Microformats in HTML) thread on the WHATWG list that is worth reading. Threads on this topic dealing in specifics, realities, sample markup… you know the stuff that makes it possible to get your hands dirty to understand how it all works… are hard to find.
I have to be honest, I'm starting to tune out the HTML 5 meta-discussions (no, not that <meta>) again. I'm still reviewing spec changes as they come in and reading the related threads… but the emo-drama that people insist on manufacturing… “is such a buzz-kill.”
Burried in Norman Walsh’s thoughts on whether AtomPub has “failed” or RSS is “dead” is a simple and oft overlooked use-case for syndication formats:
If your experience of syndication was that you lived in your favorite feed aggregator, refreshing it constantly so that you could get the latest “hot link” or one-liner from your friends the minute they happened, then sure, I can see how Twitter is a replacement.
That’s just not how I ever used syndication. I never used (my) reader more than a few times a week after the initial technology excitement wore off. I use it to collect and aggregate longer, more thoughtful pieces from users or sites that offer a good signal-to-noise ratio on the topics I'm interested in.
Emphasis mine because it is amazing how many feed readers miss on this feature.
Mercurial is coming to Google Code. Known simply as hg to developers, Mercurial is Python based and its command set is closely patterned after CVS & Subversion.
Ask MeFi helps someone find publicly available data sets. I didn’t realize Amazon was hosting any large data sets, but they have a pretty decent collection available for free to AWS users and (it appears to me at least) the general public.
Last month I noticed that Newsmap was redesigned but I didn’t exactly know why or what changed. Today I stumbled across a blog post from the developer detailing the changes made. I remember the day I discovered Newsmap from k10k… cue dusty 1920s film music.
In A List Apart #282, Stephen P. Anderson’s “In Defense of Eye Candy” should've really been titled In Defense of Design but I guess that wouldn’t pull in enough lurkers from their feed readers. The gas station bit in that piece is a genius way to approach design & trust with any audience.
Oliver Reichenstein proposes that the core concepts of iTunes UI might be useful in a desktop web browser context. Overall, sure… it is worlds better than what most browsers pass off as “bookmark management.” For instance, I'd settle for just being able to sort a collection of bookmarks in A-Z order in Safari (seriously, that feature isn’t there.) I do have to admit to having some blinders on in this area… I exclusively use delicious.com to manage my long-term bookmarks and only use the in-browser bookmark management as a temporary shelf and toolbar (for JavaScript bookmarklets).
Play multiplayer versions of Leisure Suit Larry, Police Quest and Space Quest in your browser… if your going to chat with random strangers you might as well do it in a leisure suit.
Continuing our Daily Notes meme.
I skipped writing Daily Notes on the weekend so I could:
Dave Shea becomes yet another well respected voice in the design community to get behind HTML 5. The comments are actually more interesting than original post, if only because they reveal both the community pulse and a few XHTML myths that persist in the HTML developer community. The comments on how parsing XHTML is so much easier than HTML are interesting… I wonder if those folks are referring to internal/company-specific websites coded to much stricter standards rather than the usual XHTML junk found on the web.
The discussion on “private browsing” modes and HTML 5’s localStorage was a good read if subjects like “RFC 4239 and IANA MIME Media Types” don’t usually do it for you.
In my never ending quest to find no frills polling apps, I see there’s a simple survey app based on Twitter now.
The amount of tweaking one can do around the UI bar in Internet Explorer 8 or in Opera 9/10 is impressive. Doing the more advanced operations in Firefox or Safari for Windows requires themes, extensions, “extreme” hacking, or forking the project altogether. Typically, I'd say “less is more” but personalization helps a user take ownership over their software and that can be a positive thing … maybe even worth the programmer time and extra on-disk/in-memory footprint for these features.
Jesper posted a link+commentary+idea+random thread dump in a format that reminded me of the “old” blogs from the mid-to-late 90s. I have no idea why bloggers stopped using this format but I assume it is because it is not SEO friendly and guaranteed to piss off most text-ad content discovery algorithms. Oh well.
In the spirit of reviving it… and pissing off something or someone… here’s some random notes for today. (Let’s see if I can make a habit of this)
Somehow I ended up at Mozilla bug 190550 today — “Option to disable link outlines when using mouse.” Doing a quick test just now it looks like Camino2, Firefox 3, Internet Explorer 6/7/8 place focus borders around links when activated but Chrome 1, Safari 4, and Opera 9/10 don’t. (Operating System doesn’t seem to matter for Firefox either, it does on OS X and Windows Vista) Anyone know what the history of this UI feature is? do users still get value from this?
A Working Draft of “Usage Patterns For Client-Side URI parameters” was released on Wednesday (April 15th, 2009) and the TAG is soliciting feedback. I've seen more and more modern web applications using the fragment identifier (#) to collect and pass data around, I'd highly suggest anyone using this method take a look at this document. Admittedly TAG covers a lot of stuff that I imagine your average web developer would classify as “some rocket science, astronaut crap” but this is a rather practical subject and the draft language is easily digested.
I don’t know what took me so long, but I finally upgraded to LaunchBar 5… the iCal integration alone is worth it.
I can see that Twitter is trying to fix the whole “broken back button” issue with their [more] feature. I now see stuff like this in my status bar:
http://twitter.com/home?max_id=1546356981&page=4&twttr=true
Don’t think they've got quite right yet, because Safari 4 still has no idea the page content has changed.
Jesper and I discussed two convergence products today: Beer Chips and Maple Bacon Coffee
I've started maintaing a page to capture a list of every web browser I can remember using for more than a few minutes (so I could rule out things like web kiosks). This isn’t meant to prove I've used more browsers than you, I know several folks who've mostly certainly used way more than me, I just wanted to have a record of it somewhere. It was particularly fun to consider all the browsers I tried out on lesser known operating systems (QNX) or devices (like the Newton.)
Sam Ruby’s background presentation for a panel on the future of browsers to be held at the March 22-24 2009 W3C Advisory Committee meeting:
Current state: HTML is being developed outside of the W3C by a number of browser implementers, excluding Microsoft. The prevalent feeling amongst those that do so is that if the W3C doesn’t adopt their spec, the W3C will look dull.
Desired state: Many groups representing many different disciplines and constituencies contributing to HTML. Documents with the requisite amount of consensus are adopted by the W3C independent of their source.
Getting from here to there will be confusing. Those with a vested interest will portray portions of the truth in a way that will sound very plausible. This is an attempt to level set.
It continues with a mostly completely history of HTML 5, though I think there are some gaping holes worth filling in (e.g. before WHATWG was formed HTML 5 was pitched to the W3C and they rejected it twice by vote in the same meeting, the history of <canvas> seems useful to point out, some background on key HTML 5 implementations as they shipped.)
I'd also suggest that the negative tone it takes with Microsoft’s efforts are unnecessary. I think some members would like a more reassuring feeling that Microsoft isn’t going to pick up their ball and go home. For example, Microsoft has not been particularly excited about <canvas>, one of the reasons given was patents. At one point an effort was made (largely driven by Microsoft) to remove <canvas> from the HTML 5 spec, based on the idea that it was out of scope from the HTML WG’s charter. This behavior was seen as “same old, same old” by some. Personally, I can’t see them backing out of the effort… they've contributed in good faith so far. (Also, at last check, only Apple has disclosed any patents pertaining to HTML 5 to the W3C. Really?)
No concrete action is asked for today, again, this is just a level set. Blocking Last Call until consensus is reached and supporting the publishing alternative documents as Working Drafts will be important down the line. Note: it is not important which spec “wins”, just that there is enough competition to keep everybody honest.
/me fetches popcorn
Douglas Crockford, perhaps best known for standardizing JSON, launched another shot across the bow of HTML 5 on his Yahoo! 360 blog titled “HTML 4.2”.
This isn’t the first time Douglas has expressed his dissatisfaction with the HTML 5 effort. Back in 2007 he wrote piece called “Fixing HTML”, which placed a high value on distributed extensibility by blessing unknown elements and attributes.
In, “HTML 4.2”, Douglas argues that HTML 5 has too many experimental features, which increases the likelihood the standard will be too “complex, insecure, and unreliable.” He compares the state of HTML 5 to the ES4/ES3.1 situation (if you’re scratching your head see wikipedia’s sumamry or John Resig’s recap). Douglas doesn’t put forth a specific proposal but I believe he’s mostly interested in the HTML 5’s vastly improved conformance and error handling language.
There’s a vocal group within the HTML 5 effort (and to some extent from outside groups at the W3C, TAG comes to mind) that are thinking along the same lines as Douglas. For some time work has been progressing on a more author friendly HTML 5 language reference document and more recently a document which defines the language semantics and syntax without all the “messy details” (like DOM behavior.) In the last couple weeks, Ian Hickson started working on an alternate CSS stylesheet for the HTML 5 specification that is intended to make it easier for web authors to read the document. This can be seen by using the single page version of the spec on WHATWG and a browser that supports alternate stylesheets (like Firefox.)
There’s another effort brewing out of Mozilla to reduce the HTML 5 specification to something more akin to “HTML 4.1”, you can follow along at home by jumping into this thread: An alternate take on HTML5 on Mozilla’s platform development list.
There’s a couple of issues in the HTML WG’s tracker that are following these developments:
It is unclear whether these approaches are of interest to Douglas since he doesn’t mention them in the “HTML 4.2” piece.
These are my off-the-cuff 1am commentary about this whole situation.
First, the existing scope and organization of the HTML 5 specification appears to bother enough folks that something will likely have to give before it goes to what the W3C refers to as “Last Call.”
Second, the specification now thought of as HTML 5 was originally called “Web Applications 1.0” for a reason. I’ll leave it to you to noodle on the differences between hypertext documents and applications.
WHATWG has largely prioritized implementations for attention. WHATWG at its core is a “cabal” of implementors but the focus on implementations is seemingly rooted in common sense based on experiences in the CSS WG and XHTML 2 WG as well a colorful history of implementor behavior regarding web browsers (a perceived elephant in the room I won’t touch on.) In general this approach has been quite beneficial to features like <canvas> that have amazing potential and ran the risk of becoming a vendor-specific feature that could be used for platform lock-in.
In some cases the approach seems absurd. The new <bb> element comes to mind, with its makeapp attribute that seems to have been specified solely because WebKit was intending to ship a feature that depended on similar behavior. I'm a big fan of the whole “Site Specific Browser” (think Fluid) concept but I imagine it is difficult for the average web author to see the value in standardizing what seems like a highly experimental syntax/API (though I do believe the general concept is quite sound.)
Finally, I'm somewhat bothered that Douglas hasn’t been more active within the groups working on these standards. He clearly feels pretty strongly about it and he certainly understands a thing or two about technical language design.
Participation in either WHATWG or the W3C’s HTML WG doesn’t have a particularly high barrier to entry. To be fair, I understand that Yahoo! has a rather strict position on involvement with the W3C — only one employee may do so… this was true as of 2007 at least. And while I appreciate WHATWG’s lightweight process & rules… there are some legal gray areas (e.g. patents) that are likely preventing some corporate folks from being able to contribute.
Once again, the cogs at the W3C have cranked out an updated HTML 5 Working Draft. There’s also been an update to the non-normative HTML 5 differences from HTML 4 notes, which are particularly useful for authors new to HTML 5.
Sadly it looks like we didn’t invest the time in a highlighted differences document or summary of changes as we did with the previous working draft. That said, it is a huge effort to undertake and I'm not sure how much feedback, positive or negative, we actually got on the previous supporting publication info documents.
If you did like the color-coded differences document, there is an ongoing highlighted differences stream you can follow on Twitter. It is a little more user friendly than parsing through the the raw commit notices sent to public-html-commits. If you'd like a higher-level stream than that, I'd highly suggest tracking Mark Pilgrim’s “This Week in HTML 5”. (And if you'd rather just laugh the entire exercise off then a visit to “Last Week in HTML 5” is in order.)
Besides tipping your hat to the editors, implementors, early adopters, and other working group participants — a big thanks should go out to the HTML Working Group’s staff contact, Michael™ Smith and the various groups at the W3C (like the Systeam) who maintain the infrastructure to create and present this material to the public.
Back in December 2008, Google added a Task list widget to Gmail. For my needs their task list implementation hit a sufficient sweet spot: a bare-bones hierarchical list maker with decent keyboard navigation.
I was a little bummed that you could only use it within Gmail though. Yes, there was a method to pop-out the Task list widget into its own browser window. I could never figure out how to use it without first logging-in to Gmail and then activating it directly within Gmail.
What I really wanted was a way to just bring up my task list, independent of Gmail, preferably in Todd Ditchendorf’s handy Fluid browser. Fluid, a webkit-based browser, allows one to treat URL patterns as a “Site Specific Browser”. I watched Gmail make all the necessary AJAX calls to suck in the Task list data and presentation layer code… but mimicking those exact requests in Fluid was a boatload of FAIL.
Last week Google finally made isolating the Task list application possible with an implementation of Tasks for the iPhone as well as an iGoogle gadget. I've tried both in Fluid and I find the iPhone UI generally better, even though it didn’t (obviously) implement keyboard navigation. (Bonus points to those you following at home who've read Bruce Tognazzini’s series on Keyboard vs. Mouse interaction: part 1, part 2, part 3)
It is actually very simple, and I'm mostly dropping this blog into the URL pool so that people realize it “just works™” (also as a nudge to the Googles of the world to keep making this type of hacking possible.)
Basically, fire up Fluid and create a new Site Specific Browser with the homepage URL set to http://gmail.com/tasks.
Google does a little platform sniffing with requests to that URL resource and redirects you to the ideal implementation. Originally I set Fluid’s user-agent to the iPhone one, but this resulted in an annoying message that I was using an out-of-date browser. (Fluid ships with the Mobile Safari 1.1.3 user-agent string and I was too lazy to whip out my iPod Touch to copy the latest string.) Instead, simply leaving Fluid with the default “automatically chosen” user-agent string was fine. You’ll get another annoying message, which you can dismiss, telling you that this “version is not compatible with your phone”. The message is just one of those pitfalls of user-agent sniffing, it works fine if you’re using a recent version of Safari 3+ or a WebKit nightly.
That’s it. Months ago Todd updated Fluid to be much smarter when dealing with Google URLs in a Site Specific Browser, due to the various redirects involved in the authentication process. It all works quite smoothly now.
If you would prefer to let Fluid use the iGoogle gadget implementation then you will want to set the homepage URL to something like:
http://mail.google.com/tasks/ig?up_ShowTips=false&lang=en&country=us&.lang=en&.country=us&synd=ig&libs=I6gXJQFzsCg/lib/libcore.js,MJLTofH-Kpk/lib/libsetprefs.js&extern_js=/extern_js/f/CgJlbhICdXMrMAo4ACwrMBI4ACwrMBM4ACw/UpcjQ5pVgbs.js&view=home
(apologies for the nasty line wrapping)
YMMV, that works for me. You’ll get an interface much closer to the one found in Gmail proper (including keyboard navigation.)
Questions? Sure, just contact me.
Update: For completeness, I’ll note that David Hoffman also documented his method for creating a Fluid instance of Gmail Tasks. His notes only focus on the iPhone version (but do suggest a user script to hide the annoying warning message). After using the iPhone version for a bit I switched back to the iGoogle gadget version and I'm much happier. Keyboard navigation is really helpful with an outliner.
Update2: Here’s another write up that focuses on using the iPhone version. This version includes the most recent MobileSafari user-agent string, if you'd like to “hide” the compatibility warnings. I'm still not a fan of using the iPhone UI on the desktop without access to all the rich touch interaction the iPhone provides.