Responsive Navigation: Optimizing for Touch Across Devices

I wanted to share this with people as I think it is a fantastic post and is a great read for any mobile Developers / Marketers. It is written by Jason Weaver & Luke Wroblewski. Enjoy. 

As more diverse devices embrace touch as a primary input method, it may be time to revisit navigation standards on the Web. How can a navigation menu be designed to work across a wide range of touch screen sizes? 

The Demos

• Split Screen Navigation
• Multi-Level Bottom Navigation
• Variation: Split Screen Navigation with a background
• Variation: Single Row

Why do these navigation menus work across a wide range of touch screen sizes? Why do we care about touch across a wide range of screen sizes? Read on...

Across Screen Sizes

First, why do we care about touch across a wide range of screen sizes? Isn't touch just used on mobile devices and tablets? While it's true touch interfaces are increasingly present on small screen sizes, there's a lot of diversity even in this class of devices. Consider in the past two months smartphones ranging from 3.5" to 5.5" have been released by major manufacturers.

Tablets are no different. Again in the past two months alone we've seen tablets released with 7" screens, 10.1" screens, and everything in between.

And the very notion of what defines a tablet is being challenged by laptop/tablet convertibles and touch-enabled Ultrabooks. These devices range from 11.6" to 13.3" inch screens and treat touch as a primary input method. In fact, early testing by Intel found that touch was even a preferred input method on touch enabled laptops.

Even beyond 13 inches, touch and gesture interfaces are possible. Consider Sony's 20" VAIO Tapor the use of a gesture interface like Leap Motion on any sized-screen and really quickly you realize touch is an input model to consider across all screen sizes.

Accounting For Touch

So what does it mean to consider touch across all screen sizes? Two things: touch target sizesand placement of controls. Any navigation system that needs to work with touch needs to have menu options that can be comfortably used with imprecise fingers. It also needs to be positioned in a way that aligns with how people hold and use touch-enabled devices.

Touch target sizes are relatively easy: just make things big enough to prevent accidental taps and errors. Your reaction to this may be "but I have so many things to fit in my app. How can I do that if the touch targets have to be so big?" frankly you can't and quite often that's a good thing.

Designing towards touch really forces us to simplify and decide what's most important- what needs to stay on the screen. If we go through that exercise we ultimately end up with software that's easier to understand and as a result more often used. Both good things. And while big touch targets can be comfortably used with a mouse (in fact they'll be easier to hit with a mouse), small mouse size targets can't be used easily with touch. So when in doubt, optimizing for touch will make sure things are usable for both mouse and touch users.

But accounting for touch isn't just about the size of controls, the placement of controls is important as well. To understand why this matters, let's look at how people hold a smartphone. In each of these examples, the bias is toward right handed use as most people in the world are right handed.

These common patterns of posture create easy to hit and hard to reach touch areas. The area toward the bottom of the screen is easy, whereas the upper corners are a bit of stretch. So the bottom area of a smartphone screen is where we want to put an application's most common and important interactions. Where they can be reached quickly and easily.

Similarly we can look at tablet postures or how people typically hold tablet computers. That is two hands along the sides, or typing over the screen in their lap. In the landscape postures we see a different series of easy, ok, and hard to hit touch areas.

With touch-enabled laptops, people get pretty close to the screen and use their two thumbs to tap which yields easy to hit areas in the bottom corner of the screen.

As you've hopefully observed the common pattern here is comfortable touch surfaces toward the bottom of the screen. Looking at the ergonomics of use across devices types pushes us toward the bottom, which is where we'd ideally like to place important functionality like navigation controls.

An Adaptive Solution

Today, most Web navigation systems are designed for a mouse and keyboard world. They're placed prominently across the top of the screen or along the sides. In other words, everywhere but in easy to touch areas.

In our earlier multi-device designs, we accounted for this convention by creating a series of navigation structures that adapted from comfortable touch zones on small screen devices to the kinds of navigation structures people have come to expect on desktop and laptop computers (top of screen, etc.). You can see a number of these explorations in Off Canvas Multi-Device Layouts.

But given how things are changing and touch is permeating nearly every sized screen, it may be time to revisit that structure. Specifically, rather than optimizing for touch only on small screens, optimizing for it on all screens. That means big touch targets and bottom positioning throughout.

Of course we still have to account for varying screen widths, so our navigation controls will have to change as more space becomes available. To account for this, we decided to shift from a single row navigation structure on small screens to a split row model on larger screen sizes.

You can see this technique in action in the sample pages below:

• Split Screen Navigation
• Multi-Level Bottom Navigation
• Variation: Split Screen Navigation with a background
• Variation: Single Row

Whether or not this multi-device navigation structure is the best answer for an increasingly touch-enabled computing world remains to be seen. However, rethinking our existing conventions is exactly the kind of thing we should be doing during the kind of fundamental changes we are seeing today. New input methods and devices are challenging our long-standing assumptions and that's a good thing for Web design.

Thanks to Jason Weaver for bringing these ideas to life! Check out some of our other multi-device collaborations in:

• Off Canvas Multi-Device Layouts
• Off Canvas Multi-Device Layout

How to: Send an Android User to Another App

One of Android's most important features is an app's ability to send the user to another app based on an "action" it would like to perform. For example, if your app has the address of a business that you'd like to show on a map, you don't have to build an activity in your app that shows a map. Instead, you can create a request to view the address using an Intent. The Android system then starts an app that's able to show the address on a map.

Build an Implicit Intent

---

Implicit intents do not declare the class name of the component to start, but instead declare an action to perform. The action specifies the thing you want to do, such as view, edit, send, or get something. Intents often also include data associated with the action, such as the address you want to view, or the email message you want to send. Depending on the intent you want to create, the data might be a Uri, one of several other data types, or the intent might not need data at all.

If your data is a Uri, there's a simple Intent() constructor you can use define the action and data.

For example, here's how to create an intent to initiate a phone call using the Uri data to specify the telephone number:

Uri number = Uri.parse("tel:5551234");
Intent callIntent = new Intent(Intent.ACTION_DIAL, number);

When your app invokes this intent by calling startActivity(), the Phone app initiates a call to the given phone number.

Here are a couple other intents and their action and Uri data pairs:

• View a map:

  // Map point based on address
  Uri location = Uri.parse("geo:0,0?q=1600+Amphitheatre+Parkway,+Mountain+View,+California");
  // Or map point based on latitude/longitude
  // Uri location = Uri.parse("geo:37.422219,-122.08364?z=14"); // z param is zoom level
  Intent mapIntent = new Intent(Intent.ACTION_VIEW, location);

• View a web page:

  Uri webpage = Uri.parse("http://www.android.com");
  Intent webIntent = new Intent(Intent.ACTION_VIEW, webpage);

Other kinds of implicit intents require "extra" data that provide different data types, such as a string. You can add one or more pieces of extra data using the various putExtra() methods.

By default, the system determines the appropriate MIME type required by an intent based on the Uri data that's included. If you don't include a Uri in the intent, you should usually use setType() to specify the type of data associated with the intent. Setting the MIME type further specifies which kinds of activities should receive the intent.

Here are some more intents that add extra data to specify the desired action:

• Send an email with an attachment:

  Intent emailIntent = new Intent(Intent.ACTION_SEND);
  // The intent does not have a URI, so declare the "text/plain" MIME type
  emailIntent.setType(HTTP.PLAIN_TEXT_TYPE);
  emailIntent.putExtra(Intent.EXTRA_EMAIL, new String[] {"jon@example.com"}); // recipients
  emailIntent.putExtra(Intent.EXTRA_SUBJECT, "Email subject");
  emailIntent.putExtra(Intent.EXTRA_TEXT, "Email message text");
  emailIntent.putExtra(Intent.EXTRA_STREAM, Uri.parse("content://path/to/email/attachment"));
  // You can also attach multiple items by passing an ArrayList of Uris

• Create a calendar event:

  Intent calendarIntent = new Intent(Intent.ACTION_INSERT, Events.CONTENT_URI);
  Calendar beginTime = Calendar.getInstance().set(2012, 0, 19, 7, 30);
  Calendar endTime = Calendar.getInstance().set(2012, 0, 19, 10, 30);
  calendarIntent.putExtra(CalendarContract.EXTRA_EVENT_BEGIN_TIME, beginTime.getTimeInMillis());
  calendarIntent.putExtra(CalendarContract.EXTRA_EVENT_END_TIME, endTime.getTimeInMillis());
  calendarIntent.putExtra(Events.TITLE, "Ninja class");
  calendarIntent.putExtra(Events.EVENT_LOCATION, "Secret dojo");

  Note: This intent for a calendar event is supported only with API level 14 and higher.

Note: It's important that you define your Intent to be as specific as possible. For example, if you want to display an image using the ACTION_VIEW intent, you should specify a MIME type of image/*. This prevents apps that can "view" other types of data (like a map app) from being triggered by the intent.

Verify There is an App to Receive the Intent

---

Although the Android platform guarantees that certain intents will resolve to one of the built-in apps (such as the Phone, Email, or Calendar app), you should always include a verification step before invoking an intent.

Caution: If you invoke an intent and there is no app available on the device that can handle the intent, your app will crash.

To verify there is an activity available that can respond to the intent, call queryIntentActivities() to get a list of activities capable of handling your Intent. If the returned List is not empty, you can safely use the intent. For example:

PackageManager packageManager = getPackageManager();
List<ResolveInfo> activities = packageManager.queryIntentActivities(intent, 0);
boolean isIntentSafe = activities.size() > 0;

If isIntentSafe is true, then at least one app will respond to the intent. If it is false, then there aren't any apps to handle the intent.

Note: You should perform this check when your activity first starts in case you need to disable the feature that uses the intent before the user attempts to use it. If you know of a specific app that can handle the intent, you can also provide a link for the user to download the app (see how to link to your product on Google Play).

Start an Activity with the Intent

---

Figure 1. Example of the selection dialog that appears when more than one app can handle an intent.

Once you have created your Intent and set the extra info, callstartActivity() to send it to the system. If the system identifies more than one activity that can handle the intent, it displays a dialog for the user to select which app to use, as shown in figure 1. If there is only one activity that handles the intent, the system immediately starts it.

startActivity(intent);

Here's a complete example that shows how to create an intent to view a map, verify that an app exists to handle the intent, then start it:

// Build the intent
Uri location = Uri.parse("geo:0,0?q=1600+Amphitheatre+Parkway,+Mountain+View,+California");
Intent mapIntent = new Intent(Intent.ACTION_VIEW, location);

// Verify it resolves
PackageManager packageManager = getPackageManager();
List<ResolveInfo> activities = packageManager.queryIntentActivities(mapIntent, 0);
boolean isIntentSafe = activities.size() > 0;
  
// Start an activity if it's safe
if (isIntentSafe) {
    startActivity(mapIntent);
}

Show an App Chooser

---

Figure 2. Example of the chooser dialog that appears when you usecreateChooser() to ensure that the user is always shown a list of apps that respond to your intent.

Notice that when you start an activity by passing your Intent tostartActivity() and there is more than one app that responds to the intent, the user can select which app to use by default (by selecting a checkbox at the bottom of the dialog; see figure 1). This is nice when performing an action for which the user generally wants to use the same app every time, such as when opening a web page (users likely use just one web browser) or taking a photo (users likely prefer one camera). However, if the action to be performed could be handled by multiple apps and the user might prefer a different app each time—such as a "share" action, for which users might have several apps through which they might share an item—you should explicitly show a chooser dialog, which forces the user to select which app to use for the action every time (the user cannot select a default app for the action).

To show the chooser, create an Intent using createChooser() and pass it to startActivity(). For example:

Intent intent = new Intent(Intent.ACTION_SEND);
...

// Always use string resources for UI text. This says something like "Share this photo with"
String title = getResources().getText(R.string.chooser_title);
// Create and start the chooser
Intent chooser = Intent.createChooser(intent, title);
startActivity(chooser);

How to Become a Mobile App Developer - Because... it’s the way forward

Software development is going mobile, bringing applications to phones, laptops and tablets everywhere. Gartner predicts that by 2015 mobile app development projects will outnumber PC application projects by 4 to 1.Mobile app developers are reaping the benefits of 45 percent year over year employment growth, according to Bloomberg BusinessWeek. Dice.com reported a 100 percent increase in job posting for mobile app developers between 2010 and 2011. Developers with the right mix of skills can find boundless opportunity in the multibillion-dollar mobile app industry. Learn what it takes to become a mobile software developer.

Mobile app developers hail from different walks of life—A software engineer, a tech-savvy business entrepreneur or a web designer may have what it takes to create the next top-selling app. The common piece of the puzzle is some sort of computer programming training, whether it’s a certificate in a specific language like HTML5 or a bachelor’s degree in software development. With the rapid growth of the mobile medium, some colleges and universities are adding specialized undergraduate degree programs in mobile app development.

Mobile Payment Apps Pose Massive Security Concerns

I am personally a big fan of Mobile Payments applications, well I like the idea of them. I am also pretty certain it is the way forward. Who wants to carry around a mobile and a wallet, what’s the point? It is currently going from Coins -> Cash -> Cards -> Mobile?. That seems like the logical path but what is the security behind it and is it really safe...

Your wallet is something you never want to lose. However, many people are now using mobile wallet applications for making purchases and money transactions. Opposed to your physical wallet, it is hard to control the security of your mobile wallet. Security breaches happen unexpectedly and quietly. A security attack to your mobile wallet can go unnoticed for quite some time.



According to Bloomberg BusinessWeek who refers to Mobile Payments as the new frontier for criminals:
“Nearly 70 percent of mobile phones aren’t password-protected, according to Sophos, a mobile security vendor. Parents allow children to play with their phones without considering that they may download some bit of malware, says Shirley Inscoe, a senior analyst at Aite Group: ‘They don’t realize the risk they may entail given the data stored on their mobile device.’

Criminals can access a mobile wallet by stealing the handset or by tricking its owner into downloading a piece of malicious code. Malware attacks on U.S. smartphones have risen 18 percent since 2011 and now add up to 15.3 percent of the world total, says mobile security vendor NQ Mobile…

…Banks and mobile-payment providers are scrambling to build—or buy—better defenses.”
15.3% of the world – that number shows that attacks are growing rapidly. Mobile payment apps collect the most private personal data, therefore they need to be security tested inside and out. However, they can’t just be tested in the lab, because it’s real world situations that hackers will try to work around. White hat security experts that can find and simulate risks are a developers best option for identifying security threats. Catching any issues before the app’s users do is the ultimate goal.

But how long do you think it will be until the average user ditches there wallet and uses there phone as a primary payment method?

How To Make A Simple Phone Call Application

Following on from yesterday’s post about adding a text function to your app, this time is how to make a simple phone call application. Is that important? Yes, It is. Imagine, you're in danger, and you don't know what to do. So, what should you do? Call emergency number? Do you remember that number? Or, if you get accident, can you type the number correctly? It's a simple task. But it'll be easier and simpler if you can call a number with one touch. Let's see how to do that.


Create a new android project. First thing we should do is to add user permission in AndroidManifest.xml file so we can make a phone call using our app. See the highlighted code below:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
 package="com.blogspot.juniantr.phonecallsample" android:versionCode="1"
 android:versionName="1.0">
 <application android:icon="@drawable/icon" android:label="@string/app_name"
  android:debuggable="true">
  <activity android:name=".PhoneCallSampleAct" 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-permission android:name="android.permission.CALL_PHONE" />
</manifest>


Next, open the main.xml file and we'll change the user

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
 android:orientation="vertical" android:layout_width="fill_parent"
 android:layout_height="fill_parent">
 <Button android:layout_height="wrap_content" android:text="@string/call"
  android:layout_width="wrap_content" android:id="@+id/btnCall"></Button>
</LinearLayout>


Open your activity java file (in my project, it's PhoneCallSampleAct.java) and add this code:

private void phoneCall()
{
   String phoneCallUri = "tel:911";
   Intent phoneCallIntent = new Intent(Intent.ACTION_CALL);
   phoneCallIntent.setData(Uri.parse(phoneCallUri));
   startActivity(phoneCallIntent);
}

Finally, let's add the last touch so the app can running. Our scenario is simple. We just need press the button and it'll call 911. Here is the complete code:

package com.blogspot.juniantr.phonecallsample;
import android.app.Activity;
import android.content.Intent;
import android.net.Uri;
import android.os.Bundle;
import android.view.View;
import android.view.View.OnClickListener;
public class PhoneCallSampleAct extends Activity implements OnClickListener{
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
       
        View callButton = findViewById(R.id.btnCall);
        callButton.setOnClickListener(this);
    }
   
    private void phoneCall()
    {
     String phoneCallUri = "tel:911";
     Intent phoneCallIntent = new Intent(Intent.ACTION_CALL);
     phoneCallIntent.setData(Uri.parse(phoneCallUri));
     startActivity(phoneCallIntent);
    }
 @Override
 public void onClick(View v) {
  // TODO Auto-generated method stub
  switch(v.getId())
  {
   case R.id.btnCall:
    phoneCall();
    break;
   default:
    break;
  }
 }
}


Here is a running sample:

 

How to implement Sending a SMS Message from an Android Application

Introduction

We often come across situations where we are required to send a text message from our Android app. In this article we will explore all possible ways to achieve this simple yet very useful task.

Background

There are two possible ways to send a text message from an Android app
1. The first way is to send it programmatically from your application.
2. The second way is to send it by invoking the built-in SMS application.
In this article we will explore both the scenarios one by one.

* If you are new to Android app development, do refer to the Demo Project section of this article for some useful tips.

1. Sending a SMS programmatically from your application

Include the following permission in your AndroidManifest.xml file -

 

<uses-permission android:name="android.permission.SEND_SMS" />

Import the package -

import android.telephony.SmsManager;

Code to send a SMS -

 

public void sendSMS() {
    String phoneNumber = "0123456789";
    String message = "Hello World!";

    SmsManager smsManager = SmsManager.getDefault();
    smsManager.sendTextMessage(phoneNumber, null, message, null, null);
}

The method sendTextMessage of class SmsManager sends a text based SMS.





Method Detail

 

public void sendTextMessage(String destinationAddress, String scAddress, String text, PendingIntent sentIntent, PendingIntent deliveryIntent)

Details about the parameters that the method accepts can be found here.
If you use the code above you will able to send messages with length less than or equal to 160 characters only.

Code to send a long SMS -

public void sendLongSMS() {
 
    String phoneNumber = "0123456789";
    String message = "Hello World! Now we are going to demonstrate " + 
            "how to send a message with more than 160 characters from your Android application.";

    SmsManager smsManager = SmsManager.getDefault();
    ArrayList<String> parts = smsManager.divideMessage(message); 
    smsManager.sendMultipartTextMessage(phoneNumber, null, parts, null, null);
}

The method sendMultipartTextMessage of class SmsManager sends a multi-part text based SMS


Method Detail

public void sendMultipartTextMessage(String destinationAddress, String scAddress, ArrayList<String> parts, ArrayList<PendingIntent> sentIntents, ArrayList<PendingIntent> deliveryIntents)

Details about the parameters that the method accepts can be found here



Note
The method divideMessage of class SmsManager divides the message text into several smaller fragments of size 160 characters or less.

* Refer to the Points of Interest section of this article for a useful tip.

2. Send a SMS by invoking the built-in SMS application using Intents.

To invoke the SMS application via intents we have to do the following:
- Set the action to ACTION_VIEW
- Set the mime type to vnd.android-dir/mms-sms
- Add the text to send by adding an extra String with the key sms_body
- Add the phone number of the recipient to whom you wish to send the message by adding an extra String with the key address
Note:
- The last two steps are optional, if you don't wish to specify the message text or the recipients you can ignore these steps.
- If you wish to set multiple recipients use semi-colon ';' as the separator in the string passed as theaddress

Code to send a SMS using Intents

    
public void invokeSMSApp() {
        Intent smsIntent = new Intent(Intent.ACTION_VIEW);

        smsIntent.putExtra("sms_body", "Hello World!"); 
        smsIntent.putExtra("address", "0123456789");
        smsIntent.setType("vnd.android-dir/mms-sms");

        startActivity(smsIntent);
}

Points of Interest

If you choose to send messages programmatically and wish to add the message sent from your application in the native 'Messages' application of Android in the 'Sent' folder, here is the code to achieve it using Content providers -

Code to save a SMS in 'Sent' folder of native 'Messages' application

Include the following permission in your AndroidManifest.xml file -

 

<uses-permission android:name="android.permission.WRITE_SMS" />
<uses-permission android:name="android.permission.READ_SMS" />

You will have to add both WRITE_SMS and READ_SMS permissions.

Add the following imports -

 

    import android.net.Uri;
    import android.content.ContentValues;

Insert the below code where you wish to perform the operation -

    ContentValues values = new ContentValues(); 
              
    values.put("address", "0123456789"); 
              
    values.put("body", "Hello World!"); 
              
    getContentResolver().insert(Uri.parse("content://sms/sent"), values);

Demo Project

This is a demo project which implements all the scenarios as discussed in this article.

It has used EditText widget for the Phone Number and Message input. Here I'd like to mention twoXML attributes that I have used -

• android:hint This string is displayed as a hint to the user when the field is empty. This will give your application a more native look and feel.
• android:inputType="phone" (for Phone Number field) This signals the input method (IME) that this field should accept only valid Phone Numbers. This will save you from validating user input.

Which way to go....

Both the ways have their own set of pros and cons. If you decide to use Intents to send text messages from your application then no additional permissions are required but it will become a two step process, for instance if the user presses any button in your app to send SMS the intent will be displayed where he/she will have to press send; whereas if you decide to do it programitically you might also have to check for the result.