Skip to content

Instantly share code, notes, and snippets.

@ismith
Last active January 15, 2016 03:08
Show Gist options
  • Save ismith/fb6e52bbd8a69fa6547e to your computer and use it in GitHub Desktop.
Save ismith/fb6e52bbd8a69fa6547e to your computer and use it in GitHub Desktop.

(Context: longer reply to the tweet thread at: https://twitter.com/Lollardfish/status/687807074416234496)

I tend to favor participatory design (your phrasing) and the practical ... in this space, I see product design as fitting into 3-4 levels. (Actually a spectrum; they subdivide further and the boundaries are hard to distinguish. Categorical perception, of a sort.) Gonna talk about this in terms of wheelchair tech, but it applies to other tech, both assistive- and not.

  1. The only barrier is "not on the market". "A wheelchair like my current one, but it should have USB power to charge my phone, the joystick should display the date (in addition to the time it currently has), and its throttle should range from current-minimum to twice current-maximum." This product is not really novel, it's just that the current market has not built it for whatever reason.

  2. Beyond current tech, but within reach. "My wheelchair should be self-navigating - it should be able to go from my home to the subway to my office under its own control." Within reach, but not trivially obvious from existing pieces. The original iPhone was in this vein, I think - it had novel components and engineering, it wasn't just made from already-available components ... but the achievement there was more "hey, wouldn't it be cool if I had an internet-connected computer in my pocket? My email, everywhere?" than a radical change in basic science.

  3. Near-future/imagineable future. "My wheelchair should transform into a quadcopter a la Inspector Gadget for my commute." Not achievable with current levels of technology, but not totally implausible.

  4. Far-future/fundamentally impossible. I condense these two because, well, 200-300 years ago, "I live 2000 miles from a friend I talk to weekly on a magic box" was "fundamentally impossible".

I categorize the design in question in (4). Maybe it's a 3 if you say "we can fit batteries to whatever shape we want (this is in (2)) and the weight isn't a problem because ...". There's nothing inherently wrong with this sort of speculative writing (media production?). Scifi/fantasy/spec-fic are an example of how that sort of thing can have great value! Too, using this sort of thing as a vehicle for, say, practicing/learning visual design or another specific part of the process might mean that the practicality of the design isn't relevant - that's not what's currently being done.

I think I have some discomfort with that, though, if we aren't explicit that that's what we're doing. Pulling in another area of assistive tech - every few years, someone reports on a high school kid or a college research team that has built a glove or a camera that "can translate ASL to English" ... and it actually just recognizes a small corpus of gestures in isolation. Interesting from a tech/eng point of view, and a neat project; but not solving the stated or implied problem. Not relevant or of interest to the target audience for the product.

Which, again, isn't to say that it's wrong. But I don't know that it contributes to the space of (assistive,disability) tech, or gets the involved designers thinking deeply about that space.

^-- incomplete thoughts, but that's all I have :D

Oh and - as you say, they're not necessary opposites, but they are contrastable.

@ismith
Copy link
Author

ismith commented Jan 15, 2016

Oh, and I guess those levels could also be described in terms of ... timeframe? 1 year out, 10 years out, 20 years out, 100+ years out (to pick semi-arbitrary values).

@ismith
Copy link
Author

ismith commented Jan 15, 2016

One more thought: I don't think that "participatory" and "practical" necessarily have to coincide. Participatory tends to promote practical, but practical can be a goal even when participatory doesn't fit within the constraints of a given project/exercise/class. (Because it doesn't scale, say.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment