Chris Shiflett http://shiflett.org/ en-us Web Craftsmanship & Commentary What Does Block Mean? http://shiflett.org/blog/2013/dec/what-does-block-mean http://shiflett.org/blog/2013/dec/what-does-block-mean Twitter just witnessed a pretty serious backlash over their new policy on blocking, and rightly so. If ever there was a need to do some user testing, this was it.

What was the change? You can no longer actually block users on Twitter; you can only mute them.

I should note that Twitter is already reconsidering this change, and hopefully they can address all the valid concerns being raised.

I can understand why this change made sense. As a developer, it’s easy to create false dichotomies and simplify complex issues into a simple case of black and white. Because a block can be subverted by logging out, the previous policy could give someone a false sense of security. Twitter’s CEO claims this new policy was frequently requested. I’m sure it’s meant to be more honest and less misleading. In fact, I firmly believe this change was made with good intentions, but that doesn’t mean much to those who suddenly feel vulnerable or feel like their trust has been violated.

I mentioned user testing, because I think this stuff is important, and it’s not easy to get it right. When we discuss product design, we often talk about making the desired behavior the easiest thing to do. It’s a poor argument to then claim that the desired behavior is possible, therefore no improvement is needed. The same lessons apply to this situation. Just because it’s possible to subvert a block doesn’t mean the block serves no purpose, nor does it mean the undesired behavior shouldn’t be discouraged even if it can’t be prevented entirely. When human behavior is involved, things can get messy. Sometimes, imperfect solutions are all we have.

Don’t just take my word for it. Here’s what a beloved user experience designer (and victim of abuse) has to say:

Inserting ANY friction into the process of abuse is a VERY good thing. Social contagion for attacks is enabled by ease and speed.

One aspect of this issue that hasn’t been discussed much is that the previous policy could add fuel to the fire, because blocks were more obvious. Twitter claims their desire to prevent abuse escalation was a big motivation for the change. It’s quite possible that a change of some sort needs to happen, so let’s not be too quick to assume the old policy was just fine.

When things like this happen, I try to learn all I can, and that’s one of the reasons I decided to write about it. I certainly think it was a mistake to quietly change this policy, and I think it was a mistake to try to solve a particular problem (abuse escalation) without considering what new (or old) problems might be introduced. This isn’t code, so unfortunately you can’t rely on your tests to help prevent an old bug from reappearing. I’m encouraged by Twitter’s quick decision to reconsider, and I hope to wake up to good news.

What lessons do you think we can learn from this?

I’ve been online for a couple of decades now. I’ve seen the good and the bad, but I’ve never been stalked (unless you count a very persistent troll), nor have I been a target of death threats or any of the other horrible things that others have had to endure to maintain any sort of public profile online. This post is an exercise in empathy.

]]>
Fri, 13 Dec 2013 04:04:07 GMT
Web Advent 2013 http://shiflett.org/blog/2013/nov/web-advent-2013 http://shiflett.org/blog/2013/nov/web-advent-2013 In 2007, overwhelmed with my jealousy of the Perl community's awesome Advent calendar, I decided PHP needed one, too. Of course, this thought didn't occur to me until the very end of November. Nonetheless, thanks to an enthusiastic community and some very generous authors, PHP Advent was born.

Sean not only helped out that first year by turning around an article in no time (becoming the very first author), he has also been helping me ever since. For each of the past six years, we've curated, edited, and published 24 articles for web developers. We're proud of our little contribution to the Web, but thanks to a taxing year (including a pretty ambitious Brooklyn Beta), we've decided there won't be a Web Advent this year.

This might seem like an odd time to take a year off, since we just changed the name last year, but that change was long overdue. Our focus hadn't been PHP for years, because web developers are always learning new things.

We might return in 2014. Until then, keep an eye on these other fantastic Advent calendars:

24 Ways
This is the Advent calendar for web designers.
Perl Advent
This one's all about Perl, of course. It's been going strong since 2000.
Performance Calendar
Learn all about web performance. (Primarily focused on frontend technologies.)
UXmas
UX is for everyone. Brush up on the topic this December.
SysAdvent
Even if you're not a sysadmin, you probably have to act like one sometimes. :-)
]]>
Thu, 14 Nov 2013 15:52:20 GMT