[Flatfish][System] Add animation for home gesture

RESOLVED INVALID

Status

RESOLVED INVALID
5 years ago
5 years ago

People

(Reporter: gduan, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Flatfish only] [developer-])

Attachments

(1 attachment)

Created attachment 807143 [details]
Spec for gesture

Follow-up of bug 911673.

We need an animation when user trying to swipe to home and cardview.
Assignee: nobody → gduan
Currently, I have two proposals and both of them have risk to implement.

UX: When user swipe up from the bottom, app's screen will scale down following the movement of finger.

Proposal 1: scale down the div(.appWindow). When scaling, all the system dialog(ex. alert,prompt) will be closed.
Risk: when app is scaled down and it's designed responsive, the layout may go to mobile version due to window.innerWidth is changed.(mediaquery). And the scaling seems not so smoothly.

Proposal 2: scale down the screenshot of system app. Listen to touchstart, and then generate the screenshot.
Risk: it takes almost 0.7 second to generate the picture on tablet, and it consumed a lot of resources. We need UX opinion how to handle the time delay. 

Hi Alive,
Do you have any suggestion on that or other idea to implement it?
Please let me know if anything I miss or unclear.

Hi Carrie,
please correct me if wrong.
about proposal 2, I will show you the delay tomorrow and see how to handle that.
Flags: needinfo?(cawang)
Flags: needinfo?(alive)
Please let me correct myself.

Proposal 1 will not affect responsive design (app will remain its layout), since I'm using transform:scale in css now.

So, the risk I think of , probably is the dragging performance. And when system dialog screen shows in app, how do we handle it while swiping to home? 

I think we can hide them while touchstart, and show them if user has changed his mind.
Please advise.
(In reply to George Duan [:gduan] from comment #1)
> Currently, I have two proposals and both of them have risk to implement.
> 
> UX: When user swipe up from the bottom, app's screen will scale down
> following the movement of finger.
> 
> Proposal 1: scale down the div(.appWindow). When scaling, all the system
> dialog(ex. alert,prompt) will be closed.

Modal dialog or any other app specific dialog is going to be moved into appWindow.
They won't be closed anymore until user dismiss it.
Though the bug won't be in 1.2 scope.
https://bugzilla.mozilla.org/show_bug.cgi?id=916660
https://bugzilla.mozilla.org/show_bug.cgi?id=916661

> Risk: when app is scaled down and it's designed responsive, the layout may
> go to mobile version due to window.innerWidth is changed.(mediaquery). And
> the scaling seems not so smoothly.

window.innerWidth is never changed....CSS transform won't cause resize.

> 
> Proposal 2: scale down the screenshot of system app. Listen to touchstart,
> and then generate the screenshot.
> Risk: it takes almost 0.7 second to generate the picture on tablet, and it
> consumed a lot of resources. We need UX opinion how to handle the time
> delay. 

It is still unclear why you need the full system app screenshot. Is it only for modal dialog?
If so, please don't do this.

> 
> Hi Alive,
> Do you have any suggestion on that or other idea to implement it?
> Please let me know if anything I miss or unclear.
> 
> Hi Carrie,
> please correct me if wrong.
> about proposal 2, I will show you the delay tomorrow and see how to handle
> that.
Flags: needinfo?(alive)
I do think we could leave the minor issue(modal dialog is closed upon closing gesture) opened until 916660 is fixed.
The same problem is there in cardview: we couldn't do screenshot for modal dialog so if one app is opened with modal dialog, in card view you won't see the modal dialog.
(In reply to George Duan [:gduan] from comment #1)
> Currently, I have two proposals and both of them have risk to implement.
> 
> UX: When user swipe up from the bottom, app's screen will scale down
> following the movement of finger.
> 
> Proposal 1: scale down the div(.appWindow). When scaling, all the system
> dialog(ex. alert,prompt) will be closed.
> Risk: when app is scaled down and it's designed responsive, the layout may
> go to mobile version due to window.innerWidth is changed.(mediaquery). And
> the scaling seems not so smoothly.
> 
> Proposal 2: scale down the screenshot of system app. Listen to touchstart,
> and then generate the screenshot.
> Risk: it takes almost 0.7 second to generate the picture on tablet, and it
> consumed a lot of resources. We need UX opinion how to handle the time
> delay. 
> 
> Hi Alive,
> Do you have any suggestion on that or other idea to implement it?
> Please let me know if anything I miss or unclear.
> 
> Hi Carrie,
> please correct me if wrong.
> about proposal 2, I will show you the delay tomorrow and see how to handle
> that.

Hi George,

Thanks for the demo. I think we agree to apply proposal 1 and the mobile layout issue does not exist actually.
Flags: needinfo?(cawang)

Updated

5 years ago
Blocks: 903304
Whiteboard: [Flatfish only]

Updated

5 years ago
blocking-b2g: --- → koi?

Updated

5 years ago
blocking-b2g: koi? → ---
Whiteboard: [Flatfish only] → [Flatfish only] [developer-]
Assignee: gduan → nobody
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.