-
Notifications
You must be signed in to change notification settings - Fork 6
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
Consider making home screen buttons behave like regular buttons #690
Comments
Assigning to @kathy-phet to get input on whether this is something that she would support. If so, we would add it so our list of upcoming "epics" and prioritize. |
Another advantage to switching sun button would be that sounds would be associated with UI components, not with Properties. Sounds are not currently associated with joist buttons, they are associated with Properties. So if someone changes (e.g.) the screenProperty via PhET-iO, they will hear a sound. |
The current home screen design was quite purposeful - to attract users into interact with the first screen first. I would be pretty hesitant to go with 4 equally sized buttons that go straight into the simulation. Can we use sun buttons and get the same behavior we have now? But this is very much a design question, so should be discussed at design meeting. |
And if @ariel-phet can make design meeting it would be good, because he did a lot of interviews on this design pattern when it was developed. |
I get design motivation -- emphasis of the first screen. But I've never been fond of the execution. Just about everyone who I've shown sims to initially has problems with the home screen buttons. It's very odd to have to click a button twice to select a screen. And it's very odd to have buttons change size - there are other ways to attract users to a button, for example putting a bright halo around it. Finally, the fact that the UX is so non-standard is mostly responsible for what is a complicated non-standard implementation. So I'm in favor of finding a way to achieve the UX goals with standard push-button behavior. I think it will improve the UX, and simplify the implementation. |
Changes to the buttons would impact the sound and description as well. We currently have sounds and description patterns in place. I'm not weighing in on whether changing would be an improvement or not, rather, just indicating that there are implications for the decision here across visual and auditory display, and all input methods - touch, cursor, focus (e.g., keyboard, switch, etc.). |
@emily-phet - Thanks. Good to understand implications. You were also very involved in the redesign of the home screen I believe. So if you have design insight, that would also be great to share. The designers also do a lot of interviews. I personally haven't seen any students have trouble with the UX when I teach with the sim, but I don't watch over them as much as the designers do. |
After considering this for a bit, I'm inclined to not invest our development and design efforts in a change here since it is likely to be a cascading impact of time and effort, with many more total hours than just fixing the behavior in the original issue which wasn't a big issue anyways. To change the home screen would involve resources from the design team, development team, a bunch of interviews, revisions, testing, and redoing the accessibility patterns which has the same iteration of work as the visual side. And its working as intended for students right now. We can touch base at an "in-person" meeting, but I know we have lots of high priority work, so please plan to move forward with fixing the original issue and not pursuing such a big change. Thanks. Closing for now. |
I don't think we should consider this proposal the means for solving #689, but more specifically for these two topics discussed in the comments above: (1) It would be a better user experience if tapping on a small homescreen icon takes you to the screen, rather than making that button large and requiring a second tap. The proposal (1) by itself does not mean that all the screen icons would need to be the same size--the leftmost or "most recently visited" screen could still be larger. If we don't have time to investigate this proposal now, I recommend to leave this issue open and on hold or deferred until we work on other Joist 3.0 issues #678 (comment) such as:
so we can keep it in mind as a potential improvement if/when we take time for more invasive changes. |
This is actually also a purposeful constraint that was designed specifically and pedagogically into the original sim. We did not want students to be taken into those screens with just one click. We wanted them to think before they leapt into that screen. We don't have the bandwidth to revisit this choice right now, because it would require a lot of design investigation around the implications of this change on student behavior with the sims. It's doing its pedagogical job as the constraint it was meant to be. I think its low likelihood we would pursue a redesign or change in behavior in the near term - with the other work we have on our plates. |
Understood--thanks for explaining the value of the design. |
The current screen-selection buttons on the home screen behave in a pretty non-standard way in that the user first has to select the button for a given screen, at which point it enlarges, and then the user needs to press the enlarged button. While discussing what to do about #689 during the 2/4/2021 developer meeting, it was suggested that rather than trying to solve problems that that result - at least in part - from the non-standard behavior of these buttons, we should instead consider making them behave in a more standard way. Several of the developers expressed support for this idea, since we've witnessed cases where people get confused by our home screen behavior, see #689 (comment).
For a reference on how the home screen buttons currently behave, here is a link to a sim with four screens from which to select: #689 (comment)
For a rough example of what the changed behavior might look and feel like, here is the Build an Atom game screen, which has four standard buttons for selecting a game level: https://phet-dev.colorado.edu/html/build-an-atom/1.6.15/build-an-atom_en.html?screens=3
The text was updated successfully, but these errors were encountered: