trim 2 assessment

Tuesday 5th April 2016 -- 14:00

connecting previous assessment

Slowly moving towards a broader consideration of interface and black boxing. Was the clarity I was calling for just a result of logical development following a method of boxing tools & utilities up? Are these boxes in a chain sequence or is it more organic? Where do I, the user, stand in this sequence?

The 'necessity' for such a system is clear, I'm glad one does not have to run each intricate item and dependency when executing a task. This model is not flawed or even really broken in any way. I'm looking at a logical consequence of this modeling: it's opaqueness. (Looping back to this seems terribly logical. It is suddenly quite a simple point to be looking at my research from, but anyway.)

I'm putting aside the moralistic and fearful opinions I have voiced between the start of the year and now, in order to concentrate on projects that might generate discussion / opinions for the audience it self.

In attempting to answer the question around the structure or sequence of the black boxes scheme, I collected a few examples of attempts of visualisations:

maps! schemes!
Michael's 'where does the code run' drawing on the wiki?
'if you please draw me a cloud' ?

then I tried a few more basic ones, to actually see if I could draw out what I thought I knew

Temporary conclusion:

I understand why these technologies are boxed up, and why these boxes must exist. I am fine with them, but understanding their sequence, and where I stand in their chain could be valuable.

So I started to look at the spaces between the boxes. Leverage points. Friction points, where it might be possible to insert objects (prototypes) in order to reveal the structure.


prototype ideas

live notes, tutorials, etc

I write up these quick notes and thoughts, and try to date them. They stay collected in a folder called drafts to lower expectations: