Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/pkgsite: redesign - the documentation section #41587

Open
julieqiu opened this issue Sep 23, 2020 · 4 comments
Open

x/pkgsite: redesign - the documentation section #41587

julieqiu opened this issue Sep 23, 2020 · 4 comments

Comments

@julieqiu
Copy link
Contributor

@julieqiu julieqiu commented Sep 23, 2020

We'll be redesigning pkg.go.dev based on feedback received over the last year. This is the second in a series of issues about plans for the pkgsite/design-2020 milestone. Comment below with any feedback or suggestions related to this issue!

Overview

The documentation section of the pkg.go.dev/<path> page will have the following changes:

  • Documentation index section will be added back
  • Top level heading for each section will always be present
  • New features for copying and viewing source code

Design

Here's a preview of what the documentation section will look like:

Issue2-maybesmaller

Note: The images shown in this issue are mocks, so the data may not accurately represent the exact contents of a given package.

Documentation Index

Based on feedback that we've received, we understand that users find viewing the full package API useful, so the documentation index will be added back.

image

At the same time, we’ve heard that having a sidenav is useful for navigating the documentation, especially when the documentation is very long. We plan to keep this feature as well. In the new design, the function and type sections will be closed by default, since having everything expanded can be overwhelming. When a user clicks on a function or type from the index, that section will auto-expand.

image

Empty Sections

We want to create a consistent structure across different packages in the documentation section. Therefore, when a section in the documentation is empty, we will still display the section header (for example, "Variables"), along with a message indicating it is empty ("There are no variables in this pacakge."):

image

We believe that doing so allows users to become familiar with the structure of this section over time. More importantly, UX research has shown that consistent documentation is important for accessibility. For screen reader users, having a consistent documentation structure allows them to predict the page structure. This means, for instance, if they know “Variables” is the fourth header, and they’re looking for variables, they can bounce to the fourth header without listening to each of the first three.

New Features

image

Copy
Next to each code block, we will be adding a copy button, so that users can easily copy and paste the code in that block.

View Source Code
We also want to make jumping to the source identifier a more discoverable feature. To do so, if a block of code corresponds to a function, type or method, we will also include a source code widget. Clicking on that link will take users to the source code.

Related Issues

  • #40612: LHS navigation panel is "lossy"
  • #40715: landing page for docs provides no structural information at a glance
  • #40577: auto-expand left sidebar
  • #41486: malformed function signature on LHS index
  • #40773: confusing scrolling (and header scrolls off the top)
@julieqiu julieqiu closed this Sep 23, 2020
@gopherbot gopherbot added the pkgsite label Sep 23, 2020
@gopherbot gopherbot added this to the Unreleased milestone Sep 23, 2020
@julieqiu julieqiu changed the title x/pkgsite: <this issue is a placeholder for a future issue> x/pkgsite: redesign - the documentation section Sep 23, 2020
@julieqiu julieqiu reopened this Sep 23, 2020
@julieqiu julieqiu added the NeedsFix label Sep 23, 2020
@tooolbox
Copy link

@tooolbox tooolbox commented Sep 24, 2020

Thanks for posting, @julieqiu, my 2 cents:

Based on feedback that we've received, we understand that users find viewing the full package API useful, so the documentation index will be added back.

Great!! 🎉

At the same time, we’ve heard that having a sidenav is useful for navigating the documentation, especially when the documentation is very long. We plan to keep this feature as well. In the new design, the function and type sections will be closed by default, since having everything expanded can be overwhelming. When a user clicks on a function or type from the index, that section will auto-expand.

This sounds good and the mock GIF looks good as well. Initial reaction is that it's cool that the README is in the sidebar as well, and I feel like the header (with package version, refresh date, license, etc.) seems improved.

We want to create a consistent structure across different packages in the documentation section. Therefore, when a section in the documentation is empty, we will still display the section header (for example, "Variables"), along with a message indicating it is empty ("There are no variables in this pacakge.")

I think this is a great idea.

Next to each code block, we will be adding a copy button, so that users can easily copy and paste the code in that block.

Sounds neat; not major, but neat.

We also want to make jumping to the source identifier a more discoverable feature. To do so, if a block of code corresponds to a function, type or method, we will also include a source code widget. Clicking on that link will take users to the source code.

Sounds good; it would be cool to have an example as well. Linking into appropriate source locations is a very useful aspect of the docs, so expanding this is capability sounds like a move in the right direction, although it could perhaps be overdone with links in every nook and cranny.

Thanks again!

@julieqiu
Copy link
Contributor Author

@julieqiu julieqiu commented Sep 24, 2020

Thanks @tooolbox! That's great to hear :)

Sounds good; it would be cool to have an example as well. Linking into appropriate source locations is a very useful aspect of the docs, so expanding this is capability sounds like a move in the right direction, although it could perhaps be overdone with links in every nook and cranny.

Clicking on <> in screenshot under New Features would take you to the source code. On hover, both <> and copy icon will display a tooltip that provides context on what that icon does.

@Delta456
Copy link

@Delta456 Delta456 commented Oct 3, 2020

The redesign looks amazing! Can we also show how many downloads or go gets were there for the module as NPM, PIP etc also show it? I most of the time have to see git clones.

PS: I didn't want to open a separate issue for this.

@julieqiu
Copy link
Contributor Author

@julieqiu julieqiu commented Oct 6, 2020

@Delta456, glad to hear! If you don't mind, could you please raise a separate issue for this? While the feature you suggest sounds interesting, it doesn't fit under the umbrella of this design issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.