Switch to Material design system

Originally written at https://github.com/Trustroots/trustroots/pull/1386#issuecomment-613855632

I regret a little bit not taking the opportunity with React migration to just switch something else and phase out Bootstrap v3 together with old Angular files. At the same time, current approach (using React-Bootstrap) has the benefit of making React-migration easier since it won't involve any re-designing, and old CSS can mostly be re-used. Switching to something "incompatible" with Bootstrap also makes it easier to run the two systems in parallel, since they wouldn't collide too much.

My personal preference would be to phase out Bootstrap entirely and switch to a more comprehensive framework that also translates nicely to native mobile, has strong accessibility built-in, covers more components, has a stronger type system (as in "typography"), has theming built-in, etc.

By more comprehensive I also mean that I've been missing having a design-system that guides how to build sections, not just having a bunch of components available. That would make us depend less on having polished designs available since everything built according to the system would look more or less good and balanced with less effort (flows/mechanics aside, some design still needed of course).

The gold standard for all that is Material so I'd suggest we start at some point plan how to include it in the build pipeline, how to theme it for Trustroots and how to eventually switch everything over. Taking it as a chance to redesign some things would be great; e.g. I'd love to re-design navigation/information architecture in Trustroots if someone would be up for coding it. :-)

I would basically agree, as that's what we decided for karrot and i was strongly in favour of that.

But I wouldn't make this specific to material design, so it's two aspects to me:

using a framework that embodies a design system with more comprehensive set of components
using a material design framework

More concretely, https://ant.design/ is another such design which got popular, and there is even a whole totally overwhelming website cataloguing design systems --> https://adele.uxpin.com/

The other aspect is I started to have some doubts about is whether comprehensive frameworks actually live up to the promise of making it easier to develop (especially for beginners). In my experience the frameworks eventually run out of what they can do for you and you need to drop into a deep layer (override some css/js/whatever), and that is then a huge leap from just plugging together components and reading the docs.

Whereas on the other hand, people can actually learn html/css basics and contribute with an incremental increase in complexity. It somehow feels like skills are developed more when people are improving their underlying reusable skills than learning framework-specific things.

This is also a bigger philosophical topic for me on how to architect the web from a perspective of peer learning, easy participation, and long term resilience as opposed to whatever drives the approach of a big $$$ tech company (who have the money for fancy developers, and the need to keep changing things) - which is where much of our tooling is coming from (react, etc...).

Also, I have concerns that using very "industry standard" UI frameworks makes for a very "industry standard" feel too. User interfaces become commoditized. Although that would have also been true for bootstrap and the current site does not feel so commoditized because of nice colours/photos/etc.

I also mean that I've been missing having a design-system that guides how to build sections, not just having a bunch of components available.

To some extent also, the comprehensive frameworks don't actually provide it to sufficient degree to make it clear how to build UI - they have so many options of how you can use the components (as they are used across many different sites/contexts), whereas inside one specific site there needs to be a much more limited range of options available and bigger components (like page/section level layout).

Again, my example is in karrot, and despite us using a very comprehensive material design framework, our UI is still very inconsistent because the framework will never provide components at this higher level.

And we could actually build these higher level trustroots-specific "application framework" level components with our existing bootstrap tech too (in a way that doesn't prevent changing to something else in the future), and using something like storybook (see our karrot one https://storybook.karrot.world) to showcase them and their use.

I'm actually really curious how it would be to actually build all the UI components from scratch, now we have flexbox / grid CSS / react / scoped CSS / storybook / testing, etc... ... and for the fancy widgets, more standalone small libs (e.g. autocompletes), the comprehensive frameworks provide 250 components, when we only need 20, and most of them are basically lines and boxes.

... and as you mentioned about the overlap of this topic and mobile app dev, I think it could work to push forward new approaches in the mobile app, and let desktop follow (perhaps...), so maybe that is a nice outlet for trying out some new design thinking.

Sorry, that was a bit longer than I intended :)

Thanks for sharing thoughts Nick! — I overall agree with you on technical aspects and volunteer learning sentiments (as in "keeping this simple and closer to barebones"). I'm also not tied to Material design specifically or any framework that follows it; it's just one of the ones I'm familiar with and I know it is the level of design quality and extend I miss in Bootstrap. I'd hope we have framework where most of the time we wouldn't need to do CSS overrides on each view level — because that is heavy to maintain. Instead we'd have those overrides at our own shared component level. E.g. "hosting badge" component overriding framework's "badge" component.

Now that said, I think you're looking at this little bit too much from developer perspectice, and I did indeed hint towards that direction myself in initial comment.

I think it more from perspective of design where technical implementation for componentry is just a part of the system.

Comprehensive design system (such as Material) offers opinionated guidance on hierarchy of elements, and makes it easy for someone who isn't (strong) designer to follow sensible basic principles. Those are often lost without designer guidance. Such as; how much space between elements? What typescales to apply across the page? How many primary color buttons there can be on single page?

It doesn't completely remove need for design(er) of course but it helps. Some education is also needed so that people follow those princibles. Where I'm personally hoping to help is exactly the problem you mention; "ending up looking like industry-standard material design app". That's the case with any component framework and I had to deal with it when using Bootstrap as well. As you pointed out, TR still feels unique and not that much "Bootstrappy". :-)

Does that make sense? Happy to showcase Material (or study alternatives) together from this perspective. We could e.g. try it for references listing (or in mobile app!) and see how the process looks like.

Specific technical framework I don't have much opinion in; there are several good options to choose from and picking one is likely quite objective process.

Does that make sense?

I think my tech-perspective comes from that the reality of using a framework is you end up having to buy-into whatever is actually available, rather than come up with an ideal scenario and hope there is a framework to embody it (also because I'm dumb at design so I'm usually relying on the framework to help me get that higher perspective).

But, yes would be great to have a clear design system for all the reasons you mention. It's also a lot of skilled work, and possible to get by throwing components together and fixing all the shitty bits over time (... how a lot of projects work out I think).

I think you are offering to do this design system work though, and I think you're very good at this too. What seems interesting to me is creating a/the trustroots design system (with much higher level components and subsets of a component that are for official use) and it's maybe not even that many different components? Or rather I should ask, how would you see it progressing? What would you (I think as the only one with these skills) actually do?

(trying to keep the technical implementation aside, but sneakily writing a bit here: I could actually see an implementation in any of custom, bootstrap, or shiny new framework working out, with various tradeoffs for each)

Just briefly; I could totally see us use material design princibles (loosely) with bootstrap framework.

I think it would be helpful to have some design examples for the convo so maybe I'll follow up with those. Could also do that over a call+screenshare.

Trustroots / trustroots

Switch to Material design system #1390