August 22, 2006

I've just had an epiphany!

May I present the humble dhtmlxTreeGrid.

Go play with it. It's cute.

I've never seen a TreeGrid before. Or, if I have, I've never really noticed one before. But recently I've been thinking about one of the great challenges of software geometry : "squaring the triangle" (the CS equivalent of the age-old problem of "squaring the circle".)

In other words, managing a world where rectangles (and combinations of rectangles such as tables in a relational database) meet triangles (object hierarchies, outlines and other trees).

When you look at the treegrid, you are looking at the solution of a problem. "Our data has rectangular structure and hierarchical structure. How should we present it to the user?"

Well, in HTML you can have hierarchies :


  • a

  • b



    • c



      • d

      • e





      • f




  • g



And you can have tables :




ABC
321


And you can even nest one inside the other :





ABC
32


  • a

  • b



    • c



      • d







    • AC
      31








But no combination of nesting triangles inside rectangles (or vice versa) will actually give you a treegrid. (In fact, it's quite a puzzle to figure out how it works in HTML.)

In the TreeGrid, who is master? At first glance, it looks as though rectangles are. After all, at any level down the hierarchy, the columns are the same. Same width, same type, same format etc. The tree is imprisoned in the grid. Surely, the "hierarchy" is a fake. They're simply keeping some kind of indentation information with each row. A visual trick.

On the other hand, close them all up. You're left with just one node. Are the others really all inside that? Perhaps it's a hierarchy after all, and the columns within each element are simply measured to seem like they line up? Triangle is master and rectangle is illusion?

But what about sorting, and filtering and summ(aris)ing. Surely columns rule there. Or do they? In the example, open them all up and sort by price. Results are constrained within their parent node. But what if you wanted to sum across all subnodes? or filter across all subnodes?

No-one is to be master. Instead triangle and rectangle must subtly interact. They cross-cut, one or the other taking the lead when it comes to particular operations.

The question of how to balance hierarchy with relations goes way beyond interface widgets. Almost certainly the data in your company is both triangular and rectangular. But how does your software treat it? Does it manage to get the right intersections? Or does it force it into one shape, losing the benefits of the other?

What can we learn about beautifully combining rectangles and triangles from looking at the treegrid?

Bonus : Here's another one.

No comments: