Views
A Weather Service
From PicoForms
There are a number of online services that provide weather forecast information. The data they use is often provided by a web service that returns structured data representing the weather a user is interested in.
Before they can see a well presented, intelligible forecast, the data is transformed, by code running on a server or inside a browser, into the final visual representation.
Contents |
[edit] The Problem
Unfortunately for the application builder and maintainer, the technologies often employed to achieve the transformation from something like this:
<forecast> <forecast_date>07/31/2007</forecast_date> <forecast_time>06:00:00 AM</forecast_time> <WINDSPEED>3.2</WINDSPEED> <WINDDIR>65.0</WINDDIR> <WINDDIR_NAME>ENE</WINDDIR_NAME> <TEMP2M>10.6</TEMP2M> <ACLOUD>28.0</ACLOUD> <WEATHER>FA</WEATHER> <RAIN>0.0</RAIN> </forecast>
to something more like this: 
can be an expensive, time-consuming and labour-intensive fiddle.
[edit] The Solution
An excellent way around this problem is to build a framework to manage and hide the complexity of lower-level functionality. Whoever builds the application is then able to focus on the data they are working with and the end-user experience.
This is effectively what PicoForms' XForms implementations give you.
With XForms there is no need for more than the simplest data transformation as XForms already speaks XML, and PicoForms products support the creation of sophisticated data display and interaction mechanisms over the standard framework supplied by XForms.
As an example, here is the code that the XForm author needs to write to turn the raw forecast data into something more presentable:
<xf:output value="concat(WEATHER, ' ', WINDDIR, ' ', TEMP2M, '°C', ' ', forecast_time)" appearance="weather"/>
This uses standard XForms syntax, so the code will work in any XForms implementation, not only PicoForms'. However, not all implementations will understand appearance="weather" to mean that the data contained in xf:output should be converted into the image we have already seen. However, the worst that can happen is that the data is displayed as text; the application will still work.
The advantage of this approach for the application builder is that they can concentrate on providing the functionality their application needs, rather than on the lower-level plumbing on which their application depends.
This approach pays off by making initial development much faster than it might otherwise be, and in the longer term it by makes applications simpler to maintain.
Let's suppose the format of the raw weather data has to change for some reason. The generation of our weather widget is already independent of the incoming data format, so it doesn't need to change at all. All we have to do is to alter the simple transformation of the raw data into the format the widget needs.
This might be as simple as changing our one line of code to something like:
<xf:output
value="concat(PARAM[@name = 'weather'], ' ',
PARAM[@name = 'Wind dir'], ' ',
PARAM[@name = 'Temperature'], '°C',
' ', TIMESTEP/@time)"
appearance="weather"/>
On the other-hand, if we need to alter the appearance of the widget, it can be changed without having to make any changes to the XForms that use it.
This is not to trivialise the effort still required to build a useful application. However, now the author is able to fully concentrate on their core concerns:
- Understanding the data and its format.
- The user experience.
[edit] The Example Application
PicoForms would like to acknowledge the kind help of Metcheck in putting together the application now hosted on the PicoForms Web site.
We decided to build our application to run on mobile devices, such as cell phones and PDAs. Although, it also runs quite happily in our plug-in for Microsoft Internet Explorer.
We wanted to demonstrate how XForms flexibility combined with PicoForms implementation provides an excellent platform for putting together good looking applications with relatively little effort.
[edit] Using the Application
The application is restricted to providing forecasts for UK locations. The location can be expressed as the name of a town, county or as a postcode.
On loading the application you are presented with one input box, into which you can type the location of your choice.
Not the most exciting user interface perhaps, but it does the job.
- The input is already selected, so you just need to click on the little round button in the centre of the arrows to enter the text editor.
- Type in the name of a UK town, county or a Postcode (the first part of a postcode is sufficient).
- When you have finished typing, click on the right-hand button below the word OK.
The location is sent to the Metcheck web service. If the location is found, a forecast is returned, and rendered as below.
If the location is not recognised by the Metcheck service, an error is raised. In such a case the user is informed thus:
Navigation of the forecast is managed by use of the arrow keys to move around, and the central round button to select which day's forecast to view, or to change the location.
[edit] Conclusions
- We now have a simple XForm application of about 85 lines of code that could form the basis of other, cleverer applications.
- The application will run on mobile devices and in a desktop browser equally well.
- We can change the XForm without having to worry about breaking the code that generates the graphical representation of the weather, and visa versa.
