search

jpmorganchase / salt-ds

React UI components built with a focus on accessibility, customization and ease-of-use
https://www.saltdesignsystem.com
Apache License 2.0
127 stars 89 forks source link

Update site IA (information architecture) #1483

Open james-nash opened 1 year ago

james-nash commented 1 year ago

We will be publishing new content on the Salt website, so need to revisit our IA and top-level site navigation to ensure we can accommodate that new content.

Obviously, we want our IA to be reasonably stable, but we can't predict the future so the deliverable for this issue is an agreed IA structure we're confident will last at least 6 months. If changes to the IA and nav are needed past that timeframe, that's acceptable.

### Tasks
- [x] Agree and document new IA
- [ ] Update site's top-level navigation UI as needed
- [ ] Move/rename existing pages as needed
- [ ] Setup a means to measure how well the new IA is performing (or not)

Known and expected content

Here is a list of pages and sections we already have or expect to publish over the next 6 months or so. The IA we come up with should prioritize accommodating this content in a sensible way. Please add more items if I've missed anything.

External links

james-nash commented 1 year ago

Copying some internal discussions about the new IA below as comments for future reference. Please continue the discussion in this issue via comments.

james-nash commented 1 year ago

From @shinytoyrobots on 30. March:

As @JoanaMMoreira demo’ed yesterday, the Salt site has been rebuilt on Mosaic architecture.

To follow up on that work, now we can start looking at expanding the scope and scale of our content – both to provide guidance to design system users, and also to influence the ongoing design and development work of the site to be more content-driven.

I put together a draft sitemap as a potential starting point; keeping in mind that we can iterate quickly and revise based on feedback and analytics, as we create content.

About Salt

  • What is Salt?
  • Who is it for?
  • The ecosystem
  • Our roadmap
  • Releases
  • Partners
  • Case studies
  • Our research approach

Getting started

  • Designers
  • Developers
  • Contributing
  • FAQ

Guidelines

  • Content
  • Architecture

Principles

  • a11y
  • Density
  • Color
  • Typography
  • Etc…

Toolkit

  • Components
  • Patterns
  • Tokens
  • Design kits
  • Community catalog
  • Icons
james-nash commented 1 year ago

From @MitchLit on 30. March:

Hope we iterate before going live with the navigation.

Every change to primary and secondary nav creates UX and brand trust challenges for regular visitors to a site.

james-nash commented 1 year ago

From @pseys on 31. March:

I’d suggest we change Principles to Foundations for continuity with UITK and other design systems.

james-nash commented 1 year ago

From @sion-docs on 31. March:

Looks good.

In terms of content, with the new Partner initiative I think we need to be engaging users a bit more and even giving them a voice. Case studies moves towards this, but regular blogs and things like interviews would be a really good way to make them feel part of a dialogue rather than them just getting the content we deliver them. Eventually if we could curate things like videos or podcasts where our partners are the ones telling other users how they used Salt that would be great.

james-nash commented 1 year ago

From @bhoppers2008 on 31. March:

Looks good! A few questions…

Can I propose we move a11y to guidelines? Perhaps it depends on the format we intend to deliver it in, but broadly I see a few buckets for accessibility:

  • Component specific–so therefore on the comp pages
  • Foundation specific–so therefore on the relevant foundation
  • Broader accessibility strategy–more appropriate as a guideline?

Could we publish the ‘What’s in a name’ story. Where would this live?

What do you envision as ‘Design kits’? Would this encompass ‘Training’. If not can we add a training catalogue?

Where do we stand on a blog?

Is Case studies the same as a showcase of curated designs. In the past we’ve discussed publishing them, although that might be tricky externally, unless we put a solution in place?

Should ‘Our research approach’ be ‘Our approach’ to allow scope to include/publish other processes (e.g., component build?).

james-nash commented 1 year ago

From @pseys on 31. March:

Well spotted @bhoppers2008, I didn’t see the a11y in there.

Based on recent discussions it would be good to also include Data Vis and Status Indication within Guidelines/Guidance as opposed to Foundations or patterns

james-nash commented 1 year ago

From Delme Jones on 31. March:

Chiming in on the blog. It will be extremely valuable for updates/thought leadership pieces but users are not inclined to consume posts by finding a blog landing page and scrolling down (as we have in the current design). We need to think about branding that channel, introducing categorisation, and surfacing individual posts closer to the content they’re related to.

james-nash commented 1 year ago

From @shinytoyrobots on 3. April:

The discussion I’ve had with Tanya around the blog, and my general preference, is to use an external blogging platform like Medium or Substack. Several other design system teams do this (Polaris, Carbon, etc).

It provides greater discoverability, it reduces the need for us to engineer anything in our site (we can, of course, link out). We can connect articles to related topics, but it should be more about thought leadership imo, and certainly less focused on “news of updates/releases”.

james-nash commented 1 year ago

From @MitchLit on 3. April:

I agree an external platform with a focus on thought leadership and case studies is the best approach for the blog.

james-nash commented 1 year ago

From @james-nash on 3. April:

Thanks @shinytoyrobots for kicking off this thread and everyone else for chiming in.

A few thoughts:

  • I agree with @pseys’s suggestion of using “Foundations” over “Priniciples”
    • With the slight caveat, that if we had a set of overarching principles (akin to SalesForce Lightning’s “Clarity, Efficiency, Consistency & Beauty”), we’d still need a “Principles” page somewhere. But the stuff we have about usage of color, typography, space, etc. feels more at home in a section labelled “Foundations” IMHO.
  • I agree with @bhoppers2008’s suggestions around a11y content (i.e. surface it where relevant – e.g. on component pages or design foundations.
    • I also second his suggestion of having an a11y page under guidelines that outlines the higher-level approach or motivations
  • On the subject of blogging, I’m certainly keen for us to have one and to use it to publish thought leadership content.
    • I am a little weary of using a 3rd party platform like Medium to do it though. Yes, they’re convenient and have big audiences. But we’re then also subject to the whims of an external company who wants to monetize our content. It might also make automated integrations of blog posts into other sections of our site harder. For example, let’s say we have a blog post that somehow relates to Data Grid. Wouldn’t it be neat if the Data Grid component page automatically displays a link to that post (and vice versa). It’s probably still doable via APIs, but we’ve then got to align tags (or whatever metadata connects those things) on 2 separate platforms in order for those kinds of integrations to work. Perhaps we can aspire to the POSSE model (Public (on your) Own Site, Syndicate Elsewhere). We could have our own blog within the site, which has the canonical versions of the posts. But we (perhaps with the help of automation) publish copies in places like Medium to reach a wider audience.
    • FWIW, I wouldn’t object to starting with only an external blog, but I’d very much like the longer term goal to having our own blog as the official source.
  • While agree with grouping components, patterns, tokens, etc. into one section, I’m not sure about calling it “Toolkit”. I guess it might be familiar to JPM folks who have experience of UITK. But, to me at least, the word “tool” in the context of design systems makes me think of applications that consumers use to get stuff done (e.g. Figma, IDEs, plug-ins, CLI utilities, etc.). I therefore think of components, patterns, tokens, etc. as static things we give to consumers to be used via their tools. Carbon calls the equivalent section on their site “Assets”, which feels like a better fit to me. However, I’m also weary of us already copying lots of ideas from Carbon, so if anyone has a better suggestion I’m all ears!
james-nash commented 1 year ago

From @shinytoyrobots on 3. April:

Just on that final point…

Using “Toolkit” is definitely used primarily to maintain a thread between UITK and Salt. I think there’s some perception benefits in doing so.

I agree “Assets” (or similar term) might be more fundamentally accurate term.

I guess it’s a discussion about both how much importance we want to place on maintaining that UITK -> Salt thread, and how we might go about that.

james-nash commented 1 year ago

From @mikearildbrown on 3. April:

Thanks for all the feedback around the IA. We’re going to take the suggestions and use it to build out a finalised version, working with the research team to find out what works best as our approach.

On the blog front, I lean towards Medium but appreciate James’ note that we are at the whims of a third party. My concern is whether we would be able to reach the same size audience without Medium, and publishing in two places could lead to confusion around which link to publicise and share. I like the idea of starting with Medium and moving to an official blog later, especially in the early stages as we’re looking to build excitement externally. I plan to build out a content strategy that we can use to make the case for an external blog — would be great to use it to walk readers through unique development challenges, or thought leadership pieces like Robin mentioned.

james-nash commented 1 year ago

From @shinytoyrobots on 3. April:

On the research consultation…

I don’t want to over-analyze this for the site IA. There are multiple examples of good design system websites out there that we can use for navigation comparison. And we should have enough confidence as a team to make a clear initial decision to move forward.

Broadly, if we’re content driven, I’d like us to have a top level IA that we have fair confidence we can maintain for the next 6 months or so without significant change.

We can move forward on that basis and feel fairly free to iterate lower level IA and section content. Our research can then be focused on the response to that IA and content, and we can update based on that feedback and data.

james-nash commented 1 year ago

From @mikearildbrown on 3. April:

I’ll speak with @zdxd and find out how long the research should take, but perhaps we can move ahead with a preliminary IA and tweak as appropriate thereafter.

Will set up a meeting for later this week to thrash out the basics and then we can move ahead with more detailed research for updates.

james-nash commented 1 year ago

From @shinytoyrobots on 3. April:

Yes – move ahead and then refine would be my aim.

I would like our research to be almost exclusively focused on insights and feedback based on something we’ve built, rather than something we’re thinking of building. 😊 i.e. we have our own hypothesis on why we’re doing something, and the impact it will have, and we should either validate or invalidate that based on feedback on our initial release.

So, in this case – we internally confirm the top level sitemap IA as a team, build that based, and research the impact on our defined aims and on our OKRs.

james-nash commented 1 year ago

From @mikearildbrown on 4. April:

I have drafted the below IA based on Robin’s draft and some further research:

  • Other design system sites separate out patterns and components to provide fast access to each section
  • Guidelines and foundations merged into one to cover similar types of content that will be accessed less frequently
  • Dynamic content (community catalog, blog) given greater prominence

About Salt

  • What is Salt?
  • Who is it for?
  • The ecosystem
  • Roadmap
  • Releases
  • Partners
  • Case studies
  • Our approach

Getting started

  • Designers
  • Developers
  • Contributing
  • Design kits
  • FAQ

Foundations

  • Content
  • Architecture
  • A11y
  • Density
  • Color
  • Typography
  • Tokens

Components

Icons

Patterns

Community catalog

zdxd commented 1 year ago

Quickly discussed with Michael and @james-nash at different points (for ref @shinytoyrobots)

Inital desire from content to do quick one month research study - this is possible, however product desire is to do "interim IA" that houses static content that'll be created over next couple of months. So testing would to come after on a live site.

Based on above consensus now seems to be go with latter - is that correct?

zdxd commented 1 year ago

@mikearildbrown

mikearildbrown commented 1 year ago

Yes @zdxd that is my understanding too. Will wait for further feedback on proposed IA above and then we can implement + move on to research.

bhoppers2008 commented 1 year ago

@mikearildbrown I like it. Couple of thoughts:

james-nash commented 1 year ago
  • There are 7 items (potentially 8 with Support)... is that too much for the site nav?

Just quickly on that note: While we should avoid having excessive numbers of top-level links, it's worth bearing in mind that we don't necessarily need to stick with our current horizontal main nav for presenting those links to users. While it would obviously be more work, I'm not necessarily adverse to redesigning our site's global nav if it makes sense to do so.

Several other design system sites use a vertical nav, which can accommodate a larger number of links more easily and can potentially group them for easier scanning and/or expose 2nd level links.

For example, Shopify Polaris has 11 top-level links, but uses spacing to visually group them into 4 bunches:

screenshot of the Polaris website's main navigation

DataDog's Druids uses collapsible sections in a similar way:

screenshot of the Druids website's main navigation

mikearildbrown commented 1 year ago

Several other design system sites use a vertical nav, which can accommodate a larger number of links more easily and can potentially group them for easier scanning and/or expose 2nd level links.

Then there's the Apple HIG which does both horizontal and vertical at the same time: https://developer.apple.com/design/human-interface-guidelines/guidelines/overview/

I'm not too in favour of that as on paper it sounds rather messy...but a visual distinction of some sort between the different section types could perhaps work well.

james-nash commented 1 year ago

We do something similar already:

What I meant was: If the need arises, we could consider having an always-present nav that accommodate more links or levels at once. That could be replacing the current header with a permanent vertical nav that contains level 1 & 2 (and maybe deeper?) links.

james-nash commented 1 year ago

FYI: As mentioned in the issue description above, the priority here is to come up with an IA that's good enough to house what we anticipate adding over the next 6 months or so.

If our IA can live longer than that, that's great. But, if we need to significantly rejig it at that point to accommodate new content and/or in response to user feedback, then that's fine too.

To help inform this discussion, I'm therefore gathering a list of existing and expected content we expect to publish on our site over the next couple of quarters. I've added it do the issue description above and will refine/update as I find out more and we begin to prioritise things.

For now, it's a big list of all content-related issues we already have and a few other things that have been talked about here and there.

Feel free to add more items that I've missed.

mikearildbrown commented 1 year ago
  • The current Salt site has 'Support' in the navigation. It's very easy to find atm and could be important during the next 2yr migration. Thoughts on keeping that in the nav? Maybe we can put it at the bottom of the page? We could even feature all four links at the bottom – Feedback, Bug Report, Feature Request, Contact Us. I know I tend to Ctrl-F for links like this.
  • There are 7 items (potentially 8 with Support)... is that too much for the site nav? It looks like there are actually 8 as "blog" was left off in the transfer to Github...it's similar to other sites, but a lot of them use visual markers to separate the pages. Maybe we can do something along those lines.
    • Random suggestion...Should/could foundations be in Getting started, under 'Design' and 'Dev', depending on what the foundation relates to (design foundation or tech foundation)? How important is it that 'Foundations' is top level? I'm not against it but my worry is how often people would refer back to it, and where they would expect Foundations to live. Might be slightly unintuitive as an existing user to check something in Getting Started.
  • Whilst it's not high priority, can we pencil in a place for Training content? Could live under Getting Started?
zdxd commented 1 year ago

@shey-v for visibility

mikearildbrown commented 1 year ago

So speaking with Mitch he expressed concern around switching nav from top to vertical after launch as that can harm usability.

I mocked up how the site would look with 7 or 8 options along the top and thought it looked fine — I would share the screenshot but we are blocked from uploading to GitHub it seems.

Perhaps a question for the site design team. Thoughts?

See below for a redrafted version of the IA. This is based on feedback around how we should make it clear that we have three pillars to the site and Salt is one of three. Icons has also moved away from being a top-level page to reflect how frequently users would access the page — feedback on this welcome.

I'm not against splitting out Foundations and Guidelines again as per @bhoppers2008's suggestion but I think that could mean we'd have to consider a vertical nav.

Branding Content Salt Top bar nav • Home (logo on far left) • Getting started o Designing o Developing o Contributing o Design kits o Training o FAQ • Foundations and Guidelines o Content for Salt o Architecture (Robin can you provide more detail on this one to clarify what is meant?) o A11y o Density o Color o Icons o Typography o Tokens o Etc • Components • Patterns • Community catalog • Blog • About o What is Salt? o Who is it for? o The ecosystem o Roadmap o Releases o Partners o Case studies o Research approach and methods Footer • Terms of use • Privacy policy • Feedback • Bug report • Feature request • Contact us

bhoppers2008 commented 1 year ago

@mikearildbrown Looks good.

  1. Can we agree what A11y will be. If it's just us clarifying our stance on accessibility at a strategic level should it be in getting started?
  2. What's the reason for community catalog as a separate area of the site? Should community catalog just be a view in the component and pattern areas respectively? Seems like extra work for consumers to find 'stuff' if we're separating community components/patterns into a different part of the site from core components/patterns.
james-nash commented 1 year ago

@mikearildbrown That structure's looking good. I'm a little confused by what "Branding" and "Content" are doing alongside Salt though. Perhaps that's what you meant by this:

we have three pillars to the site and Salt is one of three

Can you elaborate? The site is the Salt site. Are you suggesting there may be additional branding and content sites at some point?

@bhoppers2008, yes, I think we need to flesh out what a11y page(s) and content we anticipate having. I would suggest we could look into producing some or all of the following:

Perhaps @maj-stella has more ideas on a11y-related pages we may want to add to the Salt site.

Beyond that, I guess there may be lots of little ad-hoc a11y mentions and tips in relevant sections. For example, our color foundations docs probably should say something about how to use our characteristics to achieve sufficient contrast rations, the typography foundations might say something about minimum text sizes and honoring the user's default text size preferences, etc. etc. But, I'd consider those just part of those other pages' contents and thus not standalone things we need to write and accommodate in our IA / nav.

james-nash commented 1 year ago

What's the reason for community catalog as a separate area of the site? Should community catalog just be a view in the component and pattern areas respectively?

Yes, that's my expectation too. Rather than a single "community catalogue" somewhere on a our site, I want us to expand sections like Components, Patterns, etc. to be able to list satellite DS's components / patterns / etc. alongside our own. I've written up the concept in this epic issue: #1205

mikearildbrown commented 1 year ago

Can you elaborate? The site is the Salt site. Are you suggesting there may be additional branding and content sites at some point?

Yes, that's my understanding. This is something that Mitch had flagged with me, that we should be clear the Salt site is one of three parts that will also cover branding and content. While we are drafting the Salt IA, he suggested it would be beneficial to make it clear how the Salt site sits with these other two pillars.

mikearildbrown commented 1 year ago

2. What's the reason for community catalog as a separate area of the site? Should community catalog just be a view in the component and pattern areas respectively? Seems like extra work for consumers to find 'stuff' if we're separating community components/patterns into a different part of the site from core components/patterns.

So it was a feature I kept in place from the original IA draft, but I think it's a separation we should consider retaining. It makes it completely clear which assets are produced by the Salt team and which come from a third party. That's important for quality assurance and to make it absolutely clear which assets the Salt team will support. I noticed in the #1205 issue that we want the barrier to entry to be as low as possible, which makes me think it's all the more important to make sure the distinction is crystal clear.

I'm not against moving it underneath the patterns and component headers though if we can communicate the distinction effectively inside the categories.

shinytoyrobots commented 1 year ago

There is some confusion here. Branding and Content may be broader pillars of a design industrialization "umbrella" of sites and services, but that is a separate consideration from how we build out the Salt site.

The community index is, most likely, going to be visible only internally - as I would expect the assets there to be broadly business specific and not open sourced. But we should be moving towards convergence of those indices. And I would argue that actually we want to break down the distinctions between "core" and "community" over time, to continually further democratize the contribution model.

The best analogy I can draw is something like the AWS catalog - where everything exists within the same index, but there are clear markers of that is AWS and what is 3rd party produced/maintained.

mikearildbrown commented 1 year ago

I mean for the purposes of the IA, as I understand it, we're only building out the Salt pillar anyway. Mitch requested it be included to make it clear how it will sit as part of the three pillars.

We can move Community Catalog within each individual section if that's the intended layout.

Thoughts on where Icons should go? Same level as Components/Patterns or a lower level such as Guidelines?

shinytoyrobots commented 1 year ago

I think it ends up being practically irrelevant to make clear the three pillars until we have at least two pillars. ;) (In the sense that it doesn't have a significant impact on how we present the Salt site itself).

I think the robustness of content and the numerous categorizations implies the need for a vertical left hand navigation rather than a top nav - we'll end up forcing it to be too cluttered.

Refining your previous proposal with most recent thoughts...

Top navigation

Left navigation

Assets (nav section title, but not a link)

Footer

mikearildbrown commented 1 year ago

Looks good! I agree that if we plan to have three pillars of the site it may be best to have those three pillars as the top nav and leave the Salt-specific parts in a side nav.

Few tweaks I'm wondering about:

shinytoyrobots commented 1 year ago

Looks good! I agree that if we plan to have three pillars of the site it may be best to have those three pillars as the top nav and leave the Salt-specific parts in a side nav.

Few tweaks I'm wondering about:

  • It sounded like we wanted the community catalog to exist within each section i.e. community-produced assets reveal themselves inside each asset page when the site is accessed internally. Maybe we can drop this part.

Yeah, I think at least initially that's going to get potentially confusing. We should have a single community catalog call out (and then it's a different content and design challenge to work out how that catalog filters and makes sure that the different asset classes are highlighted)

  • It sounds like "bug fixes/feature requests" under "contributing" might duplicate the links in the footer. This might not be an issue though, as if we put "bug report/feature request" links next to "contact us" it could avoid people using the contact sheet for bugs/features.

I think this is fine - no bad thing to have a couple of different routes into the same "bug report" functionality.

  • I think news and blog are kind of the same as I was expecting we'd share news about notable releases on the blog.

I suppose my only argument here would be if there are external features around Salt in future, that we'd want to link to and highlight. I wonder if there's an argument for just having "News", which might initially be 100% links out to blog articles, but would have the capacity in future to also link out to different sources.

  • I think blog should be a top level section after "about" and before "designing" as it's dynamic and regularly-changing content we'd want to promote heavily.

And, taking earlier point about consolidating News/Blog, this seems sensible.

shinytoyrobots commented 1 year ago

We need to start populating some of this content - especially getting our roadmap updated and published.

@shey-v @JoanaMMoreira - it feels like this requires at least an initial implementation of https://github.com/jpmorganchase/salt-ds/issues/1054 (Vertical Nav) to cater for the expanded content. What do you think?

bhoppers2008 commented 1 year ago

Now that we've added Nav Item to the backlog perhaps we can get together @shey-v @JoanaMMoreira to discuss feature requirements to support Vertical and Horizontal Navigation patterns. @joshwooding and I have already started knocking a few requirements together, including:

JoanaMMoreira commented 1 year ago

Sounds good! It would also be good to loop in the Mosaic team so they can add our component into Mosaic

mark-tate commented 1 year ago

re: FAQs

In a discussion with a potential stakeholder they asked the following questions By no means a full set but a good sample created by a real user.

  1. what browsers do you support?
  2. what framework dependencies do you have?
  3. how often do you release breaking changes?
  4. what accessibility standard do you support?
  5. how big is the core development team?
  6. how do we add components to our own product which might not exist in Salt Design system?
mikearildbrown commented 1 year ago

Just to summarise here on what we settled for the final IA:

Top navigation

Left navigation

Footer

mikearildbrown commented 1 year ago

@bhoppers2008 @shey-v @JoanaMMoreira hey guys do we have any update on the timescale for the vertical/horizontal nav development and when we may be able to implement some of the other pillars alongside the Salt DS?

joshwooding commented 1 year ago

Hey @mikearildbrown, the vertical/horizontal navigation work is separate. There is already a solution for navigation leveraging Mosaic so we should figure out what priority that site IA changes have so we can figure out when we can pick it up.

james-nash commented 1 year ago

@mikearildbrown @joshwooding I think the Salt site's current horziontal nav still has a bit of room to grow to tide us over in the short term:

Today we have: Home | Getting started | Components | Support and contributions

Once @pseys's initial Foundations pages are ready to go, we can comfortably add a "Foundations" link in there, so it might become: Home | Getting started | **Foundations** | Components | Support and contributions

@shinytoyrobots and I have discussed adding some of the proposed "About" pages as well in the near term, so we might expand to: Home | Getting started | Foundations | Components | **About** | Support and contributions. And, as we do within the "Getting started" section) today, we can show a vertical nav within the About section to list out its child pages.

I don't foresee any other new content pages being added this quarter, so we're good for now.

However, adding more content beyond that will begin to push the limits of what's reasonable within a single-level, horizontal nav. So we would then need to migrate to using a permanent, vertical nav throughout all of the Salt website. At that point, we can also begin re-naming/-organizing things into the proposed IA above.

I don't know off hand if Mosaic's existing vertical nav component & functionality would let us do that. In any case, the long(er) term plan is to update that component to use the new Nav Item component we'll be adding to Salt's core library. So, sooner or later, it'll be able to do everything we need.

shinytoyrobots commented 1 year ago

I agree that we can't contain more content than that in a horizontal navigation. Though I think we capture a lot of extra richness here.

I'd re-order Home | **About** | Getting started | Foundations | Components | Support and contributions

(We could probably also give ourselves a little more flexibility if we dropped Home as an actual nav option and just used the top left logo as that fairly standard pattern)

mikearildbrown commented 1 year ago

@james-nash @joshwooding thanks guys. Reason I ask is I'm aware the Content Guide team are looking to clarify the timelines on this work. As it's one of the three pillars that live alongside the Salt DS, it's something that may have to wait until we transition to the proposed IA. But it sounds like they'd be able to publish soon, so it depends on our timelines as to when they can migrate the guide across.

delmej commented 1 year ago

Yes, we're planning to do some updates and a release for the guide - it makes sense to do this as part of a migration to Salt (I've been chatting to James about this). The amount of content in the guide is significant, meaning that although we plan to build it out, it already feels like it qualifies as a pillar. One other thing is that we've just been promoting the fact that we've moved Content to a global nav item on UITK, so if we're now going to be redirecting users to Salt, it will seem odd UX for them to find Content a bit hidden under Foundations when they get there.

delmej commented 1 year ago

Ha - sorry - I meant Guidelines, not Foundations!