I designed a Tactical Overview widget for the Icinga Web dashboard.


Donut charts enable one to have a lot of information in a compact format. As a nice side effect, they breaks up the rectangularity of typical UI elements, which makes them more interesting to look at.

Since we need to both display hosts and services, one approach was to combine two donut charts into one.

Ideation started with donut charts variations.

After some fine tuning and putting it in context, it turned out that this wasn’t quite appropriate. The graph is too detailed.

With these learnings I went back to the drawing board and focussed more on these points:


  • the amount of problems in relation to the total number of objects
  • make it graspable at first sight, if there is a problem
  • make the number of actual problematic objects obvious

While the first bullet was solved pretty well by the donut chart, it was not capable of fulfilling the remaining. It was clear, that donut chart are not suitable for complex or detailed data, so I went back to rectangles.

This is the final widget with which I came up, which checks all the requirements.

There are different grades of detail for the objects squares. So when there’s only a few they’re display pretty large. This makes it easy to grasp how many there are on the spot. The more objects there are the less important the actual number of items becomes.

Up to six objects are display pretty big. The more objects there are, the less detailed the display becomes. Important detail information like the actual amount of critical items is displayed as a number.

The final mockup clarifies, that this approach is a lot more balanced between »first glance« rough information and »second glance« detail information.

To get even more detail information, the user can interact with certain parts of the widgets as well, which would lead him either to a list of object or a detail view. Also there’s a tooltip showing the actual name of the object, when hovering a tile.

Icinga Web is the web interface for Icinga. Although a lot of the features of Icinga are better used via command line, this cumulates most of the day to day functionality in a user friendly graphical interface, that even non technical people can use.

The central part of Icinga Web is the monitoring module, which had to be completely rewritten to work with the highly anticipated Icinga DB, which is the new database interface for the Icinga core. This was the chance for a fresh UI redesign.

For the first version we wanted the new UI to be more consistent, visually clearer and provide more viewing options.

With the Icinga Rebrand to be rolled out, we wanted the Icinga Web user interface to reflect the new visual language. Since the new branding was mostly light on dark, I prepared drafts for a dark theme for Icinga Web.

Theming was an integral part of how Icinga Web was built. But we also wanted to adapt the UI to the Browser preference and enable an automatic switching, which required some extended functionality.

Defining a color palette

The first step was to define a rough color palette. Sidebar and viewport background were the first, since it was the most prominent color for the theme. We kept the status colors, but went for a new primary accent color.

Refining the palette

After I found a harmonious palette for the start, I implemented the new themes, so I could immediately see, how the colors work. Since the base background color of the viewport wasn’t pure white/black, I started tuning the grays and tinting them with subtile blue-ish shades.

Introducing Theme Modes

In addition to separate themes, we found that there has to be a relation between the flavors of a theme, a.k.a. light and dark mode. So the development team extended the theming engine with theme modes, enabling theme developers to define separate versions of their theme depending on the user’s preferred color-scheme.

I helped them implement the themes for the new engine. In the implementation process we did some further refinements and tidied our whole variable system to reflect a proper palette system and rename the variables accordingly.

With a new setting in the Icinga Web Preferences, the user can select a distinct theme mode or make the theme adapt to the browser settings.

Sewobe is the development company behind the most popular German association management software.

The software itself is highly modular. This project was a complete big visual overhaul of their man products. Especially the end user facing interfaces got a lot friendlier and clearer.

This challenge was to develop a solid design system, that provides reusable user interface components. The software itself consists of different small modules, so it was important to have a main menu with a flexible structure. The UI was should also adapt to mobile layouts, while still providing all its functionality.

Setting a consistent product character

Modular interface framework

The sidebar navigation was divided into categories that reflect the module structure. The viewport displays the main module views.

My Role

  • Project Management
  • UI Design
  • Frontend Development

This project was comissioned by Pre-IT for Sedlmeyr Spezialtüren GmbH.

The Client

Sedlmeyer Spezialtüren GmbH offers configurable doors for indoors and outdoors.


To showcase their offerings of custom made door variations to the customer on-site, he wanted an app that they could use on an iPad. The customer could use the app to configure their custom door directly. Since it would have run on an iPad, we customized it for mobile Safari and the corresponding display resolutions. But we wanted to stay flexible enough, to customize it for other platforms at a later time.


It was most versatile to build the app as a one page web front end, that get its data from a remote database. The door visualization consisted of multiple stacked layers, that were replaced by what elements the user would select.

After committing the basic features, it was quickly clear how the app layout would look like. The customizable layers were the environment, the direction of the door handled, the door layout, side parts. Apart from that there were also the door’s materials for the different parts of the door. To make the layout clearer, the materials were categorized.

Finally the user should set the color of the facade, to see if the door colors would match their custom door.

User Interface Design

I saw it a good idea to make the app feel close to a native app experience, so the designs were made close to the iOS Human Interface Guidelines and resembled common user interface elements.

This is the initial state of the app.
From the assets in the sidebar the user’s clients can configure their custom door.
An app icon set made sure, that the user could find the app on their home screen immediately.


The app was developed as a single page application, that retrieved the assets from a database. The user interface was built with the Javascript framework MooTools, AJAX, PHP, MySql and ran on an Apache web server.