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.

I'm slowly getting back to work and added a new feature to Xelog to allow users change views on the fly. You can look at the current Xelog log or example to see it in action. For now this works only in IE or Mozilla.

Currently the process is slow and takes several seconds. I suspect part of the problem is that the browser doesn't cache downloaded files and re-downloads all stylesheets every time the view is changed. I'm not very happy with delays and at some point I want to optimize both load time and change-view time.

I added this feature to allow Xelog easily support a large number of views. Even though the data is always the same (change log in XML file) there are different ways to show it. This approach allows Xelog support a number of simple views each focusing on showing history of changes in a specific way instead of having one dynamic and complicated view that tries to fit all needs.

For example, simplest view shows timeline of updates. It is important for people who track project progress and want to be aware of the recent changes. A different view can show updates grouped by components and their impact on usability. This kind of view is important for the users looking at "what's new" in a new release. It provides a picture of how the project changed since the last version.

In time I will also allow developers who want to use Xelog for their projects to create custom styles that fit their website. I want to give as many choices to all users (developers and end-users) as possible, while providing working features out of the box if there's no need to customize it.

Using this feature I also want to add support for different media used to show the change log, such as HTML (currently supported), text, PDF, RSS and so on. Developer can choose just one method of saving and distributing history of changes, or he can distribute original XML file and end-user will be able to save the change log in PDF for printing.

Here's how it works. When application loads it saves a copy of the change log in memory. All views will have a common area on top of the view where a combo box to select a view is provided. When a different view is selected JavaScript loads XSLT for the view, generates new HTML from the change log and updates the page with it. To update the page with new HTML I'm using Dojo's ContentPane widget, which parses HTML for things like style tag (browser doesn't apply some of the tags, such as "style", if innerHTML is used to set new HTML).

Sider is not the only project I'm working on. I'm also occupied by Xelog (XML log), an application to help manage change log for software projects and shows it with different veiws (web page, text file, PDF, etc). I started wiki for the project and have online example.

I started this project when I faced the problem of having a history of changes for JSForms. I was considering generating a change log from the history of SVN commits or from the fixed issues list, but I don't think it can be done in intelligent, simple manner. Change log is usually written for the user to show what's new and updated in the application. Source control and issues comments usually written for developers, to help understand the changes and remind about them when the code is read at a later date. In most cases the change log has to be written by hand.

I decided that if I'm going to manually create and update a separate file just for capture history I want to have a standard, cansistent way of doing it. I figured XML is versatile and well suited for storing data, so I'm using it.

Xelog XML schema describes the change log XML document structure. It's handy, since many XML editors can use it to provide auto-complete support.

XSLT is used to have different views. At this moment there're two views (both show log in HTML) and there's no way to change the view. In time that will change.

I also want to add support for writing the change log using browser instead of XML editors. It will abstract away the XML document from the author and simplify log management.

The project is free and open source. Forum is open for discussion. You can also read issue tracker or project change log. I'm still working on the code and will to release it as soon as it's usable. If there will be people interested in contributing I'll set up an online SVN.