Closed Bug 999226 Opened 11 years ago Closed 10 years ago

perceived performance: spinner makes sending SMS feel really slow

Categories

(Firefox OS Graveyard :: Gaia::SMS, defect, P3)

Product:
Firefox OS Graveyard
Component:
Gaia::SMS
Platform:
x86
macOS
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1041765

People

(Reporter: dietrich, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [c=progress p= s= u=]) 

Often progress indicators are used to improve perceived performance - letting the user know something is happening.

However, in the case of sending SMS it actually makes it feel *slower*.

Currently when you send an SMS, the spinner loads next to the sent message bubble in the thread, and at some later point disappears, presumably when the some async system message is received, indicating the message has successfully been sent.

This means that every time I send a message I sit there watching the spinner, until it disappears. This can take a few seconds! It's excruciating.

If the spinner wasn't there, I would not sit there waiting. I would assume it worked, and that the system did what I wanted.

I tested Android's crappy default SMS app (Hangouts) as well as Hello, an awesome SMS app for Android. Neither show a progress indicator when sending messages.

Proposal:

1. Change: Remove the spinner when sending SMS

2. No change: If there's no connection available, gets a modal alert after hitting send, like we currently do. (That we let the user try sending is kinda bad, but that's for another bug!)

3. No change: If there is a connection and the message cannot be sent, we put the red X next to the not-sent message like we currently do.

4. Change: Because we make it appear that the message was sent immediately, if the message cannot be sent and there *is* a connection, we emit a notification indicating the message cannot be sent.
Requesting UX review for the proposed change.
Flags: needinfo?(firefoxos-ux-bugzilla)
We currently remove the spinner when the message leaves the device.

I agree with your proposal here.

Some refinements:

2), 3) and 4) could be changed to:
* If we're still in the thread, we mark the message in error and display the dialog like we do today.
* If we're not in the thread, we emit a notification (like when we receive a message), and when the user taps the notifiation we move to the thread and display the dialog.

2) is actually part of 3), that's why I merged them.

Redirecting the UX needinfo to Omega.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(ofeng)
Note that we don't need to wait that the spinner disappears. We can even kill the app, the SMS would still be sent, because Gecko does this.

The only cases where we can fail is if there is an error and the app is closed. Since we don't have a system message for this, the SMS app would never be notified. Note that we already have this issue today, including for read and delivery reports.
IMO, I think the conception here is that a spinner is a sync UI, i.e. spinners block the UI, hence needing to wait to continue interacting. On the other hand, I still believe it's useful with SMS messages to report whether a message has sent or not.

To me the better solution would be to either display an Activity or Progress bar, to give the user feedback that something is happening without being intrusive to the user in being able to interact with the app.
Keywords: perf
Priority: -- → P3
Whiteboard: [c=progress p= s= u=]
Flagging Carrie for UX feedback - Great discussion! (Carrie, I've added progress indicators as a topic for the building blocks working group.)
Flags: needinfo?(cawang)
(In reply to Eli Perelman from comment #4)
> To me the better solution would be to either display an Activity or Progress
> bar, to give the user feedback that something is happening without being
> intrusive to the user in being able to interact with the app.

Thanks Eli. The idea of this bug is that the presence of a progress indicator is what prompts the user to stop and wait. Changing the visual representation of progress will still have the same drawback.

The proposal is that instead the software will Instantly Do What You Want. This is what other systems do. It feels faster, increases user trust, and reduces visual noise.

> On the other hand, I still believe it's useful with SMS messages to
> report whether a message has sent or not.

The proposed new behavior still notifies when the message wasn't sent successfully (and Julien's suggestions improve that yet further).

Can you explain a bit more about why you think we should notify if it's sent?
Apologies, I don't mean that we need an actual notification that a message was sent, just feedback to the user that their interaction occurred. I agree 100% with your statements and solutions. Also, the concepts of "Instantly Do What You Want" are outlined at [1] for more info.

[1] https://developer.mozilla.org/en-US/Apps/Build/Performance/UI_Synchronicity
And even without the spinner, displaying the message report (long press on the message + "view message report) would still show the correct status "pending, sent, etc". So if the user wants to know more (sometimes a MMS can take an awful lot of time to send) he can.
(In reply to Dietrich Ayala (:dietrich) from comment #6)
> It feels faster, increases user trust, and reduces visual noise.

Not to mention reducing battery consumption: the spinner usually pegs the CPU at 100% usage for a few seconds which is probably going to burn an order of magnitude more power than what's needed to send the actual message.
(In reply to Rob MacDonald [:robmac] from comment #5)
> Flagging Carrie for UX feedback - Great discussion! (Carrie, I've added
> progress indicators as a topic for the building blocks working group.)

redirect to Omega. He's the Message owner! Thanks!
Flags: needinfo?(cawang)
Thanks Dietrich, this is a good observation and I agree we should do something about it. But since the spinner is a common control and it's placed everywhere in the system, we should make this a broader change and make the design/animation lighter and faster instead of just taking it out. The activities indicators act as a pattern and affect other scenarios in the system.

NI Przemek and Arnau to see if this can be scoped as part of v2.0 or if it needs to be considered as part of the v2.1 set of controls.
Flags: needinfo?(pabratowski)
Flags: needinfo?(arnau)
Victoria, still, we think that the spinner, even improved, could be taken out in the Messages app, in the case of sending a message.
I agree with Julien.

In the case of sending the message, the win from instant DWIW is far greater than the win of complying with a global pattern for no other clear reasons.

If you have a specific reason why removing the spinner when sending a message affects other scenarios in the system in a deleterious manner, please explain how.

Perhaps the spinner should be modified as part of a global pattern change, but that should be a separate issue.
I've had this conversation with Gordon in regards to implementing a general UX architecture that is Async First, which implements most of its components using Async UI. These terms are defined at [1]. Gordon, do you have anything to add to this discussion?

[1] https://developer.mozilla.org/en-US/Apps/Build/Performance/UI_Synchronicity
Flags: needinfo?(gbrander)
I checked on iOS 7, and they use a progress meter similar to the one we use in the Music and Email apps.

It feels very slow. We can do better.
(In reply to Dietrich Ayala (:dietrich) from comment #0)
> Often progress indicators are used to improve perceived performance -
> letting the user know something is happening.
> 
> However, in the case of sending SMS it actually makes it feel *slower*.
> 
> If the spinner wasn't there, I would not sit there waiting. I would assume
> it worked, and that the system did what I wanted.

I see your reasoning being: it's better to ask forgiveness when errors do occur than to prove to the user every time that they didn't (that's the idea behind https://developer.mozilla.org/en-US/Apps/Build/Performance/UI_Synchronicity).

I agree that this is the right user experience. There is one caveat, though: if we allow the user to assume we are reliable, we must be reliable.

* Silent errors must *never* happen.
* The user should be able to switch apps and the SMS should complete in the background.
* If the app is killed, the user should be informed that their SMS failed.
Flags: needinfo?(gbrander)
(In reply to Gordon Brander :gordonb from comment #16)

> * Silent errors must *never* happen.
> * The user should be able to switch apps and the SMS should complete in the
> background.
> * If the app is killed, the user should be informed that their SMS failed.

Actually, the SMS sending is done in the main thread, so the app can be killed without a problem already.

What we don't do currently is firing an error dialog in case of errors if the app has been killed. This would need a gecko+gaia change.
We'll look at this issue for the entire OS in 2.1, but for now this is mainly a messages issue.
Flags: needinfo?(pabratowski)
The spinner is an indicator to let user know the message is "sending". We can make some changes on that indicator, but we cannot remove the feature indicating that the message is sending.

I checked the following Messaging apps for sending indicator:
Android > Hangouts: Text (Sending -> timestamp)
Android > Line: Icon (arrow icon -> icon disappears)
Android > Facebook Messenger: Bubble background color (lighter BG color -> normal BG color)
iOS > Messages: A progress bar below header (progress bar growing -> progress bar disappears)

In the above apps, I personally think Facebook Messenger does the best job balancing indication and non-misleading. Hangouts is also a good reference for us, since it doesn't have the spinner and the text changing is not hard to implement for our current design.
Flags: needinfo?(ofeng)
Clearing ni, after Przemek and Omega comments.
Flags: needinfo?(arnau) → needinfo?(pabratowski)
Oops, Przemek for the ni, my mistake :)
Flags: needinfo?(pabratowski)
was changed in bug 1041765
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.