Giter Club home page Giter Club logo

registry's Introduction

Registry

Pulumi Registry is the global index of everything you can do with Pulumi.

Authoring a Pulumi Package

We’re always eager to expand that index with new Pulumi Packages. Whether you want to author a new native provider, bridge a provider from the Terraform ecosystem, or create a cloud component with best practices and sensible defaults built in, we’d like to work with you to list it on Pulumi Registry. To get started, use our guide on authoring a Pulumi Package of your own.

Publishing a Community Package on the Registry

Community Steps

To publish a community-maintained package on the Pulumi Registry as a community member:

  1. Ensure your provider repo has the following files:
    • docs/_index.md, which should contain a summary of the provider's purpose (required) along with a code sample (preferred). This file will render as the index page for your provider (example).
    • docs/installation-configuration.md, which should contain links to SDK packages in each language along with instructions for configuring the provider (e.g., required credentials and/or environment variables). This file will render as the Installation & Configuration page for your provider (example).
  2. Create a release of your provider in GitHub.
  3. Add your package to the community packages list via pull request to this repository.

For assistance, please reach out on the Pulumi community slack or get in touch with us via this contact form.

Pulumi Steps

Once the community member has submitted the PR to add the provider to the registry, a Pulumi staff member should perform the following steps:

  1. Review the PR. Ensure that the PR has been rebased if necessary before merging. If ok, merge.

  2. Once the PR is merged, a scheduled task will pick up the changes and create a PR to add the package metadata to the registry. A correct metadata PR (example) will include the following files, at a minimum:

    • data/registry/${PROVIDER}.yaml which includes structured metadata about the provider. This file is always included with every PR that gets generated for a new release.
    • themes/default/content/registry/packages/${PROVIDER}/installation-configuration.md, as described above. This file must be included in the first release, but will only be included in subsequent PRs if the content has changed.
    • themes/default/content/registry/packages/exoscale/_index.md, as described above. This file must be included in the first release, but will only be included in subsequent PRs if the content has changed.

    Optionally, the PR may include additional content files like How-To Guides if they are present in the upstream repo.

  3. Merge the PR if it looks ok.

  4. In pulumi/docs, a scheduled task runs hourly and will pick up any changes in this repo, generate files from the provider schema and data/registry/${PROVIDER}.yaml, and publish to pulumi.com.

This scheduled task currently lacks adequate monitoring, and should be watched to ensure that it runs correctly to completion. (If it fails, it will block all updates to pulumi.com, including marketing and manually maintained docs pages.)

About this repository

This repository is a Hugo module that doubles as a development server to make it easier to work on the pages that make up Pulumi Registry. It contains most of the Hugo content and layouts files comprising what you see at https://pulumi.com/registry -- but not everything. A few things you won't find in this repository include:

  • JavaScript, CSS, and web component - We build the JavaScript and CSS bundles that power the Pulumi Registry here, under the themes/default/theme directory. If you are making styling changes along-side content changes, use make serve-all to enable hot reloading of both the pages and CSS/JS assets.

  • Layouts and content for pulumi.com marketing pages, CLI docs, the blog, etc., all of which are managed in the pulumi/pulumi-hugo repository.

You can, however, develop locally with this repository using content from these other Hugo-module repositories, either by loading their content remotely or pointing your Hugo development server to local clones of them. More on this below.

Using this repository

Prerequisites

We build the Pulumi website statically with Hugo, manage our Node.js dependencies with Yarn, and write most of our documentation in Markdown. Below is a list of the tools you'll need to run the website locally:

Installing dependencies

The prerequisites listed above need to be installed on your machine in order to serve the site.

  1. Run make ensure to check for the appropriate tools and versions, and install any dependencies. The script will let you know if you're missing anything important.

    make ensure
    
  2. Once that succeeds, run make build_assets to build the assets the site depends on. This needs to be done before the first time you serve this repo so the assets exist on your local machine.

    make build-assets
    

Running Hugo locally

Once you've run the above successfully, you're ready to run the development server:

make serve

When you do this, Hugo will load the latest versions of:

  • The pulumi/pulumi-hugo module, which contains our marketing pages, some docs content, the blog, and our CSS and JavaScript bundles (web components, styles, etc.).

... and then start a development server at http://localhost:1313. Any changes you make to the content, layouts, or other Hugo component folders should be reloaded automatically.

Developing alongside another Hugo module

If you want to develop another module alongside this one -- e.g., add a new web component to use in the Registry, or to make changes to Registry-specific CSS -- you can point your development server to a local clone of pulumi/pulumi-hugo. To do that, first clone the repository, then add a replace line to the go.mod file at the root of this repository to override the existing reference to pulumi/pulumi-hugo temporarily. For instance:

module github.com/pulumi/pulumi-hugo

go 1.16

require (
	github.com/pulumi/pulumi-hugo v0.0.0-20211015193555-271ef1f67093 // indirect
)

// Add this line to tell Hugo to use your local clone of pulumi/pulumi-hugo.
replace github.com/pulumi/pulumi-hugo => ../pulumi-hugo

Tip: If you run make serve-assets from the root of pulumi/pulumi-hugo (in another terminal tab) while also running make serve in this one, the changes you make to the CSS and JavaScript source files in pulumi/pulumi-hugo will be recompiled and reloaded in the browser automatically.

Be sure to remove the replace line before you commit.

Temporarily pulling in content from pulumi/docs

If the change you're working on requires content from pulumi/docs -- e.g., the aforementioned how-to guides -- you may want to be able to see some of that content as you develop. To do that, just copy the files you need from the content folder of pulumi/docs into the content folder of this repository, remembering to remove those files before you commit. For example:

# Copy the AWS how-to guides from a local/sibling clone of pulumi/docs.
cp ../docs/content/registry/packages/aws/how-to-guides ./themes/default/content/registry/packages/aws/

Generating API docs for packages

The API docs for packages can be generated on-demand using the resourcedocsgen tool.

cd tools/resourcedocsgen
go build -o "${GOPATH}/bin/resourcedocsgen" .

Run resourcedocsgen --help for help regarding its use or see the resourcedocsgen README.

Submitting, merging and releasing

Before submitting a pull request, run the linter locally:

make lint

When you're ready to submit a pull request, make sure you've removed anything that doesn't seem to belong (go.mod/go.sum changes, content from pulumi/docs, etc.) and submit the PR in the usual way.

If you're doing work in another repository that's associated with the changes in your PR, you can "pin" your PR branch to another module repository branch by pointing Hugo to that branch. To do that, use hugo mod get and pass a reference to the target branch:

hugo mod get github.com/pulumi/pulumi-hugo@my-special-branch

This will modify go.mod and go.sum accordingly and result in a PR preview that incorporates your changes from the other branch. Just be sure to remove these changes before you're ready to merge.

If you would like to generate API docs for packages beyond AWS and Aiven (the docs available in PR previews by default), add the package name you would like docs for in this file. Be sure to remove these changes before merging.

Once your PR is approved and merged into the default branch of this repository, an automated process that runs on pulumi/docs will detect your changes and produce a PR and integration build containing content from all other Hugo modules. Once that PR build completes and is approved and merged into pulumi/docs, your changes will be deployed to https://pulumi.com.

registry's People

Contributors

aaronfriel avatar cnunciato avatar danielrbradley avatar dependabot[bot] avatar dirien avatar djgrove avatar gthuang avatar guineveresaenger avatar hliuson avatar infin8x avatar iwahbe avatar jaxxstorm avatar jkisk avatar jkodroff avatar kimberleyamackenzie avatar lblackstone avatar mikhailshilkov avatar mnlumi avatar pierskarsenbarg avatar praneetloke avatar pulumi-bot avatar rawdagastan avatar ringods avatar sean1588 avatar stack72 avatar susanev avatar thomas11 avatar toriancrane avatar zaid-ajaj avatar zchase avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

registry's Issues

install experience on package detail pages

this issue is meant to describe the user experience not break down associated eng work

overview

on the package detail page we want install information to be displayed up in the header so its easily accessible no matter what tab folks are on

design details

ux designs in figma

  • heading: Install in Any Language
  • dropdown that allows folks to pick a language (should get an aria-label of Language)
  • use copy component that was built by @kimberleyamackenzie

pulumi.com/docs changes in relation to registry

overview

we are going to leave the pulumi.com/docs as is on registry release but any links to things that were moved to registry should now send folks to registry

things to check

  • cloud providers no longer has children in the left nav
  • interacting with cloud providers in the left nav takes you to /registry
  • API reference no longer has children in the left nav
  • interacting with API reference in the left nav takes you to the current index page in docs as it is today
  • interacting with any of the provider cards takes you to that package API docs page
  • any other links throughout the docs that linked to these things should now send them to the new space in registry (i do not have a complete list, if someone could make that .. it would be cool)
    • setup links in get started guides
    • packages link in glossary

Sort providers by display name

On registry browse page, we current sort by package name. Can we sort by display name instead?

Action item from 10/4 registry acceptance testing. From discussion, we're not sure how easy/possible this is.

Remove language from how-to guides title

Action item from 10/4 registry acceptance testing.

On the how to guide tab for a package, the language for the guide is shown in the title (| TypeScript, in this image). Since these are shown under a language chooser, showing the language in the title is not needed.

Screen Shot 2021-10-04 at 4 50 00 PM

browse page acceptance things

  • filters should be using the icon in the ux designs
  • we need some sort of animation on close of the filters, right now it closes too quickly.. folks should be able to see the box check and things apply and then the menu close with ease
  • the entire checkbox item check and text should be interactive and show a change of mouse pointer on interaction
  • view package should be 18px, its really important that this stand out; the idea of the button on hover also helped to communicate this; also package should start with an uppercase P
  • package names should turn blue and underline on hover to represent a link
  • the subheading needs to have a max-width added to it, otherwise, the line length becomes too long and is not readable, pls see figma for suggestion. also the you can msg needs to be on its own line

@praneetloke @cnunciato wasn't sure where or how you wanted this feedback, let me know if an issue is not the right thing for you

Improve documentation to clarify how providers obtain credentials

It's difficult to always know what the order of precedence is for what a provider will use for credentials and where credentials can be picked up from. Similarly, there aren't clear debug/troubleshooting steps for when end users have trouble authenticating or making certain API calls.

Missing instructions on how to configure Service Principal permissions/roles in Azure

Problem description

Suggestions for a fix

  • Even if the instructions do not cover all the cases or if it is not possible to indicate everywhere in the API Reference what permissions/roles are needed there should be basic guidance on how to configure the Service Principal

  • Some thought on guidance to give:

    • If the infrastructure use an existing resource group, give roles to the SP on the resource group scope
    • If the infrastructure creates resource groups, give roles to the SP on the subscription scope where the resources have to be created
    • Service Principal should have the Contributor role
    • If Application registrations are created in the stack, Service Principal should have the permission Application.ReadWrite.OwnedBy of the Azure Active Directory Graph API (might change depending on this issue hashicorp/terraform-provider-azuread#193)
    • If group or user role assignment are done in the stack (often needed to give permissions on the created resources), the role User Access Administrator should be given to the Service Principal
    • See if there are other permissions commonly needed in infrastructure stacks that should be specified in the documentation

remove status filters entirely

we decided to remove the status filters entirely from the registry browse page
and instead rely entirely on version numbers to communicate whether something is public preview or ga
but they were already added, so they now need to be removed

Write up a deployment plan

We need a doc, or an issue with a checklist or similar, that clearly explains the process we'll follow to stage and then launch the registry.

UX/UI Papercuts

Starting an open ticket for UX/UI papercuts (guidelines - will only take a few lines of code, and a short amount of eng time to fix). Starting with headings in here for demo, launch, and post, with the idea that we can break out into separate tickets as we need.

Not yet triaged

  • Click target for nav dropdown menu takes up full nav bar in certain screen widths. See image below - you can click anywhere in the nav bar to open the menu, when I would expect to only be able to click the logo/icon.

Screen Shot 2021-09-30 at 2 09 42 PM

Pre-demo

  • Decrease space between the two lines of text in the subheading on the browse page

Screen Shot 2021-10-04 at 4 33 54 PM

  • “View package” link should be the same font size on the A-Z providers as on the Feature Providers card
  • Logos should take up no more than 50% of the card (Equinix Metal and Hetzner and Venafi as examples). Check both standard and small screen sizes.
  • Fix formatting of date on package page to match formatting on index page

Screen Shot 2021-10-04 at 4 46 54 PM

  • The count featured next to the how-to guides tab designed to change color when user is on that tab.
  • Match the icons on the API docs index page to the new icons in the tree nav

Pre-launch

  • On narrow screens, Google Cloud Native text in featured provider card on browse page stretches beyond the boundaries of the card (10/4 walkthrough)

Post-launch

  • [ ]

package detail header user experience

overview

there are a few differences right now between the package detail page user experience and the current experience, lets get this stuff aligned. note the install-info is defined in #54.

design details

ux designs in figma

  • include a link back to All packages pls see figma
  • source code link should include a github icon and external link icon, pls see figma
  • missing the name of the package, pls see figma
  • text in header should be Gilroy 16, right now its Inter
  • tab text size should be 20px gilroy; right now they are Inter 16
  • there is some spacing issues between the header and the tabs and the content, pls see figma for amount of space (if ya want @susanev to show you how to get this info, pls reach out)

registry how-to guides user experience

overview

we want to have a how-to guides page for every package in the registry, even packages with zero how-to guides.
all how-to guides are coming over from #11

design details

ux designs in figma

general

  • any reference to Tutorial in the registry for moved over content should be changed to How-to Guide

changes to page tab

  • add a badge that displays the total count, across languages of how-to guides

page content

  • edit this page link, should be on all pages, including how-to guides
  • language selector, display all languages even if there are zero guides
  • heading
  • list of text links to the how-to guides
  • how-to guides URLs should be /how-to-guides/how-to-guide-name

language empty state

  • if a specific language has zero guides but other languages have greater than zero guides, display empty state message under that language

total empty state

  • if there are zero how-to guides total, hide the language selector and display empty state message

contribute to registry user experience v2

important: this issue is not intended to break down the eng related work, but instead describe the user experience

note: the user experience is still being decided on with @infin8x @praneetloke and @susanev

overview

we wont have a complete self-service publish flow on launch, but we do want to provide folks with the right resources related to publishing so we will link to the authoring docs and provide a contact us form.

design details

ux designs in figma

  • update the subheading line to You can contribute your own packages too!
  • on interaction with contribute your own packages it should open a dialog
  • on send message display notification, see figma

api docs + resource names specific to a language are confusing

this issue was originally reported by @aureq

overview

it seems our API docs default to the typescript names of resources, this can make it difficult for users that know the names in other languages and not typescript.

example: https://www.pulumi.com/docs/reference/pkg/aws/getami/

its listed as getAmi but python uses get_ami

proposed considerations

  • provide a way to set a language before you are on a particular page that sets the scope for your experience
  • consider allowing folks to select a language in relation to the navigation, that updates to displays the names that are used in that language

copy cloud provider content to registry

overview

we want to copy cloud provider content over to registry and then @infin8x and @susanev will manage editing once the content is in the registry.

note: there are more than likely a lot of sections we will need to remove from overview entirely, but lets just move them all over directly for now and then alex+susan can manage the editing once its in the registry repo

we are assuming no changes will be made to the cloud provider content in docs/pulumi-hugo after the move and all changes will instead happen in registry

content details

small providers (everything except Azure, Azure Native, AWS, Google Cloud, Google Native, and K8s)

From /docs/intro/cloud-providers/[provider]/ to the new Overview page:

  • Remove the page/provider title
  • Copy the provider description verbatim
  • Remove the provider logo
  • Remove any link to full API documentation
  • Remove the setup section header and section content
  • Copy the examples and libraries sections verbatim
  • Remove the open source note at the bottom

image

From /docs/intro/cloud-providers/[provider]/setup to the new Installation & Configuration page:

  • Remove the page/provider title
  • Copy the contents verbatim

featured providers (Azure, Azure Native, AWS, Google Cloud, Google Native, and K8s)

From /docs/intro/cloud-providers/[provider]/ to the new Overview page:

  • Copy the content verbatim (we will rewrite it once it's here, so don't focus time on any polish)

From /docs/intro/cloud-providers/[provider]/setup to the new Installation & Configuration page:

  • Copy the content verbatim (we will rewrite it once it's here, so don't focus time on any polish)

azure and azure-native package details pages are mixed up

Navigating to the azure-native package results in a 404 because there doesn't seem to be a folder for azure-native under themes/default/content/registry/packages/. Navigating to the azure package shows content from the azure-native package. We might just need to rename the existing azure package folder to azure-native and actually add the classic azure package folder to this repo.

Steps to reproduce

  1. Navigate to http://www-reg-staging.pulumi-dev.io/ and click on the featured Azure Native package
  2. Also click on the Azure package from the listing under A-Z Packages

Run link checker comparing production pulumi.com against reg-staging

@djgrove and I had a chat about the link checker. Would it be possible to for our link checker to crawl pulumi.com, log all traversed links, and then run the same set of checks against https://www-reg-staging.pulumi-dev.io/ as a way to build confidence ahead of the production cutover?

Specifically I am concerned about validating that we didn't "orphan" any content (ie something was in the google index for pulumi.com, but got deleted without a redirect and but is not represented by a link in the new reg-staging link graph).

If we were able to run this check and get it to pass, seems like it would help build confidence. Would this be worth the effort?

registry search

overview

so that we do not lose functionality we want to add a swifttype search to all registry pages.
the dropdown when typing, and the dialog when using should remain the same, no visual changes there.
the results displayed should be constrained to searching registry content only.
note: there's still some things @infin8x and i have to workout together, so this is not ready for eng work yet.

design details

@susanev will add these soonish

screenshot

134733947-4600a78e-c6ac-45ca-8af2-ef3f3c4681eb

Registry top-navigation

overview

hi hi we are releasing a thing and it needs navigation
as a note we will also carry this same exact top navigation into the console as well (more than likely hiding sign in until we can do the work to move sign in/out, and the user menu up there)

design details

bigger screens

ux designs in figma

logo dropdown

practitioner nav

screenshot

registry-top-nav

smaller screens

ux designs in figma

  • increase pulumi logo size
  • add hamburger (close when open)
  • all items in same list

screenshots

top-top-nav-mobile-closed
top-top-nav-mobile-open

Document registry development loop

We have lots of repos working together including pulumi/facet and pulumi/theme. Each of these repos should have clear local development steps in the README and it should be clear how to develop them together in tandem.

browse page user experience (excluding filters)

overview

this issue defines the specifics of the user experience on the browse page (excluding the filters)
this is intended to describe the entire user experience related to filters, not make any claims about which pieces of work should be in which pr
if you are unsure how to get style info from figma, pls reach out to @susanev they are super happy to help

design details

general

ux designs in figma

text styles

  • all general dark text should be #131314, currently, our descriptions are showing as a much lighter gray color, also the sub-heading at the top of the page is also using a much lighter gray color
  • descriptions should only be shown on the featured cards
  • descriptions should be using Gilroy medium
  • view package should be using Inter bold 18px
  • the filters heading should not be an h6 as this breaks out of the heading order that's required for accessibility it should be an h2 (no change to style info, only semantics)
  • the page heading of pulumi packages should not be an h4 as the page needs an h1 (no change to style info, only semantics)
  • the featured cloud providers and a-z package heading should be h2s (no change to style info, only semantics)
  • the all packages heading should be A – Z Packages
  • individual package cards, should be using h3 for the card headings (no change to style info, only semantics)

package meta data

  • adjust the date and published by message into one line, and add version number, e.g., v4.20.0 published on September, 10th 2021 by Pulumi

view package interaction

package logos

  • we need to have a max-width on the logos, that never exceeds more than 50% of the card width; so default to a height of 3rem (or 2rem) but reduce that if the logo width ever exceeds 50% of the card width
  • lets reduce the height of non-featured packages to 2rem so there is more significant difference between the featured and non-featured packages

section headers (featured, a-z)

  • display badge next to featured and a-z headings display the count of those items, see figma frame for heading badge styles for style info
  • these numbers should adjust based on filters
  • if there are no featured packages with the current state of the filters, that heading should be hidden entirely
  • if there are no a-z packages with applied filters, display the empty message Looks like we don't have any packages that match your filters. Adjust or clear the filters and try again. with a primary button of Clear all filters
    • primary button colors are a background color of #4d5bd9 and text color of #fff

change up the browse page to allow more cards to be shown on smaller screens

overview

some folks are concerned that we don't display enough cards above the fold. these changes allow for more cards above the fold.

design details

ux designs in figma

  • reduce subheading to 2 lines, see figma
  • remove count badge from featured packages
  • remove content from featured packages cards, see figma
  • adjust layout to fit 4 featured package cards across on larger screens
  • move filters to below featured packages, and adjust filters to not filter out featured packages

screenshot

Screen Shot 2021-09-27 at 2 03 08 PM

Distinguish ComponentResource from Resource in API/resource docs.

Problem description

Some resources in the Pulumi providers are actually ComponentResource or CollectionComponentResource types and have different behavior from "normal" resources. This isn't immediately obvious and can be confusing when expecting them to work and feel the same.

As one example, k8s.helm.v3.Chart extends CollectionComponentResource which takes ComponentResourceOptions and not CustomResourceOptions. This means it's not immediately obvious to the end user that custom resource options like deleteBeforeReplace are still available but must be used as a transformation.

Suggestions for a fix

Add a Note or callout that says something to the effect of:

ℹ️ This resource is a ComponentResource and as such its inputs are slightly different than regular resources. To use custom resource options like additionalSecretOutputs, aliases, customTimeouts, etc. use transformations to customize any of the child resources of this ComponentResource.

image

Alignment fixes for content on package page

Action item from 10/4 registry acceptance testing.

During testing, we noted a number of places where the alignment of content on package tabs was a little off:

  • Content on overview tab stretches wider than content on other tabs. Make it the same width, without adding anything in the right nav.

Screen Shot 2021-10-04 at 4 56 22 PM

  • Edit this page is too far left on all tabs

Screen Shot 2021-10-04 at 4 56 36 PM

  • Misalignment between content and source code/publish date on all tabs

Screen Shot 2021-10-04 at 4 56 56 PM

browse page filters user experience v1

overview

this issue details the user experience related to the filters on the browse page
this is intended to describe the entire user experience related to filters, not make any claims about which pieces of work should be in which pr
if you are unsure how to get style info from figma, pls reach out to @susanev they are super happy to help

design details

ux designs in figma

  • filters on cards should use a #2px border-width
  • card filters should all be located in the same position on cards, 36px total (32+4) from the bottom of the card, they should not rise from that position even if there is less content on a card
  • when a user opens a filter menu and changes the state of a checkbox the change should take place immediately and the menu should be closed
  • filter rest styles (no applied filters): pls see figma
  • filter applied filtes: pls see figma; if applied filter, users can remove the filter by opening menu and unchecking box or by interacting with the close-x on the shown applied filter
  • filter hover/focus/selected styles: pls see figma
  • filter with open menu: pls see figma
  • unchecked checkboxes should be #131314 to match the default dark text color

screenshot

filters

registry header

overview

below the top nav we need a header for registry, for now this will only contain the registry name and icon but later we will add search to this section

design details

ux designs in figma

  • use the same dots as our marketing pages
  • note that their should be an overlay where the dots overlap the registry name to make it readable (we do this on the pulumi home page currently)
  • pulumi registry is in 24px bold gilroy
  • pls see figma for detailed style info, and pls reach out if you don't know how to get it from figma
  • interacting on the icon or pulumi registry name should take you to the registry browse page

screenshot

Screen Shot 2021-09-24 at 1 08 10 PM

registry api docs user experience

overview

we know the API docs are difficult for users to navigate. with the move to registry lets make this easier for folks to quickly find what they need.

design details

ux designs in figma

filter left-nav

  • introduce a left navigation with the label API Navigation
  • present a filter box, with the placeholder text Filter
  • each type module, resource, function should have an associated icon that displays to the left of the item
    • letters are Gilroy bold, 9px
    • outline circle is 1px width
    • use the current colors for modules, resources, and functions as in the current API docs
  • anything that is a module should have a dropdown arrow to the right, indicating it has children
    • these should all be collapsed by default but auto expand if a filter is applied resulting in a child result
    • note: all of these module pages will still have associated pages, so interacting with the label should display the page; interacting with the drop down arrow should expand/collapse the menu
    • dropdown arrow icon should rotate when open/close
  • as users type in the filter box we should immediately scope down their view to only include results that match what they are typing (anywhere within the name of the thing)
    • @kimberleyamackenzie is gonna own the debounce decisions
    • any child that is a filter result should also expose the parent path to get to that child even if the parent does not match the filter results
  • [ ] #38
  • when on a selected page, the font-weight should increase in the left nav indicating where they are
  • the left navigation should not extend beyond the height of the center -page content, introduce a scroll bar in the left nav when this is the case
  • any item that does not fit in the space of the left nav should have a ... appended to it, indicating more content
  • style info is available in figma

screenshot

refined-api-nav

API docs left nav follow-up: UX review and cleanup

Follow-up from: #10. This ticket covers any minor UX cleanup that needs to be done, as well as any items that come from a more in depth UX review. Will be updated with items as they come up, and after I do a more in-depth review - just my own notes for now!

  • Styling of selected items - what classifies as a selection? Should it be active (clicked) or just the item correlating to the current view?
  • Styling for the active input
  • Some of the items in the nav don't show ellipses as expected (but some do).
  • any name that has an ellipsis should also have a tooltip on hover to reveal the complete name

add get started to top-nav

overview

in collaboration with marketing we want to add a get started button to the top-nav so new users have easy access to the get started guides in our docs.

design details

ux designs in figma

  • add get started button to the desktop nav to the right of the logo dropdown
    • text is #ffffff 14px inter
    • border is #805ac3, 20px radius
    • on hover/focus should use the same gradient as the buttons on our marketing pages
  • should link to docs/get-started in the current tab
  • mobile nav does not require any changes

screenshots

Screen Shot 2021-09-27 at 11 40 28 AM

get-started-button

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.