Plugins research summary

I seem to get a fair few emails from people interested to hear me elaborate more on the subject of my research these last few years, so now that I have a few minutes, I thought I’d write things out to explain a bit more. Firstly, a warning, my writing style is simply that of a braindump – I don’t mull over my posts so they are not necessarily complete or polished. Blog posts are intended to spark discussion and thought, and I am more than willing to elaborate either publicly or privately – my contact details are clearly visible to the right.

So my research most recently has been in the field of the semantic web. Before that it was in plugin-based systems. In both cases, my home language was Java, simply because I really do like the language, and it is the one I have invested the most effort to learn its nuances. Despite this, the concepts developed in both research areas is really language-independent, so feel free to contact me even if you don’t use Java.

My plugin research was really about enabling at a very low level the ability for an application to be broken down into separate but interrelated building blocks. Ideally, such a system would end up with a tree structure, as this enables the ‘leaf nodes’ to be relatively independent from each other, whilst still being able to draw from a common kernel. This research was based around a complete rearchitecting of Centruflow, which resulted in a base ‘kernel’ plugin which takes care of the core functionality such as server communications, caching, logging, security, xml parsing, etc, etc, etc. From this plugin a separate plugin is launched that provides all the basic user interface components. From this basic user interface library, all the functional plugins can embed their user interface components.

In Centruflow, the entire application consists of plugins. Each plugin offers zero or more extension points, and zero or more extensions, which plug in to the extension points. In general, all plugins offer extensions for either the kernel or the base GUI layer, but it is not uncommon for a plugin to offer its own extension points. With this design, it is possible to have any number of layers in our plugin hierarchy, meaning Centruflow can easily entertain new functionality that was not necessarily ever considered in the original design specification.

That word – ‘functionality’ – is an important word. This plugin architecture really means we try to break each plugin down to offer a distinct aspect of functionality. This makes it very easy for different users to receive a very different user experience simply by varying the plugins they receive. As packagers of the Centruflow product, this is trivial – each plugin is a single zip file with a descriptive name. The exact functionality offered to a user is based on the files included in a distribution. For example, Centruflow has both a ‘standalone’ and an ‘enterprise’ version, each of which simply varies by one plugin; the rest of the Centruflow application remains the same. Of course, other kinds of functionality such as scheduling, reporting, amending, searching, tagging, etc, etc, etc can all be dropped in for either version.

This plugin focus is really useful from a developers point of view as well – it means that we can easily and quickly change focus should priorities change. Also, because of the plugin hierarchy I mentioned, we actually receive compile-time errors when a plugin is trying to use code that it should not depend on. This is possible because each plugin must declare which plugins it depends on. This means that our code remains cleaner as there simply isn’t that possibility to write spaghetti-code.

As mentioned, this is how the Centruflow client is written. On the other side of the coin is the Centruflow Server, which is the area in which much of my ‘semantic web’ research has gone. I was planning to write about my more recent research into semantic web technologies such as RDF, OWL, SPARQL and heterogeneous data merging (i.e. generating virtual data stores that are populated by multiple datasources, and can be queried using SPARQL and represented visually using Centruflow), but I think I’ll leave that for another post.

Please, if you have questions, feel free to email me or leave a comment here. If you are interested in me discussing a particular topic, feel free to ask me.

Ten UI Lessons from the Real World

This is a good article about user interface design, which is something I’m quite passionate about. I enjoy creating user interfaces that are simple but functional. Centruflow is an example of this. Inside our company, I have put up a set of rules that all UI designers/developers need to follow. I thought I’d repeat them here:

  1. KISS principle — Keep It Simple, Stupid. You don’t need to make everything customisable and you don’t want to overwhelm your users with a multitude of options.
  2. Make it ‘just work’. Automate as much as you can. Try to have configuration options that either will work in the vast majority of cases with the defaults, or have the application automatically try to determine the best settings for the user’s environment. The best configuration dialog is one the user never has to see.
  3. Softer software — make things customisable, but in a way that they don’t HAVE to be customized for a good user experience. Most users won’t customise their environment very much. Always keep this in mind.
  4. Present as little of the interface as necessary to accomplish the task at hand. Better to have more dialogs or dialog tabs with a few options than one big gargantuan dialog that has everything.
  5. On layouts — put the most commonly-used controls in a very prominent place and make them big and easy to click on. Things that are less likely to be used should be smaller and out of the way. Buttons are better than menus, but don’t end up with so many buttons that the user gets lost — again, fewer controls on more windows is better than more controls on fewer windows.
  6. Know your audience.

I boil it all down to the last point – unless we are developing for other software developers, we should consider our user interface/interactions very carefully, and from their perspective. I would recommend everyone to develop a set of UI rules that all developers within a team should read once in a blue moon to remind themselves of what is important. Just copy the above ones if you want.

On that note – users (as opposed to customers – quite often different people) don’t care that your software is using a RESTful webservice that connects to a messaging server that allows for Enterprise blah-di-blah – the user interface is the program to them. If they can’t find the functionality they need the software may as well send messages via courier pigeon.

One other thing – as the lead tech guy at Centruflow Ltd it’s important to have cool features implemented and integrated into Centruflow based on customer feedback – but the development of any feature only begins if an intuitive integration is possible. I believe it’s my job to provide a first layer of protection against any ‘feature creep’ that might begin to invade the context menus, toolbars, menubars, control panels. We need to always keep these areas as clean and as intuitive as possible. The question should always be ‘how do we expose this functionality intuitively but without costing much UI real estate?’.

Well, that was a bit of a braindump, sorry for the mess – I’m running out the door to CeBIT and wanted to throw that out there. Maybe one day I’ll come back and clarify my points. Remember to read this article too if you have time.

Inactivity

I’ve been pretty quiet on this site recently, and for that I apologise – I’ve been working full-on on Centruflow leading up to CeBIT in Germany. Well, right now I am in Germany at CeBIT, and Centruflow is getting a lot of interest and positive feedback.

Of course there is always more to do, but CeBIT has really helped clarify what needs doing, and what is most important to customers.

I make no claims at being any kind of photographer, but my photos are available to see no longer available – sorry! They are all a little blurry as I have scaled them down to be web friendly, and to be fair, were mostly taken whilst I was walking. Maybe they may be enjoyable to some people (not least my family).

Anywho, busy few days just been, busy few days ahead, so I’m turning in. Today I met Pete Hodgson (New Zealand’s MP for research and science, among many things), and tomorrow is New Zealand day, so things have been hectic. Time for sleep.

Java FTW

Following on with the revelation that I’m not particularly ‘with it’, I always wondered what the acronym ‘FTW’ actually meant. I actually got around to checking out the meaning the other month, and straight away, people stopped using the term. Alas, to paraphrase Grandpa Simpson, “I used to be with it, but then they changed what “it” was. Now, what I’m with isn’t it, and what “it” is seems weird and scary to me.”

Anywho, on to the topic at hand. I got myself a nice new Java book the other day, entitled “Java Concurrency In Practice”. It has always taunted me from afar on the Amazon website, but for the last two weeks I have been living in Wellington (I’m back home now though). Whilst there I checked out Dymocks bookstore, and was happy to see they had it in stock. Given that I was once gifted $700 worth of book vouchers for Dymocks, and I had the vouchers on me, I picked it up, probably only at a 100% markup over Amazon…

I have only managed to read the first half of it so far, but it is an awesome book if you are a middle-to-advanced Java developer. The reason why I haven’t read the whole of it yet is that it is constantly giving me ideas on how I can improve Centruflow. Everytime I read a new page I tend to run off to my codebase and make changes. These changes improve the speed at which Centruflow can do certain things, whilst ensuring we don’t encounter any of the nasty race conditions, live lock, deadlock, etc. The book tends to focus on the improvements made to concurrency in Java 5 and 6, which is fine for me as Centruflow is targeted at these versions anyway.

You may wonder, “Jo – you’ve been in university studying software engineering/computer science for five years, shouldn’t you know all this already?”. The answer is simple: I learnt concurrent programming using a language called Pascal-FC, which from memory has no real relationship to Pascal. Learning in Pascal-FC had the side-effect that I didn’t learn concurrency in Java. Additionally, I learnt it in 2004, when Java 5 was yet to be released. As mentioned, Java 5 has a huge number of improvements to Java’s concurrency API.

So, to conclude – if you are writing Java applications and know the basics, get this book and read it. It will make you a better, more learned programmer. The amount of things I have learnt from half of this book is amazing. Java is seriously cool. To anyone who is anti-Java, give me a reason why, I’d love to know.

Thesis Complete

Well, it has taken a year of my life, but my masters thesis is now complete and ready to be reviewed by my supervisor and external reviewers. In hindsight I am very happy I chose to do my masters rather than a PhD – my preference in life is to be more practical rather than theoretical. Right now I’m about to get back into full-time development of Centruflow leading in to CeBIT in March next year – we have some awesome technology in the pipeline!

My thesis is titled ‘Improving Centruflow Using Semantic Web Technologies’. It weighs in at 139 pages or a little under 34,000 words. I start it by quoting Blaise Pascal “I would have written a shorter letter, but I did not have the time”. The thesis covers a lot of software development detail but at the heart of it is a decent chunk of maths. This surprised even me, as I am by no means a mathematician.

You may notice my writing style has become severely ‘relaxed’ – too much ‘proper’ writing in my thesis has forced my brain to try to rebel – my sentences now instead flow into each other as a series of hyphens. 🙂

If anyone is interested in checking out the thesis feel free to ask – I’m more than happy to hand send it out. The only reason I don’t provide a link here is that I’d really like to know who is interested.