View
Display or examine content in a specific format or perspective.
View spans an enormous range across GitHub, from reading a single file to browsing a directory tree, scanning a pull request diff, watching a workflow log stream, or opening a project item beside the board it lives on. What ties them together is a decision about surface: where to show the content, and how much to interrupt what someone's doing to see it. When the surface doesn't fit the content, people lose their place and have to work to get back.
Where this happens
- View a file in a repository
- View the files changed in a pull request
- View the details of a workflow run
- View a discussion
- View full details of an item in a project
- View the edit history of a comment on an issue
See all view scenarios in the Scenarios repo (GitHub staff only).
Implementation guidelines
-
Navigation components: Match the Primer component to the content structure so keyboard navigation and active-state semantics are handled for you: NavList for sidebar item lists, TreeView for hierarchies, and a tabbed control for switching between views of the same data. The tabbed navigation decision guidance covers whether to reach for UnderlineNav, UnderlinePanels, or SegmentedControl based on whether the view changes the URL.
-
In-context surfaces: Use a Dialog side sheet for substantial detail shown without leaving the current view, and a centered Dialog only for transient, read-only content. Both manage focus and dismissal for you; see Dialog accessibility.
-
Collapsible content: For content people expand and collapse, like tree nodes, folded diff regions, or truncated text, reach for the established progressive disclosure affordances rather than a new control, so the trigger stays recognizable.
-
Loading: Scope a Spinner or skeleton to the area the content will fill. See Loading.
-
Errors: Show failures inline where the content would have appeared with a Banner or Blankslate, following notification messaging.
-
Announcements: Announce asynchronously loaded content, status changes, and errors through a live region so they reach screen reader users. See Accessible notifications and messages.
-
Focus in split layouts: When selecting a list item updates the detail in place, keep focus in the list so keyboard and screen reader users can keep moving through items, and announce the change through the live region rather than pulling focus into the detail.
User experience principles
Match the presentation to the content
How much content you show, and where you show it, should fit the content. Show the essentials first and let people reveal more on demand, so a view doesn't overwhelm with detail no one asked for. Then match the surface to how much the content should interrupt: primary content someone came to read belongs inline, substantial detail they want to glance at without leaving belongs in a side sheet, and brief, transient content belongs in a dialog or hovercard. A modal traps focus, so it suits a short read but makes exploring harder.
Default to a simple view that shows the essentials, and let people opt into more detail by expanding it in place or opening a dedicated page when the detail warrants one.
Present all the detail up front when most of it isn't needed yet, or make the essential content hard to find in it.
Show primary content inline, put substantial in-context detail in a side sheet that keeps the underlying view in place, and reserve a modal dialog for transient, supplementary content like an edit-history diff.
Put primary content someone needs to explore inside a modal dialog, or send them to a new page when a side sheet would keep their context.
Give hover-triggered content like a hovercard a non-hover path on touch devices, and let a side sheet fall back to a bottom sheet or full-screen dialog when there's no room beside the content.
Rely on hover alone to reveal content, or assume a side sheet can always sit beside the view.
Avoid unnecessary navigation
Navigating away and back has a cost, so avoid it when content can come to people instead. Let them open detail from the thing itself and move between related items without leaving the view. The same holds when content is slow or fails: keep the loading and error states in place rather than replacing the whole view with a page-level spinner or a full error screen.
Open an item's detail from its own title, and keep the parent list on screen in a split layout, like the repository file tree, so people move between items without navigating away and back. At narrow widths or high zoom, let it reflow to a single column with navigation between the two.
Route people through a secondary control to reach detail, or force a full navigation away and back to move between related items.
When people work through a list in order, like a notifications inbox or a review queue, let them advance to the next item from within the current one.
Make people return to the list after each item when you know they're moving through it in sequence.
Keep slow or failed content in place, so people stay oriented. Show a placeholder where it will appear, and give an inline error a recovery path like a raw view or a retry.
Replace the whole view with a page-level spinner or a full error page for a transient failure, when the rest of the view could stay usable.
Make the current position unmistakable
When people move through tabs, a tree, or a list of items, they need to know where they are: which view is active, which item is selected, what's expanded. That signal gives clear orientation within the content, so make it obvious visually and expose it to assistive technology.
Give the active view, selected item, and expanded state a clear cue that doesn't depend on color, and expose that state to assistive technology.
Signal the current view or selection with color alone, or convey a state visually without exposing it to assistive technology.
Let people share and restore what they're viewing
When what someone is viewing carries meaning (the active tab, a selected item, a highlighted line), people expect to link to it or return to it and find the same thing. Make that state reproducible so a shared link opens the same content and a reload doesn't lose someone's place, and give a direct way to copy the link. State that's transient, like a scroll offset, doesn't need it.
Encode meaningful state, like the active tab, selection, or highlighted line, in the URL so a link or a reload restores it.
Keep state worth sharing only in component memory, where a reload or a shared link loses the tab, selection, or position.
Give people a control to copy a link to what they're viewing, like the code view's option to copy a permalink to a selected line range.
Leave people to copy the address bar when it doesn't capture what they're looking at, or to assemble the link themselves.