Tuesday, January 18, 2011

HTML5: Pedantry and Pragmatism

(This is in response to Jeremy Keith's reaction to W3C's new HTML5 logo, which intentionally uses "HTML5" as an umbrella term for most modern web standards, rather than just the specific technologies actually described in the HTML5 spec.)

First, from the FAQ:

IS THIS W3C'S "OFFICIAL" LOGO FOR HTML5?
Not yet. W3C introduced this logo in January 2011 with the goal of building community support. W3C has not yet taken it up in any official capacity. If, as W3C hopes, the community embraces the logo, W3C will adopt it as its own official logo for HTML5 in the first quarter of 2011.

Second, HTML is the primary vehicle of delivery for all those other modern web standards: it is the thing that brings them all together and gives them a purpose. Most of these technologies have seen adoption in browsers and websites concurrently with the adoption of "actual" HTML5 features. HTML5 has thus become thought of as a umbrella term that encompasses these things, which is not entirely surprising, and evidence of how having such a term IS convenient.

For those wishing to be more specific when they discuss "HTML5", this initiative could actually have benefits: it adds a categorization and iconography to subdivide what people think of as HTML5 into more meaningful groupings. If you assume that the average person already thinks of "HTML5" as this sort of catch-all, then this will actually draw MORE attention to the many technologies that HTML5 could refer to; rather that fighting a losing battle of linguistic prescriptivism, this accepts the trend and cuts ahead to provide a substitute terminology.

The icon set and the badge builder gives sites a unified way to quietly indicate what technologies are supported -- geolocation? offline storage? -- that could be helpful to users (although the far-too-abstract designs of those "class" icons leaves a lot to be desired). The idea reminds me of the sort of symbols you see on the back of videogame boxes, to indicate how many players and what add-ons or platform features are supported by the game.

Does this further erode the clarity of the "HTML5" label? Yes. But this was already happening, and if you accept that there's no way to really stop it, then this branding initiative becomes a clever, pragmatic choice.

Saturday, January 8, 2011

What it would mean if the iPad gets a "retina display"

Lots of rumblings about the 2nd gen iPad that's due to be announced in a month or two, along with talk of whether or not it will follow in the iPhone 4's footsteps by gaining a "retina display". Some insane numbers are being thrown around, as evidence of its impossibility, but the insanity of these numbers is due to a lot of people assuming that "retina display" means "over 300 pixels per inch, linear resolution", which is a mistake.

In announcing the retina display at the WWDC 2010 keynote, Steve Jobs didn't just say "300 is magic", without qualifiers. The full quote is:
"It turns out that there's a magic number right around 300 pixels per inch, that when you hold something around 10 or 12 inches away from your eyes, is the limit of the human retina to differentiate the pixels."

(apologies for the grammar, but that's the exact quote.)

Which, as this in-depth examination shows, is a quite accurate statement for 20/20 vision. Steve made a big deal about the 300 thing, but that only applies if you're holding it at 10-12 inches from your eye.

BUT: You simply cannot comfortably use the iPad at ten inches from your eye. It's too big for that. I can see 14 inches being a comfortable distance, though.

Now, applying the same assumptions and simple bit of trig as used at that link, we find that to meet the "retina display" criterion at some greater distances, we'd need:

1/(13*tan(1 arc minute)) ~= 264 ppi
1/(14*tan(1 arc minute)) ~= 246 ppi

Oh ho! 264 ppi corresponds exactly to a doubling of existing iPad resolution, to 2048 by 1536. That meets the standard of "retina display" at 13 inches from your eye.

Another common size, 1920 by 1440, would give the iPad display a density of 247 ppi. Which is perfect for "retina display" at 14 inches. Slightly more achievable, perhaps, but lacking that nice 2x scaling factor.

I'd say both of these resolutions ARE within the capabilities of modern hardware. No, you're not going to be running the latest cutting-edge FPS at that resolution, but videos and standard graphics? No problem.

The iPhone 4 can play H.264 1080p videos perfectly without breaking a sweat, and it doesn't even officially support that. The CPU/GPU in the new iPad will have another years' worth of R&D on top of that.

Now, whether or not they can make a 9 or 10 inch display of that resolution and still meet their price points is quite another matter.

For reference: a 1.5x (1536 by 1152; 198 ppi) display would meet "retina" criteria at 17-18 inches from the eye, which is roughly the distance from eye to screen if you're a moderately tall adult and it's sitting in your lap or on the table in front of you, but it would lose it's, umm, retina magic if you held it any closer than that. (Assuming, of course, you have 20/20 vision.)

Sunday, December 5, 2010

Garbled Addresses

I have three locations where I store, access, and edit contact information:
  • The iPhone address book

  • The OS X Address Book app, on my Mac

  • Google Contacts (i.e., Gmail)


They are all automagically synced together:
  • the iPhone syncs with Google via "Google Sync" (which uses Exchange ActiveSync as the protocol, and bundles together mail and calendar data as well)

  • the Mac also syncs with Google, via "Contact Sync" (the feature is built-in, but I'm not sure what protocol is used)

  • Address Book syncing is NOT enabled in iTunes, and the Mac and iPhone do not do any direct exchanging of contact data.


Generally, this works quite well. Some limitations -- notably, contact groups are not synced -- but that's not a big issue for me. One annoyance, though, that I've been noticing quite persistently is the garbling of street address information on the iPhone end.

Specifically, somewhere in the syncing with Google, addresses are often parsed incorrectly and show up in the iPhone address book with multiple items (e.g. city + province + postal code) clumped together in the city or province field.

Both OS X and the iPhone address books use discrete fields for storing components of an address: one or more street address lines, city, province, postal code, country. Google's interface presents only a flat text area.

The problem seems to be the different ways that the iPhone and OS X handle Google's flat text area -- or, probably more accurately, differences in how Google's two different syncing methods assemble and disassemble the discrete address components into a flat field. I'm pretty certain that the problem lies in Google's sync solutions not using the same rules to interpret addresses.

A contact created in OS X:



when synced to Google is formatted envelope-style:



but when it's then pushed to iPhone, we see oddness:



because this is the data the iPhone was given:




Whereas a contact created on the iPhone:



appears in Google as less traditional but "cleaner" one-item-per-line form:



and from there it's perfectly fine in OS X.

The problem is apparently that the Google to iPhone syncing doesn't appropriately recognize the commas and double spaces as field separators, so information that isn't on separate lines gets globbed together. Or, alternately, the OS X to Google syncing should just use line breaks as separators.

Fixing this issue is a pain on the iPhone (which ironically is the only place where I "see" a problem), where the edit fields are tiny and inconvenient for cutting and pasting. It's a dead simple matter of hitting backspace and enter a few times in Google. In either case, the changes stick, and propagate to OS X without problem -- Address Book.app still shows the data correctly.

However, any subsequent edits to a contact in OS X will cause the next sync to change the Google address field to the commas-and-spaces format, and in turn make it look garbled on the iPhone again. Grr. So, note to self, don't do that. (Or if I do, fix it in Google right after.)


Google, please fix this bug.

Wednesday, October 27, 2010

Google Maps - Transit Bookmark

Google Maps now has bus route and schedule information for GRT, which is pretty handy, particularly for factoring in walking times and coordinating multiple busses. It often points out alternative routes/connections I hadn't thought of that are faster or more convenient.

The integrated Google Maps app for IOS is nice, but the interface feels a bit awkward or backwards to me for some tasks. For figuring out bus routes and schedules, there's some advantages to Google's mobile web interface.

However: getting to that interface still requires some annoying navigation when what I really want to be able to do is just quickly and directly ask, "if I want to take a bus to [here], what are my options?"

So I hacked together a bookmark that lets me do exactly that. Here's the link, or you can copy and paste:

http://maps.google.com/maps/m?gl=ca#ll=0,0&saddr=&daddr=&ttype=now&dirflg=r&ac=t,

You can also open that link and then add it to your home screen for quick access.

This bookmark jumps you straight to the form to enter your destination, with public transit set as your mode of transportation. There's a handy "leaving now / depart at / arrive by" option right there, too. On my iPhone, the starting address always defaults to "current location", but not always when I test it on my desktop... there's something funny about the geolocation request it performs, and if it silently fails or doesn't get an answer in time it will just leave a blank field as the starting point. (The iPhone, with its GPS, seems immune to this problem.)

Friday, October 22, 2010

Title Text Bookmarklet

A lot of webcomics include an extra punchline or commentary inside the title or alt text for the comic, which displays when you let the mouse cursor hover over the image for a couple seconds.

On a touchscreen device, you can't hover. So: bookmarklet to the rescue! I'm not the first to come up with this idea, but I didn't like the style or function of the existing ones that I could find.

I did like the style of Andy Allcorn's QwantzReveal bookmarklet, which is filling this same function, but it is very specific to the easter eggs for Ryan North's Dinosaur Comics. I wanted something that could work for more webcomics but use the same style.

So, I grabbed the code for that and chiselled away at it until I had something that works reasonably well for the webcomics I'm likely to use it with.

The result: Copy this link into a bookmark!

Running the bookmarklet will make an overlay fade in on top of the comic image, showing both the alt and/or title (whatever exists). Tapping it will cause the overlay to fade away, leaving the comic as it was. (Unless the comic is linked to something else, then it will follow the link.)

Identifying which (if any) image in the page is the comic is a rough hack but it seems to work for the comics I read (including Overcompensating, The Adventures of Dr. McNinja, XKCD and Achewood (but not via Assetbar)). It doesn't work for A Softer World, but you can already just tap on the comic there to see the title text.

Let me know if (a) there's any comics this ought to work on, but doesn't, and (b) any situations where it mangles the page layout or doesn't display nicely over the image.

EDIT: Alternately, select all from the follow text area and copy it:

then create a bookmark, edit it, and paste what you copied in place of the URL.