3 Steps for Determining if Your Website is Mobile Ready

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.

The Art of Internet Connectivity

Everyone’s internet connectivity experience is unique and it can vary from minute to minute. Most internet users can sense slowdowns, and everyone can identify when a connection fails. Web developers absolutely rely on a web connection to build web pages. So, when our internet connection goes down our productivity comes to a halt.

I’ve lost count of the number of times I’ve reported to various tech support organizations that I wasn’t able to reach a particular website or web service and was told by the tech: “I was able to reach it just fine.” This happened again today when I called my DSL provider to inform them our internet service went down completely and then was degraded to 1/10 of what we were paying for (e.g. ~1.12 Mbps on a 12 Mbps service). They told me that the line was stable. Although I’m not real sure what stable means. Then the speed gradually increased back up to normal of over the next hour and a half. This has happened about a half dozen times over the last three months. 

As a web developer, you load web pages up to several hundred times per day. I almost always have monitoring tools hooked up that give the exact time to download a page and its associated elements. So, I have a good idea of when the internet is performing well, and when it isn’t.  Because of this I’ve become sensitized to small, millisecond changes in download times.

I also gained extensive knowledge of internet connections when working on high availability systems with up to five-nines uptime. We deployed systems that monitored web traffic all over the U.S. 24×7. I was amazed to see that internet traffic was very much like our roadways. Sometimes traffic is moving fast, other times it’s slow in spots, and sometimes it’s completely stopped or even re-routed.

In many cases, a modem (or router, as I’m using the terms interchangeably) simply locked up. This is quite common as these devices often run a small linux-based operating system that can occasionally flake out. I can say with certainty in the cases where my DSL modem/wireless router didn’t die, and there was no internet connection, then in 9 out of 10 of these cases it was a problem upstream with the carrier.

Guidelines. So, here are some guidelines for helping you narrow down where the problem might be:

– Check the modem connectivity lights. Usually if a modem is connected to the internet, the connectivity light will be a steady or flickering green. Red  or no connectivity light almost always means no connection. It should be a matter of reflex to simply restart the modem and see if that fixes the problem.

– If the internet connectivity light doesn’t come back after restarting the modem, then call tech support.

– On rare occasions (1 out of 10), restarting the server plus the modem restored connectivity.

– Still no service? You can go get a cup of coffee then come back later and recheck.

– Or, if the internet connection light is green, try blowing away the browser cache and try to reload? Sometimes old versions of pages can stick in the cache.

– Can you load any other websites? If you can, then your particular server or service is most likely down.

– Can you ping the server? (for servers that allow ping). Determines if the server has basic connectivity.

– Can you run a tracert? Let’s you look at the connectivity between you and the remote server.

– Document the problems so you have a record for future reference.

– If you need continuous monitoring with alert thresholds, then look into evaluating continuous monitoring tools such as Paessler.

– If you know how to get the basic troubleshooting out of the way, or if you’ve already done it, then insist on escalation when you call tech support. You need to get back to coding as fast as possible.

Check Network Connectivity in Your Android App

Our team does alot of application demos, and a vast majority of them require an internet connection. My challenge is that most of my development droid phones only have wireless (e.g. 802.11g), and I need a graceful way to detect if an internet connection exists. Without some sort of connection-based error detection, my mapping app would simply have a few buttons and a grey screen with no clue as to what the problem might be. So, here’s one way to to alert your users that the network connection is down. This was built using Android 2.2 on Eclipse 3.5.

Step 1 – Create a new Class that takes advantages of the capabilities in the ConnectivityManager class. That way you can reuse this across multiple projects. Be sure to import the appropriate references, and change the package name to the correct path in your project:

  
package com.esri.arcgis.android.samples;

import android.content.Context;
import android.net.ConnectivityManager;
import android.net.NetworkInfo;

public class CheckConnectivity{
	ConnectivityManager connectivityManager;
	NetworkInfo wifiInfo, mobileInfo;

	/**
	 * Check for <code>TYPE_WIFI</code> and <code>TYPE_MOBILE</code> connection using <code>isConnected()</code>
     * Checks for generic Exceptions and writes them to logcat as <code>CheckConnectivity Exception</code>. 
     * Make sure AndroidManifest.xml has appropriate permissions.
	 * @param con Application context
	 * @return Boolean
	 */
	public Boolean checkNow(Context con){
		
		try{
			connectivityManager = (ConnectivityManager) con.getSystemService(Context.CONNECTIVITY_SERVICE);
			wifiInfo = connectivityManager.getNetworkInfo(ConnectivityManager.TYPE_WIFI);
			mobileInfo = connectivityManager.getNetworkInfo(ConnectivityManager.TYPE_MOBILE);	
			
			if(wifiInfo.isConnected() || mobileInfo.isConnected())
			{
				return true;
			}
		}
		catch(Exception e){
			System.out.println("CheckConnectivity Exception: " + e.getMessage());
		}
		
		return false;
	}	
}

Step 2 – Create an instance of that Class, and import the new Class you just created. Be sure to place your check for connectivity before any code that requires an internet connection. You can now use the Boolean result to decide what actions you want to take. I added the System.out.println to print the results into the logcat file. You can access logcat by installing Android Debug Bridge (ADB) and then typing “adb logcat” at a DOS command prompt. On a related note, you should also install Android Debug Tools (ADT) Eclipse Plug-in.

 @SuppressWarnings("serial")
public void onCreate(Bundle savedInstanceState) {
     super.onCreate(savedInstanceState);
     setContentView(R.layout.main);

     CheckConnectivity check = new CheckConnectivity();
     Boolean conn = check.checkNow(this.getApplicationContext());
     if(conn == true){
          //run your normal code path here
     }
     else{
          //Send a warning message to the user
          connectivityMessage("Check Network Connection."); }
}

public void connectivityMessage(String msg){
     Context context = getApplicationContext();
     Toast toast = Toast.makeText(context, "", Toast.LENGTH_LONG);
     toast.setGravity(Gravity.CENTER, 0, 0);
     toast.setText(msg);
     toast.show();
}

Step 3 – I did initially run into a problem where the application threw a strange “Source not found” error on a system thread. It say strange because there was absolutely no useful information. I knew the application ran just fine without my ConnectionCheck Class, so I used the step-thru debugger to narrow things down to my checkNow() method. I placed that in a basic try/catch block and walla there was the error with the solution:

I/System.out(  269): CheckConnectivity: ConnectivityService: Neither user 10032 nor current process has
 android.permission.ACCESS_NETWORK_STATE.
I/System.out(  269): CONNECTION CHECK: false

So, I went and added that permission line into the AndroidManifest.xml file and my app worked:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
      android:versionCode="1"
      android:versionName="1.0" package="com.esri.arcgis.android.samples">
  	<uses-permission android:name="android.permission.INTERNET"/>
  	<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
  	<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <application android:icon="@drawable/icon" android:label="@string/app_name" android:debuggable ="true">
        <activity android:name=".DrawGraphicElements"
                  android:label="@string/app_name">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
    <uses-sdk android:minSdkVersion="8" />
</manifest>

Here’s what the warning message will look like if you don’t have an internet connection:

From 56K Baud to FiOS – how far have really come?

While searching for a connector in some boxes of long forgotten electronics detritus, I came across a 56K PC Card modem from 3Com. I immediately grabbed the card and thumbed it over in my hands and wondered how far have we really come since then? For those of you that never had dial-up access to the internet, this was the hottest ticket back in the ancient days of 1999. 56K was smoking back then! My conclusion: we’ve come far, but we also have taken many steps backwards. We have, in many respects, become victims of our own success.

Let me explain. Yes, first let me acknowledge that there are companies like Verizon that sell FiOS with download speeds of 15Mb/second or greater depending on how much money you want to pay. And, there are plenty of DSL and Cable internet vendors that offer 3MB/second (or more) download speeds. Oh, and I can’t forget the promise of 4G cell phone speeds.

But, reality is a far, far different animal than promises. There are plenty of times when you may not get anywhere near the download speeds promised due to a variety of technical issues. In my experience, it’s actually rare that I get to benefit the full capabilities of the cutting edge, 21st Century internet technology at my disposal. For example, if you have a 15Mb/second FiOS connection it doesn’t guarantee that every website you go to will download at 15Mb/second everytime. That’s a fact.

On any given day, we are all dependent on many factors that affect internet download speeds. The list is huge and is by no means limited to the following. Let me roughly say that all these items affect how fast something will download:

  • Number of users hitting a particular website
  • That websites hardware and bandwidth capabilities
  • General internet backbone traffic
  • Your own internet/cable modem
  • General packet collisions/losses/overhead
  • The wire or wireless connection you are using
  • Your own network card or wireless card on your computer.
  • Background processes running on your computer
  • Cell phone tower signal strength and number of users
  • And so, so many more…

I could go on for several pages, but you get the idea. Since I’m a web application developer, I have to pay attention to how fast pages load. And I often monitor and test internet connections to try and figure out where the performance problems are. Perhaps, this makes me more sensitive and less patient when I don’t receive the full benefit of the connection to the internet when it’s offered to me at my home, at work, or when traveling and using a conference or hotel wireless connection.

This is the internet age right? I have come to expect instantaneous downloads and hiccup free streaming video, but it’s very rare that I can watch a YouTube video without it stuttering and pausing to re-buffer every 15 seconds. Or, how many of you have continuously fast access to the internet via your AT&T iPhone? If you never have any problems you’re either lucky and live in a less congested area, or you aren’t a power user and are okay with downloads occasionally taking longer than expected.

There’s an immutable law that we always forget about it and it says “bandwidth is finite”.  We are very capable of building applications that consume more and more bandwidth every day.  There are millions of videos added to the interent every hour and ever larger files being downloaded. And, as tens of millions of more people buy smarthpones, they too are continuously consuming internet bandwidth 24 hours a day. And, so on and so forth the argument goes on.

In conclusion, as web developers we can do our part for improving people’s internet experience by optimize your web applications as much as possible. Make your web applications file sizes as small as possible, use lazy loading, run code optimizers, consider binary formats for moving large data back and forth, and optimize images were possible. In the end, we will all benefit from a better internet experience.