Sunday 28 July 2013

The uses of email

The success and failure of email arises from its versatility. We use it for purposes that it's imperfectly designed for, but as it's "good enough" we continue to use it despite the inefficiency.

To design the post-email world it's important to understand what functions email currently covers. At a high level, here's what I think email covers:

  • Transmitting information (to one, or to many)
  • Assigning a task (which can include the provision of information via a reply)
  • Arranging meetings (physical, voice, video)

Within each of these broad categories, there are numerous subcategories. Commonly assigned (or requested) tasks include:

  • Reply with information
  • Review and provide sign-off/approval
  • Comment on or modify document (document collaboration)

Types of information transmission include:

  • Passing on news (information on what has happened)
  • Passing on plans (information on what is intended to happen)
  • Making a suggestion
  • Offering an opinion

There are some niche cases, which overlap with the three broad areas listed above:

  • Telling someone you're going to do something: i.e. assigning yourself a task, and communicating it some a group of people
  • Compound emails: e.g. assigning a task, and providing information in one email

Calendar and task management systems are pretty well advanced, although the integration of the latter with email is frequently limited. However, on the information provision side, much of the information that is to be transmitted should be stored in databases.

It's worth noting that there's a cultural issue to overcome around people assigning tasks to other people. Whilst asking politely for information is an email is culturally acceptable, raising a task for someone to provide information appears more demanding, and more too.

Monday 22 July 2013

A couple of thoughts on the hive mind

Hive mind or better communication?

I put to myself today the argument that the root cause of the problems we have in society are not the result of separate individuals with their own separate agendas and motivations, but of the inadequacy of the communication between them, and perhaps to an extent the ability of those individuals to empathise/care when the information is passed to them.

The first of these problems is readily observable: our language is crude and we get nowhere close to communicating to one another the true nature of our experiences. There is also an interesting philosophical point on our ability to experience the experiences of others (see qualia for further information on subjectivity of experience). If we can improve communication, will we also need to improve empathy? Is the reason that the person watching the advert on TV raising money for famine victims in Africa who is not moved to act a problem of communication (the fact that the person is not truly experiencing the experience of the famine victims), or is it one of detached uncaring?

If it is a question of better communication, can this problem be addressed? Perhaps we are already addressing it. The world is better connected than it used to be thanks to communication technologies such as mobile phones and the Internet. But then much of the communication on texts and tweets is arguably not the deep interpersonal connection that we need to forge a better world.

The next paradigm in communications is brain-to-machine. And with it brain-to-machine-to-brain. We will have the potential to share our experiences directly. Such understanding of the perspectives of others that we will be able to get will profoundly shape the way we organise the world.

Where does the hyper-connected collection of individuals stop and the hive mind start?

The concept of the hive mind is to me about conformity. A singular intelligence acting in unison with no dissent. A top-down strategy. But do we begin to see the properties of the hive mind in the absence of top-down authority, just through the hyper-connectedness of individuals?

"No", in the sense that individuals still have the freedom to act. But potentially "yes" in the sense that each individual will potentially be able to know how an action will be judged by every other person in advance of the action, and hence will conform if the potential action is seen in a negative light.

Diversity in a hive mind

If we end up as a top-down hive mind, we will be at risk of a monoculture-of-the-mind that does not have the diversity of perspective to adapt to unforeseen events. How can this be addressed? It is possible that the hive mind can create intellectual sandboxes within itself, where such sandboxes have the ability to explore lines of thinking (and irrationality) that would be impossible within the core of the hive mind.

Are such sandboxes enough to benefit from the inherent qualities of diversity?

So much to know... but reducing value in actually knowing it?

As the extent of domain-specific knowledge increases at a near-exponential rate, it may be the case that the relative value of knowledge to the ability to obtain knowledge, or the ability to make relationships, reduces. The information age does to prize people who know, but learners and connections-brokers.

Monday 15 July 2013

Unified task management

How will task management look in the future? Hopefully better than it looks today. Here's some of the pitfalls of today's approach, and how current/future technology can help.

Tasks are currently allocated to people in the following ways:

  • Via a workflow system (the good way)
  • Via email
  • Via face-to-face conversation
  • Via telephone conversation (or voicemail)
  • Via meetings (whether the task recipient is present or not)
  • Via written communication
There are probably some more obscure media (e.g. text message), but I think the above captures it.

The tasks an individual has assigned (i.e. has to do themselves) and is tracking (i.e. is waiting for someone else to do) are stored in the following ways:
  • In memory
  • On a notepad (or worse, multiple notepads)
  • In an email inbox
  • In a workflow system
  • In a voicemail inbox
  • In a spreadsheet
  • In a to do list application (although this typically stores "to dos" and not actions outstanding from another
Other challenges include:
  • Cross-system incompatibility
  • Linking task data with other meaningful data (e.g. customer records)
  • The ability for multiple people to track a single task
  • The ability for an action recipient to carve up a task into sub-tasks to be delegated
  • The ability for task recipients to mark tasks as having a dependency on another task, and for the task issuer to have visibility for this
The real challenge is getting all tasks into a single database. Once they're there, everything else is a matter of good database design, reporting and management (and a good UI to access the data). Here's some thoughts on how to get tasks into the database:
  • Adding tasks to email composition: this already exists but is not widely used (in my experience) largely on cultural grounds, but potentially also to do with a lack of interface/API into workflow systems; there needs to be some kind of natural language understanding that identifies that the composer of the email is issuing a task and prompts the composer to formalise the task (e.g. recipient, date required by, etc)
  • Speech recognition by always-on mics on smartphones combined with natural language understanding could be used to identify tasks being issued and add these automatically to the database. This technique is applicable to phone calls, face-to-face conversations, meetings and voicemail messages.
If the above two are addressed, the workflow system will become such a routine part of day-to-day working life that people will automatically use these tools or add tasks manually to the workflow system as required.

And then we'll all feel like automations in a giant delivery chain...

Monday 1 July 2013

A thought on databases

Relational databases can become complex quickly due to the number of tables required to map all the relationships. It occurs to me that a simple structure might look as follows:
  • 1 table for each class of data (where each record will share the same fields)
  • 1 table defining relationships (recording the definition of the relationship between records)
  • 1 relationship table (recording all the relationships)
Under this model, the number of database tables would be equal to the number of classes of data + 2.

Here's a simple example to illustrate the point:

Relationship table
ID Class Relationship ID ID Class
1618 People 7348 1234 Company
9371 People 0829 5678 Company

Companies table (a class of data about companies)
ID Company name Company registration number
1234 Blob inc. 555-666
5678 Yodle inc. 314159

People table (a class of data about people)
ID First name Second name
1618 Albus Dumbledore
9373 Michael Jackson

Defining relationships table
ID Relationship name
0829 is employee of
7348 is shareholder of

This structure should facilitate all of the necessary queries. For example, a query of all the employees of a company.

A key feature is the directionality of the relationship: i.e. from A to B.

Information that products can transmit

I wrote yesterday on what I want from a battery charger, which touched on the subject of what information products can collect and transmit. It's a very broad topic, but fundamentally only limited by the following factors:

  • available sensors
  • available transmitters
  • power for sensors and transmitters
  • storage of data (prior to transmission)
  • cost (of the above, and of bandwidth)
  • value of the data to the manufacturer
  • consumer acceptance
So let's take another example product: the electric shaver. Probably the first most important sensor is a clock, allowing the frequency of use, time of day and duration of use to be captured. This might be supplemented by a gyroscope to measure the angles the shaver is moved through during use. And perhaps also a GPS sensor assess whether it's used as a travelling shaver, or just one left at home. Other data collected could include what buttons are pressed and when, charging patterns, and potentially data on component failure. From a transmitter point-of-view, wifi and Bluetooth are obvious and ubiquitous (and typically free at point of use), but these do require input from users, so perhaps a cellular network chip would be a better alternative. Obviously a shaver already has power (either from the wall or battery), so this is only an issue in that it might drain the battery faster. A clock  is so cheap to implement that it's immaterial to the cost of the device. The storage (a few megabytes of ssd) is also pretty low cost, as is the cellular chip and bandwidth. So in conclusion for a shaver, basic monitoring is doable from a technology and cost point of view. The only remaining issues are the value of the data to the manufacturer, and consumer acceptance. The value of the data is probably fairly low, but as the cost of the components drop and drop, this the value relative to cost will tend to increase. Consumer acceptance is a whole discussion in itself.

The electric shaver proved a fairly easy product to analyse from a product self-reporting point-of-view. So let's try something a little more challenging: a tube of toothpaste. The obvious challenge here is the absence of power. However, that's not necessarily a show-stopper due to cheap disposable solar cells, piezoelectric generators and passive near-field communication. So what could be measured? Time again is an important one, with the other key metric being degree of deformation of the tube or the degree that the sides of tube touch each other (both being proxies for the amount of toothpaste left in the tube). Although there might be enough power to collect and record the data, sufficient data to power a wifi or Bluetooth chip is unlikely. However, with a near filed communication chip, the communication could occur to a smartphone when in range, and then the data would be passed onwards to the manufacturer via the internet.

If it's possible to do it with a tube of toothpaste, it should be possible with just about any product. Bring on the Internet of Things.