17

The question itself is provocative, but I am interested in understanding why the community's repeated requests for, often trivial to implement, changes to the sites design are routinely ignored or dismissed as .

Are we wasting our time asking for these changes?

The requests that have piled up over the last 12-24 months that seem to me completely legitimate requests that would enhance the usability of the site for the people that actually frequent it are:

I suppose my frustration is that the community reports design bugs, which are addressed with commendable alacrity, but on matters that are more about the interaction between usability and aesthetics we are ignored.

Given that many of the people here do contribute significant amounts of time to making this an impressive resource for U&L, is it unreasonable to expect that we have some say in how the site looks, particularly when it does impact upon our experience using the site as these proposed changes surely would?

4
  • 1
    I think this would get better visibility on Meta Stack Exchange.
    – tshepang
    Apr 15, 2013 at 19:12
  • I'm told a couple employees are working on answers, so don't repost on MSO Apr 15, 2013 at 19:24
  • just FYI, More Visible Tags has been addressed. They went from 240 to 230, but it still looks better.
    – MattDMo
    Apr 16, 2013 at 16:02
  • @MattDMo All of the requests I linked to in the question are now status-completed, thanks to the SE team.
    – jasonwryan
    Apr 16, 2013 at 18:08

1 Answer 1

17

Short version: design tweaks and fixes take a long time because the triage process for design requests is perhaps the most brutal in-house. We currently only have one designer, and he handles CSS fixes for all sites on the network as well as various and sundry responsibilities to the company at large. Help us help you by suggesting potential hires; the faster we hire, the sooner your bugfixes happen.


The long version is a little more complicated.

I'll rather directly answer your questions:

  • No, your requests aren't ignored by default.
  • No, you aren't wasting your time asking for these changes.
  • No, it's not unreasonable to expect to have some say in the overall look-and-feel of your site.

You aren't the first person to be frustrated by Stack Exchange's long response time to design tweaks and bugs. And, frankly, you're not going to be the last. You might have noticed that major flaws in your site's design are usually fixed quickly. However, when it comes to smaller design tweaks, such as the examples you posted above, those can take weeks, months, or even up to a year before they get resolved.

Why does changing 0 and o styling take so long? Why does it take a million years (or what feels like it) to update your <kbd> styling? Why does changing your tag styling seem to yield nothing but radio silence? There are good, intensive answers for each of those. And they tie into how Stack Exchange is structured right now.

Currently, our core development team (that is, the development team that works directly on the sites' engine) numbers 10 people: 9 developers and a project manager. That group of people is responsible for maintaining the existing infrastructure, updating features and documentation, as well as coding and committing new features and products. Some of those people also help out with our sysadmin team as sys-ops, helping out when we have to fail over because of a hurricane or when we move our database and servers. Ten people make sure that 100+ sites and millions of users have access to the information they need every single day. It's kind of insane when put like that.

Perhaps more relevant to this conversation directly: our design team is one person. If you haven't yet, meet Jin, our single in-house designer. Jin single-handedly handles all design work on the Stack Exchange network: from developing designs for graduated sites, to fixing bugs in the CSS of various layouts (especially when the newest browser launches), to assisting with mockups and spec and final artwork for super fun promos, to doing a huge amount of design work -- marketing, layouts, promo materials, feature mockups, the list goes on -- for Careers 2.0.

From a very literal standpoint: designer time is an extremely precious commodity in-house. Jin can really only work so many hours a day, so many days a week. Any demand on Jin means time is taken away from something else: a potential feature getting prettyfied, a Careers 2.0 pamphlet not receiving photographs, a site having its graduation delayed. This means that every design bug/request you all give us is pretty heavily triaged.

Listen: it's not that you aren't being heard. Design and dev aren't the only teams at this company. (I for one am rather fond of my team, the Community Team, who try to keep an eye on your sites and escalate issues accordingly.) We hear you, we understand your frustration, and we're asking you to be patient with us.

I'm sympathetic -- there's a number of design feature requests that I'd like to push for. There's sites that are still in need of a graduation design (Christianity, Board Games, Money) months after their graduation announcements, and there's sites that have a large backlog of design flaws they need to have address (Server Fault comes to mind immediately, along with many others), not to mention sites missing top user swag and moderator business cards (e.g. Skeptics, Electrical Engineering, Travel, and many more). All decisions regarding design allocation are made with great care and after a lot of deliberation. We don't push a lot of design requests at Jin because we literally can't do that; he's just one guy.

The issues you've pointed out above have been handled by a developer. I believe they should be fixed (and marked as as well) in the next build, but it might require another day just to be sure. For the <kbd> elements, that one's a bit more tricky; fixing that requires altering a file that more than one site depends upon. There's some hesitation to messing with it, because the overall impact is uncertain.

If you'd like to help us do better at fixing these issues, we're hiring for web developers and designers. If you know someone who would be a great fit for us, encourage them to apply! The sooner we can bring on more designers, the faster we'll be able to fix all the problems you report to us. That said: your issues are set aside but not forgotten. I assure you that every design bug meta post ends up on The ListTM and I'm confident they will be addressed. It's just going to take some time.

5
  • 1
    Thank you for the comprehensive answer; it goes a long way to assuaging my concerns about if/how our views are heard. Perhaps we could add another tag, todo that the staff could use to signal that the request has been noted, agreed and will be actioned when time/resource allow?
    – jasonwryan
    Apr 15, 2013 at 22:01
  • @jasonwryan: that tag already exists - status-planned. We try hard not to use it for anything that isn't at least being worked on right now - otherwise, it's essentially meaningless (or rather, it effectively means the same thing as status-deferred).
    – Shog9
    Apr 15, 2013 at 23:39
  • 3
    @Shog9 Then you have a gap in your comms... Of all of the questions I linked to, only one has an "official" (ie., red) tag, and that is status-declined. I would suggest status-deferred would be at least a step in the right direction. Either that or a comment that says "we hear ya".
    – jasonwryan
    Apr 15, 2013 at 23:59
  • @jasonwryan: Retagging or commenting on this stuff probably takes about as much time as actually doing it. As aarthi noted, the long-term solution is... Just having enough manpower to actually get trivial stuff done without it becoming a major backlog.
    – Shog9
    Apr 16, 2013 at 0:32
  • @Shog9, I would imagine that new requests can be tagged "status-deferred" instead of "status-declined," though—is that right?
    – Wildcard
    May 6, 2016 at 2:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .