Contributing Editor

Craig is a Director of OptimalWorks Ltd, a UK consultancy dedicated to building award-winning websites implementing standards, accessibility, SEO, and best-practice techniques.

Craig's articles

  1. CSS Framework Fortunes and Failures with Harry Roberts

    Harry Roberts helps teams all over the world to build better front ends. Craig spoke to him about his talk at Future of Web Design.

    SITEPOINT (Craig Buckler): Hey Harry. Tell us a little about yourself and what you do.

    HARRY: Hi there! I’’m a consultant front-end architect from the UK. My work includes visiting companies of all sizes (from the likes of the BBC and the NHS right down to individuals) in all types of places (from sunny California to snowy Frankfurt) and helping them get a handle on their CSS. I do a lot of consultancy and workshops, solving company scalability woes and teaching developers how to build bigger, more performant UIs. I get to travel, meet interesting and passionate individuals, work with great companies and get paid along the way. I can’t believe my luck!

    Before that, I was a Senior Developer at BSkyB for almost three years. Before that I worked at a series of digital agencies of varying sizes.

    SITEPOINT: How did you get into conference talking?

    HARRY: I’d been blogging and tweeting for some time when Front-Trends approached me in late 2011 and asked if I’d like to speak at their conference in Warsaw (2012). I’d never spoken anywhere before so it was a huge gamble for them but I nervously accepted. It’s carried on from there.

  2. The End of the Password Age

    Despite revolutionary advances in computing, we still rely on a string of characters to authenticate users. Passwords originated hundreds of years ago and were certainly used by Roman military. In the modern era, MIT’s CTSS introduced passwords in 1961. Unfortunately, password problems are prevalent: People are predictable. Thousands use popular codes such as ‘password’, ’123456′, […]

  3. What’s New in Firefox 28

    Firefox 28 already? It’s been a full six weeks since Firefox 27 and Mozilla is back with a freshly-baked version. You can get it in one of three ways: Waiting for an auto-update; choosing About Firefox from the menu; or downloading the installer from Firefox.com.

    Again, there are few obvious features for end users but we developers are more fortunate…

    Developer Tool Updates

    I find myself using the built-in Developer Tools more often than Firebug. While Firebug still has the edge in most areas, it can’t beat the Mozilla tools for speed and quick inspections.

    Firefox 28 introduces a split console mode that allows you to use the DOM inspector, debugger, profiler etc., without having to switch back and forth to the console pane. You can see this by clicking the toggle split console icon in the top-right of the tool window.

  4. How to Charge for Websites: the Agile Way

    This entry is part 3 of 3 in the series How to Charge

    In the final part of this series we’ll discuss agile pricing — a relatively new charging mechanism which helps prevent fixed-price and pay-per-hour problems such as:

    • requirement changes
    • costly delays
    • unfinished or unpaid projects.

    Clients want a final cost figure but can not know or appreciate every requirement. Even with a clear specification it’s difficult for developers to estimate large project schedules. Accuracy is futile when you consider that the client’s requirements will inevitably evolve.

    Agile charging is based on agile development techniques but it’s not as technical as it sounds. Billing is based around “sprints”; a fixed block of time when a number of features are implemented.

    Billing Cycles

    Typically, a billing cycle is a two-week period with a defined start and end date. During every cycle you endeavor to:

    • implement a number of identified features, and
    • be available at certain times, e.g. Monday to Friday, 9am to 1pm. Avoid offering a full 40-hour week — you’ll need time for side tasks such as administration, inquiries and other client projects.

    There’s only so much you can achieve within each cycle so development estimate margins of error are reduced. No other features are normally considered during the cycle so client interruptions are minimized.

  5. How to Charge for Websites: Pay-Per-Hour Projects

    This entry is part 2 of 3 in the series How to Charge

    In part one of this series we discussed the complexities of determining a website price when your client eventually asks “how much will all this cost?” Fixed-price seems logical and is easy for all parties to comprehend but the process can break down on more complex tasks:

    1. It’s difficult to determine and document all requirements up-front.
    2. Requirements will inevitably change.
    3. It leads to the misunderstanding that a website is a “final product”.
    4. You may incur additional costs and payment can be withheld.

    An alternative model is charging per hour: the client pays for the work you do. It’s an attractive option for freelancers because they receive money at regular intervals regardless of whether a project is on-track. While requirements gathering, analysis and revision is necessary, you’ll be remunerated for that work. Clients may also prefer the model because some risk is reduced; they won’t need to pay a large deposit only to find you’ve disappeared with their cash.

    Charging per hour is typically adopted by freelancers joining large team projects. If you’re working on a variety of features, it’s easier to pay for your time than to identify discrete chargeable tasks.

    However, it’s important to understand the pitfalls of pay-per-hour projects…

  6. How to Charge for Websites: Fixed-Price Projects

    This entry is part 1 of 3 in the series How to Charge

    Many web professionals progress into freelance work because they love technology and have a strong portfolio of successful projects. However, these skills do not necessarily translate to good business sense. Many small companies find it difficult to price their work — or even define a pricing structure. This is the first in a series of three articles about the pros and cons of different charging options.

    At one end of the pricing spectrum are the $50 per-page design agencies. These companies profit by churning out hundreds — if not thousands — of basic sites every year. Their clients typically have limited funds and want to tick the “we have a website” box. It won’t revolutionize their business or entice new customers, but not everyone needs a ground-breaking site.

    At the other end of the scale there are $3,000 per-day IT consultants helping multi-national organizations determine their digital strategy. Some freelancers undertake this work via a series of increasingly large agencies each taking a slice of that fee.

    The majority of freelance work falls somewhere between the two extremes.

    How Much Will My New Website Cost?

    I dread this question. In my experience, the time it takes a client to ask is inversely proportional to the amount of hassle they cause. Many IT novices consider a website to be a product: they want X pages and expect to pay a fixed price of $Y. They do not appreciate that web design and development is a service which touches all aspects of their business.

  7. What’s New in Chrome 33

    The past few Chrome releases barely raised an eyebrow. We received a few good developer tools and minor interface tweaks but the core Blink rendering engine was largely unchanged (in a noticeable way). Fortunately, Chrome 33 provides new HTML5 toys for developers to drool over…

    Custom Elements

    Custom Elements formalize something developers have been doing for many years: creating their own HTML tags. Admittedly, we shouldn’t have done that but we’ve all tried adding <sarcasm> and <kitten> tags at some point or another. Chrome now supports Custom Elements as part of the new Web Components API.

    There’s too much to explain here but, in essence, you can:

  8. How to Use the HTML5 Full-Screen API (Again)

    If you don’t like change, perhaps web development isn’t for you. I previously described the Full-Screen API in late 2012 and, while I claimed the implementation details were subject to revision, I didn’t think I’d need a rewrite a year later! This may not be the last, but many thanks to David Storey for highlighting the recent technical transitions…