Find Me A Place To Eat?

From PicoForms

It is a classic problem: you are somewhere you don't know, and your stomach is telling you it is dinner time. It is not that you want to argue with a major organ, but on the other hand you want to make sure you fill it with something decent.

There are plenty of independent sources of information that can tell you where you would probably enjoy eating, but they may not be handy. If there is a book shop or library nearby, you may be able check out the options quickly, but otherwise, what do you do?

To take a step back, and forget our hunger for a moment, we have just encountered the kind of requirement that brought about the "pocket" guide in the first place: a need for information based on current time and location, that cannot easily be met other than by some convenient, portable information source.

There are now plenty of online services that make a living from meeting this class of need, and over the last couple of years they have started to take advantage of the emerging mobile platforms.

The modern mobile phone, especially one with GPS capability, is now ideally placed to fulfill this requirement as never before: by providing a location sensitive window to relevant online information sources. Your phone knows where you are, what time of day it is, and is certainly more than capable of running the application that will allow you to search for a place that meets your culinary requirements.

PicoForms' mobile platform takes a lot of the hard work out of building applications to take advantage of modern mobile hardware. The platform insulates the developer from differences in targeted hardware, and offers excellent integration with existing Web-based information sources.

[edit] A Sample Application

The application outlined below demonstrates as far as it can without being on an actual mobile phone, how an application can take advantage of knowing the position of a user to present relevant information.

Furthermore, the application takes advantage of common device capabilities to allow the user to interact with, and add to the information source.

So, you are wondering about where to get a meal in a place you don't know. You take out your mobile phone and start the Eating Guide application.

This gives you the options either to find somewhere for a meal, or to add a review for a meal just eaten. As we develop more related applications they can be added to the menu. So, after dinner a user might want to find a good pub, or a chemists, depending on how good the meal was. We can add options for those in the future.

Incidentally, the application options are just standard XForms controls styled to look like a menu. In the next screenshot we will see the same form control type looking very different. The important think is that the code always looks exactly the same to the XForms author when they want the user to be able to trigger some action, no matter how it ends up being presented to the user.

This may appear a rather subtle point, but it this separation of logic from presentation is key to allowing XForms a relatively simple syntax, and making XForms themselves so easy to repurpose.

Well, our user selects "Where to Eat?" and is taken to the search screen. This includes a number of options with pre-set values. The search screen works on the premise that it already knows who the user is and so is able to load the preferences that they saved the last time they used the application. The Remember option allows them to save any modifications the make this time.

It would be possible to add further options fairly easily, for example, the user could be allowed to select more than one cuisine, or specify that there must be positive reviews of any restaurants in the result set.

Of course the application also has to know the location of the user. This can be determined with considerable accuracy if the user has a GPS unit connected to their phone, and this is likely to be the case more often in the near future.

Alternatively the location of the mast from which the phone is getting its signal can be used (subject to legal restrictions in your country). This will only give an approximate location, but it can be used to present the user with a map which they can navigate to pinpoint their exact location.

To cater for the more organised user who wishes to search for somewhere prior to arriving at their destination a more traditional interface can be offered, in which the user must select a town or district in which they wish to eat.

Here we assume the more elegant GPS solution to be present, and so the application already knows the user's location when the search query is submitted.

We have now collected enough information from the user both to execute the search that they have initiated, and to present targeted advertising, perhaps on behalf of establishments that will be represented in the result set.

The search executed on the server does its best to return a useful result.

• First it looks for exact matches.
• If none are returned it will instead look for restaurants that match all criteria except cuisine (on the grounds that distance from the user is the next most important search criterion.
• If there are still no results returned any restaurants within the distance stipulated are returned.
• Finally, the user is asked to modify the search criteria, or go and stand somewhere less remote from civilization.

In this case we returned a massive two hits. Clearly some kind of ranking options will be necessary for when a substantially larger result set is returned.

The rating graphic adjusts itself according to the average score given by reviewers.

You will also notice that there is an option to view more information, and that the application has identified the user as a reviewer of this particular restaurant. Although we have not yet made use of this in the search interface, it is possible for a reviewer to indicate not just a score, but also whether or not a particular restaurant is a favourite. These could be used both in the search definition and as a means of ranking results.

So, if they take the plunge and view more information the user is confronted with the address of the restaurant, a button that allows them to call the restaurant; another that will display a map showing the user's position relative to the restaurant; and lastly an option to add (or edit) a review.

Beneath are the reviews and ratings along with their date, and, as here, an uploaded image (4 pieces of pasta artistically arranged on white plate).

Many modern mobile phones include a camera, so it seems an obvious step to allow a review, perhaps written during the meal itself, to include illustrative photographs.

If the user decides to add or update a review they are shown this simple UI. The current date is added automatically, but can be changed by the user. When the user selects "UPLOAD" the phone camera is switched on, and the image taken is added to the review.

If the user is unsatisfied with a shot they can simply delete it (button below image) or replace it with another photograph.

The interface is sufficiently simple that a review can be written and posted whilst still sitting at your table. It might be useful to break down the rating into categories such as service, presentation, taste, wine, etc. This will reduce the amount of typing required by the user; make reviews easier to compare directly and allow for more sophisticated search options.

[edit] Beyond The Food

We have demonstrated that a location-sensitive application, running on a small device is able to provide useful information to the user. The sample application has only hinted that the user is providing equally useful information about themselves in return. We shall take a few moments now to examine the way businesses could use what the user is saying about themselves.

There is certainly scope for including advertising content, though this must be handled carefully, as screen real-estate is at a premium. Ideally advertising content should be provided as part of the information package sent to the user. It could include images of restaurants, sample menus and even promotional offers for people booking directly from the application. These might not be viewed as advertising by a user, but they help restaurants to differentiate themselves.

Then there are the related services mentioned above. For example our application could be linked to another dealing with public transport and taxis services, so as to be able to offer not only more distant venues, but also a means of getting there and back.

Similarly the user might be interested in entertainment venues nearby, or the whereabouts of a good pub. These warrant separate search interfaces of their own, but when linked they add value to the user, and to businesses that pay to advertise through the services.

In the end we will have a front menu that allows the user to decide which kind of service to give priority to: food, drink, entertainment, and then to provide a search interface that meshes together facets of all those things to help the user to make more informed and complete decisions, and for businesses to have a better picture of their customers, to help them to refine and adapt the services they offer.

[edit] Conclusions

Clearly modern mobile devices, when combined with tools such as PicoForms' Mobile platform, are able to offer a great platform for new, useful, location-sensitive applications.

These should not be viewed as straight ports of desktop applications, as there are both different challenges and opportunities to be faced when reaching your customer through their phone. That said, with PicoForms' tools built on mainstream Web technologies, there is usually considerable scope for reusing existing assets, such as online data sources.

This is undoubtedly a good time to develop a presence in a growing marketplace for this class of mobile application, and PicoForms is well placed to help you make that presence an effective one.