Closed
Bug 1022546
Opened 10 years ago
Closed 10 years ago
[Vertical] Homescreen should show a placeholder/loader while new Collections are being created
Categories
(Firefox OS Graveyard :: Gaia::Homescreen, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 1026140
People
(Reporter: amirn, Unassigned)
References
Details
When installing a new app from the marketplace, a placeholder loader is shown on the homescreen while the app is installed. When the app is ready, the loader is replaced with the app's icons.
This shows the user that the installation process is ongoing.
Currently this behavior does not apply to Collections, so when adding new collections it looks like nothing is happening.
Reporter | ||
Updated•10 years ago
|
Blocks: collection-app
QA Whiteboard: [VH-FC-blocking+]
Comment 1•10 years ago
|
||
Amir - does this happen with the current homescreen? It doesn't seem like it would be difficult to do, but I'm not sure what events you listen to. Currently the homescreen gets a datastore event to add the collection, but at that point there's nothing more we need to wait for - we can just display the collection as it should be ready.
Flags: needinfo?(amirn)
Reporter | ||
Comment 2•10 years ago
|
||
good point. I guess what we can do is:
1. activity.postResult(numberOfCollectionsAdded)
2. homescreen paints a loader for every new collection
2. on datastore event dismiss the loaders and show the real icons
wdyt?
Flags: needinfo?(amirn)
Comment 3•10 years ago
|
||
Sure, I guess before we do this we should do a quick profile to see how long it really takes, and if it would really be worth it. The collection icons appear pretty quickly for me after adding them. Seems like possibly a nice to have and maybe not required?
Updated•10 years ago
|
QA Whiteboard: [VH-FC-blocking+] → [VH-FL-blocking+][VH-FC-blocking+]
Comment 4•10 years ago
|
||
Our user perceived acceptance criteria state that the user needs to see a response within 100ms. I went ahead and profiled this on a flame and it appears we start rendering at < 100ms. Additionally the spinner would be so short it may be more disorientating to the user than not having one.
I do think that we should investigate this to see what kind of UX it would achieve, but I don't think it's necessary for 2.0.
Ni? on Jason to reconsider VH-blocking flags, I'm not sure what they mean, but I would like to - on them. If we get around this we can still ask for uplift into 2.0, but I don't think it should be a priority.
Flags: needinfo?(jlorenzo)
Comment 5•10 years ago
|
||
Appears I actually did a ni? on Johan, but either one of you guys is free to chime in. Thanks!
Comment 6•10 years ago
|
||
This is nice cleanup work, but definitely not a blocking issue.
QA Whiteboard: [VH-FL-blocking+][VH-FC-blocking+] → [VH-FL-blocking+][VH-FC-blocking-]
Flags: needinfo?(jlorenzo)
QA Whiteboard: [VH-FL-blocking+][VH-FC-blocking-] → [VH-FL-blocking-][VH-FC-blocking-]
Updated•10 years ago
|
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•