Closed Bug 1169012 Opened 8 years ago Closed 5 years ago

[User Story] Group Windows by Site

Categories

(Firefox OS Graveyard :: Gaia::System::Task Manager, defect, P3)

ARM
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: benfrancis, Unassigned)

References

Details

(Keywords: feature, Whiteboard: [systemsfe])

User Story

As a user I want to view the collection of open pages, grouped by site, so that I can easily find the page I'm looking for.

Attachments

(1 file)

As a user I want to view the collection of open pages, grouped by site, so that I can easily find the page I'm looking for.
A Pivotal Tracker story has been created for this Bug: https://www.pivotaltracker.com/story/show/95570468
I'll take this, but I'm going to block it on bug 1161229, so we're building on top of a CSS-scroll-snapping task manager.
Assignee: nobody → sfoster
Depends on: 1161229
Status update: I have what's turning to be a fairly large patch underway for this (functionally complete, just working my way through the tests I broke.) Essentially it changes up the cards to hold 1+ apps, and the select/close actions on the card apply to the front app. When the app.cards_view.appgrouping.enabled setting is true, it groups apps on the stack (currently by hostname), without that setting, each card has a group of 1 and there's no visible change in behavior. 

I've left the UI for the cards & task manager as-is which seems to work ok, we'll update that as/when we get UX specs.
Target Milestone: --- → FxOS-S3 (24Jul)
Comment on attachment 8633540 [details] [review]
[gaia] sfoster:group-windows-bug-1169012 > mozilla-b2g:master

Apologies for the size of the patch, this was the straw that broke the camel's back for the task manager unit tests, so those are refactored to create a fresh TaskManager instance each test. 

I've tried to minimize the user-facing changes, and with the new setting off there should be no changes in behavior at all. 

Let me know if you have questions, I'm happy to walk you through it (but hopefully its self-explanatory)
Attachment #8633540 - Flags: review?(etienne)
Attachment #8633540 - Flags: feedback?(m)
Note to self, quit attaching patches to User Story bugs.
Comment on attachment 8633540 [details] [review]
[gaia] sfoster:group-windows-bug-1169012 > mozilla-b2g:master

Wow wow wow, let's take a deep breath :)

Grouping will have significant performance and feature regression potential (the current version of the patch adds a big delay launching the cardview and breaks screenshots for example). There's no way we're going to catch those while reviewing patches of this size.

And there's no reason to do so! Landing behind a setting makes sense for this feature I think, and it touches a pretty narrow set of system app files, so we can be super incremental.
(On this note we should also add the setting to the settings app developer panel to make it easy for foxfooder to enable the feature.)


Here's my suggestion on how to move forward, in broad strokes I'd like to see
* one bug refactoring the task manager tests and making the task manager truly instantiable (there's multiple bits of state still on the prototype)
* one bug with the card.js icon work
This should land pretty quickly since it's mostly extracts from the current patch.

Then we need to clarify a few things with UX (feel free to point me to specs if those points are already clarified):
+ how does grouping impact stack management? You can have a stack looking like [github.com/foo]-[dialer]-[github.com/bar]. Grouping will break the 1-1 relation between the Stack and the Card View. How do we solve this?
+ how does grouping impact the position when opening the cardview? And when we group where should the group be positioned? And which card should be on top?
+ which actions can you take on a group? I'm all for landing the grouping itself as a separate patch then adding features on top of it (obviously) but the UX could have a big impact on the preferred implementation.

Which would eventually lead to
* one bug to add support for grouping to the StackManager
* one bug to display groups in the cardview
* one bug for each feature on a group

Happy to discuss this in a meeting if it can help :)
Attachment #8633540 - Flags: review?(etienne)
Depends on: 1185035
Depends on: 1185063
Depends on: 1185516
Depends on: 1185553
We're making progress on the "foundations" bugs here, but are still waiting for the UX clarifications (see Comment 8).

Ben, do you know if anyone is working on them?
Flags: needinfo?(bfrancis)
Depends on: 1185160
Hi Etienne, Francis is working on the new UX spec for task manager.

All we have right now is the high level concept of windows being grouped by site (for both pinned and un-pinned sites) as part of Pin the Web, to complete the unification of the task manager and tabs manager started in Haida, and to use the UI metaphor of a stack of sheets being pinned together by the site pin.

This needs a lot of work to fill out the interaction design, which is why we chose to implement this piece behind a setting until the interaction design gets finalised :)
Flags: needinfo?(bfrancis)
(In reply to Ben Francis [:benfrancis] from comment #10)
> Hi Etienne, Francis is working on the new UX spec for task manager.
> 
> All we have right now is the high level concept of windows being grouped by
> site (for both pinned and un-pinned sites) as part of Pin the Web, to
> complete the unification of the task manager and tabs manager started in
> Haida, and to use the UI metaphor of a stack of sheets being pinned together
> by the site pin.
> 
> This needs a lot of work to fill out the interaction design, which is why we
> chose to implement this piece behind a setting until the interaction design
> gets finalised :)

Just to be clear, I think a setting makes sense here.

But we need a basic first draft of the UX not to shoot ourselves in the foot with the implementation.
As an example, piggy-backing on card.js for the "groups" might be really short-sighted depending on the actions we want to be able to do on a group.
I agree, I think Sam has said we shouldn't move any further on this implementation until we have a UX spec. I think it's up to you two whether you want to land this patch in the mean time.
Target Milestone: FxOS-S3 (24Jul) → FxOS-S4 (07Aug)
Depends on: 1189522
Depends on: 1189527
Attachment #8633540 - Flags: feedback?(m)
Priority: -- → P3
Unassigning, I'm not currently working on this.
Assignee: sfoster → nobody
Target Milestone: FxOS-S4 (07Aug) → ---
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.