Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Toast with "Submit" button should not go away until clicked #10628

Closed
QuincyLarson opened this issue Sep 9, 2016 · 19 comments
Closed

Toast with "Submit" button should not go away until clicked #10628

QuincyLarson opened this issue Sep 9, 2016 · 19 comments
Assignees
Labels
scope: UI Threads for addressing UX changes and improvements to user interface

Comments

@QuincyLarson
Copy link
Contributor

The new submit button is in a modal of some sort that slides in at the bottom of the screen. And then slides back out - thus disappearing and removing the ability to submit the solution. Reported by @P1xt

@RevoQ
Copy link

RevoQ commented Sep 9, 2016

Hi Quincy,
Whatever this version is there are a couple of issues that popped up for me this morning.

  1. I used to be able to CTRL+ ENTER to submit and move forward to the next challenge. That is not an option and now I have to use my mouse. Also, aesthetically, it doesn't look as visibly clear that the challenge is completed as it was before.
  2. When I type, the cursor somehow keeps jumping to the top of the screen and the first line.
  3. The output display box no longer populates the answer after the challenge has been completed. It only indicates "completed."
  4. I agree with someone else post that this new functionally of the system indicating "i see some previous data" and loading is not something I like. It should give the option because when I go back to something I've completed, its because I want to do it again.

I'm using Window 8.1 and Firefox 47.0.1

my two cents,
Tai

@QuincyLarson
Copy link
Contributor Author

@RevoQ thanks for your feedback, Tai. We have open issues focused on addressing all four of these problems you mentioned. Firefox is especially rough at this point. All of these things are things we're working on.

@ltegman
Copy link
Member

ltegman commented Sep 10, 2016

@QuincyLarson Because react-notification requires a timeout the path of least resistance would be to set an obscenely high timeout value on this class of toasts. They would eventually disappear but it would only effect users who submitted a challenge and then went AFK for a long period of time. Would this be acceptable or does another solution need to be found?

@QuincyLarson
Copy link
Contributor Author

@ltegman I almost feel like we should move the "next challenge" button out of the toast and put it directly into the UI. It goes from disabled (perhaps with some animation) to enabled. Then we can leave the toasts as is (~6 second duration).

@jdbarras
Copy link

I'm having the same problem as @RevoQ with the cursor jumping to the top of the code window while typing. It's really annoying. Maybe this should be opened as a separate issue?

@ltegman ltegman added the scope: UI Threads for addressing UX changes and improvements to user interface label Sep 11, 2016
@BerkeleyTrue BerkeleyTrue added the status: waiting review To be applied to PR's that are ready for QA, especially when additional review is pending. label Oct 14, 2016
@QuincyLarson
Copy link
Contributor Author

@BerkeleyTrue and I will add a CTRL+S hotkey (which will be visible in the submit tab.) This way campers can either click the submit button in the toast (and that toast will not go away until dismissed) or use the CTRL+S hotkey.

@P1xt
Copy link
Contributor

P1xt commented Oct 15, 2016

@QuincyLarson Why have the submit button in a toast at all? Toasts are informational messages that, typically, can be ignored without compromising the functionality of an application. That's why they disappear... It's not not really a "best practice" and, though I can't know for certain without actually seeing how it's implemented, I'm a bit dubious that it wouldn't introduce accessibility issues. Shouldn't a button you have to click to proceed be part of the main content of the page, right in the same section of the page as the last button you clicked.

@QuincyLarson
Copy link
Contributor Author

@P1xt a few months ago, @BerkeleyTrue and I determined that it was awkward to look over at a toast, then to look back to the directions area and click a "go to the next challenge" button. In practice, I believe most people will just click the hotkey and it won't be a big issue.

@Bouncey
Copy link
Member

Bouncey commented Oct 15, 2016

@QuincyLarson I would rarely use hotkeys to navigate a webpage. I never knew that keying 'ctrl + enter' for a second time advanced to the next challenge until I saw the issue saying it wasn't there any more.

If you don't like the idea of a separate toast and submit button, we could animate a show/hide toggle between a 'Run tests' and 'Submit' button in the side panel. The logic can be set up so that once the camper has passed the challenge, the run tests button disappears and the submit button appears. If the camper then changes their code, the buttons revert to the initial state of submit hidden and run tests visable

@Bouncey
Copy link
Member

Bouncey commented Oct 15, 2016

Toast accessibility can be helped with the alert role

@P1xt
Copy link
Contributor

P1xt commented Oct 15, 2016

@QuincyLarson the beauty of toasts is that they contain information that you don't have to waste your time looking at if you don't want to. Or, rather, that they're "supposed to" contain only non-critical information.

@Bouncey Oddly, the removal of the "double" Ctrl-Enter to test then submit was pretty much the first thing noticed in the new interface by those of us who use it.

Toggling the state so the run tests button is replaced with a submit button when appropriate is an intuitive solution that makes rather a lot of sense from a UX perspective.

@QuincyLarson
Copy link
Contributor Author

@P1xt yes - I also used the CTRL+Enter shortcut exclusively.

This is a good point about toasts generally being optional (ignorable) information for the most part. If we did this, the toasts could go away on their own, which is the expected behavior.

We could replace the "run tests" button with a "submit and go to next challenge" button, and leave the toast as an optional "You got the touch" type congratulation message. Then we could leave Ctrl+enter as the go to the next challenge hotkey, instead of introducing a new hotkey like Ctrl+s.

@BerkeleyTrue mentioned a reason why without the congratulations modal, it's difficult to use the same hotkey to advance to the next challenge. @BerkeleyTrue do you remember what the reasoning for this was?

@Bouncey
Copy link
Member

Bouncey commented Oct 15, 2016

@QuincyLarson I am literally putting the finishing touches on the animation between the two buttons. Shall I open my PR again?

@Bouncey
Copy link
Member

Bouncey commented Oct 15, 2016

This is what I have so far @QuincyLarson

anim

@Bouncey
Copy link
Member

Bouncey commented Oct 15, 2016

As for the key binding, if the PR is merged, it can be done like this:

'Ctrl-Enter': function() {
        if (isChallengePassed) {
           submitChallenge();
           return false;
          }
          executeChallenge();
          return false;
        }

I have had this working locally

@QuincyLarson
Copy link
Contributor Author

@Bouncey I just thought of a corner case. What if a camper wants to continue experimenting with their code without resetting it. In that case, they may be annoyed that the run tests button has disappeared.

Also, we are avoiding animation in favor of instantaneous changes. People get seemed to get annoyed at even millisecond animations if they are preventing them from moving forward.

So I am not sure how to proceed. Currently we have the modal that pops up, and can be dismissed, but that blocks code.

We are looking for a solution that is:

  • obvious to people, with virtually no possibility of misunderstanding that they can now advance to the next section.
  • allows people stay and continue working on the challenge even if they've passed

The more I think about it, having an alternate submit hotkey and button like @BerkeleyTrue originally suggested is the best way forward.

Keep in mind that once we have our multi-field input system...

with an additional map and challenge directions to the left - essentially 6 vertical sections - we will probably need something that pops up in the middle. So we may want to stick with our current modal system which is unmistakeable, and remove the toast for when a challenge succeeds. That way we wouldn't need to change the ctrl+enter flow - nor would we need to modify the UI at all.

@Bouncey
Copy link
Member

Bouncey commented Oct 15, 2016

@QuincyLarson as you can see from the gif, run tests is pressed and the challenge passes, I then add new lines in the editor and the run tests button comes back. This is delt with in the handleChange method for code mirror.

There are no great shakes about adjusting the animations, I can remove the animations completely if required. Styling can be adjusted.

I remember you saying somewhere that users do not like modals.

@QuincyLarson
Copy link
Contributor Author

@Bouncey that's correct. Users don't like modals generally. But I think we should continue to do as we're doing until we find a more elegant solution. So far none of the solutions I've seen are more elegant than the old fashion modal.

I recommend we remove the animation from the modal so it just instantly appears. Also, I noticed that the green checkmark animation passes right through the letters above it, so we should remove that animation, too. At least this way it will be fast and obvious, and users will now how they can exit back to the challenge (by clicking outside the modal or clicking the x to close it, or clicking escape).

@Bouncey
Copy link
Member

Bouncey commented Oct 17, 2016

I am currently working on a new success modal

@Bouncey Bouncey mentioned this issue Oct 17, 2016
10 tasks
@BerkeleyTrue BerkeleyTrue removed the status: waiting review To be applied to PR's that are ready for QA, especially when additional review is pending. label Dec 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scope: UI Threads for addressing UX changes and improvements to user interface
Projects
None yet
Development

No branches or pull requests

7 participants