Ubuntu
unity8 package

Refreshing scopes data when using a poor connection produces a really bad user experience

Bug #1417780 reported by Ricardo Salveti
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Confirmed
Undecided
Alejandro J. Cura
unity-scopes-shell (Ubuntu)
Triaged
Undecided
Unassigned
unity8 (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

(Not sure if this is the best package/project to cover this bug, feel free to change it)

current build number: 224
device name: krillin
channel: ubuntu-touch/ubuntu-rtm/14.09-proposed
last update: 2015-01-29 18:53:09
version version: 224
version ubuntu: 20150129
version device: 20150129-c75dcfb
version custom: 20150129-528-26-182

The scopes content disappears completely when you try to refresh it when using a poor internet connection, because it blanks the previous content without giving any new ones (until you get a proper connection again).

This produces a really bad user experience because the user ends up with a set of blank scopes, without any content (while the previous data could be useful in some way).

As a user I'd expect the data to be dynamically updated (visually at least) as you get them, with a proper notification for the user.

Revision history for this message
Michi Henning (michihenning) wrote :

Not related to unity-scopes-api

affects: unity-scopes-api (Ubuntu) → unity8 (Ubuntu)
Revision history for this message
Michi Henning (michihenning) wrote :

Not sure how feasible this would be from the shell's perspective. But the only option I can see is to delay wiping the screen until the first result for a new query arrives. The question is then how to make it clear to the user that no results actually arrived if the connection is dead.

Revision history for this message
Michał Sawicz (saviq) wrote : Re: [Bug 1417780] Re: Refreshing scopes data when using a poor connection produces a really bad user experience

W dniu 08.02.2015 o 11:53, Michi Henning pisze:
> Not sure how feasible this would be from the shell's perspective. But
> the only option I can see is to delay wiping the screen until the first
> result for a new query arrives. The question is then how to make it
> clear to the user that no results actually arrived if the connection is
> dead.

This is something we planned to improve the visual experience in any
case. It's the shell plugin that holds the model, so it would have to
not clear it until new results arrive. We would also show a "query
failed" banner or something, similar to the one we planned for no
internet connection at all.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in unity-scopes-shell (Ubuntu):
status: New → Confirmed
Changed in unity8 (Ubuntu):
status: New → Confirmed
Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

bug #1238979 is related

Changed in canonical-devices-system-image:
assignee: nobody → Alejandro J. Cura (alecu)
status: New → Confirmed
Revision history for this message
Paweł Stołowski (stolowski) wrote :

The bug #1238979 improves the situation with updates to the results model, but it doesn't solve the problem of poor connection.

For this to be possible I think we will need cooperation from scopes, because only the scopes know if all the data they serve comes from network and if old results should be preserved if network is not available. Scopes currently receive connectivity status with every search, so they can use push_surfacing_results_from_cache() method of the SearchReply to push the old results again without any extra work. We could make it even easier for scopes to handle this by enhancing CompletionDetails in scopes API with a new status such as InternetRequied (displays appropriate banner to warn the user) or InternetRequiredAndKeepTheResults (banner + keep old results on the screen) - but are easy to implement in the shell, but the bulk of work would be to update scopes to use it.

Changed in unity-scopes-shell (Ubuntu):
status: Confirmed → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.