After attending Scott Knaster's iPod Parlor Tricks, it occurred to me that a photo slideshow is not much different from a presentation. Perhaps the device could be used as a (ultra) portable presentation device?
Read iPod Photo as Portable Presentation Device? on my O'Reilly weblog.
Some interesting Wi-Fi news from the Big Apple.
Today during my commute into the city I passed Verizon setting up an extravaganza in Madison Park (23rd-27th street between Broadway and Madison). Seems Verizon is talking up the hundreds
of hotspots they have deployed around the city. Oh yes… and that they and MSN have jointly launched a broadband service also. (That is the sound of one hand clapping that you hear.)
The hotspots are available to its DSL subscribers free of charge. Very smart of them. (Look here for more info.) They were handing out duel hotspot and subway maps in MetroCard holders. According to my pocket map Verizon's coverage in New York includes Columbia University/Morning Side Heights, Upper West and East Side, Midtown from 59th through Chelsea (coast to coast), The Union Square extended, NYU/Washington Square Park, Wall Street/Battery Park and Brooklyn Heights. (Why is their online hotspot maps are SSL protected? Maybe they are not as smart as I gave them credit for.)
Like I said, interesting. It doesn't help me really. Verizon provides such poor service to my neighborhood that I went with @Home now Comcast. I suppose it will be helpful in getting the market to innovate and keep moving forward at an aggressive clip. T-Mobile recently announced they are packaging mobile phone and Wi-Fi. (I'm really considering T-Mobile for my next phone to take advantage of that and justify my Starbucks coffee addiction.)
UPDATE: Seems I'm not the only one thinking Verizon's move could mean something to the price and service of broadband hotspots. Internet News is reporting that Verizon could spark me-too Wi-Fi efforts. This being said, Reuters notes in that whether it be broadband Internet access, 3G mobile phones or flat screen monitors, the high-tech industry has turned hyping new technologies into high art. Cashing in is another matter entirely.
While I'm getting any real work done today having unleashed my dormant mobile computing thinking, Mark Pilgrim writes about his weblog's mobile edition concluding:
As I said, XHTML Basic has no basis in reality. Ignore it.
Certainly his points are understandable though less so outside of the US. I don't think you'll be able to ignore it very long though.
XHTML Basic is the underlying markup language of WAP 2.0 that replaces the wrong-headed Wireless Markup Language (WML) of version 1.0. Despite all of its foibles and my own harsh criticism, WAP still has the support of all the major telcos and handset manufacturers of the world for browser based applications. Most notable is Japan's NTT DoCoMo who operates i-Mode, the most successful (by a landslide) mobile Internet service in the world. Replacing WML with a standardized XHTML subset was the key concession to getting NTT to endorse WAP and migrate away from its own HTML subset called cHTML. A good, but somewhat dated summary by Wired can be found here.
Are an extensive amount of devices with WAP 2.0 out there? Not really, but look for that to change in the next year or so. So enjoy ignoring it while you can.
There are zero occurrences of the word asynchronous in the current JSR 172 (J2ME Web services) draft specification. If there is one place where asynchronous messaging is most needed its with the unreliable low-bandwidth mobile networks that mobile phone and PDAs operate. More over on my O'Reilly Weblog.
CNET has posted a video interview (the link pops open a window) with Paul Festa and Opera Software CEO Jon von Tetzchner demonstrating their mobile browser that I wrote about here. At the time I wrote:
I've always been skeptical when it comes to these attempts to repurpose web content on a mobile device as Opera's proposal or existing implementations such as Danger's HipTop browser. I've never seen them succeed at anything but frustrating users.
Web pages are designed for large high-resolution color displays, the use of keyboard and mouse and a reliable and relatively high bandwidth connection. Being a display language HTML is not terribly efficient or reliable for consumption by another application. "Qualified guessing" will yield the equivalent of a Frankenstein monster. It’s a hack at best.
Yes, if designed properly a Web page will scale gracefully and adapt to different displays and resolutions -- IF is the operative word though. Like eating your vegetables, most of know we should do it, but don't. Face it, web sites do some rather freaky things with HTML. You don't have to go past the world's most prominent software company's site to witness that.
I still remain skeptical this approach will ever work -- perhaps even more so after watching the video interview.
The interpreted CNET gateway used in demo seems readable, but it hardly looks like its original self. It also requires a lot of scrolling to read. The demo is also done using Sony Ericsson's P800 mobile phone which sports an extra large color screen. Goes to a Nokia phone momentarily and switches back to the Sony Ericsson device before giving a really good look.
Personally I remain optimistic and intruiged with the utilization of well-formed RSS and XSLT in addition to the development of novel applications (most likely using J2ME) for users on the move.
Mark wasn't the only weblogger to have an O'Reilly article published yesterday evening. My latest "Introducing MIDP 2.0" was posted here.
MIDP 2.0 improves on the original specification for open development on mobile devices by introducing secure networking, extended network connectivity, and audio and gaming capabilities.
A follow-up weblog post on Web services support in J2ME is forthcoming.
In response to the Bluetooth article "Teething Pains" published by the Boston Globe on November 11th, Bob Frankston provides some notable insights and criticism of the wireless networking technology's design.
We should learn from the example of X.400. X.400 was (is?) a mail protocol approved and required by essentially all the telecommunication agencies throughout the world. It was designed over a period of ten years yet failed against SMTP (Simple Mail Transport Protocol) which could be implemented in an afternoon. Like x.400, the Bluetooth was designed and promulgated before anyone could learn from the first generation. Bluetooth is designed to work in the specific cases imagined by its designers and thus will perform very well in precisely those scenarios and these are the scenarios touted in press releases.
Frankston continues...
Bluetooth is in the mainstream of the old model of telecommunications in which all the services are defined by the center and every new capability must be approved before it can be deployed and thus before we even understand it. 802.11 is simply a transport for packets and doesn't stand in the way of creating new capabilities.
Once again we face a familiar paradox. Bluetooth which defines so much of the solution is thus limited to what it defines and that is very little and it only works among a few nearby devices. 802.11 which makes few promises inherits the existing richness of the Internet Protocols and has no such limits of distance.
While I admire Opera Software's work and persistence in advancing browser design, I can't help but roll my eyes reading their recent announcement. Opera has developed a mobile browsing technology that has, as Paul Festa reports, "finally solved the long-standing problem of reading big, bulky Web pages on tiny cell phone screens, posing a potential threat to both WAP and to Microsoft."
Mobile users don't browse like they do from their desks, so let's stop trying to repurpose content designed for the Web.
WAP has failed for a host of reasons including the inherent security hole of the WAP gateway architecture, initial deployment on circuit-switched networks as opposed to always-on packet-switched data networks, and a lack of well-designed and useful applications. Even once addressed, browsing would still have its issues and limitations in the mobile arena. Mobile users are "on the go" and generally not in environments where they have the time or patience to navigate content as they would seated at their desks. Their environment requires useful content and applications to be location-based, time sensitive and concise. In addition, utilizing an architecture where nearly all the data and logic resides on a remote server is a poor fit with the reality of unreliable and low bandwidth connections. It frustrates users and erodes their confidence.
Besides, WAP and more specifically WML (WAP's markup display language) is becoming more symbiotic with the Web. WML2 is an extension of XHTML that utilizes a mobile specific profile. (In his CNET article, Fiesta incorrectly compares WAP and HTML that is apples and oranges. WAP and Web Architecture or WML and HTML would have been more appropriate.)
I've always been skeptical when it comes to these attempts to repurpose web content on a mobile device as Opera's proposal or existing implementations such as Danger's HipTop browser. I've never seen them succeed at anything but frustrating users.
Web pages are designed for large high-resolution color displays, the use of keyboard and mouse and a reliable and relatively high bandwidth connection. Being a display language HTML is not terribly efficient or reliable for consumption by another application. "Qualified guessing" will yield the equivalent of a Frankenstein monster. It’s a hack at best.
Yes, if designed properly a Web page will scale gracefully and adapt to different displays and resolutions -- IF is the operative word though. Like eating your vegetables, most of know we should do it, but don't. Face it, web sites do some rather freaky things with HTML. You don't have to go past the world's most prominent software company's site to witness that.
Despite my criticisms in this area, I still believe in the promise of mobile computing. Mobile data devices will eventually surpass the number of desktops. They're more affordable and the constraints of these devices insist on a simplicity that will assist the mass-market in embracing interactive services.
Repurposing Web content for mobile is not the answer, it’s a hack. Studying mobile users’ needs and tendencies, getting content into easily consumable formats and developing more usable and appropriate mobile applications are the real answers.
In his content syndication weblog, Ben Hammersley points out a nifty mobile application named PeekAndPick that he's begun using on his new Java enabled phone. PeekAndPick is a J2ME MIDP application for reading headlines and excerpts from RSS feeds and selecting the items you are interested in reading later. Your selections can be compiled into a list of links and emailed to your desktop for later reading.
PeekAndPick, the work of Jonathan Knudsen, is a brilliant mobile app because it illustrates good mobile application design. It doesn't try to do too much or be like a desktop application. It does demonstrates how mobile and traditional Internet channels can be used to provide a useful and appropriate solution together -- though it could do that a bit better. (More on that in a bit.)
The application's design acknowledges that mobile means "on the move." This mobility generally finds the end user in a less then ideal setting (context) that requires information be concise and interactions simple in order to be useful. Mobile users do not browse -- especially on a screen that typically is not much large then a postage stamp. (Note to telcos and device manufacturers: Web content was not designed or with a mobile devices or users in mind. It futile to try because it really doesn't work out and it just annoys people.)
While very well done application that we have to give Jonathan a great deal of credit for, PeekAndPick is not without its issues or room for improvement.
PeekAndPick underlines the need for RSS feed publishers to exercise good form and provide descriptive titles and concise well-formed excerpts. Since quite often this is not the case, PeekAndPick would probably benefit from a server-side proxy that retrieves feeds, cleanses them and strips any extraneous information that the app does not need. Besides heading off trouble this approach also helps keep bandwidth use to a minimum. Optimizing bandwidth usage not only improves response time, but it saves the end user some money. Remember mobile data services are typically priced by the bandwidth consumed.
Most of the configuration for the app, such as defining your list of feeds, should be handled through a web interface and not the mobile device. At a former employer, where I consulted on a number of mobile projects, we professed "configure while seated, consume while mobile." Who wants to type in a URI like http://www.timaoutloud.org/xml/index.xml with their phone's keypad?
In my cursory review of the code, the application does not queue messages if a connection if not available. Given the unreliable nature of mobile networks, handling these occurrences is important, even crucial, to developing user-friendly and reliable mobile applications.
I could really use PeekAndPick myself because I find myself woefully behind when I'm away from my desk for any extended period of time. Alas, I cannot use it because I use a Blackberry 957 that is not Java-enabled. (I love my Blackberry and still find it useful, but I've been deeply disappointed that RIM has forsaken users and not continued to advance this model's capabilities by providing J2ME support as its descendants. I suppose that's for another posts though.)
Check out PeekAndPick and consider your mobile application future.
Infoworld is reporting Microsoft announced at DemoMobile that they have come up with the killer application for mobile: Location.
I laughed maniacally when I read this. Its not that Microsoft is wrong. They are quite right. I laughed because I had to wonder "what took everyone so long?!?" Is it so hard to fathom that location would be a crucial factor in mobile data services?
I worked for a company that did some consulting on mobile back when it was the next big thing. It became abundantly clear then that, as they say in the real estate business, it was all about "location, location, location." Despite names like the "wireless web", mobile Internet services are used in a very different context then from a desk with a full keyboard and large color screen. The user's environment necessitates the need for short, time sensitive location-based chunk of information. Mobile users do not surf.
Over two years ago I visited Seattle for the first time. Armed with my then new Blackberry 957 and with a WAP browser I was walking around with a colleague looking for a place to eat. Being enthralled with the power of mobile, I pulled out my device and went into 10best.com's mobile service to find a seafood restaurant. Dozens of clicks and 40 minutes later we found a place almost by dumb luck. I had to navigate through several levels, (Portal menu to 10best menu to Seattle to restaurant to seafood etc.) and manually scan each listing to make a determination. Besides being laborious, I was never in Seattle before and didn't know where most of these locations where relative to where I was standing. I never tried that again.
When asked by clients if they should build mobile app X, we would advise "only if it is better and more convenient then other options." With this understanding mobile applications location because the differentiating factor from mediums like the desktop. This makes location a near requirement to good mobile applications.
In all fairness, I do have some sense of what took so long. Determining location of a mobile user is difficult. Global Position Systems (GPS) requires too much power. Cell-tower triangulation can be highly inaccurate especially in big cities such as New York where signals ricochet off buildings. Determining location also requires the roll out of additional equipment. I am of the opinion that location was more important to mobile data adoption then 2.5G and 3G bandwidth and that the telcos place their efforts in the wrong place.
Going back to my trip to Seattle, ideally I should have only had to select restaurant recommendation and perhaps the type, seafood. I should have then received a list of 3 or 4 of the closest right away because the application new I was in Seattle standing near the Pike Place Fish Market. My personal killer app when I did a lot of business travel would have been a service like this for locating the nearest Starbucks. One click and "Here is the closet Starbucks. Do you want directions?"
In another astounding revelation, CNET is noting that "Push technology is finding redemption in millions of cell phones." What is this push technology? SMS and always-on wireless email. (I developed a homespun solution with Blagg that pushes news excerpts to my device periodically throughout the day. It took me less then an hour to setup.) Once again this makes a lot of sense, but I am astonished at how long it's taken the industry to get it right.
