Thought Delimited

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.

So I went ahead and bought a Droid this past Friday. I haven't had a huge amount of time to play with it yet, but I thought I'd share some of my experiences so far:

• I'm not sold on the physical keyboard yet. The keys are very close together, so if you have decent-sized thumbs like I do, you have to really focus on your typing to avoid hitting two keys at once. Having said that, I have gotten better at it since my first day.

• I like the on-screen keyboards. The haptic feedback (the slight vibration when you hit a key) is nice, and I like the row of word suggestions that's displayed under the typing area as you type. I prefer it over the virtual keyboard of my iPod Touch.

• The screen is beautiful. I haven't had a chance to play any videos on it, but the application icons on the screen make the iPod icons look "soft" in comparison.

• The web browser is on par with the Safari browser on the iPod (no real surprise, as they both employ the webkit engine). The Android browser does not have multi-touch, so you can't pinch the web pages, but it lets you double-tap on the page to magnify it and I find that sufficent. Web pages load about as quickly as I expected (a bit slower over 3G, obviously).

• The new Google Maps Navigation with turn-by-turn directions is as cool as reported. I used it twice just to see how it worked, and it gave me perfect directions and was quick to recalculate the route when I went a different direction.

• I like having the ability to have widgets on my screen for things like the weather and Twitter, but because the default UI for Android only gives you three screens to work with, you have to be judicious about which widgets you want to display (though it's easy to add and remove widgets).

• I really like the notification system. If the Droid is "on" (i.e. the screen is lit), the notification/status bar at the top of the screen will denote if you have any new Gmail messages or Twitter updates with icons, and you can drag down the notification window to see a summary of what's going on. If the Droid screen is off/dark, and there are updates, an LED light in the upper right corner will flash. It even flashes different colors for different applications:  green if there's a new Gmail message, blue if Twidroid (my main Twitter app) has received new tweets.

• Android phones do not have a set media management programs like iTunes, so you have two options for copying your media files onto your phone: you can simply mount the phone's SD card as a hard drive via USB and copy the files manually, or you can download a program like doubleTwist (Windows only) or Salling Media Sync (Windows/Mac) that inspects your iTunes library and playlists and copies any non-DRM media over to the Droid. I couldn't get doubleTwist to synch my files (I suspect it just needs to be updated to handle the Droid), but Salling Media Sync was able to copy over the iTunes playlists I selected.

• Some Droid users have reported problems with the auto-focus on the camera for still shots.  I personally haven't experienced that problem. I was surprised that there was no way to specify what it was you wanted the lens to focus on within the shot: double-tapping on the screen causes it to zoom in rather than select the subject. Despite that, the few pictures I've taken look pretty good to me. There are one or two camera apps in the Android Marketplace, so I imagine that better camera applications will be developed for the Droid eventually.

• Speaking of the Android Marketplace, it's easily accessible via the Marketplace app on the Droid. You can find apps by category or via the search bar, and each application is listed with a price (quite a few are free or donation-ware) and a rating. It's easy to download an app, try it out, and then uninstall/delete it if it's not to your liking.

• The battery seems sufficient to me, though I probably haven't used it as heavily as some folks would. Since every app you turn on (and some apps start up automatically) stays on unless you explicitly kill it, having a program that can selectively turn off running apps like Advanced Task Killer if you don't want to waste power.  I also downloaded a widget that lets me selectively turn off the different radios/receivers on the Droid (WiFi, Bluetooth, GPS) if I'm not using them.

• The ability to multitask is sweet. I had the music player on while I drove to work this morning when it occurred to me that I hadn't shut off the WiFi radio on the Droid. So while I was stopped at a traffic light, I hit the Home button, swiped over to the right screen where my radio manager widget was, turned off the WiFi, and went back to the music player, all without missing a note of the song.

If anyone has any questions about the Droid, feel free to ask, and I'll answer them if I can.