Archives for posts with tag: web

I had a fun chat today with Coté on his “make all” podcast. Here are some of the topics I remember discussing:

  • What’s important (and what’s not important) about HTML 5
  • The increasing ubiquity of JavaScript
  • Java-to-JavaScript translation technologies (e.g. GWT and JDojo)
  • Ajax, RPC, and REST
  • The nirvana of mobile devices plus cloud-based data
  • I recommend Nick Carr’s “The Shallows

Happy listening!

Update: I’ve created a test page for this scenario, but I haven’t had a chance to test it yet on my iPad.

In our Jazz UIs, we tend to use “hover previews” quite a bit. That is, if you hover over a link, after a second or so it will show a small preview of the resource at the other end [1]. Jazz style guide example below (copyright IBM).

This was always broken on the iPhone’s Mobile Safari browser because I couldn’t figure out how to perform a mouseover action on a mouse-less interface.

I just noticed that the iPad seems to support onmouseover. I believe I’ve observed the following behavior:

  • If a link has no “on mouseover” actions (e.g. hovers), a tap follows to the link.
  • If a link has an “onmouseover” action, a tap activates the onmouseover action and a double-tap follows the link.

Obviously this implies that you should provide visual indications to your user whether the links provide onmouseover actions or not. For the Jazz links with hover previews we immediately decorate the link on mouseover (different color, double-underline, with a small chevron) and if the user remains over the link for a second or two we then show the preview.

[1] I realize that onmouseover actions attached to links represent a UX minefield. A page with too many / too aggressive hover actions can feel like an actual minefield!

As my dear colleagues Simon Johnston and James Branigan have mentioned in various blog posts, on the Jazz project that I work on, we’ve (finally) fallen in love with the web/REST story. Because of this, we spend a lot of time in technical conversations using the standard REST alphabet soup vocabulary you’d expect – HTTP, XML, JSON, REST, URL, URI, etc.

One funny thing I’ve noticed is that there’s a certain conversational dance that goes on when the topic of URLs/URIs come up. For 99.9% of the web developers out there the distinction between “URL” and “URI” doesn’t matter, as the Wikipedia entry on URL points out:

In popular usage and many technical documents, [URL] is a synonym for Uniform Resource Identifier (URI).

However, some people who are a bit more pedantic than others care about the distinction (not me!) and tend to use “URI” in favor of “URL” when talking about REST stuff. People who are a bit new to the REST stuff on the other hand tend to use “URL”, since this term’s a bit older and a bit better known.

I’ve observed that when a REST newbie talks with one of the REST pedants, the newbie says “URL” while the REST dude uses “URI”. But as the conversation continues the REST n00b eventually uses “URI” – essentially deferring to and adopting the more knowledgeable person’s terminology.

I’ve also observed that when I talk with one of our REST dudes, if I continuously say “URL” (usually out of spite – I’m KIDDING!), they usually eventually start saying “URL”, I think just to bring more harmony to the conversation and because they realize that the distinction isn’t that important – probably simple mirroring at play.

I think in a future experiment, I will use the opposite term of whatever the other person (newbie or pedant) uses and as soon as they adopt my terminology I’ll switch back to the other term, and see what happens.

Should be fun.