CUNY Academic Commons

I would approach it by first taking inventory of all existing styles on the site (I assume there are a lot of unnecessary duplicates or variations of styles), then make decisions together which ones to drop/replace to simplify the style guide to achieve more consistent styles. We want to only includes styles we need, e.g. one style for each of these: primary button large, primary button small, secondary button large, secondary button small, link style in text, nav styles (default, hover, active), etc.

Matt,
You mentioned that Chris might have started on a style guide or has done some work on buttons in the past? Is that something you could dig up and share? If not, I'm happy to start from scratch.

Reposting Chris's comment from #9801:

have to disagree about having Sonja spending time doing a style guide or inventory of styles of the current site. It’s a mess and something that we would basically throw out when we redesign. But I do think there are things we could do to document functionality and needs.

Along those lines I have this site I made 3 or 4 years ago that is a start at documenting the current interface elements: https://redesign2015.commons.gc.cuny.edu/

Sonja, I sent you an invite to the site. Let em know if you don’t get it.

Here is the document on buttons that you were referring to Matt: http://www.teachingmultimedia.com/commons/buttons/buttons.html

If you read it you’ll see that there are a number of different styles which are sometimes confusingly used. [Some of these issues have actually be remediated.]

Instead of documenting the styles that we have, I would instead advocate that time be spent documenting functionality and types of interface elements. If we do that it could be a valuable tool for the redesign.

So at a higher level than buttons, but maybe how much do we have an list of items with title, thumb, date, description, or when do we use tabs, etc.

For the redesign we can then focus on whether these are the right interfaces, making a style guide etc.

I would also advocate against what I’m doing here and move the conversation on style guides and redesign to another thread either here in red mine or on the Commons.

To respond to Chris's feedback above: I take your point, but would like to push back against it. For five+ years we have put off incremental visual and design improvements because it felt like a waste to put effort into something in advance of a major redesign. As a result, there are small or medium things we might have addressed years ago that would, in hindsight, have been worth handling, but which have gone undone because of our approach. Let's not continue to do this. If Sonja were to spend a few hours on a styleguide - first, doing a high-level review of interface elements and design, as recommended by Chris, but then also documenting (within reason) existing styles - it's likely that it'd lead directly to us making some meaningful, small changes that would serve us well in advance of a full redesign.

This is predicated on the assumption that Sonja wouldn't be spending many dozens of hours on this project. If that's the case, then I agree that we should limit the scope.

Thanks for moving this over Boone. I hear what you’re saying about the continually delayed changes and its a valid point. If Sonja’s time is limited and focused on making the style guide rather than documenting all of the various styles in existence then I’m on board. Those two links represent a lot of hours looking over the site and comparing things. It can be a time sink. That’s my main concern. having a styleguide would be great now and in the future.

Sonja I’m also open to your opinion on how best you can spend your time towards improving the existing interface while helping to set up the major redesign. I can also help doing some of the documentation or other work to help reduce busywork hours for you.

Also there are different versions of style guides, static/dynamic etc., can you tell us a bit more about the form you’re thihking about for the guide?

Thanks Boone for your input! I agree with the approach to not push this off yet again, but use this project to prepare for a major redesign.

Chris Stein wrote:

Thanks for moving this over Boone. I hear what you’re saying about the continually delayed changes and its a valid point. If Sonja’s time is limited and focused on making the style guide rather than documenting all of the various styles in existence then I’m on board. Those two links represent a lot of hours looking over the site and comparing things. It can be a time sink. That’s my main concern. having a styleguide would be great now and in the future.

Sonja I’m also open to your opinion on how best you can spend your time towards improving the existing interface while helping to set up the major redesign. I can also help doing some of the documentation or other work to help reduce busywork hours for you.

Also there are different versions of style guides, static/dynamic etc., can you tell us a bit more about the form you’re thihking about for the guide?

Thanks for sharing those resources and previous attempts. We can certainly use some of these resources to inform this task and give us a starting point.

I agree that given my somewhat limited time on the project, I wouldn't do a full style audit of the website, as I agree a lot of it would likely be wasted leg work. I would rather document the primary design elements (like buttons, typography styles, form elements, etc.) as well as interaction patterns (incl. things like error messages, etc.). From there I would start creating a living style guide (with the help of Boone).

After the first iteration of the living style guide is done, we can focuse on high-traffic sections of the site and identify any missing styles. This will help us make it more and more comprehensive - along this journey we'll likely make a lot of decisions to simplify current styles. We can then start rolling out styles into the site over the next release(s).

This will also be the perfect opportunity to craft a comprehensive design system which will lay the foundation of the redesign. We currently have an extensive list of individual or contextual styles for elements. Which is, understandably so, the current reality due to iterating on the site over the past 5+ years.

How does that sound for scope? Happy to discuss and refine and am always open for suggestions.

This all sounds great to me. I appreciate the conscientiousness you are all showing, and Chris's concern that Sonja's time be spent wisely. I do agree that we need to start to move this all forward, and it sounds like Sonja will be able to recognize and step back from potential time-sinks as they approach. So, I would encourage us to move forward on this. Thank you all!

Matt Gold wrote:

This all sounds great to me. I appreciate the conscientiousness you are all showing, and Chris's concern that Sonja's time be spent wisely. I do agree that we need to start to move this all forward, and it sounds like Sonja will be able to recognize and step back from potential time-sinks as they approach. So, I would encourage us to move forward on this. Thank you all!

Thanks Matt, I'll start working on this as soon as the 1.14 release issues no longer need my attention.

For this project I'm looking to create a living style guide (incl. pattern library) – it will be driven by design, but live in code. This way we can all access the same most current version of the style guide. And ideally it's setup in a way that is directly connected to inform the styles of the website – so we only have to make an update to a style in one place. Or vice versa, the style guide is informed by the styles of the website and rendered from there to be up-to-date.

I've done some research into living style guide solutions. But first let me start by sharing a few examples of living style guides out there that I like:
Lonely Planet: https://rizzo.lonelyplanet.com/styleguide/design-elements/colours
Buffer: https://buffer.com/style-guide
CenturyLink: https://assets.ctl.io/cyclops/1.8.6/
Mailchimp: http://ux.mailchimp.com/patterns/forms (not sure if we need actual html code snippets in the style guide)
Chameleon: https://pusher.github.io/chameleon/components/buttons/
U.S. Design System: https://designsystem.digital.gov/components/

We can start with basic styles (like consistent buttons) and work our way towards a more complete style guide. This will help us work towards a full or partial redesign potentially in 2019.

Now we need to look at the technical aspect of living style guides and find a solution that works for us. I'd love to hear Boone's feedback on which solution would make the most sense and is the easiest to integrate and update. I did some research already, but would need to know which direction to go to dig a little deeper for the best solution:
Overview of Pattern Library Generators: https://github.com/davidhund/styleguide-generators (not sure which direction, PHP based, parsing CSS source, Gulp/Grunt, etc.)
More styleguide tools: http://styleguides.io/tools
Chameleon: https://github.com/pusher/chameleon
Pattern Lab: https://patternlab.io/ (might not be exactly what we are looking for, but it's a holistic approach we potentially want to look at for the full redesign)
I worked with KSS on Node before: http://kss-node.github.io/kss-node/

First two links are overview of a variety of tools. Boone, if you could narrow it down for direction of tool or language, I can continue to dig.

Thanks for sharing the initial research, Sonja! I've added Ray as a watcher, as he may have opinions regarding implementation.

As a general principle, I think we should steer clear of tools that are too closely tied to a specific templating language. A number of the tools try to enforce atomic design by asking you to build a library of reusable elements, and then to include them when building molecular or template-level items. This approach won't work well for us, for a couple reasons. One is that we use WordPress, which uses PHP-based template, rather than Moustache or Handlebars or a true templating language. (We could build middleware, but it's lots of work.) Two is that our markup comes from many places other than theme templates, such as plugins and mu-plugins. Finally, I can envision a future where we build things that are technically different from what the Commons currently is (say, something non-WordPress-based), but where we still want to use the style guide toolset.

I like the idea of building a styleguide out of our CSS, using KSS. kss-node is one tool of this type, http://styleguide.sc5.io/ is another, and there are probably others. With this kind of approach, we could keep our existing infrastructure (ie not rewrite template files, and our changes to CSS would be mostly for consolidation at first), and add styleguide integration through inline comments + some build steps (grunt, php, whatever). This feels to me like something that we can do in stages, within our existing theme/plugin setup.

Matt and team,
which part of the Commons should I first focus on to review what styles exist and to start creating a style guide? Please include any sub sections that might be relevant and you wanted me to also include in this.

To inform this questions the consideration should be most used or having the widest range of UI variation. Please let me know and if you can share a link so I'm sure to find the right thing.

Thanks.

Thanks, Sonja. I see a few possibilities here:

1. The profile/portfolio section -- e.g. what you see when you go to https://commons.gc.cuny.edu/members/[username] and then also click on "Commons Profile." The rationale for starting here is that we have two divergent styles (public portfilio, which is its own design that the Commons team created a few years ago in an effort to help people put together online CVs) and the Commons profile, which inherits basic buddypress styling from the main site and which connects more to the network. So, what unites this area of the site is the Users own profile; but then there are two parts, one more public facing and one that shows internal connections with the Commons (e.g group memberships, sites, etc). FYI, when we were creating the Commons profile section, we had lots of discussions about what it meant to be creating a part of the site focused on the individual member (the portfolio) and a part of the site that focused on connections (which is what the Commons is supposed to be about). in the end, we split the difference and made both interfaces available through tabs.

2. The group interface. the rationale for starting here is that it is heavily used and also in need of a redesign. Work on this part of the site could also affect other areas of the site, such as group and blog directories or the Commons user's Commons profiles, as described above.

Those are probably the two places I'd start, though I'd love to hear what others think.
Commons Profile

Starting with single groups seem like the best approach to me. As Matt notes, they're heavily used. They also contain much of the design language used throughout the site. Specifically, they have:

- single-item navigation (left-hand nav)
- secondary nav (like "All Docs" when clicking the Docs item)
- BP item lists (like under Members)
- miscellaneous other kinds of item lists that come from other plugins (Docs, Forums, Files)

Thanks for sharing your feedback Matt and Boone.
Reviewing the suggested sections, I tend to lean towards Groups or more specifically starting with single groups. My reasoning is, that there is less of a focus on BuddyPress UI (though it's woven in with the members section). Groups include a lot of different styles and UI components that will help kick-start this project. I would start with the main single group page, and then start to dive deeper into the sub sections to identify unique styles that need to be defined. Once that's done, I can then focus on the groups archive page.

If everyone is ok with this direction, I'd start there.

I agree Groups is a good place to start.

• Lists of things (people, groups, sites, activity). These tend to have similar elements (title, image, description, time) but not always similar style
• Forms
• Tabs
• Buttons and Links

• Editing a Doc
• Social Paper
• Portfolio
• Inviting people to the Commons

I can also give you links to some of the research that was done a while ago like the Button Styles.
Perhaps if you like and have the time we can schedule a time to talk and I can cover some of the discussion Matt referenced on Profile/Portfolio and any other back history that you’re interested in.

so -- groups it is! thank you, Sonja, and thank you, Chris

Chris,
Thanks for the additional info and yes, would love to get on a call with you to get more insight. Do you have some time next week (Wed or Thur maybe)?

This is excellent, Sonja!

What are next steps? Perhaps we can start by choosing one or two items to remediate - say, consolidating the various greys - and use that as a test case for integrating the living styleguide toolchain?

Boone,
Yes, I'd like to start with a few items. The greys would be a good starting point, so would be the buttons. I can put together a unified look for primary, secondary, and maybe another type of button.

Matt,
it would be good to discuss in what capacity you want me to focus on this since the redesign bid is also something that will be going out at some point.

Hi team,
As I discussed with Matt, once I've wrapped up the designs for the 1.17 release, I'll get back to this task and the greater redesign of the Commons –– so excited to get this started!!!

I have a few questions in preparation of that, which I'd like to talk to the team about during our Tuesday meeting. I'd also like to share a few thoughts about overall strategy and approach with everyone. Here are the topics I'd like to discuss:

- Component based approach and overall design strategy
- Is Redmine the right tool for this project or would we use a repo like Github for this project (thinking about keeping track of relationships between components and overall progress etc.)
- Does the dev team have any preferred or true and tested living style guide tools they'd like to use?
- Does my Commons user profile have full access to all relevant areas of the website we're redesigning? What sections might I be missing?
- Timeline and communication

Hi team,
I've researched some possible solutions for our living style guide as part of our redesign project.
It was important to look at open source solutions to be inline with our mission, as well as for a flexible and scalable solution.

Pattern Lab
Pattern Lab is a frontend workshop environment that helps you build, view, test, and showcase your design system's UI components. Built on Atomic Design principles.
https://patternlab.io/
Demos: https://patternlab.io/demos/, https://altinn.github.io/designsystem-styleguide/tekst/artikkelheader.html

A few notable features:
- Open Source
- Nested patterns (will be great for our component based approach)
- Pattern documentation (define and describe UI patterns for cross team understanding)
- Responsive views (to look at components across various screensizes)
- Tool and language agnostic, lives on Github and has support and resources
- "Pattern lineage" (see where components are used)
- Includes a pattern starter kit and is flexible and extensible
- Interactive components

Catalog
Open Source
Catalog combines design documentation with real, live components in one single place, making collaboration between designers and developers seamless.
[https://www.catalog.style/](https://www.catalog.style/)
Documentation: https://docs.catalog.style/
Demos: https://brand.interactivethings.com/#/, https://www.interactivethings.com/styleguide/#/

A few notable features:
- Open Source
- Easy to maintain
- beautiful presentation
- Direct integration with React applications (not sure if that will work for us)
- Built on modular system, flexible and customizable
- Add Design guidelines, document and specify styles
- Interactive components
- Responsive views
- Lives on Github, has documentation and support

Emulsify
Emulsify is an open-source tool for creating design systems with reusable components and clear guidelines for teams.
https://www.emulsify.info/
Documentation: https://docs.emulsify.info/
I can't tell for certain, but this solution might be for Drupal only

A few other tools I've found, but that don't seem to be open source:
Style Guide: https://hugeinc.github.io/styleguide/
Fabricator: https://fbrctr.github.io/
Style Guide Guide boilderplate: https://bradfrost.github.io/style-guide-guide/

I'd like to ask Boone and the dev team to look at these solutions to see which ones are viable from a technical perspective. I imagine it's most important to be able to seamlessly integrate with our environment and the dev workflow. If none of those work for us, I'm happy to do more research.

Hi Sonja, these all look great, thanks for compiling them. I'll leave it to others who are doing more direct development for comments. The only other open-source tool I've come across is Storybook which seems to be both a tool for developing/testing UI Components and with Addons can output documentation.
https://storybook.js.org/
https://medium.com/storybookjs/how-design-systems-use-storybook-2ed735ad07a9

Chris Stein wrote:

Hi Sonja, these all look great, thanks for compiling them. I'll leave it to others who are doing more direct development for comments. The only other open-source tool I've come across is Storybook which seems to be both a tool for developing/testing UI Components and with Addons can output documentation.
https://storybook.js.org/
https://medium.com/storybookjs/how-design-systems-use-storybook-2ed735ad07a9

Thanks Chris, that looks like a viable option for us too from my perspective. Would love for the dev team to look at this one too.

Thanks for doing the initial research.

Some constraints that are guiding my thinking:
1. We are working with an existing codebase, mostly WordPress theme templates but also things like CSS, miscellaneous PHP files (global footer), etc.
2. We commonly build UI using at least two different technologies. First, and most commonly, we use WordPress theme templates. Second, we have an increasing number of JS-driven interfaces. These latter interfaces are split between those built in jQuery/vanilla JS, and those built in Vue.js.

These constraints are important as we consider a path forward. Most of the tools suggested here are "design systems" with very broad goals. They all allow you to build a beautiful style guide. Most have ways to make this style guide be "living", in the sense that your user-facing application (in our case, the WordPress theme) is built out of the very same pieces as the style guide. To accomplish the "living" aspect, the tools offer different ways of integrating into design and development workflows, in ways that are more or less flexible.

Because of our constraints, flexibility is extremely important. The same modesty that is guiding our redesign - "one piece at a time" - must guide any major modifications to our development technologies and workflow. As such, I think we have to rule out any systems that are all-or-nothing, systems that would require a massive redesign of our technical workflows just to be able to begin integration.

Of the options that I've looked at here, Pattern Lab seems to be perhaps the safest bet. It seems to be the most popular and well-established, giving me more hope that it'll continue to be around for a long time. It also seems to be the most flexible. Emulsify, for example, seems pretty cool, but it seems to require a specific design-dev flow. Pattern Lab, on the other hand, seems to be somewhat agnostic in terms of how you build your application, since it mainly spits out Mustache or Twig templates and lets you figure out (with the help of third-party tools) how to integrate this into your app.

Our team will need to have a couple of parallel discussions about strategy and vision, both short- and long-term, for the styleguide and the future of design-driven development on the Commons project. Here are some initial directions for those discussions.

Technical and procedural workflow for style guide construction and hosting¶

Pattern Lab works by defining a set of templates and other primitives ("atoms", "molecules", etc) in the /source/ directory of the pattern-labs application. These primitives can take a number of forms: scss files, Handlebars templates, JSON config files, etc. An npm script is used to build the public-facing styleguide.

Our team would need a workflow describing how design ideas get from designer into the pattern library. For example, we might have a setup like this:

a. We create a new Git repository for our /source/ files.
b. Members of the team have a local version of Pattern Lab. This includes Sonja (as designer) and me (as release manager) and anyone else who needs it.
c. Sonja makes suggested changes to our pattern library. She could either make the changes directly to the file and commit them to the repo. This is straightforward for some changes, like hex codes. In other cases, she may deliver the requested changes to the development team, who would then change the pattern library and commit the changes.
d. The PL build scripts create a static HTML site. At first, we'll probably build and deploy this site manually. But we could make it automatic in the future - say, a GitHub action that publishes to GitHub pages on every commit to the pattern library repo.

Integration into the Commons application¶

We are working with massive codebase, built on legacy technologies like WP templates. We cannot swap everything out right now. But I can imagine a phasing-in process, where the styleguide becomes more "living" with each step. For example:

a. At first, there is no integration with the Commons codebase. The pattern library is simply a reference for the development team, who is then responsible for manually applying the patterns to the WordPress application.
b. Certain static assets, like image files (think: logos, AJAX spinners, other glyphs) may be a good first candidate for integration. We can either: (i) load these images directly from the pattern library, perhaps by including the pattern library as a submodule and deploying it along with the main site, or (ii) add some sort of build step that copies files as needed, pre-release.
c. Sass integration may be a good next step. Variables for things like colors and typography could be defined in the pattern library, and we could pull them into the WordPress theme as part of a build step. This would involve moving to Sass for the Commons theme, and also introducing build/watch tools.
d. Markup templates - more significant 'molecules', 'organisms', etc - are more complex. For example, it would be good to have a centrally defined pattern for each type of button. PL would generate these as either Handlebars or Twig templates. Say we use Handlebars. These templates would then be usable in jQuery templates by loading the Handlebars library, and it might be possible to import at least the smaller of them for use in Vue.js. For PHP, we would need a build step that turns them into PHP (see eg https://github.com/zordius/lightncandy). (Something similar could happen with Twig, but we'd need middleware for templates on the JS instead of the PHP side.) In our WordPress templates, then, we would load these built templates by passing variables to get_template_part() (or some other convention that we would have to invent).

These are all just initial thoughts on technical integration. As noted above, PL is pretty agnostic about integration, so we would have flexibility to experiment. It's worth noting that these changes will make our development and deployment process more complex by introducing build steps, but perhaps this just brings us into the modern age of web applications.

Maybe we could take a bit of time to discuss next steps during our next meeting.

Thanks Boone for this detailed response! All the steps and considerations you've shared (at least the technical ones I could follow ;) make a ton of sense to me.

I want to add one more option here which could possibly be part of the interim step or longer term goal for implementation of styles in WordPress templates. Couldn't we also define clear css selectors that help create a consistent design. For example padding and margins could be globally defined with a few selectors, etc.

Looking forward to discussing this more tomorrow.

About Pattern Lab, just did some brief research and there are a few WordPress integrations available on Github.

• https://github.com/forumone/gesso-wp
• https://github.com/macder/derulski.com

Along with Pattern Lab, both of these implementations uses Timber, which is a WordPress middleware development library that utilizes Twig as the templating engine. Tying ourselves to another library like Timber might hinder us in the future, but it looks like a lot of people use Timber.

We are working with an existing codebase, mostly WordPress theme templates but also things like CSS, miscellaneous PHP files (global footer), etc.

If we move to a template engine, things like the global footer wouldn't work in the context of other themes, so we'd need to keep a copy of the global footer PHP file for compatibility reasons.

Thanks, Ray. I spent some time looking at Twig + Timber, but I hadn't seen those plugins. I'll take a deeper look. Twig seems like it's widely-enough used that I feel OK thinking about a future where we introduce it incrementally. I think the added value of Timber is that it provides standardized data objects for things like posts and users, which may have limited utility in our highly customized environment (particularly as regards BP objects). In any case, as I mentioned above and in the call, the Pattern Lab approach is somewhat agnostic as far as whether and to what extent we integrate, so these are questions we don't have to decide today - it's just reassuring to know that there are options down the road.

I'll take time in the next week for further review and thoughts about next steps.

Hello, just thought I'd bump this before our call tomorrow. I know it's a busy time with the semester beginning, and perhaps this is largely confined to the core dev team right now, but just in case there's anything for Sonja and others on the call to help evaluate.

Sorry, I'm continuing to do research on it, but I don't have anything to share yet. I will continue working on it, though I can't promise to have conclusions by tomorrow's dev call.

Hi all - An update from the technical end.

Using Pattern Lab https://patternlab.io/, I've put together the framework for a styleguide. Here is the repo: https://github.com/cuny-academic-commons/commons-style-guide/ Setup instructions are in the readme file.

I've written a GitHub Actions workflow to build and deploy the styleguide to GitHub Pages on every push, so that you can see the styleguide in action at https://cuny-academic-commons.github.io/commons-style-guide/?p=all

I started with some of the basic patterns that Pattern Lab ships with, and used them to learn how to use PL. A few, I customized to match what we actually have on the Commons. See eg Atoms > Tokens > Brand Colors. A bunch of them I just left in place with the default values - I'll remove them as we get started on the actual work.

I also built out our Directory Page, to get a sense of how entities might be organized - again, primarily as an exercise in learning how to use PL. See Pages > Directory. It's not perfect, but it pretty closely matches the style and functionality of our directory pages, but gutted and rebuilt for PL. How this works under the hood is too complex for this space, but you can get a sense of the potential for modularity and atomic design by noticing how the Page is built from multiple organisms (Organisms > Directory), which in turn are made out of molecules (Molecules > Directory). The inheritance structure for styles and functionality is not seamless because the original WP template were not built with these principles in mind, but it should give you a sense of how it could work once we start building things from scratch.

I went with Handlebars templates because the Twig PHP integration is only half-baked - a bunch of build steps were broken. We are a long way from having true template-level integration anyway, so I don't think this matters.

There's no Sass support built in, though you'll see the remnants of the out-of-the-box suggested setup for scss files. I couldn't figure out how to get Sass compilation built into the watch and build pipelines in a way that made sense. And since we don't currently use CSS compilation anyway, it seemed like one too many mountains to climb at a time. So all styles are currently put into the megalithic source/css/style.css, where I've left some of the table of contents and other structure suggested by the PL default configuration. We can explore CSS precompiling as a next step.

Right now, the styleguide is totally separate from the WordPress application. The style.css stylesheet might be a good place to consider the first point of true integration. I've intentionally tried to build the demo stylesheet in such a way that it was all copy-paste from our production styles. This means that we could, theoretically, yank the copied styles out of bp-nelo/_inc/css/custom.css, and load this style.css separately as the "shared stylesheet" or something like that. In this way, we could progressively move more shared styles into the styleguide and migrate them out of the theme. Then we'd need a build step (manual or automated) that moved the styleguide CSS file into the production build at the time of deployment. Let's talk more about that as we begin to tackle implementation of the homepage redesign.

Ray and Jeremy especially, I'd be glad to hear any thoughts you have about this workflow (meager as it is).

Thanks Boone, this is looking fantastic! So excited this is starting to take shape

I've been reading the back history here. I'm wondering what direction at this point @Boone & @Ray want to go in for a style guide and applying newly minted styles on the site.

It seems that the WP Core design token and style system is still a bit of a ways off from being easily managed (I got that from reading https://mrwweb.com/standardized-design-tokens-css-wordpress-future/) A lot of what is needed to interface with WordPress is a bit over my head, so I will default to Boone and Ray here.

Do we want to utilize the storybook method that Boone had started above? If so, there does seem to be a Figma plugin for it where you can compare what is in a master library in figma to what is in storybook https://storybook.js.org/blog/figma-plugin-for-storybook/

Or, is there another direction we would want to go? Opening up the floor here. Thank You!

Also, I know it might be outdated, but, could I get access to this old 2015 site?

Boone Gorges wrote:

Reposting Chris's comment from #9801:

Along those lines I have this site I made 3 or 4 years ago that is a start at documenting the current interface elements: https://redesign2015.commons.gc.cuny.edu/

Also, I know it might be outdated, but, could I get access to this old 2015 site?

I've added you to the redesign2015 site, Sara. Let me know if you are able to access it.

Or, is there another direction we would want to go?

Boone set up a test style guide using Pattern Lab here: https://cuny-academic-commons.github.io/commons-style-guide/. But that isn't currently generated dynamically.

I could see an easier path where we would add various style options to a settings page in the WP admin dashboard. When this settings page is submitted, it would auto-generate the style guide and the necessary main stylesheet like redesign-bridge.css for inclusion into our bp-nelo theme. The CSS generation shouldn't be too difficult, but depending on how complicated the style guide will be, this might not be a good option though.

Per our meeting yesterday, we decided not to do any complicated integrations and just use Figma to create a simple and static style guide. I'll update here when I have that ready