Trello now has a calendar view

Trello now with added calendar

Trello now with added calendar

It’s no secret that we are big fans of Trello here.

A fabulous feature they added in August—which may make the tool more useful to some people—is the addition of a calendar view.

For as long as I can remember, Trello has always had the ability to set due-dates on cards. These dates turn orange when the due date is near, and red when it has past. A useful visual cue. But now being able to view cards’ due dates by week or month in this new calendar view is tremendously helpful.

It’s been really well thought out too:

  • You can drag and drop cards from one date to the next to change the due date.
  • New cards can be added directly to the calendar.
  • Dates with more than one card clearly show you there are more cards, which appear in a small, scrollable pop-up window when you click on them

If you’ve not already, then sign up for Trello. It’s a really useful, flexible tool to tracking just about anything.

A scalable and modular approach to writing CSS

Scalable and Modular Architecture for CSS

Something that I’ve been keen to introduce to the web team for quite a while is a coding standard: a style guide, a consistent way for the whole team to write and format their code (whether HTML, CSS, JavaScript or PHP) and name their assets (documents, images, videos, etc.) so we spend less time trying to figure out what the last person did and more time being productive.

I actually started work on one after a meeting we had with a few developers and project managers back in October 2010 but I kept getting interrupted. I kept getting taken off ‘just writing documentation’ and put on other projects because they were seen as more important.

The importance of code conventions

Interestingly the last JavaScript Jabber podcast (#075) features a long conversation with Nicholas Zakas, author of Maintainable JavaScript, who talks about the importance of writing code that others can immediately understand and work with without needing to reformat or rewrite it.

The idea behind maintainable JavaScript. Or really maintainable anything is that somebody other than you has a fighting chance at maintaining it later on. […]

There are a few things that go along with that: […] When you look at the code it’s laid out nicely; you’re playing by the rules that have been set down at your company or on your team.

One of the biggest things that annoyed me in my career is that you go some place and you’d have five people on the team and they are all writing code slightly different. How many times have you ever opened up a file and before you did anything you’ve reset all of the formatting?

The discussion then moves on to the importance of code formatting issues. One of the co-hosts confesses that he has often become more incensed by co-workers using inconsistent formatting than by anything else because it adds needless extra mental effort.

Zakas agrees and refers to the work of Daniel Kahneman’s book Thinking, Fast and Slow explaining that our brains get used to particular patterns, and when you detect an anomaly in that patterns that you’re used to you switch into a different mode in your brain and that upsets you.

Zakas explains that when he worked as a consultant he used to go into companies to help them sort out their coding conventions:

I’m a very big believer in the broken windows theory where you need to do the small things right if you have any chance to get the big things right.

Jonathan Snook: SMACSS

One approach to organising CSS code that I’ve been investigating and trying out is SMACSS (scalable and modular architecture for CSS) which has been developed by Canadian developer Jonathan Snook.

In his book he talks about structuring your CSS not only in terms of how to organise the code but also the naming convention that he uses for classes and IDs.

What I’ve found immediately helpful, however, is the way that he categorises CSS rules into five groups:

  1. Base
    These are the defaults, usually single element selectors such as a, input or li.
  2. Layout
    These rules divide the page into sections.
  3. Modules
    These rules introduce reusable blocks, such as sidebar sections, product lists, carousels, tabs.
  4. State
    This was a new way of thinking for me, which I find particularly useful: how do things look in a particular state, e.g. when something is hidden or expanded, active or inactive. I especially like his class naming conventions for state which makes them readable, for example: .is-pressed, .is-disabled.
  5. Themes
    Themes are something that we use already on the University website: we often have a common core of page styles and elements but which are themed or skinned differently, for example compare Current Staff with Current Students.

I’ve used this approach in a few stylesheets now and the clarity it brings to organising my code has been very welcome. I’ve found myself asking “what is this to do with?” This is layout so the code needs to go in this section, that is a module so it needs to go into this other section. It has allowed me to offer a generic theme within the module itself, and over-rule it with a particular theme, if required. Very useful.

My next task is to explore Snook’s naming rules (he uses prefixes such as l- for layouts, is- for states) and compare it against the BEM (block-element-modifier) approach advocated by Yandex.

No doubt I will report back.

Essential web developer skills

Lazy man sitting on a sofa

Lazy Guy photo by David Clark (iStockphoto)

In the next few months we’re going to be gearing up to fill two posts (one replacement and one new post) to join the web team: a developer and an apprentice. So I’ve been thinking about a couple of things:

  1. What skills we are looking for in new team members?
  2. What skills do we already have that we’re maybe not using to their best potential within the team, or which have become a little sloppy and undisciplined that we need to work on.

I liked this comment in an article by Dan Frost on .net; it is point 6:

That search for ‘essential web developer skills’ brings a nice answer from Michael Greer (The Onion’s CTO) on Quora:

Laziness:
Refuses to do anything twice: writes a script or algo[rithim] for it.
Cowardice:
Thinks to test, worries over load and code impact.
Recklessness:
Tries new stuff constantly, launches same-day ideas.
Cowardice is a nice way of phrasing ‘attention to detail’.

“10 things web developers must know to become truly amazing” on .net

I remember a conversation years ago with an architect who said that he valued lazy people, because they showed him how to do things with the least amount of effort. It was from him that I also learned about cowpaths (“look where the paths are already being formed by behaviour and then formalize them”).

I like how Greer put it: refuse to do anything twice. Don’t repeat yourself; the DRY principle. Use frameworks, save snippets of code that you use often (my coding editor allows me to collect code snippets in an in-built library), don’t reinvent the wheel again and again.

Trello at St Andrews

At the meeting of the Scottish Web Folk, on Thursday 31 May held at the University of Edinburgh, I gave the above presentation about Trello from Fog Creek Software.

Trello is, according to its own help text,

a collaboration tool that organizes your projects into boards. In one glance, Trello tells you what’s being worked on, who’s working on what, and where something is in a process.

We’ve been using it since December 2011 within the web team at the University of St Andrews and are finding it really useful.

Summary of presentation

The first part of the presentation outlines something of our journey from a team of two members to (hopefully) six by the end of 2012. As our project backlog grew we knew that we needed to manage projects and tasks more collaboratively, to get details out of people’s heads and into a centralised tool.

We started to adopt Agile practices in 2008 which led to us creating a scrum board in the office. But in September 2012 Steve, our Web Manager, broke his foot and when he returned to working from home in December we knew that we needed to move the board online.

We had checked out a number of online, free and hosted applications such as Basecamp, Pivotal Tracker and Jira. However, Trello proved to be for us the perfect match.

The second part of the presentation takes a quick tour through the Trello interface and how it works.

The last part of the presentation involved a hands-on demo of the software. I’ve replaced this with two simple slides representing the two ways that we use Trello.

  1. We have one board called “Web team” which tracks the big picture: project requests, current projects being worked on, know issues, admin tasks, backlog of tasks, etc.
  2. Then we have multiple project boards, one for each project. These have a standard number of columns (backlog, in progress, waiting for, testing, done) and the labels (new feature, enhancement, PHP/JavaScript, bug, documentation, web team admin) are the same across every project.

If you have any questions or observations please leave a comment below or email me directly (gareth.saunders@st-andrews.ac.uk).

Note: this article was also posted to the Scottish Web Folk blog.