Tag: wireless

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="https://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: