Finding the time and energy to continue regularly blogging has been harder than ever. This is due to an all encompassing website project coupled with some major home improvements.

The former occupies every hour (and more) of work and the latter means I'm seldom at home without a paintbrush in hand.

This website project has been mammoth in that it has been a total rebuild. The only content we're reusing are archived press releases and blog posts. Making a 200+ page MVP website read (and look) as if it is all one publication requires a lot of coordination.

It's made me realise that I feel most energised when working on a number of digital projects simultaneously. Flitting between web, email and social media marketing helps me feel in touch with what is going on in the business and wider world.

Being so focused on one project for such a long period of time takes its toll. I'm so blinded by HTML code and the same page designs it's hard to say if what we're working on is still any good!

This is why a project of this scale needs prototyping. This is essential in giving senior management a view about how the website will look and read. Outside of the web team I've found it's impossible for colleagues to visualise an end product which exists in 'Gather Content' combined with templated designs and UX notes. These stakeholders struggle to imagine a finished product which could lead to misunderstandings or scope creep.

For them, there are lots of different ways to showcase a prototype as a proof of concept. They could be as simple as a design mockup (an old favourite of mine as a way to be clear in agency briefs). But, whilst these are good for validating visuals they are poor for testing usability.

Then there are wireframes. These are typically lower quality visually and so quicker to produce. They are good for testing visual hierarchy with users and whether they know what to do on the page. But they offer little in terms of testing aesthetics.

We've decided to go all in and hand code an HTML prototype. This has proved great for testing usability, visual hierarchy and navigation. It also allows testing across devices. The only downside of this approach for me has been the time it has taken to create. Especially as richer design or interactivity has been added.

In fact, we've had to be very clear where the HTML prototype ends and the CMS begins. Otherwise the former grows into a bigger beast than first intended and absorbs time from actually building the live site!

Being able to gather feedback on a version of the website that is 75% right means that we're now not working in isolation anymore. We can bring fresh eyes to the project to help identify any issues with styling or content. For our working prototype we've tried to involve as many stakeholders from around the organisation as possible. These include:

  • Senior Management
  • Editorial Council and Department Heads
  • Wider marketing and Communications colleagues 
By involving them people in the creation of the prototype they now feel a sense of ownership over it. This means they are less likely to criticise and more likely to defend it to others.

Ultimately the aim of this prototype is to gather constructive feedback from stakeholders and real users. To avoid the risk of non-constructive feedback we've circulated a survey with a list of predefined questions. This helps to improve the prototype by educating stakeholders about where they should focus.

Of course, we're regularly checking this feedback. We then discuss the more objective comments and see if anything needs and further follow up conversations. We're then putting the relevant changes into practice as we populate the CMS for final go live.

Once this new website is live and the home improvements are finished I intend to have a rest. It would be nice to sit down over Christmas and get fat on mince pies, turkey and fine wine.

I haven't the heart to tell myself yet that this is where the REAL work begins on both counts...!
Am I the only person who gets a Wix advert every time I try to watch a YouTube video? Or a Squarespace advert every time I listen to a podcast? I guess I've been identified as a potential buyer for these services! The ability to publish a website as quickly and easily as possible is big business.

These are the two main competitors to get you up and running fast and the results are actually pretty good. They look nice (if a bit generic) and are very easy to manage. And if you want anything a bit more powerful then there are plenty of Content Management Systems (CMS) to choose from too. But it wasn’t always this way.

The web started out as a mostly static affair. Plain old HTML was, and still is, the basis of a site. But back in the day, the ability to dynamically generate content wasn’t widely available to the average designer.

When my career got started in 1990s, every site I built was static. Granted, I didn’t know a whole lot at the time. Thus, so many of my projects became unwieldy nightmares when it came to maintenance. The task of, say, adding a new item to a navigation bar meant hacking my way through potentially hundreds of HTML files – depending on the size of the website. I even foolishly experimented with a Flash navigation for one website!

But recently I've returned to hand coding an HTML site for reasons took complicated to explain here. And this has got me thinking.

For years, I’ve dismissed static HTML as outdated and no longer useful in most situations. But maybe this dismissal may have been a bit unfair. Sure, those old school sites I worked on were a cause of major frustration when changes needed to be made. But does that mean static HTML no longer has a place on the web?

Part of the problem with using static HTML, for me at least, was the fact that it was forced into duties it should have never had in the first place. The intended use for HTML was as a markup language – not as a means to manage complex arrangements of files. But for websites built on a small budget, it was the best tool we had at the time.

Remember using nested tables to hack your way through a page layout? Through no fault of its own, HTML became a whipping boy for how not to do things.

I now realise that static HTML sites can still have a place on the web. This does depend on both the needs of your project and your skills as a developer. But, generally speaking, there might be some benefits:
  1. Full-On CMS Functionality Isn’t Needed - Sites needing regular updates (like this blog) probably won't work outside of a CMS. But “brochure” style sites, for example, could be a perfect fit
  2. Increased security - Static websites are almost completely safe compared with dynamic ones. This is because they don’t rely on CMS plugins or dynamic software
  3. No software updates - As above, 70% of WordPress sites are at risk of getting hacked by malicious hackers because of lack of maintenance and upgrading. Scary!
  4. Better reliability and speed - The absence of a middleman/database makes the static site much more speedy and easy to load 
  5. Hosting and Price - Static websites have basic HTML files which require less space making the hosting of these websites cheaper than that of dynamic websites 
Just because this is an old fashioned way to build sites it doesn't mean it should be discounted. By looking back into history we may actually find a more suitable way of doing things!
I am a genius. At least, in the past, that's how I've been introduced to new colleagues at work. "This is Paul, he's our digital guru".

But, of course, I'm not. In fact I'm in no way approaching genius status. But despite knowing this when I first heard it I still felt flattered as it played to my ego. After all, I have always been motivated by being as useful as possible to my team. I thrived on knowing little tricks to get the job done quicker or by having the ability to devise a technical solution faster than anyone else.

Of course, if I let being spoken about like this go to my head, whatever modicum of talent I do have will be squandered. I need to feel I have so much still to learn to motivate me on to do better. After all, my name (Paul) literally means 'small' or 'humble'. A sobering reminder to never let my ego get the better of me.

Nowadays I cringe when introduced as a 'Guru' or 'Ninja', because it undermines my process.

“Guru” implies that I can single-handedly solve every digital challenge. It implies that alone I have the power to make their problems go away. But this is too much expectation for anyone to handle.

Calling me a guru implies that I am superior to everyone else in the room, and have an especially privileged place on the team. It also works as a method to deflect any difficult questions to me as Mr. Fix it. "Go to Paul if you have any technical questions". "Paul knows the difference between all of the file types so I don't have to". "If the photocopier is broken go to Paul, he has 'digital' in his job title".

All this means it's harder for me to do my job. I get interrupted the most as the pressure is on me to fix people's problems when the CMS doesn't behave. I'm called on to decode technical jargon used by agencies. All I need is a few of these and suddenly the pressure of my own deadlines are doubled. So how should I address it?

Well firstly, it's good manners to accept compliments. Protesting too much would only serve to reinforce that I do indeed have this image of myself. If I do seem in any way seem like an expert in anything it will be due to a combination of gifts naturally given and hard work. It's worth reminding people what it takes to progress by describing earlier efforts and learning experiences.

Emphasising the activity is important to remind people that you are overseeing a process. By going through the sequence of activities to deliver a project it shows where you will be relying on them to provide input.

Realising and acknowledging when you should plead ignorance is important. Whilst your subject knowledge may be strong, perhaps your knowledge of the project or business is not. I frequently need to tell myself that staying quiet in meetings can be a lot more useful than striving to drive the conversation and find solutions.

If your work is anything like mine, you work on difficult problems. I frequently am called on to decipher jargon and act as a liaison with the technical details. Perhaps I get called a genius so that people can hide that they don’t understand what’s going on. You don’t have to call anyone out, and highlighting that this is difficult work can go a long way to set the right tone. “We’re learning as we go, so ask a lot of questions. I know I will!”

A luxury I never seem to have is time. But it's vital when working on complicated stuff not to rush things. Take time to explain everything. Externalise your thought process and show your work. Rather than scheduling one long review meeting each week, have shorter conversations more frequently.

I try to frequently remind myself that I'm very favoured to have a job that really interests me. Whilst the ability to keep going is down to our natural gifts it's important to keep a boundless appetite for learning. We all make some good decisions and learn from the not-so-good ones.
Next PostNewer Posts Previous PostOlder Posts Home