On Sat, Jul 14, 2012 at 8:51 PM, Mark Murphy <[email protected]> wrote: > Now, if all finger paint apps for children on Android got low ratings > and had on-screen controls, I would at least entertain the notion that > correlation might indicate causality, and the on-screen controls were > the source of the low ratings. However, a quick glance at the search > results and examining the screenshots indicate that there are several > finger paint apps for children with on-screen controls *and* 4-star > ratings (and on 1000+ ratings, not just a handful). To claim that > on-screen controls are somehow impractical for finger paint > applications for children, therefore, seems to be inaccurate
Who's to say how many 4-star ratings / downloads would a finger paint app have that didn't have to clutter the screen? Sadly, Android has a reputation for low-quality apps. People will sometimes give a good rating just because an app to do such and such exists, no matter how badly it does it. Giving the user a good feeling about using a device/app is a very tricky area. I worked for the official games industry for 7 years and I saw the attention these guys tend to give controls. While not every little Android app has to be as fine tuned as a twitch shooter, every app should feel good - something Apple is famous for understanding. You can't say that a painting app is good enough just because there are still a bunch of pixels left for the actual painting after we've rendered our UIs. > and creating an intentionally future-resistant finger paint application > for children just to avoid on-screen controls is not wise. Again, that's for people who design/make a particular app to decide. Very very few apps released this month will still get new downloads a year from now, at least in entertainment which is what I'm interested in, so risking that an OS version 3 years from now will break the app might be a very sound business decision if the risk brings in substantial benefits during the projected life cycle of the app. > Furthermore, it is ludicrous to think that a child will somehow tap on > some on-screen control, yet not tap on a menu affordance in the system > bar nor click on a dedicated off-screen MENU button. If anything, a > well-designed on-screen control could be *less likely* to be > accidentally invoked than would legacy menu affordances, by making it > slightly more challenging to trigger than just a tap (e.g., physically > smaller, tap-and-hold, tap-and-slide). While it is impossible to > prevent a child from doing any of these things, you actually have > control over an on-screen mechanism that you do not have for anything > else and therefore can take steps to reduce the odds. You might well be right on this, however the decision to leave out the Menu button is of a much much broader consequence than just finger paint apps for children. There are apps for which an off-screen button is just *the* simple and natural solution, everything else is kludgy work-around. If there were no such apps at the moment, they would appear in the future. Saying "no Menu button should be enough for everyone" reminds a similar well-known statement that concerned 640kB of memory - supporting such claims you run an acute risk of getting on the wrong side of history. :-) > If the issue is aesthetics, make the on-screen control invisible, > perhaps appearing after a period of inactivity or after the screen has > turned off and back on. You could even make the on-screen control > simply be not there except after inactivity or a screen off/on cycle, > so that a parent can readily get to the control after retrieving the > device from the child. Or find other ways of solving the problems > formerly handled by an in-app menu (e.g., auto-save after inactivity, > so the parent does not need to explicitly save from the paint activity > but can go into a separate activity to review saved pictures and > remove them). This all depends strongly on the actual application. Based on my experience, you can't make any blanket statements like this. As stated above, this is not just about kids' paint apps - it's not even just about paint apps in general, although if you consider something like a simplified Photoshop in your phone, you start seeing immediately that none of what you propose would work. Although I'm no artist by profession, I took drawing/painting classes for couple of years and I can draw, sort of - and my bro is an artist. I can tell you a painting app that kept UI stuck on-screen all the time would likely be a no-go. The canvas belongs to the artist, it's just ridiculous to make people "paint around" your UI. Also, when you're looking at what you've done so far, any UI would be annoying as hell. (I sat for some weeks next to concept artists a while ago (oh the joys of open-space offices :-( ) and these guys even go to full-screen all the time to gauge their work, often several times a minute, although switching back and forth between windowed and full-screen is far from instantaneous.) Also, if you consider the workflow using such an app, you realise that the user has to switch between the painting and the UI (colour and brush choosers) all the time, every couple of seconds. That eliminates any time-out or inactivity based solutions - a serious user will probably want to keep the thumb on the off-screen menu button all the time and will press it every couple of seconds. For these types, not even a gesture would cut it - even if you were able to find one which I seriously doubt as anything you do on the screen is indistinguishable from the painting input. I wrote way more already than I meant to so I'll cut it now. My point is that every entertainment app's first and foremost concern is to feel good (I imagine this is likely important even for productivity apps) and you'd be crazy to mess with this. Just because you can scratch your left ear with your right hand, it doesn't mean it's good or natural and that users won't uninstall your app if you make them do such things. > Now, I cannot speak for your app, because I don't know what it is. > Perhaps you could consider submitting it for the developer relations > Friday App Review thing, specifically asking for ideas for how to > address your variant on this issue, and try to get Googly input on the > matter that way. We'll only be releasing next month, or September. We will submit our app for the Friday Review. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
