Closed Bug 1227259 Opened 9 years ago Closed 8 years ago

App grouping prototype

Categories

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
2.6 S2 - 12/4

People

(Reporter: benfrancis, Assigned: cwiiis)

References

Details

(Whiteboard: [systemsfe])

Attachments

(2 files)

An architectural spike to explore a new model for grouping apps on the homescreen.
Component: Gaia::Homescreen → Gaia::System::Browser Chrome
Component: Gaia::System::Browser Chrome → Gaia::Homescreen
See Also: → 1222135
Been giving this some thought and come up with a plan.

A preface to the plan; I think there are (broadly speaking) two ways to go about this, structurally. In verticalhome, grouped icons were still container in the app grid, and we had special layout/animation code and special cases in all event handling to deal with it. This made certain things easier (namely, transitions), but other things much harder (drag-and-drop, future additions to gaia-grid, performance optimisation).

For new homescreen, I would like to try the other approach, which is for grouped icons to be a separate element. Note that the new folder-like design for grouped icons lends itself better to this strategy too. Instead of grouped icons remaining in the main container, they will be in a sub-container that handles group animations/interaction separately. This will likely be more code, but should be easier to maintain and optimise structurally. We'll see.

The plan is as follows:

- Enable hiding the icon title in gaia-site-icon
- Add an 'immediate' parameter to gaia-container DOM methods
- Support absolute and fixed positioned children in gaia-container
- Create a new gaia-container sub-class in homescreen (called 'group', I guess)
  + Has a function to add an icon from a gaia-container
    - Immediately removes from container, immediately adds to self with the correct transform to make it look as it did in the container and transitions to the right size/position by changing that transform
  + Has a function to remove an icon and add back to a gaia-container
    - Immediately removes from self, immediately adds back to gaia-container with the correct transform to make it look as it did in the group and transitions to the right size/position by removing that transform
  + Icons in group are just gaia-site-icon with the title disabled. They are absolutely positioned and take up the full width of the container.
    - A look-up table is used to determine the transform of icons within a group (so that we can do neat custom arrangements)

Expanding a group
- The offset of the group is recorded for transition purposes.
- The group is made fixed-position with display:flex to lay out children in a grid. Children are made static position again and transforms added to match how they previously were in the unexpanded group. Transitions are then removed to animate to the correct position/size and titles enabled.
? Should homescreen drag/drop handlers be repurposed inside a group ?
? Edit mode ? (UX want remove tray again, do we want to do all at once or have an interim where edit mode works for groups?)
? Dragging an icon outside of the group will remove it from the group. It would be nice to be able to continue dragging the icon out of the group in the app grid, but this is probably not feasible while maintaining performance...

Collapsing a group
- Offset of all icons recorded, and offset of fixed position group recorded.
- The group is returned to its previous collapsed state. Transforms are set on all icons to maintain their previous size and position.
- Titles are disabled and transforms changed on icons to move them to their collapsed position.


Asides:
- We probably want to set some kind of style class on body to disable overflow/input while a group is expanding/collapsing
Status: NEW → ASSIGNED
feature-b2g: --- → 2.6+
Let's track the prototype work in this bug and the actual feature implementation in bug 1222135
feature-b2g: 2.6+ → ---
I'm working on this in this branch: https://github.com/Cwiiis/gaia/tree/bug1227259-homescreen-folders-proto

Current progress, you can drag icons over other icons and groups get created (but nothing is added to the group and beyond rearranging, you can't interact with the group). Very much WIP.

I plan to take this branch up to the point of at least getting icons into groups. Expanding groups, rearranging inside of groups, removing from groups may or may not come. Group storage and testing I have no plans for, that goes beyond prototyping.
Attached image 2015-11-26-18-22-06.png
Current progress. Also striking off the prototype list 'render correctly in 4-column mode'.

Having a lot of difficulty with layout and transitions - taking this route has left interaction much easier (reordering still works fine and adding code to create and drop into groups was very easy), but rendering/layout much harder. May have to work out a slightly different layout strategy tomorrow.
Marking this as fixed, the prototype is basically complete and I don't envision doing any substantial work on it before PTO.

You can:

- Create groups by dragging icons over other icons - an icon will shrink when grouping will activate
- Drag icons into groups by dragging ungrouped icons over group icons
- Open groups (tap the group icon)
- Rearrange icons in groups
- Drag icons out of groups (by dragging an icon outside of the group at the top or bottom of the screen)
- Close groups (by tapping outside of the group)

Transitions are mostly implemented and smooth/complete. I've not implemented what I think would be the absolute best transitions, but those are pretty complex it turns out and there are a few platform oddities that make them hard (not impossible, if UX doesn't like this we can discuss alternatives).

Obvious things that this prototype doesn't do:
- It's possible to get some weird layout inside the group icon when grouping icons on slow devices/during startup. I think this is easily fixed, but you're extremely unlikely to encounter it.
- Edit mode is disabled inside groups
- Groups can't be named
- Groups aren't saved when restarting the homescreen
- There is no group size limit. Groups will scroll if they can't fit within the screen (I actually quite like this - it maps well to our previous app groups (so we could migrate user groups, theoretically...) and it lets you use a single group for all your junk icons, games or pinned sites, which I can imagine being the primary uses of this)
- The animation when dragging the penultimate icon from a group is pretty rough

This prototype, I think, is a good kick-off point for implementing the real thing. I've tried to minimise the number of shortcuts taken and changes made to external components have been reviewed and merged already (for the most-part). How challenging the final implementation will be depends somewhat on how different we want it to look/operate.

UX peeps are cc'd and gmarty will be at the work-week to demo if need be.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.6 S2 - 12/4
Blocks: 1222135
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: