Our journey building Firefly 6 and the lessons we learned along the way.
In part one we took a whistle stop tour of the year-and-a-half it took to design and build Firefly 6. This time I will discuss some of the front-end technology and practices we used to help us build better, more robust software.
We built a pattern library
Until Firefly 6, it was usual practice to build features one-by-one. There was little re-use of code, meaning if we found a bug with an element, then we’d have to fix it multiple times.
What we needed was a pattern library! In October we were joined for a few days by Anna Debenham who literally wrote the book on front-end style guides to help us catalogue Firefly’s user interface.
We used this to build a “single source of truth” library of interface elements. This means that Firefly is now essentially built from a kit of parts. If we need a button, we can just call one in from the library. Even better, if we find a bug with the button, we can fix it once, and it’s fixed everywhere. Much faster and a lot more robust.
I also have to mention Danielle Huntrods, a contractor who worked with us for almost a year, during which she built the majority of the of the pattern library. It was her brilliance that gave us such a solid foundation for the future.
We plan (at some point) to release a publicly accessible version of the pattern library. This is part of our ongoing commitment to openness and giving back to the web community. Hopefully others will find what we’ve done useful.
We flattened the cascade
Cascading Style Sheets, or CSS, is the language that allows us to define the visual appearance of web pages. Firefly uses quite a lot of it.
CSS uses something called a “Cascade”, meaning that elements can inherit their style from other elements that use the same HTML. For example:
This means all button elements on the page would have a blue background.
If you wanted to make one red, you can give it a name, and use that name in the CSS to override the background colour to red. Useful and straightforward enough.
But, the problem with this comes when you have thousands of elements. Sometimes, when you style one element, because of the way CSS cascades, you inadvertently style another element you didn’t mean to.
We solve this at Firefly by using a way of writing CSS called BEM, or Block Element Modifier. This allows us to effectively remove the cascade by using a naming system that guarantees that you only ever style the specific element you meant to target.
This is great for us at Firefly, as it means we ship far less styling bugs. And it makes it easy for us to fix those bugs that do slip through, knowing that we’re not going to accidentally cause more bugs elsewhere.
You can read more about BEM here, on the excellent CSS Tricks website.
We became more Reactive
Firefly makes heavy use of the other great language of the web: Javascript. This is the technology that allows us to manipulate the interface in real-time, without having to reload the page every time you take any action within Firefly.
To help us write better Javascript, we’ve started using a library called React. React was developed by Facebook to solve some of the challenges they were facing when building their website.
To understand why this is good for Firefly, let’s take a look at a practical example of a feature we introduced in Firefly 5: The Markbook.
The Markbook is a highly interactive screen with lots of different states. We use Javascript to manage these states. But, this is where things get complicated very quickly. The developer must remember to update all the states when the user interacts with any of the states.
For example, opening one popup will need to close any others. As you add more and more states, this compounds the problem. This is the source of many bugs, as developers can’t keep all these things in their heads at the same time.
React manages states for you, by keeping its own internal copy of the page’s HTML – this is known as the Document Object Model, or DOM. It continually compares its model to the real DOM that’s shown to the user, and updates it on the fly.
In this way, things like closing one popup when another is opening can be controlled by one simple rule, and React handles the rest. This leads to fewer bugs and happier users.
We make use of React in the new Task Details screen, where teachers can mark students’ work in a variety of ways. This screen has hundreds of different states, all managed reliably by React.
We simplified our themes offering
This was perhaps the most controversial change with Firefly 6. We did this to improve the user experience across Firefly users, but some schools did have to move away from the retired themes, Columnist and Angular.
Fewer bugs
Themes have always been the source of front-end bugs within Firefly. Each theme has its own HTML with which it “wraps” standard Firefly elements (such as, resource page content or the Markbook). It also has its own CSS to restyle the standard Firefly elements.
This means that when we release new feature or update existing ones, we also have to update the themes. The more themes, the more updates we have to do. This issue is that this model doesn’t scale well. The reduced number of themes we offer will help ensure that when we release updates we are confident that all our schools have a great experience.
Theme Variables
What about theme customisation?
Many schools want to inject their own personality into the tools they use every day. In Firefly 5 we introduced Theme Variables to do just this. We improved them in Firefly 6 (more about that later), but it’s worth covering the basics:
Firefly uses a CSS pre-processor called Less. This allows us to store colours as variables, and manipulate them programatically. For example, Melody has a variable called @background-colour, which is used in different places throughout the interface. Less allows you to use an array of colour operation functions to do things like darken or lighten colours. This is particularly useful for creating a harmonious colour scheme.
We also use Less to check the relative contrast between two colours. For example, let’s say we have a box, styled like this:
We’d want to check that any text that’s put inside that box is legible. We can do this with Less by checking the contrast of two alternative colours against a background colour, and using the one which is most legible, like so:
All of which means that, per school, we can override these core variables with school colours, and be assured that the interface will still look great, and all text will be legible.
Better theme options
A lot of work has been done in Firefly 6 to improve and streamline the Theme Variables. Each theme now only requires a small set of colours. Every other colour used within the interface is based-off this core set.
We’ve also removed a number of theme options that weren’t really adding much value for schools. For instance, lots of schools told us that they didn’t really care about things like background patterns, or changing fonts. We now use smart defaults instead.
And, we’ve paved the way to style more of the interface based-off schools’ colour choices in the future, all in a way that will work with feature updates that we make.
Wrapping up
I hope you’ve found these couple of articles interesting. We like to be as open as possible about the way we build software. Hopefully this has given you an insight into the internal workings here at Firefly, and the things we’ve done to ensure we’re delivering the absolute best product possible.
