Notes from design crit last week on making/hacking Inclusive Learning Design Handbook entry

Harnum, Alan aharnum at
Mon Dec 19 20:51:15 UTC 2016

I realized I didn't send these out last week as I'd thought I did, so am doing so now.

If anyone has further comments (or I missed a comment someone made), please let me know.

I've also added the notes to the PR at


E aharnum at<mailto://>

100 McCaul Street, Toronto, Canada, M5T 1W1<>


Notes from the Design Crit

  *   Liz Delarosa from Queen's University joined us


"hackathon" and "hacking" may themselves be alienating terms and have associations with the need for technical knowledge to participate. We discussed alternatives (such as "collabathon"), but didn't come to a definitive conclusion.

For now, we will probably stick with "hackathon" and "hacking", but add further content regarding:

  *   How we are using the terms and why
  *   Why the terms themselves need some critical examination

Remote Collaboration for Hacking & Making

The current language emphasizes "physical proximity" as a characteristic of hackathons. This isn't particularly inclusive and it would be best to:

  *   Remove this language
  *   Add some content on specific tools and approaches for remote participation

It was suggested that events and initiative that are aligned with hacking/making's spirit without being called "hackathons" (like Global Game Jam) be mentioned as themed events with distributed teams and groups.

Participant Motivations

The differing motivations of participants in these activities were discussed - this is especially so when hacking/making targets the "needs" of individuals for educational purposes (like engineering/OT students working with older adults, in Liz Delarosa's example).

The question: how to design to account for different motivations for participating, and make it clear to participants what they're actually signing up for? What kind of information do they need to be given?

"Nothing About Us Without Us"

It was suggested that some additional language be added around this concept acknowledging the extra work involved, but also that it will lead to better outcomes and learning.

Another point along these lines that came up: the entry should discuss how designing for the needs of extreme users creates benefits for all (curb cut effect), and innovations that wouldn't occur otherwise (innovation from the margins)

De-centering Hackathons from the Entry

The entry as-is skews towards hackathons in terms of how it presents hacking and making. It's important to keep in mind the broader umbrella of:

Hacking, Making and DIY Learning Generally

We're trying to talk about bringing inclusive design to a class of activities and events that have some or all of these characteristics:

  *   DIY ideology: self-motivated, not mass produced, not group directed
  *   pressurized creativity
  *   one to one design (both as an outcome, and to allow more diversity in participation)
  *   Informal creation done to make something for someone who needs it (such as Tetra Society)
  *   "an engagement and relationship with constructing new things" (Simon)

Hackathons are Not a Substitute for Other Things

Things missing from hackathons:

  *   Time
  *   Depth
  *   Field Work

Questions that arise from this:

  *   What do we need in addition to hackathons?
  *   What do we do after the hackathon?

Overall, hackathons should be a class of event discussed here; we need other examples and need the entry to focus upon the kind of learning activities (making, hacking, experiential learning, Papert-style constructionism, etc) moreso than a particular event.

Splitting Into Multiple Entries

Not at this stage, but may need to happen at some point. It was pointed out there's a lot of common things about running inclusive events that might best have their own entry (captioning, physical space configuration, etc).

Scenarios Need Work (or Perhaps Deletion)

  *   If we want to retain these, it would be best to get them reviewed4 by practitioners.
  *   They are mostly specific to disability and accessibility
  *   We need to be careful with the specialist terminology (like "multimodal interfaces"); define these terms inline, or link them out to definitions in the ILDH or otherwise.
  *   Generally speaking, examples are better than scenarios.

Having More Tools Without Becoming a Clearinghouse

The intention of the tools section (and the distinction from Resources) needs some clarity. It would also be good to add some additional tools, and explain in more detail some things about the tools such as:

  *   Who might use them ("this tool would likely be used by developers building software")
  *   General category the tools fall into (software, fabrication, design activities...)

It would be good to have some tools that are more oriented towards beginners / non-technical people like:

  *   Scratch
  *   Makey Makey

Some OT/AT/3d printing/physical hacking approaches might also be interesting:

  *   Thingiverse
  *   Cardboard for making / making on the cheap
  *   Ikea hacking
  *   Go Baby Go:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the fluid-work mailing list