In through the diorama

Managing Simplicity (TM)

2011-06-25T19:44:00.000-07:00

Software moves too fast for maturity. So software managers attempt to "Manage Complexity." There is an entire industry built around managing complexity. Version Control, Frameworks, Spring, bug tracking, wiki, JIRA, etc.

Managing Simplicity

The idea here is to prefer simple solutions, hoping that the simple solution will pay off in the long term by reducing current and future design and maintenance cost.
Managing Simplicity posits that this will be true enough of the time to make it a default choice. Of course you have to look at opportunity cost, and weights of risks, rewards, and efforts.

Here are the areas where Managing Simplicity spells out steps that are proven to save effort in the long run.

The Refactoring Rule of Three.

The first time, just write the code to get it to work.
The second usage, copy the code, make it work for the new instance.
The third usage, look for commonality, and do a simple refactoring.
So any time you have four blocks of code that smell of Cut-and-Paste, look to refactor the code in the simplest way to eliminate redundancy.

When you get to three redundancies at the next level, then consider fancier refactorings. That is, the following code is redundant, but OK, because it is only done twice:

        ContainerNode copyrightNode = new ContainerNode("Copyright");
        copyrightNode.setDesigner(new CopyrightDesigner());
        TreeItem copyrightItem = ContainerNode.createTreeItem(copyrightNode);
        getContainingTreeItem().addItem(copyrightItem);

        ContainerNode websitesNode = new WebsitesContainerNode("Websites");
        websitesNode.setDesigner(new ListDesigner(websitesNode));
        TreeItem websitesItem = ContainerNode.createTreeItem(websitesNode);
        getContainingTreeItem().addItem(websitesItem);

When you get three of these babies, do a simple refactoring, which is to move the code into a factory method, passing in the things that are different.

However, when you get to three different variations of how you call your factory method, look to fancier things, like Interfaces, Introspection, Spring, and so on.

Using Google Web Toolkit (GWT) for UI and RPC for the Anarchia Author interface

2011-06-17T09:52:00.000-07:00

This is a bit of a ramble, but contains links to get started using GWT, and some notes on how to use Eclipse and IntelliJ IDEA for GWT development.

For http://anarchia.us I plan to deploy using http://dynamide.com as the templating engine for browsing all the content. But the Author interface (that is, the interface that authors must use to upload content, manage identity, choose frame layouts, make story trails, and assign copyrights), is a real app. It has business rules, editing of one-to-many relations, and many of the things that make application development and deployment difficult via a web interface. I had planned to deploy this app as a pure java client using http://tagland.org , but the tagland client still needs a heap of work. I could use dynamide for this app, but there is a lot of back and forth to the server, and dynamide, being form-based, would make this a bit too web-1.0.

Enter Google Web Toolkit (GWT). I decided on using GWT for the Author interface because it promises cross-browser functionality, and AJAX communication to the server. Downsides: it is complicated; it has a slow load time; it has a number of moving parts that are inaccessible. I decided that the slow load time was acceptable for the Author interface since it is basically an admin application--designed to be used by a limited number of authors who are motivated to use the system, compared with the browsing interface which will be used by anyone on the web. After some initial testing, I also found that complications seemed to be in the build and deploy process, and not in the browser environment, so could be managed like any other software complexity. I also found during prototyping that all of the abstractions I really wanted were supported. GWT supports serializing real java objects across the wire with its own RPC mechanism, and supports construction of the UI by composition of components. Another plus of GWT, for a Java programmer, is that all the code and logic are in Java. So you get compile-time checking of everything, strong typing, exceptions, etc. This goes a long way towards managing simplicity. On balance, it seemed that GWT managing of complexity was the way to go rather than managing that complexity directly with something like jQuery.

On to the things I learned while prototyping GWT.

First, you can see the actual code I used here: http://tagland.sourceforge.net . There are some dependencies, so you'll probably need to check out the whole project. Look in module anarchiaAuthor. This project compiles in IntelliJ IDEA 10.5.

I also got this working in Eclipse, and that version is up on the official sourceforge page for Anarchia at http://sourceforge.net/projects/anarchia/develop

Which IDE?

GWT is supported in Eclipse and IntelliJ IDEA. Eclipse supports a UI designer tool which is very cool. They both generate sample applications for you, which is the only way to get started. The flavor of AsyncCallback that the use is a bit different. Eclipse generates inline anonymous classes; IDEA generates named, inner classes. I'm a fan of IDEA, so once I established that they both worked, I moved on to developing all my code in IDEA. IDEA has slightly better inspections and jumps between Java, XML, and HTML files in the project a bit better. Eclipse generates the deployment files correctly, which is to say, all the files with MD5 sums in their names, which are browser-specific files for deploying to all supported browsers. In IDEA 10.5 (they say they'll fix this in 10.5.1) you need to add two jars to your classpath to get this to work. In Project Structure > Libraries > gwt-user > Classes, you need to click "Attach Classes", then point to your local GWT installation dir, where you must find validation-api-1.0.0.GA.jar and validation-api-1.0.0.GA-source.jar. Accepting these files should add the jar files to the classes node (not to the sources node).

To get started in IDEA with GWT, I followed this screen-cast *very* closely, using the pause button frequently. http://www.jetbrains.com/idea/training/demos/GWT_Basics/GWT_Basics.html . Basically, you install the GWT plugin, then create a new Java module, and then specify that it uses Google Web Toolkit, making sure to check the checkboxes that ask if you want it to create a source directory and if you want it to create a sample application.

Documentation
I read the documentation here:
http://code.google.com/webtoolkit/
including the tutorial, which is very well written.

I found this article to be thorough and well written:
http://www.vogella.de/articles/GWT/article.html
It also got me past one of the big humps, which was how to let GWT know about dependent modules so I could use GWT as a layer, rather than an all-in-one solution. This is important if you want to keep from copying code or source jars around, and if you want to keep from getting everything wrapped up in GWT land so that you can't pursue other implementation strategies. Specifically, I found this section very helpful: http://www.vogella.de/articles/GWT/article.html#modules

There are two things going on when you import modules. First, you have to get your IDE to know about the modules. Second, you have to get GWT to find the source code, so that it can translate it into javascript, which is the magic that makes GWT work.

The above article shows how to do this in Eclipse. In IDEA, you should also follow the article on how to do GWT module imports, then you must create an IDEA module in your main project, call it a Java module, and add dependencies on lib directories. In tagland, tagland is the main project, anarchiaAuthor is the GWT module (a Java module with a Google Web Toolkit feature selected on the second or third page of the New Module wizard), and anarchia-obj is a Java module that contains just the serializable, GWT-friendly POJOs. (POJOs are GWT-friendly if they don't import things that can't be serialized and sent to the client. The list is here: http://code.google.com/intl/pl-PL/webtoolkit/doc/2.2/RefJreEmulation.html . You'll find that things like java.net.URL are not included.) anarchiaAuthor, being a GWT module, has a WEB-INF/lib directory, and that must be added in the project as a lib directory, and that lib must be added as a dependency in the module settings. anarchia-obj, being a POJO module, must be added as a dependency in the module settings for anarchiaAuthor.

"No source code is available for type java.net.MalformedURLException; did you forget to inherit a required module?"

You'll get these kinds of errors if you don't have the source code for the classes you want to serialize included properly in the IDE and in the imports statement for GWT. For IDEA, you sometimes need to restart IDEA after fiddling with the GWT imports statements.

You will get all kinds of strange errors if you try to send anything across the wire that cannot be serialized and emulated by GWT. In IDEA, be sure to look on the Modules tab of the Run window for the log.

You will also get errors if you include jars in your lib directory that have older sax parsers. The solution is to clean out your lib directory, and add things slowly until the error appears. These can look like this:

[WARN] Unable to process 'file:/Users/laramie/Library/Caches/IntelliJIdea10/gwt/tagland.90e8b9ba/anarchiaAuthor.4b3edb74/run/www/WEB-INF/web.xml' for servlet validation javax.xml.parsers.ParserConfigurationException: AElfred parser is namespace-aware at com.icl.saxon.aelfred.SAXParserFactoryImpl.newSAXParser(SAXParserFactoryImpl.java:37) at com.google.gwt.dev.ServletValidator.create(ServletValidator.java:191) at com.google.gwt.dev.ServletValidator.create(ServletValidator.java:172) at com.google.gwt.dev.DevMode.doStartup(DevMode.java:426)"

This give you a clue that can help when figuring this stuff out. Note the location of the WEB-INF directory. This is the deployed location, so go in there, and look in WEB-INF/lib, and see what has been deployed. In my case it was extra sax parsers that were incompatible with the one GWT wanted to use.

I also found this blog to have lots of info:
http://www.mooreds.com/wordpress/archives/category/gwt

Of Menus and Spaces

2011-04-11T23:18:00.001-07:00

Menus are hierarchical. Non-cyclic, they may contain aliases.

Menus are installed in a space. A menu is just a text file or collection of files, capable of storing hierarchy structure, and all data and algorithms to invoke an action based on a command chosen in a context.

Multiple menus can live in one space. Menus can call each other in the same space with a different security context than calling menus in other spaces.

The context is in the space. The context may be a sandbox with a namespace of variables and commands. But that context is in the space.

The space is just data; can also be represented as a directory of files.

Ultimately a space lives in a JVM, there is an uber-sandbox of Java class files to provide an API to the space, to the commands in the space.

A space is data. These data can be closed and exported to another machine.

So very quickly we have the problem of synchronizing spaces.

Some spaces will be very data-centric, will be about storing data, or metadata. Others will be more atuned to a user's desires. Data-centric spaces will have p2p, federated backup and sync, or publish-subscribe strategies for synchronization. The personalization spaces will have to follow the user more closely, e.g. actually stored on user's person, e.g. cell phone sdcard. Or perhaps biometric or passphrase based user identification for opening a write session to a hosted space. Or maybe, spaces allow mulitple users to log in and change a space. So you log into a space, and are perhaps simultaneously logged in to other spaces you need. Your master local session keeps track of these spaces, and marshalls data between spaces based on permissions.

All messages to menus, API objects, etc., use an XML payload input and output objects. The function name, plus the type (schema) of objects they require and return defines the API.

Links to Java projects that might help

2011-03-24T08:15:00.000-07:00

Which4j
I wrote one of these for Vestek, but this might be useful, seeing how it is open source. Anyway, it is nice to have a utility which tells you in which location on your classpath a java Class is actually found.
http://java.net/projects/which4j

TrueZip
This is the bomb. Archives as federated filesystems. (Zip, tar, jar, etc.) This will be needed by diorama for dealing with personal spaces. My concept of Spaces is to mount a jar file, then write to it, then unmount and share it, with whatever level of encryption. Your project's tips-n-tricks, help files, etc., would be in a public space. Your contacts would be in a private, encrypted space. Then those spaces get sync'd through your server/account, and shared as appropriate. This library, TrueZip, looks perfect for the implementation because it handles multithreaded access to the archive at runtime.
http://java.net/projects/truezip

My PowerMac is now a $4000 brick

2011-02-28T10:33:00.000-08:00

I just tried to install Java 1.6 (i.e. Java 6) on my 4 processor PowerMac, after having followed the instructions and paid $150 for a new MacOS Leopard 1.5.6 Operating System, and applied all the updates up to 1.5.8 in order, including all the Java updates from Apple. "Oooooooooh Sooorry, you can't run Java 6 because *you don't have an Intel processor!*" What!?

Without Java, my Mac is good for running ProTools, which I do. But without Java, I can not do the work that I get paid to do, which is to be a Java programmer. So this machine is useless if I want to use it for work. But also, any Java app written since 2008 has the right to rely on Java 6. So a whole raft of applications can't be deployed on a PowerPC-based Mac.

Now hold on, you say. Your PowerMac G5 is 6 years old! (Never mind that Java 6 was released the same year my G5 was.) But, I say, you haven't looked inside this machine. It easily cost twice what commodity hardware would have cost me at the time I bought it. It is made from machined aluminum. It has a liquid cooled core with a radiator. It has machined, well-designed, beautiful, expensive parts. This machine was built to last twenty years if you keep the dust out of it. And Apple built a reputation on backwards compatibility and support. Well that's all gone now, it seems. They are playing the same game Microsoft is: every two to three years you should buy a new Mac, preferably in the $3,000 - $4,000 range. Because it's better hardware. It will outlast your crappy Dell which dies after two years because of crappy, proprietary power sub-sytems. But what does it matter if the hardware lasts, if the OS doesn't get upgraded?

Also, as I see it, I can not now use my PowerMac if I want to use the best programming language in the world, that is widely accepted, and may be one of the languages that we could have standardized on. Except everyone wants to kill Java. Microsoft wanted to kill it so much that they intentionally broke their own implementation, and wrote a competing look-alike language, with the help of a hired gun: Anders Hejlsberg, the designer of Delphi from Borland, who contributed in a big way to the Java component model. Oracle wants to kill Java, too. They wanted to kill it so badly, they bought it along with Sun Microsystem, and made it even more proprietary than Sun had. Oracle allows us a quasi-open-source solution called OpenJDK which will build on Linux, but is a time-lag from the main development line. This appeases folks, and is mosly available and free, but it means they retain control. What the world needs is an open source language as robust, secure, mature, fast, and good as Java, that is not owned by any for-profit-corporate entity.

Mac wanted to kill Java so badly, they insisted that no one else could build Java for the Mac. Then they don't release security updates when the fixes are available. Then they decide to not support Java 6 on non-Intel macs. The tech support lady, when I asked her if I now had a $4000 brick, said that if I wanted to run Java 6 that I'd need to upgrade my entire system to Intel. Since when is buying a new machine called "upgrading?"

Then there's Apple's refusal to distribute Java on the iPhone. Tiny devices that are intermittently connected to network are what Java was designed for. Most phones have Java. The Android phones are making a smashing success using Java. So why doesn't Apple want to support Java on their phone?

So why do I claim that everyone wants to kill Java? I don't have a smoking gun, just this: if you have Java, it's one step closer to not needing a branded operating system. Java is a system you can run on a computer that will run many kinds of applications, and replaces many core operating system features. And does it in a particularly device-independent, OS-independent, network-aware way.

But you can't make money selling operating systems that don't have some sex appeal, and you can't have sex appeal without branding. So coming up with 5 new apps that flip pages in 3D is more important than providing security updates and version updates to core frameworks. Especially if those frameworks don't have happy little nibbled apple cores floating in a rotating 3D purple-starred galaxy.

So the Hell with Apple, and Microsoft and Larry Ellison. Software moves too fast for maturity. That's not Larry's fault. It's just that Larry, Bill, and Steve know this and have figured out how to make money on this mayhem.

Visualization Links

2010-11-16T18:40:00.000-08:00

Researching visualization software. What we will need for viewing object graphs and tree-structured data. Looks like there are some open source projects that ride on top of Java 2D, and provide visualization features such as layers, zooming, and panning. There are some open source apps built on top of the framework, so customizing may be straightforward.

This chemical model visualizer: http://sali.rguha.net/ depends on the object graph visualizer: http://www.graphviz.org/ which rides on this open source ZVTM project: http://zvtm.sourceforge.net/

The idea would be to have 2D, layered, multi-zoom interface into the trees of the tagonomy, so that tagonomies become visually recognizable and explorable spaces.

Tagland on sourceforge.net

2010-11-11T19:20:00.000-08:00

Please visit tagland.sourceforge.net to check out the source code for tagland. Under current development are some of the ideas sketched out in previous posts. Specifically, I've got a PropertyPage system working which allows you to view and edit Java Bean properties on any java.lang.Object. This will plug into the tagland command-line menu system to edit the Anarchia.us domain objects, similar to how NakedObjects does it, but much, much simpler.

These are baby-steps, but it demonstrates my bottom-up, Managing Simplicity^TM, CDC approach. I'd love to hear your comments and contributions. Please feel free to join the sourceforge project here.

Nail 2.0

2010-08-06T00:19:00.000-07:00

I live in Berkeley. Most of the houses here pre-date me. Almost all are built with wooden frames, which means almost all were built using nails. Imagine, if you haven't already, that the Naitional Nail Authority has issued Nail 2.0. Immediately, however, a bug in the Nail 2.0 implementation causes the underlying Nail 1.0 implementation to AB-END and fail to build. So immediately, of course, all Nail 1.0 and later spec nails cease to exist. So 95% of the houses in Berkely immediately fall over, and the town looks like the last little pig was smart after all, until owning a nice brick home in a town of wooden houses all broken up with gas lines open all over the place starts to seem like a really bad idea.

This kind of Scorched Earth vision was all the rage in the last part of 1999. I was working in Financial Services doing portfolio analytics server-side in Java with a legacy back end of millions of lines of FORTRAN code. So we didn't sweat the Y2K bug at all -- financial analytics really have to be able to go way into the future for Bonds and what-ifs, so the system had always been written to handle Y2K dates. But I remember thinking that if the EastBayMUD servers, which I had toured, and were highly COBOLized, were to crash, then for a few days we might not have water. Though more likely was just an EBMUD water bill for a century's worth of water.

So why don't houses fall down when they issue a new nail? Because objects in the real world are manufactured, and then installed and left there with no dependencies. Having a build system is a luxury deployed by just about every software shop, and so is having developers who use version control, test suites, etc. Yet, when we build software, we don't package everything up and ship appliances. We ship tiny bits of code that depend on lots of other code. And our bits of code were made by the interaction of thousands of other littler bits of code. And we send all our little pieces, with all their dependencies on pieces that we don't ship, out in their little boats. Sorry, lost the house metaphor for a boat reference. But I like the imagery of it.

In the dot-com binge, my brother and I started ToasterWorks.com and designed what is now called Cloud Computing. We designed, coded, networked, prototyped, and documented most of, say, what you can get from Amazon EC2. My brother worked on selling it to Dell, Compaq, and some large ISPs. We got really close, but we got beaten to market by several competitors.

I knew going into it that the ideas I had were the result of being in a computer geek zietgiest that probably included about 2 million really sharp minds. I knew there would be lots of others with identical startups, because appliances had already busted out, and linx had GUI terminal servers, so the concept of provisioning a blade at boot time with a networked version-controlled repository of boot images and large data mounts seemed like the way to go since it was clear that big iron would make some kind of comeback. I was also working then on designing web services so that all our virtualized boxes could have very simple duties and just network their messages back and forth. But like I said, that's no boast--lots of people were all scratching their heads and thinking about the future and how it might be manageable with all these dang Linux boxes stacked in the server room and all these dang software pieces.

So now we have Cloud Computing and we have Web Services. But we are still missing some of the things on my wish list.

Real packaging. You get the immutable bits that will work. All of them.
You can still have a build system for assembling and testing these beasts. But don't expect users to have a build system that can handle your kruft.

Simple communication.
All text communication.
Bi-directional communication supported, and one-way messaging is preferred.
To implement this today, I'm thinking: XML messaging. XML file formats. Use schemae and attach them to the document. These all seem viable and established now.

Real interfaces. Typed, inheriting, globally known, versioned, assembled interfaces. (Possible with things like XML messaging and JSON. But also perhaps with sending objects around.)

Come up with some kind of object that can be sent around the network and stored and versioned and transformed, round-trip, to text and back. Java does this, and it plays well with real object databases. I suspect Javascript could do this well, too, as my brilliant friend Brian hipped me to, but he said he detests blog technology, so I guess I shouldn't link to him. Anyway, he says it's totally doable, and folks are doing it.

But I haven't had too much time to see what is up in the javascript-as-object-nirvana world, since I am happy as a clam since I got the schema for the anarchia.us objects coded in Java and stored in db40 and accessed with the rudiments of Retro (my command-line framework) working on my laptop. Java objects. Simple. Not "Value Objects," but POJOs. Properties, collections, relationships--all store nicely in db40. And I'm not doing any kruft. No annotations, no JAXB, no mapping file, no injection, no nothing.

I'll put up the source very soon, and design docs. For now, please read the other posts in this blog to see where I'm hoping to go.

A day in the life in diorama

2010-06-16T13:35:00.000-07:00

Let me tell you how I work.

I keep all my documents in a hierarchy of folders.
The folders are all named tersely, but human-readable and obvious.
I put files together that are in related projects.

I maintain this hierarchy of folders in CVS, which allows me to archive it, along with dated versions of everything I add or change in the hierarchy.
I buy time on a cloud server and run several processes, one of which stores my hierarchy, in sync, archived.

My data are protected by industry standard security which would be good enough protection against any except the highest level hackers with access to large compute clouds (e.g. the government).

OK. Everything above is factual, extant, and uses existing open source technology. Everything that follows in this post is a dream, combining how I work, and new, open source software to model and automate what I now do manually, and what I cannot currently do, but wish I could do.

In addition to this hierarchical, archiving, versioning, distributed file system, I maintain my metadata in a system called Diorama. Diorama stores all the information about my files, and maintains this as a context that can be searched, executed in, added to. I can choose to add new items to my own Diorama-run file system, or I can add new items that are stored out in the cloud, in which case Diorama simply stores the URL and any metadata that get associated with that document. I use the Diorama-run file system for text and small images, and remote storage for larger, binary files. You could use any file system you want, and just have Diorama maintain metadata and indices to documents only.

In addition to tags and categories, where you were in the context at the time of document status change, can be saved in the metadata as well (if you allow your context history to be saved in metadata or metadata links to your context history database). Diorama uses hierarchies of tags as categories, with paths, in "tagonomies", or, tag-based taxonomies. The taxonomies are only suggested, and there are so many aliases, mispellings, case-changes, that they cannot be said to be purely concrete taxonomies, since they don't root together in a particularly organized or distinct way, and in many ways are really graphs. But Diorama soldiers on through the aliasing process, until small set of commands and small set of paths are what I work with most of the time, and those paths and commands become familiar to me and to Diorama, so they become quicker to execute in the command shell.

Since I work mostly through Diorama, everything I do is stored in my personal command history database. It is indexed by time. Documents and remote processes can link to the exact time I executed something, and for API calls inbound, any Diorama context I was logged into can always return its local timestamp, so that the history data are kept local, but can be indexed by request in the future.

Any time I am using Diorama, I get to keep history. So this works regardless of where I log in from. The history data are kept in my Diorama distributed database.

The Diorama command line is simply a command line environment that has a display area that can show menus of commands, pictures, web pages, etc. Diorama has a context area that shows information about the context you are in. Menus, commands, resources, shortcuts, notes, etc. You execute commands to open documents, take actions like send mail, create content, publish, and subscribe.

The context area shows you the tagonomy of where you are, and also the tagonomies of any document you have open, etc. So for this page I might see
"docs/dioramaBlog" or "projects/diorama/blogs/InThroughTheDioram". You can tag anything with these path tags (the character I use is a / but you could use anything, such as "projects :: blogs :: In through the diorama"). The system treats things in the path as parent contexts, and learns about how you categorize things this way. It starts suggesting context paths, for example. The system also does quite a bit of aliasing, phonic checking, and case-insensitivity.

Diorama also has a context area that shows you where you are in the web of contexts. Most of the contexts you will spend time in are yours, like your home directory, or directories of projects you are working on. But you stay in these contexts in multiple windows, and can switch contexts with the keyboard, while still in command mode on the command line. It's very much like being in emacs, sending mail. But it is very menu driven and simple, obvious, and fast. But you will be able to visit contexts of others. You will be invited to join these contexts, because a person on the other end knows you somehow. The system is based, just like human interaction in the offline world, on trust. Most people don't trust pimps, hookers, or car salesmen, but in fact these people are at least honest about their game. Still, when you go to hang out in the park with your best girl, you don't want pimps there, and when you go have a drink with your friends, you don't want a used car salesman standing over your table like a drunken mariachi. So Diorama has no ads. And everyone you run into, or whom you allow access to, is known to you.

Tagonomy Display; features; attributes of tagonomies

2010-06-13T15:03:00.000-07:00

See also: Why diorama?

Supposing that we have a definition of a tagonomy (elements, paths, relationships, aliases, semantic meaning versus object storage), then we can display them.

I have two user-interface rules that apply here: 1) information for navigating the system should be accessible and distinguished; 2) the signal-to-noise ratio should be very high.

For visualization, imagine you are wandering around in a world of your favorite zero-information background, and in front of you are high-information tokens, and around you are related token which could be useful if you wish to move towards them. I could see this as a virtual reality walk through a park with some avatars, etc. But for the current proposal, let me have you visualize something a bit more IBM-Gothic.

For Retro, you have a lovely black background, and words in pleasing fonts and readable, gay greens and yellows and whites (or whatever color stylesheet turns you on) get closer and farther away as you get close to them semantically, so that you see the word "eMail" in bright green letters, and it is significant. Or, if you are in the middle of navigation or choosing items from a menu, these are the only objects/words/pictures that are really highlighted and green.

In this space, we are navigating the metadata, the context. We are not storing the objects, we are providing all the information about the objects, the relationships.

- by year
- big font for years
- project inception dates, meeting person dates, most highlighted/visited/priority get biggest font
- by category
- by priority
- by tagonomy and by date as layers

Above a certain size, every object in the space, with its own representation gets its representative node to bump its display size. So each folder in the space has a template or stylesheet that exports size displays.

Displays for an object in a tagonomy:

At very small, it is just a word.
Next, it is a series of words, and maybe an icon, if icon display layer is on.
Next, it becomes a description paragraph, extract, abstract, with picture, like an article or summary.

Why diorama? Why now? And what is diorama anyway?

2010-06-13T14:50:00.000-07:00

VoodooPad was *almost* the right application.

Lotus 1-2-3 was almost the right interface for a very right application.

WordPerfect 5.1 was the right interface, but it was only a word processor.

The right interface is a command-line, with a menu, and a display.
It's not that we evolved past the command line; it is that we failed to evolve the command-line.

The modern interface is retro.

Retro :: a command line interface ...

that connects you to all personal data, projects, thoughts
and remembers where you put things

that connects you to real people you know
and no one else gets to look at that information
and you don't look at any ads.

that lets you categorize, file, and find things naturally
in a system that matches how we think and ask questions
and not at what is most efficient for the computer or designers
of input forms or advertisers.

The new interface is mostly non-information. The information sticks out because it is information.

There are no ads to masquerade as information. The menus can be navigated by picture, text or both.

Each menu level is a space, it remembers when you were in the space last, your preferences, etc.

If you are invited into the space, or it's your space, then you can run certain menu items in that space, such as checking eMail, messages, comments, etc. Other spaces might be discussion forums just for people who are invited into that space. You also have public spaces. These get mapped to HTML for delivery on the WWW.

You can set up scripts and commands at each menu, in each space.

You can link to data storage for any document that has a valid URL.

You can write notes anywhere in the system and tag them with any tag, alias, or path.

There are some global tags (always on your shortlist) that get you to buckets, or inboxes.

These are tags like "soon" and "todo" and "high priority" or "ideas". These are simply your most used tags, and also tags that map to some future search or workflow.

Ultimately, this system should be used to run tagonomy and anarchia. Anarchia is a social network built around interactions with people as artists. Each person connects to another's art/expression by linking themselves, or to a specific piece of art.

We are about breaking down the definition of artist. Everyone is an artist. Art is the expression of ourselves and our experience through a medium to another person. It is successful art if it conveys expression better than the workaday ways we have to communicate and be understood.

Some names for this stuff:

Retro
TagLand
diorama
Tagonomy