1045784 - Implement horizontal strip of task cards for each stack entry

Status: RESOLVED DUPLICATE of bug 1061324

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Sam Foster [:sfoster] (he/him)]

The new task switcher is a scrollable/pannable row of cards (TaskCard instances which overlay/decorate the AppWindows we get from stack manager). It should be possible to scroll back and forth through the strip, with similar physics to native scrolling. 

Spec: https://mozilla.app.box.com/s/lbw2wzw3p4jvxs24k4sg

Comment 1

[Sam Foster [:sfoster] (he/him)]

Prototyping this at: https://github.com/sfoster/gaia-taskswitcher-prototype (clone and install as packaged app via App Manager to see it in action)

Currently the prototype applies overflow-x:auto to the #windows div, and transform:scale and position left the appWindow elements inside to make the horizontal strip of cards. The card overlay is still in #cards-view and doesn't scroll with the task strip, it simply fades out on scroll and fades back in when scroll stops. This is nice in that we can just populate 3 static cards - previous, current and next - and do much less DOM mutation and animation. But, its not quite to spec and it only works if we have the scrolling snap to grid so a swipe always ends with some card at center. 
Somehow syncing the scrolling of the #windows and #cards-view div contents is probably out of the question, so the alternative here is to inject the necessary elements for the card (close button, favorite button etc) into the #windows container, or the appWindow's element itself. That makes me a little nervous, but I'm reviewing options and inviting feedback.

Comment 2

[Sam Foster [:sfoster] (he/him)]

Alive, can you take a quick look at the prototype in comment 1 - this is what I'm proposing TaskManager will do to implement the strip of cards and get us native scrolling and a few other bonuses. I've not attempted transitions, or easing of the scrollLeft updates and lots of other details. But the approach seems like it should work, do you agree?

Comment 3

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Sam Foster [:sfoster] from comment #2)
> Alive, can you take a quick look at the prototype in comment 1 - this is
> what I'm proposing TaskManager will do to implement the strip of cards and
> get us native scrolling and a few other bonuses. I've not attempted
> transitions, or easing of the scrollLeft updates and lots of other details.
> But the approach seems like it should work, do you agree?

Placing AppWindow instances consistently by the order to represent TaskManager and StackManager is something I proposed to :etienne in May. So for sure I agree this.

Etienne's main concern is the gecko performance issues. We should be careful and do some tests before real merge.

Lemme know what changes from appWindow you will need.

Comment 4

[Sam Foster [:sfoster] (he/him)]

Rob and/or Francis, can we talk about https://github.com/sfoster/gaia-taskswitcher-prototype sometime today? It represents the approach I want to take it on the new task manager. It doesnt address show/hide transitions and there are visual nits, the main thing here I need to get right is the scrolling and snapping of the task strip.

Comment 5

[Rob MacDonald [:robmac]]

Reviewed with Sam today and the consensus was that the snapping, as implemented, would need more work before it could be in a shippable state. Sam is working on non-snapping version for UX review.

Comment 6

[Sam Foster [:sfoster] (he/him)]

Here's a prototype implementation which which does no snapping and the task strip scrolls freely: https://github.com/sfoster/gaia-taskswitcher-prototype/tree/many-cards

As we discussed, by not centering the card there's no clear "in viewport" state and we probably have to forego the shifting of the icons in the adjacent cards as well as the transitions on the close/favorite buttons. So in this prototype we literally attach those buttons to each instance we get from the stack manager, and if you can see them, you can click on them. 

To see it in action, either download the .zip on that page, or clone the repo and change to the 'many-cards' branch. In firefox about:app-manager, add/update the Task switcher prototype packaged app (you'll need to close the app first if its already running).

Comment 7

[Francis Djabri [:djabber]]

The scrolling here feels pretty to me and a better starting point than the snapping version. It feels a tad slow and maybe not as smooth as it could be, but I think we can live with it and make improvements along the way. When you say we'll probably have to forego the animations, does that include swiping up to dismiss? I'm assuming that we'll still be able to incorporate the updated visuals and still have the opening animation according to spec, and also implement the landscape orientation?

Hopefully we can still get a snapping version working, but I think what we have is shippable if we can fix the visuals and the landscape layout.

Comment 8

[Sam Foster [:sfoster] (he/him)]

Francis, lets keep an eye on the scrolling. In principle it should be as smooth as scrolling any web page so if its not its probably something we can fix. The animation I'm talking about is where the icon slides to the edge of the card as seen in https://mozilla.box.com/s/090aywxx7z9x0nkkh6sv. Swipe to dimiss should be ok, I've filed bug 1051095 to track that. Landscape should actually be slightly easier with this approach, I've filed bug 1051098 to track that. I'm tracking the opening and dimissing animations in bug 1045787 to allow work to proceed in parallel if necessary. For the rest of the visuals, I'll ask for ui-review on this bug when its ready.

Comment 9

[Sam Foster [:sfoster] (he/him)]

Attachment: WIP - task manager refactor with TaskCarouselUI, TaskStripUI

Alive, you asked earlier to let you know what changes I need from AppWindow. I hope the slightly hacky patch here can start that conversation. This is WIP, notably: 
* the scrolling of #windows isn't working yet (not sure what I'm missing, the prototype worked great?)
* The homescreen is active and behind the task manager, obviously that's got to be fixed somehow
* The CSS changes are kind of dumped into window.css, I expect to need to reorganize and refine this
* Should the .buttonbar > button elements be added on the fly perhaps similar to appChrome?  
* I expect to add some more tests for TaskStripUI

Transitions, swipe to delete, homescreen in taskmanager are planned for other bugs. 

For context, to allow iterative/parallel work on the new task manager, I'm keeping it behind the taskstrip.enabled setting (taskManger.isTaskStrip) for now. Hopefully we can land this when its ready, and work on transitions and other details next, rather than maintaining and landing it all as a giant patch later. To this end I've refactored to create a .listUI property and all the card rendering/interaction move to one of 2 classes: TaskCarouselUI and TaskStripUI. 

For TaskStripUI we are essentially putting a lens on the appWindows, arranging them in a horizontal strip, making that strip scrollable, showing some different controls and adding close/select and favorite actions while in this view. There are no card objects or representations beyond the appWindow's view itself. This patch this is my first pass at making this work and your feedback would be valuable now before I spend more time refining.

Comment 10

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8470628 [details] [review]
WIP - task manager refactor with TaskCarouselUI, TaskStripUI

For the additional view in appWindow but not handled by itself,
I expect we have a appTaskCard subcomponent to do the same thing as appChrome:
* Inject the dom into AppWindow by this.app.element.insertAdjacentHTML(...)
* Handle the click event and pass a proper event away.

Comment 11

[Sam Foster [:sfoster] (he/him)]

Duping this against bug 1061324 which obsoletes the WIP patch and resolves a lot of what we were trying to achieve here. I'll open new bugs for missing features and the proposed AppWindow subcomponent refactor