CAGD Version 4.0

It’s the 30th of August, 2016, and I’m sat in my office at home doing some last minute testing of a project that I’ve been working on since the summer of 2013, just before I push it live. It’s been available as a beta-testing site for quite a while, but I have to confess to some last-minute nerves before publishing, not least because it’s quite a significant change to a piece of software that a considerable amount of people use daily to organise activities within the School of Art, Architecture and Design.

For a whole bunch of people — this year’s first years mostly — there won’t be any change at all, since this will be the first time they’ve come across CAGD. But for all the staff, the second and third years it will be quite a change. Hopefully a positive one.

I wanted to write something then, that explained why I’ve made significant changes to CAGD, what those changes are, and how they should make any future changes and improvements (along with the day-to-day maintenance of a big system) a lot simpler than before.

I first realised that I need to do some major refactoring about four years ago, when I was trying to add a much more whizz-bang interface to our built-in calendar. CAGD has always been a very simple server-based application — you click on a link and the server does a whole bunch of stuff and sends you the page you asked for. The more interactive I tried to make it though (with drag-and-drop and resizing and the like) the more I started to rely on more modern techniques that only send the parts of the pages that have changed.

Initially this was manageable, but there came a point where retro-fitting this into an aging piece of software started to become too messy, and I had to accept that if I wanted CAGD to move significantly forward I was going to have to scrap the whole thing and start again (mostly) from scratch.

CAGD is now split into two parts: the server, which does all the hard work behind the scenes to tell (for example) who belongs to what groups, and what type of file something is; and the client, which lives inside your browser and displays the information that the server gives it.

(For the inquisitive, the server is hosted on Microsoft’s Azure platform, written in PHP using the Slim Framework to present a REST interface, and stores all its data in a MySQL database. The client is written Javascript, using Backbone.js as its framework.)

The nice thing about this from my point of view, is that it separates different concepts in the sofware from each other, and allows me to concentrate on them without disrupting the others. For example, if a response from the server is slow I can fiddle around debugging it without messing up the interface.

As well as this, I can chuck extra resources at the different parts as we expand. Previously everything went through one bottleneck, and to increase capacity was quite a challenge. Now we can do cunning things like load-balancing the servers so that as demand increases we just automatically switch on new servers.

It also means that it’s very easy to create new clients for different devices. It’s what’s enabled me to make a decent crack at the mobile interface, without having to reinvent the wheel.

One of the mose significant things though about refactoring a website, is that it gives you the chance to revisit some ideas and make changes to some of the decisions you made in the past, taking in new ideas that have cropped up with use. Some things which initially seemed very important turned out to be quite trivial, and other things took centre stage.

The most obvious place where you can see this is the Journal. Originally it was supposed to just be a simple method for delivering feedback, but as we used it more we started to adapt it to different teaching strategies, and it’s now possibly the most important feature of CAGD. Things like the Uploads and References used to be the main focus, but this new version has allowed me to rethink that, and consolidate teaching and personal development into the Journal instead.

We’ve struggled in the past to clearly define what an “Upload” and a “Reference” is to the students, and it’s not only caused a fair bit of confusion, but also left a huge swathe of files in the system presented without any contextual information or metadata. Because it’s so easy to chuck a whole folder of images online (and less easy to then go back and label them properly) there are thousands of uploaded images that only have “IMG_0000” as a title, and no explanation as to what they are.

By shifting everything into the Journal, and making it the place where you upload your work and your research material, and also making it explicitly obvious where and how to add reference information, we can help students reference their research properly, and lay claim to their own work. As well as being good practice, this also makes the process of assessment and feedback a lot more simple.

Another thing that I’ve been able to rethink, is the structure of the groups within the system, in particular the difference between ‘teaching groups and ‘community groups’. In the previous version, everything was just lumped together, but I’ve restructured things slightly to draw attention to the differences between spaces that are intended purely for academic purposes, and spaces that are for more wide-ranging activities. This has also meant that I’ve been able to put things in much more readily-accessible places, so you can access all of the modules that you either teach or study from the top-level “You” category.

The icons for Modules tells you how many credits they are worth. One piece of pie equals twenty points.

Staff can then build these modules up as they need them, and structure any assessments/submissions in a way that are quick to find for students, rather than having to dig through a large hierarchy of groups.

I’ve also had the opportunity to address one of my most frequently-asked questions/requests: being able to edit or delete Journal entries.

One of the most significant but surprising aspects of the CAGD Journal is that you can’t edit entries after you post them. The reason for this is in order to preserve their integrity — they act as an authentic record of your development over the years. Rather than allowing edits and deletions, my approach has been the acceptance of any mistakes that are made within it, and that those mistakes should be explored and documented. The point of the Journal is to be authentic with yourself, and allowing editing/deletion would hinder that.

Having said that, I’ve never really had much of an answer for people who post things by mistake, or where there is a technical glitch — where the mistake is as a result of my coding rather than something that person has done.

The way I have addressed this issue, is to make it so that all entries are fully editable up until the point at which they are accessed by someone else. (“Accessed” is important here, because there is a difference between someone accessing a journal entry, and actually reading it.) You can then, on noticing a mistake or a typo or something, click on an entry to start re-editing it. Doing so reverts it to being in a ‘draft’ state, and it won’t be visible to others until you re-post it.

People have been asking me for these tools for about ten years.

The other thing I’ve been able to do with Journals is make it so that certain entries can be made public — visible to other members of the site, and not just staff. You can also subscribe to Journals that you find interesting, and see who follows yours.

This is part of the community-building aspect of the redesign, and will allow staff to separate things of interest (which can now come from their journals) from the important course-management announcements.

Also, for the first time in almost a decade, I’ve used a font that isn’t Helvetica.

I’ve split the typography of CAGD into three parts:

1. The user-interface text.
2. The conversational, informal text.
3. The formal, published text.

Informal text is things like messages between people, comments, private journal entries — things where the audience is personal, informal and private. There’s an aspect to these conversations of preparing, sketching things out, staging — and the informality of monospace type seems very appropriate.

We’re using Input, from Font Bureau for this text. It’s a very fexible font for code, and well worth exploring. I’ve tweaked some of the opentype features to make it more legible for lenghty pieces of text.

A page from my Journal, showing Input.

One of the reasons for using a monospace font is the similarity of the conversational to the preparation for typesetting, by supplying columns of typewritten text. The formal text on CAGD then takes this idea and uses a proportional font for it, the idea being that certain parts of CAGD are to be read as being ‘finished’ and ‘published’ — the public journal entries and the group announcements for example. For these, we’re using PT Serif, from ParaType.

PT Serif, used in a group announcement. The little bookmark at the top right is the tool to bookmark an announcement.

Finally then, the user interface font is New Rail Alphabet, by Henrik Kubel of A2/SW/HK in collaboration with Margaret Calvert. I have a theory (that I need to do some considerable research into) that the best source of reference for ways of navigating through large online systems of information, are public transport wayfinding systems, and one of the most appropriate of these wayfinding systems is that of British Rail.

New Rail Alphabet, used for UI elements

(Why New Rail Alphabet and not Transport, as used on Transport is designed to be large and read driving past at speed, in short lengths, not as body text. Rail Alphabet was designed to be used not only as wayfinding on stations, but also as body text, to be able to be read over longer periods of time. I still think it was a mistake for to use Transport.)

This version also sees the introduction of a new interface element — a ‘drawer’ on the right hand side of the window that pops open allowing you to choose different objects depending on the circumstances. For example, when you’re putting together a group for something it will pop up with either a browseable list of people, a search field, or your bookmarked people.

When you’re orgainising your work into folders, it will pop up and contain your bookmarked folders and work, or all of your folders, or a searchable list of all of your alread-uploaded work.

Adding some old work into my portfolio, using the sliding-in drawer.

This should make it easier to organise stuff in CAGD, and by making it the same interface across many different areas (it’s also used when sharing a file with a group for example), it should become very convenient.

There are, of course, a fair few loose ends that I haven’t been able to tie up as yet — some of which are little interface inconsistencies, some are features that exist conceptually but haven’t been fully implemented yet.

One rather significant unfinished feature is the ability for groups and individuals to publish “collections” of things externally. The existing feature of building a website around a folder, or sharing an upload externally with a short link (or on Twitter) is still there (and the publishing interface should be greatly improved), but I haven’t yet had the time to properly polish this idea of Collections. What I’m envisaging is something that will allow you to create a collection of things within CAGD that is linked to some external outlet — a Wordpress blog, or a Twitter account, or a Symplectic account (so staff can publish their research), or just a simple website — and have it perpetually in sync.

I’m also only half-way through the process of building syncing systems to tie our data to the University’s main records, so that all the timetables are the most up-to-date, and everyone is properly enrolled in the right Modules and on the right Courses.

But, as I said, I’ve been working on this new version for about three years now, and I’m confident that it’s at the point where it’s ready to be used on a daily basis. Once everyone has had a chance to get used to it, and I’ve spent some time ironing out the inevitable bugs that I’m sure will appear over the course of the next couple of months, then I can get on with fleshing some of these ideas out.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.