Sidwell’s flagship web product, Portico, was originally developed when Silverlight was ESRI’s preferred web platform, and it provided a stunningly rich, smooth graphical experience at the time. Along with the impending demise of browser plugins, Silverlight will not run on most mobile devices. So, my first assignment at Sidwell was to provide an answer for a users who were asking “Why can’t I use this on my phone?”
The first task was to decide whether we wanted a mobile app or a mobile website. This was a critical choice that went all the way up our command structure. Our key decision points included the following:
- Timeline: If we developed an installable app, we would have to develop for at least two platforms, stretching our workload. Xamarin was already big on the scene, but ESRI did not support Xamarin bindings for their API.
- Existing Skill Sets: I was the only developer, and I had no experience with Android or iOS. I could not leverage my .NET experience because Xamarin was not an option. But, I was an expert in front-end web technologies.
- Deployment: From a business and usability standpoint, we had to consider app store deployment. Would we need to deploy a separate app for each agency that used our product? Or, would the user open a single app, and then choose which agency he or she wanted to view? Neither of those choices was very appealing.
As you can probably guess, we chose to develop a mobile website. Incidentally, when I attended the 2014 ESRI International Developer Summit in Palm Springs, there was a session on exactly this topic. Their takeaway was that if you need the system capabilities of the device, then develop an app, otherwise develop a mobile website. That was comforting.
I also had to look at the audience, and their intended workflows, to decide which tools made sense on a mobile device.
- Search? Of course.
- Identify? Of course.
- Measure? Probably not.
- Print? Definitely not.
- Geolocate? Aha! A feature for mobile only, not on the desktop!
After I set the product’s design direction, the next phase was just a matter of implementing the selected features using standard tools and technologies. I’ll leave those details for other, more technical, blog posts. But, since I was able continue using all of the same backend services, I focus on the development on the front end.
Given this new product which I had developed and tested on the major platforms, I had to cover as many different devices as possible. This was a key challenge on this project. We had to cover major devices — Android 2, Android 4, iPhone 4, iPhone 5, iPad, Windows Phone, Kindle — and also the browsers on those devices — Android Stock, Samsung, Chrome, IE. One thing We discovered that at the time was that Samsung was using their own browser, with its own set of quirks. Since then, the situation has gotten even worse. Developing for the mobile browser market reminds me of the chaos that was the desktop browser market in 2001. And, since we have a limited budget, I spent a lot of time asking questions like “Who has an Samsung Android 4.2 with Chrome installed?”
After deploying the mobile website, we found that it wasn’t used as much as we envisioned. But, our analytics also showed us that mobile was used for more during weekends and evenings then during business hours. So, I imagine that the ability to access Portico on a mobile device is very important to mobile professionals, such as realtors. And, going forward, I think we’re going to find that tablet users differentiate themselves from phone users, requiring still different UX patterns.