swagger-api / swagger-api/swagger-ui

Separating "Server Response" from "Responses" always takes mental effort.

Open
#6,548 13 comments 26 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

cat: style & presentation cat: user experience
Dominant language
JavaScript
Stars
29k
Forks
9.3k
Avg merge
2d 23h
Merged PRs (30d)
25

Description

I love Swagger UI. And this is a minor UI flow issue that I thought I would raise just incase others agree and it can get support.

When I use the "Try it out" button and run the operation, I always have to take a bit of mental effort to separate the actual response, from the list of potential responses.

This is (at least in part) because the Text "Server Response" and "Responses" is smaller than the headers ("Code" and "Details") for each section:

SwaggerUIResponses

I think that increasing the size of "Server Response" and "Responses" would help. But I also think that changing "Responses" to "Potential Responses" would help clarify that they are not actual responses from the server.

Last I think that using some other visual separation between the request information and "Server Response" and also between "Server Response" and "Responses" would be helpful. A line or some other break in the UI flow.

The goal is to allow me to flow right to the Server Response without having to work mentally to track where that value is.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the Swagger UI "Try it out" flow that renders the "Server Response" and "Responses" sections, then compare the layout with the linked screenshot. The work is done when the actual server response is visually distinct from the potential responses and the hierarchy is easier to scan.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
design, frontend
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.