Fast: Component definitions: Base, Foundation, Pattern

[chrisdholt]

Currently this only affects the MSFT development site, but I think this goes towards how we document the different categorizations and creation of components. This issue will serve to vet and land definitions for various component buckets in our design system architecture.

The primary question here is:

How do we categorize different sets of components?

As a starting point, let's use the MSFT package as it's a valid example and will help vet the idea. Consider the current buckets we have when looking all up at the different parts available for use:

base - unstyled foundational components within the fast-components-react-base package
foundation - basic styled components?
pattern - a specific configuration or extension off a basic styled component?

Please provide your thoughts regarding the question above using the MSFT package as a non-exhaustive example.

[Falkicon]

My opinion is that base components are un-styled components. Foundation are styled components built on top of base components and are un-opinionated. Pattern components do not have a base of their own but are built out of foundation components or bases of other components. Pattern
are also not foundational UI building blocks and can be more opinionated.

I think where it gets a bit sticky, is that some components seem to overlap base-to-foundation such as the case where several components like carousel and tabs share the same base. One of the questions was around flipper where it uses the button base, in this case, I think it would be a pattern based on my definition above since it is using the button base and does not have one of its own.

[awentzel]

My opinion, while I like the idea behind Base/Foundation, is that Base and Foundation both tend to mean the same thing. This could be confusing to the broader audience. Why not call it what it is? Styled Components. For documentation sake it could then look something like:

Components
|-- Base
|-- Styled
|-- Patterns

This i think would resonate with the largest audience members and tend to be how people think of these things when searching to use other component frameworks online. Also, note ordered so we could add visualizations / diagrams to help show how they are constructed into patterns to really drive home the idea.

[eljefe223]

Do we even need to distinguish styled from pattern ? To me there are base components and everything else.

Using Jason's Tab example. we have a base Tab. Then a styled Tab, but Carousel uses Tab and Flipper which would be a pattern? Coming from the XAML world we tended to not distinguish aggregated components from styled ones. There were base building blocks and then everything else... these building blocks were just styled and combined to build out functional components. For example (in XAML) <Checkbox /> was build using a Base <Toggle/> and <TextBlock/>. <Checkbox/> was a built in control but if you cracked it open this is fundamentally what it was. However they didn't distinguish it as a pattern or a styled component

[janechu]

I think we are conflating terms.

@Falkicon This is confusing use of the word _Foundation_ as we have a foundation package that exports the foundation component which is what the base components are built upon.

To @awentzel point I think his breakdown makes sense in a designers world, I want to expand on it a little though because we have things that are __ready to use__ and things that are more __build your own__ for the developers that want to create their own component libraries, more of an advanced usage. I think we need to tell both of those stories but the __ready to use__ would take precendent.

For clarity:

• _Foundation_ (a component that provides additional functionality to the React component class)
• _Base components_ (no style applied, browser default, built from _Foundation_)
• _Microsoft components_ (microsoft style applied, built from _base components_)

If you want a non-browser default set of components that map to the _base components_ I believe we discussed a set of _frame components_.

I have no opinion on patterns, I was under the impression they were not being exported in any meaningful way and that we would describe our patterns from a design perspective.

[nalogiudice]

After reading through the thread, I think @janechu 's thoughts make the most sense. And I too thought patterns only described an internal utility.

[awentzel]

@janechu could you provide an example of Foundation as you have defined it? Are you actually referring to the fact that React really by default is our base, then we come in and add some structure to define the base component, later for which style can be added to meet style guides? If this is the case then I would make an update to my proposal:

Components
|-- React (foundation)
|-- Base 
|-- Styled
|-- Patterns

Patterns to me, represents how components (base or styled) can be composed together to create larger things, patterns. Could be as large as a full page or as small as a label element + input element.

[awentzel]

would be great to get feedback from @khamudom @scomea @marjonlynch since they are the newest and may have a fresh perspective.

[marjonlynch]

The was @janechu expressed it makes most sense to me. Since the styled components are styled specifically to what we refer to as Microsoft style seems logical to label them as such so someone doesn't get the impression they can style them anyway they want. Patterns seems very generically referring to composite components/controls. Do patterns have to adhere to Microsoft styled components or is it anything goes there?

[chrisdholt]

I think patterns would vary based on design system.

From a MSFT design system specific standpoint, we have things like Call To Action, Action Trigger, Action Toggle - all patterns which are derivatives of the MSFT button.

If I had a Material or Lightning design system package, I think there would be patterns specific to Lighting/Material design as well.

[scomea]

I'm not convinced the notion of patterns is clear enough to be useful as a category. IMO we should have base components which could include components that use other base within their base implementation (menu, menuitem, etc...), and then we have styled collections that derive from that (ie. MSFT). What may make sense as a different category are styled higher level constructs like "error dialog", "user profile panel" which are not really intended as building blocks but are reused across a style ecosystem.

[khamudom]

I like it simple, having a base, style and pattern works for me.

[chrisdholt]

In terms of the foundation conversation, I think @janechu was detailing that there is a component class that we have which provides base functionality for all of our components. It is completely unrelated to the conversation at hand in my opinion aside from showing how using "Foundation" would cause confusion.

This shared language will help us classify our components in places such as the component documentation site: https://msft-docs.azurewebsites.net. The word pattern is already in use there and references exported packages. What are those called instead?

A couple thoughts:

• Base are always unstyled. We have a package named this way and relating it to anything styled is cause for confusion. These are not specific to any specific design system and we shouldn't convolute the story
• MSFT components (as an example because it's the package we have) include both generically styled un-opinionated components which map 1:1 with a base component (button), more opinionated implementations which do not map 1:1 to a unique base component (flipper) and potentially design-language-specific derivatives of styled components (action trigger, call to action, action toggle).

I am specifically interested in landing how we categorize the variations within the styled components package. Currently, it is a very convoluted story trying to articulate when and how something should be built; without a shared language, it's very difficult to get the principles across efficiently and effectively.

[chrisdholt]

closing for now as obsolete.