I think a "button" being "attached" to the UI is a good guideline too. For the most part that's how I use them, and then I put what I call "high level" actions in the menu (stuff not directly attached to a UI element).
Another thought, though the menu is a "button and a tap," and that's arguably better than just a button, what about devices that don't have touch? That's probably the exception, rather than the rule, granted, but if they don't have touch an on screen button becomes a "d-pad around and a button." I guess I shouldn't optimize prematurely for that, but it just seems like the "menu" is familiar and intuitive, and will work more seamlessly across multiple device types. (Or maybe with future versions of the API we will be able to detect whether or not the device is touch capable and swap out the setup based on that?) On Oct 3, 9:46 pm, jtaylor <[EMAIL PROTECTED]> wrote: > A button is fundamentally attached to the UI. A "Go" search button is > attached to a textbox, or a "start" and "stop" in a stopwatch defines > the UI. Otherwise it's a menu item. > > - Juan T. > > On Oct 3, 3: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 -~----------~----~----~----~------~----~------~--~---
