GUI Component Library

Derick Montague Derick.Montague at ibm.com
Thu Nov 28 03:39:30 AEDT 2019


> Yes, agreed that with additional collaboration we can continue to polish the design – in all cases, both the existing UI and my proposed designs can continue to look cleaner with more time and collaboration.
 
Using a static style guide will help as we transition to Bootstrap-Vue and rewrite the framework. Our current plan is to replicate the existing UI. If we can find a consensus on foundational items like typography, vertical rhythm, color palette, and button styles, we would document them in the style guide. This conversation is more efficient using an existing standard and discussing the need for change before making changes and then discussing them. 
 
> I wanted to share our work once we’d gotten initial working designs, and did not feel it was important to invest further time in them before beginning the stylistic conversation we’ve been having, since as we collaborate, it’s efficient to address details in the process and after some of the bigger issues are agreed upon.
 
Designing with code and then reviewing is not how we design. However, we understand there are different philosophies around the design process. We use static mockups to review and iterate quickly. Even with some of the changes currently being proposed, there aren't any clear expectations. The use of a style guide would resolve that.
 
> I also believe that with some CSS consolidation – which is something I’ve been working on downstream - many elements would be easily standardized and consistent.
 
It would be great to be able to review those changes upstream and move forward with those types of improvements. I feel that the cleanup effort should precede any design changes to make the implementation easier. I expect that the cleanup effort also includes the proposed design changes, which is a concern.
 
> I do have concerns about the dynamic nature of the site’s development and the potential static nature of a design guide. I wonder if it might be best to continue working towards consensus with our concept process, and then revisit the style guide once we get a little further towards that consensus.
 
The goal of the style guide is to document our consensus. It would be helpful to agree on some of the foundational aspects of the application to make the concept process easier.
 
> We could revisit the design library, which I do think is a good potential option if we can agree on one, or we could make a concerted effort to clean up CSS, to make it more of a sitewide style guideline in and of itself, during this collaboration as well.
 
The style guide is the agreement. Its documentation can be used to validate any changes to the code. We could continue to clean up the CSS now, but would not be a great use of our time since we will be doing that as part of the framework update. We are currently working on the prototype after our agreement in the last GUI Design Workgroup to move forward with a Vue rewrite.

Unfortunately, we can't take the existing code base and migrate to Vue and the Bootstrap-Vue component library. The current codebase uses both the Bootstrap and Foundation libraries but does not leverage the benefits of either. We need to create custom theming and take advantage of the library to minimize the need for theme overrides. We will address this with the framework update, along with leveraging Bootstrap 4's use of SCSS theming.

We need to establish foundational agreement and document those decisions in a style guide as we move forward. Otherwise, we will be wasting time developing code that we would have to rewrite.

Regarding using the site as a style guide, the lack of documentation is the reason the codebase lacks consistency in both design and implementation. Relying on the site to inform future collaborators on how to create new layouts will eventually result in the issue you are currently trying to solve.
 



More information about the openbmc mailing list