GUI Component Library

GUI Component Library

[Derick Montague]

[-- Attachment #1: Type: text/html, Size: 8315 bytes --]

Re: GUI Component Library

[Jandra A]

[-- Attachment #1: Type: text/plain, Size: 3038 bytes --]

>
> We are working to compromise on a component library as we move towards a
> change to the GUI front-end framework. As discussed in previous emails to
> the list, we are planning on updating the BMC UI to use Vue. It is
> currently written using AngularJS, which will reach the end of its
> lifecycle on June 30, 2021.
>
>
>
> With this update, we are looking to select a component library that allows
> the GUI design/development team and any contributors to focus more on
> feature work and less on base-level components. IBM has proposed using the
> Carbon Design System. Carbon is an open-source library backed by IBM. We
> are advocating for this library for the following reasons.
>
>
>
> 1. Has an open-source community of Designers and Developers supporting the
> library
>
>
>
> 2. It is built with a user-centered approach that utilizes Design Thinking
> processes that include user testing and heuristic evaluation
>
>
>
> 3. It is compliant with the World Wide Web Consortium's (W3C) Web Content
> Accessibility Guidelines (WCAG).
>
>
>
> 4. The framework can be themed to meet the branding needs of other
> community members.
>
>
>
> 5. We agreed to and are using Carbon Design System icons
>
>
>
> 6. We are creating custom components using Carbon Design System patterns,
> e.g. LocaL User Management table. Using the Carbon Design System would
> allow us to bring in elements without the need to re-design or develop a
> new custom component in Vue.
>
>
>
> We are looking to discuss the use of other libraries and should choose one
> library. Using more than one library will add complexity with keeping all
> the utilized libraries up to date, create additional work to customize the
> library components to have the same look and feel, and could create
> confusion determining with components are being used
>
> from which library resulting in a lack of consistency within the
> application. None of the 3rd party libraries will likely meet all of our
> needs so when we are evaluating component libraries some of the criteria
> that need to be met includes:
>
>
>
> 1. Ability to create and use different themes
>
>
>
> 2. Components have been tested and meet the W3C Web Content Accessibility
> Guidelines principles
>
> of Perceivable, Operable, Understandable, and Robust
>
> https://www.w3.org/WAI/fundamentals/accessibility-principles/
>
>
>
> 3. Open-source with an active community
>


As an exercise, I mocked up the proposed Event Logs design using the Carbon
Design System. This was a test on the theory of being able to theme and
customize Carbon to fit the needs of multiple community members. The
resulting design uses lighter colors and rounded edges to achieve a
friendly aesthetic. This demonstrates the flexibility that still exists and
can be embedded into Carbon using themes, while providing a sturdy
foundation of interactions and components to build from.

https://ibm.invisionapp.com/share/QANZHJKP74E#/319333663_Event_Logs
<https://ibm.invisionapp.com/share/QANZHJKP74E#/319333663_Event_Logs>

[-- Attachment #2: Type: text/html, Size: 8237 bytes --]

RE: GUI Component Library

[Pine, Kathryn ElaineX]

[-- Attachment #1: Type: text/plain, Size: 3463 bytes --]

Thank you, Jandra, for putting together this mockup to demonstrate how our proposed design style could be somewhat maintained with this library. Is this all done via CSS overrides?

Thanks,
Kathy

From: openbmc <openbmc-bounces+kathryn.elainex.pine=intel.com@lists.ozlabs.org> On Behalf Of Jandra A
Sent: Wednesday, November 20, 2019 2:36 PM
To: Derick Montague <Derick.Montague@ibm.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: GUI Component Library


We are working to compromise on a component library as we move towards a change to the GUI front-end framework. As discussed in previous emails to the list, we are planning on updating the BMC UI to use Vue. It is currently written using AngularJS, which will reach the end of its lifecycle on June 30, 2021.



With this update, we are looking to select a component library that allows the GUI design/development team and any contributors to focus more on feature work and less on base-level components. IBM has proposed using the Carbon Design System. Carbon is an open-source library backed by IBM. We are advocating for this library for the following reasons.



1. Has an open-source community of Designers and Developers supporting the library



2. It is built with a user-centered approach that utilizes Design Thinking processes that include user testing and heuristic evaluation



3. It is compliant with the World Wide Web Consortium's (W3C) Web Content Accessibility Guidelines (WCAG).



4. The framework can be themed to meet the branding needs of other community members.



5. We agreed to and are using Carbon Design System icons



6. We are creating custom components using Carbon Design System patterns, e.g. LocaL User Management table. Using the Carbon Design System would allow us to bring in elements without the need to re-design or develop a new custom component in Vue.



We are looking to discuss the use of other libraries and should choose one library. Using more than one library will add complexity with keeping all the utilized libraries up to date, create additional work to customize the library components to have the same look and feel, and could create confusion determining with components are being used

from which library resulting in a lack of consistency within the application. None of the 3rd party libraries will likely meet all of our needs so when we are evaluating component libraries some of the criteria that need to be met includes:



1. Ability to create and use different themes



2. Components have been tested and meet the W3C Web Content Accessibility Guidelines principles

of Perceivable, Operable, Understandable, and Robust

https://www.w3.org/WAI/fundamentals/accessibility-principles/



3. Open-source with an active community


As an exercise, I mocked up the proposed Event Logs design using the Carbon Design System. This was a test on the theory of being able to theme and customize Carbon to fit the needs of multiple community members. The resulting design uses lighter colors and rounded edges to achieve a friendly aesthetic. This demonstrates the flexibility that still exists and can be embedded into Carbon using themes, while providing a sturdy foundation of interactions and components to build from.

https://ibm.invisionapp.com/share/QANZHJKP74E#/319333663_Event_Logs <https://ibm.invisionapp.com/share/QANZHJKP74E#/319333663_Event_Logs>

[-- Attachment #2: Type: text/html, Size: 10811 bytes --]

RE: GUI Component Library

[Derick Montague]

> Thank you, Jandra, for putting together this mockup to demonstrate how our proposed design style could be somewhat maintained with this library. Is this all done via CSS overrides?
 
She used the Carbon Design System toolkit to mock this up in Sketch. We would implement this through custom theming.
Rounded corners, larger font size, etc could be simple overrides, but I think best way to accomplish this is by creating
custom themes.

RE: GUI Component Library

[Pine, Kathryn ElaineX]

[-- Attachment #1: Type: text/plain, Size: 4017 bytes --]

Thank you, Derick, for sharing this conversation with the larger community.

I like the idea of using a design library to improve code consolidation and design efficiency.

The Carbon Design Library looks like a great library in terms of fundamentals, but the design style is rather similar to the existing web UI. Since Intel has been working on a new, more modern-looking UI, choosing a design library that is stylistically similar to the existing UI might not be the best compromise.

In terms of a design library that matches the style of the web UI we’ve been working on, Bootstrap would be a great choice: https://bootstrap-vue.js.org

However, I wonder if we could find a happy medium between the two styles? I’ve been looking for websites that have elements of both style preferences -- that include the more modern look (larger elements, rounded corners, light colors), with the more stable look (dark colors, square elements) – and found these great examples:

- Invision App’s website https://www.invisionapp.com/
- Visual Studio Code website https://code.visualstudio.com/
- GitHub website https://github.com/

Perhaps we could look into the design libraries the above websites use?

Either way – we can work with whatever design library works best for the community. As long as it doesn’t preclude further customization, I’m sure we’ll be able to make things work on our end.

Thanks,
Kathy


From: openbmc <openbmc-bounces+kathryn.elainex.pine=intel.com@lists.ozlabs.org> On Behalf Of Derick Montague
Sent: Wednesday, November 20, 2019 1:47 PM
To: openbmc@lists.ozlabs.org
Subject: GUI Component Library


We are working to compromise on a component library as we move towards a change to the GUI front-end framework. As discussed in previous emails to the list, we are planning on updating the BMC UI to use Vue. It is currently written using AngularJS, which will reach the end of its lifecycle on June 30, 2021.



With this update, we are looking to select a component library that allows the GUI design/development team and any contributors to focus more on feature work and less on base-level components. IBM has proposed using the Carbon Design System. Carbon is an open-source library backed by IBM. We are advocating for this library for the following reasons.



1. Has an open-source community of Designers and Developers supporting the library



2. It is built with a user-centered approach that utilizes Design Thinking processes that include user testing and heuristic evaluation



3. It is compliant with the World Wide Web Consortium's (W3C) Web Content Accessibility Guidelines (WCAG).



4. The framework can be themed to meet the branding needs of other community members.



5. We agreed to and are using Carbon Design System icons



6. We are creating custom components using Carbon Design System patterns, e.g. LocaL User Management table. Using the Carbon Design System would allow us to bring in elements without the need to re-design or develop a new custom component in Vue.



We are looking to discuss the use of other libraries and should choose one library. Using more than one library will add complexity with keeping all the utilized libraries up to date, create additional work to customize the library components to have the same look and feel, and could create confusion determining with components are being used

from which library resulting in a lack of consistency within the application. None of the 3rd party libraries will likely meet all of our needs so when we are evaluating component libraries some of the criteria that need to be met includes:



1. Ability to create and use different themes



2. Components have been tested and meet the W3C Web Content Accessibility Guidelines principles

of Perceivable, Operable, Understandable, and Robust

https://www.w3.org/WAI/fundamentals/accessibility-principles/



3. Open-source with an active community




[-- Attachment #2: Type: text/html, Size: 12076 bytes --]

RE: GUI Component Library

[Derick Montague]

[-- Attachment #1: Type: text/html, Size: 6033 bytes --]

Re: GUI Component Library

[Jandra A]

[-- Attachment #1: Type: text/plain, Size: 3177 bytes --]

Updating the OpenBMC Style Guide Prototype link below.


> In terms of a design library that matches the style of the web UI we’ve
> been working on, Bootstrap would be a great choice:
> https://bootstrap-vue.js.org
>
> We agree to use Bootstrap-Vue for the Vue framework rewrite. Bootstrap-Vue
> does not have an icon library and refers to third-party sources. Since we
> are already using the Carbon Design System icons, can we agree to continue
> to use them?
>
> > However, I wonder if we could find a happy medium between the two
> styles? I’ve been looking for websites that have elements of both style
> preferences -- that include the more modern look (larger elements, rounded
> corners, light colors), with the more stable look (dark colors, square
> elements) – and found these great examples:
> >
> >- Invision App’s website https://www.invisionapp.com/
> >- Visual Studio Code website https://code.visualstudio.com/
> >- GitHub website https://github.com/
>
> Thank you for sending the site examples. They are great examples of
> well-designed user interfaces. Although the proposed Intel UI updates
> provide some pattern improvements, the overall layout and design changes
> don't feel as polished as the examples you shared. We believe more
> collaboration is needed to improve the design and implementation of the
> proposed changes to meet both Intel's and IBM's needs.
>
> A little over a year ago, we developed an OpenBMC style guide to make it
> easier for designers and developers to contribute to the project. We built
> a living style guide prototype, but Ed's concern about who would develop
> and maintain the guide kept it from moving forward. The inconsistency and
> lack of code reuse throughout the application is the result of not having
> this documentation.
>
> OpenBMC Style Guide:
> https://ibm.invisionapp.com/share/EBNYECMH3Y2#/318986393_Grid
> <https://ibm.invisionapp.com/share/EBNYECMH3Y2#/318986393_Grid>
>
> OpenBMC Style Guide Prototype:
> https://derick-montague.github.io/openbmc-styleguide-proposal/
>
> As we rewrite the application in Vue, we have an opportunity to create
> this documentation and assure that the OpenBMC UI is clean, maintainable,
> and adheres to an agreed-upon set of values. Since joining the project, you
> have been working alone on both design and development. We hope that we can
> work as a team to collaborate and lean on each other's strengths.
>
> I feel the next step is to schedule a meeting to review the existing style
> guide. We can then determine what needs to be updated to meet both Intel's
> and IBM's needs. We can use the updated style guide to create the theme
> changes required for the Bootstrap-Vue out of box experience to adhere to
> the updated style guide.
>
> This effort will require a stronger focus on the framework update and
> style guide development. When we start working on the framework update, the
> only updates to the AngularJS UI will be critical bug fixes. Our goal is to
> have the framework update complete no later than the end of Q2 2020.
>
> What are your thoughts on this plan?
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 6212 bytes --]

RE: GUI Component Library

[Pine, Kathryn ElaineX]

[-- Attachment #1: Type: text/plain, Size: 5282 bytes --]

>> In terms of a design library that matches the style of the web UI we’ve been working on, Bootstrap would be a great choice: https://bootstrap-vue.js.org

> We agree to use Bootstrap-Vue for the Vue framework rewrite. Bootstrap-Vue does not have an icon library and refers to third-party sources. Since we are already using the Carbon Design System icons, can we agree to continue to use them?

Yes, I’m ok continuing to use the Carbon Design System icons. I agree, also, that if an icon does not exist in the library, we can use the library’s icons to make new icons that match that style.

>> However, I wonder if we could find a happy medium between the two styles? I’ve been looking for websites that have elements of both style preferences -- that include the more modern look (larger elements, rounded corners, light colors), with the more stable look (dark colors, square elements) – and found these great examples:
>>
>>- Invision App’s website https://www.invisionapp.com/
>>- Visual Studio Code website https://code.visualstudio.com/
>>- GitHub website https://github.com/

>Thank you for sending the site examples. They are great examples of well-designed user interfaces. Although the proposed Intel UI updates provide some pattern improvements, the overall layout and design changes don't feel as polished as the examples you shared. We believe more collaboration is needed to improve the design and implementation of the proposed changes to meet both Intel's and IBM's needs.

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. As I’ve gone through each page downstream, I’ve done a basic update focusing on style & UX, making incremental improvements with the goal of moving things to an even more polished state with additional investment of time and resources. 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.

I believe the process that Jandra and I have begun, reviewing the design proposals page-by-page, is a great example of how we can continue to collaborate and work towards the best result and get a polished look with some agreed upon elements representing both a stable and modern style.

>A little over a year ago, we developed an OpenBMC style guide to make it easier for designers and developers to contribute to the project. We built a living style guide prototype, but Ed's concern about who would develop and maintain the guide kept it from moving forward. The inconsistency and lack of code reuse throughout the application is the result of not having this documentation.

>OpenBMC Style Guide:
https://ibm.invisionapp.com/share/EBNYECMH3Y2#/318986393_Grid
<https://ibm.invisionapp.com/share/EBNYECMH3Y2#/318986393_Grid>
>OpenBMC Style Guide Prototype:
https://derick-montague.github.io/openbmc-styleguide-proposal/

>As we rewrite the application in Vue, we have an opportunity to create this documentation and assure that the OpenBMC UI is clean, maintainable, and adheres to an agreed-upon set of values. Since joining the project, you have been working alone on both design and development. We hope that we can work as a team to collaborate and lean on each other's strengths.

Indeed – I agree that all of the design work we do can be better through this collaboration.

>I feel the next step is to schedule a meeting to review the existing style guide. We can then determine what needs to be updated to meet both Intel's and IBM's needs. We can use the updated style guide to create the theme changes required for the Bootstrap-Vue out of box experience to adhere to the updated style guide.

>This effort will require a stronger focus on the framework update and style guide development. When we start working on the framework update, the only updates to the AngularJS UI will be critical bug fixes. Our goal is to have the framework update complete no later than the end of Q2 2020.

>What are your thoughts on this plan?

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. It might require us all to revisit how we can find a stylistic compromise, and perhaps we look to those sites I shared, or others as well, as possible stylistic directions that would work. 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. 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.




[-- Attachment #2: Type: text/html, Size: 11401 bytes --]

GUI Component Library

[Derick Montague]

> 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.
 

RE: GUI Component Library

[Pine, Kathryn ElaineX]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

>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.



My proposal is that we work towards a vision with concepts for the overall site prior to getting into the details, as a method for consensus building. Our work will be the best if we agree on a look that encompasses a shared vision for the entire UI, not just individual elements. I’ve shared a few example websites that from my perspective, look like a happy medium of both our styles, and expect we can find more good examples if we want to go down this path.



I think we have the opportunity – leaning on the collaborative strengths that we can all bring – to combine what we have each been working on to make something even better. But it will mean being willing to compromise some of our style preferences to agree on a shared vision. Is there interest on working towards this vision together? It seems like a good time given the rebuilding with VueJS.



If we can agree on the big picture, creating a style guide or choosing a design library will be much easier as we’ll have consensus reflecting that shared vision.



How about we discuss in this week's GUI Design work group meeting?



Suggested topics:

  *   Transition to VueJS
  *   Goals & Improvements
     *   Style goals – can we unify to a single style preference?
     *   Design library vs Style guide
  *   (If time)
     *   Non-style contributions – process for logging issues
     *   Current work in pipeline





[-- Attachment #2: Type: text/html, Size: 10519 bytes --]

Re: GUI Component Library

[Jandra A]

[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]

>
> My proposal is that we work towards a vision with concepts for the overall
> site prior to getting into the details, as a method for consensus building.
> Our work will be the best if we agree on a look that encompasses a shared
> vision for the entire UI, not just individual elements.
>
> If we can agree on the big picture, creating a style guide or choosing a
> design library will be much easier as we’ll have consensus reflecting that
> shared vision.
>

Can you specify the big picture items we want to agree on? I think at a
high level, we all want a modern and polished UI. The realities of how that
is implemented and brought to life is were the conversation breaks into
subjective opinions and where we've had difficulties before.

Like Derick, I suggest taking the existing style guide as a starting point,
since that is what is currently implemented and what has tested positively
with numerous customers. After reviewing it, we can start by discussing
overarching design principles that are implemented (such as color,
typography, icons, and corner type) and apply those to all components. This
way, we ensure that the UI is updated across the board to maintain
cohesiveness and reflects a single design language. If needed, individual
components can be revisited once we have agreed on the big principles.


Regards,
Jandra Aranguren

[-- Attachment #2: Type: text/html, Size: 1823 bytes --]

RE: GUI Component Library

[Pine, Kathryn ElaineX]

[-- Attachment #1: Type: text/plain, Size: 2824 bytes --]

>Can you specify the big picture items we want to agree on?

In terms of a big picture, working towards a mockup that aims to address the page design, header, navigation, layout & overall look in a more comprehensive way could look like this: I can imagine that we could choose a page and each create a mockup/mockups to consider for that page, with the aim being to take some pieces of the existing and proposed design style. This process could potentially address ways to apply different color palettes downstream with ease. We could each share our concept(s), as it’s usually easier to come to an agreement without feeling like the choice is either black or white – multiple concepts often allow room to compare, contrast and merge ideas together.

We’re not too far away from that kind of process, already, in that we are already working on updated navigation and moving towards updating the header next, and with the way that you & I coordinated on the sensors page. I feel like by taking a step back and each working on mockups, it would allow us all to feel like we had some ownership of a new style and could better come to an agreement on what a modern and polished UI could look like for this project.

From: Jandra A <jandraara@gmail.com>
Sent: Tuesday, December 3, 2019 9:31 AM
To: Pine, Kathryn ElaineX <kathryn.elainex.pine@intel.com>
Cc: Derick Montague <Derick.Montague@ibm.com>; openbmc@lists.ozlabs.org
Subject: Re: GUI Component Library


My proposal is that we work towards a vision with concepts for the overall site prior to getting into the details, as a method for consensus building. Our work will be the best if we agree on a look that encompasses a shared vision for the entire UI, not just individual elements.

If we can agree on the big picture, creating a style guide or choosing a design library will be much easier as we’ll have consensus reflecting that shared vision.

Can you specify the big picture items we want to agree on? I think at a high level, we all want a modern and polished UI. The realities of how that is implemented and brought to life is were the conversation breaks into subjective opinions and where we've had difficulties before.

Like Derick, I suggest taking the existing style guide as a starting point, since that is what is currently implemented and what has tested positively with numerous customers. After reviewing it, we can start by discussing overarching design principles that are implemented (such as color, typography, icons, and corner type) and apply those to all components. This way, we ensure that the UI is updated across the board to maintain cohesiveness and reflects a single design language. If needed, individual components can be revisited once we have agreed on the big principles.


Regards,
Jandra Aranguren

[-- Attachment #2: Type: text/html, Size: 6959 bytes --]

GUI Component Library

[Derick Montague]

> My proposal is that we work towards a vision with concepts for the overall site prior to getting into the details, as a method for consensus building. 

Designing a site without understanding the base-level building blocks will not work. We need to agree on the foundation before we start trying to build concepts. Building concepts without an agreement on the foundation will not be efficient.


> I think we have the opportunity – leaning on the collaborative strengths that we can all bring – to combine what we have each been working on to make something even better. But it will mean being willing to compromise some of our style preferences to agree on a shared vision. Is there interest on working towards this vision together?

That is the objective of this thread. Since you are opposed to using Carbon, we agreed to use Bootstrap. We are working towards this vision together.
 

> If we can agree on the big picture, creating a style guide or choosing a design library will be much easier as we’ll have consensus reflecting that shared vision.

I thought we already decided to use Bootstrap-Vue as the component library. Did something change? 


> How about we discuss in this week's GUI Design workgroup meeting?

The topics you suggested work. We will need to discuss the framework migration with a focus on how to align on theme customization.

RE: GUI Component Library

[Pine, Kathryn ElaineX]

I'm sure we can figure out how to approach this design challenge. I appreciate you being willing to work with Bootstrap and am open to discussing the approach you suggest. From my point of view, I do see a way forward to unify our design styles and really feel like putting together a mockup is a process that will help me see and share that vision, so perhaps I'll just work on that and share it when it's ready... and meanwhile we can discuss your proposed approach in the GUI Design workgroup meeting tomorrow.

Thanks,
Kathy 

-----Original Message-----
From: Derick Montague <Derick.Montague@ibm.com> 

> My proposal is that we work towards a vision with concepts for the overall site prior to getting into the details, as a method for consensus building. 

Designing a site without understanding the base-level building blocks will not work. We need to agree on the foundation before we start trying to build concepts. Building concepts without an agreement on the foundation will not be efficient.


> I think we have the opportunity – leaning on the collaborative strengths that we can all bring – to combine what we have each been working on to make something even better. But it will mean being willing to compromise some of our style preferences to agree on a shared vision. Is there interest on working towards this vision together?

That is the objective of this thread. Since you are opposed to using Carbon, we agreed to use Bootstrap. We are working towards this vision together.
 

> If we can agree on the big picture, creating a style guide or choosing a design library will be much easier as we’ll have consensus reflecting that shared vision.

I thought we already decided to use Bootstrap-Vue as the component library. Did something change? 


> How about we discuss in this week's GUI Design workgroup meeting?

The topics you suggested work. We will need to discuss the framework migration with a focus on how to align on theme customization.

Re: GUI Component Library

[James Feist]

On 11/26/19 1:19 PM, Pine, Kathryn ElaineX wrote:
>>> In terms of a design library that matches the style of the web UI we’ve been working on, Bootstrap would be a great choice:  https://bootstrap-vue.js.org
> 
>> We agree to use Bootstrap-Vue for the Vue framework rewrite. Bootstrap-Vue does not have an icon library and refers to third-party sources. Since we are already  using the Carbon Design System icons, can we agree to continue to use 
> them?
> 

Bootstrap did just release an icon library yesterday fwiw, although it 
is only in Alpha https://blog.getbootstrap.com/2019/11/26/bootstrap-icons/

> Yes, I’m ok continuing to use the Carbon Design System icons. I agree, 
> also, that if an icon does not exist in the library, we can use the 
> library’s icons to make new icons that match that style.
> 

GUI Component Library

[Derick Montague]

> Bootstrap did just release an icon library yesterday fwiw, although it
is only in Alpha
 
Thank you! Would like to use the same framework for everything and can consider this once it GA's. The rewrite to Vue will make it easy to update the icon library.