One of the common criticisms/complaints that we have received about the 1.0 version of the Blog Writer is the user interface. 1.0 is very functional and has quite a few features, but the UI is cluttered and just feels "busy". We have done/are doing our best to address that issue with Raven. In this post, I will talk a little bit about our approach to the UI within Raven.

General Approach
We are trying to take a more context based approach to Raven's user interface. What I mean by that, is that the UI will tend to dynamically change based on the selections that a user makes. The idea is to show only the information that is relevant to what the user is currently doing. I think that a mistake we made with version 1.0 was to cram too much functionality in too little an area. For example, Raven will have many more context-menus (right-click menus), as well as controls that hide and show information as needed. We are trying to stay away from windows that show everything at once.

Interface
The default user interface in Raven will be broken out into two windows, much like other applications of its type. The two windows will be the "management" window, in which the user will see a "perspective" of their data. This perspective includes their Accounts, Blogs, Blog Posts, etc. The data shown in this window depends on the user's selection in the Account Navigator sidebar. For example, when the user selects an Account in the Navigator, information about the Account is shown. When the user selects the "Posts" item under a Blog, a list of Blog Posts that have been published to that Blog are shown. Perhaps a screenshot to illustrate:

The above screenshot shows the "Posts" sub-item under the "Paalin's Test Blog" Blog in the Account Navigator tree view. (Note: this UI will still change in a variety of ways, including different icons, additional toolbar items, full preview tab in the lower context pane, etc. This screen shot is just to give you a general feel for the new UI)

The second primary window in Raven is, of course, the editor window. I'm sorry to say that the editor is still enough of a work in progress that I don't have an acceptable screen capture of it. However, I can say that the editor is a tab-based editor, meaning you can finally edit multiple blog posts at the same time. In addition, we have created some custom controls that should ease the screen clutter somewhat. The biggest problem (and this may be the topic of its own post in the future) is designing a UI to let the user specify and configure multiple Blogs. For example, a single Blog Post can be published to more than one Blog. Each Blog may have different categories, timestamp info, draft status, etc. Again, I'll probably talk more about this issue in a future post.

Perspectives
The above screenshot shows the default, "Standard" perspective. The Standard perspective is designed to feel much like a typical email client, such as Outlook or Thunderbird. However, Raven supports multiple perspectives. For instance, we may create a Calendar perspective, which might be a more targeted user experience, allowing the user to more easily manipulate and schedule the publishing of blog posts. Or, if a lot of our users prefer the Blog Writer 1.0 interface, we may implement some sort of "Retro" style perspective. In addition, third party plugins could contribute their own perspective, effectively taking over the entire presentation of the data.

Extensibility
Another issue that we are addressing with Raven is extensibility in the UI. I have already discussed the Extension framework in my previous "Zoundry Raven: Extensibility" post. However, let me take this opportunity to talk about some of the ways that framework impacts the User Interface. Raven will come, out of the box, with a variety of UI related extension points. Using the above screenshot as an example, off the top of my head I can think of the following extension points (not an exhaustive list):

• Main Menu: plugins can contribute new menu items in the main menu.
• Main Tool Bar: new toolbar buttons can be contributed by plugins.
• Context Menus: when the user right-clicks on items in the Account Navigator sidebar (an Account, Blog, etc) a context menu is shown. Plugins can contribute to those menus.
• Blog Detail Panel: when the user selects a Blog Post in the upper-right pane above, multiple details panels are displayed in a notebook-type view in the lower-right pane. In the screenshot you will see 'General', 'Links', and 'Media'. Additional details panels can be contributed to display other information about a blog post.

There are a variety of others (with more to be added, I am sure), but I think you get the idea. This UI extensibility provides third party plugins with an opportunity to extend the functionality of Raven in a variety of ways.

For my first few posts, I want to focus on some of the goals that we have for Raven. One of those goals is for the application to be as extensible as possible. For us, extensibility means easily adding new functionality to the application via the creation of plugins. In this post, I will talk a bit about our plugin system and what sorts of benefits we get from it.

Plugins/Extension Points
Our plugin system will be extremely familiar to anyone who has worked with the Eclipse Java IDE plugin system. A Zoundry Raven plugin consists, minimally, of a plugin descriptor file called zplugin.xml. The zplugin.xml file defines the ways in which the plugin will be extending the application. Here is a simple example:

  <zoundry-plugin xmlns="http://www.zoundry.com/schemas/2006/03/zplugin.rng"
                  version="1.0"
                  name="Zoundry Common User Preferences"
                  id="zoundry.raven.appframework.prefs">
      <dependencies>
          <depends on="zoundry.raven.appframework.services" version="1.0"/>
      </dependencies>
      <!-- My Contributed Preference Page -->
      <zoundry-extension point="zoundry.appframework.ui.preferences.prefpage">
          <id>zoundry.appframework.ui.preferences.prefpage.myprefpage</id>
          <class>foo.bar.ui.prefs.prefpages.MyFirstPreferencePage</class>
          <extension-data>
              <prefpage>
                  <parent/>
                  <name>My First Pref Page</name>
                  <description>This is an example preference page.</description>
                  <header-image>images/prefpages/foobar/header.png</header-image>
                  <icon>icons/prefpages/foobar.png</icon>
              </prefpage>
          </extension-data>
      </zoundry-extension>
  </zoundry-plugin>

The above sample zplugin.xml file defines a new Preference Page that would appear in the User Preferences dialog. In short, new functionality is contributed to the application via extension points declared within the zplugin.xml file found in each Zoundry Raven plugin. In the above example, the plugin is contributing a new User Preference page via the zoundry.appframework.ui.preferences.prefpage extension point. In this case, the plugin would also need to supply the actual implementation class called foo.bar.ui.prefs.prefpages.MyFirstPreferencePage by including some compiled python code as well, but the details of how that is done are beyond the scope of this post.

Extensions Without Python Coding
Now, not all extension points will require compiled python code. There are some extension points that are meaningful simply based on their zplugin.xml declaration. For instance, the application exposes the zoundry.blogapp.mediastore.site extension point, which allows a plugin to contribute a new place to upload media (e.g. images). The extension point would only need to include, for example, the default FTP information for a site. This would allow Zoundry Raven users to easily configure their account at the given site for media uploads. In other words, if a particular FTP-based image hosting company wanted to contribute a plugin that would cause their specific information to show up as a first-class option when a user configures a Media Store in Zoundry Raven, they can do so by simply contributing nothing but the zplugin.xml declaration XML.

Extensible Extensions
Finally, the plugin system (I really love this) is itself extensible! Zoundry Raven will ship with some set of extension points that plugins can contribute functionality to. At present, I would say we have about a dozen or so extension points. However, when a third party plugin contributes some functionality to the application, they may want their functionality to be extensible. This can be accomplished by contributing to the zoundry.extension extension point. The third party functionality can then access the Zoundry Raven plugin registry and query it for any extensions contributed to its extension point. In this way, other plugins can extend the functionality that was provided by the original third party plugin.

Extension Validation
Finally, it is worth noting that extension points will have a Relax NG schema associated with them when they are declared. This schema will be used to validate the XML found in the zplugin.xml file whenever a plugin contributes to an extension point. In this way, the application can be more confident that the extension was properly declared. In addition, for those extension points that require that a python class be specified, the schema will indicate what type (interface/base class) the contributed python class must be.

Ok, so now you know a little bit about how our plugin system works. In my next post, I will hopefully talk a little bit about the main application UI and provide a screen shot of how it looks at the moment (still in progress).

Labels: extensions, zoundry

Welcome to the Zoundry 2.0 Development Blog. This has been a long time in coming and I apologize for the delay. Although it's not a great excuse, we've been pretty busy trying to get Zoundry 2.0 into an alpha state so we can get it out to early testers.

Please note that the code name for this product is "Raven", so from now on I will most likely refer to version 2.0 of our Blog Writer product as Zoundry Raven. I think this is a lot easier to manage than "Zoundry Blog Writer x.x".

The reason for this blog is for us to keep our community informed of our progress and, more importantly, to solicit early feedback on the features we are implementing. My hope is that we will post updates here frequently (and with screen shots!) so that everyone can keep appraised of our progress.

My first post (to be written soon) will simply describe the architecture of Zoundry Raven and hopefully give you an idea of why it is taking us so long.

Good night, and good blogging.

Labels: zoundry