Recently I was asked to share my implementation of the Google Maps SDK for iOS‘s Street View “Polylines,” via a post on the Google Geo Developers Blog. This was a thrilling opportunity to share some code and technique, and something I want to do more of.
The post covers overlaying items on top of a street view panorama and ensuring that they move accordingly while the user moves the panorama.
A fully working sample project is hosted on github.
Sun Surveyor is now available in 13 languages (English, German, Japanese, Spanish, Italian, French, Czech, Russian, Turkish, Norwegian, Afrikaans, Dutch and Danish), mostly due to an army of passionate user-volunteers. Localization goes beyond language translations, and I’d love to share what I’ve learned so far.
First Lesson: A Picture is Truly Worth 1000 Words
The more pictures, icons, or otherwise universal symbols a piece of software contains, the less words, and thus, the less translations will be needed. And with Sun Surveyor, I’ve written several help files which are included in the app, which contain a lot of text and almost no images. In addition, there’s more than a few UI Elements which contain text. So this can directly affect the UI/UX of the application since some languages are more verbose (German) than others (Japanese). So we can potentially have a problem of both imprecise translation of text and inconsistent UX.
If I were to do it all over again, I’d make sure to use more standard graphical elements and remove as much text from the UI as possible that made sense to do so. In fact this is a long term goal, to streamline the UI and make it less “texty.” Better documentation with screenshots versus textual descriptions will help, too. After all, that’s just a matter of taking multiple screenshots, with a few pointers for context, instead of translating reams of descriptive help text. The Android widgets for Sun Surveyor reflect this lesson, as I’ve used images to represent the various solar and lunar events within UI constraints that do not offer much room for varying size words.
Second Lesson: Localize Early and Often, and Pass the Turkey Test
Here’s where localization goes beyond language translation: different regions of the world like to look at dates, times and numbers differently, and indeed software applications may display text using different encoding. These 2 posts (here and here) describe what the Turkey Test is, but in essence, will an app look right to a Turkish user, whose date format is something like 09.2.2013 versus 02/09/2013 in America, and whose numbers are typically expressed in the form 50.000 (fifty thousand) versus 50,000 in America? Less esoteric to those of us in the US is a comparison of European or Canadian date formatting which puts the day before the month.
Thankfully, the Android and iOS SDKs (and the underlying platforms they’re built on) offer and recommend constructs to handle these issues. Using Date and Number formatters by specifier (short, long, etc), and configuring them (decimal length limits, rounding rules, showing grouping, precision), rather than hardcoding a format string, makes for pain-free number and date display. Placing strings in the appropriate locale-specific resource bundles and accessing them that way, versus magic strings or “constant” files also, similarly makes for painless, abstracted text localization. Sun Surveyor does actually have a Turkish translation, and Google and Apple have made it quite easy to make it pass the Turkish Test.
Taking the “extra” (it’s not much!) effort to set this up on day one, even without immediate localization plans, offers more benefits such as properly abstracting text resources and formatting logic such that they are properly separated from the rest of the application logic. Writing some simple utility classes to handle tricky formatting specific to the application allows that code to reside in one place, for reuse throughout. For custom formatting beyond the SDK or language-supplied “short” and “long” abstracted format types, one might get a handle on the current locale, and build formats that way.
Android also has a system setting to toggle 24 hour date/time formatting, so making sure to respect that helps users respect the app!
// iOS: configuring a number formatter
_shortDecimalFormat = [[NSNumberFormatter alloc] init];
// Android - get some information about the date format from the context
char dateFormatOrder = DateFormat.getDateFormatOrder(context);
boolean is24HourFormat = DateFormat.is24HourFormat(context);
Beyond mobile: character encoding can be a large discussion on its own, but suffice to say, learning which encoding the platforms are using (in this case, UTF-8), and ensuring that translated assets are using the same encoding is key (ie: not Western Latin, not MacRoman, etc…). I’ve worked in the past on web applications and database applications which have had trouble with “special characters” (in some cases this was considered to be an apostrophe: ‘). This experience shows that the application simply just needs to work, regardless of what characters are in the text; there is no excuse to not get this right as appropriate utilities and facilities exist to properly encode any and all text correctly, it’s a problem that’s been solved over and over again at this point.
Third Lesson: Google Translator Toolkit is Your Friend
When the first few people approached me about doing translations for Sun Surveyor, I was not sure how to handle the translation process. I wound up sending .xml and .html files, which were edited and sent back. I may have done some further editing and cleanup, and in the process learned that various text editing applications and IDEs may convert text encoding, or otherwise not properly handle different encodings. Working through these things was a largely manual and time consuming process beyond the translation itself, and those folks deserve medals for their efforts.
Thankfully before the next set of translations, I discovered Google Translator Toolkit, which as of March 2012 began supporting Android string.xml files. It also currently supports iOS Localizable.strings files. This is amazingly useful by allowing one to upload files to be translated, with a UI that has the original text on the left, and editable translated text on the right, with the ability to comment, share, and more.
Supporting Android and iOS simultaneously: since most of the text of Sun Surveyor is the same on both platform versions, I’ve written some simple python scripts (shared here) to clean up the Android strings.xml file and convert it to the iOS Localizable.strings format. The help text (.html) is good to go with some minor edits.
Fourth Lesson: Localization is Empathy; Horizontal Expansion
The majority of Sun Surveyor adoption is in English-speaking countries, but there are many slivers of adoption across countries where English is not the native language. Presumably where there was no localization for these places, some knowledge of English was likely required to figure out this application; it would be nice to presume that it’s intuitive enough otherwise, but I doubt it. Proper localization (internationalization) of date and number formatting solves one issue (the Turkey Test), and translation of text and graphic assets solves another (language barrier). All creating an experience that is local and specific, and more importantly: comfortable, familiar. We, and our applications through us, express empathy for our user community when we take care to properly localize and translate our applications.
Finally, from a business perspective we can think of localization as horizontal expansion. Localization opens our application up to a whole new market of users who may not otherwise read or speak the default application language. This can only be a good thing, and lead to more adoption or sales, but the main added value here is in being customer-focused and having empathy for our users via providing a more optimal experience.
This image of a slide, in Russian, showing Sun Surveyor to a group of cityscape photographers was sent to me by Sergey Louks, who along with Nikita Sidorov performed the Russian translation. It thrilled me to know that something that didn’t exist less than 2 years ago can now be presented to an audience with whom I might not be able to communicate with otherwise.
In the wild journey this application’s taken me on, I’ve interacted with many other warm-hearted individuals who have helped with the translations. I hope to meet them all in person some day soon. Through the translation process, I’ve learned little bit about each language, and there’s really a huge richness of history and tradition behind them, alongside curious aspects. For example, beyond the use of Chinese characters in Japanese, Norwegian (Sun Surveyor is in Norsk Bokmål) has an intriguing story currently playing out that’s been fun to explore.
Just wanted to post a quick update, things have been quite hectic this year so far, so unfortunately I didn’t get around to writing a “part 2” to the previous post.
The most recent version of Sun Surveyor (1.4.9) features native Italian, Spanish, and German translations. Thanks to Samuele Tovagli, Marco Götze, and Francisco Javier Fonseca Padilla and Juan Pablo Fonseca Padilla!
I am pleased to say that version 1.0 for iOS is almost complete and ready for submission to the App Store, after some final touches and beta testing. The development target is as follows:
iPhone 4, iPhone 4s (iPad version to follow)
English (Italian, Spanish, German translations to follow)
As soon as it has gone through the review process and is in the App Store I will post an announcement.
Most of the functionality from the Android version will be present, the major difference being that some of the advanced Map functionality from Android will not be present in 1.0. This is due to the very different SDK APIs, and slightly different implementations of the Maps on iOS versus Android. This functionality will follow in a future update.
Working on a port to iOS has been very interesting; I’ve learned a lot from the experience so far and hope to write about it at some point in the future.
This time last year, I started developing Sun Surveyor initially as an academic exercise of building and deploying a native mobile application from start to finish on 2 different platforms. The idea of it being something people other than myself could use or purchase was a secondary goal. To that end, the Android iteration has had modest success, beyond my own expectations for it. Ideally, the iOS iteration will be finished within the next few months. I’m sometimes asked what was involved in building a mobile app, and in particular the unique challenges of this one. So here’s some thoughts and reflections on what I’ve experienced over the past year.
Building an Application
Here’s a list of technical topics I had to brush up on, or get a basic understanding of, that were essential to the development of Sun Surveyor:
Basic Trigonometry (SOHCAHTOA!) and Circular Geometry
Astronomical Algorithms – Sun and Moon calculations and information
2D Graphics Programming basics – for the 3D compass, z-order stacking
3D Rotations – for representing the user’s position in the world versus other object positions
Quaternions vs. Euler Angles, gimbal lock – for spherical augmented reality
Game Development basics – efficiently calculating and rendering graphics
Time Zones and their complexity – they are geopolitical, and dynamic!
Accelerometer and Magnetometer basics – understanding the sensor fusion that allows deriving the device orientation in the world
Compasses and Magnetic Declination – the difference between Magnetic North, True North, and how it varies throughout the world
Optimizing for Mobile – very limited heap space, varying device builds and capabilities, strong need for efficient algorithms and data structures, asynchronicity, respecting the main/ui thread
GUI basics, GUI design patterns and UI/UX interaction patterns
Maps, Geocoding, Coordinate systems
If I knew that all of these things were to be involved on day one (on top of learning the Android SDK), it would have seemed an intimidating start. Thankfully, my ignorance allowed me to dive in and constantly add to the growing list of topics of which I needed to increase my knowledge, and slowly the app came together. Something I realized is that one doesn’t have to become an expert in every topic to make use of its basic concepts! And to that point, I think that the concept of abstraction and working with abstraction, which is so important to us in the software engineering world, really comes into play here. Many components and problems for this app could be modeled in the abstract sense with the implementations evolving until they were working and efficient. This is the one part about engineering that I think many non-“techy” folks may find intimidating, overwhelming or “magical,” when it’s all just possible due to careful abstract design, thought and structure.
In the months since the initial release, many of the components and modules of the application have been rewritten, refactored and improved as time allowed; resources such as Refactoring, Effective Java (2nd Edition), and the classic GOF Design Patterns were helpful influences.
Another great resource was the The Business of iPhone and iPad App Development book, which really helped put into perspective the mobile app marketplace and how applications I develop would need to find their way within it, even if it was focused mainly on the iPhone/iPad and iTunes. I saw this at a Cocoaheads meeting and it was incredibly helpful to buy and read right before launching the app.
Some of the non-technical topics that I quickly became aware of:
User Base – other than myself, who potentially uses this application? The answer was broader than I imagined!
Customer Service – understanding the expectations of customers, handling complaints, issuing refunds, and resolving and prioritizing bugs and feature requests
Competition – what other apps are out there? How does this one stack up? What is unique about it?
Pricing – understanding the value people expect out of something priced at a certain price point, versus how much value they expect from a free version or a competitor’s
Mobile App Business Models (“Freemium”, ad-based, etc)
Analytics – what the most used features are, how many are upgrading from the “Lite” version, how many people make use of a new feature when it’s added, etc
The business side was an interesting and unexpected one, and I’ll cover that in Part 2.
Some of the modest successes and highlights over the past year:
All of the interaction from the wonderful folks who use the app – solar panel installers, real estate agents, gardeners, architects, grips and film crews, cinematographers and photographers!
Seeing the app mentioned by Romain Guy (Android framework wizard) in several posts (here and here)
Also in the past year, I started making an effort to discover and meet more people within the Pittsburgh developer community. I started by attending a Geek Night, then the iPhone/iPad and Mobile App Developers Pittsburgh Meetup (great, though seemingly now dormant), and eventually discovered the wonderful Pittsburgh Cocoaheads Chapter. Run by co-founder Mark Dalrymple (author and developer extraordinaire) and augmented with additional presentations from Sean McCune, Nick Waynik and others, Cocoaheads has been a great monthly experience and opportunity to meet and interact with other passionate Pittsburgh developers and enthusiasts.
I also attended a really fun and free event called the Global Day of Code Retreat, which happened worldwide, with the Pittsburgh event having over 50 attendees. This involved pairing up with different partners in 6 sessions to practice test-driven development on Conway’s game of life, with the code being deleted at the end of each session. Definitely an interesting and intense way to practice and hone some coding, design and testing skills.
To Be Continued…
In Part 2, I’ll share some thoughts on sales, the “freemium” business model, the Live Wallpapers I’ve developed and Android marketplace and device fragmentation.
Recently I released version 1.4.1 of Sun Surveyor. This followed on a major effort in release 1.4 to include Time Zone detection and many usability enhancements. 1.4.1 adds left/right buttons next to the time slider. These allow for fine adjustments relative to the selected slider mode, and more than ever helps better realize the unique vision for a 3D Compass visualization of Sun and Moon data, with the interactivity that I wanted when that portion of the app was conceived.
Flurry analytics was also implemented recently, and it’s been a great tool to show which features are the most used (Compass, Augmented Reality Camera, Map, Details in that order, and of course Help being the least used, accessed 6 times per 100 sessions!). Today, I added AdMob ads to the Lite version, and it will be interesting to see if that brings in any revenue from the many Lite users. The ads are located on the Main Menu dashboard and do not appear in any of the functional modules.
It’s been approximately 6 months since Sun Surveyor was first released, and it’s been an incredibly fulfilling time. It’s brought me great pleasure to interact with Sun Surveyor users, to receive helpful and critical feedback and implement suggestions to improve the product. The most important lesson I’ve learned in this time is to stick to a vision for what the product is, and what the product is not. To stick to what it does best, and leave certain functionality and features instead to those other applications which do them best.
The Android platform has been great to develop on, and it was possible to create this application in a much shorter period of time than I initially thought, using nights and weekends. It’s been a lot of hard work, and involved re-learning a lot of math and trigonometry, and learning graphics programming concepts, optimizations for mobile and mobile JVMs specifically, mobile UI concepts and interaction patterns. There’s still a lot of hard work ahead, especially in creating the iOS version natively, but I feel Sun Surveyor is now in a good place, as a software product.
So here’s the roadmap for Sun Surveyor from this point on:
– Graphical / UI Updates to make it a more finished product in appearance
– iOS version development work
– OpenGL implementation for the Augmented Reality Camera
– OpenGL and more graphical implementation of the 3D Compass (possible)
– Altitude lookups and calculations w/r/t Sun/Moon altitude (possible)
On the side, another creative outlet has been in creating some fun Live Wallpapers for Android, with fellow ACiD Produtions alumnus and artist Cat Spencer which are a vehicle to learn some more graphics programming concepts, and some OpenGL ES which will be useful for potential re-writing portions of Sun Surveyor to use OpenGL. These can be seen here: All my Android Apps.