Today I want to start a series of articles on information management. I want to look at what information is, how it relates to our lives, why it's important to think about it, how people work with it, etc. My goal with this and the following posts is to better understand the nature of the information to design better information management tools.

To understand what it is we need to take a look at data. Data is a description of an object, relationship between objects or a process. I couldn't come up with a better definition. Numbers, letters, pictures, sounds, smells are all data and they represent something to us.

Most of what we perceive in the world is gradual. There are no distinct borders between colors. On the spectrum one color changes into the other. Time is continuous as well. We created minutes and hours to measure it. We enumerate and simplify data naturally (often without thinking about it) to make it easier for us to work with it. Different pieces of data describe a small characteristic of an object, relationship, process. Looking at a brick we can figure out its size, material it is made from, weight, etc. All of these describe different aspects of the brick. We enumerated information on the brick. Without doing it it would be hard to calculate how many bricks we will need to build a house or how tall it can be before it will collapse. Use of correct tools can help us capture this information and use it more effectively.

Information is a collection of data organized into a pattern. Humans are very good at recognizing patterns and finding associated meaning. Keep in mind that data and information are objective, but their meaning is very subjective. A brick is a brick no matter who looks at it. Associated meaning (how we see it) can differ. One person might decide to use it for construction, another to use it as a weapon, while third uses it as a paperweight.

When looking at the information we might recognize it. In that case we automatically recall associated meaning. When we look at a red, rectangular stone we recognize it as a brick. Actually we like to recognize patterns and understand the information we are presented with.

Patterns we fail to recognize are noise and are very, very boring because we think they are useless. TV snow is a random pattern of black and white dots. We might recognize that something is wrong with TV, but we probably will not be able to understand all signals that force dots to be arranged in one pattern and not the other.

In the next post I want to talk more about how people work with information. This is directly related what kind of tools can help them do their job better.

Microsoft has finally released IE7. It offers a lot of improvements over IE6 for both users and developers. A lot of bugs related to layout, CSS and memory leaks were fixed. I got really excited when I installed it thinking that most of my problems are over, but life is never perfect. I spent almost a whole day trying to figure out how to work around a new problem that appeared with IE7.

New Internet Explorer introduces native XMLHTTP (used to communicate with server behind the scene without page refresh) support. Up to and including IE6 developers had to use ActiveX object that came with MSXML. Native support makes IE more compatible with other browsers (script is easier to reuse between browsers), but more importantly it is faster and allows XMLHTTP to work even when ActiveX is disabled.

This new feature became a source of frustration for me. Microsoft is tightening security screws and new XMLHTTP denies local files access. In general I think this is wise, but there are exceptions where access to the local files is needed.

When I'm developing JavaScript web controls I often test them by simply opening a file from hard drive. With the enhanced security DojoToolkit doesn't work locally since it uses XMLHTTP to load packages.

I know only one way around this - disable native XMLHTTP support in IE options. This forces DojoToolkit to use old ActiveX MSXML object.

Another problem is with Sider. It hosts WebBrowser control to show document with HTML views. All files are on the hard drive and native XMLHTTP refuses to load them. This made the application pretty much unusable.

Again, the only solution I found was to disable native XMLHTTP and force script to use old ActiveX object. However, I can't force users to change IE options just for my application. Microsoft, fortunately, provided a way to customize them for a specific application and I can disable native XMLHTTP only for Sider.

To disable it for a specific program use this registry key:

I'm not too happy about having to disable new features only because there's no way to configure them. Native XMLHTTP is faster and I would like to have an option of testing it. It's not essential for me now, but at some point it might be more important. For now I can look for an alternative on the Internet from time to time, hoping that there will be a better solution to loading local files through XMLHTTP than simply disabling native XMLHTTP feature.

I have released the first Xelog version. You can look at Xelog change log to see how it looks or download it. In this version I focused on implementing the most important things: schema for the change log XML, allow auto-start by opening Xelog XML file in the browser, and support for different views with ability to change them on the fly.

Current views are simple and static. I considered dynamic views to support on the fly sorting and such, but decided against it. I wanted to release as soon as I could and to have a working proof of concept, but I also wanted Xelog to be useful. I think it is and I'll use it with all my projects.

My goals for Xelog are to help users read and understand project changes and help developer to record those changes. Having different views and ability to switch them on the fly is a user-oriented feature and I will continue to add more of them in the next releases.

For the developers I want to provide views to allow change log editing on the fly. I will probably add it at least partially in the next release. For now you would need to edit XML file manually, but there's a Xelog schema to help you. If you are using a sophisticated XML editor it might be able to use it to supply auto-completion.

With the next release I also want to add support for different formats, such as text, PDF, RSS. I'm not sure yet how that will work and I have a feeling that RSS support might require a server-side solution.

Last, but not least, I want to allow developers to customize how to show the change log by generating different links to the XML file (or maybe HTML file that will launch Xelog). I'm thinking of using URL arguments to configure Xelog behavior.

So, check out Xelog, play a little with it and I'd love to hear about your thoughts. Would you consider using it? Do you think there's something missing that would make it more useful for you? I'm open to suggestions and ideas.

I want to focus on Sider and release a technology preview version. I'm not really sure when I'll release next Xelog version, but I don't want to delay it for too long.

I was working on Xelog and had an idea. A change log describes what has changed in anapplication. It lists new features and bug fixes. But I don't think it's really about logging project changes. Its main audience is users and they want to know how new updates affect their experience with the program. Most of them don't really care about changes deep inside the application, only about things that are visible on the outside. A user doesn't really care about things like code refactoring (and he shouldn't), unless he's using this code directly. He only cares the benefits it provides, for example refactored code can lead to improved performance (and this can be important if performance hindered program's use).

Many, many projects only talk about changes to the project, but don't really talk about what it means to the user. Often it's possible figure that out, but what user thinks in many cases is quite different from what developer thinks. This can lead to unintended confusion.

I added support to Xelog to document this aspect of the changes. Each entry in the change log needs to have an impact flag to indicate how much a user is affected by the change. It can be something minor, such as a spelling fix, or something that can break things, such as public interface change, document format change and so on.

In addition to the notes describing the change and impact flag, there's a new text field to allow developer describe how the new update affects the user. Its purpose is to allow developer explain what effect he thinks the change will have. It's a good place to describe how to adapt to the new data format or how to use new feature to its fullest.

I've updated old views to display impact information for each change. In addition, I'm going to add views focused at showing change log with emphasis on this user impact. I want to help anybody reading the change log to understand which changes are important and provide new, cool functionality, and which are minor and thus can be ignored.