Here are three step for helping determine the mobile ready strengths and weaknesses of your existing website. I’ve had a number of conversations from website teams recently asking the question: “Can we reuse our existing site for mobile users?” I was surprised to learn that the individuals asking me the question had, in fact, never visited their own site on a mobile device.
Note, this blog describes steps that need to be address before you decide whether to build for the web or native applications.
Step One – Create a small focus group of company outsiders, friends as well as employees.
- Gather as many different types of mobile devices as possible including: iPad, iPhone, Android tablet, and several varieties of Android phones. Try to use a combination of older and newer devices. Don’t fool yourself by simply using all of the latest great versions, especially if your web visitors are the general public.
- Get a mobile projector, such an Elmo or IPEVO.
- Write down the common use cases, and the workflows associated with them. An example use case might be logging in to your site. And, a workflow would describe the steps a user takes to complete the login process from beginning to the end.
- Visit your website and run through the common use cases.
- Turn off wireless, if possible, and let everyone experience typical internet speeds to simulate, for example, standing in line at the grocery store.
- Trade off using different devices.
- Hire a user interface (UX) designer if you don’t already have one. Bring them on board at the beginning, or as early as possible, in this evaluation process.
Step Two – Create a grading system to help assess the experience everyone had with each device.
- Were you able to accomplish your task as easily and quickly as if you were at your desk with a full-size laptop or computer?
- Did you have to do a lot of extra panning and zooming in and out to navigate through the use cases and workflows?
- Was there any functionality that simply didn’t work, didn’t work correctly, or didn’t work as expected on the mobile device?
- Were there any aspects of the site that looked different or wrong? For example, was all the text the right size? Was everything in the right place?
- Were you satisfied with the amount of time it took for pages and images to load?
- Were you able to comfortably use the site when rotating the phone between landscape and portrait views?
- Were you okay with how quickly you were able to switch between different pages on the website?
- Were you able to access secure resources without any problems?
- And, perhaps most importantly, were there any obvious improvements you would like to see made to make mobile surfing experience better?
Step 3. Apply some commonly known mobile-specific conditions to your findings and see if helps to provide context to everyone’s experience.
- One-handed plus gestures. It’s a fact that navigating a mobile web is significantly different from a desktop browser. There’s no mouse! Mobile browsing is usually done with one hand, while the other hand is used to hold the device. The screen is driven by what are called gestures. Examples of gestures are when you swipe your thumb upward on a page to scroll it downward, or when you use two fingers, usually the index finger and thumb, to pinch zoom the screen in or out.
- Smaller Screens. And, of course the screens are much smaller than what you would find on a desktop or laptop. Different devices have different resolutions. And, navigating a full website can seem more cumbersome as you use gestures to navigate around, in comparison to the desktop experience of seeing the entire page, and using your a precision mouse to whip through the different links on a page.
- Download Speeds. Download speeds on mobile devices vary considerably compared to your work machine hooked up to a reliable local area network (LAN). A site that seems zippy on your work machine, may load much differently on a typical smartphone. Also, for some older phones they may have much less processor power and that may lead to the perception of slower download speeds as the CPU chugs through displaying the page.
How do I interpret the results?
When you are done compile, discuss and analyze the findings with your internal teams and stakeholders.
Good. If most testers successfully navigated the majority of use cases and workflows then you are in good shape, and you may simply need to do some additional tweaking to your site.
Not so good. However, if most testers had unsatisfactory experiences then you’ll need to spend more time looking more closely as what worked and what didn’t work. You may find workflows that are great on a desktop machine that are clumsy and awkward on a mobile device.
Don’t be surprised. Portions of your site may have to be redesigned. You may not be able to include everything that’s in your full site into your mobile site. You may have to spend a lot of time optimizing the site to speed up page load times. Pay special attention to functionality that didn’t work on mobile. Mobile web browsers have well known limitations compared to full browsers. Looking at what didn’t work may help you decide if you need access to native device capabilities.
You’ve just taken a huge first step towards helping your team set the stage for stepping into the mobile world.
Here’s my short list of some things to consider when you demo your company’s mobile apps to a live audience. I’ve accumulated this list over the last several years as the team I’m on does a lot of showing off apps on iOS, Android and Windows Phone. We’ve also seen quite a few demos from customers and at industry conferences.
While most of these tips apply to personal demos where you have the phone in your hand while standing in a tradeshow booth, I’m actually talking about projecting demos on a big screen in front of a live audience, or during an internet video conference call with screen sharing.
- Screen brightness. Adjust the screen brightness so that the screen is not too dark and not washed out, and temporarily disable screen brightness auto-dimming. Auto-dimming is where the phones background light gets dimmed usually around ten to fifteen seconds before the screen auto-locks.
- Turn off auto-lock. Temporarily disable your auto-screen lock (if your company policy permits it). There’s nothing more aggravating than talking about something for a few minutes and then when you turn your attention back to the phone you have to re-enter your unlock code. I’ve also seen this happen to people on the screen behind them and they didn’t notice but the audience could see it.
- Silence the phone. For demos that don’t need sound, which is probably most demos, turn your phone’s sound all the way to “off”. Most phones beep, tweedle and pop as various things happen in the background, so spare your audience by making your phone silent.
- A/C Power. Plug your phone into a power outlet. While this may seem obvious, I’ve seen a phone die during a major industry conference plenary session.
- Shutdown extra apps. Shut off any unnecessary apps that will consume memory and CPU. You want your demo to run as fast as possible.
- Remove unnecessary icons. Clean any non-professional app icons from the navigation screens you will be showing live. On a few rare occasions I’ve seen some fairly disturbing icons that had no place in a professional presentation.
- Verify the type of demo camera. Ask ahead what kind of demo camera the conference has for mobile phones, one of the most common ones is called an ELMO. These are devices where you set your phone below it and it has a camera that points downward at the phone and connects to a projector through a switch. So, when you go to show off your app you turn a switch that connects the ELMO (or similar device) to the projector. Some of these are terrible and some are great. I use an IPEVO Point 2 for some demos because it’s portable and I trust it.
- Test demo camera. Test your demo camera well before your presentation. You may need some help from the conference’s audio visual team. Make sure your phone in focus, check if you can see the application details, look to see if the background colors aren’t too white and washed out, etc.
- Cache local data. Cache your data when possible. If you plan on connecting to remote data sources, consider moving that data onto a local SQLite database on your phone.
- Check internet connection. Check your internet connection beforehand. Conference are notorious for having limited cell and wireless coverage. My recommendation is always create a movie backup of your most important demo points. Yep, I’m 100% serious. With an IPEVO Point 2, for example, you can project the camera image in a desktop app and use software such as Camtasia Studio, which also offers a free trial, to create a movie with audio too. Also, a note to phone developers here, it’s a best practice to check if your app has an internet connection and to let your users know if the connection goes away, for example: http://www.andygup.net/?p=155.
Debugging iPad or iPhone apps that you built with FlashBuilder has a number of extra steps that you don’t need when developing with Android. This is especially true if you use Windows as your primary operating system. The good news is that once you’ve done it once or twice it should be fairly straight forward. So here are a few hints to get you going.
Step 0. If you are building on Windows make sure to install the latest version of iTunes. Then check that your iPad or iPhone can be synched with iTunes. If you use a mac you’ve most likely already done this step (in your sleep a hundred times).
Step 1. Make sure you have a certificate and provisioning file. This must be configured under FlashBuilder Project > Properties > Flex Build Packaging. IMPORTANT: If the certificate and provisioning file are not set up or are not valid you will not be able to compile your project. If you don’t know what this is or how to do it, additional info can be found here in a great blog post by Holly Schinsky (@devgirlFL).
Step 2. Set up a Debug Configuration. If you don’t know where that is, select the pulldown next to the bug icon on the FlashBuilder toolbar and then choose Debug Configuration, or go to Run > Debug Configurations. Choose Apple iOS as your Target Platform. Be sure to select the On Device Packaging Method > Fast! If you don’t do this and you choose the Standard option it will take five or more minutes to compile the build each time you hit debug, and that can become a huge time waster really fast. One advantage of using the Standard option is it will perform more like the final release build. In comparison, the Fast version won’t be as performant. So, for the vast majority of your debugging you should probably use Fast, and when you want to test a final build then you might want to choose Standard. When you are ready select the Debug button.
Step 3. You will then see a popup window with six important instructions. Once you have completed Steps one and two, select the Show package in Explorer link.
Step 4. Drag the .ipa file from your file browser window into the iTunes Library > Apps area.
Step 5. Select the Sync button on the bottom right hand corner of iTunes. You should see Sync In Progress screen on your device. Let the operation complete. When it’s finished you should see a message in the message box at the top of iTunes that says the sync was successful. If there was an error it will also show up in the message box at the top of the iTumes application window.
Step 6. Launch the application on your iPad or iPhone. You should get a popup window titled Flash Debugger that asks for the IP address or hostname. Important: your iPad or iPhone and your development machine need to be on the same wireless LAN, if they aren’t then this step won’t work. If you don’t have a wireless LAN handy you can always log both machines into a MiFi or some other type of mobile hotspot. Then enter the IP address of your development machine. On a windows machine you can easily get that in a DOS prompt using the command ipconfig. Hit OK.
The Final Result. If all goes well the app will launch and you will start to see debugging output in FlashBuilder.