Posts Tagged ‘Fluidinfo’

A shared writable object for everything: Sudoku problems

Wednesday, June 15th, 2011

Image: wikipedia

Fluidinfo is composed of objects that have tags with values. One of the tags is special, the about tag (its full name is actually fluiddb/about). One of its properties is that its values are unique across Fluidinfo. In other words, there can only be one object with any particular about value. It’s a bit like Wikipedia, which you can think of as having a single shared writable page for every topic imaginable. Fluidinfo offers a shared writable object for everything imaginable. The last part of a Wikipedia URL is like a Fluidinfo about tag value. That’s very wiki-like, but other properties of Fluidinfo make it more useful for applications than a wiki is. For example, it has a permissions system, its data is typed, and it has a query language. If you’d like to learn more about the about tag, there’s an entire blog named after it, run by Nicholas Radcliffe.

This morning I was having breakfast with Esteve Fernández and Jamu Kakar and Jamu mentioned a friend who’s heavily into Sudoku. I mentioned that there are several mobile apps that let you take a picture of a Sudoku puzzle and then solve it for you. I also said “Fluidinfo has an object for every Sudoku puzzle”.

I thought I’d write a very short blog post to illustrate this. So I took the Sudoku puzzle from the Wikipedia entry and made a Fluidinfo object for it. I read the cells of the puzzle left-to-right, top-to-bottom, and used a hyphen to indicate an empty cell in the starting configuration. Written as a single string of characters, that’s 53--7----6--195----98----6-8---6---34--8-3--17---2---6-6----28----419--5----8--79. I used the Fluidinfo Explorer to create an object in Fluidinfo with that as the about value. Then I put a tag called terrycojones/solution onto that object, with value 534678912672195348198342567859761423426853791713924856961537284287419635345286179, which is the correct solution to the puzzle, again read left-to-right, top-to-bottom.

This illustrates a few things. Firstly, Fluidinfo really does have an object for all Sudoku puzzles (created as needed, of course). Second, I’ve established a convention for the about tag value to represent those things. I could have done this in many different ways, and the solution I chose may not be the best. If I were intending to add information about lots of Sudoku puzzles, I would publish my choice and encourage others to follow it (which anyone could do, since any Fluidinfo user may create an object with any about tag – if the object already exists it’s no problem, you just get the already existing object). Third, the terrycojones/solution tag I put onto the object may not be of much use to the wider world. But, I could give other people (or applications) that I trust write permission for that tag so they could tag the objects too. Fourth, if I thought those solutions were worth something, I could make the tag unreadable by default and try to sell access to it (i.e., allow only those who paid me to have read access).

Finally, this illustrates the simple way in which isolated activities, like individually solving a puzzle, can be made social through shared writable storage. If I used a Sudoku application that tagged the shared object with some subset of terrycojones/solved or terrycojones/working-on-it or terrycojones/too-hard or terrycojones/solution-time tags, and others used that application too, solving Sudoku puzzles would instantly be social. Any Sudoku application could use Fluidinfo to allow you to see puzzles your friends couldn’t do or were working on, it could show you the amount of time your friends took, give you hints, find errors, etc. It’s easy to think of a ton of possible social extensions to the Sudoku world, and these include collaborative efforts.

This is a nice example of how shared writable storage with an object for everything allows formerly isolated actions to easily be made social. I’m planning to write up some more simple examples. There are many of them.

Information. Naturally.

Friday, August 28th, 2009

Image: Mary Hodder

Image: Mary Hodder

From the Fluidinfo home page:

Humans are diverse and unpredictable. We create, share, and organize information in an infinity of ways. We’ve even built machines to process it. Yet for all their capacity and speed, using computers to work with information is often awkward and frustrating. We are allowed very little of the spontaneity that characterizes normal human behavior. Our needs must be anticipated in advance by programmers. Far too often we can look, but not touch.

Why isn’t it easier to work with information using a computer?

At Fluidinfo we believe the answer lies in information architecture. A rigid underlying platform inhibits or prevents spontaneity. A new information architecture could be the basis for a new class of applications. It could provide freedom and flexibility to all applications, and these advantages could be passed on to users.

Fluidinfo does not attempt to directly model information accumulation and use in the real world. It simply provides an information architecture that is more flexible than the ones we’re used to. It provides a fairly simple answer to the question of how we might work with information more naturally when using a computer. It does not claim to be the final word on the subject, but points out a fruitful direction for advance. And it provides a concrete implementation that can be used today.

The fruitful direction

The computational world is too read-only, and too tightly controlled. Most of the time we spend using a computer, we are either 1) strictly in read-only mode or 2) using an application that allows us to write, but only in predetermined ways. In contrast, in our normal dealings with the natural world, when using our brains, we are never in read-only mode. We are constantly processing information and adding (i.e., writing) to our mental models. I’m talking about everyday things, like noticing something and remembering that you noticed. Or seeing something you like, and being able to recall that fact later. Even in these trivial acts we are in some sense writing—laying down memories that can later be recalled, sorted amongst, shared, organized, merged, or put aside for long periods or even forever.

In thinking about this extreme fluidity, I find it illustrative to consider how we work with concepts. As I wrote in Kaleidoscope: 10 takes on Fluidinfo:

Concepts are very fluid: they don’t have owners, you don’t ask for permission to add to them, they have no formal structure or central piece of content, they can be organized in many ways, and they have no pre-defined set of qualities or attributes. Exactly the same can be said of Fluidinfo objects.

The fruitful direction—and the mission of Fluidinfo, if I may be so grandiose and dramatic—is to engineer an information architecture with a fluidity similar to that of concepts, in order to make the world more writable. The question (and the point of this posting) is how?

Objects without owners

The answer is actually very simple: Fluidinfo provides support for information objects that do not have top-level owners. These objects are comprised of tags (with values), for which there is a flexible and secure permissions model. Because the objects don’t have owners, anyone, or any application, can add tags to any object it can find. These objects have all the nice properties of concepts mentioned above.

That’s it?

While there’s a lot more to Fluidinfo than having objects with no owners, this single change is the key to the architecture and is responsible for its generality and flexibility. It’s almost embarrassingly simple.

It takes a while for the implications of this twist to sink in. I’m not going to go into the details in this post. I’ll just point out that a simple change in representation can have a surprisingly profound effect. I’ve already written about this, though without giving details of Fluidinfo.

I’m fascinated by representation and its role in problem solving. How can such a simple piece of mental jujitsu result in fundamental change? I’ll describe the consequences in later posts. There are several of them, and I think they’re important. For now though, if you’re interested, please follow the link above to see some simple examples of the power of changing an underlying representation.