Status page redesign in review

The status page redesign got committed to core the other week. This is a good thing because it shows that we can actually get decent design work done in core.

Or is it, because it has become the longest issue on d.o. and took way too long and seems too much work for redesigning a single page. It shows we still can’t get good design work done in an effective way.

But if you look closer you’ll find that:

A first iteration was committed at ±60 comments in. This was 5 years ago. Then another 60 or so comments of discussion about what could be improved about that initial redesign.

“Only” 9 months ago, Bojhan kicked off a whole new redesign. That actual design was agreed on in a decent amount of time and discussion (35 comments, 2 months and 2 or 3 discussions of it in our UX meetings). We spent a lot of time with a first and maybe even second round of implementation approaches before settling on a core worthy architecture. Refining that approach still took a lot of effort to get right but not extremely so.

In summary:

• 60 comments for the first iteration, this was a long time ago
• 60 comments discussing additional details of that first iteration
• 35 comments to agree on a whole new design (!)
• 170 comments to arrive at a core worthy approach for the frontend code
• 150 comments refining the code, reviewing it and fixing minor design issues

Some lessons maybe:

• Restarting a whole new redesign in an already years old and fixed issue is not how we normally work. It might have been better to start a new issue for the redesign.
• I think we’d now also choose to create and agree on the design in one issue and implement it in yet another. Although we really didn’t redesign by committee that much in this issue. 35 Comments to arrive at a whole new design is in fact a quite spectacularly short amount of time.
• Learn to recognise when a design introduced new frontend patterns. Because we need expert guidance on how to implement it correctly.
• Outline and agree on the architecture for implementation before starting to write code.
• Getting good design done + changing a stable core feature is still lot of work. It needs visual design, interaction design and information architecture. It needs HTML, CSS, JavaScript and PHP code. It needs to be checked on correctness for each of those. And don’t forget about accessibility (we didn’t). Without breaking backwards compatibility because we were changing a stable core feature. That’s a lot of disciplines that need to be involved, which means it takes more people to complete.

I’m happy the issue got committed. I had mixed feelings about whether this is really is an achievement worth celebrating given the length of the issue. Looking back at how the process went, it shows that we did in fact manage to redesign a core feature in a reasonable amount of time. And despite the length and complexity the discussion never went off rails and tone remained civil at all times.

For the design part it has been very valuable to discuss things in our UX meetings where we can share screen and provide feedback while looking at the actual thing. Imagine that! :-)

Thank you Christina, Sumit, Chris, Joel, Lauriii, Gabor and everybody else who chipped in. Well done.