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

Stability attribute should not be displayed as just color #24201

Closed
rodrigorc opened this issue Apr 8, 2015 · 13 comments
Closed

Stability attribute should not be displayed as just color #24201

rodrigorc opened this issue Apr 8, 2015 · 13 comments
Assignees
Labels
T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@rodrigorc
Copy link

In rustdoc documentation, the stability attribute is shown as a little vertical bar to the left of the item. In the main window of crates, types, etc. it is also shown as text in the header of the window. But some items, as impl member functions do not have a proper window, so the stability is never seen in plain text.

It is a well known usability rule that relevant information should never be revealed with color only, as the sensibility to color varies highly between individuals.

I would like stability to be shown as a letter, icon or something other than color alone, so that color-blind people will see what they are doing.

@steveklabnik
Copy link
Member

We chose the current colors to be decent for color-blind people, IIRC.

@steveklabnik steveklabnik added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Apr 8, 2015
@killercup
Copy link
Member

The colored bars have tooltips (like "stable" or "deprecated").

This reminds me: many stability attributes contain further information that is only "visible" in that little tooltip if you hover above that small colored bar, e.g. "Unstable: should ideally be implemented for all fixed-sized arrays". (rustdoc just writes this to the title attribute of the a.stability element).

This doesn't work for touch devices. Should that information be displayed more prominently? (Might be another issue, sorry of this is too off-topic.)

@steveklabnik
Copy link
Member

We have an issue for that already, @killercup

@rodrigorc
Copy link
Author

There are a lot of color-blindness types. Choosing a set of about 5 colors easy to differentiate for everybody is practically impossible.

See for example this image:

stability

I can barely see the difference between the orange and the green ones, unless they are just next to each other. And I'm just slightly color-blind. (The magenta one is fine for me though.)

The problem with the tooltip is double: 1. you cannot see it in touchscreens. 2. You have to move the mouse over it for every function, and there may be a lot of functions to check, if you want to use only stable functions you have to step through all of them.

@steveklabnik
Copy link
Member

I'm not saying that it's perfect, just trying to add some context.

@rodrigorc
Copy link
Author

Don't worry, we color-blind people are not very sensitive about this ;-p

However, the rule of not using only color for conveying information stands: any combination other than black / gray / white will be confusing for somebody. And imagine the situation with real blind people and screen readers!

For me adding an icon, or even a simple uppercase letter (S for stable, U for unstable, D deprecated) would be more than welcomed.

@killercup
Copy link
Member

I couldn't help but think of icons for this.

state icon
stable 😃
unstable ⚠️
deprecated 💀

@steveklabnik
Copy link
Member

@killercup that is.... amazing

@vogon
Copy link

vogon commented Apr 8, 2015

some prior art: developer.mozilla.org uses icons for "deprecated" and "unstable", as well:
autocapitalize
x-moz-errormessage

@killercup
Copy link
Member

@steveklabnik, thanks. I was gonna go with ❄️ for "deprecated", but then stable APIs are kinda frozen…

I'd prefer to use a monochrome icon font, though, using the old colors ;)

@lilyball
Copy link
Contributor

lilyball commented Apr 8, 2015

I like the icons idea. They'd also provide good touch targets for revealing the stability info (which is important for non-touch devices as well; users may not know to expect a tooltip, and you can't copy text from a tooltip).

@aturon
Copy link
Member

aturon commented Apr 8, 2015

I also really like the idea of icons; I think we should remove the little color blobs altogether. I also think that stable APIs should have no marking (they should be the default), and the icons should go to the right as in the above comment. That would help with some other alignment issues as well.

@rodrigorc
Copy link
Author

@aturon: Agreed. I like the mozilla style best. Profesional and easy to see from a distance.

About the tooltip information, I would keep it as tooltip in content lists, such as members of a crate, but promote it to full paragraph when viewing the details. After all, the reason for unstability is IMO quite important.

@alexcrichton alexcrichton self-assigned this Apr 10, 2015
alexcrichton added a commit to alexcrichton/rust that referenced this issue Apr 14, 2015
This commit is an overhaul to how rustdoc deals with stability of the standard
library. The handling has all been revisited with respect to Rust's current
approach to stability in terms of implementation as well as the state of the
standard library today. The high level changes made were:

* Stable items now have no marker by default
* Color-based small stability markers have been removed
* Module listings now fade out unstable/deprecated items slightly
* Trait methods have a separate background color based on stability and also
  list the reason that they are unstable.
* `impl` blocks with stability no longer render at all. This may be re-added
  once the compiler recognizes stability on `impl` blocks.
* `impl` blocks no longer have stability of the methods implemente indicated
* The stability summary has been removed

Closes rust-lang#15468
Closes rust-lang#21674
Closes rust-lang#24201
alexcrichton added a commit to alexcrichton/rust that referenced this issue Apr 15, 2015
This commit is an overhaul to how rustdoc deals with stability of the standard
library. The handling has all been revisited with respect to Rust's current
approach to stability in terms of implementation as well as the state of the
standard library today. The high level changes made were:

* Stable items now have no marker by default
* Color-based small stability markers have been removed
* Module listings now fade out unstable/deprecated items slightly
* Trait methods have a separate background color based on stability and also
  list the reason that they are unstable.
* `impl` blocks with stability no longer render at all. This may be re-added
  once the compiler recognizes stability on `impl` blocks.
* `impl` blocks no longer have stability of the methods implemente indicated
* The stability summary has been removed

Closes rust-lang#15468
Closes rust-lang#21674
Closes rust-lang#24201
quantheory pushed a commit to quantheory/rust that referenced this issue Apr 17, 2015
This commit is an overhaul to how rustdoc deals with stability of the standard
library. The handling has all been revisited with respect to Rust's current
approach to stability in terms of implementation as well as the state of the
standard library today. The high level changes made were:

* Stable items now have no marker by default
* Color-based small stability markers have been removed
* Module listings now fade out unstable/deprecated items slightly
* Trait methods have a separate background color based on stability and also
  list the reason that they are unstable.
* `impl` blocks with stability no longer render at all. This may be re-added
  once the compiler recognizes stability on `impl` blocks.
* `impl` blocks no longer have stability of the methods implemente indicated
* The stability summary has been removed

Closes rust-lang#15468
Closes rust-lang#21674
Closes rust-lang#24201
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants