In another life, a touch over 4 years ago, a job opening on the Google jobs site caused me to speculate on the imminent arrival of GoogleTV - a cooperation between Google and hardware manufacturers that would bring the power of Google search to your TV viewing experience.
A regular TV that I can write code for? That sends me to my happy place.
Let me start of by saying that I'm not a part of the GoogleTV team. I don't have any insights into their plans beyond what they talked about during the day 2 I/O keynote.
The focus of that keynote was GoogleTV as a platform for the web - letting you consume web video, use apps, and surf websites on your TV. Obviously that will be cool, but web on TV isn't what excites me.
What is? Android. Being able to write apps is what got me interested in computers to begin with. I didn't own a smartphone until Android provided a free / open opportunity to write apps for mobiles. Now GoogleTV promises to deliver a platform me to to code for my TV.
GoogleTV is an opportunity to develop apps on one of the most widely used content consumption platforms on the planet.
Over the last few years we've seen apps transform mobile phones into platforms for innovation - dramatically changing the way people use their phones. GoogleTV could do the same thing for the television.
During the keynote we saw an app that added real-time translated subtitles. Seriously. How cool is that?
Imagine the opportunities that gives you as a developer, particularly when combined with Cloud to Device Messaging? Shazam listening to your movie (in the background) to compile a soundtrack. A click of the remote can add the ingredients from a cooking show straight to your Ocado basket. Pandora (or Spotify) can let your TV play a collaborative playlist.
That's not to mention the immersive experience for apps that already exist for Android. News, shopping, music, picture galleries, restaurant guides - and perhaps most importantly - games.
I particularly like the idea of using my GoogleTV in combination with my Android handset.
In my experience, watching TV is communal. Rest assured, the first time someone interrupts my movie by loading Shazam or switches the playoffs into picture-in-picture to check the box score on the browser they will experience my displeasure by way of a shoe to the side of the head.
That's where C2DM and background services come in. Apps can run silently in the background, waiting for me to "pull" (or push) information from / to the TV to / from my Android device.
It's up to us to create innovative experiences that make people change the way they experience TV.
Just as great apps and mobile websites have driven a transition towards internet connected smartphones – a different brand of apps and TV websites can drive users towards internet connected smart TVs.
So I have two questions:
What's more exciting for you: Web on TV or Android apps for TV?
What apps (web or Android) are you going to create?
A couple of weeks ago I published my first Android App Surgery, a technical review of MySettings from JQSoft. One of my UX suggestions was that they drop the "Exit" menu item. This turned out to be more controversial than I expected and soon dominated the discussion in the comments.
So, when should your app include an exit button?
The Short Answer
Never.
The Long Answer
Your app doesn't need an exit button. It really doesn't. Arguments to the contrary can generally be summarized as:
Users expect it.
It's a way to let users say "stop doing everything and stop consuming juice".
Do Users Really Want It?
Let me posit this assertion: no they don't.
Of the apps that ship with the device (Gmail, Contacts, Maps, Gallery, etc.) exactly none of them include an exit button, and most users are comfortable with that. Nonetheless many developers are adamant, "I added it after users demanded it!".
Fair enough, so why do some users demand an exit button? How do they cope with the bundled apps without an exit button? In my experience what they really want is:
An unambiguous way to guarantee that an app will stop consuming resources (battery, CPU cycles, data transfer, etc).
The Goggles Do Nothing!
Many users perceive that an exit button implements this requirement and ask for it to be added. Developers, looking to please their users, obligingly add one. Shortly thereafter they both fail.
In most cases the exit button simply calls Activity.finish. This is exactly equivalent to hitting the back button. Exactly. Services keep running and polling keeps happening. Users may think they've killed the app but they haven't, and soon they'll be even more annoyed.
Exit behavior is now ambiguous. Should your exit button just close the Activity, or should it also stop all associated Services, Receivers, and Alarms? What should back do? What happens if they hit home instead? What happens if your app has a widget? Should the exit button stop that from updating too?
The solution is to make the back button behave as you'd expect the exit button to. Better yet, simply stop consuming resources whenever the app isn't visible.
Users: Consider this. If an app needs an exit button because the back button doesn't properly manage resource use, what do you think the chances are that this exit button will be implemented properly?
Kill Everything When Not in Use
As soon as an app isn't visible its onStop handler is fired, as soon as it's not the foreground Activity onPause is triggered. This happens no matter what the circumstance - including hitting the back or home buttons or selecting a notification.
At this point (ideally within onPause) you should behave as though your user has hit exit. Location and Sensor Listeners should be removed, Services stopped and unbound, and Intent Receivers unregistered.
Once your app moves back to the foreground - triggering onStart and onResume - you hook everything back up.
"Sure," you're thinking, "but what about apps that need to run in the background?"
Foreground Services and Ongoing Notifications
Some applications, such as turn-by-turn navigation and music players, need to run (and use resources like GPS) while invisible. This is generally achieved using a foreground Service. It's also the only reason for creating a foreground Service.
Users should always know if such a Service is running, and be provided with a simple way of unambiguously turning it off when it is. In navigation there's an "exit navigation" menu item. Pausing playback in a music player is enough to kill the playback Service. In both cases ongoing notifications provide a simple shortcut to the app, where you can easily stop the Service.
As far as the user is concerned, if the app isn't visible and there's no notification icon it's not consuming resources. If there's an icon, it's running in the background and I can click the notification to go turn it off.
Background Services and Polling
Some applications (such as News & Weather) need to occasionally run in the background to get updates. Whenever possible use inexact repeating Alarms to schedule your updates, and then kill your service as soon as the update is complete.
This will help with resource use, but is still only half the answer. How can a user demand the app stop using resources completely?
What's the easiest way for me to prevent every app from transferring data?
Settings > Accounts & sync > Background data
Unchecking this should ensure that no app send or receive data while it's not visible. However: This needs to be enforced at an application level - so if this comes as a surprise to you have a fix to implement and an update to go push.
Go ahead, I'll wait.
Offer Users Options
Provided the user is cool with background updates in general, you need to let them adjust the frequency - or disable them - for your app. Be conservative by default. If users aren't getting updates as quickly as they want they'll look for a way to increase the frequency.
Be Adaptive
A Twitter discussion from this post resulted in a suggestion that "Android should offer a way to listen for low battery so that an app can be more conservative with it's use of resources." Register a Broadcast Receiver and thou shalt receive.
You can also monitor for things like connectivity status and type, so you can disable updates when there's no data connection, or modify the frequency based on the connection type.
In each case it's always good practice to offer these tweaks as user configurable options.
Conclusion
If you build an application that's predictable, configurable, and unambiguous your users won't ask for an exit button. The first time they see an unknown background Service that's been running for an hour, or the GPS icon unexpectedly starts flashing, or the device gets hot while in their pocket they're going to get narky.
Next on my hit list: Splash screens, task killers, and modal "loading" dialogs.
Unlike last week's app MySettings, which provided shortcuts to existing functionality, AndCam3d offers something entirely new. Using a SurfaceView to show a live camera preview, it allows you to take multiple photos from different positions - using them to construct 3D images.
There's a particular UX challenge associated with introducing a user to novel functionality while keeping it simple, intuitive, and easy to use.
Unlike traditional software, it's unlikely that your users will know anything about your app beyond the title and the description from the Market. So when introducing a new workflow users need to be able to get started quickly, before they give up and claim it "doesn't work".
AndCam3d does this well by displaying up a set of instructions (with images!) the first time the app is run, an approach similar to that used by Google Goggles. In this instance Dialogs are used, overlaying the instructions over the camera preview. Personally, I feel that Activities might be a better fit, and have these additional observations on the instruction screens:
Having the camera on and displaying a preview in the background while I'm reading the instructions causes the app to take longer to start, and drains battery while I'm reading the instructions.
Using Dialogs over a landscape-only Activity restricts me to reading the instructions in landscape mode.
Consider renaming the "cancel" button to "continue" (or similar). You're dismissing the instructions, not canceling an action.
There are links within the instructions to websites - use Linkify to make them clickable!
In Windows applications an ellipsis (...) at the end of a menu item means "opens a dialog". In mobile apps this isn't a well established metaphor. I'd suggest using an arrow, such as the one used in the system settings to indicate a dialog or new Activity.
I really like the UI for taking photographs.
Having the two stateful eyeball buttons in the bottom left and right corners is an intuitive way to guide user action. I think it could be even better with the following minor tweaks:
When taking my first picture I would have appreciated more guidance. A tutorial like on-screen guide ("click here to take the left-hand picture", "now click here to take the right side", "now click here to compose the stereograph!") - for the first picture only - would have helped me get up to speed more quickly.
The eyeball icons (particularly the hands) aren't high-res enough to look good on the Nexus One.
This app is new, but the basic action (taking a photograph) is familiar. I like the way the new functionality has been incorporated, but I'd love to see some of the UX from standard camera app integrated here. The good news? The camera app is open source, so you can totally steal this stuff:
I'd like to review of each image I create, and an onscreen icon link to the last image I constructed. Clicking it should display the last image so that I can evaluate and manage it. Using the current UI it wasn't obvious to me where my new stereographic image had gone.
Like the camera app, I'd like to see the "Share" and "Send" menu items moved to the (new) image preview Activity. Neither of these verbs make sense without the context of an image.
The "Share" menu item links to a custom "share via Flickr" dialog. I'd love to see share use the standard sharing Intent (annoyingly named Send) based on the last / current image. To include the Flickr sharing, I'd create an Intent Filter to listen for the Send Intent to enable your app to share any image via Flickr, not just the stereograms I create.
Finally, it's great to see the standard Menu system in action, and the Preference Screen too -- especially the use of the standard icons for preferences and help. Without being a pedant, I'd suggest being even more consistent with the system defaults by:
Sticking to greyscale images for menu icons.
Renaming "Preferences" to the more commonly used "Settings".
Android Features
It's a great app, and there are a couple of pretty cool Android features you might want to consider to make it sparkle a little more uniquely.
Live Wallpaper. Why not allow users to set their latest wigglegram as a wallpaper? Live Wallpapers are dynamic, so you could easily create one that would quickly switch between two images to display a wigglegram.
Camera Parameters. Android 2.0 supports modifying camera settings and effects. It would be great if it allowed users to set some camera parameters before taking each picture.
I did notice that on the Nexus One it requests an invalid camera preview size. To avoid potential hardware-related failures, always check to see which preview sizes are valid before setting one.
Get Your App Reviewed!
If you'd like to see your app reviewed, you can self-nominate at the moderator site. You can also go there to vote for which app you'd like to see reviewed.
This post is the first of what will (hopefully) become a regular series of Android App Surgeries. You can vote for which app I should review next, or nominate your own app for review on the Android App Surgery Moderator page.
As an Android Developer Advocate at Google I work with developers, helping them get the most out of Android so they can provide their users with the best experience. An important part of that is using apps, figuring out what they do well, what they could do better, and what could really make them sparkle.
A lot of apps make similar mistakes (and leave out the same functionality). Last Wednesday I wondered aloud on Twitter if sharing my opinion with a wider group might be useful. The response led me to create this moderator page for people to nominate their apps for me to review publicly.
The goal is to highlight Android best practices for you guys to use in your own apps -- more of a code review than a book review (though without seeing any code). I won't be giving ratings out of 5, describing the app in detail, and telling you why you should (or shouldn't) install it. I will be sharing my opinion on how the User Experience (UX) could be improved, which additional Android features could be added, and how stability / performance / battery life could by optimized.
It should go without saying that while I'm a Google employee, the opinions and suggestions made on this site are my own, and don't necessarily reflect the opinion of my employer. Also, they're my opinions - I'd love to see if other Android users agree with my thoughts.
MySettings is a relatively simple app that displays a single screen of shortcuts to some of the most commonly used system settings and toggles.
I’m actually really glad this was one of the most popular nominations last week because it lets me talk about some common UX stuff that I'd like to cover.
User Experience
The overall UX is pretty good - the layout is simple and intuitive, it looks good and works well in both landscape and portrait orientations on both HVGA and WVGA devices. In particular I liked that it featured:
optimized layouts for landscape and portrait views (how-to).
screen size and resolution independence with optimized high-res assets (how-to).
support for trackball navigation (hopefully using StateListDrawables).
A PreferenceScreen to implement "standard" application preference screens.
Like a lot of apps they've implemented some custom UI behaviour.
One of the beauties of Android is the freedom to do whatever you like when it comes to UX, but with freedom comes risks.
The app is presented in a partially transparent floating window. That's pretty unusual and I found it a little off-putting. I've seen this before, but more commonly only when the app is launched from a widget.
The custom menu. Pressing the menu button brings up a menu, but rather than the standard menu mechanism they've implemented a totally custom UI. This introduces some potential UX issues:
It's unexpected and unfamiliar. I know what to expect when I hit menu, a custom menu makes me stop and think about what I'm looking at and how to use it.
It doesn't include the text labels I'm expecting, and it doesn't use the standard icons I'm expecting (particularly for accessing settings).
It doesn't support trackball navigation.
The regular menu is modal, this one isn't.
The menu has an "Exit" Button. Thanks to the Android application lifecycle there's no need for it - pressing "Back" will exit the app just as effectively.
The "About" dialogue doesn't derive from Dialog and pressing back exits the app rather than closing the dialogue. An alternative is to use the AlertDialog and completely replace its UI. It's also good practice to let the Activity handle the Dialog lifecycle.
The standard behavior for a long-press on Android is to display a ContextMenu. In this app a long-press performs an alternative action (opening a contextual settings screen). While useful, overloading an existing UI metaphor is risky.
Enabling or disabling WiFi and Bluetooth doesn't provide any feedback on what's happening. They could use Toasts to provide updates. The system broadcasts Intents that announce changes to both WiFi and Bluetooth device state.
A Live Wallpaper is fully dynamic and interactive, so you could implement the entire UI as one, though with homescreen real-estate being crowded as it is, a widget might be better.
I'd love to see them include a widget that looks just like one of the settings buttons. It could use a configuration Activity that lets users select which of the settings buttons they'd like it to represent. Then you could add multiple, different, settings shortcut buttons to the homescreen.
Stability / Performance / Risks
The app stability is great (I got no crashes) and it's nice to see that no unnecessary Services are being created.
One thing that worried me a little is that the app is directly toggling some system settings. Earlier releases have moved some of these toggles (notably GPS) into the read-only secure settings table. It might be worth confirming the settings are directly modifiable, then falling back to open the right page in the System Settings if they aren't.
Hopefully you guys found that useful
Later this week I'm going to take a look at AndCam3D. If you'd like to see your app reviewed, you can self-nominate at the moderator site. You can also go there to vote for which app you'd like to see reviewed.
If I get enough interest, and have the time, I'll try and do these on a semi-regular basis.
I'm Reto Meier, I work for Google as the Tech Lead on the Android Developer Relations team. I'm also the author of Professional Android 4th Edition.
This blog covers technology and programming - particularly Android - but this is my personal blog. The views expressed on these pages are mine alone and not those of my employer.
