Closed Bug 1023658 Opened 10 years ago Closed 6 years ago

[User story] Hide CC and BCC fields while composing an email

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: skasetti, Assigned: robert.sajdok)

References

Details

(Keywords: feature, Whiteboard: [tako])

User Story

As a user I want to hide cc and bcc in emails so I can maximize the display for my content that I am typing.

Attachments

(5 files)

      No description provided.
Spec attached.
Can you clarify how we are supposed to do the visual transition of going to/from "Cc/Bcc:" to "Cc:" and "Bcc:"?  Based on the PDF right now I'd guess that we instantaneously transform "Cc/Bcc:" to "Cc:" at the start of the expand cycle, and instantaneously transform "Cc:" back to "Cc/Bcc:" back.

(I don't really see a lot of alternatives, but I thought I'd check.  The only thing I could think of would be a complicated multi-step animation where we decompose "Cc/Bcc:" into separate items "Cc:" and "Bcc:" on the same line, and then we animate "Bcc:" moving downwards with the envelope area expansion, and then animate Bcc sliding left to its new home.  The collapse process would be the opposite.  I'm not sure how feasible that would be until we have the new animation spec support and with it all off-the-main-thread compositor-accelerated.)
Flags: needinfo?(jhuang)
Hi Andrew,
Thanks for your suggestion! I also have some ideas about this animation & need you to review it's possibility... 
Please see screen 4 of page 4: It might be hard to describe the animation, but my expectation is that when users tap on the "Cc/bcc:" list, the "Cc/bcc:" list turns to "Cc:", and there is a "bcc:" list slides in and then push other list items down.
Fang will help us to make a video of this animation later so that we can have a more clear view of what we want to do.
Need info Fang to comment.
Flags: needinfo?(jhuang) → needinfo?(fshih)
Peko will take over this from now on, Thanks!
Flags: needinfo?(fshih) → needinfo?(pchen)
https://www.dropbox.com/s/0ksp01f8qgtq4jy/Email_ccbcc_expend.mov
Animation for cc/bcc ready.
Flags: needinfo?(pchen)
QA Contact: edchen
feature-b2g: 2.1 → 2.2
Blocks: 1028224
Keywords: feature
Whiteboard: [tako]
Use feature-b2g:2.2? rather than just 2.2.
feature-b2g: 2.2 → 2.2?
I have made a prototype for the bug or the part of this bug. I am not sure. I mean the functionality "Collapse cc/bcc list" In the pdf specification and in the video I see functionality which I made in my prototype. Please, watch the video and tell If I did the right fix.    
Next, Is there a function or functions which would allow to make an animation such as in the video from Juwei?  Or do I have to write that piece of code by myself, completely new?
Flags: needinfo?(jrburke)
Flags: needinfo?(edchen)
Attached file Video for prototype
Attachment #8498026 - Flags: feedback?(jrburke)
Attachment #8498026 - Flags: feedback?(edchen)
Hi Robert,
Thanks for your work!! It looks great!
I think you achieve the fundamental need for this requirement, which is good :)

Unfortunately I cannot provide you any helps on coding the animation because it's made by After Effects.
But we can provide some values for you to do the experiment if you need it, such as opacity value or show up timing. Then I'll ping Peko, our visual designer, to discuss with you.
Thank you!
QA Whiteboard: [COM=Gaia::Email]
Flags: needinfo?(edchen) → in-moztrap?
Flags: in-moztrap?
Attachment #8498026 - Flags: feedback?(edchen) → feedback+
Comment on attachment 8498026 [details]
Video for prototype

This animation may be a bit tricky. I would summarize the animation as doing the following:

1) swap "cc/bcc" with text that just says "cc". For this I would be tempted to just have two different spans, one for each version of that text, that are either display none or inline depending on a class value that is set on probably the parent.

2) Show the bcc line with a combination of an opacity and height transition. Height might not be the right thing here, more likely a translateY. Although for div layout reasons, might try starting with height.

CSS transitions can be used for those things (see existing card navigation code/CSS that sets translateX for example). However, I expect using "height" as the transition will perform very badly, and it also means knowing the end size.

On performance: opacity and translateY should perform well. The trick is to get the translateY to work, I believe it will mean containing the bcc, subject and body in a div so that the translateY could be used on the whole contents of that div. That may make it hard to get the contents to all fit nice in the card though.

We have something like this in play in the folder_picker, if more than one account is configured, there is a dropdown that pushes down the folder names. It works on a translateY nature. 

The unfortunate part is that this seems to perform poorly in master and 2.1 right now. It may be a graphics issue, but I think it also may be dependent on the size of the folder list. For example, if the all the folders fit in the folder_picker display, without scrolling, the animation is choppy. If there are enough folders that it already scrolls, it performs better. However, if there are a lot of folders, then I think that may trigger the low-res tiling issue described in bug 1075271.

So in summary, it is likely going to be tricky to do. I would probably start with just doing a height animation, and we can see how bad that is. The trouble is really getting the end size to get the CSS transition to work, as they need numeric end goals for the animation to work.

At first thought, using the size of the "cc" cmp-envelope-line div might be useful, but I expect that to break down if there are lots of people already entered in the bcc list.

I am running out of time for bug work at the moment, otherwise I would look it up, but perhaps that is not an issue: if there are bcc entries then perhaps we do not collapse those fields. Would need to consult the UX spec to be sure. If it is not in there, then I suggest we just ask for that to be a limitation on this feature: if bcc is entered, then we do not do the collapse, we just always show it expanded.

End result though is that I expect it will take some experimentation, and likely we may need to go back and forth on it a few times to get it fully sorted.

And for future reference, for these sorts of "how should this step be done" questions, you can just set the needinfo flag on a general bug comment instead of a feedback flag on a specific attachment. It saves some bit flipping, and makes it easier to get feedback without requiring an attachment. If you set one (feedback? or needinfo?) you do not need to set the other flag.
Attachment #8498026 - Flags: feedback?(jrburke)
Flags: needinfo?(jrburke)
Attached file Video for solution
What do you think about my solution?
Attachment #8513031 - Flags: feedback?(jhuang)
Attached file Proposed fix.
Attachment #8513034 - Flags: review?(jrburke)
Comment on attachment 8513031 [details]
Video for solution

Hi Robert
The animation looks smooth and great! Thank you!Great Job :D

Yet the interaction is a little different than ux spec... when entering compose view, cc & bcc list should be already collapsed. It's not until users tap on "To" then the two lists merge together, it should be merged at the beginning.

And the margin of the subtitle seems offset a little when expending cc/cc. Need info Peko for visual advice.
Flags: needinfo?(pchen)
Attachment #8513031 - Flags: feedback?(jhuang) → feedback+
Hi~

Can you please make the margin of subject 40px? it should be the same as "to" and "cc".
Thanks
Flags: needinfo?(pchen)
Comment on attachment 8513034 [details] [review]
Proposed fix.

Review comments in the pull request. For me, the transition is really choppy on my flame, and giving more time to the animation seemed to help. 

Also, the changes in bug 1005446 may cause a bit of bumpy swirl for the changes, but I think the animation is on the right track. We need to lock down some specifics for it, but feels like something in this direction may work out. Thanks for looking into this!
Attachment #8513034 - Flags: review?(jrburke)
Assignee: nobody → robert.sajdok
Attachment #8513034 - Flags: review?(jrburke)
Attachment #8513034 - Flags: review?(jrburke)
Attached file Proposed fix
Attachment #8532519 - Flags: review?(jrburke)
Comment on attachment 8532519 [details] [review]
Proposed fix

This is coming along, but some more things to sort out, mentioned below. If we had fully realized UX spec, that might help save some time. Sometimes we do not discover all the edges until we try it too.

Notes:

* The compose card comes up with cc/bcc expanded. I would expect we want it to start collapsed, since we likely expect most emails not needing to set those values.
* There are overflow problems, where the contact bubbles can bleed outside the envelope area. It results from setting a specific height on the animation. We likely need to clear the height, or set it to auto when the animation is done.
* If there are multiple entries in cc and bcc, the animation trims out more than one line of the CCs also, and does not show a bcc entry. I think we may want a design where when collapsed only one bubble is shown with a "..." or "more" link that would expand it out more.
* Related, if only a bcc address is entered, no other cc or bcc, that address should show in the cc/bcc collapsed state. Right now it just gets hidden.
* We likely should collapse when tapping anywhere outside the cc/bcc area, so if user taps in subject or body area.

It might be good to wait a bit more on this bug until UX can weigh in on the "..." or "more" link type of experience, and for how the animation should work for some of the edge cases like only one bcc, in collapsed state. Ideally that is reconciled with the behavior for bug 1107994.

To set some expectations on getting more eyes on it: currently FxOS is in a planning phase for next year and some people will be on vacation here in December, so I do not expect to see movement on this until perhaps later in January, early February. So until then, it may be good to pick up bugs that have less UX edge cases and are more about behind the scenes code changes or simpler UI polish. That is what I am planning to do too.
Attachment #8532519 - Flags: review?(jrburke)
Removed it now due to Tako project.
feature-b2g: 2.2? → ---
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: