Exercise: You vs the Machine
15-60 minutes.
In this exercise, you'll find an opportunity that is uniquely yours. Make free use of the examples and use Cadence Keeper for short durations. For longer exercises, dig into something more personal.
Build
(half the available time)
Scribble down a few things about what it is, and what it does. Perhaps you want to add what it's for.
Examples
Cadence Keeper lets you track how long it has been since you did things, and lets you keep and manipulate a list of those. It's a web page with JavaScript, and uses the browser to store information.
What it is: Code (HTML / CSS / JS) – something made by James – an exercise source – something like a habit-tracking tool – generated code – not ready for production
What it does: Allows you to CRUD items in a list – accepts input – tracks time – keeps data when the page is closed
Pick a few items from your collection. Identify generic artefacts that you can in some way handle. These are your exploratory surfaces.
Examples
Code:
-> several JavaScript scripts, linked HTML and CSS files (can be handled by enumerating vis DevTools),
--> within those there are identifiers with meanings (handle by looking within DevTools / debugger to look for objects with properties, or search code – especially the HML for names and the CSS for classes that might imply functions).
--> error management (handle by looking for console.log or alert or assert or try...catch, or looking for text).
--> structure (handle by throwing at a tool like CodeToFlow )
--> style (handle by throwing at ESLint? Asking an LLM about it?)
-> a repo (handle by asking for it)
--> look at the commit history
Made by James:
-> it has an author (handle by asking questions)
--> purpose
--> tech stack
--> values and risks
CRUD a list:
-> it should have a list (handle by looking in the code for a plausible list to watch in DevTools),
-> allow each of CRUD (handle with a checklist and watch that list if available)
-> should be list-like (handle by thinking of max and min sizes, sorts, how these work with weird contents, other access to the list)
Keeps data when page is closed:
-> how? (handle by searching in code, looking for open files, or digging into localStorage for the domain in your browser)
-> the persisting data (handle by identifying location, try changing the data when the page is closed and see results on open)
Pick one or two of those artefacts that you might want to explore. If nothing appeals, notice that and spend time thinking of others that might. No sense in mucking about with dull things.
Write a note about how you'd handle that exploration (remember: you don't have to change it to explore it, and you don't need to know what it should do). These are your Exploratory Interfaces.
When you're writing,
- Know why this thing attracted you for exploring
- Consider whether you would bring a specific skill
- Consider whether you'd use (or go look for) a tool
- Consider how you might iterate – to do similar things to a series of similar parts, and how you'd find the limits of your exploration.
If the opportunity presents itself, certainly try handling it in the way you imagine, take the next steps and see how you handle the next.
Use the shared space to write / share your note.
Debrief
(the other half)
We'll ask for volunteers to share their thoughts, and the rest of the group will celebrate the unique approach that they bring.
At the end, we will sum up with surprises and changed perspectives.
Comments
Sign in or become a Workroom Productions member to read and leave comments.