When I’m tussling with the design of a UI for an Android application, it’s often the case that I’m struggling to find some extra screen-space in at least one activity. So I’m always on the lookout for how other designers and developers have tackled the problem in their applications. Here are three interesting adaptations that I’ve noted as I’ve used my phone.
I use the stock music player to listen to music, audio books and other recordings. I always get a little satisfaction from noticing how the application neatly switches the “Now Playing” control from being a button in portrait orientation into an extra tab in landscape, where vertical screen-space is always at a premium (also - nice attention to detail: gently separating the extra tab from the other standard ones).
I’m a very occasional user of the StreamFurious streaming audio application. But I’ve used it enough to discover this gem.
Audio applications (like the Music app above) that play tracks into which you can ‘seek’, can elide “Stop” and “Pause” since there is no difference in how the track will be resumed: the application will just seek to the position at which play stopped/paused and start playing.
But applications that stream live radio can’t do this as easily. Pausing implies that the application needs to continue running, constantly buffering data from the stream until the user resumes play. Stopping, on the other hand, is generally taken as an indication that the application should cease reading the stream.
StreamFurious avoids having two buttons (one for “Pause” and one for “Stop”) by retaining the regular Play/Pause button and using a long-press during play to fully stop the stream. Perhaps this is a common idiom, but it’s new to me and I find it elegant and intuitive.
Guessing from the approach taken, the developers of the GMail application on Android have particular difficulties with implementing a UI for it. Preserving GMail’s distinctive conversation view has resulted in HTML controls that masquerade as native Android components (I guess a list of web views was just too problematic).
In recent versions of the application, to make it easier for users to follow which email is currently being viewed within a conversation, the email header pops-up over the conversation below at exactly the point where the information would have been hidden by scrolling, and scrolls away at exactly the point where the email message ends. This is an efficient use of space, because the design ensures that the header is only occupying space on-screen at the same time as the email message it relates to (which is also the only thing it ever obscures).
I think this is a really nice touch, and demonstrates the effort that has gone into producing some of these UIs, especially since I have a hunch that the overlay is produced using Android widgets and not HTML, which presumably means careful tweaking of both the HTML and the layout XML to make the switch between both seamless.
The Android Market has its deficiencies. I don’t think anyone would deny that. One of the niggles is that there’s no place to list the changes between application versions.
I think this is very important in Android applications because the limited screen space often necessitates moving access to core application functions into the menu. Users who are already familiar with an application may never discover a new feature that has been added to a menu that they opened once and never since.
Instead of lamenting the Android Market’s inability to display my application changes to users, I decided that the information was important enough to move in-app; in the past I’ve simply logged changes on my website. The design I settled on was to introduce a small notification at the top of my main application activity - about the size of a mobile ad - that appears if there is change information to present to the user. The user can tap the notification to read details about the changes in the latest version.
Not all updates will need explanations, so the user may not receive a notification on every update, and users can cancel a notification without bothering to read it. Accidentally dismissing the notification isn’t much of a concern since on the next update the user can page backwards and see the descriptions of previous changes.
This functionality will be included in the next release of Daisy Garden. I think it works well and I hope users like it; the use of animations to show and hide the notification adds extra bit of polish. And I’ve implemented it as a library project, so I’ll be able to introduce it into my other Android projects.
I think every developer should consider adding something similar to their applications.
I’ve been meaning to post something about the Android Developer Challenge for a good while, but I’ve been so busy recently (architecting a multi-faceted e-commerce system at the moment) that I’ve had no time for anything else. In fact, I was so busy that the results almost passed me by.
Daisy Garden didn’t win. This was not surprising since I’d had an opportunity to judge a number of the applications in entertainment category. It’s not that I felt there were lots of significantly ‘better’ applications, but that so many of the applications were more suited to the challenge. Congratulations to all the winning entrants. My prediction had been for a music app 1,2,3 in my category and I was almost correct (it was a music app 2,3 instead).
But the results aren’t what prompted this post; I’ve been more interested in how the voting has been structured in both challenges, and I’ve had the opportunity to think about it: my entry into the first ADC flopped, then I joined a team that went on to win, this time round my entry made it to the shortlist but didn’t win - so I’ve pretty much run the gamut of possibilities.
I was mildly critical about the structure of the voting after the first ADC. In my opinion, it pretty much amounted to a map-reduce algorithm in which apps were distributed over judges. The ADC2 was essentially similar and introduced bucketing (perhaps ensure variety?) and pre-filtering with a public vote (to ensure the expert judges had a manageable task, I’m sure).
My basic criticism was, and remains, that such a voting scheme hampers people’s capacity to reach a good judgement because it doesn’t provide a medium through which they can influence each other’s evaluations. The judging process essentially atomizes the judges and fails to take advantage of their human strengths. And I think that understanding this has implications for my field of endeavour: creating software.
I think I’m paraphrasing Bjarne Stroustrup here when I say that software design involves balancing lots of subtle and complex considerations, and the best place to do that is inside the brain of a programmer. If one accepts this, there is an implicit assumption that all of the necessary considerations are known (and will fit into one brain*). I believe this perspective explains a lot about why ‘design by committee’ fails: a team of human’s can’t compete with synapses at transmitting and evaluating ideas. It also explains why ‘elite solo programmers’ may often fail: they can form good judgements but usually don’t have all the necessary data.
In trying to avoid the worst weaknesses of these two extremes, I look to encourage good design by:
With this approach I try both to preserve the clarity that solo-design frequently provides and avoid the narrowness that often accompanies it.
Back to the ADC judging. Forming an unqualified analogy between designing software and judging is application is clearly absurd, but there are similarities, and I think that a panel of judges who freely discussed their opinion about each application before recording individual ratings would provide fairer judgements than may have been the case in the Android Developer Challenge. For example, if there were five judges, and one judge knew that the application under consideration was a direct copy of an existing application, he could share that information with the other judges who could factor it into their rating. Without that exchange of information, the more knowledgeable contribution becomes marginalized.
The point is to target two human strengths: information sharing and individual decision making. Of course, the curse is that this approach doesn’t scale, but I’d love to find one that does, because I’m sure I’d learn a lot about designing software from it.
Thanks to Google for hosting and funding the Android Developer Challenges, it’s been fun.
(*) I think this is the simplest gauge of whether a software project will be successful: If the requirements can’t simultaneously fit into one brain then problems are unavoidable.
Now that android devices with different screen resolutions are becoming a reality, I just wanted to share these shots of Daisy Garden at QVGA.
Even though I’ve done no direct work to support QVGA in my applications, it always features in my thinking for the UI. One simple approach is to aim for two things in each activity layout:
You can see how this approach has worked quite well for Daisy Garden; this is the first time I’ve viewed the app at QVGA resolution, and though there’s definitely work to do, all the layouts look redeemable.
I’ve just published an updated design for the Moseycode website. It’s not going to win any Webby’s but it’s an incremental improvement.
With these cosmetic changes in place, I’ll be free to concentrate on filling the site with information and documentation related to Moseycode.
To get this off the ground, I’ve integrated my Moseycode related blog posts (like this one) into the site. But realistically, the site will remain just a shell until I start publishing the application and its source code.
Under the hood, there are a couple of new features:
A media upload facility is now available. Using this it will be possible to customize the appearance of barcodes you publish at the site. But it’s not possible to actually do this at the moment so I wouldn’t bother.
A new API is in place that allows third-party applications to authenticate users and list/publish moseycodes on their behalf. It’s a compact little HTTP based API that accomodates a simple & efficient implementation. When the Moseycode source code is released it will include a helper package for interacting with the API (which is definitely not stable at the moment).
It also features a small CAPTCHA library I wrote because I couldn’t use (or had good reason not to use) any of the available grails CAPTCHA plugins. It’s a bit hard to read at the moment - sorry about that. Naturally, I’ve managed to introduce a couple of bugs too so those might take a couple of days to iron out.
Moseycode logo concept.
Not directly related to yesterday’s algorithmic challenge, just some speculative barcode design work. Colours courtesy of Mary Ann.
Woke up not tired for the first time in a month - that evil flu must be losing its grip. So I had the energy to actually an create an icon for Moseycode, quite how the application has survived development so long without one is a mystery.
How did Moseycode’s threading get so complicated? Inattention?
I couldn’t resist getting diverted this evening by an idea I’ve been turning over in my head for a good while now. Codenamed Moseyplane, the aim is to provide an extendable and reliably trackable surface for mobile augmented reality games.
In this case I’m trying to ensure that every portion of the plane contains multiple rings with a wide distribution of diameters. There’s a long way to go from this initial design. For example I need to tackle identifying locations within the plane in addition to the plane itself.
