excellent advice, thanks: > So back to the whole issue of menu icons... if there are standard menu > icons you want to use, I recommend just copying them out of the platform > source and into your app, so you can make sure that the other icons you > design remain consistent with them.
the old UI consistency problem is one of choice vs. lack of choice, or more-choice vs. less-choice. in general the less-choice approach works well for a little while then often breaks down or loses to a competing more-choice approach. I for one prefer the more-choice approach, coupled with some guidance for the current recommended choices and some care for some consistency. Over the long term, e.g., decades, the best or preferred UI techniques are determined by the users. The problem of choices is mostly only for the new platforms, such as Android with its very open, small&large devices, lots of internal components, touch-based, voice-activated (eventually) platform. It will take a few years but I expect that new dominant UI techniques will emerge from Android and similar devices. It's a lot of fun to be in the phase where anyone can try to invent a new UI technique. So for now, lets have freedom of choices and go for it, invent. serge On Mar 21, 11:51 pm, Dianne Hackborn <hack...@android.com> wrote: > Hi Mark, > > I think there are two things being mixed here: you mention a number of times > the basic user interaction model of not having a "close" menu item, but seem > to be equating that with not having a standard look for menu icons across > all applications. > > To me, these are really different things. > > In Android, as you note I have said before, we discourage applications from > having a close command. This is part of the basic interaction of the > device, just like we also encourage an edit-in-place model, and other > aspects about how applications behave. This should be as consistent as > possible across applications, and we do need to have these more clearly > described in UI guidelines. > > But when it comes to the look of menu items... well, at the end of the day, > trying to make these consistent across all applications on even most Android > devices just isn't going to happen. The first thing a lot of device > manufacturers will want to do is customize the look of the stock UI to give > it their own look, branding, etc. I think we can expect to see Android > devices in the future with quite different looks than the standard open > source platform, and I really don't see anything wrong with that. > > It does mean, however, that we probably made a mistake in putting any > standard menu icon resources in the platform. The fact is, it is just going > to be impossible to use these with a good result except in the unlikely > situation where you only have menu items for which there is a platform > icon. Otherwise, on some number of devices, your application is going to > end up with radically different appearing icons in its menus. > > For example, I am sure some manufacturers are going to have menu icons that > use colors, because the stock Android UI is admittedly very low-key in its > use of color and other devices are going to want to be much more striking. > So there you'll end up with your own icons being all laid-back and > grayscale, sprinkled with a few stock colorful icons. Yuck. > > I don't see how we can avoid living with the user seeing different UI looks > in different applications. Heck, a good chunk of serious app developers > -want- to give their app its own distinctive look, and I really can't fault > them for it. But as long as the applications are internally visually > consistent, and the *user interaction* is consitent across all applications, > this seems like a perfectly acceptable situation. > > Btw, for this reason I also recommend, if someone finds they want to do > something like customize the look of a button or something, that they > actually go and just create their own look for their UI. Otherwise you'll > end up with a similar problem: if you make this special button have a look > that matches the stock Android UI buttons and other widgets, when you run on > a device that has its own look for these your internal UI will end up with > an inconsistent look. (And fwiw, Cupcake has slight changes to a lot of the > visual elements, so you'll actually see this problem crop up just by running > on the newer platform.) > > So back to the whole issue of menu icons... if there are standard menu > icons you want to use, I recommend just copying them out of the platform > source and into your app, so you can make sure that the other icons you > design remain consistent with them. > > On Sat, Mar 21, 2009 at 8:09 PM, Mark Murphy <mmur...@commonsware.com>wrote: > > > > > > > Marco Nelissen wrote: > > > On the other hand, you might be better off using your own copy of the > > > system icons. For example, if you were to use system icons plus some > > > additional ones in the same style that you made yourself, your > > > application's menus will look weird if the system icons are > > > redesigned. > > > Android has been beaten up in the past for apps not having a consistent > > look and feel, particularly when compared with iPhone. It is likely to > > get beaten up for it in the future. > > > While having apps with disparate UIs is part-and-parcel of having an > > open platform, it might be nice if there was at least some measure of > > guidance for how application developers *can* strive for a consistent > > look and feel if they so choose. In other words, let developers have the > > freedom to follow a lead as much as they have the freedom to chart their > > own course. > > > Either a sporadically-consistent look and feel is a goal of the core > > Android team, or it isn't. Speaking as a developer, it would be nice to > > know which philosophy the core Android team is adopting. > > > If the core Android team would like a consistent look and feel from apps > > (e.g., Ms. Hackborn's repeated insistence that "close" menu items are > > evil), then you're going to have to throw us a bone now and again with > > advice on how to maintain a consistent look and feel with the stock > > Android apps. I would think rules for how to have consistent menu icons > > might be part of that. > > > If, on the other hand, the core Android team is not terribly interested > > in UI look fidelity, or feels it's not an issue because of re-branding > > that device manufacturers might do, that's perfectly fine. However, if > > the UI critics continue harping on the issue, please don't blame the > > developer community for not following non-existent style guidance. > > > The worst answer is no answer at all, where we are left with conflicting > > guidance: the core Android team sometimes berating us for not slavishly > > following the stock apps design (e.g., not having "close" menu items) > > and sometimes saying that our efforts to follow the stock apps design > > may be fruitless (e.g., you might change the icon style out from under us). > > > --------------------- > > > Also, with specific respect to the icons, bear in mind that we're > > working under a 70MB hard cap, and so every KB we can slice off our apps > > makes it that much more likely somebody will keep our apps around, > > rather than discarding them to free up space. Hence, the interest in > > avoiding redundant icons. > > > -- > > Mark Murphy (a Commons Guy) > >http://commonsware.com > > _The Busy Coder's Guide to Android Development_ Version 2.0 Available! > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
