Update UI components for `-core`

[rneswold]

As we've gained experience in developing the Parameter Page and Plotting apps, some of the decisions we made have been applied to the widgets in -core. However, at this moment, I feel we have three different solutions: the Parameter Page's, the Plotting app's, and core's (which no one is using.)

I'm opening this issue to start discussions on getting all applications to use a common, base library for their UI.

• What UI components/layouts do we like in Param Page and Plotting?
• Are there things we realized we didn't like in those apps?
• Change -core so it follows our desired design.
• Modify apps to use -core.

This will be an ongoing discussion until those apps have switched over. I've been trying to keep our flutter-template repo in sync with the changes we make to -core. This will help people writing new apps to start off with a compliant example.

The major stakeholders are @cnlklink, @madpolzin, @beauremus, @mguzman04, and @rneswold. But please invite others that you feel could help us.

[beauremus]

I think @mguzman04 and I can share our "getting started" experience as well as we've recently spun up the https://github.com/fermi-ad/autotune-app.

To start I can share that we used the ppage for reference for some things and it feels like a ppage solution and not a general one. I think we backed up and are using the core way of doing things.

[rneswold]

I'll start the discussion by saying I really like the plotting app's UI.

I like the thin icon bar along the left side. The top icon opens a menu which allows for more complex text and information. I would imagine that, on thin displays, the icon bar would be displayed along the bottom of the screen. Is that right? The menu icon would have to start in the title bar, though.

[mguzman04]

I was thinking of having a design system repository that has all our Fermilab Widgets. The idea is to have a library of widget (FermiButton, for example) that are available to all apps. These widgets could implement the material widgets with our own styling, or integrate a different design system (see #46). They could be implemented so that the styling properties are not shown, and this guarantees consistency, assuming devs use this library.

I'm not sure if this will be an issue, but the Flutter team has proposed a decoupling of the flutter core library from Material and Cupertino. If this introduces any breaking changes, this could potentially be contained inside this library

[rneswold]

I was thinking of having a design system repository that has all our Fermilab Widgets.

I guess we should decide what is the purpose of flutter-controls-core? I envisioned it being a package that provides core behavior that we expect all our apps to support. In my mind, this also includes the set of widgets that we developed.

[mguzman04]

I guess we should decide what is the purpose of flutter-controls-core? I envisioned it being a package that provides core behavior that we expect all our apps to support. In my mind, this also includes the set of widgets that we developed.

It sounds like we're in agreement, but maybe a different implementation. I also envision that all our apps should be getting their theming, widgets, etc from flutter-controls-core. I was thinking of having a separate repository for the design system that then gets bundled in to core so that all apps have this. By having in a different repo we can version them separate and keep the UI side of this separated.

Initial work on a design system has been worked on. This has been an implementation of the designs from Leah and Maddie. The idea was to include it into core. In fact I have a branch that would bring this into core that I'm hoping to open a PR soon

[rneswold]

"Design system" is too vague for me. What does it to? My brief look into it showed a theming system that looked cleaner than Flutter's, so that's good.

But "implementation of the designs from Leah and Maddie" sounds like widget design. Isn't that opposite of what you and I just said -core was offering? I'm not against them designing stuff at all! I'm trying to understand how it ties into -core. For instance, should I have added the ParameterPanel and ParameterPanelRow widgets to their repo?

[mguzman04]

Google's Material Design is a design system for example. It does a lot of what you said. It would provide a theming system that exposes tokens (variables) to abstract the hard coded values, allowing for theme switching for example. Also a set of common widgets for all our apps to use.

I see your point. Originally I was thinking I would bring in the package to core similar to the auth package and the process of moving out the GraphQL code out. Then any app would only directly depend on core. Maybe I misunderstood the intent?

[rneswold]

Ah. So -core directly provides the base Scaffold for apps and sets up the theming. But it also pulls in the needed dependencies. So -core is the one-stop shop to get everything.

I can get onboard with that. When you merge your bison changes, we need to move the two widgets I mentioned into the bison project.