I think something as common as Button will probably be universal across all devices. But it might be navigated to differently, touch or non-touch, etc.
- Juan T. On Oct 4, 8:26 pm, Charlie Collins <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
