Static Presentation Consistency Issues in Smartphone Mapping Apps

The explosive growth of the Internet coupled with the increasing use of location-enabled devices such as smartphones has led to an increasing awareness of the importance of location information, which traditionally has been presented with a map. For centuries, maps have been used to convey abstractions of spatial information in a manner that is aesthetically pleasing and familiar to their users. Often this came at the expense of accuracy, which users have found to be acceptable, usually due to conformance with commonly held beliefs. For example, labels for place names are supposed to be placed on the map so they do not overlap names of other nearby places, and winding roads with switchbacks are represented with a screw-like symbol where the number of turns in the symbol usually has no correlation with the number of switchbacks actually present. In the past, maps were used not only to present information but also to store information, and to provide easy and rapid access to it (also known as indexing using today’s parlance.³²).

Back to Top

Traditionally maps were drawn by cartographers, who were often regarded as artists. This took a considerable amount of skill, effort, and time, and the maps are still highly valued from both financial and artistic perspectives. The advent of computers, and the increase in their use to produce maps, as well as the diversity and increasing sophistication of the output devices on which the maps are presented and viewed, led to a dramatic decrease in the time needed to produce maps, and hence in their variety and distribution. In particular, maps are no longer created and produced only when there was a sufficient demand for them, where “sufficient” was usually defined quantitatively. Moreover, maps are no longer necessarily printed nor assembled in collections such as atlases, often with a common theme, such as the display of particular attributes like crops, land use, rainfall, and so on. Instead, maps are produced in a custom-made manner to display some specific spatial relationship rather than in groups, most often in units of one, and in a way that allows them to be manipulated.

The rise of the Web and the ease with which documents can be accessed, regardless of their physical location, has profoundly impacted the accessibility of maps and their customized generation and use. People do not hesitate to decide they need a map, and, in fact, results returned by search engines are often accompanied by a map when the result involves some location information. The results can be viewed dynamically, unlike atlases that are usually viewed statically, meaning that changes can be made through manipulation actions such as browsing (for example, Anselin,⁸ Esperança,¹² Samet³³) including panning and/or zooming, or manipulating what is termed a spatial spreadsheet.¹⁸ Moreover, the Web has made it easier to find and retrieve data by location (that is, index it) regardless of whether the location is specified explicitly or, increasingly more importantly, implicitly by virtue of the physical location of the user.

Back to Top

Location Specification

The explicit specification of location has traditionally been geometric (for example, as latitude-longitude pairs of numbers). This is often cumbersome, as users do not think of a location in this way. They often do not know it in this way or have easy access to it. More importantly, they are not accustomed to communicating it to others in this way. Instead, they are used to specifying a location textually (including verbally). A textual specification has a number of advantages. First, ease of communication especially on smartphone devices where a textual (also increasingly verbal via speech recognition, such as Siri on the Apple iOS platform) input capability is usually present. Second, text acts like a polymorphic type in the sense that one size fits all. In particular, depending on the application, which makes use of this information, a term such as “Washington” can be interpreted both as a point or as an area, and the user need not be concerned with this question. The drawback of textual specification of location data is ambiguity. For example, there are many locations named “Washington,” and they must be resolved (known as toponym resolution^7,22). Moreover, in some cases we are not even sure the term “Washington” denotes a location as it could be a reference to the name of a person (known as toponym recognition^21,30). This can be the case when processing documents such as newspaper articles, tweets, blogs, and so on. The drawback can be overcome by taking advantage of the fact that toponyms often appear together as in lists or tables where we can make use of clues such as prominence, proximity, and sibling (for example, Adelfo,⁶ Lieberman²⁵). The process of understanding and converting a textual specification of a location to its geometric specification is known as geotagging (for example, Hoffart¹⁷) and is beyond the scope of this article.

Implicit specification of location can be done in a number of ways including by the IP address of the user’s computing platform (regardless of its size) or, increasingly by an embedded GPS capability that provides the user’s physical location.

Another technique of location specification that is increasingly used with the rising popularity of touch interfaces combines implicit and explicit specifications to yield an approximate specification. Observe that a map, coupled with the ability to pan and to vary the zoom level at which the world is viewed, provides an inherent granularity to the location specification process, which facilitates this approximate specification. In particular, the act of pointing at a location (that is, by the appropriate positioning of a pointing device with the aid of panning) and making the interpretation of the precision of this positioning specification dependent on the zoom level is equivalent to permitting the use of spatial synonyms,^23,38,41 which are the hallmarks of approximate specifications. For example, a user posing a query seeking a concert in Manhattan would be satisfied by a concert in Harlem by virtue of proximity, New York City by virtue of containment, and Brooklyn by being a sibling borough of Manhattan in New York. Thus, users no longer need to know the exact name or position of the sought location. In other words, the touch interface serves as an implicit access structure to the data accomplished with direct manipulation. Of course, an index must be built (for example, Hjaltason¹⁶) whose access is achieved by software that translates the screen coordinates (using nearest neighbor techniques as in a “pick” operation in computer graphics) to the ones used by the index.

---

The Web has made it easier to find and retrieve data by location regardless of whether the location is specified explicitly or, increasingly more importantly, implicitly by virtue of the physical location of the user.

---

Back to Top

Mapping Apps on Smartphones

The almost universal adoption of smartphones, and, to a lesser but increasing extent, tablet devices (virtually all of which have an embedded GPS) has made location information a cornerstone of queries. This has led to the reinforcement of the realization that the map is the most convenient way (especially on the smartphone with its limited display size) of presenting query results to users and also to formulate and specify the query. This leads to a wide range of applications and the use of a wide range of sources for the maps.

The drawbacks of this wide range of sources for the maps is that the maps generated by them are not always produced in a manner consistent with the traditional concerns for the factors of/trade-offs between accuracy, aesthetics, and completeness, as well as not being in line with generally accepted cartographic principles (for example, Robinson³¹). To a large extent, the airing (as well as increasingly venting) of these drawbacks has lain dormant in the sense that people were subconsciously aware of them but were so satisfied with the resulting increase in capabilities they were inhibited from expressing their disappointment in their failures to live up to them.

However, all of these inhibitions were abandoned with the introduction of the Apple iPhone 5 smartphone and the accompanying iOS6 software environment. It replaced the use of a mapping app on Apple’s mobile devices based on Google’s map data (referred to here as the iOS5 mapping app) with an app that makes use of Apple’s map data (referred to here as the iOS6 mapping app as well as the subsequently released iOS7 mapping app and iOS8 mapping app). It also changed decisions as to what data is displayed (served to the user) in responses to queries (especially implicit ones through the manipulation of the viewing window). This replacement has led to significant changes in the user experience with apps that both make use of and serve map data, and has resulted in closer scrutiny of mapping applications on mobile devices as done here.

The mapping applications on the mobile devices (smartphones and tablets) are not the traditional ones where the map is used in a passive manner as is the case in atlases containing maps that are browsed leisurely. On mobile devices, the map is used in an active manner as a tool to enable such tasks as navigation and location finding, using pan and zoom. Here accuracy is paramount, and now issues of data quality and lack of quality assurance policies and protocols by Apple in releasing the iOS6 mapping app became very apparent. This resulted in errors such as misplacing the town of Uckfield in East Sussex in the U.K.² as well as others.^4,11 In fact, the public uproar over them was so large it led to the eventual dismissal of Apple’s leaders of the new mapping app project.³ Most of these errors have been fixed in subsequent releases of iOS6 and in its iOS7 and iOS8 successors. Nevertheless, some persist, such as marking the city of Faro in Portugal as a park⁴ (see Figure 1a from iOS8 version 8.1.2).

Notwithstanding these resolved issues, at times, we have found the iOS6, iOS7, and iOS8 mapping apps to be lacking from the perspective of presentation consistency when deployed on mobile devices such as smartphones due to the limited amount of screen “real estate.” For example, consider the map of Europe in an early version of the iOS6 mapping app given in Figure 1b. Here, the labeled countries are poorly distributed with a high concentration in Eastern Europe while not labeling major countries such as Italy and France, although their capital cities are labeled. In addition, Algeria is mis-labeled as “Alger.” Surprisingly, criticism from such a perspective has rarely been leveled before (but see Paolino,²⁸ Samet³⁶), which we do in this study in greater detail using examples of how they also plague other mapping apps.

Back to Top

Motivation

The motivation for our study is to take advantage of the fact a map provides an efficient way of accessing spatially referenced data when we cannot look at all of it at once. Our observations are based on the experience we gained in building the STEWARD,²⁴ NewsStand,^23,38,41 TwitterStand,^15,19,40 PhotoStand,³⁷ and TweetPhoto¹⁴ systems and adapting them (especially NewsStand and TwitterStand) to run on smartphones.^34,35 These systems access documents such as, but not limited to, news and photos with a map query interface (that is, by location and, to a lesser extent, also by topic). In these applications, as well as in many related ones, the map on the smartphone helps users to anchor and orient answers to queries in which they want to take advantage of spatial synonyms. In addition, we are motivated by the desire to be able to place spatially referenced information on the map such as icons for topics, image thumbnails (for example, Nutanong,^26,27 Peng²⁹), names of particular locations, names of people and diseases,²⁰ mentions of brands,⁵ or any other data that lends itself to being classified using an ontology.

Note the Gazetteer, which is used to translate textual specifications to geometric ones, can also be considered an ontology. The result is analogous to a mashup except, in our case, the mashup is hierarchical in the sense that as we zoom in on the map, additional spatially referenced information is displayed that was not of sufficient importance to be displayed when we zoom out completely. This zoom out capability is not available in comparable systems such as HealthMap^9,13 for disease monitoring.

This article compares the mapping apps using various presentation consistency properties broken down into two categories: static and dynamic. We focus on the static consistency properties although we also give a brief definition of the dynamic properties with more details provided elsewhere.³⁹ We also include a detailed description of the environments in which the comparison was conducted.

Back to Top

Comparison Summary

Our choices of presentation consistency properties are motivated by centuries-old classical principles used by cartographers that are derived from the static way in which maps have been traditionally browsed, as well as motivated by the continuously evolving dynamic ways maps are browsed that involve manipulation actions and have much to do with the platform used to view them (for example, an atlas versus a smartphone). The classical static presentation consistency issues involve the undesirability of label overlap and having a reasonable label distribution that are aesthetic in nature. Other static consistency properties include hierarchical consistency that simply seeks a consistent way of presenting labels of containing entities by requiring they must be included whenever they are visible in their entirety, while sibling consistency corresponds to labeling all visible spatial entities that are in the same level of the mapping object hierarchy. These properties pertain to issues related to the identity of the labels that should be present and the manner in which they are presented. They are the subjects of this article.

The dynamic presentation consistency properties are a result of the manipulation actions users take to browse the map and are often achieved by gesturing. They include pan, zoom, full zoom out, and wraparound. The pan and zoom consistency properties correspond to the integrity of the available gesturing actions in terms of retaining label information as the actions take place. In particular, the premise is if a spatial entity has been labeled, then the label persists as long as the spatial entity remains visible in its entirety. The full zoom out property reflects the desire to be able to view the Earth in its entirety rather than being compelled to apply pan operations to do so. Similarly, the wraparound property is an acknowledgment the Earth is round and again reflects the desire not to have to apply pan operations in the opposite direction to be able to view adjacent locations on the map. These properties are discussed in greater detail elsewhere.³⁹

In terms of devices, we compare the iOS6 mapping app (initially iOS version 6.1 on iPhone 5 and most recently 6.1.4), the iOS7 mapping app (iOS version 7.0 on iPhone 4), the iOS8 mapping app (iOS version 8.1.2 on iPhone 5), the iOS5 mapping app (iOS version 5.1.1 on iPod Touch), the Android mapping app (Maps version 8.0.0 on Android 4.3), Google’s iOS mapping app (version 1.0) for Google Maps data (referred here as the iOS mapping app for Google), and the HERE Maps app on Microsoft’s Windows Phone 8 (HERE Maps version 3.5.481.8 with map data 8.0.50.116). Although each vendor’s mapping apps are similar, they do not always yield the same result. At times, we also use the qualifiers “old” and “new” to distinguish between the versions of iOS6 used in our initial tests (version 6.1 in October 2012) and in our most recent tests (version 6.1.4 in April 2014 and later), respectively.

This distinction is necessary because we observed the algorithms used to implement the various mapping apps are frequently changed for a particular version of the operating system, even if the operating system is not updated. It is especially true for the label distribution and placement algorithms that we often found to yield different results for the same queries. This is because all queries are transmitted to the map tile server over the Internet, and the server makes the final decision as to what labels will be placed, and where, on the resulting map tiles that are also transmitted by the server. Therefore, do not be surprised if you cannot always repeat our observations. The important take away from them is the undesirable behaviors of some mapping apps should not be taken as absolutes but instead are just indications of what could possibly go wrong. Our comparison also contains the iOS Apps of Bing Maps, Nokia Maps, ESRI, MapQuest, and OpenStreetMap.^a

The accompanying table summarizes the comparison in terms of presentation consistency properties we want satisfied. Their satisfaction is primarily an issue on smartphones where the screen size is small thereby requiring panning and zooming for more information, while not needed on tablets where the screens are larger. The apps are detailed in this article and identified using I5 for iOS5, I6 for iOS6, I7 for iOS7, I8 for iOS8, A for Android, WP for HERE Maps on Windows Phone 8, IG for iOS of Google, IB for iOS of Bing Maps, IN for iOS of Nokia Maps, IQ for iOS of MapQuest, IO for iOS of OpenStreetMap, and IE for iOS of ESRI. The table denotes whether the property does not (×), partially (P), or holds ( ) for the apps.

Note the variation in the relative sizes of the screenshots in some of the figures due to the different devices we used. In particular, the screenshots for the Android and Windows Phone mapping apps are larger due to 2.5 × 4.3 and 2.31 × 3.86 inch screens for the Android and Windows Phone, respectively, instead of a 2 × 3 inch screen for the iPhone 4 and iPod Touch and a 2 × 3.5 inch screen for the iPhone 5 devices we used. The latter was used to perform comparisons with the iOS5 mapping app which is not available on the iPhone 5 as well as with the iOS mapping apps.

Back to Top

Hierarchical Consistency

Generally speaking, the name of a location should not be displayed without also displaying the name of its containing location provided the area spanned by the containing location is visible in its entirety (termed hierarchical consistency). Therefore, if Los Angeles is displayed, then so should the name of its containing state, California. While being desirable, examples can be found where this property does not hold for the iOS6, iOS7, iOS8, and Android mapping apps (see the discussion and examples of zoom consistency in Samet³⁹) as well as for the Windows Phone mapping app (for example, a scenario not shown here where Belgrade is displayed but not the name of its containing country, Serbia). In the case of the iOS mapping apps, it only holds uniformly for the Bing and OSM variants. For the iOS5 and Android mapping apps and for the iOS mapping apps for Nokia and Google, it holds only for Australia, Brazil, Canada, and the U.S., but does not hold for China, India, and Mexico. It completely fails to hold for the iOS mapping apps for MapQuest and ESRI.

Back to Top

Sibling Consistency

If the name of an object at a particular depth of the mapping hierarchy is displayed, then the names of all of its visible sibling objects should also be displayed and should use the same font type and point size or symbol (termed sibling consistency). In other words, if, for example, the name of one state is displayed, then the names of all visible states should be displayed using a consistent labeling scheme (for example, full name or abbreviation, abbreviation type or style, all caps, boldface font, font point size) while also obeying a stipulation that the labels not overlap and that the name of the containing country be displayed as well (hierarchical consistency). We discuss the satisfaction of this property only for states and provinces within a country and for continents within a maximum zoom out level map of the world. We do not discuss it for other objects such as countries within continents for which the sibling consistency requirement is generally waived due to impracticality. We examine it primarily for the U.S. and Canada. In our examples of countries, we often restrict ourselves to landscape maps as they maximize the amount of information that can be presented on the smartphone form factor.

For the U.S. map, none of the most popular mapping apps that are currently used satisfy the sibling consistency property in its entirety. For example, the Android mapping app (Figure 2a) and the almost equivalent iOS mapping app for Google (not shown here), at the level of zoom that permits the entire U.S. to be seen, use abbreviations and yield the same result. However, the sibling property is not satisfied for both of them as we see the names of two states (Rhode Island and Vermont) are missing.

Zooming in a bit further on the Android map in Figure 2a so the map spans almost the entire U.S. and applying a small amount of panning to see the remaining parts of the U.S. (see Figure 2b), finds that most of the names of the states are spelled out in full although some are abbreviated (Maryland, New Jersey, Rhode Island, and Vermont), while others are missing (Arkansas, Colorado, Connecticut, Delaware, Florida, Georgia, Illinois, Kansas, Massachusetts, Mississippi, New Hampshire, North Carolina, West Virginia, and Wisconsin). In the case of Colorado and Kansas, one possible explanation for omitting them is the presence of the label corresponding to the name of the containing object (which is the United States) thereby satisfying hierarchical consistency; however, they could have been included as there is room for them. The hierarchical consistency property is also satisfied for the various cities present in the sense the names of their containing states are also included. The names of a number of some of the states that are missing such as Arkansas, Georgia, Illinois, North Carolina, and Wisconsin could have been included as there is room for them.

The labels of some of the missing states in the Android mapping app (for example, Delaware, Massachusetts, and North Carolina), and of the abbreviated ones (for example, Maryland, New Jersey, and Rhode Island) could have fit by extending some parts of the labels to the adjoining body of water even without abbreviations as done, for example, for San Diego (see Figure 2b).^b

For the U.S. map, the iOS6, iOS7, and iOS8 mapping apps only display the names of a few cities as well as the name of the containing country (with the exception of iOS7), which is the U.S., but do not display the names of the containing states (see Figure 3a). Zooming in a bit further so the map spans almost the entire U.S. and applying a small amount of panning to see the remaining parts of the U.S. (see Figure 3b), finds the names of most of the states are labeled using a multitude of formats ranging from being fully spelled (Ohio, Iowa, Utah, Maine, Idaho, Texas), partially spelled out (for example, Tenn for Tennessee), specified using standard abbreviations (for example, KY for Kentucky), and abbreviated with periods (for example, N.C. for North Carolina). Notice the name of the containing country is present and does not prevent the labeling of any states in its vicinity although some visible states are missing (Connecticut, Delaware, Maryland, Mississippi, New Jersey, and West Virginia). Clearly the sibling consistency property is not satisfied, although the hierarchical consistency property is satisfied.

Contrast the iOS8 mapping app with the iOS5 mapping app (see Figure 3c), where all states are labeled using the USPS (U.S. Postal Service) abbreviations placing them in the ocean and adding appropriate pointers when there is not enough room. Notice the containing country is included but no cities are labeled. Both sibling and hierarchical consistency are satisfied by the iOS5 mapping app.

Of the remaining iOS mapping apps (not shown here), only OSM satisfied these two consistency properties as most of the data requires a significant amount of zooming in to see and the non-overlap property is not satisfied. The iOS mapping app for Bing labels the states using both fully spelled out names and abbreviations all with a standard font, but does not use the same font point size. Its novelty lies in the use of a watermark-style font for the containing country thereby enabling it to overlap the names of the states although a number of states are still not labeled. The iOS mapping app for Nokia makes use of standard abbreviations but misses a number of states and Canadian provinces due to labeling of the container U.S. with “United States of America,” as well as the containing continent “North America,” both in a relatively large point size watermark style. Unfortunately, the states and provinces are also labeled using a watermark-style font and thus the nonoverlapping label requirement prevents some of them from being labeled unlike the iOS mapping app for Bing. The iOS mapping apps for MapQuest and ESRI make no attempt to present a map of the states of the U.S.

Presently, the Windows Phone mapping app cannot be used in landscape mode and thus we only review its operation for the U.S. map in portrait mode where it uses abbreviations for the names of the states and labels some of the cities in which case it also labels the containing states. In addition, it labels the containing country although this is at the expense of omitting the names of some of the states (Iowa and Nebraska) as in the case of the Android mapping app even though there is room for them.

Back to Top

Overlap Avoidance

A classical property is that labels of place names should not overlap (for example, Christensen¹⁰). It is enforced in all of the mapping apps with the exception of the iOS mapping app of OSM that permits labels to overlap and the iOS mapping app of Bing where watermark-style labels are permitted to overlap other labels with different fonts. For example, the label “Africa” in the map of Africa in the iOS mapping app of Bing in Figure 4a is a watermark and is overlapped by Cameroon, Gabon, and Congo in a standard font.

Note the iOS6, iOS7, and iOS8 mapping apps also make use of watermark-style labels for very large regions vis-a-vis the size of the display screen such as neighborhoods, cities, and countries (but, surprisingly, not states) apparently in order to provide contrast. However, they do not appear to permit watermark-style labels be overlapped by labels corresponding to names of objects of other types such as roads, neighborhoods, and cities, respectively, that are labeled using other font styles such as standard or boldface (not shown here). Interestingly, for example, continents are labeled using a watermark style in the iOS6 mapping app (not shown here) but not in the subsequently released iOS7 and iOS8 mapping apps where continents are labeled using a boldface font all caps with widely spaced letters (see Figures 3a and 3b). All but the iOS mapping app of Bing appear to restrict the orientation of the labels to be horizontal and parallel to the x coordinate axis. In particular, the iOS mapping app of Bing uses curved labels for Madagascar, Malawi, and Somalia (Figure 4a). It is also noteworthy in using different font point sizes for the labels (compare Algeria with Gabon) as well as abbreviations (C.A.R., for the Central African Republic).

Curiously, the iOS mapping app for Bing (Figure 4a) uses a watermark-style label for Africa yet it does not label the Democratic Republic of the Congo. This is so even though it could have done so easily in the same manner as done in the Windows Phone mapping app (see Figure 4b) and the iOS mapping app for Nokia (not shown here as it is identical to the Windows Phone mapping app in Figure 4b). On the other hand, these two mapping apps do not label C.A.R. as it would overlap Africa, which is not allowed as they use the same watermark-style font to label all objects instead of restricting it to continent names as in the iOS mapping app for Bing.

Interestingly, although Nokia’s HERE Maps is increasingly serving as the source for Bing Maps¹ and is now used in the Windows Phone mapping app, the quality and extent of the information displayed by the Windows Phone mapping app has declined vis-a-vis what was previously available on the iOS mapping app for Bing. For example, as we pointed out previously, although the iOS mapping mpp for Nokia makes use of a watermark-style label, it deploys it for all of the objects and this is what is done in the Windows Phone mapping app and the iOS mapping app for Nokia (see Figure 4b). Thus, they abandon the increased functionality afforded by the watermark-style font, which can be seen by the fact that fewer countries are labeled in the Windows Phone mapping app than in the iOS mapping app for Bing.

Back to Top

Label Distribution

Besides not being encouraged to overlap, labels should also be well distributed rather than being bunched up in one or a few regions of the map while the rest of the map contains just a few, if any, labels. The maps of Europe in Figure 1b and Figure 5 demonstrate some stark differences between the iOS6, iOS7, iOS8, iOS5, and Windows Phone mapping apps with respect to label distribution. We do not show the Android and Google mapping apps for iOS as they do not differ from the iOS5 mapping app for this example. For the original and early releases of the iOS6 mapping app, some of the issues we mention appear to be fixed in subsequent releases of its successor iOS6, iOS7, and iOS8 mapping apps and thus we differentiate between the variants of iOS6 using the qualifiers “old” (November 2012) and “new” (January 2015).

We immediately notice the two iOS6 (Figures 1b and 5a) and the iOS7 (Figure 5b) mapping apps do a poor job of label distribution. Moreover, countries that are labeled are not necessarily the most important or the most populated. For example, France and Italy are absent in the old iOS6 mapping app (Figure 1b); Italy and the United Kingdom are absent in the new iOS6 mapping app (Figure 5a); Syria is absent in the iOS7 mapping app (Figure 5b). In particular, it appears the countries near the center of the viewing window are given preference. The iOS8 mapping app (Figure 5c), while showing a much better label distribution than its predecessor iOS6 and iOS7 mapping apps, is still lacking where we see the absence of labels in Central Europe (Austria and/or Switzerland). Also, Serbia is absent while it can fit and it was present in the two variants of its predecessor iOS6 and iOS7 mapping apps.

---

We observed the algorithms used to implement the various mapping apps are frequently changed for a particular version of the operating system, even if the operating system is not updated.

---

The iOS5 mapping app (Figure 5d) does a better job of deciding that at this level of zoom in, the country entity is more relevant and the labeled countries are chosen on the basis of which ones provide the best distribution over the space spanned by the query window. This is better than the approach of the iOS6 and iOS7 (but not the iOS8) mapping apps of displaying names of countries without much thought paid to their spacing and also to their population, thereby leading to a cluttered appearance. A similar label distribution problem arises in the Windows Phone mapping app where only the cities Paris, Lyon, Marseilles, and Toulouse are displayed for France while many cities are displayed for Germany (Figure 5e).

Note the mixture of city and country names in the two iOS6 and the iOS7 (and to a lesser extent the iOS8) mapping apps without satisfying hierarchical consistency. In particular, when a city name appears, the name of the country is not always included such as Rome and not Italy in the two iOS6 mapping apps (Figures 1b and 5a), Prague and not the Czech Republic in the iOS7 mapping app (Figure 5b), and Zagreb and not Croatia in the iOS8 mapping app (Figure 5c). This also occurs in the Windows Phone mapping app where Belgrade is included but not Serbia (not shown here).

Back to Top

Concluding Remarks

We now review some of the presentation consistency issues for the various mapping apps we found noteworthy with an emphasis on the static consistency issues although we do include the dynamic consistency issues when speaking about the properties in a collective sense. However, we first re-emphasize our aim here is not to criticize Apple, Google, or Microsoft. Instead, it is to use examples motivated by Apple’s foray into the Maps space, where Google and Microsoft have a longer history due in part to their work on Microsoft Virtual Earth and Google Earth and Maps, to point out the difficulty of such a task and the need to take into account centuries-old lessons in map making.

Despite the obvious similarities among the Android and iOS5 mapping apps, we saw important differences including the way they differ for the landscape U.S. map where the iOS5 mapping app labels all states while the Android mapping app only labels those that fit without conflict thereby omitting labels for small states and thus not satisfying sibling consistency.

From our limited comparison summarized in the table, we conclude that newer is not always better in the sense the iOS5 mapping app is probably still the best especially with respect to the four presentation consistency (hierarchical, sibling, panning, and zoom) properties making for better map-based applications on smartphone form factor devices. The Android mapping app often has similar behavior although it was also plagued by zoom and sibling inconsistency that are also common to the iOS6, iOS7 iOS8, and Windows Phone mapping apps as well as others.

From an overall perspective, mapping apps from Google (iOS5 and Android) exhibit an understanding and appreciation of the small form factor of the smartphone target device, which is easily seen by the nice distribution of labels of place names over the display screen. This is in contrast to the iOS6 and iOS7 (and to a far lesser extent in iOS8) mapping apps where, at times, the placement (and distribution) algorithm for the labels of place names is relatively poor. This is partly due to their use of large point sizes with fixed-width fonts and much space between the letters, although these factors are less of an issue on tablet devices (for example, iPad) that have a much larger form factor. Some of the remaining apps, at times, ignore the small form factor of the target device and the choice of the size and number of labels to display is made under the assumption the form factor of the target device is large (for example, a display monitor or even a tablet such as the iPad), or decide to display very few, if any, labels. Note that displaying too many labels reduces the app’s utility to anchor additional spatially referenced information such as icons that is a critical requirement for mashups (for example, NewsStand^34,35,41) and is done so well on the mapping apps from Google (iOS5 and Android). Observe that use of watermark-style labels can mitigate the busy screen somewhat, but their use should not be all encompassing as in the Windows Phone app (Figure 5e).

It is important to note the main emphasis of this article has been to point out static consistency issues in well-known mapping apps. Ideally, any mapping app should satisfy all of the presentation consistency properties outlined in this article and tabulated in the table. In practice, however, an app developer may choose to partially satisfy or even completely ignore some of the properties due to factors such as space and computational time. In some cases, trade-offs must be made, and a possible future research direction is a study of how to make such a trade-off without compromising user experience. Such a study would require access to different labeling algorithms and involve usability testing to assess them.

Back to Top

Acknowledgments

This article is based on an earlier paper by Samet et al.³⁶ This work was supported in part by the National Science Foundation under Grants IIS-10-18475, IIS-12-19023, and IIS-13-20791.

Back to Top

Back to Top

Back to Top

Back to Top

Back to Top

Back to top