Wireless Wonders

No news, just comment about mobile phones and services, from a veteran practitioner...3G, GPRS, WAP, Bluetooth, WiFi, etc...

Thursday, June 22, 2006

Calendar in my radio station (idea #98)

Previously I suggested using a digital picture frame to display messages from a PC, such as calendar reminders (see idea #87). The general idea is to grab the user's attention via the "bump into effect". An alternative approach is to play announcements through a radio, a bit like traffic alerts that break into the program. For example, when listening to music in the kitchen, the user would here an announcement like "you have email from fred" or "you have a meeting at 3pm" etc. Most likely, the radio would incorporate Bluetooth or WiFi to receive the announcements from the PC.

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

A gate in the wall via personal-use open APIs (idea #97)

Previously I posted that operators are holding back their ability to create new business opportunities by effectively limiting innovation in their industry. This is because, unlike the Internet, a huge ocean of software innovators and entrepreneurs are shut out of the operators' walled gardens. Operators need to find a way of courting innovators without breaking down the wall.

One possibility is to create a set of open APIs into the operator network to allow mash-ups, but with a strict "personal use only" agreement and some kind of resource throttling where necessary. Most of the usual operator APIs could be made available, such as location, 3rd-party calling, texting, MMS, as well as new ones (such as call records - see idea #94). The operator could also offer an open-source SDK for a server framework to allow developers to quickly build Internet-hosted services with these APIs. A developer can play with this to their heart's content, only able to implement non-commercial services against their own phone account with the operator. Access to the APIs should be free along with a degree of free usage as an incentive. Other features, such as static public IP address for the device could also be included.

The benefits are that developers get a play pit, which is what developers like, but without operators having to think about what's the business model to allow x, y or z service on my network, as these new services are limited to developers in a way that doesn't pose a business threat. What the operator gets is a community of developers doing interesting things with their network i.e. innovation. This may or may not lead to actual service ideas with mass-adoption possibilities.

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

Voice notes with text navigation (idea #96)

Many phones incorporate a "voice memo" feature that allows digital voice recordings to be made. However, often this feature is next to useless. To start with, open up the recordings folder and the user is often confronted by a long list of obscure file names, like 24200011.amr, 24200012.amr and so on. It's like the old days of computing all over again, before computer scientists realised that normal people were trying to use their software and before usability - "design" - became vogue (obvious?).

The key missing ingredient is voice recognition. This is not beyond the realms of a mobile phone's processing capabilities, especially with today's powerful low-cost processors. Some phones today even have graphics accelerator chips in them to make 3D games go fast!

What I think is worth exploring on the mobile is a hybrid approach to allow speech files to be navigated using a text-driven interface, but reviewed and edited using voice. For example, I record a series of voice notes and can then look through the notes using the first few words from each note. I imagine being able to spin through the opening words of each note using a thumbwheel and then clicking on the entry to hear the voice note again. If the voice note is large, I can use a similar tool to navigate through the note using "text clips" of the converted voice stream.

Using this approach, the use of voice as a tool for note taking becomes viable. It also means that it is not necessary for entire audio files to be converted, which might be too costly in processing terms, especially if fast and accurate performance is required. Performance and accuracy can be improved by uploading the voice files to the PC for some serious number-crunching offline.

An additional feature to be considered is voice search, using a spoken word to find matches in the voice notes.

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

Wednesday, June 21, 2006

Unified addressing (idea #95)


Previously I have argued for the ability to "dial a website". At one time I suggested changing the UI on phones to incorporate a "connect" ("@") button, as shown in the image on the left. Of course, some phones do incorporate a dedicated portal button to launch the operator's home page in the browser with just one click - an idea used heavily by Three. However, this is not a short-cut button, but a data entry button that follows an input string, namely a number (or it could be a domain name).

I still think the idea has merit, but in a modified form. It seems obvious now, but what the connect button should do is allow the user to enter a number and for the phone to return a list of services associated with that number, such as "call", "website", "text", "download", "find", "email" etc. A client on the phone performs a look-up of the number to see which services are registered with the number. A number owner is free to register any services they wish (within a defined allowable set). For example, if my number is 0977115554 (which it isn't), I could register wirelesswonders.blogspot.com against that number. I could also register an email address, a postal address etc. These would all be DNS-type look-ups, as already possible using ENUM mapping.

The objective still remains that we ought to be making it dead simple for mobile users to connect to services, which is not easy on today's phones. We don't need to wait for any rocket-science or massive core-network upgrade (i.e. IMS, which needs enum) to justify moving to such a unified addressing scheme now. It can be done today and is probably a highly useful aid to mobile services adoption. The use of a "connect button" is a design issue, although I think it has merit.

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

Tuesday, June 20, 2006

Pretty in pink...

There are so many pink mobiles. When I posted a while back (pre pink-fad) about the idea of there being a "Women's Mobile", I said that I didn't mean a mobile with flowers on, but that is exactly what Siemen's latest "Poppy" design has. Things have moved on and we now have sites dedicated to "women's gadgets", like Shiny Shiny.

While at Shiny Shiny, I noticed the "Beat Buckle", which enables an iPod to be carried on (used as?) a belt-buckle. This reminded me of my crazy cellular socks idea (# 58), which was supposed to be a joke, but looks like someone took it seriously with the cell phone garter. Moreover, it has now become fashionable to puts socks on the phone, which sounds like it has excellent re-cycling potential to me (after washing).

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

Monday, June 19, 2006

Context awareness via phone habits (idea #94)

Recently I wrote a conference paper for Motorola about using context-awareness to improve the end-user experience. Context awareness is about bringing any additional data, not generated by the application itself, into an application in order to enhance the user experience. For example, if I go to make a call to Fred, the "dialling app" on the phone could detect that I have an urgent email from Fred. Therefore, I may choose to read the email before making the call. The app found out about the email by asking my Gmail account. Context can include all kinds of data from anywhere, as long as it is somehow relevant to the task in hand.

In the age of Web Services and Mash-Ups, it is becoming increasingly possible to augment services in this way. Moreover, I have argued in the paper that many service creators will begin to incorporate two levels of service in their application. The first is the core functionality and the second is generating meta-data about the usage of the application. This meta-data shall be made available via an open API for other services to consume and use as context. In this way, a context pool shall slowly emerge on the Internet. It will become commonplace for services to share data, but this will need to be done in a secure and reliable fashion to guard user privacy and so on. Identity federation will probably be a core enabling technology so that services can talk to each other with the users' permission.

The use of tagging shall be important in the context pool. For example, tagging can transform a "coffee shop" in a mapping application into a "meeting place", which will be useful context for a meeting application (as per the opening chapter of my book). Additional tagging by a variety of users can transform "meeting place" into "good meeting place" and so on. It won't be necessary to know the tagging taxonomies in advance because applications will increasingly have "soft interfaces" by incorporating search into the workflow. In other words, when I use an application to set up a meeting, the meeting place could be selected via search to allow the user to play around with different tags as keywords. Of course, the search will be conducted by giving precedence to the context pool before going out to the net for more results. If the search knows that a user relies on Acme Maps for finding places, then it will look in the user's tagged favourites there first.

This is a big topic, but one of the keys is the unleashing of context data, which comes from a variety of sources, particularly from services that we use every day (and other key sources, like the clickstream in our browser, which is more likely a useful pointer into the context pool).

There are so many potential generators of context. Let's consider in this post (for idea #95) my phone call habits, or my phone records: received, dialled and missed calls. This is a potential gold mine of context data for other applications. Imagine these records are available via a Web Services API on the net and that using identity federation a user can give permission to another service on the net to access this API. A task management application could use these records as useful context data. For example, it could tell whether or not a scheduled call was made to a particular number. An online phone book could also use the data by importing unrecognised numbers and prompting the user to add names. There are plenty of other applications, but it isn't for me or any service provider to dictate them. Once open APIs become available that release service usage and context data into the net, users will have much greater power to create useful and interesting services. Sooner or later, operators will realise (some are already) that this kind of net-friendly and open approach to services is the only future for mobile applications.

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