Reflections on the Design

In this post I discuss the development of the “new” user-interface for, and how it has shaped up. Now is a good time for a review because it has been a bit over a year since I released the new interface for the open-source GroupServer mailing-list manger (11 June, 2013) and a bit under a year since I deployed the interface for (5 November, 2013).


My first step in the redesign was sitting down with Dan and discussing the fundamental concepts that needed to be expressed by the new design: things like people are members of groups, posts made by the members are organised into topics, groups belong to sites… We then started discussions with Mike Harding at Cactus Lab, who questioned our assumptions, pushed our concepts, and created the early static prototypes.

We did all our work, including the prototypes in monochrome. This ensures we use colour to enhance information, rather than causing accessibility issues by conveying information using colour. It also allowed us to concentrate on the layout and typography. It has resulted in a design that remains usable even when entirely in monochrome, as is shown by

The design was made for the desktop first, bucking the current trend for creating prototypes for small-screen devices that are then altered for larger screens. However, on each page the design did have to present a hierarchy of information. Identifying the hierarchy for each page — and presenting it clearly to the person viewing the page — made the design of all forms of the various pages much simpler. I see mobile first design discipline as primarily a way of identifying the information hierarchy; because our hierarchy was clear to us we could create a design that was also clear to the people that use without going through a mobile-first process.


I started by developing the page for a single post. While rarely seen, it sits at almost the base of the information hierarchy and incorporates much of what needs to appear on other pages. I then spiralled out from there, working on the image, topic, and group pages. At each stage I would learn more and tweak the designs of the earlier pages, further evolving my understanding of the design. By the time I had finished the group page I had most of the design for all of GroupServer finalised.

I tried as much as possible to implement the new design using just CSS, altering the HTML as little as possible. This allowed me to gradually release the new design to production sites, using the skinning system in Zope to serve up both the old and new designs as needed. We wanted to do this, rather than switch everyone over at once, in order to gather feedback, improve the design, and warm up the existing user-base at


The markup is XHTML5. I chose the XML-variant of HTML because I appreciate the extra automatic validation that is possible with XML. I used very few of the newer features of HTML5, because at the time of development and deployment we had a significant number of corporate clients that used surprisingly old version of Microsoft Internet Explorer. However, as time progresses newer features, such as responsive images, are being rolled out.


Microformats are used to provide generic CSS class names with the new style, as they were for the old design. I use microformats because it ensures I use consistent class-names across all of GroupServer, with the added benefit of search-engine optimisation.

Once I had implemented design for the desktop I implemented the breakpoints for the responsive design. I did this simply by narrowing my browser window to identify when things looked incorrect on the post page, topic page, and group page. I then added a width-specific media-query and then repeated the process until I could confidently narrow the pages down to a screen as small as a feature-phone.

The CSS class names and ID attributes that are specific to GroupServer tend to be long in comparison to those used by other projects. This is because I encode the name of the module that produces the CSS, and is usually responsible for the associated JavaScript, into the identifier.

I avoided using SCSS because of the open-source nature of GroupServer. The biggest problem we have with GroupServer is installation, and I could envision the addition of SCSS complicating an already complex problem. Instead I use a system with two files: one provides the core layout and typography for GroupServer, while a second provides the colour. We currently have two colours in addition to monochrome: blue and green.

Web fonts are not used in the new design, with Helvetica used as the primary typeface. This typeface reflects the generic nature of GroupServer, and the old-school charm of mailing list managers. It also avoided the performance problems of web fonts.


The hardest change was the switch to Twitter Bootstrap from jQuery UI. The differences between the two systems were many, and on reflection it required the bulk of my effort.

Sadly, soon after I released the new interface a new version of Twitter Bootstrap was released. I have avoided updating Bootstrap because of the difficulty caused by the switch from jQuery UI.


Web performance was very important to me as I implemented the new design. (I have spent a long time at the wrong end of the Southern Cross Cable, where 250ms round-trips are common, so I consider performance to be a concern for all devices rather than a concern specifically for mobile devices.) Early on I decided that the most important measure was the time to glass: the time taken between a page being requested and something appearing on the screen. I achieved most of the performance gains through careful thought about the information hierarchy and optimising the use of JavaScript. I also optimised the images, and used an icon font to speed rendering.

Thinking about the information hierarchy helped with the performance optimisation. With the group page, for example, the important static content, such as the name and the About box, are rendered first. Then AJAX requests are made for the dynamic content: first the most recent topics are requested, before the requests for the lists of most recent posting members and files are made.

The JavaScript is usually deferred, often asynchronously loaded, and almost always minified and in strict-mode. I wrote my own loader, based on advice from around the Web. However, in the future I would like to switch to a system such as Require.js.

The images, such as profile images, are heavily compressed in comparison to many sites. Large images have relatively “high” quality (or low compression) set, at 75%, which is still much lower than the 98% quality that is used when posting photos to a group. As the size drops the quality also drops, because it becomes harder to see the compression artefacts (the strange square ghosting in JPEG images) that appear. For the tiny 20×20 pixel profile images the quality is dropped to 40%; in addition data URIs are used to embed particularly small images in the page, reducing the need for an HTTP request.

Leave a Reply

You must be logged in to post a comment.