Also, please actually pay attention to these requests, and don’t add stuff that you don’t know the community wants without talking about it first. In my experience, site redesigns can easily lead to large amounts of drama over very minor issues. If we’re trying to be rationalist we should keep that in mind and proceed cautiously.
I suspect much of the reaction is the feeling that many user suggestions and requests were ignored, while other actions were taken that users didn’t necessarily ask for or desire.
I’ve gone through that thread to summarize all of the most popular suggestions. For now, I’m defining “most popular” as having > 10 karma so this list does not become even longer. (If anyone feels I’ve unfairly or incorrectly summarized a suggestion, please let me know.) Here they are in order, with their status as best as I can tell (Y for implemented, N for not implemented, ? for unsure).
Edit: The list takes up a lot of space when posted, so I’m hosting it here.
The totals are: 8 Y, 33 N, 7 ?. That’s not a particularly stellar record. Now, personally I’m glad that some of these didn’t get implemented (karma bounties and markets, for instance), but there are entire categories of repeated and similar requests that seem to have been ignored. Better searching and sorting for user comment histories appears at least 5 times. Making the commenting process better (previewing, better help function) appears at least 5 times. It doesn’t look like these concerns were addressed at all; in fact, at first changes to the interface made double posting a frequent problem just as the option to delete posts was removed.
I’ll second Unnamed’s comment: there should have been advance warning of the redesign being rolled out, with a description of what would happen. As it is, the goals and scope of the redesign are unclear; the feeling I get is that this is something being done to us rather than with us or for us. My above analysis shows that users’ feeling of being ignored is fairly justified.
Edit: In the interest of not being entirely negative, in general I think that the design looks nice (although I preferred the “map and territory” header), and I’m glad to see the meetup issue is being addressed thoroughly. Also, I appreciate that you’ve already addressed some problems that I and others pointed out.
I suspect much of the reaction is the feeling that many user suggestions and requests were ignored
Again, let me start by admitting fault in not communicating this more clearly: I assumed it was the most reasonable assumption that we would release features as they were ready, rather than releasing nothing, then everything. Once the redesign was ready we pushed it and all of the other features we’d finished to that point. There are other suggestions we’ve heard and plan to implement or are part way through implementing. … and, there are suggestions we don’t plan to implement.
The totals are: 8 Y, 33 N, 7 ?. That’s not a particularly stellar record.
See my notes on your notes at the end of our notes doc. Several requests contradicted each other (“avoid clutter” vs “add feature/button/info X”). For others… “make suggestions that will guide their redesign efforts” doesn’t sound to me like a promise that we’ll process the suggestion list in order. We considered all suggestions, and I tried to update my own opinion by comment upvotes. “Not a stellar record” seems a pretty harsh take compared to something like “considered all suggestions, and implemented their favourites”.
I hear you, and I think you may be accurately explaining why many felt annoyed/ignored… but “I made a suggestion and the suggestion wasn’t executed” doesn’t add up to good evidence that you were ignored. We should have made clearer in Louie’s post that we would use our own discretion in what we implemented, and that our budget was limited.
Again, let me start by admitting fault in not communicating this more clearly: I assumed it was the most reasonable assumption that we would release features as they were ready, rather than releasing nothing, then everything. Once the redesign was ready we pushed it and all of the other features we’d finished to that point. There are other suggestions we’ve heard and plan to implement or are part way through implementing.
… and, there are suggestions we don’t plan to implement.
That modus operandi seems to be a trend in recent social web development (e.g. Facebook), but I don’t think it’s one that endears the developers to users. Prior communication is almost always a better option than just doing things whenever, especially in cases like this one where user advice and suggestions were explicitly requested.
Also, I suspect the release of new features at the same time as new visuals contributed to users’ inference that what’s been done so far constituted “everything.” If a new feature pops up by itself, it’s just a new feature. The inclusion of the graphic redesign made it seem like this was the entire redesign, period.
See my notes on your notes at the end of our notes doc. Several requests contradicted each other (“avoid clutter” vs “add feature/button/info X”).
Thanks for the response. Before making a few specific replies, let me further explain why I went through the posted suggestions in that manner. Really, it was to make sure that I wasn’t just upset because my own suggestions didn’t appear to get much attention; I wanted to remove my own bias by looking at the contribution of the user base at large. As it turned out, my suggestions were repeated several times, and related suggestions were also repeated several times, as we both noted. On to specific notes:
I think you’re interpreting #11 a touch broadly. When I see “clutter” in the context of web design, I think of something that takes up more space than its function is worth, i.e. a net negative contribution. It’s not adding anything, it’s just adding things that are not overall helpful/desired. Of course, that’s my interpretation, and others may not share it.
I did not realize that the help page had been wikified, and that the welcome page will soon be as well. Thank you for pointing this out; it’s a very good change.
I agree that #3, #14, #18, and #22 are complicated and expensive to implement.
I do not agree that #27, handling footnotes, is expensive. Collapsible sections take about 5 minutes to construct with CSS and Javascript, so the only difficult part would be adding a custom button to the article editor so they could be used. I have seen such buttons added in a variety of different editors (from vbulletin to wiki software), so I don’t think that it’s infeasible.
I’m not sure that separating upvotes and downvotes constitutes the desired polling solution; the discussion in that comment thread indicated a desire to separate polling and karma entirely.
I also do not agree that “don’t add things without discussing” amounts to “design by committee”; ideas can be discussed without being subjected to a majority vote.
You did not remark on comment previews. Right now, the system of “just post it and then edit it” works fine for the user making the comment; the problem is that other users may start replying to those comments while they are still being edited, and manually adding a “don’t reply to this yet” note is tedious for the user. (I have been on both ends of this problem.) I understand that adding an entirely separate preview interface would take a fair amount of work, but I think there is a simpler solution. Place a check box above the “Comment” submit button that, when selected by the user, flags the comment as a “draft.” The comment still appears in the thread, but only to the commenting user, without a date, and with an extra button to submit it fully. I am not familiar enough with the backend of the site to know exactly how much work this would entail, but we definitely already track user-based properties of individual comments.
After your responses to the suggestion list, my revised count is: 13 Y, 29 N (7 planned), 2 ?. (This is after removing the 4 repeats you identified explicitly.) That obviously looks much better than it did before.
I hear you, and I think you may be accurately explaining why many felt annoyed/ignored… but “I made a suggestion and the suggestion wasn’t executed” doesn’t add up to good evidence that you were ignored.
I think the principle illustrated here is without providing explicit information and description, action:[considering suggestions carefully and sorting them into “implement immediately,” “implement in the future,” “too costly to implement”] looks a lot like action:[cherry-picking a few suggestions and just ignoring the rest]. It’s very hard to tell how much effort was put into analyzing the suggestions if that effort isn’t somehow conveyed to us.
Also, I suspect the release of new features at the same time as new visuals contributed to users’ inference that what’s been done so far constituted “everything.”
Agreed. As you and others have pointed out, a post like this one would have helped a lot. I have learned.
Before making a few specific replies, let me further explain why I went through the posted suggestions in that manner.
For what it’s worth, I did what you did, and we worked from a Freemind map very similar to your list, organised/weighted by upvotes, our estimate of effort required, and our personal desire to implement the features we worked on. I should have made that more public.
I did not realize that the help page had been wikified…
I’ve been intentionally circumspect about the wikification, to try to leave the three wikified pages open as long as we can. I expect that soon enough the spammers will find them, and we’ll have to lock them down as protected pages. For those paying close attention, see this.
I do not agree that #27, handling footnotes, is expensive.
I’m not sure that separating upvotes and downvotes constitutes the desired polling solution; the discussion in that comment thread indicated a desire to separate polling and karma entirely.
It is my intention that agree/disagree has no karma attached. I think it very plausible that agree/disagree won’t work as I hope it will for polling… but the test is as cheap as ordering which we implement first. Since we plan to implement agree/disagree anyway, we get the experiment for free.
You did not remark on comment previews.
I agree that preview would be nice. What we have now works pretty well, so I’m judging this feature as low benefit/cost. Your suggested solution would be easy to implement, but I think would be confusing to users.
Didn’t notice this has gone live. Luke edited in the wiki source of about page what I think is just terribly wrong, and now it’s the site’s about page, but it’s 5:40 AM and I can’t figure out a way of undoing the problem without removing the content. From the page:
Community norms Twelve Virtues of Rationality summarizes the core norms of Less Wrong: … There are also community norms about how to use words. For example: don’t sneak in connotations or endlessly debate definitions.
These are not norms, these are skills, and there is no hope or point in enforcing them, particularly absent understanding the purpose.
It’s like saying that believing that ZFC is consistent is a community norm in a math seminar. Doesn’t sound at all right.
I was not a lone actor. The new About page I wrote was approved by SI.
(Which to some extent does indeed mean you’re not a lone actor, but it’s worth noting that SI approval isn’t much of an argument in favor of the About page’s quality. (Just wanted to make sure people didn’t assume you were making an argument from authority.))
I assume “I can’t figure out a way of undoing the problem” speaks to finding the right words for the about page. The technical way to solve the problem is to edit the wiki page (with the right words, whatever those may be), then wait a few hours or be logged in to LW and click the “Force reload from wiki” button at the bottom of the about page.
— comment by JoshuaZ in the suggestion thread
I suspect much of the reaction is the feeling that many user suggestions and requests were ignored, while other actions were taken that users didn’t necessarily ask for or desire.
I’ve gone through that thread to summarize all of the most popular suggestions. For now, I’m defining “most popular” as having > 10 karma so this list does not become even longer. (If anyone feels I’ve unfairly or incorrectly summarized a suggestion, please let me know.) Here they are in order, with their status as best as I can tell (Y for implemented, N for not implemented, ? for unsure).
Edit: The list takes up a lot of space when posted, so I’m hosting it here.
The totals are: 8 Y, 33 N, 7 ?. That’s not a particularly stellar record. Now, personally I’m glad that some of these didn’t get implemented (karma bounties and markets, for instance), but there are entire categories of repeated and similar requests that seem to have been ignored. Better searching and sorting for user comment histories appears at least 5 times. Making the commenting process better (previewing, better help function) appears at least 5 times. It doesn’t look like these concerns were addressed at all; in fact, at first changes to the interface made double posting a frequent problem just as the option to delete posts was removed.
I’ll second Unnamed’s comment: there should have been advance warning of the redesign being rolled out, with a description of what would happen. As it is, the goals and scope of the redesign are unclear; the feeling I get is that this is something being done to us rather than with us or for us. My above analysis shows that users’ feeling of being ignored is fairly justified.
Edit: In the interest of not being entirely negative, in general I think that the design looks nice (although I preferred the “map and territory” header), and I’m glad to see the meetup issue is being addressed thoroughly. Also, I appreciate that you’ve already addressed some problems that I and others pointed out.
Again, let me start by admitting fault in not communicating this more clearly: I assumed it was the most reasonable assumption that we would release features as they were ready, rather than releasing nothing, then everything. Once the redesign was ready we pushed it and all of the other features we’d finished to that point. There are other suggestions we’ve heard and plan to implement or are part way through implementing.
… and, there are suggestions we don’t plan to implement.
See my notes on your notes at the end of our notes doc. Several requests contradicted each other (“avoid clutter” vs “add feature/button/info X”). For others… “make suggestions that will guide their redesign efforts” doesn’t sound to me like a promise that we’ll process the suggestion list in order. We considered all suggestions, and I tried to update my own opinion by comment upvotes. “Not a stellar record” seems a pretty harsh take compared to something like “considered all suggestions, and implemented their favourites”.
I hear you, and I think you may be accurately explaining why many felt annoyed/ignored… but “I made a suggestion and the suggestion wasn’t executed” doesn’t add up to good evidence that you were ignored. We should have made clearer in Louie’s post that we would use our own discretion in what we implemented, and that our budget was limited.
Thank you for the detailed response.
That modus operandi seems to be a trend in recent social web development (e.g. Facebook), but I don’t think it’s one that endears the developers to users. Prior communication is almost always a better option than just doing things whenever, especially in cases like this one where user advice and suggestions were explicitly requested.
Also, I suspect the release of new features at the same time as new visuals contributed to users’ inference that what’s been done so far constituted “everything.” If a new feature pops up by itself, it’s just a new feature. The inclusion of the graphic redesign made it seem like this was the entire redesign, period.
Thanks for the response. Before making a few specific replies, let me further explain why I went through the posted suggestions in that manner. Really, it was to make sure that I wasn’t just upset because my own suggestions didn’t appear to get much attention; I wanted to remove my own bias by looking at the contribution of the user base at large. As it turned out, my suggestions were repeated several times, and related suggestions were also repeated several times, as we both noted. On to specific notes:
I think you’re interpreting #11 a touch broadly. When I see “clutter” in the context of web design, I think of something that takes up more space than its function is worth, i.e. a net negative contribution. It’s not adding anything, it’s just adding things that are not overall helpful/desired. Of course, that’s my interpretation, and others may not share it.
I did not realize that the help page had been wikified, and that the welcome page will soon be as well. Thank you for pointing this out; it’s a very good change.
I agree that #3, #14, #18, and #22 are complicated and expensive to implement.
I do not agree that #27, handling footnotes, is expensive. Collapsible sections take about 5 minutes to construct with CSS and Javascript, so the only difficult part would be adding a custom button to the article editor so they could be used. I have seen such buttons added in a variety of different editors (from vbulletin to wiki software), so I don’t think that it’s infeasible.
I’m not sure that separating upvotes and downvotes constitutes the desired polling solution; the discussion in that comment thread indicated a desire to separate polling and karma entirely.
I also do not agree that “don’t add things without discussing” amounts to “design by committee”; ideas can be discussed without being subjected to a majority vote.
You did not remark on comment previews. Right now, the system of “just post it and then edit it” works fine for the user making the comment; the problem is that other users may start replying to those comments while they are still being edited, and manually adding a “don’t reply to this yet” note is tedious for the user. (I have been on both ends of this problem.) I understand that adding an entirely separate preview interface would take a fair amount of work, but I think there is a simpler solution. Place a check box above the “Comment” submit button that, when selected by the user, flags the comment as a “draft.” The comment still appears in the thread, but only to the commenting user, without a date, and with an extra button to submit it fully. I am not familiar enough with the backend of the site to know exactly how much work this would entail, but we definitely already track user-based properties of individual comments.
After your responses to the suggestion list, my revised count is: 13 Y, 29 N (7 planned), 2 ?. (This is after removing the 4 repeats you identified explicitly.) That obviously looks much better than it did before.
I think the principle illustrated here is without providing explicit information and description, action:[considering suggestions carefully and sorting them into “implement immediately,” “implement in the future,” “too costly to implement”] looks a lot like action:[cherry-picking a few suggestions and just ignoring the rest]. It’s very hard to tell how much effort was put into analyzing the suggestions if that effort isn’t somehow conveyed to us.
Agreed. As you and others have pointed out, a post like this one would have helped a lot. I have learned.
For what it’s worth, I did what you did, and we worked from a Freemind map very similar to your list, organised/weighted by upvotes, our estimate of effort required, and our personal desire to implement the features we worked on. I should have made that more public.
I’ve been intentionally circumspect about the wikification, to try to leave the three wikified pages open as long as we can. I expect that soon enough the spammers will find them, and we’ll have to lock them down as protected pages. For those paying close attention, see this.
Code contributions are welcome :)
It is my intention that agree/disagree has no karma attached. I think it very plausible that agree/disagree won’t work as I hope it will for polling… but the test is as cheap as ordering which we implement first. Since we plan to implement agree/disagree anyway, we get the experiment for free.
I agree that preview would be nice. What we have now works pretty well, so I’m judging this feature as low benefit/cost. Your suggested solution would be easy to implement, but I think would be confusing to users.
Agreed. I have learned.
Didn’t notice this has gone live. Luke edited in the wiki source of about page what I think is just terribly wrong, and now it’s the site’s about page, but it’s 5:40 AM and I can’t figure out a way of undoing the problem without removing the content. From the page:
These are not norms, these are skills, and there is no hope or point in enforcing them, particularly absent understanding the purpose.
It’s like saying that believing that ZFC is consistent is a community norm in a math seminar. Doesn’t sound at all right.
I was not a lone actor. The new About page I wrote was approved by SI.
The community norms are both norms and skills. I have seen them enforced by the community hundreds of times.
I’ve just edited out the phrase “community norms” from the “about” page.
I like what you’ve come up with. Thanks.
(Which to some extent does indeed mean you’re not a lone actor, but it’s worth noting that SI approval isn’t much of an argument in favor of the About page’s quality. (Just wanted to make sure people didn’t assume you were making an argument from authority.))
I assume “I can’t figure out a way of undoing the problem” speaks to finding the right words for the about page.
The technical way to solve the problem is to edit the wiki page (with the right words, whatever those may be), then wait a few hours or be logged in to LW and click the “Force reload from wiki” button at the bottom of the about page.