Updating the SFO Museum Wayfinding Service - Interface changes, WebShare and Nearby

Since the last blog post about adding custom publications for wayfinding routes we’ve made the following changes and improvements:

• Lists and thumbnail views for route steps, galleries and public art works along a route and objects from the SFO Museum Aviation Collection related to a flight arriving at or departing from SFO have been standardized and moved in to modal dialogs.

• When supported by the browser the Web Share API has been enabled for linking to (and sharing) individual routes.

• The new “nearby” feature allows you to find galleries, public art works and other waypoints close to arbitrary points inside the SFO terminal complex.

Interface changes

The most noticeable change will be updates to the wayfinding interface. Lists and thumbnail views for route steps, galleries and public art works along a route and objects from the SFO Museum Aviation Collection related to a flight arriving at or departing from SFO have been standardized and moved in to modal dialogs. Instead of trying to squeeze multiple lists, usually of different lengths, in to parent elements with fixed sizes and scrolling controls, a short description of each list is displayed and, when clicked, launches a modal dialog that can take full advantage of the available screen real estate.

For example, now that collection objects related to flights in and out of SFO are displayed in a stacked list, rather than three-abreast, there is ample space to display complete titles and credit lines for each object.

Every item in these new lists also has a new “Show on map” link which will open a second modal dialog showing just that item and its location on a map of SFO. These maps have a “geolocate” button that will, assuming you are physically located in the SFO terminal complex, use your current location to generate a route to the specific item you are looking at.

Technically, what’s really happening is the site is determining the closest waypoint to your location and using that as the starting point for the new route. This is how the new “nearby” feature works. Both the nearby feature and the details of how the geolocation functionality work are discussed later in this blog post.

WebShare API

In browsers that support it we’ve enabled the Web Share API which is described as a programmatic interface to:

…allow a site to share text, links, files, and other content to user-selected share targets, utilizing the sharing mechanisms of the underlying operating system. These share targets typically include the system clipboard, email, contacts or messaging applications, and Bluetooth or Wi-Fi channels.

If supported a new “Share this route” link will be displayed over the default “Link to this route” link:

When you click the link it will display a menu with all the different ways your device supports for “sharing” things like text and images and links. For example:

The link itself will also have a long-form description of the route being shared. For example here’s the text that’s included when sharing the route, through the terminals at SFO, for Air France flight 84 arriving in San Francisco as a text message:

Here’s a screenshot of a conversation that happened while I was writing this blog post:

Nearby

The new “nearby” feature allows you to define an arbitrary point inside the SFO terminal complex and list all the SFO Museum galleries and exhibitions, public art works from the San Francisco Arts Commission and other waypoints near that location. You can limit results to a specific floor level or by their place type and waypoints will be automatically filtered to exclude things that are post-security if the map’s center-point is pre-security and vice versa. You can try the “nearby” feature here:

You can also link to a specific spot using the “nearby” service by appending the relevant latitude, longitude and map zoom level to the URL. For example here are all the things near the Gate E6 waiting area in Terminal 3:

One of the challenges of designing a “nearby” system at a place like SFO is that the terminal complex spans multiple levels each with its own set of waypoints. A web browser’s geolocation functionality will, when available, returns an altitude property indicating how many meters above sea level it thinks the device doing the geolocating is. With that information we can make a good faith estimate about which level of the terminal complex a nearby query is being made from.

It is often the case, however, that elevation data is not included with geolocation events. When that happens the wayfinding site will interrupt the geolocation flow and ask you to specify what level of the SFO terminal complex you are on. I mentioned that when a browser does return altitude data we make a “good faith estimate” to associate that elevation with the relevant level at SFO. As of this writing there may still be errors in our approach because elevation data do not apply equally across all parts of the airport. That is the floors and ceilings for “Level 2” in the International Terminal have different heights than the “Level 2” in Terminal 1. We are waiting on more accurate numbers from the airport itself but it points to the need to develop an elevation-aware point-in-polygon interface (an interesting technical challenge, albeit one I kind of wish we could avoid) and corresponding data attributes to account for these differences.

It is also worth noting that consumer grade elevation data is not very precise either as demonstrated by the tool we developed to collect the data in use today (discussed below) so in the end it may be easiest to always interrupt the geolocation flow to prompt visitors for the level they want to scope queries to. We’ll see how things go but we welcome any feedback you have using this new feature.

Under the hood

The rest of this blog post gets in to some of the technical details of how we implemented these updates. If that’s not of interest you can stop reading now and we invite you to investigate the interface changes we’ve made and try the new “nearby” feature here:

ios-altitude-recorder

As mentioned, SFO Museum needed a tool to measure, or more precisely to approximate, the different elevations in the SFO terminal complex in advance of more accurate data being delivered by the airport itself. ios-altitude-recorder is that tool. It is an iOS data collection application designed to record location information as it is generated by the operating system’s CoreLocation framework. Locations can be recorded explicitly in atomic units or automatically as they are received. Data is persisted using the SwiftData framework (which means the application only works with iOS 17 or later) and it is possible to export location records as a GeoJSON FeatureCollection.

That’s all the application does. It is being released as-is in the spirit of generousity in the hopes that it might be useful to other museums and cultural heritage institutions who need to collect similar data or simple as a reference implementation for how to develop bespoke location-based iOS applications.

Please remember that indoor location continues to be imprecise, as you can see from the screenshot above where I often appear to be floating in mid-air or standing in the middle of the road when I was actually standing indoors, and you should factor that knowledge in to how you use and interpret the data produced by ios-altitude-recorder. The source code for the application is available from SFO Museum’s GitHub account: