In the last post I divided existing information management tools (mentioning some in examples) into either open or strict-type categories. Today I continue by describing what I think is done right and what I would want to see improved.

Done right

Open tools

I'm happy with open tools. Most of them have been in development for over a decade and are helpful with general problems. Microsoft has done a good job with its Office and there are several alternatives, such as OpenOffice. You can use Microsoft Word (or something similar) if you need to write anything (a report, an article, or a note). Other examples are Adobe, Macromedia (which is part of Adobe now) and other companies, all providing good tools to work with pictures and graphics.

These tools are useful in many information management scenarios, but in most instances, they can handle only cases with simple data structure. When amount or complexity of information goes up open tools become harder and harder to use and strict-type tool designed for specific problem becomes more and more appropriate.

Simpler design

Another thing I like is a general shift towards less complex design. Applications like this with less features are becoming more popular, especially web applications. This is a good change from old feature racing (where every program would try to have more features than competition), although I don't agree that cutting features out is always appropriate. I think Einstein's, "As simple as possible, but no simpler" is a good guideline in design. Eventually we might end up with applications that are too simple to be practical.

What can be improved

Strict-type tools

There exist a lot of strict-types tools that try to address specific problems. Many of them are good, but I think most need to be better. When the tool fits the problem, great, however it often doesn't. Designing and developing a good tool is difficult. It's not easy to understand the problem (because usually there's a set of problems to address) and to come up with the best solution (there can be many solutions, each with its plusses and minuses, and on top of that different people might have different preferences on how to do something). Finally it's hard to balance resources (both development and of the user PC). As a result, a lot of strict-type tools have good potential, but can see a lot of improvements.

All tools have common problems

Almost all tools have very similar problems. Few tool supports substantial source control (saving history of changes to see and compare document modifications through its lifetime). Usually there's limited support for collaboration and security. The list goes on, but the whole situation is improving.

Strict-type vs. open

Strict-type tools are often not strict enough on one hand, but on the other are too strict, making them harder to use. For example, wiki supports flexible structure to store notes in a graph, with one note being able to reference any other including its parent. They can be strict and often don't allow notes with the same names, their wiki-text is often too simple (creating tables is too hard), etc. At the same time, note (page) doesn't have any text structure, so it's impossible to enforce certain structure, where user has to fill out some fields for a new note.

What can be done

I don't really have a good answer. Designers need to always keep in mind user needs and make interface simple and intuitive. Things are moving forward. Every new generation of tools gets better. We are starting to see more flexible, context-based interface and support for larger, more complex problems. With Internet emergence demand for online tools is growing, and developers have to address that as well.

Our solution, so to speak, is Sider. We're trying a different approach, creating an environment to help with applications development. We believe in strong-type tools are the best solution for many information management problems, but at the same time developing specific tool from scratch requires a lot of effort. Sider addresses this by supporting higher-level languages to define logic, structure and interface, and to bind them together (through XML and browser technologies). It also promotes reuse of parts of existing tools through inheritance, composition, referencing and other mechanisms.

We also want to address a set of common problems I have mentioned previously. Since all tools will run on a single platform, it's possible to share horizontal features (like security or capturing document history) with all Sider-based tools.