With Unicode adding more and more useless emoji, and seemly doing little else, it’s time to ask an important question: what the fuck is the Unicode Consortium supposed to be doing anyway?
It’s time to dust off Howard Oakley’s excellent blog post Why we can’t keep stringing along with Unicode, and think about the Normalization problem for file names and the Glyph Variation problem of CJK font sets. These problems fit together surprisingly well. My take is the problems must be tackled together as one thing to find a solution. Let’s take a look at the essential points that Oakley makes:
Unicode is one of the foundations of digital culture. Without it, the loss of world languages would have accelerated greatly, and humankind would have become the poorer. But if the effect of Unicode is to turn a tower of Babel into a confusion of encodings, it has surely failed to provide a sound encoding system for language.
Neither is normalisation an answer. To perform normalisation sufficient to ensure that users are extremely unlikely to confuse any characters with different codes, a great many string operations would need to go through an even more laborious normalisation process than is performed patchily at present.
Pretending that the problem isn’t significant, or will just quietly go away, is also not an answer, unless you work in a purely English linguistic environment. With increasing use of Unicode around the world, and increasing global use of electronic devices like computers, these problems can only grow in scale…
Having grown the Unicode standard from just over seven thousand characters in twenty-four scripts, in Unicode 1.0.0 of 1991, to more than an eighth of a million characters in 135 scripts now (Unicode 9.0), it is time for the Unicode Consortium to map indistiguishable characters to the same encodings, so that each visually distinguishable character is represented by one, and only one, encoding.
The Normalization Problem and the Gylph Variation Problem As Oakley explains earlier in the post: the problem for file system naming boils down to the fact that Unicode represents many visually-identical characters using different encodings. Older file systems like HFS+ used Normalization to resolve the problem, but it is incomplete and inefficient. Modern file systems like APFS avoid Normalization to improve performance.
Glyph variations are the other side of the coin. Instead of identical looking characters using different encodings, we have different looking characters that are variations of the same ‘glyph’. They have the same encoding but they have to be distinguished as variation 1, 2, 3, etc. of the parent glyph. Because this is CJK problem, western software developers traditionally see it as a separate problem for the OpenType partners to solve and not worth considering.
Put another way there needs to be an unambiguous 1-to-1 mapping and an unambiguous 1-1/1-2/1-3-to-1 mapping. I say the problems are two sides of the same coin and must be solved together. Unicode has done a good job of mapping things but it is way past time for Unicode to evolve beyond that and tackle bigger things: lose the western centric problem solving worldview (i.e. let’s fix western encoding issues first and deal with CJK issues later), and start solving problems from a truly globally viewpoint.
I finally had time to catch Adobe Nat McCully’s ATypl Tokyo 2019 presentation. He covers the topic that I have covered in depth many times before: the (sad) state of CJK typography. As Nat points out most software developers and system engineers talk about CJK support as typography without any idea of what it means. Throwing CJK glyphs on a screen is not typography, they are not the same thing at all.
The defining feature of CJK typography and layout in general and Japanese typography in particular is that space is an essential composition element equal with text and graphics, with fine space element control way beyond a baseline. Instead of thinking about how much space should be between text, flip it around and think about how much text should be between the space. Baseline font metrics will never deliver great CJK typography because there are too many limitations. So everybody implements the missing stuff on the fly and everybody does it different. Unfortunately the irony of it all is that Adobe played a huge role in how these limitations played out in the evolution of digital fonts, desktop publishing (DTP) and the situation we have today.
QuickDraw GX was probably the only time in computer history that fonts, layout engine and the basic OS came together to solve these limitations for all language systems, all language typography as equal from the bottom up. Parts of that effort survived, such as Apple’s San Francisco variable system font based on the TrueType GX model, and the inclusion of the TrueType GX model as the base technology for OpenType Variable fonts. Nice as this is, it’s only a tiny sliver of the GX vision pie that survived, all the other baseline font metric and CJK typography limitations still exist. Outside of a handful of people like Nat at Adobe, and the Adobe CJK typography ghetto approach of keeping all the good stuff corralled in InDesign J, very little is being done to address them.
Call me a pessimist but after 20 years of watching things slide sideways, I don’t see much hope for the future evolution of great CJK typography on digital devices. Most western software development people think that having CKJ glyphs on a screen is ‘good enough’ CJK typography, end of story.
Already I see the OpenType Variable Font effort devolving into a bauble for web developer geeks, always stuck in demo-hell, never going mainstream. It is the same story for quality CJK typography on digital devices. When the current Adobe CJK leaders like McCully and Ken Lunde reach retirement age, whom have devoted their careers to fixing these problems, I think it will be the end of an era. In many ways we are already there.
That’s great for building owners to indoor map their own building. What about shared public places like Shinjuku Station which is spread out and shared by 8 different owners? There is also the localization problem. It’s one thing to indoor map for Japanese users, but who’s going to localize all those Point of Interest (POI) icons and information sheets in English, Chinese, Spanish, etc. That costs serious time and money.
Let’s take a comparison look at indoor maps of the primary entrance gate for inbound visitors coming to the Tokyo Olympics next year: Tokyo Station, and compare Yahoo Japan Maps, Apple Maps and Google Maps.
Yahoo Japan Maps Yahoo Japan Maps only offers Japanese language but it has best cartography and attention to small details that matter, like yellow station exit signage colors that exactly match what you find on the ground. Apple and Google don’t.
Apple Maps Japan Apple Maps does not offer indoor station mapping in Japan. It does offer multilingual support but judging from the English Point of Interest information, it’s not robust. As usual Apple Maps Japan overwhelms users with Point of Interest icons. It’s map death by Point of Interest. There’s a lot of fixing Apple needs to do if they want to present a good map product in time for the Olympics.
Google Maps Japan Google Maps offers indoor mapping for Tokyo Station in multiple languages. For all the detail Google offers here, it’s much less helpful than Yahoo Japan Maps. For high density areas like Tokyo, good cartography and smart editing makes all the difference between a good map and lousy one.
There were very few Apple Maps rumors for WWDC this year, only one little paragraph from Mark Gurman <with comments>:
An updated Maps app will make it easier to set frequent locations, like home or work addresses, and then navigate there. Users will also be able to create groups of frequent places and add a photo to them. The current interface for navigating to suggested or past destinations can sometimes be confusing. <duh> This will increase competition with Google Maps and Waze apps <really? are you serious?>
Collection Eddy Cue outlined Apple Maps 2.0 as a dual approach of using anonymous iOS device data and Apple Maps vans to collect high quality map data while getting faster updates from devices vs. the next scheduled drive:
“The truth is that Maps needs to be [updated more], and even are today,” says Cue. “We’ll be doing this even more with our new maps, [with] the ability to change the map in real time and often… In the new map infrastructure, we can change that relatively quickly. If a new road opens up, immediately we can see that and make that change very, very quickly around it…”
In short: Traffic, real-time road conditions, road systems, new construction and changes in pedestrian walkways are about to get a lot better in Apple Maps.
TechCrunch Apple is rebuilding Maps from the ground up June 29, 2018
High quality in-house map data collection is a vital step, but there are limitations. The Google Maps Japan meltdown proved that even Google can’t do it all. When Google dropped premier Japanese map data supplier Zenrin, Google Maps Japan quality instantly crashed. Japan has very high density urban areas and very remote rural areas that cannot be effectively mapped from a van no matter how much fancy recording equipment it has. Zenrin has a 1,000 person ‘ground truth’ team just for mapping and updating those kind of places, inside and out, on site and on foot.
Processing Panzarino explained at length how the high-resolution image data collection effort fits with Apple’s in-house data qualification toolkit to identify problem areas with machine learning, so that the human team can quickly vet problems and update corrected map data for the trouble area:
The coupling of high-resolution image data from car and satellite, plus a 3D point cloud, results in Apple now being able to produce full orthogonal reconstructions of city streets with textures in place. This is massively higher-resolution and easier to see, visually…This is hugely important when it comes to the next step in Apple’s battle for supremely accurate and useful Maps: human editors.
Apple has had a team of tool builders working specifically on a toolkit that can be used by human editors to vet and parse data, street by street.
Many hundreds of editors will be using these tools, in addition to the thousands of employees Apple already has working on maps, but the tools had to be built first, now that Apple is no longer relying on third parties to vet and correct issues.
And the team also had to build computer vision and machine learning tools that allow it (Apple) to determine whether there are issues to be found at all.
There we have it: Apple is using in-house machine learning and no longer relies on 3rd party vetting or correction. How is this working out? Answer: not so great. At least in Japan. Let’s take a quick look around the Ikegami Honmonji Temple area.
Example #1: Ikegami Hall is completely missing in the map view even though it is in the satellite view.
Example #2: Duplicate Five-story Pagoda pin locations. The Manji character marked pagoda is correct while the grey one from Foursquare is the wrong location and duplicate information that needs to be removed or merged. <Kudos to Apple here for respecting local culture and using the traditional Buddhist temple Manji character, while Google Maps does not>
The conclusion here is that Apple Maps 2.0 isn’t living up to Eddy Cue’s stated goals, at least in Japan:
In example #1 machine learning is supposed to identify problem areas when the satellite and map views don’t match up, but fails. The human team is not alerted to the problem and cannot fix it.
In example #2 the system cannot distinguish between incorrect 3rd party supplied duplicate data and the real thing. In my experience Foursquare Japan and Yelp Japan have no human location vetting, most of their product is worthless. Apple faces a choice: is it better to show nothing, or is it better to show unvetted 3rd party data that has a high risk of being incorrect leading users to the wrong place? My suggestion: don’t use any 3rd party data that has not been vetted by Apple Maps van collected in-house map data.
Presentation Cartography and the Maps UI is where it all comes together.
Apple has a team of cartographers on staff that work on more cultural, regional and artistic levels to ensure that its Maps are readable, recognizable and useful.
For instance, in the U.S., it is very common to have maps that have a relatively low level of detail even at a medium zoom. In Japan, however, the maps are absolutely packed with details at the same zoom, because that increased information density is what is expected by users.
Panzarino got it wrong here. Users in Japan don’t want a map view packed with details. The difference is not cultural, it’s simply that high density metropolitan areas like Tokyo have much more information packed into a given area than American cities. Presenting high density information in clean easy to read cartography is challenging.
Yahoo Japan Maps and Google Maps have both evolved their cartography away from detail packed, point of interest cluttered views to cleaner cartography. Yahoo Japan Maps cartography is the best because they deploy good design with smartly edited zoom level assignment: this information is important at default zoom level, this other information belongs at zoom-in level 2, etc. This clean approach shows only the important details for the given zoom level for quick navigation. The differences in readability comparing Tokyo area views of Yahoo Japan Maps, Apple Maps and Google Maps are immediately noticeable. Here is Gotanda Station:
Apple Maps 2.0 fails here too. The cartography is less readable, recognizable and useful than the competition. The easiest fix would be for the Apple Maps cartography team to stop stuffing so many Point of Interest (POI) icons at the same zoom level and intelligently rank information to display at different zoom levels.
Unfortunately, that effort requires a group of humans with expert local area knowledge. An Apple Maps engineer explained the dilemma to me once, “Yahoo Japan Maps has the luxury of focusing all of their product development on just the Japan market.” It’s a luxury that neither Apple nor Google have.
WWDC19 Wish List
Here is my wish list for Apple Maps Japan 2.0 using the same categories, including transit which is a separate app and service layer within Maps.
Traffic and Real Time Road Conditions: these important features are missing in Japan and absolutely must be added. Car navigation with Apple Maps in Japan is worthless without them.
Offline turn by turn navigation: Apple Maps turn by turn navigation completely dies in underground roads or in rural areas without a network connection. It’s like flying blind. Dedicated Japanese turn by turn navigation systems handle this without a problem. Apple Maps 2.0 needs to match the same level of performance to be a reliable car navigation service.
Fix stuff: Improve machine learning to identify problem areas for humans to fix, or hire humans who can identify and fix problems in Japan maps.
Vet Stuff or Don’t Use It: If Apple Maps cannot internally vet 3rd party social networked geo trash from notoriously unreliable Yelp, Foursquare and TripAdvisor, don’t use it.
Presentation(Cartography and Maps UI) This is where most of the action is covering how the map looks and how users interact with it.
Apple Maps Cartography 2.0 Google Maps and Yahoo Japan Maps constantly tweak and evolve their map design, changing contrast, colors, text sizes, and more while pushing map information updates. Meanwhile Apple Maps cartography is fossilized in 2012 debut era design garb. I can only assume 2 things. Either Apple thinks so highly of the current Apple Maps cartography design language that it will never change it. Or Apple is creating a whole new cartography design. Let’s hope for the latter.
Fix the Point of Interest overload: with smarter zoom level editing
Eliminate Separate Map View/Transit View Modes Toggling back and forth between 2 basic view modes in Apple Maps is passé. It desperately needs a revamp. Yahoo Japan Maps leads the way here by collapsing separate road map and transit maps into a single comprehensive map view that covers 99% of what users need, while offering a real rail map for the 1% who need a real rail map. It’s a time saver and smart way to eliminate toggling map views. More on this in the transit section.
Recents2.0 The current version of Recents is an old shoebox filled with crap: tapped places, liked places, Siri searches, suggestions, liked train stations to receive train delay notices, home, work, and stuff I have no idea why it’s even there. There are so many improvement suggestions I don’t know where to start. I’ll keep it simple and say, Apple please figure out what Recents is supposed to do, so that we don’t have to.
Nearby2.0: Nearby suffers the same problems as basic processing, Apple Maps 2.0 needs to do a better job of filtering out the junk. Anybody can list 10 nearby cafes, but only smart editors can give me 10 that are worth visiting. Also follow Yahoo Japan Maps nearby approach of keeping everything on one screen, with minimal pinch and zoom. Avoid Google Maps approach of turning Nearby into stealth advertising.
Live Weather Layer: this is Yahoo Japan Maps insanely great secret weapon. I always use it to find when its raining and where, with a time slider to predict if I need an umbrella at my destination. It’s a life saver and must have Apple Maps 2.0 feature. Once you use it, you can never use another map that doesn’t have it.
Nearby Transit Time Widget Google and Apple both use the same transit data supplier, but Google Maps uses it much better than Apple Maps. Most people already know where they are going and how to get there. What they really want to know is: when is the next train? Google Maps does this via a handy widget that offers location based nearby station train times and bus times without having to open the map or tap on a station. This is incredibly simple and convenient. Apple Maps 2.0 needs to offer it.
Siri Transit Support Siri does not support transit requests. Siri can navigate you to the nearest station but after that you are on your own. The ability to ask Siri for transit times is an important Apple Maps 2.0 feature.
Transit Route Search 2.0 This is another area where Apple Maps has stood still while Yahoo Japan Maps and Google Maps continually push out improvements: route suggestion sorting by fare, transit time and number of transfers, train car position information for faster transfers and exits. Apple Maps 2.0 Transit needs to catch up with the competition.
Location Based Transit Alarms on iPhone Apple Maps transit has wonderful integration with Apple Watch but it could be improved with destination and transfer point alarms/alerts that also work on iPhone.
Improved Apple Pay Transit Card Integration Apple Maps has some basic integration with Apple Pay Suica but it could be improved by incorporating user Suica Commute Plan information for better route searches with more accurate fare information. Apple Maps integration with HOP and Ventra cards in Apple Pay Wallet would be a great feature for those transit regions.
Adaptive Transit Times The problem with transit route suggestions on Apple Maps, Google Maps and Yahoo Japan Maps is that once the user selects a route suggestion, transit times are locked in and cannot change on the fly. All too often a users selects a route and time but catches an early or later train, and has to input a new search to reset the transit time. But this is often impossible to do on the fly as transit route searches add a ‘time to station’ buffer. Transit times that adapt and automatically update to transit conditions would be a great feature to have in Apple Maps 2.0 transit.
I have noticed recently that Google Maps in Japan has stopped using the traditional Manji 卍 character for marking Buddhist temples and has substituted a plain gray drop pin. All the other religious organizations still get special icons to denote the religious group: Shinto, Christian, Islam and Judaism. Why do Buddhism get the short stick?
Apple Maps and Yahoo Japan Maps both respect local culture and display Buddhist temples the traditional way. Why can’t you? If you study history and culture you will understand that the Manji character has been used in connection with Buddhism throughout Asia for hundreds of years. It has nothing to do with European history or the tragic events of WW II.
As a Buddhist I hope that non-Buddhists strive to respect Buddhist culture as Buddhists strive to respect other cultures and religions. It’s easy to understand why some Westerners might misunderstand this aspect of Japanese culture, but misunderstanding is always an opportunity to learn new things and grow. When you whitewash one religious symbol because somebody who doesn’t come from that culture doesn’t like it or doesn’t understand it, you are promoting cultural discrimination.
I’m sure Google Maps does not want to promote cultural discrimination. Please do the right thing and respect all religions equally.
Love and Kisses, Ata Distance
UPDATE Some readers have suggested this a result of the some preliminary map symbol proposals from the Geospatial Information Authority of Japan, however the Manji symbol was retained in a later proposal with the word ‘temple’ included. What’s important to remember is that the map symbol suggestions were merely suggestions intended for non-Japanese language maps at tourist areas and such. It’s also important to note that the Japanese government did not consult with Buddhist organizations. In short what Google has done does not follow Japanese government guideline suggestions or respect local culture. It is censorship.