Tuesday, June 25, 2013

Android: The usability papercut of the paste popup

Introduction

Since Android gingerbread (v. 2.3), Google enhanced the copy/paste functionality by pressing and holding a selected word to copy text to the clipboard[1]. In more recent Android versions the copy and paste functionality is shown in a popup window rather than a context menu as known in gingerbread.

This post is about the definition of an usability papercut that concerns the paste popup window. It is divided into two sections. In the first section I will describe a scenario and in the second section I will talk and discuss about the papercut itself.

Scenario

To illustrate the problem, I wrote a simple application that shows an EditText widget with some entered text as seen in Figure 1.

Figure 1: EditText with entered sample text.


To let the paste popup appear, one just do a press hold on the text. This triggers two operations: a) the placement of the caret and b) the appearance of the popup. In figure 2 it is shown that the popup window is located right above the caret and the press position (white circle).

Figure 2: Appearance of the paste/replace popup.

The papercut

The papercut happens when there is no text in the EditText widget. As seen in figure 3 the touch-hold position and the popup window are "dislocated" in comparison to figure 2.

Figure 3: The papercut in action.

To argue against this dislocation, one can say that the location of the popup follows the law of proximity, which says that "things that are close together as seen as belonging together"[2]. As seen in figure 2 and 3 the paste (and replace) popup appears right above the caret indicating the user that there is a possibility to paste (or replace) some text right where the caret is positioned. However in figure 3 the paste popup appears at an unexpected location, so that one has to visually search for the popup window. The solution I am proposing is to place the popup window right above the pressed hold position of the finger when there is no entered text.

To justify the argument of dislocation, I tried to apply FFitt's Law[2] (an expansion of Fitt's law for finger touch input) and to calculate the mean time to complete the paste task with and without entered text. However this was not possible, because the popup window is not available in the android view hierarchy of the sample app as seen in figure 4.

Figure 4: View hierarchy of the sample app. The red frame highligts the curent view of the sample app. The paste popup is not part of the view hierarchy.




The paste functionality is located in the TextView class (from which the EditText class inherits). In detail, the paste function and management of positioning the caret etc. is outsourced into the Editor class. This class uses internal android classes (e.g. classes that are located in the com.android.internal.* package), which makes it even more difficult to change the popup location as suggested above.

Conclusion

In this post I introduced an usability papercut concerning the paste popup. I wrote a simple application that illustrates the problem. Moreover did I discuss why and how this is a papercut with a suggestion on how to fix it. An attempt on how fix this in code has been introduced as well. I found out that a popup window cannot be captured with the hierarchyviewer, since it is not a part of the view tree. It would be interesting to see a user interface component that is like the popup window but also part of the view hierarchy.

References

[1] Android Gingerbread Platform Hightlights. Available: http://developer.android.com/about/versions/android-2.3-highlights.html. Last accessed 25th June 2013.
[2] Bi, Xiaojun and Li, Yang and Zhai, Shumin. (2013). FFitts law: modeling finger touch with fitts' law. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. CHI '13 , 1363-1372.
[3] Boeree, George. (2009). Perception and Interaction. Available: http://webspace.ship.edu/cgboer/genpsyperception.html. Last accessed 25th June 2013.