Top Level PDOM Structure and Guidelines for use of term "Play Area"

[emily-phet]

Since starting the development of the initial PDOM, we have discussed how to have a consistent top-level structure that can be used across sims. Our early work with BASE and CL:B resulted in the current structure:

• Scene Summary
• Play Area
• Control Panel
• Sim Screens, Resources, and Tools (or "Resources and Tools" for single screen sims)

As we encountered new sims, we have been selecting what goes into the Play Area on a case-by-case basis. This has become the current standard (though not all PDOM structures follow this exactly):

The Play Area consists of all objects (interactive or not) that:

• Require interaction to "start" the sim (e.g., play buttons, turning sources on, etc.)
• Are involved in "target phenomenon" or is an object involved in a key relationship intended to be conveyed by the sim (e.g., Plinko's pegboard, MAL's light source and molecule selections)

Changes in view, layering on a visual representation, adding/removing objects, and peripheral tools, are not considered part of the Play Area.

Thoughts on deciding what goes in the "Play Area": One way to think about what goes in the "Play Area" is to consider where a users navigation focus will likely be during the most dynamic aspects of sim use (e.g., where will their focus be while receiving multiple alerts of dynamic behavior). Interactive objects that can receive focus and selecting or adjusting these objects will result in multiple updates of dynamic behavior in the sim should be considered for inclusion in the Play Area.

Proposal regarding use of term "Control Panel" in the PDOM To avoid conflicts with typical use of the term "Control Panel" (to refer to individual visual boxes containing controls in sims) I propose we change this heading in all PDOMs to "Other Controls."

[terracoda]

Example sims, thus far BASE Sweater, Balloon(s) and Wall are in the Play Area which is described as a small room. All UI controls starting with the Remove Wall button are in the Control Panel. In this sim, I described these UI controls as things that "change conditions in the room. Note that in this sim 2 out of 4 of the visual sim objects (the balloons) are directly interactive."

OL The Equation, the Circuit and the the Slider Controls are all in the Play Area. The Control Panel contains the Mute Sound button and the Reset All button. In this sim, the visual objects, the Equation and the Circuit are not themselves directly interactive. A student must play with the sliders to make changes to the model.

RIAW Is set up the same way as OL.

JT The Leg Swing slider and the Hand position slider are in the Play Area. Like BASE's balloons, John's arm and leg are the interaction and the visual (at the same time). In reality the key parts of the Play Area are John's body, his arm, his leg and the rug. Only John's arm and leg are directly interactive. The Mute Sound button and the Reset All button are in the Control Panel.

[samreid]

@terracoda or @emily-phet can you please summarize today's conversation, with an emphasis on what decisions were made and what open questions remain?

[terracoda]

@samreid, I will try to get a summary posted asap. There certainly seems to be concern that the current terminology used for the high-level PDOM structure is controversial. I am glad we are discussing it with the wider team.

Based on my notes from the meeting, I don't think a decision has been made yet. Comments and ideas have been generated:

• Need to distinguish Primary UI options and Secondary UI options
• Play Area is not conceptually separate from UI controls
• Play Area as representation (readouts, etc)
• Controls that go in the Play Area are things they actively effect the Play Area, and controls that go in the Control Panel effect representations in the Play Area.
• Other possible headings generated from yesterday's meeting and Tuesday's meeting:
  • "Play Area Options"
  • "Utilities"
  • "Play Area Controls"
  • "Auxiliary Controls"

Other things that were mentioned

• Exploration Space vs. Play Area (also not under debate)
• Scene Summary vs. Screen (also not under debate) - "Scene Summary" is more general. Keep in mind a screen may not be used by some visually impaired users.

More thoughts and summary to come.

[emily-phet]

Moving forward, I think we’ll:

• Continue to make final decisions on structure on a sim-by-sim basis
• Keep the wording “Play Area”
• Keep the wording "Scene Summary" - it does describe the scene. When there are multiple scenes within a sim it will describe the current scene. Contact EM for an example if there is still concern over this.
• Consider wording for a new H2 heading that would come after “Play Area”, but before “Control Panel” (or whatever the final wording for “Control Panel” becomes)

I believe this would allow more flexibility than we currently have while still meeting the original goals of consistency, understandability, (relative) simplicity, and indicating to even young kiddos the intended priorities of content.

Here's what the PDOM structure would look like this:

• Scene Summary
• Play Area
• [New Heading, e.g., “Other Play Area Options"] - optional for simpler sims
• [Control Panel - with new wording. Would include things like peripheral play/pause buttons, sound on/off, reset all, etc.]
• Screens, Resources, and Tools

[ariel-phet]

Just a thought for an alternative structure:

• Scene Summary
• Explore (is it crazy to use an "active" title like this...I think it gets the idea across nicely)
• Exploration options
• Settings and controls (I think by putting settings first, it de-emphasizes controls, settings being things like sound, reset....controls being play/pause and such)
• Screens, Resources, and Tools

[terracoda]

@ariel-phet, regarding https://github.com/phetsims/a11y-research/issues/84#issuecomment-362758484, I don't think it is crazy, but I do think using active verbs works best for describing objects and controls that are actually interactive.

For example, I like to use verbs whenever possible for labels for controls and for associated help text (i.e., an interaction hint) that might be needed.

Sim Examples:

• BASE: Hint at end of Scene Summary: "Grab balloon to play." Then later a label for a button, "Grab Yellow Balloon".
• Plinko: a possible hint might be "Drop balls to play."

[pixelzoom]

My 2 cents:

• Avoid using terms that already have meaning elsewhere in PhET. "Scene" is particularly problematic, and was the source of much confusion in last Thursday's discussion. The meaning of "scene" in PDOM and sim design are currently totally different. "Play Area" also muddied the waters.

• Avoid inventing new terms for things that already have establish terminology in PhET, unless the PhET terms are too technical to be public facing. For example "Screens, Resources and Tools" is widely known as the "navigation bar".

• The UX literature is full of information about multiple representations for structuring and describing user interfaces and user interaction. Has this literature been reviewed? Is there anything relevant that can be reused, instead of (re)inventing something? This is especially important if you plan to publish in forums related to UX or CHI.

[emily-phet]

@pixelzoom

Avoid using terms that already have meaning elsewhere in PhET. "Scene" is particularly problematic, and was the source of much confusion in last Thursday's discussion. The meaning of "scene" in PDOM and sim design are currently totally different. "Play Area" also muddied the waters.

Our use of "scene" actually aligns quite nicely with the current use of the term. Imagine a sim that has scene selection buttons - the PDOM describes the current scene. When a new scene is selected, the PDOM updates to then describe the new scene. Just imagine that sims without a scene selection button have one (unchanging) scene, and I think you'll get the idea.

Avoid inventing new terms for things that already have establish terminology in PhET, unless the PhET terms are too technical to be public facing. For example "Screens, Resources and Tools" is widely known as the "navigation bar".

The use of Play Area in the PDOM stems from (and is intended to have a very similar - if not the same - meaning). In the same way that PhET can invent terms to serve specific needs, we can also expand use of these terms to address new needs as they arise. Our lack of inclusion of "Navigation Bar" in the PDOM has to do with the fact that this term would likely lead to confusion for users accessing description content. It's not "navigation" in a traditional use of the term, nor does "bar" mean much in a non-visual sense. We chose the current Heading because it effectively conveys what is useful to know about those specific options available - and does not require background knowledge or further investigation to make sense of what the heading means.

The`UX literature is full of information about multiple representations for structuring and describing user interfaces and user interaction. Has this literature been reviewed? Is there anything relevant that can be reused, instead of (re)inventing something? This is especially important if you plan to publish in forums related to UX or CHI.

In the same way that the design teams you're used to "pixel polish", the accessibility-focused design teams 'letter' and 'digit' polish. We have conducted extensive user testing, collaborate with world leaders in inclusive design, and we also attend and present at international HCI conferences (CHI, ASSETS, etc.) (and have been for years). We are well aware of the UX literature, as well as its limitations when it comes to the goals of inclusive design. If you'd like to learn more about our work, and how we align with accessibility standards and attend to UX conventions, we should go to coffee sometime. For our purposes here, I can assure you there are tremendous gaps in knowledge and conventions when it comes to the design of inclusive interfaces (e.g., created with the potential for simultaneous access through different modalities). An outcome of our work will likely be the setting of new conventions to be used by the broader community as we encounter and address needs not yet robustly explored, or in some cases, not yet even encountered.

[pixelzoom]

@emily-phet said:

Our use of "scene" actually aligns quite nicely with the current use of the term.

That's not what I heard from multiple members of the development team. I was told to mentally substitute the term "screen" where it appears in PDOM specification. "Screen" and "scene" are very different things in sim design and implementation. So if you're telling me they align nicely because they are the same thing, then I'm even more confused.

[emily-phet]

To be clear, I did not say screens and scenes are the same thing.

The functional use of 'scene' in the scene summary aligns with the use of the word 'scene' used by designers on teams you've been on. That is all I said. The pdom structure (as I wrote on the board Thursday) will change based on what scene you are on for multi-scene sims. The scene summary will only ever describe the current scene. So, it aligns with this use of the term 'scene'. For single scene screens, this still works. It is functionally as if sims without a scene selection button have one scene.

Use of 'screen' from a non-visual perspective is complex and frankly just does not do the work we need it to do. Not because some users don't know what a screen is, but a person's relationship to the screen is highly context dependent. For example, blind users don't necessarily have to have a screen. We have seen centers where visually impaired folks go to improve their computer skills have a 'no screen' policy. Some users have Braille devices that are like laptops, provide braille input/output, and have no screen. We've also seen users who utilize alternative input devices like an external keyboard leave their laptop tilted almost closed, just so the computer doesn't go to sleep, and then merrily interact away on their peripheral device. So we use screen only in a functional sense (there are X screens in this sim to select from), but we focus on painting a picture (a scene) when describing the objects to interact with. The result is that users select a screen, and once they make their selection they are provided a summary of the scene that they are to interact with, and this scene can change resulting in a corresponding update to the PDOM.

[jessegreenberg]

If the scene summary only includes information about the selected scene, than it does align with current terminology. But until now, we have been putting full screen descriptions under the scene summary.

Here is how I assumed that the document for the first screen of rutherford-scattering might look:

[h1] Rutherford Scattering
  [h2] (Currently called Scene Summary)
    - Description of the sim screen, including information about the play area, control panel, and
       user's ability to switch between atomic and nuclear scales (different scenes).
  [h2] Play Area
    [h3] [Label for the atomic scale view of the foil] - only visible in atomic scene
    [h3] [Label for the nuclear scale view of the foil] - only visible in nuclear scene
  ...(more stuff)

For this structure, the "Scene Summary" is using the term "Scene" when we have previously meant "Screen". If "Screen" is too physical, maybe another user friendly word can be used to label the screen description. Just brainstorming:

• Overview
• Display Summary
• View Summary
• Summary
• Setting

[pixelzoom]

@jessegreenberg There are a few things I'm still unclear on, related to a screen that has multiple scenes (e.g Hooke's Law, Rutherford Scattering, Unit Rates,...) Perhaps you or @emily-phet can clarify.

If "The scene summary will only ever describe the current scene", as @emily-phet said in https://github.com/phetsims/a11y-research/issues/84#issuecomment-363174581, then:

(1) How does the user get an overview of all the scenes that are available for a screen? Do they have to select each scene to get that's scene's description?

(2) Some controls are not part of a scene, and are shared by all scenes in the screen. Examples include the scene selection radio buttons, Reset All button, sound on/off button,... Where are these controls described?

[jessegreenberg]

The "Scene Summary" includes overview information for the entire screen. This includes information about the Reset All button, sound toggle button, and scene selection radio buttons.

So I disagree that "Scene" in "Scene Summary" aligns with how we have previously used the word, and I don't believe that the scene summary will only describe the current scene. It would best align if it were called "Screen Summary". @emily-phet listed problems with the word "Screen" so I suggested some other alternatives to "Scene Summary" so we don't overload the word.

[emily-phet]

@jessegreenberg I think we're getting into the weeds a bit here. I don't expect students to learn all our lingo and it's nuanced meaning. From the perspective of a user, the scene summary will change in response to scene changes. Frankly, what constitutes a "scene" in the historical sense of PhET's usage has never been clear to me. Sometimes it adds things, sometimes it replaces things, sometimes control panel information changes, sometimes not...

But most definitely the scene summary will not simultaneously describe all possible scenes, it will reflect the current scene. That's why I think the description aligns with how designers typically use it.

Ultimately though, I don't think this is a major concern. It works for the purposes it was intended for, and doesn't hurt anything else. :) It's also one of the easiest parts of the PDOM to write - I haven't had anyone ask questions about what should go in it yet - and initial drafts from folks are really good! The conceptual challenge with the Play Area affects how people structure what's in it, which is why I wanted to focus discussion originally around that part of the PDOM.

[emily-phet]

@terracoda Let's focus on selecting wording for two potential sections to go between "Play Area" and "Resources and Tools." One would be an H2 heading that has secondary sim-specific features, the other would be an H2 heading for common screen controls (reset all, sound, in some cases play/pause). At least the second of these will be needed for the publication of Rutherford Scattering and Plinko.

In general, we'll still go with using Scene Summary and Play Area, and make decisions of what goes in the Play Area on a sim-by-sim basis. Over time, and with more user testing, I'm sure it will start to become more clear what we like to have in the Play Area vs elsewhere. Then we can revisit the relationships between the PDOM play area, and the various other uses of Play Area within PhET.

[terracoda]

There has been some evolution on top-level sim structure:

• designers are happy with a change from "Control Panel/More Controls" to "Control Area".

And there is a design pattern for Multi-Screen sims on joist/doc/HomeScreen.md that people are still reviewing, but has receive positive feedback thus far.

@emily-phet, can we close this issue?