rodcorp

Timo Arnall/Immaterials and Improving Reality

Notes from the Immaterials show and the Improving Reality conference, Brighton, Sep 2013.

(Immaterials: Light painting WiFi project by Timo Arnall)

Immaterials

• the show by Timo and Einar Sneve Martinussen, Jørn Knutsen, Jack Schulze and Matt Jones at Lighthouse is put together well - beautiful images and films that make visible the RFID, Wifi, GPS and machine sensor fields we walk through and bathe in.
• The Fischli & Weissy Nearness film with Schulze is delightful. The early Experiments in Field Drawing. (Confession: it's impossible to review something with Timo, Schulze and Jones in it with any objectivity.)
• The faint wobbliness in the light lines in Light Painting WiFi - the experimenter's unreliable hand.
• Tiniest quibble: the stills from Wireless in the World fall slightly short of the rest, by appearing decorative.
• The twitchy object rec algorithms in Robot Readable World.
• The recent Satellite lamp is beautifully sputnik. 
• Timo's background to the show.
• [and this is how much I like it!]

Timo's talk at Improving Reality

• Technology: the frictionless and seamless glowing, slidey, textureless glass rectangles. Little of the technology is apprehendable or graspable (think of Heidegger: ready to/present at hand).
• The importance of making the invisible visible (of showing the seams) so that we can understand the tech, the system. The difficulty of the same, because seamlessness is so desirable and seductive.
• And yet in our experience technology can often be a lightning rod for very human concerns (as if an antenna receiving and amplifying). When you deploy a new application on new mobile phones to an organisation, human questions are immediately raised: do we have to use this? Does it track us? Is this why X lost their jobs? 
• So the technology might be invisible, but it can also make human concerns visible.
• Light painting - the photographic technique - came from employee time and motion studies
• user Stockholm syndrome (Sterling?) - the act of becoming dazzled by user considerations/needs and forgetting the other parts of the jigsaw, eg materiality
• Julian Oliver et al, Critical Engineering Manifesto.

Keller Easterling

• Extra-statecraft
• Dense talk - a sense that there's some substantial stuff to unpack here, but hard to follow. (Performative exemplification? Or I am stupid.)
• Contemporary architecture's power-ideological bias, cartoons unfolding in time.
• How to un-develop, to subtract architecture?
• "ESC researches global infrastructure as a medium of polity. Some of the most radical changes to the globalising world are being written, not in the language of law and diplomacy, but rather in the language of infrastructure [... infrastructure] generates emergent new constellations of national, international, intergovernmental and transnational administration and generates undeclared forms of polity faster than any even quasi-official forms of governance can legislate it" - from Extrastatesraft.

Frank Swain

• Entertaining on the fictions in maps. 
• Though of course all maps are fictional to some extent. Though of course so is reality.

The second session, Re-imagining reality, was energetically hosted by Simon Ings. What a shame though that we didn't hear from him directly - his books (The Eye, Dead Water, etc) are excellent.

Paul Graham Raven

• Raven's An Introduction To Infrastructure Fiction.
• Infrastructure fictions, a manifesto rather than a literary mode - explicitly a call to "think about the box", not to write, er, more stories about bridges
• Intent: lightbulbs were invented to sell electricity - source? (related?).
• Resist "flat-pack futures" - Scott Smith.
• A preoccupation with engineering ("how", goal) vs design/art ("why").

Maja Kuzmanovic

• Baffling. 
• "'patabotanists" was good. "Prehearsal" however sounds like "pretending".

Alexandra Daisy Ginsberg

• Food for astronauts is always constrained to flat, light high energy seaweed and other nutridusts, but what feeds their psyche? 30 tonnes of food needed to sustain a team to Mars and back.
• GM bacteria that change colour - as health diagnostic. Bacteria-tinted shit. "As someone with crohns disease. Shit as an interface would would be super useful".
• Human foot-cheese bacteria cheese (same bacterium as certain cheese so why not make it into real cheese), armpit bacteria cheese.
• Why is it that everything we can separate from or expel from the body revolts us as soon as it is separated? Shit etc obviously, but think of hair and saliva. And even when it is identical to something else - foot-cheese bacteria - it remains no less revolting.
• bacterial-mediated fruit that grow on electricity rather than sunlight
• Is synthetic biology part of/apart from nature?
• Questions about design vs art, science vs culture, science vs non-science

Tobias Revell

• Get your futurism bingo cards ready!
• "Design can be a political movement [...] technology can be a territory" - now when stuff like this comes from my own keyboard it is a string of shining pearls, but when someone else says it in a talk I just hear reckony air - ah, such is the hypocritical tyranny of the spectator in a hot, dark room. Sorry.
• His 88.7: Stories From The First Transnational Traders was very good.

Tom Armitage/Jeff Noon, The Literary Operator

• Charming story machine by @infovore and @jeffnoon: you stroke a book with its puck and it Burroughs into the text, printing you a voucher.
• Eg this from Chandler's The Big Sleep: "Our breaths met and mingled, our eyes were slaty [...] Canino look like a clock".

Farida Vis, Georgina Voss, Paula Le Dieu, Justin Pickard

• Unfortunately the improving reality of life intervened, and I missed the third part.

There's no reason why Improving Reality cannot simultaneously appeal to realism and attempt to augment/transcend it, but even so I am slightly uncomfortable about the conference's name. 

Cruising above both show and conference is the invisible drone-father James Bridle, and in the luminous clouds above, Ben Cerveny and Kevin Slavin watch over us and keep us real.

A list of writing tools is a displacement activity

Writing, focussing, assembling, editing, collaborating, feeding back, researching, structuring, outputting and publishing. (Updated Feb 2014.)

Focus through constraint:

• iaWriter - "Keep your hands on the keyboard and your mind in the text". Has good reviews.
• Byword - "Simple and efficient text editing". Also has good reviews.
• Writeroom - appears a generation older than iaWriter and Byword.
• Textmate - does text, html and a zillion other developer's things.

Quality:

• Hemingway - "makes your writing bold and clear".

Research speed and convenience:

• nvALT - Speeds up that did-I-already-write-about-this? moment, auto-saves, does text files, Markdown. Nice. I'm writing this post in it.
• Pinboard - elegantly executed webpage bookmarking.

Collaborating and community feedback:

• Draft - its drafts are neat version control, has premium "ask a pro", updates frequently. (Has a no-going-back Hemingway mode, thought isn't the same as the Hemingway above.)
• Poetica - "Get feedback about your writing from people you trust, wherever they are" - not released yet. Amusingly, screenshot critiques Word track changes and Google Docs. Reviewed by Rev Dan.
• Google Docs - good at collaboration and export, auto-saves. Has automated versioning but without actual version *control*.
• Editorially - "makes collaborative writing easy", via here but sadly shutting down.
• Penflip - "helps you write better with others".
• Authorea - "the collaborative platform for research. Write and manage your technical documents in one place".

Assembling, structuring, editing and eBook workflow:

• Ulysses 3 - "All your texts. In one place. Always." Not tried, but this review says "the app reimagines the text editor in a way that visually resembles Mail and conceptually sits somewhere between iA Writer and the project-based Scrivener". Which sounds like quite a thing.
• Scrivener - looks a bit of a mess to be honest. They also have Scapple, a mind map/words-on-sticks app.
• LeanPub - "Publish Early, Publish Often - Authors and publishers use Leanpub to publish amazing in-progress and completed books". Costs $0.50 plus 10%.
• Lacuna books - "the best way to write and publish a book". Big on structuring, rendering chapters and ebooks easily.
• Quip - "Beautiful documents on any device".
• Marquee - "a full-stack publishing platform...  to help everyone, from editors to designers and developers, come together to make great content for the web".

Formats and outputs:

• Marked,  because between text and html, Markdown is the popular "intermediary" format, (like nvALT) is good at simultaneous preview.
• Mou - good at simultaneous preview of Markdown, custom css etc, always seems to recover well from its frequent crashes.
• And a simple Google Apps script to convert a Google Drive Document to markdown.

Online publishing and attention:

• Medium - "A better place to read and write things that matter" - becoming a centre of gravity for serious writing, per-para commenting interesting.
• Wattpad - an ebook platform/store/agora that isn't Kindleland.

Back to it now. Again.

The file-burning stove

One technique for managing paperwork that's fairly common in productivity circles is the Noguchi filing system, in which files are always re-filed on the left of a shelf. This results in a gradient of freshness, with old or stale files naturally sorting themselves to the right, whence they can be discarded or permanently archived.

It's a nice system, but the archiving/discarding triage takes such effort doesn't it? Once those files have made their way to the back or the bottom of the filing cabinet, wouldn't it be nice if your filing system automatically and judiciously took care of that for you.

And kept you warm.

We're hiring a BlackBerry/.Net developer in Brighton

We're hiring a developer to build mobile software products that help police forces and other government orgs communicate quicker/better. Messaging, photos, maps, presence, ajax, compliance, etc. Technically, it's generally BlackBerry J2ME mobile client and ASP.Net web/backend. More details on the role here.

We do scrum. We are nice people and have a shiny office in the middle of Brighton.

We're also looking for a good QA person in Brighton.

Ping us with your story at hello at mobbu dot com.

Maintenance, or the keeping of too much at hand, having delivered too much

Henry VII passed a law against "maintenance", the keeping at hand of too many male "servants" - contracted men-at-arms, private armies financially retained by powerful noblemen in the power vacuum after the Wars of the Roses. (The word maintenance derives from the Latin manu tenere, to hold in the hand, ie: to keep in a condition of effective functional condition: keeping at hand functionally.)

The visual evidence of this surplus and illegal retainer was the overuse of a nobleman's livery (whereas the visual evidence these days of maintenance, seems to be a spanner - a tool rather than an emblem). In legal terms at least - "retaining", "livery" and "maintenance" seem to have had the same meaning. And the term livery derives from the French livrée, meaning delivered: typically the object or a servant/messenger bore the livery of the noble that owned, retained or had sent them.

Thus maintenance would become a punishment for delivery, which may be a hollow joke for some of us working in technology. And every now and then, when reading contracts, I would like to follow Henry VII's lead and pass a law against maintenance.

Policing news; BlackBerry management tips

The Cabinet Office is providing £75m to get 25,000 mobile devices in the hands of police officers, the funding being managed by the National Policing Improvement Agency. It's quite hard to find consistent coverage of the story in the mainstream press, so we're tracking the story on the Mobbu blog as it unfolds:

• June: 27 Police forces will get £50m for 10,000 mobile devices
• July: Part of the £50m will be spent via NPIA's mobile data accelerator programme
• Sep: More background on the NPIA funding (and of Airwave's investment in Kelvin Connect, and BlackBerry having hit the 20,000 devices mark in UK policing).
• And any day now funding announcement is expected from NPIA for the unallocated £25m. And in the last week, 15 police authorities have revealed that they have money held by embattled or defunct Icelandic banks.

And Alex is starting to post some useful tips on device and application management with BlackBerry Enterprise Manager:

• Application updates not recognised on new BlackBerry devices? - on the benefit of keeping your device and vendor XML files up to date
• Always keep older versions of your Java apps on BES so that your BES can still perform remote management upon those devices that happen to update later then you expected.

How Lighthouse ticket-tracking currently uses Markdown for lists

We are gradually switching from Mantis to Lighthouse for ticket tracking at work because it's a great ticketing system, and more customer-friendly than Mantis because it's simpler. Lighthouse uses Markdown as its text-formatting "language". But we've had some problems getting text formatting to work well, partly because we're habituated to writing content in Textile-format in Basecamp, partly because we do lots of structured lists in our tickets, and partly because Lighthouse's implementation of Markdown lists is currently a bit idiosyncratic.

So here are some rules of thumb for making lists work in Lighthouse. As the developers improve it, I'll come back and edit this post. (I hope this also helps the developers updating the documentation and, preferably, the code: Lighthouse is a great product but we'd love to see a less brittle and more consistent implementation of Markdown lists.)

1. Every list must have a blank line above it and one beneath it. Else, your list will break horribly. (Also don't do a numbered list, then have a blank line, then do another list: it'll continue your first list.)
2. Nested/hierarchic lists work slightly differently for numbers and bullets:
   • To do a second-level bullet (a "child") you do space-space-*
   • To do a second-level number (a "child") you do space-space-space-1. That it's different from the way bullets are handled is probably a bug.
   • To do a third-level bullet (a "grand-child") you do tab-*
   • To do a third-level number (a "grand-child") you do tab-tab-1.
   • To do a fourth-level bullet (a "great grand-child") you do tab-tab-*
   • To do a fourth-level number (a "great grand-child") you do tab-tab-tab-1.
3. Mix numbers and bullets very carefully in nested lists: numbers should not contain bullets as children because the bullets tend to kill the number order of the parents...

Some examples. A list of bullets that works:

* parent
  * child (space-space-bullet)
    * grandchild (tab-bullet)
        * great-grandchild (tab-tab-bullet)
* parent
  * child (space-space-bullet)
    * grandchild (tab-bullet)
        * great-grandchild (tab-tab-bullet)
    * grandchild (tab-bullet)
  * child (space-space-bullet)
* parent

A list of numbers that works:

1. parent
   1. child (space-space-space-number) - nb, here it's a triple-space, not the double-space you'd do for a child bullet
   1. child (space-space-space-number)
        1. grandchild (tab-tab-number) - again, not the same as it is with bullets. And nb now you can't do a fourth, great-grandchild, level of numbers.
1. parent
   1. child (space-space-space-number)
   1. child (space-space-space-number)
        1. grandchild (tab-tab-number)
   1. child (space-space-space-number)
1. parent

And a list with both bullets and numbers that doesn't work in Lighthouse:

1. parent
   1. child (space-space-space-number)
   1. child (space-space-space-number)
    * grandchild (tab-bullet)
        * great-grandchild (tab-tab-bullet)
   1. child (space-space-space-number) - here the number order has been broken by the preceding bullet
        1. grandchild (tab-tab-number)
        1. grandchild (tab-tab-number)
   1. child (space-space-space-number)
    * grandchild (tab-bullet)
    * grandchild (tab-bullet)
   1. child (space-space-space-number) - again number order broken by preceding bullet
        1. grandchild (tab-tab-number)
        1. grandchild (tab-tab-number)
1. parent
   1. child (space-space-space-number)

There may be a better/more robust way to do nested lists, but I haven't found it yet. (Nested lists seem to work quite differently in Markdown, but to be fair to Lighthouse here, it does all seem a bit arbitrary in Markdown. Markdown seems more powerful than Textile, but also more complex, so maybe I don't understand it well enough yet.)

See also: Lighthouse commits to Markdown over Textile; Markdown syntax and testing doobry; a Lighthouse ticket discussing this very matter.

dConstruct 2007: raise your hopes

Quickly then, two eves and a day of experience, quickly compressed into an undifferentiated slab. In a bar on Brighton's stag night strip: an outdoor terrace packed with familiar and new faces, and a queue on the fire escape to access it. Queues will be cited the next morning. We are in town for dConstruct, a conference on user experience or experience design. Some of what I heard and thought follows and there are poor drawings. Apple and Flickr are good at design, and Microsoft and Nokia and nearly everyone else are not so good. That is law. Being an expert is good, but some things are inexplicable juju - unless you do them a lot, in which case you might become an expert. Queues are a floating signifier: either the hallmark of excellent design or the symptom of ballsed supply chain management. The history of consumer electronics starts with an experiential promise - Eastman (Kodak): "you press the button, we do the rest". This same history has technology giving way to features, and features to experience and simplicity. The history of aerial warfare starts with vision (reconnaissance) and develops towards projected force (machine guns) via a bias for problem-solving instead of solutions-provision (I have no problem with the design takeaway, but wonder if Sven Lindqvist might tell a different history that starts with projected force (bombs from balloons) and ends with panoptic reconnaissance and un-manned strikes). Steve Jobs 1984, 2007: time is even crueller to humans than it is products. Jeff Hawkins: the block of wood story which begat the Palm Pilot = good experience design. But the more interesting question: if the same man and approach was also responsible for the recent Foleo car-crash, then how to make it more likely you'll consistently have product hits? That Flickr started as a feature in a now defunct game is well-known; how does this open-ness to unintended consequences and adaptation tally against the much-cited iPod, whose claimed excellent design derives from an iron-grip on the product and service experience? The father of Waterfall secretly coveted next door's younger baby, Agile. Waterfall as haircut can look good, but as process is bad for designers and humans (well, always?). Reassuringly, user-centred design and agile development can (be made to) live together in perfect harmony. A sofa invites intimacy and anecdote - an unstated Gricean maxim of conversation? Swear-filters invite language reuse; people that write paragraphs like this are clearly utter cranberries. We don't like to offend our computers. Nor our conversations: implicature is what we do in bringing expectations about intentionality and meaning to a conversation, transaction or experience, via a mental model. Your website is not (the limit of) your product: your product reaches out into the network, and this is to be encouraged. Design for always-already reused. Nit-picking: experience/web/internetty design conferences tend to privilege performative and presentational competence, with corresponding risks. That a design proposal can legitimately be called a prototype. That dogma abounds: Apple/experience design good, Microsoft/non-experiental design bad. And that simplicity veneers a necessary complexity. But that's the nature of talks. There wasn't much new content, but the speakers performed really well. I must stop whining from the sides, raise my game and raise my hopes (that courtesy Arthur Davies, via his proud dad). The Market Diner is still a good place to go when the Meat Reaper comes calling in the middle of the night; Bill's is the lunchtime restorative. The event was really well organised by Clearleft and Brighton was in good form. At its social, playful best dConstruct felt like Reboot, and the return to Londra was an ascent back to the surface after a stag night's beer and talk. Good fun thx.

(Architectural metaphors in (sport) metaphors in business)

If you work in software, you're used to hearing metaphors borrowed from architecture and physical construction: technical architects, software engineers, building the software, "supporting" software, servers falling over, pipes, wiring, flows... (Eric Evans is not a fan of the production line or architecture metaphors, and considers experimental science or literature as more appropriate analogues -- the latter recalling Paul Graham comparing hacking to painting, and in turn Maciej Ceglowski's rebuttal -- before deciding that the metaphoric approach is in the end as much a veil as illumination*.)

An obvious reason that software making is a recipient of analogies is that it's a discipline that's rather opaque to those that aren't practitioners. And no doubt we could go back to Lakoff to remind ourselves why metaphors are so seductive* more generally.

And we're also used to hearing about business - about the work that is work - borrowing metaphors from sport or war: teams, winning, losing, indefensible arguments, attacking problems, taking the high ground, and so on... too many examples. (At this point in this post, I'd like you to imagine you were reading a couple of thousand words on sport as the pared-down movement-time-drama essence of social dynamics, an ideal vehicle* for bearing references to human relationships and drama. If it helps, imagine this absent description of a metaphor like Dan Hill's piece on Zidane, only not written as well.) And of course, you might push the boat out* and claim that sport is itself a ritualised, civilised form - ie metaphor - for war.

So given all that, this is interesting. Via one of the best Arsenal blogs comes Arsene Wenger offering the developing footballer as a building in an interview:

Wenger's response illuminates how he moulds stars. "You build the player like a house," he says. "The basis is the technique that happens before 12. If the player can play, the next floor is the physique at 14-15. Then it the tactical ability - how to use your technique and physique in the game.

"The last part, the roof, is the mental side. If you have no roof, it rains in your house. How competitive are you? How motivated to do well every day? That is the final step. I believe that hunger is something you get at 18 and remains relatively stable during your life. That is decided between 18 and 20. And that decides careers.

"You are not born with hunger. Roy Keane was competitive [from a young age], but why? You need to be psychoanalytical to see why. Sometimes the same adversity can have a bad effect. If you have a strong father, you can fight against him or completely lie down. Maybe Roy Keane had the first reaction, to fight the father. I don't know."

So if sport is a metaphor for war, and business borrows from sport, and software borrows from architecture, the question remains: what metaphors do architects borrow to describe their work? Answers on a postcard please - perhaps one of Rob-the-architect's.

Related: George Lakoff's Metaphors We Live By (1980/2003), Nik Boyd's Software Metaphors.

* they're everywhere, those metaphors, aren't they.

Crowd psychology: evacuation behaviour patterns

Evacuation

A few weeks ago I went to Heathrow to meet up with and see off my beloved aunt and uncle, who'd been visiting the UK from Melbourne. I got the tube from North London, they a taxi from Harefield. But I didn't see them because Terminal 3 was evacuated due to a bomb scare. I hung around in the crowd in case I managed to see them afterwards, and started thinking about the behavioural patterns below (disclaimer: obviously, I'm not a psychologist), some of which seem equally applicable to workplace situations.

Stages of acceptance and information desire

Disbelief: waiting to be told several times in case the officer and tannoy announcements aren't really serious. The choruses of "tcha" and "gah!" and "typical" that progress through the crowd. (Is there a Kübler-Ross progression of denial, rage and later acceptance at work here?) There's an irritable obedience, as if the inconvenience is deliberately and personally targeted at us. And that obedience is minimal  - "No, keep moving back please, further back".

There's a profound information need: people want a lot of info and context, immediately and continuously. Desire to manage/minimise uncertainty/danger (and to be reassured); it's also a participatory voyeurism. If we're going to be held up and miss the plane, we want it to be something good rather than a false alarm (also because this legitimises the officials).

Authority and gossip

Officials should be omniscient: we assume they all have total information. Police and officials need an air of calm authority - they should and would never say "I don't know what the situation is". That they're bristling with kit and guns helps. But where there's an insufficiency of information, gossip and rumour necessarily emerge spontaneously. A police officer turns to another and murmurs, and we strain like night-time deer to catch and sift the sounds. News provision: many of us call or text friends to share news, boast of hardship or solicit sympathy.

Copying: if one officer stands at the border answering questions, then they'll get a steady stream of people all asking what's going on - we lurch forward, twitching that we might not be left out of the loop. (Here is where a constant broadcast of information, either over a tannoy or via mobile, would be useful. Except that often there is no news to convey.)

An hour in, there's a sound exactly halfway between a gun shot/explosion and something heavy crashing into a large metal object like a skip. Perhaps this is the destruction of the suspect package. It's an obvious sound, but none of the police react to it at all.

Herding and positioning

Herding/clustering of people: together generally. In areas of perceived value: closer to terminal (ultimate goal, minimal effort), closer to the action (immediate goal: info - again, the psychological benefits - curiosity/rubbernecking, gossip, privilege), out of rain, near seats (comfort for longer waits),  local gatherings: families, friends, people that are identified as similar. Is there an unconsciously ethnic/sociodemographic herding happening? Grudging retreat, as a herd, if a valuable area is devalued by police officers pushing people further back.

We're shooed further away from the terminal by the police, into a space usually used only for the regulated movement of cars and buses - on foot it's a no-place, the interzone. We're held here as if this vehicle corridor is a real place, outside a processing space attached to the aerial corridor.

An awareness that when the evacuation is over there will be a rush: hence positioning is important. The Dunkirk spirit is very mild at best. We're too put out by the delay, and too aware that when movement is restored, it's a zero-sum game at the bottlenecks. That awareness is like a background hum.

Advantage and prestige

The hum, that awareness - a crowd throb. Heightened awareness of factors that confer power, privilege, position or prestige. When some people move forward it's contagious: no-one wants to be demoted in position. We watch the officials closely for indicators. We're gradually jostling for position.

There's a casual swaggering from those that are official or quasi-official (seen it all before... I am apart from the crowd...) - they have a carefree world-weariness as a defence mechanism: I'm good enough that can afford not to pay attention or look alert. As a counter to this ploy, I find myself immediately imagining offering help to the police on the dubious credentials that my company does some IT for police services - it's a clear desire to separate myself from the herd.

Correspondingly, a just-perceptible hierarchy is being expressed amongst the officials: passengers < airport staff < staff with badges < staff with uniforms < police < police with small guns or in small vehicles < police with big guns/in big vehicles < specialist police with unusual uniforms or sniffer dogs < the unseen police commanders in the radios...

Taxiing and takeoff

A pair of false starts: staff go back into the building, but many of us assume that passengers can move too. These movements starts others off too. Then, an after shock: as we prepare to head back in, there are police radio rumours of another device, and we are held up another ten minutes. (How many of us are thinking of Ballard, and casting off our raiments of civilisation and rising up in a tide against the thin blue line of police and airport officialdom? Or worse, that we'll never leave, and will become tribes of T3.)

Later, as the all-clear is confirmed, there's the extraordinary sound of a thousand luggage trolleys setting off and accelerating across rough tarmac all at once: a stampede.