Diary Location Field Past its Sell by Date

Written By: Peter Abrahams
Content Copyright © 2018 Bloor. All Rights Reserved.
Also posted on: Accessibility

The location field in electronic diaries has not changed in over 20 years. It is inadequate to support modern integrated apps and accessibility requirements.

I was an early adopter of Personnel Digital Assistants (PDA). In 1997 I was working for IBM and was given a Palm Pilot by Bloor Research, I have never used a paper diary again. The benefits were obvious:

  • Synchronisation with my office computer diary meant that I did not have to worry about losing my diary as everything was backed up.
  • I never again had the embarrassment of not being able to read my own writing.

Over the following 20 years I have moved from IBM to Bloor, from IBM mainframes and Microsoft Windows to mainly Apple and the Cloud. Through those changes I have been able to automatically move my diary and contacts more or less seamlessly. This has been possible because the data structures have not changed.

This was fine until recently, when I have found the lack of structure in the diary location field increasingly annoying. The problem is I now want to share the location information with other digital applications such as maps, car sat-nav, public transport route planners etc. It sometimes works but often does not.

In the past the location information was just text that I could read and understand; the fact that it has a lot of structured information that may, or may not, be included was not important to my understanding. However, digital applications need to be able to extract the pieces of information that are relevant.

Let us look at a few examples (all the locations are fictitious):

  • Starting with a complex one that I came across when I was going to a conference – Board Room, Big Bank, Level 35, 2 Church Street, London, EC1 WWW, UK. Basically this has two parts the building address, and the location within the building. I needed both to get to the meeting but I cannot pass all this information to another app and hope it can pick out the relevant information. To have any hope of things working I had to remove the room information and put it in the diary notes field along with other information. Not an easy solution and particularly difficult to do if the location information is included in an electronic invitation.
  • So what about 2 EC1 WWW some apps may recognise that as a building number and a postcode. Two problems firstly it might not be and I may be sent somewhere else or probably no where. Secondly, postcodes define where the post is delivered which may not be the public entrance to the building in the worse case it may not even be the same building, for example the postcode of a church I go to takes you to the vicarage which is half a mile away from the church.
  • Jim’s flat. Artificial intelligence on my system may allow me to type that in and then add more detailed location information from the contact app.
  • Mr Chips house Azan near Timbuktu. This is a typical address for most people in the world especially in the third world. But similar problems can exist in the UK for example ‘The pig enclosure, Alresford County Fair, Dorset’. A solution has been developed for this called What3Words which divides the world into 3 metre squares and gives each a memorable three word identifier for example ///player.broom.lint so that could be added to the location information. Note the triple slash at the front which is an indication that what follows is a What3Words address.
  • Finally you could use latitude and longitude 44.0989 31.0767 which is accurate but not memorable and not understood by all apps.

So what is the solution? The industry could carry on doing nothing and let the users struggle on and find work-arounds.

But surely a better answer is for a new standard for the location field; except that setting up a new standards committee then letting it take its time to report is much too slow.

Pragmatically what we need is for one of the big companies with diary products to create a new standard and provide import and export functions to/from the new format.

The first step should be to look at the address field in address book, this has some structure to it: street, town/city, county, postcode, country. This could be improved by:

  • Adding a building name and number fields separate from the street field.
  • Adding a What3Words field.
  • Adding fields for latitude and longitude.
  • Defining all fields as optional. In particular apps should not insist on the county field being filled in, in the UK county is obsolete in most addresses and in London you have to specify Greater London which is not really a county.

This enhanced data structure should enable any building to be located. We then need a new structure to define the location within the building. There are lots of different ways to identify a location within a building including: floor, room name, room number, company name (for buildings with multiple companies). There are undoubtedly other ways fo defining a location within a building so there needs to be some free form fields available. So I would suggest the following new fields be added to the location data structure:

  • Floor
  • Room name/number
  • Company
  • Free form fields

This new structure needs to be implemented in the contact and diary apps. The export function for both the apps needs to be able to export the new structures or convert them into the existing structure. The import function should enable data in the new structure to be imported as is; and for data in the old structure artificial intelligence could be used to create a new structure or all the data could be put in the street field for the user to convert manually.

If these changes were made then there could be a seamless integration of diary and contacts with other applications such as maps, route planners and sat-nav. Itmight even enable specialised apps to direct you around large buildings such as department stores, malls, train stations and airports.

My area of expertise in Bloor is usability and accessibility. This suggestion is obviously a usability improvement but in particular it would benefit people with disabilities.

I look forward to hearing that one of the major players, or maybe a start up, has implemented the changes and is benefitting from the improved functionality.