How not to do sticky ads

Making ads sticky can help to improve viewability percentages – viewability is important to many advertisers.

Ads can be made to stick for a short period of time and then disappear, or they can be set up to be “perma-sticky” – so they don’t go away.

When ads are permanently stuck, publishers need to be careful that there’s sufficient space to display everything on the page.

Here’s what I saw on the Telegraph today, while viewing a story:

Continue reading “How not to do sticky ads”

A Southern Rail nightmare: my story

After a particularly bad day on the trains, I felt compelled to share my story and ongoing woes with Southern Rail.

Generally speaking, I’m one of the luckier commuters. Whenever there’s trouble on my route, I usually miss it. Sometimes an issue affects a train that’s one or two timetable slots after mine – or mine is the last good train for a while. Sometimes I can get a different train with minimal disruption to my commute. Very occasionally, train problems occur on a night when I’m out with a friend – so when it’s time to go home, things are nowhere near as bad as they were during the evening rush hour.

However, every problem has a knock-on effect – even if I’m often lucky with how things line up. Delays add up. And I’m already choosing my trains purely based on which ones I expect will cause the least amount of pain – rather than the ones that would get me to and from work for my normal working hours.

First, let me tell you about my typical daily commute.

Continue reading “A Southern Rail nightmare: my story”

A week of back trouble

A few weeks ago, I woke up and felt a slight twinge in my back. It felt awkward and very slightly painful, but I put it down to sleeping “a bit funny” as it wasn’t all that bad.

Over the next couple of weeks, the pain didn’t go away. It stayed pretty much the same, never fully rearing its painful head (or back), but somehow, perpetually, just “there”.

Last Monday, it got a bit worse. I phoned the doctor in the afternoon – they said to phone back in the morning. On Tuesday I started noticing quite a bit of pain if I turned, stood up, or sat down a bit too quickly. I arranged an appointment with the doctor that afternoon.

The doctor suggested it was most likely muscular pain, and recommended taking ibuprofen three times a day for the next two weeks. Tuesday night was rough – I woke up at 3:30am in a lot of pain. As I’d taken the first painkillers at 6:30pm the night before, they’d probably worn off by this point.

I stayed home on Wednesday and Thursday, attempting to work from home – although it was tough. I could hardly move without being in pain. I came up with an idea for a makeshift standing desk – basically a small table on my regular desk. Luckily the table wasn’t too heavy, but I had to be careful lifting it. That got me through Wednesday. After that, I had a bit more luck sitting at my desk. I’d previously booked a day off on Friday, so was able to rest that day then through this weekend.

For those of us lucky enough to not deal with pain or physical difficulties on a daily basis, I quickly realised how much we do each day that uses your back. Things become a lot more difficult due to back pain or an injury. Showering, getting dressed, going up or down the stairs were all particularly tricky. Putting on socks – normally such a simple task – became something of a mission impossible.

I also noticed just how much we rely on computers. As I usually spend a lot of time talking to people in the office or on the phone, being at home is not ideal. I was able to schedule in a couple of phone calls while I was at home, but for the most part I was communicating via email and Skype IM. Cue lots of typing – and while the makeshift standing desk helped, I soon got backache from standing up for too long.

Thankfully, I’m mostly better now, but I’ll need to be more careful in future. Monday is my first commute in nearly a week – I’ll see how that goes…

Link: the Washington Post has brought its page load speed down to milliseconds

Page load speed is important – possibly more so than ever, thanks to the dominance of mobile devices for browsing the web.

As of July 2015, [load time] was cut down to 1.7 seconds — an 85 percent improvement gained by shedding bulky features that took too long to load. With the progressive web app, article pages load in 80 milliseconds, Merrell said.

Source: “With lessons from Google, The Washington Post has brought its page load speed down to milliseconds” (Poynter)

Production code and real-world tech

This week I read a tweet that really resonated with me:

I totally agree.

However, this applies beyond coding. I’d like to see more examples of tech being put to use on real projects. It’s cool to look at what’s new in tech – but to me, it’s even cooler to think of real-life examples where a specific piece of tech has added value that would have been a lot tougher – or impossible – with another tech choice.

Rather than talks or blog posts along the lines of “How we built a website in AngularJS”, how about why you used AngularJS? How about whether a framework has been a huge asset in the early stages of building an application, but it’s caused difficulties later on? How about moving between JS frameworks? How about tales from teams who have inherited bad codebases and gradually improved them? Or tips from developers who stay in jobs for a few years and have consolidated tools or reduced technical debt?

I’m sure there are plenty of these talks and blog posts around. I’d just like to see a little less of “here’s a new tool!” and a little more of “here’s how to get more out of your existing setup”.

How I prioritise small requests alongside project work

Recently, I changed the way I prioritise new work requests and projects. Here’s what I’ve started doing.

Prioritising the product backlog

JIRA is our central system for development requests. There’s one project for smaller requests: the “BAU” as I call it, which is anything that takes 2 days dev time or less. Except for urgent requests, which we will drop other work to look at, anything in JIRA is allocated a business area via a custom field.

Each week, I export a list of all open tickets, filtered by area. One or two people in each area indicate their Priority 1 and Priority 2 tasks, and those go into the queue. We also prioritise our internal work, such as changes to the core product, and improvements to our technical stack.

We won’t complete all of the prioritised tasks every week – but it allows us to see what the priorities are.

I believe it’s important for all areas of the business to be included in the prioritisation process. Nobody should feel that their area is being ignored. Allowing each business owner to define their priorities can prevent this issue.

Prioritising the projects

Instead of starting yet another spreadsheet, for projects I decided to use pen and paper. I ordered a stack of 1000 plain white 5×3 record cards and a pack of Sharpies.

I started by writing one project on each card, and laying it all out on the table (literally). Staff involved in the meeting can see all the known projects, ask what they are, and identify anything that may be missing.

Once all projects are defined, we agree what’s the next priority. This makes it very clear which project will be worked on next – and also what won’t be. Showing the number of projects can make it very clear if there’s a capacity issue. There’s only so much resource, so we can’t work on every project simultaneously.

Does it work?

As this is a very new process I’m trialling, it’s too early to say how effective it is. I’ll write a follow-up post on this.