article

|

I’ve had my GMail address for several years now; I don’t really use it for anything more than legacy accounts, logins, or as a spam trap. For the most part it just sits there in the background, silently passing on any messages it receives to my “proper” account, which is email with a custom domain hosted on Fastmail.

Over the last 12-18 months, I’ve been receiving a slow-but-steady stream of mail clearly meant for someone else: newsletters mostly, but occasionally something personal, and the odd booking confirmation. At first I put these down someone mistyping an email address now and then, or something to do with how GMail has fun with dots (“.”) in email addresses1. Whatever the cause, at first I would just delete them as soon as I realised they weren’t intended for me.

Over time though, it became apparent someone genuinely thought my GMail address was theirs. The nature of the emails became more personal, and there was an increasing variety of individuals and organisations mailing the address, and increasingly with information you wouldn’t want to miss. I’m guessing from the nature of the mail that they are older, but that’s just a guess. The profile I’ve built up is (I’ve written some details more vague than I know them to be, and excluded others):

  • They live in an area of North London
  • They are a member of a residents committee
  • They have an elderly/sick family member or friend they wanted to keep up to date on
  • They used to use Eurostar semi-regularly
  • They recently decided to get their garage converted

Where before I used to just delete immediately, now I have taken to responding to certain mails, to let senders know they have a wrong address – in the hope they can let the intended recipient know they’re giving out the wrong address. Beyond this, I don’t know what to do… it’s not like I can email them to say!

  1. If you didn’t know, you can place a dot anywhere in a GMail address, and it will still resolve to your address. Another tip is you can “extend” your email address with a plus (“+”) and anything you like which gives you potentially unlimited addresses for the price of one. For example, test+something@gmail.com will resolve to test@gmail.com. I would use it for potential “throwaway” addresses ↩
article

|

Ads and websites which automatically redirect your iPhone to the App Store1 need to stop being a thing.

I’m seeing more and more instances of this user-hostile behaviour happening when I’m following a link on my phone. Usually it’s caused by an ad unit on the page, but now and again, it’s a site publisher who really, really, wants you to install their app.

Here’s the thing: if I wanted your app, I’d likely already have it installed. If I open a link to your website, I expect to (and am happy to) access your content there. Redirecting me to the App Store is a massive inconvenience and interruption; it takes me out of the app I was already using – often after I’ve already started reading your content – and puts me somewhere I wasn’t expecting to be. It breaks my concentration as my brain switches from reading your content to looking at the app download page. Assuming I still want to read your content after being treated like this, I now have to close the App Store, reopen the app I was just in, and hope I can pick up where I left off. The publishers who treat their users in this way seem to think I’ll:

  • Download the app, and wait for it to install
  • Create the usually mandatory account
  • Validate said account by switching to my email
  • Reopen the app, and try to find the content I’d clicked through to read in the first place
  • Read it (at last!)

Err, how about “no”? I was already reading your content. If you want to pimp your app to me, put a button or mention of it at the end of the article.

When this kidnapping of my attention is caused by an ad, I’ll sometimes go back to the site to finish reading, or I’ll go back to where I found the link, and send it to Pocket to read later instead (and without the ads to interrupt me). When it’s the publisher itself, chances are I’ll be annoyed enough I won’t return. You had your chance, and you chose to send me elsewhere instead. Either way, I sure as heck won’t install any app advertised using this method.

So can we please put a stop to this? It’s even worse than interrupting me to beg for an app review.

  1. This probably applies to Android and the Play Store as well, but I’m on an iPhone and so that’s where I have experience of this problem happening. ↩
article

|

I’ve written previously about how the archives of my blog were less full than they should be – that, between domain changes, server/CMS moves, and times when I simply didn’t care, there were potentially hundreds of posts missing from the early years in particular.

Back up your crap, people – including your blog.

For the last couple of years I’ve had an on-off project to restore as much of this personal history as possible. Every so often I’d go ferreting through old hard disks, or exploring the Internet Archive’s Wayback Machine for old content I could salvage. At first I had limited success, turning up only a handful of posts. Of those, I was fussy and only restored the “worthwhile” posts – usually longer posts about big events, or technical in nature.

This last weekend though, I revised my stance on this. If I was going to recreate my blogging history, I couldn’t – shouldn’t – just cherry-pick. I should include as much as I could possibly recover: the good, the bad, the plain inane. Anything less would feel a bit dishonest, and undermine the raison d’etre of the whole endeavour: saving the past.

The only exception would be posts which were so incomplete due to missing assets (images mainly) that any body text made no sense, or posts which were completely unintelligible out of context of the original blog – entries about downtime, for example. Also excluded were my personal pet peeve – posts “apologising” for the time between updates1!

A Brief Synopsis of the “How”:

To bring the past kicking and screaming into the present, I dove back into the Wayback Machine, going as far back on my first domain as I could. From there I worked as methodically as I could: working from the furthest back onwards, post-by-post. The basic process was:

  • Copy the post text and title to the WordPress new post screen
  • Adjust the post date to match the original
  • Where possible, match the original publishing time. Where this wasn’t available, approximate based on context (mentions of morning/afternoon/evening, number of other posts that day, etc)
  • Check any links in the post (see below)
  • Add any recovered assets – which was rare
  • Turn off WordPress social sharing
  • Publish

I started on the Friday afternoon, and manually “imported” around 50 posts in the first batch.

Turning off social sharing was done so I didn’t flood my Twitter followers with a whole load of links to the posts – some over a decade old. One thing I didn’t anticipate though, and which I had zero control over, was WordPress emailing the old posts to those who had subscribed to email notifications. It wasn’t until a friend IM’d me about her full inbox that I realised what was happening – so if you found your mail filled with notifications as a result of this exercise, I apologise!

To get around this, I ended up creating a new, private WordPress blog to perform the initial manual process, so I could later export a file to import into this blog.

Between Saturday, Sunday, and Monday evenings, I tracked down and copied over a further 125 or so posts. Due to the vagaries of the Wayback Machine, not every post could be recovered. Generally speaking, it was reliable in having a copy of the first page of an archive section, but no further pages. Sometimes I could access “permalink” pages for the other posts, but this was really hit-or-miss. A lot of the time the page the WBM had “saved” was a 404 page from one of my many blog reorganisations over the years, or in other cases, it would have maybe one post out of eight.

I made a rule not to change the original posts in any way – no fixing of typo’s/correcting something I was wrong about. The only thing I would do, was mark where there was a missing asset with an “Editors Note” of some sort, when appropriate. The only content I did have to consider changing were links.

Dealing with Links

One thing I had to consider was what to do about links which might have changed or disappeared over time. When copying from the WBM, links had already been written to point to a (potentially non-existent) WBM archive page, but if the original still existed, I wanted to point to that instead. In the end I would have to check pretty much every link by hand – if the original existed, I would point to that page; if not, I would take a chance with the Wayback Machine. In some cases I had to consider what to do where the page existed, but had different content or purpose to the original. I dealt with these on a case-by-case basis.

For internal links, I pointed to an imported version, if it existed, or removed it if there was none and context allowed.

Wrapping Up

In total, I imported around 175 previously “lost” blog entries, covering 2002-2006, with the majority from 2005. These years have gone from having a handful of entries, to having dozens. Overall, this has grown the archives by roughly 50% – a not so insubstantial amount!

At some point I will go back and appropriately tag them all, but that’s a lower priority job for another time.

2007-2010 were years when my writing output dropped a lot, so while I will look for missing entries from this period, I don’t expect to find many at all.

Side Note: History Repeats

I discovered, in the process of doing all this, that I had gone through the same exercise before, roughly 10 years ago!

Over the last few days, I’ve been working on the archives of my old site; cleaning and recategorising them. Today, I have added them to the archives of Pixel Meadow.

These additions represent everything that was left of ChrisMcLeod.Net. Over the course of its life many changes occured and data was lost – so these additions don’t represent everything that I’ve written there over the years.

You would think I might have learned from this mistake back then, but obviously not! Fingers crossed it’s finally sunk in.

  1. Though only where they had no other content to the post. ↩
note

|

The Reading List is a round-up of interesting blog posts and articles I’ve recently read, curated and posted every couple of days.

quote
|

Quoting:

“”

“Time is a created thing. To say ‘I don’t have have time,’ is like saying ‘I don’t want to.’”

note

|

The Reading List is a round-up of interesting blog posts and articles I’ve recently read, curated and posted every couple of days.

note

|

The Reading List is a round-up of interesting blog posts and articles I’ve recently read, curated and posted every couple of days.

note

|

The Reading List is a round-up of interesting blog posts and articles I’ve recently read, curated and posted every couple of days.

note

|

The Reading List is a round-up of interesting blog posts and articles I’ve recently read, curated and posted every couple of days.

note

|

The Reading List is a round-up of interesting blog posts and articles I’ve recently read, curated and posted every couple of days.

article

|

Once upon a time I viewed myself as only a developer. I didn’t like support, and tried to avoid it as much as possible – even though I knew it was in the customer service side where I would always learn the most in my day-to-day job. I put it down to the stubborn “programmer” in me! Then I moved into a role which was 90% support work, and I had an awakening of sorts: I really like support work. More than that, I loved working in support. I haven’t really talked much1 about this shift in mindset, so this post is part of an attempt to rectify that.

For 3 years, leading up to early 2014, I led a small support team within a major oil and gas company. We were tasked with looking after a complex health and safety-related web application which had users from all across the globe The support team itself was spread out internationally, so I quickly had to get used to working remotely and communicating with both users and team-mates over email, IM, screen-sharing and other ways of coordinating as a distributed team.

A bit of extra background: I initially took on the support of this application by myself. The application was a virtual unknown within the IT structures of the client, and entirely unknown to my employer who was tasked with assuming responsibility for it from the original developers. I had a very, very small window of opportunity to learn from the original developers, and precious little documentation to work with afterwards. On top of this, the main stakeholders of the application were steadfastly against the move to a new support team.

Things did not get off to a good start. The support needs had been grossly underestimated by all involved in the planning sessions which had led to me being hired. It was taking longer than I’d have liked to learn the application, and soon there were red flags being raised about the reduction in support performance. When my manager and I discussed what was going wrong and how to turn things around, the first thing we agreed to was expanding the team. Initially one more person was added, with the goal of adding a second once the first had been given enough knowledge to free up enough of my time to train them both in the more in-depth aspects of the application. I should point out that at this moment I was still learning a lot of nuances of the application myself! Eventually the core team grew to four.

Our users were very diverse, ranging from someone who only touched a computer when they had to, right through to very highly technical users who spent all day, every day within the application – and this was before taking into account regional and cultural differences – so I learned to adapt myself to each person I was talking to. Sometimes even a subtle shift in tone or language could help a user understand something they’ve been struggling with for hours (or days in some of the requests we got). My communication skills levelled up immensely over this time period!

Empathy was one of the other key skills I used every day, and in turn was something I try to instil in the rest of my team. I think it’s essential to a support role, and credit it as one of the reasons I ended up as successful as I was in this particular role. Many times I found insight into a problem by pausing the technical analysis until I’ve asked the user why it is they’re trying to achieve something, and even in some cases why what they think is a problem is a problem to them (i.e. results vs. expectations). In my experience, the most important questions you could ask a user was not “What is the problem? What were the symptoms?” but rather “what is it you’re trying to do?” and “why do you want to do it?”

Through a combination of hard work, honest, friendly engagement with the users (beyond just their support tickets), and a willingness to “go the extra mile”, we went from being the unknown, out-sourced support team “forced” on them, to trusted colleagues who were experts in the application and would always do right by the users – which is something I’m very proud of.

What I learned over all of this was that I am happiest when I am solving problems and helping others with something which is bothering them — and customer service work gave me the opportunity to combine both in to one job. Put this together with the challenges which I overcame in the role, and this was one of the most rewarding and satisfying periods of my career so far. I still like to write code, but I no longer feel it is where my heart truly belongs.

Eventually, due to the shifting sands of Enterprise contracts and budgets, my team had to be disbanded, and the application handed over to a new team from a new supplier. I used the lessons I had learned in my own adoption of the application and its users to prepare the new team as best as I possibly could, training the incoming team of six with an intensive crash-course as we only had a fixed amount of time. After all, their success or failure would be a reflection on how well I had understood my application and users. I’ve only had limited contact with the client since I left, but from what I understand, things have been good in objective, results-driven manner, but my team and I have been missed for the extra attention we put into talking and listening to the user community.

  1. I don’t really talk much about work in general these days. Partly it’s the nature of the beast; at any given point I’m under a number of NDAs which reduce what I can say to nearly nothing worth writing about. ↩
note

|

The Reading List is a round-up of interesting blog posts and articles I’ve recently read, curated and posted every couple of days.

After a short break, the Reading List is back with a bumper issue.