997447 - Modify EditText to shrink hint when text is not empty

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Brian Nicholson (:bnicholson)]

The hint on EditTexts isn't very user-friendly since it disappears if the EditText isn't empty. This is especially true when showing a form that has pre-filled text fields (e.g., Edit Bookmark), and the user has to figure out what they're editing based on the context of the field.

We don't have too many EditTexts in our existing UI, so this isn't a big problem. With autofill support (bug 946022), however, we'll want a clean way to show many form inputs. Permanent labels next to/on top of each field take up a lot of space and can be visually overwhelming; disappearing hints suffer the problems mentioned above. We can compromise by using hints that shrink when text is entered.

Comment 1

[Brian Nicholson (:bnicholson)]

Ian, here's a build with the fancy new text inputs. Thoughts?

http://people.mozilla.org/~bnicholson/fennec_builds/shrinking-hint.apk

Three ways to test:
1) Settings > Customize > Autofill > Add
2) Bookmarks panel > context menu > Edit
3) Go to intranet.mozilla.org and enter username/password

Comment 2

[Ian Barlow (:ibarlow)]

This is pretty freakin hot. 

My one comment so far would be that we could add a little more visual emphasis to the text in the active field. Maybe make it the same blue as the field highlight? Like so: http://cl.ly/image/3M0N1p1p261r

Comment 3

[Brian Nicholson (:bnicholson)]

Here's a build where the hint fades to holo blue:

http://people.mozilla.org/~bnicholson/fennec_builds/shrinking-hint2.apk

This build works only with the Edit Bookmark dialog.

A couple of notes:
1) The underline that appears under the focused TextView is a drawable png in Android, so there's no way to get the blue color programmatically, meaning the color (#33b5e5) is hard-coded. If the phone's uses a theme other than holo blue, our floating hint color won't match the underline color.
2) It feels strange switching between a non-empty text field and an empty one since the focused color changes for floating hints, but it doesn't change for normal hints. Switching focus from Location to Keyword, for example, I kind of expect the Keyword hint to switch to blue as well.

Comment 4

[Brian Nicholson (:bnicholson)]

Going from comment 3, here's another build where the focused hint is always blue, regardless of whether the text field is empty. It feels more consistent when switching fields, but it's kind of weird seeing a non-gray hint on Android.

Comment 5

[Brian Nicholson (:bnicholson)]

Forgot link: http://people.mozilla.org/~bnicholson/fennec_builds/shrinking-hint3.apk

Comment 6

[Ian Barlow (:ibarlow)]

I think you had it right the first time in comment 3, this looks great :)

I don't think we want to add colour to normal hints, it feels a little too severe to me.

Comment 7

[Brian Nicholson (:bnicholson)]

Attachment: Add FloatingHintEditText widget

Implements the widget.

Comment 8

[Brian Nicholson (:bnicholson)]

Attachment: Replace uses of EditText with FloatingHintEditText

Replaces our existing EditTexts with FloatingHintEditTexts (excluding search fields).

Comment 9

[Lucas Rocha (:lucasr)]

Comment on attachment 8418513 [details] [diff] [review]
Add FloatingHintEditText widget

Review of attachment 8418513 [details] [diff] [review]:
-----------------------------------------------------------------

Looking good overall. It's probably a good idea to be focus aware here so that we float the hint out of the way when the entry gets focus? With this patch as is, I guess the hint animates 'over' the text you initially typed i.e. when you first go from empty to non-empty. Just giving f+ to get some discussion about this.

::: mobile/android/base/widget/FloatingHintEditText.java
@@ +38,5 @@
> +        super(context, attrs, defStyle);
> +
> +        floatingHintColors = getResources().getColorStateList(R.color.floating_hint_text);
> +        normalHintColors = getHintTextColors();
> +        wasEmpty = TextUtils.isEmpty(getText());

Is even possible to have non-empty text at this point?

@@ +92,5 @@
> +        // The large hint is drawn by Android, so do nothing.
> +        if (!isAnimating && TextUtils.isEmpty(getText())) {
> +            return;
> +        }
> +

Do paint = getPaint() here and reuse the value throughout this method? Same for getDrawableState().

Comment 10

[Lucas Rocha (:lucasr)]

Comment on attachment 8418514 [details] [diff] [review]
Replace uses of EditText with FloatingHintEditText

Review of attachment 8418514 [details] [diff] [review]:
-----------------------------------------------------------------

Nice.

Comment 11

[Brian Nicholson (:bnicholson)]

(In reply to Lucas Rocha (:lucasr) from comment #9)
> Looking good overall. It's probably a good idea to be focus aware here so
> that we float the hint out of the way when the entry gets focus? With this
> patch as is, I guess the hint animates 'over' the text you initially typed
> i.e. when you first go from empty to non-empty. 

Interesting idea. Build here: http://people.mozilla.org/~bnicholson/fennec_builds/shrinking-hint4.apk

This solves the focus color inconsistency I mentioned in comment 3. On the downside, it's a bit more difficult to read the hint of an empty focused field, which might slow people down if they don't look at the hint before touching the field.

Ian, thoughts?

Comment 12

[Ian Barlow (:ibarlow)]

(In reply to Brian Nicholson (:bnicholson) from comment #11)
> (In reply to Lucas Rocha (:lucasr) from comment #9)
> > Looking good overall. It's probably a good idea to be focus aware here so
> > that we float the hint out of the way when the entry gets focus? With this
> > patch as is, I guess the hint animates 'over' the text you initially typed
> > i.e. when you first go from empty to non-empty. 
> 
> Interesting idea. Build here:
> http://people.mozilla.org/~bnicholson/fennec_builds/shrinking-hint4.apk
> 
> This solves the focus color inconsistency I mentioned in comment 3. On the
> downside, it's a bit more difficult to read the hint of an empty focused
> field, which might slow people down if they don't look at the hint before
> touching the field.
> 
> Ian, thoughts?

Heh, I still prefer the one in comment 3.

The fact that the hint animates away just in time is part of what makes it feel so nice. If we are really worried about the hint animating over top of the text a user is typing, we could try other kinds of transitions, like a crossfade or something, but I'm not sure it's necessary...

Comment 13

[Brian Nicholson (:bnicholson)]

Attachment: Add FloatingHintEditText widget

(In reply to Lucas Rocha (:lucasr) from comment #9)
> ::: mobile/android/base/widget/FloatingHintEditText.java
> @@ +38,5 @@
> > +        super(context, attrs, defStyle);
> > +
> > +        floatingHintColors = getResources().getColorStateList(R.color.floating_hint_text);
> > +        normalHintColors = getHintTextColors();
> > +        wasEmpty = TextUtils.isEmpty(getText());
> 
> Is even possible to have non-empty text at this point?

Sure, just set android:text="foo" in the XML.

> @@ +92,5 @@
> > +        // The large hint is drawn by Android, so do nothing.
> > +        if (!isAnimating && TextUtils.isEmpty(getText())) {
> > +            return;
> > +        }
> > +
> 
> Do paint = getPaint() here and reuse the value throughout this method? Same
> for getDrawableState().

Done (along with some other fixup).

Comment 14

[Lucas Rocha (:lucasr)]

Comment on attachment 8427196 [details] [diff] [review]
Add FloatingHintEditText widget

Review of attachment 8427196 [details] [diff] [review]:
-----------------------------------------------------------------

Good.

Comment 15

[Brian Nicholson (:bnicholson)]

https://hg.mozilla.org/integration/fx-team/rev/8037201a5680
https://hg.mozilla.org/integration/fx-team/rev/d4d6c13c6b83

Comment 16

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/8037201a5680
https://hg.mozilla.org/mozilla-central/rev/d4d6c13c6b83