Cloud Four Blog

Technical notes, War stories and anecdotes

Maps fiasco demonstrates the need to be able to change default applications on iOS

Good news today that Apple CEO Tim Cook has acknowledged the problems with the iOS 6 Maps application. Now everyone is anxiously waiting on Google to release a new native version of Google Maps so they can regain their lost functionality. But what many people are overlooking is that even if Google releases a native maps app, it won’t be able as useful as it once was.

One paragraph in Tim Cook’s open letter stood out to me:

While we’re improving Maps, you can try alternatives by downloading map apps from the App Store like Bing, MapQuest and Waze, or use Google or Nokia maps by going to their websites and creating an icon on your home screen to their web app.

He’s right that these are good alternatives. I’ve been using Mapquest for turn-by-turn directions on iOS for a couple of years now. It works really well.

But here’s the thing, even if you found a maps application that worked better for you in the short run, if you tap on an address in the contacts app, it won’t launch your preferred maps application. It will always launch Apple’s default Maps app.

The same is true for people who prefer to use Sparrow for email, Chrome for browsing, or a different calendar. There is no way to change the defaults for these activities.

And that’s the real shame. Based on features alone, someone might decide that they prefer a different Map application than the one Apple ships with iOS. The fact we can’t chose our default applications becomes even more frustrating when the default applications fail us like the new Maps application has done.

So Tim Cook is telling us that while we wait for them to improve Maps, we should try these other Map applications. My question to him would be, while we’re waiting, would you mind letting us select a different app as our default?

Our Content Management Systems are the Mainframes of the Mobile Era

I’ve recently had the great fortune to preview both Sara Wachter-Boettcher and Karen McGrane’s upcoming books on Content Strategy—Content Everywhere and Content Strategy for Mobile respectively. They’ve reminded me of something that got lost in the shuffle after I wrote my poorly titled article back in 2010.

When I wrote that CSS media queries give developers a false promise of a simple solution for designing for multiple screens, most people thought I was referring to the performance issues.

UNIVAC

But what I was referring to was an epiphany that I had had earlier that year. After finally convincing clients that building apps wasn’t sufficient because links don’t open apps, I had run into a bigger obstacle—their content management and ecommerce systems were poorly suited for mobile. I wrote in a comment on that original article.

The big problems aren’t CSS or reformatting for the screen. The big problems for mobile web are:

  • Content management systems designed before mobile that don’t separate out text from images and video which are necessary if you’re going to provide those assets in multiple sizes.
  • WYSIWYG editors for content authors that allow the creation of content that won’t republish anywhere.
  • HTML templates, javascript and css that assume desktop bandwidth, cpu, and caching behavior.

These are BIG problems. My conversations with clients over the last year has made me realize how big these problems are. Our existing web infrastructure is ill-suited for the mobile web.

Content Strategy for Mobile by Karen McGraneI was reminded of this last night when I read the following passage in Karen’s book:

The acrimony and the debates around mobile web vs. native apps, or responsive design vs. separate templates are missing the point. The challenge for most organizations in the long run won’t be figuring out a development approach for cross-platform code—because these techniques will evolve and standardize.

The challenge will be supporting a multi-channel editorial workflow, particularly if they want to prioritize content differently across platforms…

The root of the problem is in our internal processes, workflow and tools. To avoid the problem of content forking we need a new approach to publishing content to multiple devices.

Karen summarized the situation better than I’ve been able to. These legacy systems that are often duct taped together containing years of customizations. Often, the people maintaining the infrastructure weren’t around when the systems were put in place and don’t know why the systems do what they do.

Putting our CMSes in a closet

One approach we’ve implemented for a few clients is something based on what I remember happening in the early days of the web to mainframe and mini computers.

Many businesses has existing systems that contained crucial business process and customer data that would make the company’s website better. Unfortunately, these legacy systems were built before the web so they were poorly suited to run a web server and sit exposed on the Internet.

The company I worked for at the time decided it couldn’t afford to move everything off that legacy system. But what it could do is bring in a NetBSD box and then write proprietary connections on the backend between that NetBSD box and the legacy system.

We’ve used a similar strategy for clients for whom changing their infrastructure to support mobile would be too costly, too risky or too time-consuming.

Diagram showing how we use device detection to route someone away from the legacy system to a clean slate as a temporary workaround.

In the diagram above, the mobile web server is using device detection to select the correct template, but it could just as easily be a responsive web design. The key is that the legacy system is now being separated from the presentation layer.

When Daniel Jacobsen described NPR’s Create Once Publish Everywhere (COPE) system, he talked about how most content management systems conflate the task of content management with web publishing and how these things should be separate.

As an added bonus, we’ve found that organizations that already have plans to build mobile applications realize that they need to build APIs to support those efforts. It is much easier for organizations to devote a few developers to create an API than it is to refactor all of their existing web infrastructure. So often you can piggyback on the API development being done to support the organization’s app efforts.

What’s nice about an approach like the one in the diagram above is that it is on the path towards providing better separation of the content management system from presentation layer. Often organizations use the new mobile site as an opportunity to start fresh. The mobile site not only serves the short term goal of serving mobile users better, but it also becomes the site that will eventually replace the current desktop site.

What we’re doing is no different than what we did with those mainframe computers. We’re putting the CMS in a closet. It can continue to do what it does best until the organization is ready to replace it.

This is just one piece of the content picture

While we could identify the problem and point to some things that we were thinking about, we didn’t have the time to dig deep and figure out what it would take to tackle the CMS and content problem thoroughly.

That’s why I’m so happy to have read both Sara and Karen’s upcoming books—Content Everywhere and Content Strategy for Mobile. They do a much better job of showing you how to change the way you think about content and your content management system.

The books help you understand the high-level objectives and why these changes are important. But they go further into discussing how to implement the change in your organization.

I was also pleasantly surprised to find that the two books are complementary without an excess amount of overlap. I think Karen’s might be the one you would hand to a senior person in your company to convince them that there is an issue and Sara’s is the one you would distribute to team members for implementation. That said, both do a good job of balancing the theory and practical.

I realize it may be a bit of torture for me to talk so extensively and effusively about books that you can’t order yet. What can I say?

I know that there are a lot of organizations that are facing these challenges. These books say what I’ve been trying to say for two years and say it better than I ever could. I can’t wait to be able to reference them and share them with clients.

Bonus: Presentations from Lyza and I on content

While I never managed to blog about this topic until now, I did manage to talk about it at Breaking Development last year. The relevant section starts about 19 minutes into the video.

Breaking Development April 2011: Native is easier. Web is essential. from Breaking Development on Vimeo.

Lyza also gave a mind-blowing presentation at Mobilism this year on the nature of content. The video isn’t available yet, but the slides are below.

Mobile-First Responsive Design Virtual Seminar

When the kind folks at UIE asked if I was interested in conducting a virtual seminar with them, mobile first responsive design is the first topic that came to mind. It’s something everyone should be doing, but few are.

So let’s do something about that shall we?

If you’re already doing mobile first responsive design, awesome. Make sure you tell your colleagues why it matters and teach them so more responsive designs are built this way.

If you’re not doing it already, then I encourage you to join me for my Mobile First Responsive Design UIE virtual seminar next Thursday at 1:30 PM ET. The seminar lasts 90 minutes and costs $129.

I’ve put together a little slideshow with audio to give you a little preview of what the seminar will cover.

If the embedded slides don’t work for you (sometimes the audio takes a few seconds before the play button works) or you just want to see a larger version, try the original version hosted on SlideShare.

I hope you can join me next Thursday. Register today to save your place in the seminar!