A Bad Procedural Argument (For Reducing Online Hate-Speech).

~60 min sketch. Best in webkit browsers. Click here to interact. 

This sketch allows a user to ‘reduce’ hate speech online by ‘limiting bandwidth’ with the obvious catch that the occurrences can’t be reduced in proportion to other kinds of speech, only speech overall can be limited. It presents the premise that hate speech is always in proportion to other kinds of speech and from this a kind of naïve argument that  limiting one kind of speech is just to limit all kinds of speech. (This description is admittedly very imperfect though  as there is nothing to indicate, procedurally or otherwise, that the purpose of the manipulable features is to affect the occurrences of “HATE”.)

Continue reading “A Bad Procedural Argument (For Reducing Online Hate-Speech).”

Other questions to ask than ‘should designers code’?

‘Should designers code?’ is a question with  many competing takes. I will not provide another answer here. Instead I’ll offer an alternative route for consideration—questions that favor descriptions of what is over prescriptions and value judgements. Hopefully they’ll bare someone more nuanced fruit…

  • If we take “code” as a transitive verb, the question becomes “Should designers code [thing]?” What then is the thing? Are there different categories of coded things in question here? (The reader may be familiar with the concept of high and low level prototypes, but a low level prototype of a multi-player game does not present the same problems as a low level prototype of a resteraunt landing page.)
  • How much coding (and of what sort) does a designer have to do (whether yearly, monthly or daily) in order to be a ‘designer that codes’?
  • Are there criteria for excellence with respect to the things coded? Can these be used to establish minimum and expert level coding aptitude? 
  • What are the distinctions betweens novice, intermediate and advanced levels of capability with respect to the above? What does it take to develop these skills at these levels?
  • Do designerly programming skills break down into different domains?
  • What has been produced by people with some or all of these skills?
  • What kinds of (design) problems have been solved (or investigated) through programming?  
  • What are problems that designers have tackled through programing that they wish they didn’t?
  • What problems did designers not tackle through programming that they wish they did?
  • Are there specific programming skills that can be abstracted to more traditional design areas? What about reverse?
  • What are some best in category ‘interaction/interactive designs’?
  • Who made them?
  • What were the skills of the people on that team?
  • What were their responsibilities?
  • Are there any ‘good’ ‘interaction/interactive designers’ who can program? How ‘well’ do they program exactly?
  • How do they use their skills (if at all)?
  • What are their overall methods like?
  • What kinds of projects do they work on?
  • What kinds of problems do they solve?
  • What kinds of teams do they work with?
  • What are their day to day responsibilities?
  • Are there good ‘interaction/interactive’ designers who do not program?
  • How do their methods, responsibilities, activities, problems and projects compare to those that do?
  • What other (sub) skills “should” a designer have (or not have)?
  • What investment is necessary to develop what aspect of these skills to what degree? What resources are available? How does this compare to other skills designers develop?
  • For the designer asking if they should [learn to] code: do you like to code? 

Finally, If you absolutely need an answer, you could do worse than weighing Alan Cooper’s negative argument from “Should Designers Code?” (2017) against the affirmative point of view from John Maeda’s “Design in Tech” reports (2017, 2018).