Lucas Pardue

UI Navigation – Android

Up vs. Back or in other terms hierarchy vs. chronology is one of the User Experience aspects touched upon in my post UML: Modelling User Interfaces Part 1 – Hierarchy and Navigation. The Android methodology for UI navigation has received some attention over the years and the largest change to date was brought in with the introduction of the Action Bar as part of Android 3.0+.

Pre-3.0, Navigation would occur as a result of widget interaction (forward nav) and the system Back button or user defined Back widget (backward nav). Post-3.0 the Action Bar now offers an Up button in addition to the previous Navigation methods.

The Up button is used to navigate within an app based on the hierarchical relationships between screens. For instance, if screen A displays a list of items, and selecting an item leads to screen B (which presents that item in more detail), then screen B should offer an Up button that returns to screen A.
If a screen is the topmost one in an app (that is, the app’s home), it should not present an Up button.

The introduction of the Action Bar and the Up navigation method is no news, so why am I posting about it now? The Google documentation of Android Navigation goes to some length to describe and clarify the current situation. I feel the information presented there resonates with some of the points made in my post that I shall explore further

Navigating to screens with multiple entry points

Sometimes a screen doesn’t have a strict position within the app’s hierarchy

Indeed! I wish I had been able to capture this point so saliently. The concept of an always available page runs counter the that of a fixed hierarchy and yet it is a very common use case. Following the advice of the Android documentation, back or up should return the user to where they previously came from, in a tree-like hierarchy this could only be achieved by having the page as a child node of every node. This sets some warning flags regarding duplication.

Changing view within a screen

Changing view options for a screen does not change the behavior of Up or Back: the screen is still in the same place within the app’s hierarchy, and no new navigation history is created.

Obvious? This can be treated as an internal state change. Some actions are clearly an internal change but are they all, this is very much a UX issue and the actions/outcomes should match the user expectations. The decision as to whether to keep the behavior internal or cause a navigational transition is debatable and often an area for user feedback and iteration. One approach would be to look at this from a function/non-functional change perspective – does the action cause a change to the current function or user sequence?

Navigating between sibling screens

When your app supports navigation from a list of items to a detail view of one of those items, it’s often desirable to support direction navigation from that item to another one which precedes or follows it in the list.

This is personally the most interesting point of the article, the concept that navigation between siblings is neither a hierarchical or chronological navigation action. On first site this may be difficult to articulate to a user, designer or implementer, however, in real term usage there are many straight forward use cases e.g. viewing multiple photographs one-by-one in an image gallery, or selecting between songs in a music player. The Android article does highlight where the alternative approach is used and it is a legitimate case. The selection of implementation is therefore quite tricky and should be done to best provide affordance to the user.

Looking at this from a tree-like hierarchy perspective, the notion of sibling-to-sibling node navigation (and the notion that Up or Back should operate independently of the nodes) is something that breaks the rules.

Summary

Hierarchy Navigation on the Android platform was enhanced with the introduction of the Up button in version 3.0. Android documentation provides guidance and clarification on the UI in order to provide the best UX. The documentation provides several examples that resonate with concepts raised in my earlier posts. The main theme of these is that a strict, rigid Hierarchy is not rich enough to articulate the nuances of everyday device and app usage, not convoluted applications but intuitive ones. From the perspective of a tree-like hierarchy, several elements bend or even break fundamental rules and pose the question “Is the Tree fuzzy enough to accommodate me comfortably?”

UML: Aside – Completeness vs Clarity and other CvCs

One of the recurring issues I have experienced with UML, or more generally Model Driven Design is the continual struggle between definition and interpretation. One of the tenants of UML is to abstract upwards towards a level that avoids implementation specifics. However, this introduces the potential for a need of a “Leap of Faith”, something that was discussed my post UML: Modelling User Interfaces Part 1.

In tools that allow a complete forward driven Modelling approach (by this I mean where the model generates code for implementation) the gap between abstraction and implementation must be bridged, generally by propriety extensions, properties or mechanisms. Ignoring some of the practical issues, this seems to work counter to the benefit of the abstraction in the first place, putting a larger burden on the Modeller. However, a counter argument is that these additional decorators offer and capture the bridging formally and explicitly; this could be view as beneficial in comparison to implicit knowledge held withing a group. Whether the Model is the best place to document such information is a topic for another day.

Android Resource and the Eclipse switch Quick Fix

In the process of updating and refactoring an old Android project I unwittingly changed a Project configuration option (the “Is Library” option) that lead to my resource file being generated differently. E.g

Before

public final class R {
public static final class id {
public static final int button1=0x7f090001;
public static final int button2=0x7f090002;
public static final int button3=0x7f090003;
}
}

After

public final class R {
public static final class id {
public static int button1=0x7f090001;
public static int button2=0x7f090002;
public static int button3=0x7f090003;
}
}

A subtle change indeed but one that caused the following compiler error for each line

case expressions must be constant expressions

C and C++ Preprocessor: warp, Clang and GCC

I belatedly came across the news regarding warp, a C and C++ preprocessor written by Walter Bright in a joint project with Facebook. This has been released under the Boost license and is available at https://github.com/facebook/warp.

The Facebook blog makes the following statement with regards to improved efficiency over the GCC preprocessor

Replacing gcc’s preprocessor with warp has led to significant improvements of our end-to-end build times (including linking). Depending on a variety of circumstances, we measured debug build speed improvements ranging from 10% all the way to 40%, all in complex projects with massive codebases and many dependencies

The AMA on Reddit and the comments on Hacker News have some interesting commentary on the performance claims, as always with performance measurement and comparison this is a difficult field to navigate.

I am reminded of a recent bottleneck I experienced in the build process of a medium sized project using GCC for an ARM target. The investigation identified the major culprit to be the preprocessing stage, specifically the Search Path for header files was very long. A long Search Path is not something that I would have immediately assumed would be the cause of the bottleneck but other lines of investigation were strongly indicating this was truly the cause.

UML: Modelling User Interfaces Part 1 – Hierarchy and Navigation

This is the first post in a series that looks at the modelling of User Interface (UI) related software using UML.

The main purpose of the post is to explore how we effectively model the navigation of a tree-like hierarchy, especially when considering the premise “In a tree structure there is one and only one path from any point to any other point”.

The tl;dr is that UML does not necessarily have the ability to represent UI concepts of hierarchy and navigation effectively.

Introduction

In the design stages of UI, whether it be be a Desktop application, Mobile app or Web site a useful tool for understanding and modelling the interaction is to define a logical hierarchy.

The details of such hierarchies is domain dependent and much has been written on the topic, which I shall not attempt to retread. Broadly speaking, we would attempt to create categories and align “Pages” or “Views” to these categories, usually resulting in a tree structure. There are a few approaches to describing hierarchies but the more commonly used examples are

Text-based “Outline”- e.g. a list using indentation and/or bullets to represent the hierarchy
Graphical “Node linked” – e.g a graph of connected nodes with a single path from one node to another

In narrow-scope or simple applications the scope of the hierarchy will be small, however as complexity increases the breadth and depth will increase also. A typical problem encountered here will be deciding the most appropriate place for placing a node – this has a large effect on the User Experience (UX) as the location should match the user expectation; a task made harder when catering for multiple personas, cultures or languages. This part of the process will often result in compromises such as bending rules (categorisation rules) or duplication.

The UI design process must consider User tasks or workflows and an easy trap to fall into is to concentrate these within a single “Page” or “View”, indeed this may be the most appropriate approach. However, once the complexity begins to increase there comes an overload of information and a degradation of the UX, often leading to a separation of concerns and a build out of the hierarchy.

However as a hierarchy begins to grow, the interaction sequences may get more complicated and it can become more difficult to model user tasks or the overall UX of the application. The sequences must consider the navigation of the hierarchy and herein we explore that problem