Research Notes – Development Concepts for Android

Research Notes – Development Concepts for Android

Android users are familiar with the constructs developed by Google for Android devices. These cookie-cutter constructs allow for development teams to very quickly produce working applications. Although the Android platform is open and customizable, creating custom Android designs can take much longer to complete.

GUI Controls

Android provides a number of standard GUI (screenshots) controls that enable a rich user experience. Designers and developers should thoroughly understand these controls because they are faster to implement and ensure good performance. By implementing standard controls, you can eliminate the need to test, revise and improve custom controls. Creating a “clean” custom control from scratch can take a significant amount of design and development time. Google, however, has already thought about these interactions and developed standard controls to properly address them.

Android users expect standard controls. Through their interactions with other Android apps, users become accustomed to Android’s standard controls. Deviating can confuse and frustrate users, making them less likely to want to use your app.

User Activities

Android applications are composed of activities which are unique, focused actions a user can take. Because it can be difficult or time consuming to scroll, zoom in, or click links on a small screen, it is recommended that an app display only one activity per screen. While a screen can expose multiple tasks, it should help the user complete just one activity at a time.

User Interactions

When a user first downloads your application, he will make snap judgments on the usability and intuitiveness of the application within the first few minutes of use. So it’s crucial to balance the creativity of your app with the standard Android user interactions.

Standard user interactions include:

  • Hard buttons – including Back, Menu, Home and Search buttons. Soft buttons that duplicate these features will only confuse or frustrate Android users.
  • Long press elements – Items of a list can be long pressed to open a context menu that provides secondary information.

Layouts

Android GUI (screenshots) screens are frequently re-sized, both on the fly via pinch and zoom as well as at start-up when Android adjusts the size of the GUI (screenshots) to fit the screen. In order to make the most of the screen size and handle this resizing gracefully, Android provides a number of screen layout options. First, Android developers must specify whether each screen should follow a linear layout (the most common) which manages controls in a horizontal or vertical fashion, or a relative layout which manages controls in relation to one another. A relative layout defines the position of controls by their relationship to other components on the same screen.

Android also offers specific layout properties to control the way in which screen elements are displayed across Android devices and during use:

  • Weight – allows the developer to determine how free space is divided on the screen.
  • Gravity – the term used for control alignment (right, bottom, top, or left) on an Android device.
  • Density independence – an application achieves “density independence” when it preserves the physical size (from the user’s point of view) of user interface elements displayed on screens with different densities. Without density independence, a GUI element (such as a button) will appear larger on a low-density screen and smaller on a high-density screen.

So who specifies all of these properties? In our experience, best practice is to have the designer document the layout and re-size behavior of each screen to the development team via a series of wire-frames, if not a full style guide. The designer should then stay in close communication with the development team as the developers work to determine the right combination of Android layout properties to realize the design.

Smartphone and Tablet Screen Sizes

A common misconception is that an Android application should be designed to support only a specific set of Android devices. In reality, Android offers you tools needed to develop a visually impressive interface that supports the full range of devices and screen sizes on the market.

To help you accommodate the range of Android screen sizes, Android recommends designing four versions of the application GUI:

  • A small version for screens under 3″.
  • A normal version to accommodate 3″ to 4.5″ screens.
  • A large version for viewing on 4.5″ to 10″ screens.
  • An extra large version for devices with screens larger than 10″ (tablet).

It’s not strictly necessary to create a design for all four versions – in some cases; one “normal” and one “extra-large” version may suffice.

Fragments Construct

A smartphone should only display one activity per screen due to its small screen size. Tablet devices, however, offer additional screen real estate and are often used in a similar setting as a desktop or notebook, meaning the application could show more information at once on the screen. Using an Android construct called fragments, designers and developers can merge portions of the GUI (screenshots) onto one large screen or split them into individual screens for use on small screens. This can help to reduce the number of interactions a user must perform on a device with a large screen and eliminate wasted space.

If you anticipate your app will someday be used on a tablet device, we strongly recommend you incorporate fragments into your design. By designing custom, reusable fragments for each screen activity at the beginning of the project, you can eliminate the need to create an entirely new layout for a tablet device.

Intents Construct

Android applications typically borrow from other applications already on the device. Using intents you can simplify both the programming requirements for your application and offer simpler, less cluttered screens.

If your application needs to perform a function beyond its core abilities such as opening a photo, looking up a contact, etc., the team should investigate whether a tool that can perform that function already exists in the OS or in a popular third-party application. If so, you can leverage that functionality using intents.

What Are The Lessons Learned?

Android offers specific GUI (screenshots) controls, activities, interactions, layout and re-size options, as well as special constructs like fragments and intents. While on the surface these appear to be things that the design team needs to work with, we contend that the entire team must be immersed in Android to coordinate design, workflow and execution into a single, intuitive application — one that grabs users’ attentions and draws them in to the real value of your product.

Advertisements

I am a software engineer whose has many interests. My current distractions are ontology, mobile device technology, medical bioinformatics, and micro-robotics.

Posted in Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: