Screen scraping to my mobile...idea #62/100...

I have experienced many times the desire to access information on my mobile that is not available in a mobilised form. However, the information is available via The Web and is therefore, in principle, accessible via a mobile (e.g. in WAP format).

For example, my Blockbuster Online account contains various pieces of information that from time to time I have wanted to know whilst away from my desktop. This may not be a particularly compelling application, but it serves as an illustration for this discussion and idea.

However, I should first say that the phrase "compelling application" needs examination. I am inclined to think that the adoption of mobile data services is not about finding compelling applications. If only it were a lot easier to access various information sources via mobile devices, then users would slowly get used to the convenience of mobilised information and this would lead to a tipping point in mobile data adoption, similar to what happened with voice.

The future then is about building an information environment in which it is easy for information to flow from one device to another. In my view, this should be the real meaning of the market buzzword "seamless mobility". I have a slide in the seminar for my book that begins "Would the real seamlessness please stand up."

There is an obsession with seamless mobility in the context of multiple radio access technologies - WiFi, WiMax, 3G, GPRS, Bluetooth etc. Of course, multiple access technologies is an increasingly important aspect of mobile computing, but from a mass-user perspective this is just more techno-babble. Users are still stuck with more mundane issues like how the train timetable on their desktop is apparently inaccessible on their phone. A whacking great seam!

So, returning to the problem. On the Blockbuster site, I can see a list of videos currently allocated to me. This list is buried within a web page. However, this page doesn't display on my phone. Therefore, I should be able to select the data on the page that I'm interested in and scrape it off to my mobile. That's the idea. Simple!

Now, whenever I access that "page" on my mobile, I just get the data I'm interested in. Moreover, I could also select an option to have the data monitored for any updates (which could be via an RSS feed, but that's not important).

Ditto any information that I'm interested in. ..

After navigating a variety of web screens to find train times I need for daily travel to London (say), I scrape them onto my mobile.

I'm not going to discuss the possible routes to this solution technically, as there are programmers out there far more competent than I who should take this up. As I mentioned in my last post about Ajax, we should by now be thinking of models that make sense for mobile, instead of continuing with the one-dimensional approach that dominates the industry, which is that essentially mobiles are just tiny web browsers. This approach doesn't seem to be yielding much fruit.

The browser model is a publishing model. I think that the mobile environment would be much more effective if we implemented an effective subscription model. RSS is interesting in this regard, but it is really a publishing model made to look like a subscription one, because it relies on a programmer deciding on a set of information to publish as an RSS source. What I am discussing here is letting the user decide entirely what information they want to subscribe to, whether the information provider intended it, or not.

"Screen scraping" is one approach, although I am aware that it has problems if we think about how to implement it within the current WWW environment. However, don't get hung up on the details just yet - the concept is what matters. I'm convinced that clever programmers out there could make this concept work well. All of the technological ingredients we need are available - the progamming languages, the mark-up languages, the delivery protocols. The model is what matters. Of course, we could talk about RSS and Web Services, da-de-da, but "screen scraping" is a better end-user metaphor.

Let me make it plain.

I am looking at my Blockbuster page. I can see a list of information I want on my phone. I hover my house over that area and highlight the info I want. I right-click "send to mobile". I'm asked for a title. I type "My videos". My phone lights up and voila! There's a "page" called "My Videos". I can return to that page whenever I want in order to view the information, courtesy of Blockbuster's database, but not via their web page, nor via any mobilisation process that the Blockbuster people programmed for me (at least not overtly). I can also be notified of changes to the information.

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book

AJAX and mobiles...

If you frequent the knowledge circles of web designers and architects, then you can't have failed to come across AJAX.

No, it's not a famous scouring powder in the UK for scrubbing baths. It's a design approach for browser-based applications. Some disgruntled web-heads are upset about the new term, as it's possibly just a marketing spin for something that already existed.

Renaming old things can be a great way of creating a buzz. Whether Adaptive Path should have come up with a new term or not, they have certainly succeeded in generating a buzz and attracting interest in this approach. After all, here I am writing about it!

My interest, naturally, is in the potential of AJAX for wireless applications. To spare ourselves all the sordid detail about AJAX, the key concept of this design approach is the ability for a web page to pull new data in from a web server, as opposed to the browser. To see this in operation, you could try the interesting Google Suggest interface.

Notice how an area ("panel") appears below the text box and starts to fill with search terms that match the letters you type. What's essentially happening is that a small piece of code (JavaScript) associated with the web page is fetching search terms from the server. This allows the suggestions to dynamically and rapidly populate the panel area. If the entire web page, graphics and XHTML had to be fetched, instead of some relatively light weight search terms, this whole process would be slow and cumbersome.

That's the problem - slow and cumbersome - with a lot of web (WAP) browsing on mobile devices, which makes it painful much of the time. It therefore seems sensible that this approach would be a good fit for mobile. Interestingly, it is supported on Windows Mobile Edition 2003! Not surprisingly perhaps, as the heart of that piece of JavaScript that pulls the info from the server was invented by Microsoft (called the "XMLHttpRequest" object ).

The reason that AJAX and this XMLHttpRequest object are worth talking about is that whilst the user is interacting with the page interface (i.e. reading, thinking, contemplating, typing), the page can be pulling in new data without waiting for an explicit request from the user. In other words, asynchronously to the user commands, which is where the A in AJAX comes from.

Let's think of an application to illustrate the possible advantages of AJAX in the mobile context. Let's choose one of the most popular portal experiences, which is surfing for downloadable ring tones. Sorry if you don't use custom ring tones, but a lot of people do. Even if you don't, I suggest surfing your operator portal to get a feel for the pain involved.

(For this example, we have to put aside the fact that most browsers don't or couldn't support AJAX. Not only is the XMLHtt.... bit missing, but the necessary scripting and CSS support is missing too. However, we need to think seriously about what a mobile web browser should be able to do, and this is an important topic that I hope to return to. Fundamentally, as I have suggested many times before (and in my book), the logical progression from desktop browsers to "desktop-browser-lite" was, and is, flawed.)

The ring tones are usually listed in alphabetical order for each genre, like rock, 80's pop, indie, etc. Most portals seem to insist that users have to page through lots of listings to find the one they want to try (or buy). It would be much more efficient and usable to allow the user to scroll through a list of tones, or use a suggestion-panel, to home in on the desired tone. Also, if it's a midi tone, then it can also be pulled into the page without re-loading and allow a helper object to play the tone.

Of course, this is speculation. I'm not in a position to try this out with a mobile device and the actual performance and usability improvements are guess work. However, I suspect that the improvements would be real.


Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book

Directional interfaces...idea #61/100...

With a digital compass capability, it seems a useful idea to display geographically sensitive data on a mobile according to the direction it is pointing. If I point the device North, then I get the nearest fish-and-chip shop going North. Turning 180 degrees, I get the nearest fish-and-chip shop going South, or whatever else is of interest in a Southerly direction (for those that don't want fish and chips).

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book

The importance of Presence and Push-to-X...

The specifications for the latest 3G networks/handsets include recommendations for a generic presence capability, which is essentially part of a wider infrastructure evolution called IMS (IP Multimedia System), which is an area I am working in at the moment.

Any user of an Instant Messaging service will understand presence, which is the indication of buddy states, like "online", "offline", "busy", "do not disturb" etc.

The presence capability in next-generation 3G handsets (and 2.5G ones) is a service enabler, which means that other services can use it to enable advanced services. Instant Messaging is an obvious example. Another is Push-To-Talk (PTT).

In addition to presence, there is a companion service enabler called group management, which provides buddy and group management (e.g. add contacts, create groups, etc.)

Some vendors and operators have taken a view that presence is potentially a service in its own right that is chargeable, although this seems unlikely. However, it does depend on how the service is introduced and what the handset capabilities will be.

For example, one idea, which seems widely discussed, is the active address book. Instead of the current address books, which are merely electronic versions of their paper predecessors, the new ones will be "presence aware". This means that scanning the list of entries will yield presence information, if possible, for each entrant. Hence, we shall be able to see who is "online", "offline" and so on.

Presence information is potentially very rich and includes device capabilities too, so we would be able to see not only who's "online", but whether or not their device can receive a picture message or a video call.

Because the presence capability is generic, any service can potentially hook in to its network, so we could imagine a distinctly English service that enables us to see what the weather is like for each of our buddies in their current location. (The English talk about the weather a lot, which is more to do with social ice-breaking than any real interest in meteorology.)

The widespread penetration of presence has the potential for a profound transformation of mobile usage and habits, which is why it is being explored as a service in its own right. However, presence information usually leads directly to the use of other services, which means it is more likely to surface with the introduction of a symbiotic service, like PTT, which is probably the service that is attracting major attention from operators globally right now.

The point about presence is that it brings us closer to the contacts in our address book. Instead of a name being just another passive entry in the address book, it now becomes something nearer to the person it represents. Instant Messaging users will already know of the "sensing" phenomenon. When we see a buddy "online" in the contact list, we sense (feel) the person at the other end, simply because we know that they're there.

This sense of immediacy will lead to a greater urge to communicate, or connect. If we see that our buddy is online, then we might initiate direct communication, such as texting or an IM session. Or, we might access outstanding email messages or voicemail, or check their latest blog entries: all of which are examples of connecting. Within the emerging landscape of community-forming mobile services, connecting will be an increasingly important mode of mobile usage as distinct from communicating (person-to-person).

The urge to communicate (or connect) will be greatly enhanced by the new breed of "push-to-X" services. PTT will undoubtedly become commonplace, but others will follow hot on its heels, such as push-to-view, which is instant image sharing. The point here is that these services are instant - just one push of a button away. This new modality for mobile communications is going to prove irresistible.

Presence and push-to-X are generic service modalities that will have major impact on mobile device usage in the coming years. It is currently my view, along with others, that these capabilities, perhaps more than any other currently being introduced, will have the greatest impact on the transformation of mobile devices from telephones to personal-networking devices.

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book