Bugzilla – Bug 12898
Implement new button behaviors for text entry
Last modified: 2010-05-27 14:46:03 UTC
This would apply to all devices and all non-touch interfaces (remotes, hardware buttons etc.) The only thing really "new" here is the ff/rew button stuff, but to summarize: - center button (controller), knob press (baby and boom), right (IR remotes) = "enter character" (second press = "submit") - back button (all devices) = delete - rewind button (all devices) = move left (non-destructive) - press-and-hold rewind = move to beginning of string (non-destructive) - ff button (all devices) = move right (non-destructive) - press-and-hold ff = move to end of string (non-destructive) (Note: This does NOT apply to the alarm clock, which will likely be its own "widget.") (Note: this is a cross_platform bug)
While waiting for feedback, to allow alarm input to at least work, I speculatively added the FEW RWD behavior for SP, which affects all input screens. r6629
Matt-- I took away something slightly different from our meeting. I thought it was: * press-and-hold rewind = continuous scroll left (non-destructive) * press-and-hold ff = continuous scroll right (non-destructive)
Dan, the "jump" is more important to support than the "scroll" i think. in a pinch, you can always press rew/ff quickly to get some slower approximation of scroll. But there's no way to "jump" from the end to the beginning of the text string (i.e. to go a full screen "back") without this jumping behavior. Good example is email/password entry, where I don't realize until submitting that i misspelled the email, and decide to go back in order to re-enter the email address.
This is only during setup, right? You don't want to override the FWD and REW buttons while music may be playing, right?
(this is why we badly need a revamped remote control design, since we're constantly having to make decisions like this that are less than ideal, but i digress...) 1. I would basically be ok with making this setup-only. Better than nothing, and most of the times where exact text is crucial is in setup (accounts, wifi network, etc) However: 2. Even if music is playing, if I navigate into a text entry field on purpose, it's a safe assumption, i think, that the user would be more likely to want that functionality (left-right) than ff-rew. the pause and volume controls will still be there in any case. Basically, you can't have it all here. Our remotes, as they are currently designed, are being stretched to the limit here. There will be tradeoffs.
(In reply to comment #4) > This is only during setup, right? You don't want to override the FWD and REW > buttons while music may be playing, right? Taking away fwd and rew is already the global behavior on jive text input, and has been that way for a long time I believe. There were basically cancel and finish.
I think it's a disservice to the user to override a fundamental transport button like fwd or rew to context sensitive for text input. Indeed, text input is so rare and the amount of text that's input is so small, generally, that keeping it as simple as possible is much more important than building a full-fledged text editing mode. If we do find that we need something more sophisticated, I think we should move to a more complex on-screen keyboard that matches the one that's on the touch UI, where the selection rolls over each key.
Let's implement this for setup-only at first, then see how bad it is having the missing functionality post-setup.
Sounds good. On Jul 16, 2009, at 3:47 PM, bugs@bugs.slimdevices.com wrote: > https://bugs-archive.lyrion.org/show_bug.cgi?id=12898 > > > > > > --- Comment #8 from Weldon Matt <mweldon@slimdevices.com> > 2009-07-16 15:47:58 --- > Let's implement this for setup-only at first, then see how bad it is > having the > missing functionality post-setup. > > -- > Configure bugmail: https://bugs-archive.lyrion.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug.
do we really mean setup-only or network key entry only? Setup only is trickier to code.
Also, then I am hearing I should remove the old rew and fwd functionality so that the global transport handling takes over. Is that correct? Also on regular screens, how does one go escape out? For example, "Squeezebox Name" brings up the current name. The only way to cancel is to back back back (which is now delete) which is a bit odd.
Let's think about this for a second. I'm starting to change my mind about which functionality we should test (leaning toward always having rew = back and ff = forward in text forms) If I'm entering a network ID or password, is music really going to playing? Even if it is, I'm about to bork my current connection probably, so is ff/rew really that important to have available? The same goes for email address entry (account login/creation), account password entry, IP address entry (remote login). All of these cases have a low likelihood of currently-playing music, and a high likelihood that any currently-playing music is about to be stopped anyway. What are all the places where we currently have text entry? Off the top of my head, I can think of: SETUP - network name (uncommon case) - network password (common case, can be very long and tedious) - IP addresses, WPS PIN entry (edge cases) - email address (required case) (account creation/login) - password entry (required case) (account creation/login) POST-SETUP - search (pretty common) (various places) - setting alarm clock (this is going away and being "widgetized", shouldn't be part of this conversation) - account login/creation (edge case) - IP address entry (remote login? Can't think of any other cases, but there may be some) - squeezebox name (fairly common) - naming a pandora station, playlist etc in various apps (fairly common case) - network name (uncommon case) - network password (uncommon case, can be very long and tedious) I've probably missed some. The cases where music is somewhat likely to be playing while entering text are: - search - squeezebox name (will rarely be accessed) - naming a pandora station, playlist etc in various apps All the other cases involve something that relates to connectivity with your network/account, where either nothing can be playing by definition, or you're about to bork whatever connection you have that's enabling playback. Also, Tom makes two excellent points: - One of the problems we're trying to solve is being able to exit a text entry form gracefully. Removing the ff-rew functionality for forward-back keeps us from solving that problem. - the ff/rew "takeover" has been in existence for a long time on controller. Have we had any complaints? Any bugs? After re-thinking it, I'd really like to see this solution get implemented, and see if anyone complains about it.
I am strongly in favor of having FF and RW used for text scrolling any time you are doing text editing. It is the most intuitive option. While it would be better not to ever change the button function, if we change it for some text entry but not for other text entry I think this is more confusing.
Tom, let's implement the proposed solution and see what people think. Dean, I wanna hear what you think too! After you play with it!
(In reply to comment #2) > Matt-- > > I took away something slightly different from our meeting. I thought it was: > > * press-and-hold rewind = continuous scroll left (non-destructive) > > * press-and-hold ff = continuous scroll right (non-destructive) Hmmm... I think I might like this idea, lemme sleep on it. It's more intuitive, but is it more useful? Any other opinions?
K sorry for the waffling back-and-forth! Let's still stick with the original proposal from comment#1. Press-and-hold to "scroll through" a string is a snazzy idea, but it's only a minor improvement from just pressing ff or rew quickly, and doesn't do much to help users who are actually trying to exit the screen.
added the FEW RWD behavior for SP in r6629, so lowered priority from P1
Reset priority before triage.
fixed in r6842
Reopened and reassigning to Matt: Were we also talking about putting help text on some part of text input screens to let them know they can cursor, etc?
*** Bug 12728 has been marked as a duplicate of this bug. ***
yes, adding hrs to my queue for help text/strategy for all devices...
Just an FYI that I've been trying these Edit features on as many editable screens as I can find on Baby and it works beautifully. FF/REW are great and function easily and correctly (non-volatile). :) My only suggestion would be to add this great Edit functionality to Edit other existing text fields on Baby. But this would require a Review screen of existing text. Possible examples: - PITA factor = Major: change Encryption (changing encryption key or type of encryption) but keep existing SSID - PITA factor = Minor: change SSID but keep existing encryption type & key - change MySB password, but keep existing login email - change SC login name and/or password
These are marked as CAT, yet that milestone is over now. Please re-target accordingly.
Resolving. bug 13367 is the uber-bug for overall text entry enhancements. *** This bug has been marked as a duplicate of bug 13367 ***
moving current p2 bugs to p3 to make room for moving p1.5 bugs to p2
These bugs have all been marked resolved and belong to a component which is being removed. Therefore they have been moved to the most applicable of the new components.