It amazes me that I haven't seen soft keys. When it comes to usability I feel like having to press 8 buttons to add a new contact is better than having to press 20 buttons if the number of physical buttons on the hardware is constant.
This Menu key doesn't strike me as a great interface. If I have a list of 10 emails. And I want to delete 5 of them and mark the other 5 as read. Say the context sensitive menu for each email only has two options, one is delete and one is toggle mark as read / unread. Let's say that delete is in the default position. Then it will take a menu key press then a enter key press to delete an email. You could argue that a shortcut key like '7' or '3' could be used but that will make every application impossible to remember how to use, and different apps will use different shortcuts for delete. It seems like a nightmare. Then marking emails as unread is an even larger nightmare. One menu key press, one down key press, then the ok button press per email. The functions people are going to be using the most are going to be very slow without softkeys. What I think Android should do is when you construct a context sensitive menu, you should be able to tag the most important items with some kind of shortcut precedence which helps map the function onto a softkey or shortcut key if available on the device. Then devices without any soft keys will still have access to everything, but devices with soft keys will be able to have users fly through apps. Some phones could have 3 softkeys, others could have 2. If the developer leaves out the flag, then the top X menu items are used for the X soft keys. The only issue I see with my idea is that I'm guessing that the context sensitive menus are only generated lazily when the key is pressed. So as you move your cursor over the emails in a list of emails the menu that says "mark as read" or "mark as unread" depending on the read status of an email isn't actually calculated until the user hits the menu key. So in order to get around this, the generate menu would have to be called on every change of what the cursor is selecting, and possibly a second time if the button is actually pressed. For phones that are decoding video in real time, it doesn't seem like a big deal, but I know how code is and how this could be a potential slowdown. Maybe Google already has softkey support and my ability to read the SDK doc and peruse the SDK is just lacking. But if the final Android UI is released and it can't support softkeys I think it's going to be a huge mistake. So many phones on the market use softkeys because they are really a great user interface device. What does everyone think? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" 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-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
