The Goo Blog

Glob Design

2010-03-02T12:06:00.004+02:00

I've spent quite a while designing Globs.

Design is really about distilling the essential form and function to solve a problem space. Once the problem space is known - sometimes the design just pops out. After a lot of effort, thankfully, the design for Globs is starting to squeeze out.

During the design phase I've constantly moved up and down the following axis:

big vs small
fast vs slow
consistent vs eventually consistent
complexity vs simplicity
private vs public
flow vs interruption
creation vs copying
usability vs utility
XML vs JSON vs RPC vs HTML5
universal vs limited
and many more ....

I'm still moving the sliders on each of these dimensions - but here is what I know so far:

a Glob is a handle on a Thing - it is not the Thing itself - it just sticks to it
a Glob belongs to a Channel
a Glob has a URI in that Channel
a Glob is idempotent (we need this for calculating Karma++)
each Glob has an external SHA1 and an internal SHA1
a Glob has a summary, favicon, text icon, origin context, captured_on_time and given_to etc.
a Glob has a HTML5 Description/Payload
a Description contains actions on the underlying Thing
Channel, Context and Configuration variables can be inserted into Glob placeholders
Globs can be HTTP POSTed into the Trail of a Channel via a Sensor
Globs can arrive in the Trail in absolute time or relative time (including the future)
A Glob can be proxied from one Channel to another Channel

Along the way here are some ideas that were ruled out:

using Git as the Glob store
a Glob does not contain code itself (although it can anchor some code)
a Glob-specific templating language
tying Globs to a specific programming language or web framework
storing Globs in XML, JSON or YAML etc

So there you have it: each Channel contains a Trail of Globs which the user can traverse from the past into the future while performing actions via the Globs stuck to the underlying Things. The speed of action, while scoring karma points, with directed focus will hopefully lead the user to a state of flow.

The Goo - still alive and kicking

2010-01-06T19:24:00.008+02:00

I've spent quite a lot of time catching trains in 2009 and as a result I've had lots of time to plan the design, implementation and evolution of The Goo.

Since I started this blog there has been some convergence on what I have in mind.

The following software contains elements of what I'm planning:

Google Wave
Git
Facebook activity feed
Atom
Plagger
Plack
Perl6
PubSubHubbub
AnyEvent
Remember the Milk / ToDo systems in general
Starcraft

Can you guess which bits?

Fortunately what I have in mind is much less complicated than all of these systems. Ideally it needs to be programming language agnostic and so a spec or RFC is in order - followed quickly by a prototype in Perl.

Hopefully the prototype will get some way to helping users find 'flow'. Stay tuned in 2010.

Perceptron = Goo + Blob = Glob

2008-10-05T18:56:00.004+02:00

I'm working with Audrey Tang (of Pugs and Perl6 fame) on cleaning up the design of The Goo. One problem we identified is funky terminology which can act as a barrier to new developers.

So today during a design discussion with Audrey I decided to say goodbye to the term 'perceptron' for the more descriptive term 'blob' - but perceptrons are slightly more complicated than blobs - so Audrey suggested 'glob' as in Goo + Blob = Glob. In Perl parlance a glob is a generic handle on a thing - which fits what I'm trying to model. What's more:

Glob: 1. a drop or globule of liquid. 2. a usually rounded quantity or lump of some plastic or moldable substance

So that decided it. A Perceptron is now known as a Glob™.

Gedit - The Goo's Editor

2008-05-16T14:57:00.005+02:00

I've finally found a text editor that does syntax highlighting, word completion and starts quickly.

Gedit with the help of the word completion plugin does what I'm looking for.

1 Medal = 500 Karma++

2008-02-26T14:42:00.002+02:00

After every 500 points of karma++ you now receive a medal!

I scored my first medal a couple of weeks ago. Now it's really starting to feel like playing a game - which is all part of the plan.

I'm feeling progress being made --- which is one of the preconditions to feeling "flow".

Sensations Snookered? - The Careenium to the Rescue

2008-01-03T16:12:00.000+02:00

So I'm modelling conscious thoughts with 'perceptrons' and lower level thoughts with 'sensations' - which are fired automatically by 'receptors'. But at what point do sensations fire a perceptron?

If you touch something hot the sensation quickly gets upgraded to a perceptron - Ouch! Some receptors have a deservedly high priority - but what about more subtle sensations that need to coagulate and mingle before finally firing? - hmmm .... tricky.

Douglas Hofstadter conjures an amazing metaphor in his book, "I am a Strange Loop" to describe this process. He likens the human brain to a frictionless snooker table where tiny balls, called sims (small interacting marbles) constantly career into each other. Some sims bounce off each other, while others may stick together and form larger 'simmballs'. He suggests that consciousess emerges from the simms amd simmballs crashing around what he coins the 'careenium'.

I like the idea! So does The Goo need a careenium? Well currently I'm programming a 'See' Sensation to find filenames in emails, comments, web pages etc. Take this for example: Login.pm. Most of you will recognise this as a filename. The "." visual sensation, the mixed case, and the filename suffix (.pm) all combine to give this impression. But is that enough to fire a perceptron? Are there enough simms (i.e., sensations) for a simmball?

If you're a Perl programmer you will "see" a Perl module thanks to the ".pm" suffix and your mental model of what it is to be a Perl module. But this still may not be enough for a perceptron to fire. If Login.pm appears in an email from your boss, however, he may be referring to the Login.pm module that you wrote and suddenly there is a mental collision between your environment - the display of Login.pm in pixels on your screen and your internal simmball for Login.pm. Pop! And a perceptron is born -> Login.pm.

The firing process, in this example, is a combination of your current context, your memory (the trail) and the sensory forces in your environment (communicated via receptors). There's lots to do so back to implementing but for version one I'll settle for a very simplistic careenium.

Sensations need Receptors

2007-11-30T08:02:00.001+02:00

I've decided I need to model "sensations" as well as "perceptrons" but the problem now is what picks up a sensation? Here again psychology offers some helpful terminology: receptor. Just like the receptors in the back of your retina - some sensors fire automatically in response to a stimulus. These low level sensors are important for classifying low level sensations (e.g., ___ ).

So practically speaking, in The Goo a Receptor generates Sensations which in combination with other Sensations may be picked up by a Sensor that may in turn "fire" a Perceptron (e.g., I see a red line).

Snipping The Gordian Knot

2007-11-19T13:44:00.001+02:00

I recently painted myself into a corner with the design rule "everything must be a perceptron". The problem is that just like with human perception, events need to bubble up from their source until they reach a threshold and "fire". A perceptron is a perceptual event that has fired - but how do I model the preconditions for a perceptron to fire? I need something smaller than a perceptron.

Borrowing from psychology again:

Sensation is the first stage in the biochemical and neurologic events that begins with the impinging upon the receptor cells of a sensory organ, which then leads to a perception.

Sensational!

So instead of tying the design in knots trying to model perceptrons with perceptrons I've snipped the proverbial Gordian Knot and now lesser perceptual events are simply sensations that can chain sensors together to make a perceptron.

Do, Delegate, Defer + Divide = Smoother Workflow?

2007-10-09T09:58:00.000+02:00

The todo subsystem is at the heart of The Goo. One of our ex-employees recently wrote:

"The job is great however I thought being involved in such a large organization there would be better procedures/communication in place! I miss the goo - esp the tutorials. You guys are certainly on the right track there."

But there's more to come! After my YAPC::EU presentation, Farley Balasuriya gave me some great feedback and said he'd recently seen similar ideas in 'Getting Things Done' by David Allen. I've since read the book and Allen makes some important suggestions - if the task takes less than 2 minutes Do It now - otherwise Delegate it to someone else or Defer it.

So in the pursuit of atomic todos I would add one more D - Divide It up. If the task is too big it can be a flow-stopper so it should be divided into smaller todos. I'm currently designing how todos will appear on your mental horizon - and the fours Ds will help you to wade through them.

giz - sticky editing

2007-10-05T12:48:00.000+02:00

I'm going to release a small part of The Goo to CPAN before the London Perl Workshop in December.

giz is an $EDITOR wrapper that:

works with your existing editor (e.g., vi, emacs, nano, pico, kwrite etc)
helps remember where your files are located - so you can afford to forget
injects a special comment into your Perl code to help with keyword completion
can be called from a url (giz://filename=your_filename)

The Goo powered by Perl

2007-09-08T08:32:00.000+02:00

I recently presented about how The Goo is powered by Perl at the YAPC::EU Conference in Vienna. Here are the slides:

Thanks to those who were there for the feedback and encouragement.

Group Karma++

2007-08-19T07:31:00.001+02:00

It's a great feeling being in a state of flow. Sometimes you can get into a state of flow with a group of people, a kind of 'group flow'. This is where the team is working well and everyone is excitedly making progress while the technology is supporting their communication and ability to stay productive. I've been watching developments in the Perl6 Pugs project and the IRC log shows moments when the group hit productivity gold and achieved group flow.

One of the preconditions for flow is feeling progress being made. In the Perl6 pugs IRC log this is achieved by giving each other karma++. As you make commits to the pugs project you get a small pat on the back in the form of another point of karma++ - the more contributions you make the more karma++ you collect. You can see progress being made as the karma++ points tally up in the log.

I've been designing the scoring system for The Goo and I think karma++ is a really important part of feeling progress being made. But to help achieve flow we also need small mentally manageable tasks - atomic todos. So to help the system converge at smaller task sizes a user receives karma++ when they create a task - this should motivate them to create todos, and they receive karma++ when they complete a task too. When you view a person's context you see what channels they are tuned into and how much karma++ they have.

Sensors vs Censors

2007-08-10T10:36:00.000+02:00

I'm reading Marvin Minsky's, "The Emotion Machine" and he makes a strong case for the role of "censors" in expert cognition.

Experts can arrive at the correct answer quicker. But how? Minsky suggests it's because the expert brain blocks unhelpful information and is not slowed down by useless processing. He refers to these automatic blocking agents as "censors". Censors, he suggests, free the expert brain to think about the important stuff. An expert learns from the mistakes of the past and censors help to avoid them in the future.

So far The Goo has been sucking in perceptrons via positive "sensors" but there is also a role for "censors" too. Spamassassin, for example, does a great job of filtering emails before they become email perceptrons. Spamassassin acts as a blocking censor.

But actively blocking events before they become perceptrons solves only part of the problem. There are still too many perceptrons coming in to stay in a state of "flow". They need to be channelled in light of your current mental context to prevent needless context switching.

So channelling perceptrons is the next step ...

Atomic ToDos

2007-06-21T13:42:00.000+02:00

I'm having fun designing how to make the ToDo part of The Goo flow.

Flow happens when you can context switch smoothly in the face of a wave of challenging incoming tasks. The Goo needs to make it easy for users to resolve a task quickly, reward them in some way and move onto the next one. But there is a fine line between being challenged and overpowered by a task. Some tasks, for example, stop us in our tracks because the set up time is too expensive.

A ToDo task that is too unwieldy will break the state of flow. You might get stressed even thinking about where to start on a task. Stress is the flow killer!

Generally at Trexy and Turbo10 we try to break all our projects down into mentally manageable ToDos - which means we minimise stress while still making headway. No ToDo is too small and we actively avoid "projects" and "deadlines".

The trick is to break down a complex project into atomic ToDos --- indivisible, non-blocking, time slices of attention that get the job done.

Hmmm. How can I force the system to converge at atomic ToDos?

One way is to set a time limit per ToDo. How about a 'billable unit' to borrow a solicitor's term? Let's say five minutes.

Now some tasks will take less than five minutes (e.g., increase font size of heading to 20px) while others may take longer (e.g., write blog entry) but the time limit will generally encourage a smaller task size.

It also means that a user could acquire extra time over the course of the day if they 'beat the clock'. This helps to 'keep score' which is an important part of maintaining flow in computer games. User's should be rewarded in some way for beating the clock.

OK. So this is the next step for The Goo's ToDo management - atomic, 5 minute ToDos - and a cumulative scoring system based on time. Let's see if this helps find the elusive flow ...

Working with "Flow"

2007-06-20T22:01:00.000+02:00

Game designers know implicitly that "flow" is the mental state they want their players to be in: happy, productive and engrossed in their game.

Wouldn't it be good if Microsoft Office could achieve the same effect?

Well my virus-ridden XP machine is currently showing the blue screen of death - so for me this is an entirely rhetorical question - but I hope you get my gist. If I can get into a state of flow while playing Tetris why doesn't office software try and do the same?

The Goo is some of the way there but to be honest it can't reliably get me into a state of flow. What can The Goo learn from game design? Here are some features of flow mentioned in a presentation by Daniel Johnson from the University of Queensland:

Tasks that offer a chance of completion
Tasks that facilitate concentration
The task has clear goals
The task provides immediate feedback (the need for a score or energy bar)
The task leads to deep but effortless involvement (removes awareness of everyday life)
A task that facilitates a sense of control over one's actions
Concern for the self disappears during the task, yet paradoxically the sense of self emerges as stronger when the flow task is completed
The sense of duration of time is altered

OK. In light of this it's time for the rudimentary user interface to go through another evolution ...

Bashing away at The Goo

2007-06-12T18:33:00.000+02:00

A goal of The Goo is to help stick Things together and for a long time I've been wanting to add all my shell commands into The Goo. Thanks to some quick help from London.pm I can now capture all my bash shell history with the following ~/.bashrc setting:

export PROMPT_COMMAND='history 1 | /home/search/goo/lib/Goo/Sensor/ShellHistory.pm'

This inserts a perceptron into the database each time a command is executed and any 'things' in the argument list are automatically marked up. It also means the context is preserved between web based actions and shell actions.

Too Many Perceptrons?

2007-05-19T22:20:00.000+02:00

In the last month over 70,000 perceptrons have flowed into The Goo.

I know that sounds like a lot but it doesn't feel too bad. It's not like your email inbox is suddenly inundated with 70,000 messages. The perceptrons are spread more or less evenly through time, and they kind of wash over you, for want of a better description.

Seeing wave after wave of perceptrons makes you feel slightly out of control but in a good way. All the perceptrons are flying in but once they go past it's reassuring to know they are frozen in the trail. Like events in a computer game some things can just fly by whilst others require special attention. The trail acts like a mental crutch collecting all the perceptrons.

Meanwhile, between waves of perceptrons, I've been bringing my cognitive science knowledge back up to date. Things have moved on since I studied 'cog sci' at the University of Queensland in the early 90's and I've really enjoyed reading Doug Hofstadter's, "I am a Strange Loop".

I'm halfway through the book and can't find too much I disagree with so far. If indeed our consciousness is, as Hofstadter suggests, a kind of "strange loop" then as a computer scientist it's very tempting to think of ways to optimise the loop!

All in all I still feel like I'm on the right trail.

Split Screen - Prior Art

2007-03-15T07:41:00.000+02:00

Just found some prior art for a split screen - Vannevar Bush's Memex, 1945. I must be on the right trail!

New Interface - Balancing Perceptrons and Actitrons

2007-03-14T09:49:00.000+02:00

Here is a screenshot of the really rudimentary interface that handles "perceptrons" (on the left) and "actitrons" (on the right). This tries to retain the 50/50, Ying/Yang, relationship between what you see and what you do when you're in a state of flow. The interface works with console based browsers and graphical browsers.

There is much more to be done on the interface but the essential 50/50 nature of the interplay between perceptrons and actitrons will hopefully get the user into a state of "flow" quicker.

Perceptrons - Feel the Flow

2007-03-01T12:55:00.000+02:00

Email perceptrons are raining into The Goo. Great!

But this is only part of the problem solved. What about context switching and preventing buffer blowout?

I can only help improve context switching if The Goo is aware of the context I'm in. Added to this the context itself must be mentally manageable. Ideally I only want 7+/-2 things to juggle at a time.

Have you ever lost track of time in an "immersive" computer game? Computer game designers want you to feel "flow" as you context switch smoothly around the game. It's not a bad state to be in: your brain is working well, you're feeling good and you're getting stuff done. It feels smooth. It would be great if The Goo could help me get into, and stay in, a state of "flow".

The next phase is to capture the context I'm in by taking a snapshot of the perceptrons and actitrons in my buffer. See the thin green lines on top of the stick figure above. The perceptrons that get through will be appended to the "tail" of the trail as time goes on.

First Sensor - Goo::Sensor::MailFolder

2007-02-20T12:58:00.000+02:00

I'm spending two hours a day implementing the next part of The Goo: perceptrons and actitrons.

I've decided on the layout of the interface and remarkably it works in the "links" console-based browser - no AJAX here!

Today I wrote my first "sensor" that captures perceptrons from email folders. Implementation options included:

scraping user email in webmin
fetchmail handler
.procmail forwarding

But each of these introduce another prerequisite and configuration complexity. CPAN came to the rescue with two handy modules: Mail::Box and Schedule::Cron.

Currently a sensor POSTS perceptrons to a Goo::Server where they are recorded in a database. Each Goo::Sensor has a scan() method for searching its environment.

The next sensors to come are: tasks, chat and RSS...

I'll post a screen shot soon!

Modelling Perceptrons and Actirons

2007-02-12T07:33:00.000+02:00

I use a hybrid database modelling methodology of ORM and E-R and over the weekend I started to model what a Perceptron and an Actitron is and how they relate to the Trail.

Here are some of the points that came out of it:

A "perceptron" is a unit of perception that is picked up by a "sensor".
A sensor is a software device for capturing perceptrons.
The sensor must send where the perceptron was captured, when and who the sensor operates for.
The perceptron may be observed but is not seen unless it goes via someone's short term memory buffer (7 +/- 2).
A sensor passes perceptrons to a user or group of users or another sensor.
An "actitron" is a unit of action which may be performed by a person or a sensor.
An action performed by a person is always "seen" - but this may not be the case for a sensor.
Over time a user's trail is filled with seen perceptrons and seen actitrons.
Actitrons can happen on Things.
A Thing is an object in your perceptual environment.

So what does this mean? Well by creating sensors your potential perceptual environment can be expanded (i.e., see more). Your own actions are remembered and can then be temporally associated with other Things which means you can make lighter context switches as time goes by (i.e., juggle more). It means you can also add future events into your trail by putting something in front of a sensor at the right time.

Actitrons + Perceptrons = Ying + Yang

2007-02-01T19:21:00.000+02:00

I started writing a SciFi novel where in the future there are two types of things: Perceptrons and Actitrons. A perceptron is a unit of perception that somebody perceives (apologies to AI guru, Marvin Minsky for pinching his term) and actitrons are units of action.

My SciFi novel is on the back burner but I think these ideas could be useful in designing the next part of The Goo. When we work we perceive things and then perform actions as a result. A lot of time is spent moving from perceiving to acting and going back again.

Hopefully this diagram will help explain:

Seventh Heaven? Not quite.

2007-01-15T11:12:00.000+02:00

At the start of the week every member of the team receives a "Pending Things Report" which shows the top ten pending Things. The problem is all the Things are set to care factor: 7. The care factor is not discriminating between what's not so important and what's really important. But the real problem is no one cares about the care factor - what is care factor 7 anyway?

So I'm looking at a different way of ordering Things without the need for maintaining a care factor.

Email is Br0keN

2007-01-15T09:18:00.000+02:00

I started using email in 1990 and over the last 16 years I've progressively received more and more emails while sending less and less. In the last six months though, I've felt a change. The Russian "spam bots" are winning - exponentially so.

I now receive way more spam than real emails and I feel we're heading towards a tipping point - spamassassin does a valiant job of applying a Holtzam-esque shield but the slow, and crafty spam still gets through! I think we're converging on the "Spam Singularity".

The demise of email may not be such a bad thing --- I think there's more that can be done with a controlled hypertext system. A worthwhile message, for example, should always have a "what's next". I wonder what's next for email?