Day 3 Keynotes: session 2
Clay Shirkey (NYU) Phone as platform
NYU have been looking at use of phones in teaching;
- PacManhatten / ConQuest – 'big games' – controllers use phones to control players on a macro scale.
- dodgeball: started as a site for rating nightspots; but evolved into a more general social network. Tells you who else is where you are
- Mobjects – sqeezable controller for driving a bluetooth phone. Squidge it and it sends an SMS. Heartbeat – very similar idea.
- phone is beginning to be used as a platform rather than as a device unto itself. standardisation of comms protocols (bluetooth) is making this easier although phone mfrs are not used to 'hackers'
- Server infrastructure is the key – expose back-end data in ways which phones can use
- voice is increasingly underused.
Tom Igoe ITP / NYU
Physical computing: crossover betwen art & programming – making computer-control of phsical objects simpler. Lots of cool toys / tools, particularly in the space of communicating emotions over a network. I can't easily describe them in a blog post, so hopefully there'll be a slideshow available on the web soon…
Tom Hoffman / Tim Lauer wiki in the classroom
Teaching middle-school children. No managed file space or tech support – looked into wikis. Instiki is a ruby-based wiki that can run on a workstation / laptop. Since the school is mac-based students can use Rendezvous to discover the pages. Since the teachers run the wikis on their own laptops they can run them at home just as easily.
- Benefits: easy, responsive, completed project can be published as static HTML
- Problems: if the teacher's machine is asleep it doesn't work, not all teachers grasped that their laptop had to be in the lesson. It's not a supported technology by the LEA
Trying to get student information into the wiki is difficult because the student records are silo-ed (sound familiar ? :-)) Tim got around this by building an open-source, open-api platform for school student records: SchoolTool. SchoolTool is based around a set of ReST APIs. relationships are modelled as xlinks.
Collection action is sometimes touted as a magic bullet – the idea that and difficult problem can be solved with a large enough group of people. It is true that in the right context, a crowd can be smarter than the smartest person in it. e.g. the average of a large set of guesses about a single value ('guess the weight of the ox'), or the odds of a horse winning – with a large sample, horses with 3/1 odds win about 1/4 of the time.
Works well when the problem has single 'right' answer. Collective wisdom isn't appearing out of consensus, it arises from the variation in answers. Also there's not much interaction between each person.
Contrast with Linux: A large group work on problems but ultimately 1 person writes the code – the decision-making process is highly centralised. Or alternatively the anthill – lots of dumb agents with lots of interconnection and simple rules. However, humans are not ants. We don't do the same efficient interaction; in some scenarios the more we interact the less inteligence the group has overall.
The reasons for this are all basically Herding – 'it's better to fail conventionally than to succeed unconventionally'. People like the comfort of the crowd. Leads to 'information cascade'.
The root of all problems in the world is that man cannot simply sit by himself in his room
- Keep ties loose. Loose coupling minimises the disruptive influence of others around you.
- Keep a wide range of inputs, so that you get the maximum amount of diversity/randomness injected into the solution space.
Jon Bostrom Nokia: Mobile computing on the edge
Advantages of edge computing:
- ease of use
- dynamic evolution / low centralised control
… this is turning into a bit of a Nokia sales pitch….yawn…