Monday, May 03, 2010

Android App Surgery: "MySettings"

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.

The App: MySettings from JQ Soft

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.
Android Features

I thought the (optional) ongoing notification as a shortcut to the app was clever, and I loved their use of Intents to open specific system preference screens.

What might be nice additions are a Live Wallpaper and a some Widgets.

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.
Posted 5/03/2010 05:09:00 PM
Labels: ,

28 comments:

  1. Love it please keep them coming.
    ReplyDelete
  2. I'm gonna defend exit button. As android developer i totally agree with Reto - back will do it just fine. But "normal" people very often ask "how i exit the app". And since this particular app showed up on the market very early - user pattern were not established. So exit button is totally ok imo. Custom menu - whole other story.
    ReplyDelete
  3. Thanks, Reto, for this review :)
    ReplyDelete
  4. Thanks for doing this, Reto - interesting and useful without being a multi-page teardown that takes forever to read :o) The how-to links for discrete items of functionality are v handy, too. Cheers!
    ReplyDelete
  5. I too am going to defend the exit button. I assume that it kills the app and stops draining power. I want to be able to tell an app to "stop doing anything and just stop using juice."
    ReplyDelete
  6. @christophermahan.com i don't think it does anything special beyond finish(). Therefore it exactly same in terms of functionality as back button. And to be honest i strongly believe that memory management should be left to android. They implemented activity life cycle for a reason and developers should follow platform best practices rather trying to bend the rules.
    But in this case, it just more of UX decision than technical. People over the years got used to that you need to EXIT the app. So there you go. A familiar usage pattern nothing else.
    ReplyDelete
  7. I didn't like exit buttons at first but now I'm ok with them. The reason I changed my mind is that apps running in the background can and do impact foreground performance, either through CPU use or increased memory pressure. In an ideal world we would not have to worry about that, but apparently we don't live in an ideal world.

    So if an app realizes it can't do anything useful in the background and there's no reason to keep it around, why not do a real exit and get it out of the way quickly rather than waiting for Android to heuristically kill it later. That said, maybe this could be accomplished in a cleaner way through some sort of application hint.

    I'd love for there to be absolutely no need for task killer apps, but unfortunately they seem to still be needed (and even recommended by many performance-intensive games and apps).
    ReplyDelete
  8. @Ed If an app knows it can't do anything useful in the background, it should clean up its resources / kill Services / unregister Receivers whenever it is no longer visible (within onStop). Alternatively, the user hitting the back button will kill the Activity, so as long as the app hasn't started any Services that will effectively kill it. What does the exit button offer that the back button doesn't?

    As for task killer apps. In my view, their existence isn't sufficient justification for their necessity.
    ReplyDelete
  9. The 3 arguments in favor of Exit buttons I've seen in the comments here can be summarized by: it's easier than to write the app correctly. Write your app correctly, don't do anything in the background if it's not needed/not the point of the app, and if you need to perform in the background, do so carefully.
    ReplyDelete
  10. Re: Exit buttons; I will straddle the fence on this one in terms of agreeing that in well behaved apps it is not necessary. However the fence-straddler in me also reckons that people still to want to be able to say "Die, app, die!".

    Also for task killers; again, I think their necessity is borne out of misbehaving apps combined with an old fashion desire from developers to be able to send kill commands regardless of the quality of the app.
    ReplyDelete
  11. Re: Exit buttons: As a user, an exit button can be very useful. Therefore, as a developer who wants to provide the best experience for his users, it would be foolish for me to dismiss them.

    Its a user's way to cleanly say "Look, I don't care if you've got pending alarms, server polling etc, I just want you to stop everything!". Unlike with task killers, this at least gives the app a chance to do it all properly.

    Take the twitter app. I guess that it will poll twitter's servers from time to time, but hang on, right now battery juice and bandwidth quota is low so I want to make sure that sort of app is stopped pronto. An Exit button is a natural way to do this for the user. Otherwise, I'm forced to use Task Killers or uninstalling the app.
    ReplyDelete
  12. Another way to look at this is...

    The back button is the user's way of saying "I've finished using your UI".

    The exit button is the user's way of saying "I've finished using your app".

    Most apps would not need an exit button because the UI and the app are usually synonymous.
    ReplyDelete
  13. Ed Burnette: The only app I've seen who truly deserved an exit button, is the CoPilot Live GPS software - and that button might as well just be called "Halt navigation services" or similar, but Exit is shorter. ;)
    ReplyDelete
  14. everybody are debating technical reasons but i think it more UX debate - exit is a commonly used UI component. Average user has no idea that pressing back is pretty much the same and people don't know about Activities and life cycles. Note, i didn't say android user. I said just a user, who throughout the years got trained that to close the app, some thingy with Exit or big cross should be pressed. So in my opinion faking it and provide Exit perfectly acceptable as long as actions that follows are the same as pressing back. Yes it takes one question "how i exit from here?" to educate yourself about backbutton, but why not have an Exit. It comforting to the user to have it. I know company who put a sleep() after their error check function, because user test group didn't feel confident that error check can be done so quickly.
    ReplyDelete
  15. This comment has been removed by the author.
    ReplyDelete
  16. Great review & suggestions Reto!!

    I'm wondering why people aren't talking about the home key though. To me the exit button in Android is the home key and so a specific "exit" menu option/button doesn't seem to have much value.

    To me any clean-up routines should either be in onStop/onPause (as Reto said), or, if it really is necessary to carry it on in the background, in onLowMemory, and leave the OS to decide when and how it should be tidied.

    It's worth remembering that an exiting an application is not a real world "user" experience and only came into the mainstream because computers needed a way of allowing users to tell them when they were finished with an application, and Androids process management makes that a redundant concept.

    Still, I have seen requests for an exit option before, but they mainly came from users on hardware not designed for Android which didn't have a home button available.
    ReplyDelete
  17. A user needs a way to say to the OS "preserve my battery where possible" so that lower priority services (maybe twitter feed updates) are put on hold for a while.

    This might also be done automatically when the battery is low.

    No idea how this can be done at the SDK level but I'm sure its possible.
    ReplyDelete
  18. I agree with Reto and Romain. There is no good reason to have an exit button in Android apps.
    Regarding Twitter clients, feed updates are done ONLY if the user selected this option in the settings. It's his choice.
    A good app always has a way to stop the background services in the settings. There's no need to have an exit button.
    Task killers are just for misbehaving apps (that keep running services in the background, even if the users didn't choose so in the settings). But for this, you already have the ability to kill services in Android 2.1, so they're only helpful for 1.5 and 1.6.
    I know the users expect an exit button... and it's tough for us to make them understand that Android apps do not need one.
    ReplyDelete
  19. @Edi- sometimes you don't want to modify the settings because you only want to temporarily stop background activity.

    In your scenario, the user would have to go through the app to do all the things necessary to stop background processing. How to do this will not always be clear. Then later, when battery levels are not a problem, they would need to go back in and change everything back to how it was.

    "Exit" says it all. Its a clearer contract between user and app.

    Better still would be for the user to be able to suggest to the OS to "take it easy". The OS would then propagate that suggestion to the apps. Apps that don't follow suit could be killed.

    The underlying problem is that the user just doesn't trust the apps so you will always have users wanting to use task killers. The best we can do is give the user as much confidence as possible that their battery life is being looked after and this is best done at the OS level. And yes, 2.1, goes some way in doing this, but I think we need more.
    ReplyDelete
  20. Hi, all again :) We added Exit button, because our users are asked to make this.

    Once we removed the Exit button from MySettings, but many users vote badly for this app (low rating) because of it. By the way, a user has even asked to make a cross (X) in the top-right corner of the application for the closing of the application that it does not not have to press the hardware buttons.
    ReplyDelete
  21. Btw, our Exit button make only finish() (same Back button). Other action we run in onPause()
    ReplyDelete
  22. @JQSoft - Meeting user requests is never a bad thing, and with the Market rating system as it is (i.e. with no developer replies) ignoring them isn't a great idea.

    I think the main problem is user education. They're used to "exiting" applications, so they expect to do it, and when they can't they assume it's a problem with the app.
    ReplyDelete
  23. On the issue of exiting to save power; Maybe we need an onLowPower activity method so developers can deal with low power situations as well as low memory ones (e.g. reducing the frequency of updates, pausing downloads, etc.).
    ReplyDelete
  24. @Al - exactly, but more importantly it would be a Service method since there may well be no activity running at all.

    This would definitely make sense but wouldn't really solve this problem, because the user wouldn't have any confidence the app is being a good power-saving citizen.
    ReplyDelete
  25. I found that some service apps running in the background triggers a lot of garbage collection. It slows down the performance of foreground apps. I'd like to see this being reviewed in the future.
    ReplyDelete
  26. I vote for no exit button.

    Your UI should be obvious enough to turn off and on needed services. A big red / green light, play / stop, for example. Something that makes sense in the context of your application.

    Android apps were meant to be more "web like", so a standard app should do what it needs to display the page and no more, unless it absolutely requires it, like a media player, a feed of some kind, etc.

    As of 2.1, all background tasks require an icon if they don't want to be culled automatically. In this way, you know whether or not the application is fiddling with something in the background.
    ReplyDelete
  27. Most apps would not need an exit button because the UI and the app are usually synonymous.
    ReplyDelete
  28. I just purchased the MySettings App, When does the every 5 sec.Donate stop flashing??? Great App.I bought it 30 minutes ago!.
    ReplyDelete

Subscribe to: Post Comments (Atom)