1052951 - [email] signature upgrade experience

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[James Burke [:jrburke]]

Now that bug 847168 landed signature support, by default, email accounts that are upgraded to the new code do not have a signature listed and do not have it listed. This is the expected behavior, but we could make things a bit easier for those people that then want to turn on a signature. Two main issues:

1) When they see the signature preference, the button that shows the existing signature is blank. Ideas might be to show the default signature if they turn on signatures, or a placeholder text that says something like "(tap here to type in a signature)".

2) When navigating to the signature edit card, the editable area is not focused at first, so the keyboard is not shown, which may be confusing, particularly if the signature is blank. So it seems like a good idea to focus inside the editable area when the card is shown. The question then is if the cursor should just be placed at the end of the existing text or if the whole of the existing text is selected for easy deletion.

This is only an issue for 2.1/master.

Comment 1

[Juwei Huang[:juwei]]

Attachment: [Email] Signature_1.1.pdf

I've modified a new version for signature spec, changes below:

1. When the list button of signature is blank, show "Tap to Edit" in gray color in the list button to indicate user that the list is editable.

2. When user enters the signature edit card, the keyboard should slide in automatically and the cursor should focus on the end of the sentence. 
(I prefer not to highlight the exist text... in case users delete it by accident)

I'll also update the spec to bug 847168.

Comment 4

[Tony Chung [:tchung]]

[Blocking Requested - why for this release]:
signature is missing in dropdown.  see bug 1057280

Comment 5

[Juwei Huang[:juwei]]

Attachment: [Email] Signature_1.2.pdf

Update spec due to bug 1058699 & bug 1054553.

Comment 6

[James Burke [:jrburke]]

Attachment: signature-cleanup.png

I have a patch that addresses the issues for this ticket and that are also mentioned in the ux design doc now. Attached is a picture showing the screens with the results. There are four screens:

1) Shows "Tap to Edit" when no signature text is configured, in a gray text. I chose #858585 for that text color, but happy to change it to another color as :peko sees fit.
2) Shows how the keyboard and focus is now set by default when first navigating to the signature edit card.
3) Shows the wrapping of long lines in signature edit.
4) Shows the wrapping of long lines in compose.

Only flagging :peko for review since I believe Juwei will be unavailable. I apologize for the short notice, but ideally we could get ui-review within the next 15 hours or so, so that we can land this before the end of the sprint. This changeset has an l10n string, so it is more important for it to land before the string cutoff on Monday.

Comment 7

[James Burke [:jrburke]]

Also, forgot to mention, for screenshot 2), if there is existing signature text, the cursor is placed at the end of that text. It does not highlight all the text, just places the cursor at the end.

Comment 8

[James Burke [:jrburke]]

Attachment: GitHub pull request

Pull request, will flip to dev review once ux-review passes.

Comment 11

[Peko Chen [:pekochen]]

Comment on attachment 8481064 [details]
signature-cleanup.png

Looks good~~~
Thanks!!!

Comment 12

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 8481074 [details] [review]
GitHub pull request

r=asuth.  I'm a little jumpy about the string values we use now, like it's not immediately obvious to me that "Tap to Edit" is more right than "Tap to edit".  I'm definitely out of the loop on our style guidance right now.  So if it's possible to ping Stephany/Matej before landing (per Axel's message on dev-gaia about the "2.1 String Freeze") if we don't already have some type of authoritative sign-off from them, that would probably be good.

Comment 13

[James Burke [:jrburke]]

The title case use for UI labels, like "Tap to Edit" matches the UX feedback I received in bug 1043529 from Juwei, so I thought it was correct, but good to double-check.

Going to ask Stephany for feedback since according to the dev-gaia email, she offered to help with English strings, and is likely to know the generally preferred case practice for UX, and hopefully she is in the North American Pacific timezone at the moment.

Stephany, you can see the "Tap to Edit" text in action in the attachment to comment 6. Is it correct to use title case in this case?

Comment 14

[Stephany Wilkes]

Title case is fine. We'll work out details later when our new copy style guide is completed in a few more weeks.

Comment 15

[James Burke [:jrburke]]

Fixed in master:
https://github.com/mozilla-b2g/gaia/commit/b2d5060543c5770d411c0664ec7817a3405d2fe5

from pull request:
https://github.com/mozilla-b2g/gaia/pull/23452

Comment 16

[Edward Chen[:edchen]]

All of dependency tickets are fixed, the root can be mark to VERIFIED.


[Environment]
Gaia      fbb297c39aab5f17b179533d2a9a6c5166b2c197
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/fb5e796da813
BuildID   20140902160204
Version   34.0a2
ro.build.version.incremental=eng.cltbld.20140820.195518
ro.build.date=Wed Aug 20 19:55:28 EDT 2014


[Result]
PASS

Comment 17

[Dylan Oliver [:doliver]]

triage: blocking 2.1

This was a late use case for a new 2.1 feature. Without this addition, the signature feature is confusing for users that upgrade from a previous version of FxOS.

Comment 18

[Dylan Oliver [:doliver]]

triage, take 2: no need for blocking, this landed prior to 2.1 branch date.