Scrubbed out a few anti-patterns #34
Conversation
|
I'm not sure it's the right time to be reductive yet. For example, so many SMSisms: https://www.newschallenge.org/search.html?text=sms
This is a concrete criticism. You're right that these are closer to TV Tropes, but I think the ultimate point of writing these is to help people ideate or converse, rather than be a rigorous study or criticism. So I guess the lens I'm looking through is "is this functional?" rather than "does it fit?"... which is why I've been fine pasting in stuff like that list from Types of Civic Applications. Also, in terms of audience, I think that normalizing it as a "pattern" gives it more traction. |
|
Thanks Ben for clarifying, I appreciate the chance to talk through a few of these. I’ll be honest, I don’t really get what the issue with SMS is. It’s the closest thing we’ve got to universal push notifications, and that’s what makes it a trope. By all accounts, Promptly has been a huge success. Über uses it to tell me my first-world car is on its way. If it’s just a lazy choice, then let’s say that instead of calling it an anti-pattern? If it’s just old news to more experienced civic tech folks, then maybe we should unpack that to see if we’re prematurely introducing an old club mentality? Same goes for Stuff On Maps. |
|
Another way to think about lazy choices: they are signs of opportunities for platformization, and therefore something we at Code for America might want to spend more time thinking about, not less. Mapbox has made a highly visible company out of Stuff On Maps, for example. |
|
I don't think Ben and I are of identical mind on this, but w/r/t to the SMS one: I think the bigger point here is not to implement SMS unthinkingly or just because, assuming that it's a great lo-fi, maximum access interface. This is important: different types of interfaces engender qualitatively different input. Text may not be the best-suited (or even well-suited) way to get input. For example, text/SMS is a terrible way to do 311 submissions. Not only is it hard to use, but it's hard to implement (and cities who do it often wind up bending over backwards or not providing full support for all services through it). Voice is much better, not only because it handles the situation more adeptly, but also because of how users respond to it. CityVoice is another example of the same thing in action. Pushing users towards voice input, rather than SMS, resulted in qualitatively different feedback and, I think, was probably more widely accessible. But someone who worked on it would probably have more to say about that (paging @daguar). All of this isn't to say SMS is bad—there are a huge number of applications for which it is very well-suited. The problem is just that the rhetoric is "SMS makes your app accessible to a wider audience," which is not necessarily true. Think critically about it before implementing it and pushing users towards it. |
I think this is exactly the attitude I am trying to engender with Civic Tech Patterns: giving a common language and building blocks for building more complex understanding (and interventions) in the space. When someone reads "Stuff on a map" I don't want them to think "don't use maps", I want them to think "how can I make sure that the maps I use are truly transformative and necessary in this intervention?" And I don't disagree either with the fact that rents can be captured by intermediating bad investments. But that's somewhat orthogonal to "how do I structure a good investment?" Oh, and I think all of these things could use with some good expansion because I completely agree that just reading the 3 sentences of "Stuff on Map" can leave one more in a state of methodological criticism rather than of methodological belief. |
|
So, really what is meant is “don’t stop here,” rather than “don’t do this?” What’s a better way to phrase that than Anti-pattern? I don’t see the value in having anti-patterns at all, if we are really just asking people to think a little harder.
|
@Mr0grog hit the nail on the head with this. The anti-pattern is when people have a web app or native smartphone app idea, but think many of their users won't have access to these, and so build an SMS interface regardless of whether: With CityVoice, we actually fully prototyped and tested an SMS app because we knew that access to the web might be lower in the communities most affected by abandoned properties. But what we learned from actual user testing with community groups was that while we would increase access with an SMS app (i.e., more people had a device capable of using it) we wouldn't increase engagement because many of our target users were older and didn't know how to use SMS -- even if they had it on their phone. I think the meta-anti-patterns here could be boiled down to lack of intentionality and cargo-culting. The core utility of this document, to me, is to say, "X being ubiquitous in 'civic tech' is a weak signal of X's efficacy in your specific problem space. In fact, in most cases, if you dig into the details, you'll find the Emperor has no clothes." I believe that's quite valuable. This all said, I support removing the current SMS anti-pattern wording. I think as-is it's more of a put-down to people who might just not have thought about this, and is probably suboptimal in actually affecting people's design decisions. I'll do a PR with proposed revisions. |
|
👍 to everything, thanks guys. I’m just going to throw out that “think about it more” or “don’t fuck it up” are both Pattern anti-patterns. The power of Alexander’s original book is that each section is brief, concrete, actionable, and gives you a clear thing to do along with the issues it attempts to solve for. Single room with nooks for a single older person, that kind of thing. I’d be interested to see the anti-patterns here replaced with actionable research patterns (I dunno, “Ask ten people” or “run a Cityvoice poll”) which prevent cargo cult behavior without calling it out as lazy, just the same way a smart advisor might push you to follow a line of inquiry further. |
|
The Wikipatterns website seems to be down, but maybe it's easier to show by example what the goal is of this project, so via Wayback: https://web.archive.org/web/20130415102150/http://www.wikipatterns.com/display/wikipatterns/Build+it+and+they+will+come |
|
I think that all the anti-patterns should reference good patterns as alternatives. But I do think it's helpful to explicitly call out bad things and things you shouldn't do (have a map for no reason; flatly equate SMS with inclusion) because that then becomes a reasonable floor. My concern with being solely positive or action-oriented is that those become things to attain ("it would be great if...") and dismiss ("...but we don't have the resources/time/mandate.") rather than things to flat out avoid ("if we don't have the resources/time/mandate to exceed this, maybe we should do something else entirely"). I'm stretching for examples, but it's the difference between saying "use a password manager that generates random passwords" and "don't reuse the same password everywhere." You gotta have the former and the latter (and there are some people I'm gonna link to the latter, and other people I'll link to the former). Anyways, this also falls into the perennial problem of giving advice: it's couched in the language of outcomes ("do this, end up with that") but is itself process ("consider this, be aware of that"). And if I could just reference some 1960s psychology experiments, I'd have a pop-marketing book. |
|
Sure, yeah. However, the ones I’m proposing to scrub would need to be substantially modified to be anything but buzz-kills. Have a map for a reason: give examples of good reasons. Aim for inclusion: suggest research paths to identify users to include. Want growth: show how to growth-hack. |
I removed a few anti-patterns that didn’t seem to offer guidance. There are others, but these were the ones that read most like TV Tropes: descriptions of approaches or arguments that a lot of developers reach for, perhaps “bad” because common, but not wrong or harmful in any meaningful sense. Maybe bring them back with concrete examples, or ditch the “pattern” name (which has a specific connotation in the Alexander or GoF contexts) and replace it with “lazy ideas”?.
Cc @daguar, @bensheldon.