15

With the recent removal of the envelope icon and the addition of the dropdown menu, there has been a lot of controversy about whether the change has been good or bad. I'm not here to complain, but to make a suggestion for future changes.

Other web applications often give users the ability to choose between the old and the new ui when significant changes are made. When Twitter rolled out their new UI, users were temporarily given the option to switch to the new UI, or keep the old UI. Facebook did the same thing when they redesigned user profiles recently.

My suggestion is to give users the option to choose between the "old" and the "new" ui when changes like this are made, allowing feedback to be gathered and features to mature before being released.

I'm not recommending making this a permanent feature, to allow users to choose, but rather to have a "soft" rollout with the intention of gathering widespread feedback before flipping the switch and forcing everyone to use the new changes.

Improve this question
7
  • Stating the obvious: but that means having both sets of code in the app at once, which is developer hassle. I can't see them going for this.
    – Rup
    Commented Mar 11, 2011 at 17:28
  • Yeah, thats an unfortunate side effect of this. I guess the question is: is it a necessary evil?
    – Kyle Trauberman
    Commented Mar 11, 2011 at 18:07
  • 2
    While something like this would work for the recent change that inspired this, I feel this suggestion focuses on the wrong problem, misses the bigger picture. The real problem is that those who run StackExchange make changes and then, (1) completely ignore the community's feedback, and (2) entirely refuse to explain why they made the change. In an ideal world, those in favour and those opposed would attempt to convince each other and, if not reach a compromise, at least understand the other's reasoning. Here, when the SE people (Atwood/whoever) remain mute and deaf, no progress is possible.
    – ShreevatsaR
    Commented Mar 11, 2011 at 21:50
  • @ShreevatsaR that's the point of this suggestion. If the community has a chance to see upcoming changes, they can provide feedback, and let the feature mature before it's released into the wild. I see a completely different problem with the envelope release. A feature was removed with the intention that it be re-added in the near future. Why not just wait until the whole thing was ready before rolling it out? Doing something like this would help the devs identify shortcomings like this and fix the immaturities before rolling it out to everyone.
    – Kyle Trauberman
    Commented Mar 11, 2011 at 21:53
  • @shreev both #1 and #2 are not true, but I find your beliefs fascinating.
    – Jeff Atwood
    Commented Mar 12, 2011 at 6:19
  • 1
    @Jeff: Perhaps you'd like to go to this question and either (1) listen to those who complained and give some feedback, or (2) explain from your end why you continued to think the change was an improvement. Or go here and explain why the entire community was wrong, and you, an outsider, were right. Both trivial instances no doubt, but your refusal to communicate is a bad sign.
    – ShreevatsaR
    Commented Mar 12, 2011 at 6:32
  • @shreev ample feedback was given in both cases; if you'd like to contact me on skype to discuss either one further, please do -- my username is codinghorror or "Jeff Atwood" from El Cerrito CA 94530.
    – Jeff Atwood
    Commented Mar 12, 2011 at 6:42

2 Answers 2

Reset to default
16

Or, slightly simpler, use MSO for testing. It wouldn't be terribly difficult to make a branch and only push highly experimental stuff to meta until it's ready to go out to the entire network.

Improve this answer
7
  • This is a nice idea. +1. Whoever is interested in staying up to date, can frequent Meta and/or look into the "change log" question.... questions regarding feature changes could get a tag of their own so they are easily searchable.
    – Pekka
    Commented Mar 11, 2011 at 20:31
  • I believe that this is in fact what was done for such features as the privileges page and the "interesting tab" tweaking. Also the front page when you got rid of the tag cloud. I think it's a great idea on the surface. My question is, would this work as a sort of UAT where feedback gets taken into account, or would it just be an early-warning system?
    – Aarobot
    Commented Mar 11, 2011 at 20:42
  • @Aarobot I don't work on the Core team so I can't speak for them, but I doubt the way they respond to feedback will substantially change
    – David Fullerton
    Commented Mar 11, 2011 at 20:46
  • 4
    This sounds like a good compromise. Easier on the devs, easier on the users.
    – Kyle Trauberman
    Commented Mar 11, 2011 at 20:58
  • 1
    this doesn't work well in practice because a) maintaining branches is a pain and b) we get blocked on a bunch of other necessary changes that need to get deployed every 6-12 hours. Also because we actually want the feedback from the feature being live.
    – Jeff Atwood
    Commented Mar 12, 2011 at 6:22
  • @Jeff it's only (a) or (b), since you either branch and are not blocked, or don't branch and are blocked. And branching really isn't that painful if you're doing it right.
    – David Fullerton
    Commented Mar 12, 2011 at 14:21
  • @david I'll be emailing you all our future 3 way merges because they are such a giant ball of fun! :)
    – Jeff Atwood
    Commented Mar 18, 2011 at 8:16
7

It's a fair suggestion, but is it really necessary?

I agree it's not great to get a feature change shoved in your face without consultation. I also don't like the change that sparked all this discussion, and I hope they roll it back or improve it significantly.

But has it seriously impaired anybody's ability to be active on the site? Seriously?

A "experimental/beta" opt-in system is likely to be a huge technical hassle; also, too much democracy in feature discussions can be seriously paralyzing. You would have to run every damn small change through the beta opt-in approval process, and every change would be guaranteed to lead to a huge discussion - it's inevitable, it's the way communities work. Everybody (including myself) would feel called upon to comment on every new feature. It would be hell.

I am actually fairly happy with the (albeit slightly dictatorial) way things are done currently - features get implemented; hugely unpopular changes cause a shitstorm. I, too, would prefer a heads-up before an UI change like this happens, but as long as the voice of the people gets heard most of the time (as I'm sure it will be in the case at hand) I have no problem with the current process.

Improve this answer
3
  • 3
    -1: I think you're missing the point. It's not a question of functional impairment (although actually, what I've seen here on meta indicates this particular change is annoying and impairing). It's about showing your users some respect. It's very simple. Huge changes like this should be explained in advance. What is the benefit of antagonising so many users? The same thing happened just recently with the rep recalc. It's stupid.
    – ire_and_curses
    Commented Mar 11, 2011 at 17:54
  • I'm not suggesting this for small, insignificant changes (e.g. algorithm changes, rep recalcs, etc.), but more so for significant changes impacting the UI like the envelope change.
    – Kyle Trauberman
    Commented Mar 11, 2011 at 18:05
  • @ktrauberman I see what you mean, but I'm not sure it's necessary even for that. Calmly going to Meta, registering one's disagreement, and seeing what happens would be the ideal course of action IMO. Nobody was seriously impaired in their ability to use the site by this. However, it has to be said that the immense tension in the other thread is surely also caused by past experiences when Jeff completely ignored the people's voice and stuck with an unpopular decision.
    – Pekka
    Commented Mar 11, 2011 at 18:10

You must log in to answer this question.

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