1,146 karma · joined August 11, 2011
My project, Unfold Studio [3], makes use of the affordances of Inkle's Ink language for teaching CS in the context of students' existing identities and concerns. Here, the limitations of the format are again useful. Students can create small playable worlds in a way that's still manageable and which makes CS concepts rhetorically powerful--they are immediately useful for creating particular experiences for the user. Here's an accessible piece [4] on how this approach could support marginalized youth in developing criticality: understanding and challenging unfair techno-social conditions.
I'm always looking for collaborators!
[1] https://www.theatlantic.com/technology/archive/2017/04/video... [2] https://ncase.me/cos/ [3] https://unfold.studio [4] https://chrisproctor.net/publications/proctor_2019_voice.htm...
"In September, the website went after David Ollila, a serial entrepreneur who in 2010 created a short ski for climbing snowy hills he called the Marquette Backcountry Ski...Backcountry.com argued that Ollila knew he was intentionally abusing the Backcountry.com mark because he had ordered products from the website in 2002 and 2010."
Someday I will help lead a school whose software is written by students and whose policies are debated by student government, faculty senate, and the PTA.
I guess I could use a hash of the domain (eg asdffdsa@accounts.mydomain.net) to make my strategy less visible, but that feels like I'm probably overthinking it.
I'd also want to teach beginners in a way that lets them keep building and tinkering outside the environment I provide for them. This is where I'd love to see schools providing and encouraging the use of hosting space and resources like Minio, so that students can just count on them being available.
A lot of current approaches prioritize scalability over everything else, leading to canned and sandboxed curricula.
I'm curious, though, whether this is in tension with your understanding of constructionism.
First-year CS students (middle school or high school) with experience using Apple products don't have a concept of a filesystem. The shift to auto-saving documents also corrodes the intuition that files get stored on disk in some non-magical way. In the same way that it's now easier to teach networking and graph theory because youth experience identity and relationships this way, it's now a lot harder to teach lower-level abstractions. In my experience, this has changed over the last five years.
One thing I'm looking forward to adding is tagging recipe steps as do-ahead, mis en place, early, late, and last minute. This will make it a bit easier to think through the mental gantt chart I use when cooking a dinner composed of a bunch of dishes. Also a simple scraping utility for importing.
The thing all these have in common is that they're reactions against the festering cesspool of hostile-UI, low-information-density, pages full of affiliate links that are today's cooking sites. (NYT cooking very much excepted.)
I wish we had a better mechanism for including more people in the project of iteratively refining the way we think about life tasks and improving the tools we use to think with. I think this is a great conversation and wish more people who like to cook could participate.
It would add a bit of technical complexity for site owners, but that seems manageable, particularly for b2b relationships.
Obviously, I hope this doesn't happen, but it seems like an obvious strategy and I don't see the flaw.
After reading GMail's announcement about dynamic email and your position statement on AMP, I am thankful to have switched to FastMail and looking forward to remaining your customer. I'm writing to ask you not to implement AMP dynamic email. Even though you don't have a huge slice of the email market, your customers are probably disproportionately privileged and informed (they choose to pay for email...), which positions you to resist these erosions to privacy and democracy in ways that individuals can't.
More pragmatically, I see your non-support of AMP as a big feature. If you don't support AMP, companies can't as easily put pressure on me to use a communication channel where they have all the control.
Thanks!
One strategy for explaining the problem to non-technical people is by comparing regular email to the walled-garden email used by some banks, phone companies, and the like--where you have to log into their website to see your 'inbox' and use a web form to send messages. It's super annoying and the other party has complete control of the communication channel.
"Dynamic email" could be implemented to inject this kludge into your email client, giving the AMP sender (who likely has more power than the user) the same level of control over the channel. Imagine opening your email client and finding a message which asks for two security questions and a captcha, then lands you in a messaging interface which limits you to 200 characters and denies basic affordances of email like archiving and forwarding.
I find the arguments that email is already mutable because images are externally-loaded unpersuasive. In 2013 Google started caching images in gmail "to protect you from unknown senders who might try to use images to compromise the security of your computer." [1] Email marketers were upset at losing engagement metrics. Now a practice that used to be considered abuse is being rolled out as a feature.
[1] https://gmail.googleblog.com/2013/12/images-now-showing.html