Thought Delimited

So just when I thought that all of the rhetoric regarding the Apple verses Adobe dustup over Flash had died down, Steve Jobs published an open letter entitled "Thoughts on Flash" on the Apple website today, ringing in yet another round in this boxing match.

I encourage those folks who care about this issue to read the letter in its entirety (rather than someone's summary of it).

Some quick thoughts I have on what was said (just my opinions/observations):

• When Jobs dings Adobe on the issue of Flash being proprietary, he acknowledges that Apple has proprietary products as well, but that "we strongly believe all standards pertaining to the web should be open." Why, exactly? What makes it okay to engage in proprietary protections off of the web but not on it?
• Jobs makes the point of mentioning WebKit to illustrate that Apple contributes to the open standards for the web.ﾠ He fails to mention that Adobe also makes contributions to web standards as well (the partnership with Mozilla on Javascript engine code comes to me) and that Adobe does have products in their toolset to allow developers to create websites using the latest advances in HTML, CSS, and Javascript. Adobe certainly has an interest in promoting Flash, but they continue to support other competing technologies.
• It's interesting that Jobs implies that Adobe was tardying in providing support for the H.264 hardward decoder, yet it has been pointed out by a number of sources that Flash has long suffered from performance issues on Macintosh computers because Flash was not allowed to make use of the graphics accelerator on Macintosh chips.
• Jobs states that any Flash sites that rely on "rollover" events to activate certain functionality would have to be re-coded in order to work on the iDevices. That may be true in some cases, but let's not forget that certain HTML and Javascript events also rely on the idea of hovering over a page element with a mouse, or dragging and dropping an item. The need to adjust to a multi-touch paradigm is not something that just affects Flash-based sites; it affects websites built with those open web standards as well. And just because something doesn't work quite right on a new device doesn't mean you should throw it out and start over from scratch.
• I see the issue of allowing Flash to run as a browser plugin on the iDevices and the issue of letting Adobe provide a tool for developers to translate Flash code into a binary file that runs on the iPhone OS as two separate things, yet the way the letter is written it seems to combine the two issues. Perhaps it was done as a means of using the earlier arguments to sway some options regarding the Flash-to-iPhone compiler issue.
• A lot of these complaints Jobs has regarding Flash (valid or not) can be or are being rectified. Instead of encouraging Adobe to address the things he has issues with, he "suggests" Adobe should drop Flash and stop criticizing Apple. That certainly implies to me that even an open, secure, battery-friendly, and efficient version of Flash would still never be allowed on the iDevices.
• I have to wonder what he thinks this letter will accomplish. The fact that he wrote it at all seems to imply either some desperation or annoyance over the fact that that Apple's anti-Flash stance hasn't been as widely accepted amongst the industry and amongst consumers as he'd like.ﾠ Perhaps he's looking to gain a few more converts to his stance at the cost of making his opposition that much angrier with him?

Just got back from the first Washington DC jQuery UI Meetup (more on that in a later blog post). One of the co-presenters was a Microsoft Developer Evangelist who happened to have on him a prototype Windows Phone 7 device and was willing to demonstrate it for anyone who was interested. So I got to take a look at it and wanted to share a bit of what I saw while the memory is still fresh.

If you haven't seen any of the photos or videos of what Windows Phone 7 looks like (check out Engadget), the UI is very different from that of the iPhone or Android. Instead of icons and distinct applications, you have tiles that you tap to enter certain "hubs", and within these hubs can be added app-like functionality. For example, the hub concerning photos not only serves as a photo gallery for the photos stored on the phone, but also provides the functionality for uploading your photos to Flickr or Facebook or for viewing photos in your friends' Facebook albums. Another distinct difference is that the UI menus can span across multiple horizontal screens, so sometimes you'll see text cut off on the right side indicating there's more going on just off to the right.ﾠ

I knew most of that prior to seeing the actual phone, but I was curious to see how it actually worked in practice. It actually looked kinda cool: the scrolling and screen transistions were smooth, and the removal of the need to fit text into the width of the handheld screen allowed Microsoft to use bigger font sizes for the text, making the screen very readable even from a few feet away.

But in other ways, the UI was more subtle: it has a celluar radio strength indicator at the top of the screen like the iPhone and Android phones do, but the text was small and the background was transparent, letting the wallpaper image show through underneath. And as we waited to see new Facebook updates from his friends (Facebook functionality is integrated into the OS), he pointed out the marching horizontal line of green dots that appeared at the very top of the screen that indicated that data was being updated. It was barely noticeable, but very unobtrusive.

The interesting thing I found about the "hubs" concept was that each hub area was distinctive (different background, different text color), which really emphasized the idea that you were in a different area or aspect of the phone, not just a standalone app. And he wasn't switching from one app to another to do things: he was navigating around or deeper into the current hub to access certain functionality.

Another attendee asked him what the platform would be for developing apps for Windows Phone 7, and he told us that developers could build apps for these phones using either XNA (which I'm unfamiliar with and too tired to look up right now) or Silverlight. Given the struggle Microsoft has had in promoting Silverlight as a competitor to Adobe Flash, it'll be interesting to see if the ability to develop mobile phone applications with Silverlight will further Silverlight adoption. I should also note that earlier in the conversation, he'd mentioned that the first version of Windows Phone 7 wouldn't support browser-based Silverlight or Flash (simply because there wasn't time to put that into the first release), so I took that as a sign that Microsoft plans to allow Flash (at least browser-based Flash) on these devices.

I think that about covers it. While I personally plan on remaining an Android user, I do think Microsoft's doing something interesting here, and I'm curious to see how it plays out.

I've done very little blogging over the past few months, and I wasn't a prolific blogger to begin with. Part of it was that I didn't have that much to share, but mostly it was because my heart wasn't in it. Somewhere along the line, blogging became a chore rather than a hobby, something that took a lot of effort but didn't return much in the way of satisfaction.

I'm going to try and make blogging fun for me again. Not exactly sure how I'm going to achieve that, but it probably means changing my blogging style a bit.

Consider this your one and only warning.ﾠ :)

Today I attended a presentation about a joint study being conducted between the English and Computer Science departments at the University of Maryland regarding the use of e-readers for academic reading. What was interesting about the study was that it wasn't just about whether students preferred using an e-reader device over standard textbooks, but whether the simultaneous use of TWO e-reader devices was more conducive to academic reading.

On the surface, using two devices to read instead of one seems a bit odd, but the premise of the study was based on research that showed that individuals engaged in academic reading (reading to learn, to synthesize information and translate into research notes) often had two or more sets of reading material (books, research papers, etc.) in front of them, and that they would go back and forth between those sources as they took their notes.

So at the beginning of the semester, the students in this literature course (which appropriately is a course that studies the history and future direction of books) were each given one of these e-reader devices developed by the Computer Science department. Each of these e-readers were about 7"x10", used E-ink for the display, allowed students to write notes with a stylus, and were optimized for quick page refreshes and overall book navigation. Now that the students have had a few weeks to acclimate to the use of the readers, they are each going to get a second one and try using them simultaneously. Although the presenter didn't go into great detail, the e-readers apparently have the ability to transfer and synchronize data with each other, so the students can decide to tackle the same source material with both devices or perhaps create references between two different documents.

To me, studies like these really highlight the fact that the e-reader market is still a young market and that no one has all the answers. Mainstream e-readers like the Kindle, the Nook, and the almost-here iPad may lead the e-reader market when it comes to casual reading, but there hasn't been as much of a focus on what works when it comes to e-readers for academic or professional use. As was discussed after the presentation, there may be a shift in the very concept of a "book" is as people explore not only different ways of consuming text-based content, but ways of producing and presenting the content, perhaps with the addition of other types of media.

It'll be interesting to see what comes out of all of this several years down the road.

Every April, the University of Maryland holds a huge open-house event called Maryland Day that draws 60,000+ visitors to the campus to view exhibits highlighting the research conducted at the university and participate in various events and activities. All of the event details are entered into a ColdFusion application, and one of those details is the GPS coordinates (latitude and longitude) of where each event is taking place so visitors to the website can see where the events are located on Google Maps.

Now that smartphones are becoming more prevalent, I wanted to see if it was possible to build a web application that would show the user where they were currently located and then show them on a map how to get from their current location to a particular event.

So I did some research and learned that HTML 5 comes with a Geolocation API. This API allows you to execute Javascript functions within the navigator.geolocation object built into the browser that retrieve the supposed latitude and longitude coordinates of where the browser is located (and, if available, the altitude, heading, and speed at which the browser is moving).

Using the code examples I found on the Gelocation API page on the W3C website and on Oliver Wehren's geolocation demo page, I was able to create my own test page for determining my location and marking it on Google Maps. I then tried using the page with my Motorola Droid, my iPod Touch, and my manager's iPhone.

The default web browsers on all three devices implemented the Geolocation API (my preferred browser on my Droid, the Dolphin Browser, did not). Each of the browsers displayed a confirmation dialog asking for permission to share my location information with the web page (as mandated by the standard), and once I permitted the information to be used, my test page was able to place a marker denoting my location on the map.

However, the location wasn't as accurate as I had hoped. Although the API was coded to accept location data from the on-board GPS system in a mobile device, neither the iPhone nor the Droid seem to provide GPS data to the browser. If I was connected to the campus wireless network, my location was determined via the network topography, and it could be off by as much as 150 feet or so. The accuracy was even worse if I was relying solely on 3G: in that scenario, but the iPhone and the Droid had me located on the side of a state road on the outskirts of campus, a good twenty minute walk from where I actually was. I have no idea what caused both devices to pick that particular spot, as there certainly wasn't a cell tower anywhere near that location.

So I came to the conclusion that while the Geolocation API could be used to determine what town, city, or general area a user was currently in, it wasn't accurate enough (at least with these browsers in these devices) to provide walking or driving directions within a small area, especially given the fact that many of the users for the service I had in mind would only have access to the Internet via a 3G connection.

But if someone knows of a way of increasing the location accuracy of the Geolocation API, a way that doesn't require the end-user to modify their mobile browser in order to make it work, I'd love to hear about it.