Is it time to pursue a Joist 3.0?

[ariel-phet]

Joist is a fairly fundamental piece of our HTML5 infrastructure, but since it was initially developed early on in the project, it might be time for a more involved refactor/revision to support future goals.

Certainly with the "global controls" work, iO requirements, and recent large refactors of components like buttons, it seems like a good time to investigate this question.

@pixelzoom has certainly been an advocate for this work, and I would appreciate his thoughts here. @jessegreenberg would also be an important voice as I believe he is likely to be spearheading much of the "global controls" work. Also currently assigning @samreid since I believe he has done a significant amount of Joist work. Tagging for developer meeting as this discussion should involve the whole team, but I would prefer to be around when the larger team discussion takes place.

In particular, it would be good to understand the scope of what we would envision in a Joist 3.0 and try to break that work into a number of issues/tasks.

NOTE: I will be tagging a couple of issues as related to this work. Some of those issues may be closed since the problem the issue noted had been solved, but could potentially be done in a more robust way as part of a reworking of Joist.

[pixelzoom]

Here's my input.

First, triage the 83 open issues in joist. This repo is suffering from bad hygiene. There are may too many ancient/stalled issues. Wrap issues up, and boil it down to what needs to be done for joist 3.0.

The big chunks of work for joist 3.0 are:

(1) Revise/rewrite the joist button hierarchy (JoistButton, HomeScreenButton, NavigationBarScreenButton, etc.) Leverage sun buttons if possible. This would probably address #689
(2) Rewrite the navigation bar. Layout has gotten way too complicated, it’s not general, and it's buggy (#673)
(3) Reduce coupling between components, especially Sim, #188
(4) Standardize layoutBounds throughout. Eliminate dependencies on specific layoutBounds (e.g. NavigationBar depends heavily on HomeScreenView.LAYOUT_BOUNDS for some reason, which caused grief for #640)
(5) Replace LookAndFeel with ColorProfile. E.g. in NavigationBar, instead of the weird “light” and “dark” stuff. #222
(6) Associate animations with screens, #404
(7) A11y: Identify deficiencies and requirements for joist 3.0. (There are open issues related to a11y that are outside of my wheelhouse.)
(10) PhET-iO: Identify deficiencies and requirements for joist 3.0. (Based on structure of the Studio tree, it seems like this may be in pretty good shape. But I'm not sure. It's probably a matter of making sure that we don't accidentally change the structure of the Studio tree.)

Work that overlaps with sun:

(11) Eliminate BarrierRectangle. Develop a framework for popups (glass pane, or whatever), use it for dialog, menus, listbox, etc. via Popupable
(12) Use Popupable for PhETMenu

[pixelzoom]

12/10/2020 dev meeting

@ariel-phet wanted feedback on whether joist 2.0 (or any of the identified changes) is necessary to add the new "Preferences & Quick Access" feature. @jessegreenberg gave an overview of that feature.

@pixelzoom said that there's nothing blocking this new feature. But the new feature involves (at least) navigation bar, dialogs, layout bounds -- all things that have been identified as needing work. Addressing those things first may make it easier to add the new feature. Adding the new feature (depending on how it's done) before addressing these issues may make addressing them more difficult later.

@jessegreenberg agreed that it would be good to address some of these issues before adding the feature, but not essential.

[jessegreenberg]

Of the list mentioned in #678 (comment), I think the things that would be good to work on before the "global controls" work would be

Rewrite the navigation bar. Layout has gotten way too complicated, it’s not general, and it's buggy (#673) (Another button added to navigation bar, may want to rework the container for the "a11y buttons" in A11yButtonsHBox)
Replace LookAndFeel with ColorProfile. E.g. in NavigationBar, instead of the weird “light” and “dark” stuff. #222 (The quick access menu will need to respect the selected color profile, best to not add a usage of LookAndFeel)

Another that I will be thoughtful of is:

Reduce coupling between components, especially Sim, #188

I don't think changes for this would touch "global controls" related work, but I can be careful not to add more of this coupling. I suspect other issues can be done separately, though more overlap might become clear as we get farther in development.

[zepumph]

From today's dev meeting, "Someone said that we are already on 2.0, so now it's time for 3.0."

[samreid]

At today's meeting, @pixelzoom and @chrisklus and @samreid and possibly @jessegreenberg agreed to meet to triage and prioritize the parts of this issue.

[samreid]

@pixelzoom @chrisklus and @jessegreenberg would it be efficient for us to asynchronously review the open issues and #678 (comment) and comment on proposed priorities, or should we frame this as a working meeting? If we can begin asynchronously, how can we synchronize our triaging without duplicating too much work?

[pixelzoom]

I've already done my triaging, and the results are in #678 (comment). I've edited that comment to number the "chunks". Highest priority imo are (2), (1), (4), in that order.

[chrisklus]

@pixelzoom @chrisklus and @jessegreenberg would it be efficient for us to asynchronously review the open issues and #678 (comment) and comment on proposed priorities, or should we frame this as a working meeting? If we can begin asynchronously, how can we synchronize our triaging without duplicating too much work?

I would prefer to meet and have a discussion for remaining triage and prioritization

[samreid]

I looked through open issues and, working with @jessegreenberg and @zepumph, we were able to close 15 of the open Joist issues. I reassigned or commented on other issues where appropriate. I opened one new issue #691 about improving the startup time of our simulations. We met this morning about this issue, and @pixelzoom volunteered to write up notes.

[pixelzoom]

2/16/21 subteam meeting with @samreid @chrisklus @jessegreenberg @pixelzoom

Conclusions:

• This issue and the term "Joist 3.0" implies that we're going to create a new version of joist. That's not the case, and is not needed. There are some joist GitHub issues that need to be evaluated, prioritized, and scheduled to make joist better, not replace it with something entirely new. Those GitHub issues can be evaluated individually. So this issue can be closed.

• The reason that this issue was created is that there is work that has been reported (in GitHub issues) that is not getting done or even evaluated. This builds technical debt and sometimes makes it impossible to move forward (e.g. Home screen uses non-default layoutBounds #640). And this problem is not unique to the joist repo.

• There is currently no ownership of common-code repos, and no one is responsible for their "health". (scenery and kite might be considered exceptions.). Lack of ownership makes it more likely that no one is managing GitHub issues, or motivated to evaluate and schedule work needed to keep these repos healthy.

• Developers should be encouraged to look for opportunities to improve common code, and time should be made available for them to do that. For example, @jessegreenberg mentioned that he'll be adding more a11y-specific fields to Sim.js, and it would be preferrable to do that in a way that addresses remove dependencies on {Sim} sim in numerous constructors #188 (by factoring out a11y responsibilties into a delegate class.)

• PhET needs to generally improve its process for managing GitHub issues, especially for common-code repositories and cross-cutting work. This is essential for code "health", Quarterly Planning, and day-to-day management. Individual developers can make recommendations about which issues to work on, but a birds-eye (management) view is needed to prioritize and schedule. A couple of things that could be done to improve issue management:

  • Have management review all GitHub issues more frequently, to guide day-to-day management of developer resources, and to provide input for Quarterly Planning.
  • Assign each common-code repo to a specific developer. On a regular basis, have developers report on the status of each repo, including recommendations about what work to do next.
  • Identify and create reporting tools that would make it easier to manage GitHub issues. PhET has a relatively large number of repos. What questions should we be asking about the state of those repos? Do simple GitHub queries answer those questions, or is more support needed?

Addressing this issue is included in 2021 Q1 goals. So assigning to @kathy-phet to decide how to proceed, and whether to create additional GitHub issues or goals based on the above conclusions.

[jessegreenberg]

This was discussed during planning meeting on 1/12/21.

"Identify and create reporting tools that would make it easier..."

We pulled this into the project board to be worked on and discussed. Issues exist for the remaining issues here and they will be managed by the "responsible developer" as the processed is described in #678 (comment). As mentioned in #678 (comment) we will otherwise not start a "Joist 3.0" project. So this issue can be closed.