innerHTML

Peter Bergstrom, a user interface engineer at Apple and a Master’s student in Computer Engineering at Santa Clara University, has been working on Papercube. He describes it as a way “to more effectively search digital libraries with a focus on academic paper network navigation.”

A longer description: “It is a rich internet application using SproutCore, SVG, and the canvas tag. For even more interactivity, I use Webkit CSS transitions for animation. No Flash, Flex, or Silverlight.” It works in WebKit-based browsers and Firefox.

In Network Systems, we’ve been looking around for a way to visualize UW’s network and the other networks we monitor. These networks are big. As in really big: Carl-Sagan’s voice “thousands and thousands” of nodes big.

I had a hard time navigating Papercube’s interface to find the view I wanted. I got what I wanted following these steps:

1. Mouse to the left and a search pane slides out.
2. I entered “network” as a search term in “Paper Titles.” I chose a search result with 8 references and 37 citations.
3. Using the default setting, you get “Paper Detail”–some windows/panes that give you, as expected details about the paper.
4. In the upper banner you can choose a different “View.” For wanted, the view was “Paper Graph.” I’m not sure this is the best term. But I can’t think of a better one.

The popup hovers hide the graphed information and the right-click popup controls are unintuitive (even though “intuitive” is a vague notion). But I like where this is headed. A non-proprietary way to visualize rich data. Other methods exist, Walrus being one, but this is one among the many that’s worth watching.

I’m quoted, for better or worse, in this Seattle Post-Intelligencer article. The article mentions my concern about “how the school chose IT vendors.” How choices are made doesn’t seem transparent at the moment. When it does become transparent, I’ll post about it here.

I’d forgotten how much I love this book.

This is depressing, but maybe in a good way. It’s a useful discussion of the long-standing question (a question that will keep standing, it seems) of whether or not we should be writing HTML or XHTML.

As the author states: “Most browsers handle XHTML as yet another form of HTML tagsoup.” Too true. Most browsers treat it as HTML and if you don’t serve it as application/xhtml+xml it’s definitely not being treated as XHTML.

A personal anecdote. When serving some work I’ve done as application/xhtml+xml I ran into problems. For example, when a dynamic document was loading—while jQuery was building the document’s content—the XML processor would throw an error before all the content was loaded. The document looked to the browser’s XML processor like it was invalid XML, but it just wasn’t finished building itself. Maybe there’s a way around that, but I didn’t have time to find it. I didn’t have time to research the problem so just switched back to serving the document as text/html.

Grrr.

When I started more serious web development around 1997, XHTML was the hot new thing. I adopted it and other developers around me were adopting it. Employers were asking asking about the difference between XHTML and HTML and XHTML transitional, and on and on. XHTML seemed here to stay. But it seems less clear the more I read that it’s necessity is absolute. So, to deepen my uncertainty and perhaps yours, some articles that take up the debate:

• WaSP: HTML Versus XHTML
• 456 Berea Street: The perils of using XHTML properly
• 456 Berea Street: No more Transitional DOCTYPEs, please
• W3C: HTML and XHTML Frequently Answered Questions
• Ian Hickson: Sending XHTML as text/html Considered Harmful
• WebKit Blog: Understanding HTML, XML and XHTML

Today a co-worker and I were scratching our heads over why Safari wouldn’t display XML with an XSLT stylesheet defined. It should display the XML, at least according to Safari’s developer documentation: “Safari 1.3 and above supports XSL transformations of XML pages at load time.” It wasn’t working for us, though.

Searching eventually turned up this article, but the article’s author could get XML to display sometimes. We couldn’t at all.

But one of the article’s comments helped:

The problem is that the DTD is not available at the specified URL. So you mustn’t suppres [sic] the DTD in the Stylesheet but you must insert a DTD declaration that points to an existent file.

In other words, it turns out Safari requires a DTD. And the browser doesn’t like XSLT stylesheets with <!-- comments. But you can use the <xsl:comment> tag (something new to us that probably shouldn’t have been new). So, I removed the HTML-style comments, added the DTD for XHTML 1.1 and … no more blank screen. All is well with the world.

John Resig announced today that “jQuery will be distributed with Visual Studio.” Scott Guthrie, a Corporate Vice President in the Microsoft Developer Division, talks more about “adopting jQuery” in his blog.

I hope Microsoft doesn’t begin to hover over jQuery like this:

I read today how to simulate a Multi-Touch pinch in the iPhone Simulator. Hold the “option” key while clicking on the screen. I was scratching my head about this one for a while. The Simulator’s help gives you the message: “Help isn’t available for the iPhone Simulator.” Nice. I finally found this (buried) in the documentation.

A colleague told me about an important RFC from 2000 that I’d missed: the RFC for IMPS.

The September 2007 unveiling of jQuery UI was going to be a leap forward, in the words of John Resig: “jQuery UI signals the start of a whole new branch of the jQuery project which will focus on developing high-quality, reusable, components that you’ll be able to drop in your applications.”

On component I was happy to hear about was sortables (the demo is here). But since the new UI library’s debut, sortables, at least for me, hasn’t worked right. What do I mean by “right”? I’d argue, maybe wrongly, that if you’re building something to act like other somethings already on the web, your new something should follow the user expectations the previous somethings have already created. This is a conservative stance, but much interface design philosophy instructs us not to break patterns web users have come to expect. I’d compare it to an automaker deciding to put the gas pedal to the right of the brake. Maybe a nice new idea, but it breaks what users expect. In web design there are a few similar don’ts: don’t mess with people’s scroll bars, link to home from the upper left, keep search boxes in the upper-right corner, the list goes on. Steve Krug and Jakob Nielson have written extensively on patterns users expect.

The sortables component of jQuery UI breaks an expected pattern, at least to me. Sortables, like what you find on like iGoogle and Netvibes are a relatively new phenomena, but users have likely come to expect them to act in similar ways. Netvibes and iGoogle work almost identically: move a tile (the sortable element you’re sorting) and the tiles around the moving tile snap out of the way, making room for what you’re moving. Also, what you’re moving never hides what’s underneath and the other tiles never disappear while you’re moving one tile.

Comparing these sites to the jQuery UI demo I linked you’ll see some differences, at least two: 1) You can move one element over the top of another without the bottom element(s) snapping out of the way and 2) you can end up, in some cases, with multiple “placeholders” or empty spots where you can drop the thing you’re sorting.

Problem 1.
I made a screencast of the movie as an example. In the movie, I create a few new tiles and then move one tile over another without them moving out of the way to make room for the tile I’m sorting. Neither iGoogle or Netvibes work this way. Tiles move out of the way on both sites to make way for the tile you’re moving. But not in the jQuery UI version.

I wrote about this behavior in the Google group and filed this as a bug with the jQuery UI developers and the bug was closed with “wontfix.” A developer closed the bug with these commetns: “This is not a bug, but a thoughful implementation. However, we’ve added other tolerance modes for it – For example, tolerance: ‘pointer’.” Excellent, I thought. A fix. As usual, I thought I’d done something wrong, but looking in the sortables documentation, I found no option for tolerance. I followed up, asked for more help, but didn’t get anywhere. It’s not the developers’ faults they’re busy developing. But I’m still unable to get the jQuery UI sortable component to work like either iGoogle or Netvibes.

Problem 2.
Proliferating placeholders. In a web application I’m building, if I use the jQuery UI sortables method, I can end up with three placeholders as I’m sorting one tile. Another screencast shows what I mean.

With the above two problems, I’m unable to use the jQuery UI library for sortables. It could be that I have problems in the way I’ve coded my XHTML, that a missing end element is causing all the madness. But I’ve checked it all as best I can and built test pages and confirmed the same problems in jQuery UI’s demo. So, instead, I’m using Interface for jQuery. This sort demo is exactly the user experience a user would expect and it’s the one I’ll use until jQuery UI’s implementation becomes more flexible.

Tags. It’s not as easy to use them now. The social-ness of the site is clear. I’ve got 101 options across the top of the page to interact with the site and others, but I’ve lost easy, ginormous access to my tags.

I’ve stolen a screenshot of the previous del.icio.us design from Alan Le’s site:

In the new “delicious.com” this same functionality, getting at bookmarks with tags quickly, is buried:

The feature I most used has gone from a font-size larger than large, to a tiny font buried down into the site’s new, over-busy drop-down menu navigation nightmare.

Oh, and about drop down menus:

Now, me, I hate drop-down menus. I hate them as a user. Too many choices. It’s like those big laminated menus you get at a New York diner. Spaghetti, diet plate, French Toast, broiled filet of sole, pizza, ice cream sundae, Atkins menu, veggie burger…. The eyes blur. You slam the menu shut and order coffee.

As a designer, wherever possible, I avoid drop-down menus. For they almost always create an inferior user experience versus drilling down through clearly labeled, intelligently organized categories.

When I see a drop-down menu, I know that a committee sat around a table, unwilling to think through the organization of the site’s material into a user-focused structure — or unwilling to accept the recommendation of an information architect who spent days making sense of the site’s offerings.

Thank you, Zeldman.