From iOS App to the Web Site

During the development of an iOS application and researching about (mobile) web and talking to some app-developers there are a few things that I have learned. First of all, the realization that the Internet has changed. It’s no longer a digital business card, a social experience, or a web site to get people to sign up for a service. We are partially beyond that. A bit of rethinking is required to adapt to get what you need from others by offering them not what you have, but by giving them what they need.

Scale up. Start with the mobile interface, scale up to the web interface. Because it’s useless to build a whole web interface, and then offer an iOS solution for them. You have all that, what they wanted in the first place was your product. Assume they might have it. Offer them the web interface as the alternative. Have that mobile experience running. I mean, do not design a full fledged site and scale it down to a mobile interface, and as alternative a stand alone app. Scale up, by designing the app, the mobile web, and the web interface.

Delude business in the interface. Focus on the content for the end-user. The visitor to your site not there to read about your quarterly earnings, your press releases and your data graphs. They’re there for answers and content. Focus on this, don’t bore them or put them off. Provoke their focus by putting attention on the content. The faster you provide them with the content, the longer they stick around. Lowering the time to get their focus results in faster page load times, a more positive experience, and users sticking around longer on a page.

Don’t give the end-user what you have. Give them what they need. They might already know what you have, you know what you have. But they are there for what they need. This content, is what is foremost important to present. Provoke discovery by creating the urge and desire to browse around to see what else you have; After they found what they need. Someone selling you 15 breads at the bakery is annoying, you came there for the croissant, if the croissant is excellent, easy to find, you will buy or come back to discover what else you have. Sure, statistics might show that force feeding your customers will increase short term sales. But aren’t you looking for long term customers?

Optimize the mobile experience. Waiting = death. Zero tolerance. So make it work, draw their focus, and deliver the important content as fast as you can provide it. Overloading the interface with graphics, additional data, advertisements and what not will provoke frustration, and not their interest. This has no excuse. Let the competition have that shitty experience, you aim for user-experience. This has no balance to shift. Optimize the app, the mobile experience. They’re on edge, 3g, lte, at at most on wifi on their mobile devices. Leave the extra bloat for the web interface, consider it an ‘extra’ you can provide. The stable uncapped broadband is most likely at home or the office.

If you are there for your users, be there for them. Process their feedback and make sure you have their feedback. Let them know they can communicate with you. Be it informally over social networks, or formally over crowd-sourced FAQ / Support system on the site. Or professionally through private support tickets. A knowledge base and a support community is important. This creates search results that matter, gives an impression of the people behind a product. And it gets those with experiences involved to help those in need for answers. If there’s a dead web sites without the options to interact, a quiet twitter account or the false promise of 24h response times, your competitors will enjoy your income as you’re losing customers.

iOS app is 1. mobile interface is 2. Web interface is 3. Cross device support. If your goal is to put a pin in the iOS market, focus on the iPhone application. Additionally on the iPad screen, but at least make it work. To support other devices such as Android then make a mobile interface to match the app. And a web interface for the no-mobile-device experience. Make sure there’s cross browser and cross devices support. But I believe you should do this in steps. Overloading yourself with supporting everything is not going to help you. If you think it’s a mistake, take a look at instagram for iOS. No iPad version, no web interface, no Android app. And boy, are they successful. And yeah, in a year from now they will have Android.

Modern devices can support client-side rendering. Offload where realistically possible. As their CPU/GPU increases, so does the performance. Browsers, apps, and what not can client-side render content. Offload the experience with caching, libraries and stored routines. Why not?

Offload stress with end-user distraction. Background pre-caching and processing is a plus. When you do run into that moment when processing is going to take a few seconds. Distract the user. You can do this in the background, while other screen elements such as an input field for a picture comment, etc, could take up their time. They do not notice the processing. What they do notice is when they press the [Done] button that everything’s loaded, uploaded, and already live. Boy this app is fast!

Provoke discovery, don’t hide options Hide screen-area when not needed. End-user explores. With this I mean that if you have different screen panes you could have a button for each one. I tend to suggest that swiping between panes using an indicator that it’s possible, is the right solution. You have a cleaner interface, no clutter by buttons. And a fun interface for users to explore. You’re involving them in the app by provoking them to swipe around to discover more content relevant to them (rather than knowing there’s a button but when do you actually go click on them?). If you have 3 preferences but the user might switch between them, hide them under a ‘hold and wait’ popup button. A prime example of this is the iOS tweetbot app. You can set a button to direct messages. Clicking it will load the DM screen pane. However, holding it, lets you switch to another preference, such as a twitter list. Inline replacing the preference to that list option instead. No clutter, all the options at your fingertips, and it’s fun exploring what the program can do. Plus, you can personalize it without having to go through 15 settings in ‘system preferences’.

Mobile? Support alert via Push. Logical interface choices over program control, wins. If you are using an iOS app, and there’s interaction, time sensitive content, or user-feedback, etc. Why not offer the option for push notifications? Rather than having the user go to the full fledged site. Login to an account, wait for email notifications, etc. Assume they are on the road, mobile, and are interested in a ping that a friend has signed on, responded, changed something or informed you of something you wanted an answer to. No load on your end, the app’s end, and easy to ignore by the user, but provokes discovery and use of the program without bugging the user with switching between programs, web pages, accounts and emails.