In mid January, Weather.com dropped their mobile website entirely. All previous links to the mobile site now redirect to the corresponding page on their main site. To start off, I do want to mention one key tip that Weather.com handled well.

Tip #1: If you switch domains, subdomains… or otherwise change the URL of a page, you should redirect users from the old URL to a new one which provides the same basic content as the old. Don’t just redirect them to the home page, or even worse, fail to redirect them at all.

The mobile web

The core issue with the next tips is: How to best handle mobile web users. Previously, weather.com offered up a m.weather.com version of their site that was designed specifically for mobile. The content was focused. The code loaded fast.

Responsive web design is very popular. In many cases it is the right solution. Weather.com highlights a handful of pitfalls with responsive design. From a user’s perspective, their previous solution – a dedicated mobile site – was far superior than the responsive site.

The old mobile site

I took this screenshot months ago, not knowing the site would go away. I took the screenshot for a different reason – the forecast low temp was off, by about 950°F. Still, this is a good example of their old site. Some good traits of this site:

1. Its clarity and focus on the important content is very well done.
2. It loads fast – a couple seconds at most.
3. It is easy to scan.
4. The information important to me is well placed, with good font sizes, good contrast, good icons…
5. Nearly seven days fit on the screen without swiping.
6. The ad is decently placed and not distracting. However, the height was not accounted for, so the content moves down the screen after the ad loads.
7. The menu is clear & locations are easy to select.

There’s really nothing more I need here.

Significant loss of speed with responsive design

On a WiFi (802.11ac) connection that shows 30Mb down and not a lot of other users on the network, after eight seconds of waiting, this is what the user sees:

There’s nothing I can do nor useful information I can see. More starts to come in after the eight second mark, but it’s not until after the 13 second mark that I get any useful information. I ran this test multiple times and experienced the same issue over multiple days. My LTE connection yields slightly slower results. This is entirely unacceptable.

Loading the desktop version shows quite a few of the issues

• 19 seconds to load in Google Chrome
• Nearly 3MB of data transfer
• Over 350 requests
• About 20 console errors including security errors
• Several console warnings

Now that’s not quite a reasonable comparison. By loading the desktop version, I am loading content that isn’t sent to most mobile devices with default settings. Google Chrome does allow for emulation. I set it to work as an iPhone running iOS8. I also set it to emulate a “Good 3G” network. Even still, the results are pretty horrific.

• 19 second to load
• Nearly 3MB of data transfer
  • About 1.6MB of that is JavaScript
• Over 260 requests
  • 80+ for JavaScript files
  • 100+ for images
  • 6 for CSS
• Still many console errors

Using the “Regular 4G” emulation, load time was over 12 seconds. Clearly that’s generous considering my tests on a phone over good WiFi come in at about 19 seconds.

Let’s put that in comparison to how it should be

• Google recommends content start displaying in one second – not 12-19. Research has shown that any delay longer than a second will cause the user to interrupt their flow of thought, creating a poor experience.
• At best there should be one JavaScript file, and it shouldn’t be that large. Sometimes one isn’t possible, so a handful sometime need to be loaded. You should not be loading a dozen JS files, let alone over 80. Also, those JS files should all be minimized.
• For the content needed on this page, there should only be the need to load two images – not 100+. One image is for the ad, the rest could be executed as a single sprite. That technique has been in widespread use for over a decade. I do realize SVG sprites take extra care, but it shouldn’t take more than an extra few hours to implement. There is other, non-relevant, content on the page. I won’t go into why it shouldn’t be there, but even if it should, it could still be loaded in a way that did not slow down loading of important content.

I could go on with ways they could optimize, but you get the idea.

While writing this, I left the desktop site up on my desktop. I came back a day later to find my computer largely unresponsive and Google Chrome sucking down nearly 11.5GB of RAM. Once I killed one process, memory usage dropped dramatically. And what was that process? It was the tab running weather.com

The design falls short

Let’s go over the immediately visible design issues that were not present in the original mobile version.

1. The ad for the mobile app. This can be dismissed, but it always comes back. I won’t go into why I don’t want the app, but I don’t.
2. The time is shown. Why? This is a mobile device and my time is already at the top of the screen. If I reload the page, I know I’ve got the latest version weather.com has available.
3. Huge gap under the location and time. Whitespace is nice, but why so much and only here?
4. Column headers – they’re detached from the columns. That makes them more difficult to associate. One of them is truncated to just “DESC…” – I don’t even know what that stands for.
5. I only get one row of actual content. The previous layout gave me seven without having to swipe.
6. The Menu button is now placed inconveniently over the top of the content. This is a technique used in Google’s “material design”, but in this case, this is where the useful content starts.
7. Sharing buttons. Do people actually share the weather on Facebook? I never see it. Do they post the hourly forecast to Pinterest? These buttons are not useful at all.
8. You only start to see it here, but the day, month and date show up on every row. Why? As I swipe down here, all rows show the same info.

*sigh*

UX Tips

Sorry, some of these are going to be painfully obvious, but they apparently still need to be said.

Tip #2: Loading your web page – be it mobile or not – in a few seconds is a much better idea than in 12-19 seconds. Concatenate, minify and compress your assets so they can be delivered quickly. Only supply what is needed, and load important content first so users can start getting value from the site while other assets load.

Tip #3: Sometimes a dedicated mobile site is better than a responsive site. Usage on mobile can be different enough that responsive can’t handle the differences with ease. Quite a few companies are discovering this.

Tip #4: Only put relevant content on a screen. Track usage (one tool I use is Mouseflow) to discover what’s actually used. Certain things are a given – we don’t need time on a screen that already shows time.

Tip #5: Remember dismissible items. If you’ve decided a user should be able to dismiss something, you should also take the effort to think about for how long it should stay hidden. Hours? Days? Weeks? Months? Know your users, and figure out it. Just don’t keep forcing them to dismiss something.

Tip #6: If you have a grid or table of information with column headers – keep the headers to close to the content. Even better, use “sticky” headers so they’re visible as the user scrolls down the screen.

What about Mobile First?

I’ve seen many design mantras come and go over the years. The general problem is many people think they’re universal – that they apply in all circumstances. They follow these “best practices” instead of understanding what’s really going on and what the users need. I have designed and built several large scale apps that were specifically NOT mobile first. Why? Because usage was not mobile, and not going to be anytime soon. If you’re working with ecommerce, social media, content consumption… then chances are a mobile first approach is best.

Weather.com has content. It is consumed en masse. It is a prime target for a mobile first approach. I don’t have their data, but I imagine they have significant mobile traffic. In late 2011, they said they were receiving more mobile traffic than desktop. Undoubtedly, that has only increased. I reached out to Weather.com and asked why they dropped their dedicated mobile site. They have not responded.

Thanks

Thank you for all of the positive feedback I’ve received since starting this series. It is much appreciated. This is my most meticulous review yet. For the non-technical designers, I imagine some of this may have seemed a little dry. I included it because slow loading is a very bad experience, and I wanted to provide solutions.

I invite your comments – including critiques of my critiques. If you see other experiences that are ripe for a critique, feel free to send them along. I’ll make sure to give you credit for the inspiration.