Closed Bug 910328 Opened 12 years ago Closed 12 years ago

[e.me][feature] Improve boot process

Categories

(Firefox OS Graveyard :: Gaia::Everything.me, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 910331

People

(Reporter: sonmarce, Unassigned)

References

Details

No description provided.
Blocks: 1.3-e.me
Additional information: In v1.1, Evme code is lazy loaded (when searchbar is pressed) to spare homescreen load times. In v1.2, this doesn't look like an option because Collections are displayed immediately on the first grid page and require Evme logic to render the icons and display it's content. We propose to remove lazy loading to prevent complexity and risk. In order to optimize loading time, Evme assets should be added to the GAIA_OPTIMIZE script.
Cristian, Vivien, what are your thoughts on this?
Flags: needinfo?(crdlc)
Flags: needinfo?(21)
IMHO, I would like to delete that code although I think that we could wait because we have a close deadline and this is not a new feature and it could be implemented as improvement at the end.
Flags: needinfo?(crdlc)
(In reply to Ran Ben Aharon (Everything.me) from comment #2) > Cristian, Vivien, what are your thoughts on this? Urgh. Do we need to do this for 1.2 really? It is a lot of work to avoid the additional load time and memory consumption on the homescreen app. Why it is not 1.3?
Flags: needinfo?(21) → needinfo?(clee)
Vivien, try the current v1.2 branch https://github.com/EverythingMe/gaia/tree/enhanced-squashed. Our only way to avoid loading on init, would be to lazy load after clicking a Collection/Searchbar. I think it's just wrong.
(In reply to Ran Ben Aharon (Everything.me) from comment #5) > Vivien, try the current v1.2 branch > https://github.com/EverythingMe/gaia/tree/enhanced-squashed. > > Our only way to avoid loading on init, would be to lazy load after clicking > a Collection/Searchbar. I think it's just wrong. We can investigate the reasons where the memories goes and why it takes so long but 1.2 ends on the 15th of this month. Seems short to me. Again why it should land on 1.2 and not 1.3? Any particular reasons for that?
Cause the Collections (previously smart-folders/shortcuts) is now a grid icon. Meaning, it loads with the Homescreen. When the OS first initializes and the Homescreen populates the pages with icons for the first time - Evme code is required in order to create the "3 app" icons. (I'm not totally certain about this) We've seen that lazy loading isn't that bad when clicking on the searchbar - typing still works while Evme loads. But, clicking a Collection icon and waiting idly for over 2secs is too painful. I think the user expects icons on the grid to open instantly. I guess we have 3 options: 1. Leave it lazy loaded and hurt UX (and perhaps functionality) 2. Optimize Evme loading and bundle with homescreen and hurt inital load time. 3. Split Evme loading sequences - initial and lazy. Probably won't have time for this.
> When the OS first initializes and the Homescreen populates the pages with icons for the first time - Evme code is required in order to create the "3 app" icons. (I'm not totally certain about this) It can be resolved in this bug 911961. It is working on my device extremely fast > But, clicking a Collection icon and waiting idly for over 2secs is too painful. I think the user expects icons on the grid to open instantly Yep, I realized that it takes a lot of time if the users try to open them while ev.me is loading logically. 1) We could show them disabled while ev.me is loading (easy) 2) or.. move the functionality that implements the open animation for collections to the homescreen part and when the info it will be ready, the collection will be filled (more complicated) 3) more ideas?
Flags: needinfo?(ran)
Flags: needinfo?(21)
(In reply to Cristian Rodriguez (:crdlc) from comment #8) > 2) or.. move the functionality that implements the open animation for > collections to the homescreen part and when the info it will be ready, the > collection will be filled (more complicated) From UX standpoint this is much preferred to showing them as disabled. As a general rule interface elements should react immediately (100-200ms) to user touch.
Cristian: 1. Sounds easy enough 2. Yeah, that's what I suggested in my #3. We should probably do that eventually.
Flags: needinfo?(ran)
Cristian I think we can mark this as a duplicate of Bug 910331
Flags: needinfo?(crdlc)
For sure
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: needinfo?(crdlc)
Resolution: --- → DUPLICATE
Flags: needinfo?(clee)
Flags: needinfo?(21)
You need to log in before you can comment on or make changes to this bug.