Archive

Ubiquitous computing

Quick work thing. We’ve working with Chromecast for a little while.

Chromecast is basically a chrome browser on a stick that plugs into the back of your telly using the HDMI port and once connected to your wifi can be controlled by almost anything else on that network – phone, tablet, ‘puter.

It’s the sort of cheap, accessible tech that is really worth examining for opportunities – like the hacks we did with the Cooper-Hewitt – or this: Photowall for Chromecast.

It’s introduced in this video by m’colleagues George and Justin who first prototyped it and helped usher it into the world.

The SDK is out there – have at it.

I really enjoyed Andrew’s book. I thought I knew about the structure (and structures) of the Internet, but this is is a detailed, critical and fun illumination which quickly proved me mistaken. It’s also a travel book, about an unreal place that spans/permeates real places, lives, spaces. And a wonderful one at that. Highly recommended.

(My emboldening below)

Everything you do online travels through a tube. Inside those tubes (by and large) are glass fibers. Inside those fibers is light. Encoded in that light is, increasingly, us. [Location 94]

The Internet is everywhere; the Internet is nowhere. But indubitably, as invisible as the logical might seem, its physical counterpart is always there. [Location 276]

TeleGeography in Washington was asking a computer science department in Denmark to show how it was connected to a university in Poland. It was like a spotlight in Scandinavia shining on twenty-five hundred different places around the world, and reporting back on the unique reflections. [Location 418]

You can demarcate a place on a map, pinpoint its latitude and longitude with global positioning satellites, and kick the very real dirt of its very real ground. But that’s inevitably going to be only half its story. The other half of the story comes from us, from the stories we tell about a place and our experience of it. [Location 485]

“If you brought a sophisticated customer into the data center and they saw how clean and pretty the place looked—and slick and cyberrific and awesome—it closed deals,” said Adelson. [Location 1211]

But it wasn’t the machine’s mystery or power that terrified Adams most. It was how clearly it signified a “break of continuity,” as he puts it. The dynamo declared that his life had now been lived in two different ages, the ancient and the modern. It made the world new. [Location 1826]

He counted off the zeros on the screen. “This point is the millisecond … this point is the microsecond … and this one is usually expressed as nanoseconds, or billionths of a second.” I mulled all the zeros on the screen for a moment. And when I looked up, everything was different. The cars rushing by outside on Highway 87 seemed filled with millions of computational processes per second—their radios, cell phones, watches, and GPSs buzzing inside of them. Everything around me looked alive in a new way: the desktop PCs, the LCD projector, the door locks, the fire alarms, and the desk lamps. [Location 2045]

Nearly universally, they wore black T-shirts and zip-up hooded sweatshirts, handy for spending long hours on the hard floor of the server rooms, facing the dry exhaust blast of an enormous router.[ocation 2378]

The Internet “cloud,” and even each piece of the cloud, was a real, specific place—an obvious reality that was only strange because of the instantaneity with which we constantly communicate with these places. [Location 3159]

The Internet had no master plan, and—aesthetically speaking—no master hand. There wasn’t an Isambard Kingdom Brunel—the Victorian engineer of Paddington Station and the Great Eastern cable ship—thinking grandly about the way all the pieces fit together, and celebrating their technological accomplishment at every opportunity. On the Internet there were only the places in between, places like this, trying to disappear [location 3183]

The emphasis wasn’t on the journey; the journey pretended not to exist. But obviously it did. [location 3186]

“Want to see how this shit really works?” he asked. “This has nothing to do with clouds. If you blew the ‘cloud’ away, you know what would be there?” Patchett asked. “This. This is the cloud. All of those buildings like this around the planet create the cloud. The cloud is a building. It works like a factory. Bits come in, they get massaged and put together in the right way, then packaged up and sent out. But everybody you see on this site has one job, that’s to keep these servers right here alive at all times.” [location 3268]

“If you lose rural America, you lose your infrastructure and your food. It’s incumbent for us to wire everybody, not just urban America. The 20 percent of the people living on 80 percent of the land will be left behind. Without what rural America provides to urban America, urban America couldn’t exist. And vice versa. We have this partnership.” [location 3299]

Ben Bashford’s writing about ‘Emoticomp‘ – the practicalities of working as a designer of objects and systems that have behaviour and perhaps ‘ intelligence’ built-into them.

It touches on stuff I’ve talked/written about here and over on the BERG blog – but moves out of speculation and theory to the foothills of the future: being a jobbing designer working on this stuff, and how one might attack such problems.

Excellent.

I really think we should be working on developing new tools for doing this. One idea I’ve had is system/object personas. Interaction designers are used to using personas (research based user archetypes) to describe the types of people that will use the thing they’re designing – their background, their needs and the like but I’m not sure if we’ve ever really explored the use of personas or character documentation to describe the product themselves. What does the object want? How does it feel about it? If it can sense its location and conditions how could that affect its behaviour? This kind of thing could be incredibly powerful and would allow us to develop principles for creating the finer details of the object’s behaviour.

I’ve used a system persona before while designing a website for young photographers. The way we developed it was through focus groups with potential users to establish the personality traits of people they felt closest to, trusted and would turn to for guidance. This research helped is establish the facets of a personality statement that influenced the tone of the copy at certain points along the user journeys and helped the messaging form a coherent whole. It was useful at the time but I genuinely believe this approach can be adapted and extended further.

I think you could develop a persona for every touchpoint of the connected object’s service. Maybe it could be the same persona if the thing is to feel strong and omnipresent but maybe you could use different personas for each touchpoint if you’re trying to bring out the connectedness of everything at a slightly more human level. This all sounds a bit like strategy or planning doesn’t it? A bit like brand principles. We probably need to talk to those guys a bit more too.

Which I’ve written a little bit more about over at the S&W Pulse Laser.

I felt I rushed the talk, which was probably not wise as I was giving it in English to an Italian audience, but there’s stuff in there I want to dig into further in the coming months for sure. If you for some reason feel the need to punish yourself and want to see my lack-lustre performance it’s captured forever here, but deep thanks to (most of) the audience for indulging me and not falling asleep or wandering off chatting into the gorgeous Italian sunshine… I know I would have…

The concept of “Thingfrastructure” in the talk is something I’ve found myself scribbling in the margins of my moleskine for a few months now, and it’s something I want to come back to: resilience in services, especially when connected to things – and whether it’s possible to design ‘things’ that generate resilient services for themselves. I think it’s been in the back of my mind since Ryan Freitas gave an excellent talk on the subject at MX last year in San Francisco. Anyway – as I say, I’ll keep scribbling, and hopefully others will too.

Thanks very much indeed to Leander, Matteo, Manuela and all the team behind Frontiers for the kind invitation to speak and a wonderful time in Rome.

UPDATE:
The good folk at Adaptive Path have pointed out that (unbeknownst to me) Brandon Schauer was walking this path a few months ago. He’s a smart cookie is Brandon.

Apple’s iPhone 3.0 announcements caused a kerfuffle today, but it seems to me insane that the thing that’s being talked about most is… Cut and Paste?

At the time the event was running I summed my feelings up in <140 chars thusly:

Twitter / Matt Jones: of course, while I'm shaki ...

I mean – they’d announced that you could create custom UIs that worked with physical peripherals – they’d had someone from Johnson & Johnson on stage to show a diabetes sensor companion to the iphone – the nearest thing to AP’s Charmr you could imagine!

Then my friend Josh said:

“Am now wondering whether a bluetooth/serial module and arduino will be able to talk with iPhone. And, pachube

A rapid prototyping platform for physical/digital interactions? A mobile sensor platform for personal and urban informatics that’s going mainstream?

Imagine – AppleStores with shelves of niche, stylish sensor products for sale in a year’s time – pollution sensors, particulates analysis, spectroscopy, soil analysis, cholesterol? All for the price of a Nike+ or so?

Come on, that’s got to be more exciting than cut and paste?

—–
UPDATE

Tom Igoe points out in his comment correctly that I have been remiss in not mentioning Tellart’s NadaMobile project from late last year – which allows you to easily prototype physical/digital/sensor apps on the iPhone through a cable that cleverly connects to the audio jack. It’s also totally open-source.

Reblog this post [with Zemanta]

Warning – this is a collection of half-formed thoughts, perhaps even more than usual.

I’d been wanting to write something about Google Latitude, and other location-sharing services that we (Dopplr) often get lumped in with for a while. First of all, there was the PSFK Good Ideas Salon, where I was thinking about it (not very articulately) then shortly after that Google Latitude was announced, in a flurry of tweets.

At the time I myself blurted:

twitter-_-matt-jones_-i-still-maintain-perhaps

My attitude to most Location-Based Services (or LBS in the ancient three-letter-acronymicon of the Mobile Industry) has been hardened by sitting through umpty-nine presentations by the white-men-in-chinos who maintain a fortune can be made by the first company to reliably send a passer-by a voucher for a cheap coffee as they drift past *bucks.

It’s also been greatly informed by working and talking with my esteemed erstwhile colleague Christopher Heathcote who gave a great presentation at Etech (5 years ago!!! Argh!) called “35 ways to find your location“, and has both at Orange and Nokia been in many of the same be-chino’d presentations.

me_home_work1Often, he’s pointed out quite rightly, that location is a matter of routine. We’re in work, college, at home, at our corner shop, at our favourite pub. These patterns are worn into our personal maps of the city, and usually it’s the exceptions to it that we record, or share – a special excursion, or perhaps a unexpected diversion – pleasant or otherwise that we want to broadcast for companionship, or assistance.

Also, most of the time – if I broadcast my location to trusted parties such as my friends, they may have limited opportunity to take advantage of that information – they after all are probably absorbed in their own routines, and by the time we rendevous, it would be too late.

Location-based services that have worked with this have had limited success – Dodgeball was perhaps situated software after all, thriving in a walkable bar-hopping subculture like that of Manhattan or Brooklyn, but probably not going to meet with the same results worldwide.

This attitude carried through to late 2006/early 2007 and the initial thinking for Dopplr – that by focussing on (a) nothing more granular than cities-as-place and days-as-time and (b) broadcasting future intention, we could find a valuable location-based service for a certain audience – surfacing coincidence for frequent travellers.

Point (a): taking cities and days as the grain of your service, we thought was the sweet-spot. Once that ‘bit’ of information about the coincidence has been highlighted and injected into whichever networks you’re using, you can use those networks or other established communications methods to act on it: facebook, twitter, email, SMS or even, voice…

“Cities-and-days” also gave a fuzziness that allowed for flexibility and, perhaps plausible deniablity – ameliorating some of the awkwardness that social networks can unitentionally create (we bent over backwards to try and avoid that in our design decisions, with perhaps partial success)

In the latest issue of Wired, there’s a great example of the awkward situations broadcasting your current exact location could create:

“I explained that I wasn’t actually begging for company; I was just telling people where I was. But it’s an understandable misperception. This is new territory, and there’s no established etiquette or protocol.

This issue came up again while having dinner with a friend at Greens (37.806679 °N, 122.432131 °W), an upscale vegetarian restaurant. Of course, I thought nothing of broadcasting my location. But moments after we were seated, two other friends—Randy and Cameron—showed up, obviously expecting to join us. Randy squatted at the end of the table. Cameron stood. After a while, it became apparent that no more chairs would be coming, so they left awkwardly. I felt bad, but I hadn’t really invited them. Or had I?”

It also seemed like a layer in a stack of software enhancing the social use and construction of place and space – which we hoped would ‘handover’ to other more appropriate tools and agents in other scales of the stack. This hope became reinforced when we saw a few people taking to prefacing twitters broadcasting where they were about to go in the city as ‘microdopplr‘. We were also pleased to see the birth of more granular intention-broadcasting services such as Mixin and Zipiko, also from Finland

This is also a reason that we were keen to connect with FireEagle (aside from the fact that Tom Coates is a good friend of both myself and Matt B.) in that it has the potential to act as a broker between elements in the stack, and in fact help, weave the stack in the first place. At the moment, it’s a bit like being a hi-fi nerd connecting hi-specification separates with expensive cabling (for instance, this example…), but hopefully an open and simple way to control the sharing of your whereabouts for useful purposes will emerge from the FE ecosystem or something similar.

Point (b) though, still has me thinking that sharing your precise whereabouts – where you are right now, has limited value.

lightcone_slideThis is a slide I’ve used a lot when giving presentations about Dopplr (for instance, this one last year at IxDA)

It’s a representation of an observer moving through space and time, with the future represented by the ‘lightcone’ at the top, and the past by the one at the bottom.

I’ve generally used it to emphasise that Dopplr is about two things – primarily optimising the future via the coincidences surfaced by people sharing their intended future location with people they trust, and secondly, increasingly – allowing you to reflect on your past travels with visualisations, tips, statistics and other tools, for instance the Personal Annual Reports we generated for everyone.

It also points out that the broadcasting of intention is something that necessarily involves human input – it can’t be automated (yet)- more on which later.

By concentrating on the future lightcone, sharing one’s intentions and surfacing the potential coincidences, you have enough information to make the most of them – perhaps changing plans slightly in order to maximise your overlap with a friend or colleague. It’s about wiggling that top lightcone around based on information you wouldn’t normally have in order to make the most of your time – at the grain of spacetime Dopplr operates at.

Google Latitude, Brightkite and to an extent FireEagle have made mee think a lot about the grain of spacetime in such services, and how best to work with it in different contexts. Also, I’ve been thinking about cities a lot, in preparation for my talk at Webstock this week – and inspired by Adam‘s new book, Dan’s ongoing mission to informationally refactor the city and the street, Anne Galloway and Rob Shield’s excellent “Space and culture” blog and the work of many others, including neogeographers-par-excellance Stamen.

I’m still convinced that hereish-and-soonish/thereish-and-thenish are the grain we need to be exploring rather than just connecting a network of the pulsing ‘blue-dot’.

Tom Taylor gave voice to this recently:

“The problem with these geolocative services is that they assume you’re a precise, rational human, behaving as economists expect. No latitude for the unexpected; they’re determined to replace every unnecessary human interaction with the helpful guide in your pocket.

Red dot fever enforces a precision into your design that the rest must meet to feel coherent. There’s no room for the hereish, nowish, thenish and soonish. The ‘good enough’.

I’m vaguely tempted to shutdown iamnear, to be reborn as iamnearish. The Blue Posts is north of you, about five minutes walk away. Have a wander around, or ask someone. You’ll find it.”

My antipathy to the here/now fixation in LBS lead me to remix the lightcone diagram and post it to flickr, ahead of writing this ramble.

The results of doing so delighted and surprised me.

Making the most of hereish and nowish

In retrospect, it wasn’t the most nuanced representation of what I was trying to convey – but it got some great responses.

There was a lot of discussion around whether the cones themselves were the right way to visualise spacetime/informational futures-and-pasts, including my favourite from the ever-awesome Ben Cerveny:

“I think I’d render the past as a set of stalactites dripping off the entire hypersurface, recording the people and objects with state history leaving traces into the viewers knowledgestream, information getting progressively less rich as it is dropped from the ‘buffers of near-now”

Read the entire thread at Flickr - it gets crazier.

But, interwoven in the discussion of the Possibility Jellyfish, came comments about the relative value of place-based information over time.

Chris Heathcote pointed out that sometimes that pulsing blue dot is exactly what’s needed to collapse all the ifs-and-buts-and-wheres-and-whens of planning to meet up in the city.

Blaine pointed out that

“we haven’t had enough experience with the instantaneous forms of social communication to know if/how they’re useful.”

but also (I think?) supported my view about the grain of spacetime that feels valuable:

“Precise location data is past its best-by date about 5-10 minutes after publishing for moving subjects. City level location data is valuable until about two hours before you need to start the “exit city” procedures.”

Tom Coates, similarly:

“Using the now to plan for ten minutes / half an hour / a day in the future is useful, as is plotting and reflecting on where you’ve been a few moments ago. But on the other hand, being alerts when someone directly passes your house, or using geography to *trigger* things immediately around you (like for example actions in a gaming environment, or tool-tips in an augmented reality tool, or home automation stuff) requires that immediacy.”

He also pointed out my prejudice towards human-to-human sharing in this scenario:

“Essentially then, humans often don’t need to know where you are immediately, but hardware / software might benefit from it — if only because they don’t find the incoming pings distracting and can therefore give it their full and undivided attention..”

Some great little current examples of software acting on exact real-time location (other than the rather banal and mainstream satnav car navigation) are Locale for Android – a little app that changes the settings of your phone based on your location, or iNap, that attempts to wake you up at your rail or tube stop if you’ve fallen asleep on the commute home.

But to return to Mr. Coates.

Tom’s been thinking and building in this area for a long time – from UpMyStreet Conversations to FireEagle, and his talk at KiwiFoo on building products from the affordances of real-time data really made me think hard about here-and-now vs hereish-and-nowish.

Tom at Kiwifoo

Tom presented some of the thinking behind FireEagle, specifically about the nature of dealing with real-time data in products an services.

In the discussion, a few themes appeared for me – one was that of the relative-value of different types of data waxing and waning over time, and that examining these patterns can give rise to product and service ideas.

Secondly, it occured to me that we often find value in the second-order combination of real-time data, especially when visualised.

Need to think more about this certainly, but for example, a service such as Paul Mison’s “Above London” astronomical event alerts would become much more valuable if combined with live weather data for where I am.

Thirdly, bumping the visualisation up-or-down a scale. In the discussion at KiwiFoo I cited Citysense as an example of this – which Adam Greenfield turned me onto –  where the aggregate real-time location of individuals within the city gives a live heatmap of which areas are hot-or-not at least in the eyes of those who participate in the service.

From the recent project I worked on at The Royal College of Art, Hiromi Ozaki’s Tribal Search Engine also plays in this area – but almost from the opposite perspective: creating a swarming simulation based on parameters you and your friends control to suggest a location to meet.

I really want to spend more time thinking about bumping things up-and-down the scale: it reminds me of one of my favourite quotes by the Finnish architect Eliel Saarinen:

demons029

And one of my favourite diagrams:

brand_keynote_400

It seems to me that a lot of the data being thrown off by personal location-based services are in the ‘fashion’ strata of Stewart Brand’s stack. What if we combined it with information from the lower levels, and represented it back to ourselves?

Let’s try putting jumper wires across the strata – circuit-bending spacetime to create new opportunities.

Finally, I said I’d come back to the claim that you can’t automate the future – yet.

twitter-_-matt-jones_-kiwifoo-plasticbaguk_sIn the Kiwifoo discussion, the group referenced the burgeoning ability of LBS systems to aggregating patterns of our movements.

One thing that LBS could do is serve to create predictive models of our past daily and weekly routines – as has been investigated by Nathan Eagle et al in the MIT Reality Mining project.

I’ve steered clear of the privacy implications of all of this, as it’s such a third-rail issue, but as I somewhat bluntly put it in my lightcone diagram the aggregation of real-time location information is currently of great interest to spammers, scammers and spooks – but hopefully those developing in this space will follow the principles of privacy, agency and control of such information expounded by Coates in the development of FireEagle and referenced in our joint talk “Polite, pertinent and pretty” last year.

The downsides are being discussed extensively, and they are there to be sure: both those imagined, unimagined, intended and unintended.

But, I can’t help but wonder – what could we do if we are given the ability to export our past into our future…?

Reblog this post [with Zemanta]
Can I have a … ?, originally uploaded by straup.

This Saturday saw the first-ever PaperCamp successully prototyped.

After an amount of last-minute panic, I think I stopped being stressed-out about 5 minutes into Aaron’s talk.

Instead I started to become delighted and fascinated by the strange, wonderful directions people are taking paper, printing and prototyping the lightweight, cheap connection of the digital and the physical.

Jeremy Keith did a wonderful job of liveblogging the event, and there is a growing pool of pictures in the papercamp group on flickr.

Highlights for me included the gusto that the group gave to making things with paper in a frenetic 10min session hosted by Alex of Tinker.it, Karsten‘s bioinformatic-origami-unicorn proposal, and the delightful work of Sawa Tanaka.

Also, the fact that we’ve made Craft Bioinformatic Origami Unicorns a tag on flickr has to be seen as a ‘win’ in my view.

Lots of people didn’t hear about this one as I was deliberately trying to keep it a small ‘prototype’, and also we were luckily operating as a ‘fringe’ event to the Bookcamp event that had been set up by Russell, Jeremy and James and didn’t want to take the mickey too much (thanks guys) – so apologies to those who didn’t make it.

But, the enthusiastic response means we’ll definitely be doing this again, as a bigger, open, stand-alone event, maybe in the summer, with more space, more attendees and hopefully more heavy-duty printing and papermaking activities.

The next PaperCamp is going to be in NYC in early Feb, and I hear noises there maybe one gestating in San Francisco also…

Stay tuned, paperfans…

Follow

Get every new post delivered to your Inbox.

Join 5,133 other followers