Closed
Bug 1227259
Opened 9 years ago
Closed 8 years ago
App grouping prototype
Categories
(Firefox OS Graveyard :: Gaia::Homescreen, defect)
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.
Reporter | ||
Updated•9 years ago
|
Component: Gaia::Homescreen → Gaia::System::Browser Chrome
Reporter | ||
Updated•9 years ago
|
Component: Gaia::System::Browser Chrome → Gaia::Homescreen
Assignee | ||
Comment 1•9 years ago
|
||
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
Updated•9 years ago
|
feature-b2g: --- → 2.6+
Reporter | ||
Comment 2•9 years ago
|
||
Let's track the prototype work in this bug and the actual feature implementation in bug 1222135
feature-b2g: 2.6+ → ---
Assignee | ||
Comment 3•9 years ago
|
||
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.
Assignee | ||
Comment 4•9 years ago
|
||
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.
Comment 5•8 years ago
|
||
Assignee | ||
Comment 6•8 years ago
|
||
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
Updated•8 years ago
|
Target Milestone: --- → 2.6 S2 - 12/4
You need to log in
before you can comment on or make changes to this bug.
Description
•