Thanks for the tips Nikkelitous, all that advice sounds quite reasonable. I hadn't really thought of the button and tap vs tap thing, great point. And I totally agree about consistency.
I am basically using high level actions as menu items (create, save, edit, delete, next page, last page), and then my app specific stuff as buttons, but I am being consistent (sort of what the built in apps seem to do). Also, I am borrowing the system menu icons for those functions to go even further in terms of consistency. I set my menu "save" icon to "android.R.drawable.ic_menu_save" for example (that's a handy tip if you haven't already tried it, you can reuse the "android" package resources in your own apps, I do this for all the standard actions). I was just curious what others here did, especially the UI gurus. On Oct 3, 7:07 pm, Nikkelitous <[EMAIL PROTECTED]> wrote: > It really depends on the application. Personally, I prefer on screen > buttons to menu buttons in almost all cases when the screen real > estate isn't at a severe premium due to the difficulty of using a > button then using the touch screen. So as long as you have space, I > say put it on the screen. Games and stuff this is obviously > impossible for, so go ahead and put them in the menu in that > situation. Just remember, 1 tap is better than 1 button and 1 tap. > > Now, there are a few exceptions I follow. Anything that is the same > in any activity I put in the menu so that it's consistent across the > UI. In fact, that's the most important rule I can think of: Be > consistent! Don't put save in the menu sometimes and on the screen > sometimes. > > Try to think of common tasks and minimize the difficulty in going > about them. Sometimes it's easier in general to put everything in the > menu. I seriously doubt this is the case for almost all apps as the > menu seems to get cluttered very easily. > > If you do use the menu, PLEASE use common icons so that a user can > navigate it at a glance. Don't use a magnifying glass for file open > that's just going to confuse people and make your app slower and > harder to use. > > On Oct 3, 1:12 pm, Charlie Collins <[EMAIL PROTECTED]> wrote: > > > Every time I make a new screen I find myself debating which buttons > > should be on screen buttons, and which should be menu items, and or > > which should be both. I was wondering what others thing about this. > > Are there general guidelines or logical approaches that people are > > using? I apologize up front if this is a silly question, but it comes > > up again and again in my own head, and I haven't found any > > documentation or direction on it really. > > > I notice that the built in contacts app, for example, has the sort of > > "main" actions like "new contact," "edit contact," "save," "discard," > > etc, as menu items. But it also has "Add Icon" as both a menu item > > and as an on screen button. > > > I personally think it makes the most sense to use the menu for high > > level "actions," so "save" and "add" and so on make sense in the menu. > > But maybe that is subjective? Is it just whatever works best with the > > screen real estate and layout, etc. > > > Seems like the menu is faster/more intuitive if you can use it, but > > with the d-pad all the on screen buttons work too whether or not the > > device is touch capable, and being on screen makes the choices more > > obvious. > > What to the UI gurus and Android devs think are some best practices in > > terms of making button/menu choices? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
