Noise Over Spatial Information

Wireless Mobile Agents and the Internet of Things

Wireless Collaboration for First Responders, a white paper authored by Drakontas talks about the challenge of making a variety of communnications devices, databases, and information resources interoperable and evaluate in a non disruptive fashion in established organizations. Drakontas believes that networks should be built vertically (ad-hoc mode) “mesh or Mobile Ad Hoc Network (MANET)) and that mobile intelligent agents would be responsible for carrying information from one computing or communications device to another. These types of agents are task driven and network-aware. That is agents that can adapt their behavior based on their own knowledge about the state of the underlying network, and thus, alter its behavior based on information about the state of the network.

Drakontas is in the process of developing collaborative situation awareness capabilities such as agent based interactive whiteboards and GPS mapping, that can function across multiple handheld devices without the need centralized resources.

Extending the context of this white-paper to the Internet of Things is inspiring, because it address 2 challenges, namely scale and interoperability. Ad-hoc networks scale and agents can adapt to their hosts. Back in my engineering student days, I built such mobile “intelligent” agents.

In the context of blogjects, there is mention of objects and flocks creating “meaning”. However, they could transfer this burden to their agents. An agent task being to report on relevant information to its owner (an object, a blog, a pet, a human, …). An agent learns the topology of the networks, they are network-aware. An agent evolute and mutate. Instead of communicating information, devices could become more passive and transfer their communication skills to agents who know best. In the future, the Internet could uniquely transport ever-evolving task-driven “instances” carrying data.

Plazes + Nabaztag

I quickly hooked the Plazes API with the Nabaztag API to make Supongo frequently “aware” of my “Plazes”. Well, at least he gets excited whenever I change location. I’ll probably make it bitch about his hard day whenever I move to “BCN home”. Next step would be to make Supongo aware of the movements of my “Plazes’ buddies” and to gossip about them.

Relation to my thesis: I am a geek

Mobile Apache Web Server

Nokia Research has come up with a port of the Apache web server for their smartphones (should work on any S60 2nd Edition Feature Pack 2 based device and upward). Developing any kind of server on a mobile phone does not represent any technical issue (e.g. providing BT services, used to bring GSM footprints to a MIDlet level, …). However, the biggest achievement I see in Nokia’s work is on making the device reachable from the Internet:

Providing access to a mobile phone from the Internet is not straightforward, as operators typically employ firewalls that prevent access from the Internet to phones inside that firewall. By implementing a custom gateway we could circumvent that limitation and we are now able to provide a webserver on a mobile phone with a global URL than can be accessed from any browser. In a sense, the mobile phone has now finally become a full member of the Internet.

I am not sure how they do the trick with heir custom gateway. They built a “connector” that together with a gateway provides a mobile phone with a global name in the operator networks of today. Currently I only see it to be of dynamic IP mapping services used back in the dial-up days. This can be done via a the PushRegistry in J2ME and publishing the inbound connection.

Relation to my thesis: Putting Internet accessible servers (web or others) on mobile devices changes the mobile information flow and is a clear step forward an Internet of things. Location information could be both push and pulled. Pull, allows custom remote interaction with the device as well as accessing some elements of the device’s context (network data (e.g. cellid), usage, and access to core data. I surely should prepare a prototype for the upcoming Blogjetct “hands-on” workshop.

Design Patterns for Ubiquitous Computing

James A. Landay, Gaetano Borriello, “Design Patterns for Ubiquitous Computing,” Computer, vol. 36, no. 8, pp. 93-95, Aug., 2003.

Design patterns offer a solution to the difficult problem of reusing prior reusing prior design knowledge. The author propose to introduce patterns in ubicomp to offer a way to communicate solutions to design problems. Design patterns emerged from the work of Christopher Alexander in the 70s (A Pattern Language: Towns, Building, Construction. Alexander proposed for example the Beer Hall pattern considering the following problem: “Where can people sing, and drink, and shout and drink, and let go of their sorrows?” The resolution would be:

Somewhere in a community at least one big place where a few hundred people can gather, with beer and wine, music, and perhaps a half-dozen activities, so that people are continuously cris-crossing from one to another.

Some efforts in documenting lessons already learned in ubicop have taken place in Chart of Patterns in Ubiquitous and Context Computing and evaluation reported in the paper:

Eric Chung, Jason I. Hong, James Lin, Madhu K. Prabaker, James A. Landay, and Alan L. Liu. Development and Evaluation of Emerging Design Patterns for Ubiquitous Computing. In Proceedings of Designing Interactive Systems (DIS2004), 2004.

Relation to my thesis: The “gang of four” made a impact on software engineering by formalizing “best practices”. Ubicomp might need such a milestone and “mature” from implication for design to design patterns. It related to Everyware‘s Thesis 57 refering that the proper ubicomp design convention do not exsist yet:

As designers, we simply don’t yet know how to discuss these issues, not with each other, not with our clients, and especially not with the people using the things we build.

An output of my thesis could land in the ubicomp design patterns field.

Slides of User Interface Design Labs

Teaching user interface design in spanish is a challenge… The slides of my first 3 labs are below:

Lab 1: Introduction. Preparatory work: select an interface to design, and one similar that already exists

Lab 2: Questionnaire. Development of a user questionnaire; evaluation of a similar interface; preparation of the results analysis.

Lab 3: Contextual Design. Not taught by me

Lab 4: Usage-centered Design. Apply the user-centered design methodology: Model of the role, task and content.

Lab 5: Keystroke-level Model: Focus on the details, evaluate the user’s cognitive load, use the Keystroke-Level Model

Lab 6: Interface development: Design and rapid prototyping of the interface

Nabaztag

Out of social pressure a nabaztag finally entered my home. The API is very simple and rather limited (restricted to input actions). To go beyond that, the protocol is decrypted here and there is an open source proxy.

Make Supongo laugh, insult me and complain. Unfortunately you cannot make it sneeze and cough yet…

Like the L’arbre atchoum, it should be disrupting and show character.

Peaceful Cohabitation and Scalability in Ubicomp

Radar detectors normally cover all the frequencies that police use for their radar. Any detector will detect an active source within a certain range. I was told this weekend that sometimes wrong alarm are caused by gas stations’ security system, often confusing the drivers. Moreover, 4 years ago the radar detector launched devices that created interference problems with gas stations (interference at pay-at-the-pump credit card terminals resulting in lost or incorrect sales), fast-food outlets, convenience stores. (causing music and advertisements to skip or mute), small airports (several private pilots have been unable to get weather updates because of radar detectors in airport employees’ cars parked nearby). Source: New radar detectors zing small satellite systems.

Relation to my thesis: Setting ubicomp applications free to the real-world will challenge the peaceful cohabitation of systems. Hence creating confusion, uncertainty and errors. I share the same concerns over ubicomp and scalability as Adam Greenfield puts mentions in his conversation in progress over at the Well.

But I’m not sure how many people in academic ubicomp have really marinated themselves in a consideration of the experiential and affective dimensions of system failure. I’m not sure to what degree people have ever simply sat and imagined what it will feel like when systems like these surround us…and break down, as technical systems often do. They may have thought about the specific system at hand, but as a gestalt? I haven’t heard that many people raising the issue.

Back From Wired Geneva