The core team have completed our retrospective on the 2018 Rust website redesign: https://blog.rust-lang.org/inside-rust/2020/05/26/website-retrospective.html. It took a bit longer than we would have liked, sorry for the delay.
33 Likes
I don't know what the fuss is about. The website is fine. It's sober, it serves its purpose.
2 Likes
I started with rust in the 1.3 days. In the run up to the edition I was routinely reading all of internals, users, and r/rust. So I felt established and well informed. One of the things I loved about rust is the team leadership setup. Design by crowd is limited by having the decision only up to the team of respected experts. But, to acknowledge that most of the time someone in the audience is more knowledgeable than the team on this decision, all decisions need to be made in public with time for feedback and based on rationale that had been articulated before the decision. The norms were old when I started, and well established by the creation of editions.
The first I remember being aware of the new website was when it went live. My impression at the time was, and a good TLDR of this retrospective is, that the norms for how rust is governed were not followed for this project. The fact that the Core Team had allowed this project to not follow the norms of the community hurt a lot more than the details of what was still to do on the website. The scales fell from my eyes over this.
I am still involved in rust. Since then I have even joined the cargo team. But I feel the need to articulate why this incident is so painful to me.
Anyway, thank you to all of those that have made this retrospective happen. It sounds like it was a project all on its own.
14 Likes
(speaking only for myself)
This is not the process, and the idea that it is (so prevalent in this communtiy) is a big part of what burns me out on Rust.
There are sometimes niche intersections on which we need outside expertise, but in general the Rust teams are the most knowledgeable people. They are the experts for a very obvious reason: they have the most intimate knowledge of the development history and inner workings of the subject of discussion, they have spent the most time considering the question, they are the ones for whom this is central to their working life. Of course they are the most knowledgeable!
The process is premised on the idea that good ideas do not always come from the most knowledgeable. This is not the same as the idea that the teams are not the most knowledgeable. The role of the public commentary process is meant to be to identify ideas that are better than the ideas that we, the experts, have had. But it requires expertise to identify that an idea is actually better.
All of the faults in how it was executed, the website's content was produced by the people who are the world experts in generating Rust adoption. They have conducted the surveys, met with production users, written white papers, and so on. There are people for whom that is their expertise. This expertise is ignored by commentators who, for example, continue to valorize the content on the old website as "for developers" while the new website is "marketing fluff."
One of the ways in which open source is broken is this exact elevation of the commentator en masse over the expertise of the makers. Many of the best ideas in the development of Rust have come from people who were not experts, and this is why soliciting feedback in the manner we do has been so productive for us. But the attitude expressed in this comment is part of a large scale devaluation of project leadership's expertise and competence which makes it very hard for me to continue working in this environment.
34 Likes
I think your explanation of the Rust process is insightful. I'm not entirely sure that it disagrees with @Eh2406's experience of it even if it disagrees with how they have written it up here. At least, the rest of @Eh2406's post seems to still work within the context of your explanation:
That is, sometimes the best ideas come from people who are not the experts. In this case, there was little chance for the experts to accept/work ideas from the "commentator en masse" (which seems a little pejorative to me) even if they were good ideas. I felt that was a step back from the process that was seemingly institutionalized earlier in the RFC process (usually summarized as "no more new ideas"), and it was disheartening to me that the project allowed substantially the same mistake to happen again.
4 Likes
I don't remember everything that happened when the website was launched. I remember that I was surprised, because I didn't even know that there would be a new website. I also remember that some people posted very aggressive and hateful comments on Reddit and other forums. Many criticized the design, there was even a pull request to change the whole design and give everything a white background. I bet the developers didn't like getting so little appreciation for their hard work.
4 Likes
I don't care much about the specific argument, but as a person with depth in a different background (philosophy and the history of thought), I can identify this sentiment as representing a fundamental and recurrent fallacy.
I write in the hope that a different perspective might actually make you less 'burnt out' than moreso: as a philosopher, I also recognize you probably "know" all these things, but having them put this way may be of use.
Requiring an expert to identify, enunciate, and defend exactly some proposition, publicly - for instance, whether something is better or not - is the correct way of utilizing expertise. That an expert identifies some ideas as better than another is of no more objective, prudential value than any other position of any other person.
Examples of common bias fallacies of an expert - part of an "establishment elite" that embody the the institution they represent - multiply. You probably know a lot of them by heart: "not invented here", "we've already done that", "insufficient difference to make a difference", and various things that reflect Lennonist "democratic centralism" - the notion that once a thing has "been decided" by the majority of the elite, it's no longer up for question, and everybody who was on the losing end of the proposition should just 'let it go' in order for the greater body to 'make progress'. These are all wrong, and wrong-headed.
Experts rarely have the capacity to adjudicate outside of their expertise, and meta-decisions (about the greater 'good' or 'bad') are invariably outside of expert's domain. You see it in the historical decisions of the 'top men', the 'best minds' or whatever elite phraseology is in use - such-and-such decision balances prudential judgments in a way that the hoi polloi can't fathom, and the experts don't have time to elucidate. In history, it's almost always b.s.
Put another way: if you put an expert in-charge merely because they are an expert, you will invariably gain an expert in-error, and doing so leads to generating systematically erroneous outcomes.
For instance, from "the website's content was produced by the people who are the world experts in generating Rust adoption", it does not follow that the content was good. At all. Even in the least. For instance, there are 'world experts in generating Go adoption' - which may be, in all ways one could measure, better too at generating Rust adoption, had the least among them turned their attention to it. They didn't, so it's not.
"One of the ways in which open source is broken is this exact elevation of the commentator en masse over the expertise of the makers." If the experts can't defend their positions, then it's often the case that the position is indefensible. Further, if the experts cannot, or will not, understand the objections of the outsiders and be able to provide an objective argument contrary, then expertise be damned.
Obviously, there's not enough hours in the day, and if this was a case of just dealing with one-offs, trolls, or whatnot, I suspect we wouldn't be talking about it.
However, the contrary notion that expertise comes with intrinsic privilege is antithetical to all the sciences (including philosophy): it's fine for priests and Bishops, and for professors of modern literature, but it's regressive for people who are attempting to do things.
Another vector of the tendency to rely on experience - "mastership", does ride with some crafts - including software engineering - but, this is fundamentally anti-progressive and anti-intellectual - ultimately, it's a form of misology, and has as much to do with "these damn kids who don't know anything" as anything else: what the master knows is special, and cannot be captured and transmitted in words, it's become muscle memory, and only a long and arduous path can allow the non-elite into the inner sanctum.
However, this is fundamentally the narcissistic b.s. of the aging mediocrity: if you can't or won't teach, if you can't or won't form those who come after you by explaining, then you have no claims to mastership.
And, it's this last thing that should, I hope, in the final analysis, help with your burnout: you're not arguing with some opinionated jerks on the internet. You're teaching - potentially, a bunch of people. You're transmitting what you yourself were given at various times and places, and what you have come to know.
31 Likes
Design is to a large extent subjective, and designers (along with everyone else) tend to underestimate that. As a not-entirely-relevant example, I remember reading comments back in the day that flat UI design was objectively superior, because it removed unnecessary visual clutter and prioritized the actual content being displayed. These days I'm more likely to read claims that flat design is objectively inferior, because it hides visual affordances and forces the user to guess. Both perspectives have valid points, but much of the difference in attitude over time comes down merely to shifting fashion trends.
That doesn't mean the website designers should have listened to all the community perspectives. On the contrary, design by committee gets worse the more subjective the topic. With an objective topic, initially divergent beliefs should eventually converge on a single truth. With a subjective topic, they'll stay divergent, making it impossible to combine them all into a coherent whole.
But it does mean that expertise only goes so far. I believe that on the big hot-button design questions (as opposed to the details), on average, community members' opinions were not much less valid than the community team's. Therefore, the only reason to disregard them is that too many cooks spoil the broth.
Do you disagree? One of the most prominent (and complained-about) changes in the 2018 overhaul was the removal of the 'playground' widget with editable and runnable code samples. Yet, as some people pointed out when complaining about the removal, many different programming languages' homepages have similar widgets. The websites of Go, Python, Haskell, and Reason all have both (a) code samples on the homepage and (b) a 'playground' environment either directly embedded in the homepage or (in Reason's case) linked as the most prominent link on the page. Additionally, the websites of Ruby, Elixir, Dart, D, Nim, OCaml, and Zig have code samples on the homepage but without the very prominent playground.
In contrast, the new Rust homepage has no code samples and the playground is not emphasized. Plenty of languages' websites do share those attributes, such as Node.js, Erlang, PHP, Perl, Swift, and Lua. But almost all of those websites (with the possible exception of Node) also seem less 'designed', lower-effort, than the ones with samples. Having a high-design website with no code samples on the homepage is a combination relatively unique to Rust.
The Rust community team probably does have more expertise than the designers of some of those websites. But does it have more expertise than all of them? Or is Rust so different from those other languages that the value of featuring code samples is significantly different?
No. The Rust team just made a different subjective choice: to have the homepage focus on telling users what Rust does, as opposed to showing them how it looks. They may have been trying to approximate a theoretically objective goal, "pick the design that has best impression on the most users". And they may have considered some objective evidence (survey results?). But with very little evidence available, the evaluation was inevitably highly subjective. It's not like they did a website A/B test. (And even if they had, A/B tests are prone to misinterpretation.)
Anyway, circling back around:
I guess the question is whether the issue was only one of communication. I hope and believe it was – that any perceived dismissiveness towards the community was, as the retrospective suggests, an unintentional result of rushed deadlines, conflicting expectations, and miscommunication in general. Perhaps combined with a failure to explain the spoiling-the-broth issue.
On the other hand, if someone in an authority position shared the view that community members' opinions should be disregarded as invalid, rather than just because of too many cooks spoiling the broth… well, you can try to soften the blow, but perhaps it's impossible to avoid coming off as at least a little dismissive.
With some topics, where expertise matters a lot, that's unavoidable. With website design, it's simply an incorrect belief. Having your views disregarded is frustrating even when you're in the wrong; having your views disregarded on what you know to be incorrect grounds is much worse.
27 Likes
A couple of observations from the perspective of an occasional contributor to various Rust web sites:
-
When making changes to the Rust language and libraries, we need to get things exactly right before we ship them, because we have a very limited ability to change them later. This affects every aspect of the engineering culture, leading to a long, careful process with lots of feedback and consensus building early on, but then a design that is frozen before release.
I think our community is so used to this that we subconsciously bring similar expectations to web development and design, even though none of the same constraints apply. I think this partly explains the community’s reaction to the short window for feedback and changes before release. It also may explain the team’s process that (as the retrospective said) didn’t plan enough for feedback and fixes after release.
-
Despite what I said above, I’ve also been disappointed by our willingness to ship bugs and regressions in our web sites that we would not accept in our other software. This is especially frustrating for an occasional contributor like me. Some personal examples:
-
I contributed a small feature to the Playground. My PR was reviewed and merged; it had a bug, which I fixed... and then, less than a month later, that Playground codebase was thrown out, replaced by a fork that had conflicting changes with my patches. Nobody warned me that I was contributing to a code base that was scheduled to be abandoned, nor did they keep their fork up to date with contributions from “outsiders” like me. I didn't had the time or motivation to then redo my work on the new playground.
-
I made a small change to improve the usability of the Cargo docs, which was later reverted without comment by a random commit in an unrelated PR, seemingly without anyone checking or commenting in my PR that had added the change.
-
I have repeatedly added redirects to the website and docs when people did things that broke existing URLs. This includes the 2018 redesign, which broke every link to every resource on www.rust-lang.org, such that no Rust projects had working links the code of conduct, and some tutorials no longer had working links to download Rust. I submitted a PR to fix this the very next day.
But despite the fact that I was at the Mozilla All-Hands at the time, and let team members know in person that they could even walk over and work directly with me to get it reviewed quickly, it wasn't reviewed or merged until four days later, and wasn’t deployed until two weeks later. Even then, some of the old community-contributed content (including some that I had personally written) was simply taken down with no replacement or new permanent home.
-
The 2018 redesign also threw away all the community-contributed translations, without giving the translators any warning so they could get a head start on re-translating everything from scratch, or any tools to help them do so. (The retrospective says the redesign finished on time with “an implementation that made the website much easier to keep up to date and to translate.” but as far as I can tell this is completely false, and translation infrastructure wasn't restored until half a year later.)
-
I don’t want to paint too dire a picture: A few bad experiences spread across five or more years is not a sign that everything is broken. Nonetheless, I have mostly given up on contributing to Rust’s web presence. Despite having many years of experience in the Rust community, I still feel I just don't understand how decisions are made, so it too often ended with me feeling frustrated and disrespected, and I didn’t see this improve over time.
If we want Rust’s community infrastructure to be a vibrant, living resource that gets continuous improvement from an engaged community, like our technical infrastructure does, then I think we need to change some basic attitudes about how it's developed, to be more like our software development process in some ways, and less in others: more rigorous when it comes to regressions and development process, but also more flexible about gathering feedback and changing things after release, including immediately after release. (The latter part is one thing I think the retrospective gets right.)
45 Likes
Oh, yeah, I had never seen the landing page before.
Yeah, the fuss makes a little more sense now.
@withoutboats: just want to say, first of all, thank you for everything you do for Rust as a technical project and for the community.
You're right that it is simultaneously true that 1) the Rust teams are in general the most knowledgeable people about Rust and had done the legwork on understanding the requirements here more deeply than anyone else and 2) that, on specifics, individuals in the community may have more knowledge or better ideas, and the point of the community process is to bring those ideas to the fore. This creates a dual dynamic: on the one hand, there is a community expectation that the Rust teams include the community in discussions; on the other hand, there is a team expectation that the community respect when a decision is made, and respect the contributions and hard work of the teams. I think in this case both sides came out feeling like they'd been burnt, which is a shame.
There are other issues here, including programmer disdain for "marketing" and making things more accessible (my two cents: if you're opposed to low-level programming being more accessible, you're in the wrong community), but I think in the end this was, as the post describes, a bad outcome arising from the best intentions.
If I had to summarize the dynamic as described by the post: the team unintentionally bit off more than they could chew, ended up scrambling to finish on time, and the crunch left community involvement to later in the process than usual, so by the time the project got there there was so little time and so much left to do, along with so few resources to handle feedback, that the community felt excluded AND the developers felt unfairly criticized and demeaned.
Even in this thread it's clear people still feel sore about how this process went. Personally, I'd contributed to the old site (including writing much of the now-shelved FAQ), and think this new one is an improvement on all the parts that matter. Of course people quibble over the design, but the harder work of information architecture and serving the needs of a very diverse set of users appears to have been met. I've been developing websites for 15 years and projects could go a heck of a lot worse than this.
So good job to the Rust team, thank you for this retrospective, and I'm sorry this has been such a hard topic with so many bad feelings around it. I really do believe everyone did their best.
12 Likes
I'm really not fond of the "experts just know better" sentiment. I'm no web design expert, true, but I don't think I need much experience to say a few things that I really don't think are controversial:
-
The site looks good on mobile, but desktop usability was clearly an afterthought - there's lots of padding, everything is large and spread out, and you need to scroll a lot. This makes for a looking-through-a-toilet-roll experience.
-
Overly-saturated colors on large elements are known to cause eye-strain, and I don't need to be an expert to tell someone that my eyes are in literal physical pain when looking at their design. This is the sort of thing that is even talked about in UX circles, so I doubt that the designers of the website were unaware of this when going for all those big colorful rectangles.
-
Text on non-uniform backgrounds looks just plain odd (talking about the headings). The first time I saw the page, I actually thought that my browser extensions were messing up the rendering or something.
I understand that making a design that scales well across different screens is no easy feat, but I doubt that simply going for less saturated colors would have involved any extra work. As for bullet #3, it looks like the designers went out of their way to obtain a less appealing (and imo confusing) result.
I'd probably accept that experts know better if they inspired more confidence, but in my case they really don't.
5 Likes
Let's look at the color saturation:
| Color | Hex | HSL | Saturation | Lightness |
|---|---|---|---|---|
| Purple | #2e2459 |
hsl(251, 42%, 25%) |
42% | 25% |
| Green | #0b7261 |
hsl(170, 82%, 25%) |
82% | 25% |
| Red | #a72145 |
hsl(344, 67%, 39%) |
67% | 39% |
The three colors span a range of saturations, with purple being the least saturated, red being in the middle, and green being the most saturated. The lightness values are all similar, and quite dark. At this level of darkness, the impacts of the relative saturation are lower (color receptors are located in the cone cells of the eye, which are less sensitive in dim light). Now, you may feel that these colors (perhaps particularly the green) are still too saturated, in which case maybe you'd like to open an issue.
It serves no one to claim 1) the developers didn't care, 2) that this is an obvious sign of ill intent or incompetence, 3) that other design elements look "just plain odd." A lot of design is subjective! Text on non-uniform backgrounds isn't unique to the Rust site. It may be a design choice you dislike, but it's not "odd."
You could make your point in a collaborative, constructive way that doesn't insult or impugn ill intent toward the Rust team. Cut them some slack. After reading the post it should be clear the intense constraints and challenges they faced. The website isn't set in stone anyway, and perhaps a constructive conversation could be had if things were approached in that way.
7 Likes
I can say as someone involved in the implementation (though not the design process) that we actually spent quite a bit of time on accessibility and usability across viewports, including verifying contrast ratios for everything used and testing exhaustively (though not perfectly by any means!) across different sizes. I spent an inordinate amount of time with the a11y tools in Firefox and the responsive design tools across browsers those couple weeks, making sure that the design worked in all views.
That doesn't mean it's to everyone's taste, for sure. Some people like the bright colors, and some people don't. Some people like the broad, expansive feel on large screens, and some don't. That's fine—genuinely! But consideration was definitely given to those questions, and everyone involved in the implementation cared deeply about those things, even under the time pressure we were under at the end.
I'll also note that anecdotally, I heard nothing but positive responses from the people I shared it with who were not already part of the Rust community (and I don't just mean friends who knew I'd worked on it 
). I think it's fair to describe the impact of the design (and not just the process) as somewhat polarizing, but many bold designs are that way, for good and for ill.
In any case there's zero need to attribute ill will or incompetence to the folks involved with the design or the implementation, and I'd especially ask that folks remember that your personal likes and dislikes are, the same as mine, not universal. There are definitely things I would have done differently about the design—my taste runs in other directions in some spots! But that doesn't make it bad, and I didn't mind implementing the design even when I differed from it precisely because where there were real and widely-agreed-upon usability issues—from color accessibility issues we identified early on, to typography problems that impacted legibility—the team eagerly ran with that feedback.
In short, the primary problems in my view were the process problems, and it's not helpful to try to litigate differences in taste. What's more, things like this can work well: Ember (which shares some common leadership with Rust) went through its own website redesign process a bit after Rust did, and learned a ton about it from what went badly process-wise with Rust. You can see the RFC and discussion here. (In the end, Ember's process had the opposite problem from Rust's: it took too long to get it all the way done!) It definitely also helped that Ember's community is much smaller, but making the process open from the start—with some initial input and guidance around design, but also actively involving community feedback even when it wasn't especially positive—meant that the design itself ended up being not only uncontroversial but actively celebrated overall.
In case anyone cares, and for the record: I was not one of the people who got burned out by their interactions around the website relaunch. I've been involved in enough efforts that I fully expected a lot of heat and backlash simply because of the scale of the change. While I did experience pretty bad burnout in 2018, that preceded the parts of the website work I was involved in. Nor was my wrapping up New Rustacean last year in any way impacted by it.
18 Likes
That would only be the case if the numeric values are linear WRT human perception, which IIRC they aren't (hence why Photoshop needs to do more than simple linear transformations when applying effects in order to make them look natural to the user). Feel free to correct me though, I admit that I'm speaking from memory here. (edit: mjbshaw is confirming my suspicions in the post below)
The white and green are the most painful imo, so the green is most definitely one of them. As for the white, I'd have preferred at least a somewhat darker-than-white grey.
Uhm... where did I claim that? Those are some strong words that I didn't even use. All I said is that I'm sure that the designers are aware of saturation issues, but I haven't really made any calls WRT the reasons why the result turned out underwhelming for me. I purposely attempted to leave their motivations as an open question. If that's what you took away from what I said, I'm sorry, but I did my best not to assume too much. I admit that I may have failed, but I most definitely did not write with the purpose of s**t-swinging in the direction of the designers.
My main purpose was to justify why I don't appreciate being told that "experts know better", and I'm not sure how I could have made that clearer. It was not intended to accuse the designers of incompetence or ill intent, but as a basis as to why I don't think that blindly trusting them is justifiable. Personally, I find that your reply towards me is more strongly worded than what I said, and I'm not sure that fanning the flames here is the best course of action. I apologize if my own post was already too inflamatory, and I'm open to suggestions on better wording, but I don't currently feel that what I said was taken in good faith.
It's just a personal opinion that I voiced, sorry about that.
I believe that I offered constructive suggestions for all of my criticisms to a reasonable degree, but for some reason didn't seem to account for much: 1) less padding would help 2) less saturated colors 3) uniform backgrounds for the headings. If extra decoration is desired, it can go around the text itself.
Anyway, to get back to the topic: I maintain that simply trusting authority is a non-starter.
6 Likes
HSL is a convenient color space but it's not perceptually uniform. HSLuv is better, and it gives:
| Color | Hex | HSLuv | Saturation | Lightness |
|---|---|---|---|---|
| Purple | #2e2459 |
(270.8, 52.4%, 18.2%) |
52.4% | 18.2% |
| Green | #0b7261 |
(168.8, 97.4%, 42.7%) |
97.4% | 42.7% |
| Red | #a72145 |
(3.0, 84.1%, 37.4%) |
84.1% | 37.4% |
The Rust website didn't invent it, but I think it's reasonably fair to say that the headline design is unusual. Most headlines I've seen in life aren't split in half by two wildly different colors with a hard border. I too have difficultly reading the headlines due to this design choice.
I made a PR to change the headlines. I guess we'll see how this goes...
4 Likes
Moderation note: Folks, could we please try to stay out of the weeds of specific design problems? That isn't really what the retrospective is about, and I think haggling over the particulars of the design is probably pretty off topic for this thread.
12 Likes
Looking at the situation from the outside, it seems a reason that people are still upset about the design is that there still hasn't been any space dedicated to litigating UI concerns.
It would be one thing if there had been a large discussion, at the end of which a team member had said "We've looked at the concerns that have been raised and decided to keep the current design for reasons X, Y and Z", but it seems that what happened instead was that people raising concerns were repeatedly told "This isn't the place to talk about the site's design" without ever being given such a place.
Having an approach of "we don't want to re-litigate this" is going to leave people frustrated, because they feel it wasn't litigated in the first place; instead the perceived message so far has essentially been "We know what we're doing because we're experts, accept our decision".
10 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.