This post from Jolly Bureau ties in very nicely with what I wrote for The Pastry Box Project this month. So I thought I’d elaborate on:

About a year ago, I left day rates and job rates behind and started estimating, billing and working on projects on a weekly basis. A year on and I’m better organised, more productive and less stressed than ever before. Our accounts are in better shape and no one owes us money for longer than a week. It was one of the best business moves I’ve made.

2011

Go back just over a year and I guess my situation was pretty similar to many, if not most freelancers or small business owner designers. I found some aspects of running my business very difficult. In particular:

• Estimating
• Scheduling
• Billing

“How much is it for a website?” is pretty much a cliche question, but often client enquiries lack the information or detail we need and digging into a client’s requirements deep enough to be able to provide an estimate for work can be extremely time consuming. I’m not talking about knocking up a quick quote for a straight forward task or small-scale project, I mean us spending hours or sometimes days trying to understand a complex problem or large-scale project in order to provide a detailed quotation. This is often time before we’re hired and the meter is running.

You could argue that the time we spend on estimates is just one of the costs of doing business. But when you’re a one-man-band or a very small company like mine and your time and energy is what keeps things going, that cost of doing business can be disproportional.

In the past, for larger or more complex projects, I guesstimated (as best I could) the days or weeks or months I’d need and I blocked that time in my calendar. This worked well up to a point, but a calendar can be a fragile thing and sometimes it does’t take much to break even the most carefully constructed schedule.

A client might be late delivering something. That something might not be right. They might change their mind or it might just take longer than we anticipated. Building in wiggle room, extra time between projects is good, but that wiggle time can all too easily get swallowed up.

When we get busy, projects can follow on one after another and often without a break between them. Worse still, projects can overlap and that’s when the late nights start and stress levels rise on all sides sides as we rush to get the job done. No one benefits from this. We, the client and the work all suffer.

Then there’s billing. Keeping on top of money can be a nightmare. There are so many variables.

How do we bill? Do we give our clients a fixed price or charge by the hour or on day rate? Is that the same for every activity?

Do we ask for money up-front? (We should.) Do we ask for a third, 50% or some other figure?

When is the final balance due? Is it when we hand over the deliverables or when the website goes live? Either way, unless we’re fortunate to work with people who pay their bills immediately, we’ll likely have to keep track of who owes us what and the fact that we’ll have different people owing us different amounts at different times all adds to the complexity of getting paid.

(At Stuff and Nonsense we always pay our suppliers and contractors the same day we receive their invoice, sometimes within a few minutes if they send it electronically. There’s no reason anyone should wait longer than that for their money.)

2012

About a year ago, I was asked to work on a redesign of ISO with my friend David Roessli. Their site’s so large and complex that to be honest I struggled with where to start scoping the estimate for redesigning it.

Then an industry friend told me about how his studio worked in fortnightly sprints on specific aspects of a project. I don’t want to get into the pros and cons of agile (mainly because I don’t know enough about it) but that conversation sparked an idea.

I suggested to ISO that we spend one week periods tackling specific design problems. They agreed, so we scheduled a week on news and PR, another on their catalogue pages, another on their standards and so on.

Because those weeks were scheduled in advance, everyone on ISO’s team knew precisely what we’d need to get started. You know that thing where you’re waiting for content from a client? Didn’t happen. Everything fell into place and because we’d set realistic expectations, everyone knew when we were finished. Which we did. On time, every week. It was a resounding success and I now take that same approach with every client project I take on.

Working weekly has undoubtably made estimating easier. Instead of attempting to figure out precisely how long a large and complex project might take and therefore how much to charge, I break down each project and estimate the parts in multiples of a week.

If a client introduces a delay (which happens once in a while), they change their mind about something or introduce a new feature (which the design process should allow them to do) it doesn’t cause a problem. They know that those changes can be rolled into a future week and they know the costs associated with that, so they can make an informed business decision about whether or not to proceed with it. Everything is transparent, everybody knows where they stand and everybody is better off.

Our scheduling has improved too. I know exactly what I’m working on and when. My clients know exactly when I’m starting so they know to have all the materials I’ll need ready before then. They know when I’m due to finish and when I’ll need their attention to sign things off.

I know when to tell new clients our next available week is. Things are busy these days — we’re booked solid until October — so new clients know to book time in advance and they pay in advance to reserve it too.

Instead of asking for a third or 50% deposit and then a balance on ‘completion’ as we used to do, we now ask our clients to pay weekly, one week in advance. This has dramatically improved cash-flow and it means that, unless there are extraordinary circumstances, no one owes us for longer than a week.

Better estimating, scheduling and billing are some benefits, but I’ve also never been more relaxed about work and more on top of things at the same time. I feel I’m more productive and making better work than I have in years. I’m convinced that’s down to less complexity, better organisation and therefore lower stress levels.

In the past, I felt like I should always be working, especially in evenings and at weekends, because I was worried about money. It’s common for freelancers’ to feel constantly hungry. I missed a great deal of time for myself, on personal projects or with my family. Now I look at a calendar that’s full as far as I want it to be. I know we’re never more than a week away from being paid up to date so I can finally relax about money. Not working all the evenings and weekends gives me balance. I’m sleeping better and doing things that aren’t work.

We’ve even got our weekends back for the first time in years.

I skipped linking to this a couple of weeks ago, but it makes sense to read along with the previous link to Edward O’Riordan.

Edward O'Riordan, writing for .Net magazine

They emphasise surface impressions when we also need to talk about the feel of browsing and the experience of interacting. Getting design sign-off as images of pages we teach them to think of sites in terms of pages rather than components. Comps give a false impression of the web as something which neither ebbs nor flows but stays stubbornly static.

It’s great to see the idea that static design visuals set the wrong expectations getting more coverage. I’d had liked to read more details about exactly how Edward deals with this in his own client relationships, so I can see how it differs from mine.

Chris makes some great comparisons. I’ve used LESS extensively for a while now and there’s been exactly zero instances where I needed something that LESS couldn’t do (but Sass could.) Maybe that’s because I’m a designer who writes code, not a developer? Who knows? Still, I am tempted to work with Sass on a project sometime.

I’ve been reading Jonathon Snook’s Scalable and Modular Architecture for CSS book this week. (It’s well written, practical and perfectly formatted for Kindle. I learned a lot and I’d highly recommend it.) In SMACSS, Jon recommends breaking down stylesheets into rules for:

• Base
• Layout
• Module
• State
• Theme

He establishes a naming convention for these categories of styles. Jon says:

I like to use a prefix to differentiate between Layout, State, and Module Rules. For Layout, I use l- but layout- would work just as well. Using prefixes like grid- also provide enough clarity to separate layout styles from other styles.

I like this idea a lot because, 1; I’ve had a fascination with naming conventions, and 2; I’ve long had a problem with mixing styles for layout with styles for ‘atmosphere’ (colour, texture and typography,) something we’ve all done for years.

To me, using classes makes sense when we need to ‘classify’ items such as modules on a page. They make sense for groups of styles in a theme too. But it doesn’t make sense to me to use classes for the layout outline of a page, particularly when many times we add the elements they style purely for layout reasons and especially in a responsive context. It feels somehow messy.

Years ago, when oft-used browsers only supported element, class and id selectors, we didn’t have much choice. Now that browsers from Internet Explorer 7 up have solid support for CSS attribute selectors, we can bind our styles to elements based on their attributes. That’s why we’ve seen more and more people binding styles using ARIA role attributes. For example:

<div role="navigation">…</div>

[role="main"] {
/* styles */ }

Reading SMACSS got me thinking. Why not abstract layout styles even further than Jon suggested, by using HTML5’s data- attributes instead of classes. Something like:

<div data-layout="content">…</div>

[data-layout="content"] {
/* styles */ }

Conceptually, this fully separates styles for layout from every aspect of atmosphere. Although I’m aware that there are no practical advantages to using data-, to me it somehow feels cleaner.

I’m not 100% sure if this could be a legitimate use for data-. What are the experts’ opinion? I’d be interested in hearing if you’ve used this approach already and what you think might be the possible advantages and disadvantages?

When I set up my home/office wireless after switching broadband providers, I called the downstairs router’s network ‘Planet Of The Apes.’ And why not? ‘Andy Clarke’s Network’ is a boring name. (And Planet Of The Apes is a better movie than Star Wars.)

Then I called the Airport Extreme extended upstairs network ‘Rise Of The Planet Of The Apes’ and the Airport Express I keep under my desk ‘Beneath The Planet Of The Apes.’

I bought a mifi today because I’m working in London a fair bit over the next few months and the client site doesn’t have open wifi. I could stick with the network’s given name, 3MobileWiFi-c602, but ‘Escape From The Planet Of The Apes’ seems much, much more appropriate.

Jordan Moore (who has a name like a country singer:)

Say for example we want to present an article in the narrow single column view, but before the article appears in the stacking order we have: a header (containing site name etc), navigation, maybe even a banner advertisement, then the article. The heart of the page is buried beneath items that may be less important in this context. Rather than brutally hiding these items with a display:none property we can reorder them using another CSS property - flex box.

It takes something to make me sign in and blog on a Sunday, but this is good. Very good. Read the whole thing. Then study Jordan’s demo page. Brilliant.

Harry Roberts:

Loosely, the single responsibility principle states that every module or chunk of code (a function etc) should do one job well and one job only. The benefits of this are mainly in the way of maintainability and extensibility.

I didn’t know this approach had a name or think to look.

Faruk Ateş in Opera Confirms WebKit Prefix Usage:

I’m left feeling that this is just Browser War II, and what grace we’d regained by switching to Feature Detection rather than UA sniffing will be lost once again as a result of these moves.

With some luck, things will just become better for the users of those browsers who will once more pretend to be someone they aren’t, and us web authors aren’t inconvenienced too much. Meanwhile, it is left—again—up to web authors to invent the tools to placate the browser vendors who gave us this mess in the first place.

I commend Opera for finally admitting — through their decision to adopt WebKit Prefixes — that their real motives are the corporate motives we always knew them to be. That they’re not the standards champions they pretend to be. That they’re prepared to break a fragile, but working standard for corporate gain.^[1]

What their actions also tell us is that despite hiring some of the best minds in the business^[2], their strategy of evangelists and ‘web openers’ has resoundingly failed to convince developers that Opera is relevant. If that wasn’t the reality, they would have no need to adopt another platform vendor’s prefixes.

What Opera forgets in its colossal arrogance, is that vendor specific prefixes were intended to give developers a choice to support a browser platform — or not.

We were never ‘required’ to include a full set of prefixes.

Excluding Opera didn’t qualify as ‘invalid.’

If I choose to exclude Opera (or Webkit or Mozilla or Microsoft,) that’s my choice and my right.

1. For the record, I don’t have a problem with a profit motive, just hypocrisy. 2. I don’t have a problem with individual Opera employees either (although many think I do). This isn’t about them.

I’ve worked for myself for the last fourteen years and for most of that I’ve worked in my office at home.

Now this is handy. It adds viewport width and height as a :before pseudo element on the body to help you determine breakpoints for content-first responsive design. Here’s Matt’s test page with the debugger* enabled. Download the debugger from Github.

* Snort

Remember Matt Stow and his responsive retina images using CSS and a spacer PNG? (Now updated.) Well, Matt’s been at it again, this time with a solution to the image map problem in responsive design. Matt’s solution recalculates area coordinates to match the image size on load and window.resize. Clever. View the demo page or download the plugin from Github.

A lot’s changed since I wrote the original ‘320 and Up’ — my ‘tiny screen first’ responsive web design boilerplate — one year ago.

Honestly, I’ve been wanting to start hoarding candles, fire-lighters, tins of corned beef (it’s nice. Really.) and other things for a while. I know the collapse of civilisation is much more likely to come from a petrol strike these days, but hey. It’s a zombie survival map. My wife thinks I’m mad.

It’s been almost three years since I launched, what most people thought of as the bat-shit crazy Universal Internet Explorer 6 CSS stylesheet.

I’ve been working on a small travel site over the last few weeks and came across an interesting responsive web design challenge.

This came at the perfect time for me this week (thanks Chris), as one of the projects I’m working on required icon fonts. I chose Font Awesome because it works so well with Twitter’s Bootstrap and even comes with files for my beloved LESS.

More from Matt Stow. This one had gone clean out of my head. When I was in Sydney in February, Matt showed me a Fireworks extension he’d written for exporting responsive prototypes.

Now I use Fireworks almost every day — it’s my ‘go to’ design tool and so much more efficient than Photoshop for web designing — but I’ve never used it’s code output, not even for a ‘rough as a badger’s arse’ prototype, let alone anything I’d show to anyone. But Matt’s extension worked flawlessly when he showed it to me.

I’m going to try this and if Fireworks is your thing, test this out too and let’s compare notes.

Matt Stow emailed me from Sydney with a link to his solution to the responsive/retina images problem. It’s a clever workaround that uses CSS and a transparent spacer PNG. Matt’s interested in your feedback (and so am I) so try it out and let Matt know your thoughts via Twitter.

Brilliant.

Now, when will our politicians, in all parties, communicate with such clarity and honesty.