老年人口苦是什么原因

We've had this conversation before and it hasn't gone particularly well.

At the time, sites received significant downgrades to their per-site customizations. Sites lost custom fonts and other special features in favor of a more unified approach - I'm still personally unhappy with how Science Fiction & Fantasy turned out and have used userscripts since then to change how it looks. It got bad enough that a CM at the time posted What does constructive criticism of a design change look like? in an attempt to get the conversation back on the right foot, with... limited success, from what I remember. I don't know if anybody involved in this initiative today was around at the time; in any case, just know that people are still sore about it.

This initiative is overlooking one small, but major piece of information: Each site is its own community. There is no real Stack Exchange community; each site is its own individual community with its unique identity, culture, norms, and expectations. Conflating everything into the "Stack Exchange community" is a mistake.
The unique site theming helps that community identity. I have a t-shirt and stickers with the SFF design elements; that helps my attachment and connection to that individual community. I also have a Puzzling.SE sticker, for instance. Each site has its own community and identity, and removing even more of the existing custom theming will harm that community identity.

As I mentioned, site custom theming has already taken a big hit from where it was a while ago, but it still allows you to easily tell what site you're on and gives you the impression that that specific site is a finished, complete entity - which is the goal. The suggested re-theming framework seems to move over to more of a Reddit-esque feel, where individual sites are just a piece of something larger without their own identity. The differences between Unix & Linux, Bitcoin, Puzzling, and Literature are huge, and those communities may not overlap at all; they're unique, individual communities rather than subsections of something larger.

Yes, there's the network. But that is in the end just the community framework; the reality of hosting such diverse communities and allowing them to flourish independently for so long is that they have done just that. They are more than just cogs in the larger machine - and they have their own unique needs.

Which brings me to the feature customization. Sites have unique features because they need them. Mi Yodeya has a Hebrew keyboard. Math.SE and some other sites have MathJax. Chess.SE has a board editor. Movies.SE has YouTube embedding. Each of those custom features grew out of an actual need displayed from the site. SU has no need for a Hebrew keyboard - but removing it from Mi Yodeya would be a step back. Enabling MathJax on sites that don't need it, such as Literature.SE, would needlessly increase loading times and enable abuse vectors. It's not that features are enabled willy-nilly for some sites but not all; each site has their own unique needs and there have been steps to meet those needs.

To sum up: Each site has its own unique identity, with its own unique needs, and treating them as a monolith is a mistake. Anything that further reduces site individuality should be considered extremely carefully, since that both harms community identity and brings up sore wounds from the past; and features enabled on a site-by-site basis are because those sites actually need them and shouldn't be easily dismissed.

I joined SO as a Community Manager in July 2018, just a few months before the huge design update that year. I spent a huge amount of time communicating the rollout plans and future improvements of these themes to communities across the network. I worked with the team to improve the rollout process to include opt-in preview modes and lots of feedback and collecting requests for changes as small as hover colors to larger design fixes. It was exhausting.

One of my biggest regrets is how many small asks I assured community members would be in scope for us to eventually adjust or improve their site designs. I sincerely believed that everything I'd told community members we planned to address would eventually be done but very few - if any - of those ever came to be. I spent many years dangling the promises of dark mode and site theming as carrots in an attempt to sway community members to accept the loss of community identity. You know how far that's gotten.

I'll tell you, David - I respect you and know you have the best of intentions - but in my experience, it's just all smoke and mirrors and very few of these things ever actually get prioritized by the company - and little has happened recently to leave me feeling that's changed, first and foremost, yet another attempt to overhaul theming.

I assured people that the 2018 round of customization streamlining would finally make it possible to design for the entire platform. It wasn't. Practically every network change that was shipped over the next few years ended up breaking on multiple sites because even the reduced customizations weren't adequately simplified. Maybe that's changed in recent years. I've been a bit out of the loop.

There's one element I have a difficult time believing will ever change, which will always make SO different - the top bar. SO doesn't have a banner because it has a customized top bar. The banner is literally the only thing that makes the sites customized in many cases and if all sites have to be the same, either SO has to get one and get "Stack Exchange" in the top bar and get rid of all of the product junk or the network has to lose theirs and start shilling paid products for SO. But the top bar is the one part of your design that's blank.

Beyond that, what about -

• ELU really wanting an easier-to-read non-white background?
• Photography (among others) having their _____ of the week?
• the custom disclaimers on sites like Judaism and Law?
• serif fonts on sites that specifically want them?
• the ability to support MathOverflow's design requirements?
• Stack Apps?
• Meta?

There's lots of others mentioned elsewhere on this page and many I've likely forgotten... and that's just what we can remember.

Please don't make SE look like Reddit

Reddit top bar/banner for reference:

The proposed design is literally identical to Reddit. By moving to a design that is the same as Reddit, you're priming people to assume that SE works the way Reddit works. This means that it's likely to lead to more and more users who are confused about why their post - which "would have been fine on Reddit" - gets closed on SE. You need to create a design that ensures people recognize SE is different. This design isn't that.

There are thousands of Reddit sites. There are less than 200 SE sites. While there should be some conformity, giving sites free reign over what minimal design they have would lead to the sites feeling less cohesive, even while forcing them into a more standard design. So many of the Reddit headers (if used) just look like something someone smashed together in Paint - that's not what SO should want for the network.

Logos and wordmarks (if used) generally aren't professional-looking and leave the sites feeling very homemade - which can make sense for reddit. I'd argue it's somewhat incongruous for a platform that purports in many cases to be for "professional[...]" people in a field.

Beyond that, I'd be hesitant to allow even mods to decide what looks "good" - I consider myself to have reasonably decent taste but that doesn't mean I haven't thought extremely tacky things looked "good enough" in the past. I'd really want to know what amount of support/review would be given by SO (if any) before updates to a site theming were approved.

Start with the unthemed

If you want to truly sell people on this, can I recommend that you don't start by trying to convince sites that have had custom designs for years to give up even more of their personality for an untested design and unproven but promised future and instead release a theming update targeted at un-themed sites and users who want to customize their personal experience through skins.

By building something for the large number of unthemed sites, you are still benefitting many communities but you also allow the communities on themed sites to see the work you're doing in action and get to know the flexibility involved in the update before they're forced to adopt it themselves - some may even opt in voluntarily if they feel it allows valuable upgrades.

There are likely also users who would prefer a more consistent, clean view and would want the option to override the sites' theming with their own options, whether that means a simplified dark mode (unthemed otherwise) or a more dyslexic-friendly design, or whatever. Many platforms allow this option, including Dev.to, I believe, so it's certainly possible for some platforms.

The thing is, you can give everyone who wants it dark mode (or other custom skins) right now by making them choose between the custom "skin" of the site and the dark mode "skin" - you don't have to make it possible to have both at the same time. Sure, it'd be nice but it's not required.

Yes, at least temporarily, this would make the code a lot more complex to build for but it would also likely assuage the concerns many users have if you actually show us that you're actually going to give us those carrots the company has been talking about for 7 years and it allows y'all to actually test if the sites' needs are met before shoehorning them into the new layout.

Much of the question's text is meaningless to me. Obviously, you wouldn't have written something deliberately meaningless. I diagnose a schema mismatch!

Reading the question with that in mind, it looks like you're trying to construct a grand unifying model of what the Stack Exchange Network actually is. You've done a good job at that – I've had to get all meta to even notice the discrepancy – but we already have this grand unifying model. It's described piecemeal in some of the early blog posts (1, 2, 3); and of course it's developed since then, but that's a start.

You shouldn't be trying to construct this model: you should be trying to reconstruct it – including the reasons for the decisions. (Then you can think about changing it.) None of the employees I know to have written about this still work there, but you've still got some employees I'd expect to remember, and plenty of community members too. (Look for people who remember "the trilogy".)

Alas, I'm not among them, so I'll focus on technical concerns for the rest of this answer.

each of those things becomes a very complex workflow to follow for a product manager, developer or designer working here – it’s like entering a parallel universe through layers of if/else statements

This reminds me of The Codeless Code: Case 231 Laziness.

“Laziness,” the head monk declared; “for she says that our interface makes her do too much work, yet the work is her fault, not ours.”

This is a common problem: what appears to be stunning, unfathomable complexity, and is usually implemented as such, is actually much simpler than it first appears, if the proper abstraction is chosen. Fundamentally, what is a Stack Exchange site?

• A database of posts:
  • Questions
  • Answers
  • Tag wikis / excerpts
  • Help centre articles
• A curation system of votes:
  • Up
  • Down
  • Charm Close
  • Delete
  • Accept
  • Flag
• Comments
  • Comment flags
• User profiles
  • Reputation
  • Mod messages
  • Suspensions
• Views:
  • for reading
  • for contributing reading material
  • for curating
    • for commenting

We can already see a couple of snags in this breakdown:

• Comments were originally intended as curation tools, but they're often used as contributions! (Fortunately, this isn't relevant to the issues at discussion right now; but it is an issue we need to resolve eventually.)
• The tour doesn't cleanly fit into this model.

Existing site customisations can be broken down in the same way. Sites have customised:

• Posts:
  • Site content
  • Help centre articles
• User profiles:
  • System users (not everyone has a user -2)
• Curation features
  • Custom close reasons
• User profiles
  • Authentication routes (e.g. Launchpad on Ask Ubuntu)
  • Privilege thresholds (as seen on /help/privileges)
• Views:
  • general:
    • Site design
    • Site language
  • reader:
    • MathOverflow's hidden reputation scores
    • MathJax support in Q&A
    • YouTube embeds
  • editor:
    • Mi Yodeya's Hebrew keyboard
    • MathJax support in the editor
    • YouTube support in the editor
  • curation:
    • Stack Overflow's extra review queues

This schema is hierarchical, and real features aren't required to fit cleanly into it, so there are a few things that don't (e.g. Staging Ground involves a new post type and corresponding views), but I'm pretty sure everything fits in here.

If all these features were cleanly laid out like this in the codebase, it'd be fairly easy to configure them on a per-site basis. However, they're not. I don't know much about the internal architecture (just a few hints about configuration flags), so I'll illustrate with what I can see: the front-end.

The front-end is composed of views. These can be broken down into:

• What gets shown (e.g. translations, post bodies, .-flair).
• What it looks like (e.g. site designs).
• How it functions (e.g. voting buttons, the inbox).

Traditionally, these correspond to HTML, CSS, and JavaScript respectively. At the moment, though, it's all mixed up into one big soup:

• Hiding reputation from the "user details" section on MathOverflow is handled by JavaScript. (I'm aware of the political component here, but that shouldn't be relevant.)
• Site designs are implemented by modifying the HTML.
• Several popups are positioned server-side.
• Custom elements are implemented using DOM Observers looking for custom attributes (or some equivalent mechanism), rather than with the native mechanism.

Of course you've got feature-flag hell! You've got a decades-old software stack, which you aren't able to refactor, and are instead just piling more kludges onto. That might be due to lack of expertise, but I bet it's mostly due to lack of time, and possibly some perverse incentives.

You took away the beautiful custom site designs we had, replacing them with inferior alternatives, because the old way was hard to maintain. Sure, okay, that's justifiable – but you replaced it with the Stacks design system, which doesn't fix the problems. A good solution would mean:

• the HTML contained the information that should be presented,
  • in a way that's accessible even with CSS fully disabled,
  • with hierarchical "components" for hierarchical data;
• the CSS presented it,
  • taking advantage of the hierarchical structure for reliable, clean styling; and
• the JavaScript provided dynamism,
  • via calls to a RESTful API employing HATEOAS (either text/plain or HTML responses – with occasional JSON (I'm not a purist) but only where appropriate),
  • using data embedded in the HTML, rather than passed using generated JavaScript, where appropriate.

This scheme has many advantages:

• We can get our old site designs back! Sure, no more table layouts, but modern CSS allows you to implement pixel-perfect "photoshop designs" just as easily.
• Changes are far more local.
  • You can fork site designs without changing the generated HTML, making later reconciliation easier. (Should simplify experiments, among other things.)
  • Designers can work on site designs on their own machines, without a dedicated test environment.
    • Different designers can work on different parts of the site, without any real risk of merge conflicts!
  • JavaScript doesn't have to deal with setting font sizes and colours.
• The footprint of each page will go down, making page loads much faster, and reducing the amount of hardware you have to procure your cloud hosting bills.
• HTML can be modified confidently, without risk of breaking the design.
  • This does require robust CSS, but having a variety of test pages (with more extreme variation than the real site – e.g. a version with a hundred entries in the left sidebar, and a version with zero entries, and a version with an absurd-but-valid colour scheme) will quickly catch any CSS that's misspecified.
• It's be easier to write userscripts.
• It's be easier to write userstyles – this is important for accessibility, and not something SE currently provides.

As for disadvantages:

• Such a drastic change will break (nearly) all existing userscripts. (But that's no reason to avoid the change! It's merely a reason to get it right, to avoid having to change things again and again.)
• Implementation details of Stacks would have to change.
• Designers would have to learn CSS (for which many many educational resources are available), rather than your NIH class-based system (for which very few educational resources are available).
  • In practice, that amounts to "different syntax" and "different names for things": there are only a few instances where Stacks components would have to be broken up or reorganised.
• CSS allows you to produce unmaintainable rubbish: you'd need a code review pass, to make sure people were using the Stacks-approved CSS functionality rather than dragging in other stuff.
  • You need this at the moment anyway: there are several different ways in Stacks to describe "black", each with different behaviours outside the default light mode. I've seen such errors on the site: Stacks doesn't actually solve this problem.

A great example of this would be dark mode, which if we’re rid of thousands of lines of non-design system CSS customisations, we can turn on more easily.

And if you were using CSS properly, you'd only need to switch out a few CSS variables. Stacks has hardcoded colours, devoid of semantic meaning, meaning it's actually harder (in some ways) to add dark mode in Stacks. See The Codeless Code: Case 95 Roses are Red.

Remember: some users have accessibility needs that you will never anticipate, and you need to allow those users to customise their own experience of Stack Exchange. The Stacks design system is an accessibility barrier. (From an abstraction perspective, it slices perpendicularly to the correct direction. We don't need another layer: we need the navbar styling to be separate from the sidebar styling.)

(Stacks is the right approach, conceptually, but it's built with the wrong tools. Not as bad as "let's render the text with JavaScript", but it's in the same genre. There's a reason we don't use <center> any more, and it's not because class=".op-center" is mystically better.)

The Codeless Code: Case 2 Unknown Unknowns might also be relevant.

Please don't forget international-sites. To mention one thing to have in mind, some labels may require more space than the original English term.

There are four international sites that use a subdomain from stackoverflow.com

• es
• ja
• pt
• ru

The primary goal of the stacks framework was to try to make it easier to give sites custom themes. One of the critiques of the last big redesign was it stripped out much of the character old sites had. Couple of thoughts here

Ownership: Various sites feel more or less ‘theirs’ or ‘ours’. Part of the Network or their own world. Brand plays a huge part of this.

I'd say a sense of healthy ownership is important. I think of Super User as 'my' site, and have a fondness for Server Fault and some other sites. For individual sites to be healthy, that sense of ownership and agency amongst its core communities is important. It goes beyond the brand to me, and with the broader interactions between the various stakeholders.

I'd even say it's one of the reasons I'm still here and posting meta posts - that I belong to these spaces and that their needs are inadequately met a lot of the time.

Themes: Some sites (including their chat instances) have custom themes, while many have a default SE theme - there was once a rule about graduating out of Beta which got the site upgraded to a full theme, but I don’t believe we’ve followed that in recent years due to resource limitations.

Site graduations tended to be a big thing, the theme and associated swag was a reflection of how far we came. Resource limitations are a reflection of a broader companywide malaise and lack of focus. I'd say rather than not giving sites themes and taking them away, having someone work through and update existing sites to have unique themes is the correct way to go if you want to energise the network.

The general energy I get is there's sometimes interest in working on these if there's nothing else going on but getting smaller sites up to scratch is a very low priority.

That individuality, and the care shown in design means a lot to the folks active on sites.

This is a fair question because the main focus has quite clearly been Stack Overflow.

This to me has been a bit of a bug, simply because you're building for a site, not a platform, and really the Stack Overflow focus has heavily been so it can be leveraged for other products.

The divergence from the 'regular' design and trying to tack on a lot of additional things is a poor choice to me, even if SO has a few unique things that keep getting added or removed.

I've literally been complaining about this for the better part of the decade, and it'd be nice to realise that rest of the network needs a little more attention.

Unified customization

Is what stacks was supposed to be - a flexible, simple platform that would speed up site customisation. One of the previous April Fools' Day jokes allowed for variable site designs per site, and it was actually quite good. The design time needed might now allow for it but I can't believe making every site look similar is the 'only' option.

In a sense, I'd wonder what Stacks lacks right now, after a fair amount of development time.

I know at first this may seem like a step back, but please let it sit and think about how if we can align on a way to unify how we present customisations this unlocks a path where we can add features more easily across the network, not just a ‘Stack Overflow-first’ mentality. A great example of this would be dark mode, which if we’re rid of thousands of lines of non-design system CSS customisations, we can turn on more easily.

Dark mode was designed to be an example of how stacks could be used to add flexibility to network design as I understand. I'd say if you asked many communities and users, they'd want a dark mode option over removing it. Rather than stripping out dark mode, I'd say either a default unified dark mode across the network, and/or including a dark mode option for newly designed sites would be a better option and adds a feature people want.

As an addendum, years ago we fought to save the Worldbuilding's mascots from banishment to the sidebar. So if we're doing this, and I'm not a UX designer... could we include the option to keep a custom background like Anime or Worldbuilding does? I'm a little hopeful when we get around to Pets we'd get something appropriate on the background.

Some questions-

• Who would govern these avatars and header graphics? The respective communities? If a community wants to set it to something the company doesn't like, what happens?

• Any particular reason why challenges with domain names is mentioned? Are domains going to be removed? What about the link rot? Do cookies not work if a site was redirected to?

• What about primary and secondary colours for a site?

• What are the exceptions? I'm going to assume you're not going to simply let Stack Overflow's community change the avatar of Stack Overflow (at least- not without some sort of company review/approval process).

• What does "unified features" mean? I assume from the framing that it involves tradeoffs. What things do you have in mind?

• What will this mean for community-specific JS? Are you going to make it easier for sites to customize that through meta discussion and mod controls?

From the question

Features: Some exchanges get a slightly different feature set, for example MathJax, Stack Snippets – anything else? Stack Overflow receives the most new features and experiments.

Questions about custom features in Stack Exchange Sites that help to answer "... anything else?"

• What site-specific post formatting settings are available?

Other questions

• Embedded audio player on language sites
• Integrated virtual keyboards for posts and chat
• Which Stack Exchange sites use MathJax?
• Which sites have YouTube embedding on?
• Which Stack Exchange sites have syntax highlighting enabled?
• Which sites use citation helper?

Initial thoughts

The unique themings of the different sites seem to contribute substantially to their success. People seem to really like it. The question is: How can the upcoming changes support that?

Reactions

We want to explore leveraging existing community decision making processes (mods, meta etc) to empower individual Stack Exchange sites to determine their own look and feel, rather than a top-down approach.

Reads to me like design support from the company is lost and communities are on their own if they want to have nice design.

The additional benefit is all sites are treated equally, so smaller sites can create a theme if they wish, whereas previously they used the functional but characterless default.

Sounds to me like all communities (even the big ones) have to design their own site.

... this unlocks a path where we can add features more easily across the network, not just a ‘Stack Overflow-first’ mentality.

I always wondered why you did Stack Overflow first and only Stack Overflow. I could not understand it. Of course underlying platform technology should be as unified as possible. I had hoped that you had done this already. Hopefully it can be achieved now.

Closing thoughts

To efficiently support all the communities you would need a unified "software" basis. I'm very much surprised this doesn't seem to be the case already. It should be done as much as possible.

Additionally, special emphasis should be paid to keep the number of features that can be customized as high as before (vote buttons, fonts, etc.). Otherwise it would be a step back feature wise.

And help with the design would also be greatly appreciated. I mean, one can outsource it, but then one gets what one pays for.. (and cannot complain about it).

You're asking a group that's mostly programmers so I'll give the programmer answer: don't try to build what you think we need, just give me the tools so that I can build what I need for myself.

I'm imagining something like a community-specific plugin that could be maintained and developed by each community's mods that let them adjust page styles, Javascript, etc. Many users already do this on the the browser side via userscripts and custom CSS. Why not make it easy to leverage that existing code to become a site-wide customization?

I'm not proposing that any mod can inject code into the site at will. I fully expect that the company would do a full code review and safety test to ensure nothing malicious sneaks in.

The company would have to document, maintain, and provide support for the interfaces involved plus review and approve the site plugins. That seems like far less work than trying to wrangle so many sites with diverse needs. The number of communities could scale without adding much additional burden on the company. Different communities would try different things, effectively serving as a hundred separate design experiments running in parallel. Particularly good ideas can be incorporated into the core functionality. From the Teams standpoint, customers would enjoy being able to add functionality specific to their company (such as automatically identifying a reference to a part number and formatting it into a link to their inventory management system).

I acknowledge that we have many non-technical communities that most likely don't have many people with software development skills. Thankfully, we have a community full of programmers that enjoy helping. An open-source sample plugin that shows how to adjust a few basic elements (color scheme, header graphic, etc.) would probably cover the needs of 90% of communities.

• I love customization - but only up to a point. A point made by Catija, as well: the result should be professional. This means a harmonious use of the variables (font, logo, background, colour scheme, &c.). Within a preset framework, a certain amount of unity between the sites will always persist and so retain a level of professionalism, but customization might require some level of professional supervision, and probably cannot be entirely democratic in that sense.

• That being said, I think the more pressing matter, considering your words and parts of other answers, is that a first step would be to simplify the framework:

  Reflecting back on the list at the start, each of those things becomes a very complex workflow to follow for a product manager, developer or designer working here – it’s like entering a parallel universe through layers of if/else statements (to use a programming analogy).

  A great example of this would be dark mode, which if we can get rid of thousands of lines of non-design system CSS customisations, we can turn on more easily.

  I feel like your proposal/thought experiment/discussion topic is way too premature, seen in this light: if that initial step, apparently a prerequisite for this customization, is executed first, a lot more will be gained. Afterwards, customization can be put on the table again. This will also make that possibility feel more tangible.
  In other words: please stop/reverse/halt the enshittification first.

...our thinking around how we might unify the user experience across all sites, in service of a thriving network...

Please, don't.

The future: unified features

One thing that is desperately needed is to let users that are moderators or trusted users at one site to get some moderation privileges on all sites. To get access to basic things like close votes and a sufficient amount of flags.

Some of the smaller sites have little to no moderation and flags often "age away". Additionally it would help to combat spam.

The relationship between reputation and moderator privileges is nonsense in general.