Cancelling sign-in after grading review says "Submitting now…" forever

[Matthew Paul Thomas]

Ubuntu Software Centre 3.1.24.3, Ubuntu Natty daily 20110327
software-center-gtk3 trunk r2169, Ubuntu Ocelot
Ubuntu Software Center 5.1.14.1, Ubuntu Precise

0. In a new user account, launch USC.
1. Find a software review.
2. Next to "Was this review helpful?" click "Yes" or "No".
3. In the sign-in dialog, click "Cancel".

What happens:
2. A spinner and "Submitting now…" appears.
3. The spinner and text remain.

What should happen: The spinner and "Submitting now…" text don't appear until you've signed in.

[Aaron Peachey (aaronp)]

Hi mpt, firstly, the fact that pressing cancel doesn't remove the 'submitting now...' message and return the UI to the 'pre-click' state is an issue that we need to fix.

In regards to the 'what should happen' in yout bug report:
When the user presses on Yes/No to submit usefuleness it spawns the submit usefulness app. This app signs in first before submitting the vote. If the user is already signed in, then the sign in process is just a verification (but distinct from the submitting of the vote), doesn't take very long and doesn't bother the user with additional UI.
However, if they need to sign in then the login window appears.

The issue I have with not showing the spinner and text until you've signed in is that we would be leaving the Yes/No links visible while that sign in process happens. For a user who is already signed in, the time between when they click Yes/No and the time when the spawned app is actually signed in and has commenced submitting the review may confuse them into thinking that their click didn't work and they may try to click again and subsequently spawn another instance of the submit usefulness app.

My reasoning behind implementing 'submitting now...' from the moment they clicked the button was so that the 'background' process was transparent to them (i.e. the distinction between sign in and submit is irrelevant if they don't need to interact - because they're already signed in) and they can simply keep reading reviews while the submit happens.

My suggestion would be to leave it as-is now, but just ensure that we return the usefulness UI to it's original state when the user cancels the sign-in dialog.

[Matthew Paul Thomas (mpt)]

Aaron, I agree it's good that the spinner appears once USC knows that you're signed in, so that (as you say) people can keep reading reviews. What isn't good is a spinner being used at a time when the computer is waiting for you. A spinner is never for when the computer is waiting for you. It's always for the opposite: for when you are (or might need to be) waiting for a computer.

Now, that's technically a separate problem from this bug. You could stop the spinner on cancel and fix this bug, while still having it spinning while the dialog is up. But if the spinner wasn't spinning while the dialog is up in the first place, then you wouldn't need to stop it specially here.

It's fine if the Yes / No links stay visible during the sign-in process. Links on Web pages do that all the time. What do you think of making them insensitive until the sign-in is either complete or cancelled?

[Aaron Peachey (aaronp)]

Hi mpt, this makes sense and we should be able to make the links insensitive while the dialog is up.

My only issue is when a 'silent' sign in is happening because the user has already entered their credentials and the sign-in is just the app using the token to sign in with the server. This happens without UI and can take a couple of seconds, I'm not sure about insensitive buttons while that's happening.

Essentially we have four 'states' when submitting a vote:
1. Signing in, dialog visible, waiting for user input.
2. Signing in, dialog visible, user input received and signing in with server
3. Signing in, no dialog visible, authenticating with server
4. Submitting vote, no dialog visible

Case 1: User has previously signed in
Then we have state (3) for a couple of seconds and then state (4).
My personal opinion is that a spinner should be visible on the review on the app details screen for both states 2 and 3 in this case, since the user is waiting for the computer to negotiate the vote.

Case 2: User has not previously signed in (or has no account or is unauthenticated for some reason)
Then we have state (3) temporarily (while we try to sign in, and figure out we need user input) then state (1) for a period of time while the user enters their input then state (2) actually signing in and then state (4).

So, in case 1 we should display the spinner during both states. Perhaps the text of the spinner should say 'signing in' during state 3 and 'submitting now' during state 4.

In case 2, we may need some thought, as this seems clunky to me:
State (3) - Spinner running, "signing in"
State (1) - Spinner stopped, "awaiting sign in details" (Alternative: Normal usefulness UI visible, Yes/No links insensitive)
State (2) - Spinner running, "signing in"
State (4) - Spinner running, "submitting now"

To qualify all of this, I'm not certain about what level of signalling we currently havefrom the submit_usefulness helper so all this UI changing may not be a quick fix, but should be possible with some tweaks.

Any thoughts?

[Matthew Paul Thomas (mpt)]

Why doesn't USC already know whether you're authenticated? It seems to me that the only time the spinner should start, then stop, then start again, is if you've changed your password on the Web interface -- so USC tries to authenticate with your old password, then puts up the dialog, then authenticates with your new password.

Annoying though it may be, there is some non-zero number of people who will think that they can't enter their sign-in details until the spinner stops spinning. :-)

[Aaron Peachey (aaronp)]

In a practical sense USC can already know that the user has authenticated but in every instances, the spawnedf helper app looks for the token and gives it to the server, so there is technically a 'sign in' step even though it is a formality if you've already signed in (unless the server has revoked the token in the interim).
Note when I talk about signing in, in this sense, I'm not talking about the user entering any credentials (or even any dialog showing) but more the process that is happening in the background between the client and server to 'handshake' before allowing submission.

[Matthew Paul Thomas (mpt)]

Ok, in that case I guess we can't practically avoid the spinner continuing under the sign-in dialog.