How to make your responsive mobile website hurt my heart

I think the most ironic part about responsive websites is that of the first word: responsive. It seems to have become a pattern wherein people take their over-complicated, bloated website: add a few media queries or use a few framework components and hide the elements that do not fit. The concept of optimising the website for mobile (which includes more than just the visible aspect) seems to have been ignored for about 70% of mobile websites I visit.

I was initially going to point out examples of bad responsive website designs: but, I’m not the internet police, nor am I always right; so it feels wrong to victimise websites that have made mistakes. Instead, I hope they read this article and think: “you know what? some of these apply to me”.

The points below are a collection of my most heineous annoyances with some modern, responsive mobile websites.

Unoptimised, image heavy pages

A mobile user’s worst nightmare: a page that loads multiple, large, unoptimised images on the page. Not only does it stop you looking for the content you visited the website for in the first place, it slows down the rendering of the finalised layout AND uses up your data allowance. If the web page has some sort of carousel without lazy loading, it wouldn’t take long to use up 10% of somebody’s 1GB allowance.

Synchronous web-fonts with no backups

Nothing is going to make a user as frustrated as them visiting your website, having the layout load and being unable to read any text. Why? The 23 fonts you are bringing in are done synchronously and without backups, making all text on the page invisible until the font files have finished loading in.

Research and multiple user experience tests online show that you have only a few seconds to capture your user’s interest: why would you waste that improperly loading a bunch of funky fonts?

Post-load DOM manipulation

So, the user waits the 5 seconds your site needs to load. They begin scrolling and suddenly, the entire page layout changes. Why? Because the desktop site that has been converted to a mobile site ends up getting “bodged” through Javascript to accomplish what should have been done properly in the first place.

Doing this is not only harmful for your end-user, but it also shows that you have a severe amount of technical debt surrounding your responsive mobile website (after all, if you’re having to resort to front-end hacks to accomplish something that could easily be done server-side, something is wrong).

Too much going on

The average modern mobile device has a screen size of around 5 inches. That means you have 5 inches of screen real-estate to fit your most important content on, regardless of the resolution of the phone. Too many websites fill this space with advertisements, pointless images and text that is irrellevant. If you purchased an advertisement board in your local super-market, would you waste 70% of your visible canvas on something that no-one will be interested in? No, you wouldn’t. So why should your home page be any different?

Scroll manipulation

Everybody knows their phone’s scroll speed, they know exactly how much of a swipe they need to make to get where they need to go. Websites that override this behaviour cause the user to get frustrated, something you cannot afford when first impressions count.

(this is also ridiculously annoying on desktop, but I’m trying very hard not to rant)

Sticky headers/footers

(thanks to drngdds for reminding me of this)

As mentioned previously, you have a limited amount of screen real-estate in which to sell your product/services/content or inform users of your goals. Having sticky headers or footers can take away this in-demand space and the focal points on your website. This will undoubtedly annoy your users, especially when the content they are trying to view is blocked by the header/footer elements.

This again is down to poor optimisation of the responsive mobile website; where elements are just hidden and no attention is paid to the experience the user will have on the website.

So – what can be done to solve these problems?

I think the solution to having an awful responsive website is to know your limits. If you begin experiencing performance or user experience issues with the “mobile view” of your responsive website: it’s time to make a change. Best practices are only best practices when they are applicable to you and your circumstances; they are not gospel. Release your website, speak to your users and adapt accordingly.

I really like the look of the accelerated mobile pages and the benefits they deliver, though I hate the idea of vendor lock-in and their ability to push their own agenda unknowingly onto their users. Instead, like the Wikimedia foundation are doing, I think it’s a good idea to implement their best practices in your own way. In short:

  • Render as much server-side content as you can.
  • Reduce/remove the third party dependencies you have on your pages.
  • Lazy load images whilst maintaining page layout.
  • Stop hacking fixes for your mistakes with Javascript.






The art of over-engineering your side projects

Many software engineers who develop software as a hobby often have side projects. The sad thing is, those software engineers often have the tendency to over-engineer their side projects, put all of their effort into mundane and, let’s be honest, pointless tasks and burn out before they’ve even finished their MVP.

Now, I don’t want to sound like a broken record, so I’m not going to preach ‘ship often’ to you, but I’m hoping that by reading this post you’ll be able to see the mistakes I used to make (and stop yourself from making them!).

Mistake 1 – Project managing

So, you have a great idea and a view of how you’re going to go about completing it. Logically, you will try to put together some sort of plan of approach. However, focus too much on this initial plan and you risk falling down the ‘project management’ rabbit hole: writing user stories, creating backlogs and finding tools for a project that you haven’t even started, let alone need copious amounts of rigid management for.

Solution: don’t try and project manage a non-existent project. Note down ideas and rough timelines – that’s it. If you start predicting what you’ll be doing in 2 months on the project, you’re not in Kansas anymore Dorothy.

Mistake 2 – Over-architecting infrastructure

You’re so hyped for this project and confident that it will succeed that you start thinking about the future: “how will I scale my application for the millions of users it will have?” “How do I ensure I have multi zoned redundancy?” “How do I keep 100% uptime? ”

“I know: I’ll create a triple zoned redundant architecture with pub/sub database replication, a 32 node Kubernetes cluster and private networking across all regions – that way, I can handle anything!”

Now, reading that – you might think it sounds ridiculous – and you’d be right. Scale the numbers down though and it will probably sound familiar. So many people are guilty of over-architecting their application’s infrastructure before they even have that application in a state for it to be deployed!

Solution: Develop your project. Then, put it on the bare minimum architecture that it can run on (be that a 512MB instance from DigitalOcean or a medium instance on AWS). As you get more users, monitor, and modify the infrastructure appropriately to account for load and redundancy.

Mistake 3 – Worrying about “tech stacks”

The majority of software engineers seem to be under the illusion that potential customers care about the stack they are running. They don’t. A customer will not know or care if you are using Ruby, Go, PHP or any other language as long as what you have written is performant and is fit for purpose (which all modern languages are).

Solution: Write in a language that  suits the task at hand and one that you are comfortable/experienced with.

Mistake 4 – Creating custom frameworks

Bootstrap? Too basic. Materialize? Too fat. Foundation? Nah. Better create my own.

A made up statement, but relatively common nevertheless. I have many-a-time started a new project, thought the statement previously and set out writing my own framework. By the time I had completed it, I no longer had any desire to work on the project I had thought of in the first place.

Solution: Use frameworks and customise them – only refactor/build your own when absolutely neccessary (and when you have appropriate metrics).

Mistake 5 – Continuously delivering nothing

Similar to the way you can easily over-architect your infrastructure, it’s extremely easy to over-architect your continuous delivery practices before you have anything to deliver! Jenkins, Drone, Travis are all great tools – but you shouldn’t spend time configuring them until you have a working MVP.

Solution: Build your project first – then worry about continuous delivery.

It’s easy to believe you’re doing the best for your project by doing the above things but you aren’t. The best thing you can do for your project is to market, market, market, and then do a bit of development.

Edit: as many people on HackerNews are pointing out, this article focuses more on side-projects that people wish to use to generate income or turn into successful lifestyle businesses. If you’re working on something personal (with no plan to monetise it in the short term) or just for fun, then as long as you’re happy doing it – who cares!