2019 is my 20th year of web development. Well, in 1999 I started updating a corporate website’s sales page via MS Frontpage Express ūü§ď live on the server ūüĎĽ. And at that point that was basically web development right?

Throughout my career, I have been self taught, and have had to learn continuously to keep apace with modern techniques. Non tabular standards based HTML. CSS 2 and 3. Responsive web design. jQuery. PHP (WordPress). Grunt/Gulp/Node. As well as many dead and dying frameworks and platforms.

But over the last couple of years I’ve been aware of one part of my skillset has been lacking. Namely modern Javascript frameworks in the form of React, VUE, Angular. Generally speaking I’ve not really needed much in the past as regards JS, this website has two functions, toggle the search form and set a cookie (for the cookie notice). Some websites use a lot more, but it’s often that sort of thing and I’ve been able to get away with a moderate if not very efficient knowledge of jQuery. Often my approach to writing JavaScript is akin to French philosophy, verbose, dense and often self-referential. It works, but I am always aware it could be better. And it always bugs me how long it takes sometimes to do something that seems simple in my head. I also am intrigued as to the general discussions around React CSS-in-JS, modules and overall methodology (test-driven development, node, deployment).

So for 2019 I am going to embark on learning JavaScript more thoroughly, building up to React (I know VUE and Angular have many benefits but React seems to be edging it for me). I originally decided though to learn ES6 first, as I wanted to understand better the fundamentals rather than dive straight into a framework with little understanding of what’s going on under the hood. Saying that, when I started the ES6 course (ES6 for everyone – Wes Bos) I was a little out of my depth straight away so decided to take it back a step and start with JavaScript fundamentals (JavaScript: Understanding the Weird Parts).

Anyway, I aim to update this site as to my progress, hopefully weekly, or there about. I don’t expect this to be easy but if we don’t continue to learn we don’t grow ūüöÄ

WordPress WorkFlow

I’ve been using WordPress for a very long time, this site was built in 2004 and I think it was on version 1.2,¬†and was using WordPress¬†from around mid-2003 on other sites before that.


So a long time.

Much has changed, but WordPress has proved remarkably robust, I just spun up a theme I built around 2005/2006. See the code here (please forgive some of the code, this was 11 years ago. ) and it still works! The Loop is still the same crazy Loop, that I am never sure I fully got, anyway the point being if I had installed a theme from 2005 it would still work today.


So¬†pretty amazing and points to why WordPress was a good solution 10 years ago and is still a good solution now, we don’t talk about longevity much in web development, but I like to know something I build now has a shot of existing 2, 5, 10, or even 20 years from now.

Sure we now have custom post types, custom taxonomies, rest API and some amazing plugins that turn WordPress into a fully fledged CMS, but at it’s core it’s the same easy to use, easy to develop¬†on and easy to recommend system I first installed all those years ago.

Now my own workflow has changed a bit, whereas back in the day all I needed was a copy of WordPress, Dreamweaver! (Code View & FTP) and maybe Photoshop.

These days it’s a bit more involved, this is what I tend to start most new projects with, on average I reckon the setup is about half a day, give or take:


WordPress plugins


Anyway, thanks WordPress


UX Development – a journey from -er to -ment

I’ve been using the job title UX Developer for a while now, it just seemed to best describe what I do. When it came to setting up my business Dogwonder Ltd/>¬†I wanted and needed to describe what I do, not in a manifesto type way, I haven’t thought that far ahead, I wanted to do what I know – UX Development seemed the obvious choice.


Given I have been hanging that term off of my own logo for 18 months, it got me to thinking about what that actually meant in practice. What happens when the verb becomes a noun, from -er to -ment. Was my business really worth of such a noun, am I living up to it?

The vast majority of the engagements for Dogwonder Ltd/> lean more towards web development, mostly SMEs wanting a website that they can ultimately control (text editing, menus, social media, SEO etc). As such the traditional UX phase tends to be much leaner that I was previously used to in consultancy land where engagements could be upwards of several weeks. When a project has a budget that stretches to around 5 days worth of work, the UX phase needs to be quite lean indeed. That’s not to say it’s not important, but usually that part tends to be about understanding the primary goals, users and business needs quickly. I will often start with an initial stakeholder meeting and a 1-2 hour workshop with a various focused exercises, followed up with a brief report and page sketches to validate ideas. For most projects this tends to suffice, still it’s probably 10-20% of the overall budget, so not too shabby. But more than anything it’s essential I understand what problem I am trying to solve for the client, what do they ultimately want the website to do? Without understanding this from the outset, any chance of completing the project successfully is very low. ¬†In addition often is necessary to understand the clients business at least from a zoomed out perspective.

I quickly realised that even if the traditional UX phase of a project was proportionally much smaller on smaller sites, it didn’t mean it had to end there, I found that UX was inherently weaved into the fabric of the rest of the project timeline:

  • Design phase
  • Site development and administration
  • Measuring success
  • Touch Points (social, IRL)

Given that my projects tend to be quite short, on average 1-2 weeks ¬†(project time, not elapsed time), the various project phases are likewise short, and so it’s important that I bake in as much UX goodness throughout.

Design Phase


Often I will receive maybe two or three design comps for a website, mostly likely a homepage, single page/post as well as a feature page (gallery, forms, petitions etc). These will usually designed for desktop (900-1000px) and mobile breakpoints (320px). Sometimes I might only receive a PDF style guide and some assets such as fonts/images.

So mostly it’s up to me to fill in the gaps, mobile, landscape, tablet and everywhere in between. Graceful degradation for older browsers that don’t support opacity, gradients, animations. Often pretty important decisions not just from a design perspective but from a usability perspective. I might not be deciding how a page layout is put together, but I am certainly ensuring it is usable for the device and platform in question.

Often there are other page types and design patterns that emerge over the project, where it’s necessary for me to extrapolate from the original designs. So 404 pages, alerts, form submission errors, external dependencies (social sharing, like buttons, video includes), cookie warnings (grumble grumble), all of which need to work within both the design framework as well as from a usability perspective. We could design for every one of these scenarios, but this would take too much time, so we (designer(s), client(s), me) design directly in the browser as situations emerge. So from an initial lean UX/Design phase a working breathing site emerges responding to content, devices and platforms as the build process develops.

We might only design for 20% of the final site, and the ‘final’ designs may differ substantially from the final site, but it’s enough to get us to the build phase we we can make UX decisions with real content on real servers through real devices. What worked in photoshop doesn’t so much work in the browser.

Site development and administration


I am a big believer in enabling administrative users to manage as much of their content as possible, having to rely (and pay) me to change something on the site invariably leads to inaction or delay thus compromising the original goals of the site. Why hardcode a google map or team photo when through things like Advanced Custom Fields¬†we can enable site administrators to change that themselves. Or for example enable site administrators to change a hero image/text on the homepage allowing them to be more responsive to their user’s and business’ needs.

If I make a bad decision on how a site is administered it might mean that specific functionality that was meant satisfy end-user needs is not used to it’s full potential. Questions like, correct terminology, ease of access, clearly labeled forms, taxonomical organisation, complexity of administration, editorial work flows all combine to decide whether a site is easy to administer and directly proportional to how successful that site maybe, if the site administrator doesn’t feel comfortable updating the site, then no amount of up front design or UX will aid the eventual success of the site.

Measuring success


In the same vein empowering stakeholders with analytics is a very important part of the whole process, enabling them to see what’s working and what’s not. Often as part of the development process I will set up a GA account and add the client as an admin and encourage them to use it. We can then use those analytics to improve the site, based on actual usage rather than assumptions.

Touch Points


The website is only one part of the whole. Social and offline are just as important, without promotion in these channels the website is likely to only exist in a vacuum, again missing out on it’s initial goals. How does the site look when shared on Facebook, optimising og:title and og:image can be essential to ensure Facebook users are getting a good experience when sharing the site, and not some random image from the homepage or elsewhere. Ensuring facebook and twitter profile and banner images as well as google places are also considered as part of the process can make a big difference to how end-users might find and interact with a site, as well as potentially offer feedback on the experience.

Even IRL, does the print media reflect the goals of the business? Often I have spent time with a client on re-aligning the website much more towards core business needs, only for the business card and other print literature directing users to the site not reflecting those needs.

To sum up

So I realise that not all of this is strictly UX (although a fractal definition of UX seems to be pretty common) however, if we are talking about ensuring a website meets it’s primary goals and serves and responds to users, then I’ve found considering the impact of development decisions on end users and stakeholders essential in the ongoing success of a website. Thus I am going to be continuing to use UX Development as a description for my business function, it’s what I do.

Moving forward I would like to demonstrate some of the methods used on projects, with code examples and screen grabs.

A year of Dogwonder Ltd.

So I’ve been running Dogwonder Ltd. since 10th September 2012, just over a year. It’s been quite a ride, I’ve learnt an incredible amount about myself and had to deal with many challenges, not least project managing myself. I’ve not shared much during my first year as really just wanted to get on with it, but felt it was time to show some of the sites I have been working on in the last year. I’ve not put everything here, as mostly wanted to share the sites I have built responsively. All of the sites below are built on WordPress.














2022 2021 2020 2019 2017 2016 2014 2013 2012 2011 2010 2009 2008 2007 2006 2005 2004