Improving the UX of a front-end framework
How we focused on our users for the latest version of Kickoff
Back in May 2015 we released v5.0.0 of Kickoff, the focus of this release was to improve the framework’s UX. What does that mean? Can you have UX on a framework or a set of files? I believe you can, and here’s how we did it.
Kickoff is predominantly used at my place of work, TMW, but increasingly it is being used by more and more developers and other agencies. This means that we need to be more considered when changing things but we now have to focus on how it will be used by a wider community. Files should be where you expect; ‘things’ should be named in an intuitive manner; and the all important download/install has to be as easy as possible and we realised we needed to improve various things.
Pre version 5, Kickoff’s folder structure looked something like this:
│ └── dist
To fix this, we moved all these into an assets folder, but separated the source code and compiled/dist code. We decided that this would be more useful as there is now a separation of concerns & if you have a continuous deployment workflow you can deploy an entire directory and leave the source files behind. See below for the updated tree:
│ ├── dist
│ │ ├── css
│ │ ├── img
│ │ │ └── icons
│ │ └── js
│ ├── src
│ │ ├── grunticon
│ │ ├── img
│ │ ├── js
│ │ └── scss
│ └── temp
│ └── icons
├── [files ...]
Other changes to folder naming should help developers to know where to look without having studied the frameworks’s details. More recently, the scss folder has been changed for just this reason.
We have been pushing our Yeoman generator as the primary way to start using Kickoff, for quite some time but from this release it really does make sense to use it to get your project started. Yeoman’s interface is simple, just type yo kickoff in your command prompt (after having installed the Kickoff generator npm install -g generator-kickoff) and you are then asked a few questions about your project and intended workflow. These help get you further more quickly but also enable developers to understand the options available to them in a simple way.
As an example, the generator asks if you would like to use Browserify or a simple file concatenation workflow and then generates the correct boilerplate files and grunt config. Below are all the questions that the generator asks:
- Project name
- Project description
- What are the project developer’s names?
- Does this project support IE8?
- Use Browserify?
- Include Kickoff’s styleguide?
- Use Kickoff Statix?
- Use Grunticon?
Lest we forget one of the most important parts of any open-source project — documentation and examples. Kickoff’s documentation lives on it’s website at trykickoff.github.io but also within the code itself. Almost every js, scss & html file has been commented with usage guidelines or some form of help. Examples are also extremely useful to developers which is why we provide many demos of our CSS components.
To see the v5.0.0 release notes, please visit the Kickoff releases page on Github.
If you maintain your own framework or work on a large project, have a think about the UX of your project — how easy is it for new developers to intuit where files go or where CSS is written? Some small changes can make a big difference.