Musings

Thoughts and resources from a wondering web designer.

The hamburger menu on Office for Windows Phone:

The problem is, there’s just way too many things on the top bar. For example, you might want to print. How do you do it? Well, you could design a print icon in the top bar. But it’s probably not worth it. You could hide it in the ribbon, but that sort of sucks for discoverability.

And then you notice the top left corner. And you think “Well, tons of Android apps just put everything there. Maybe we could try that?”

And so it became clear, due to the massive number of features in Office apps, and the extremely tight real estate, and alignment with tablets, that a hamburger was the best overall pattern.

Maybe they’ll start using material design next.

Marc Frons talks about making the New York Times a mobile-first business

In the early days of the web, almost all brick-and-mortar companies woefully under-invested in digital technology and product development. These days everyone has a website and even a mobile app or two. But the shift to mobile is so rapid that many companies are in danger of repeating the same mistake and under-investing in mobile.

At The New York Times, we are determined not to fall into that trap. Not only are we focusing more technology resources on mobile development, we are also rethinking how our newsroom and product development teams operate so that we can become a mobile-first company. And when we say mobile, we mean smartphone.

Defining ‘mobile’ as a smartphone is problematic for a few reasons. Does Frons mean a smartphone app or a smartphone website? Is it both? Do tablets with cell service or smartwatches count? Frons seems to be implying that mobile means mobile app (or multitude of apps in the case of The Times) when he advises:

If you’ve got 30 engineers on the web and three on mobile, you’ve got to even that balance out quite a bit. If you’re spending 80 percent of your money on desktop and 20 percent on mobile, it should probably be 50/50 at least, if not tilting the balance toward mobile just in terms of playing catchup.

I agree there needs to be a better balance if you have those kind of numbers, but personally I don’t think there should be such a strong distinction between desktop and mobile for news businesses. The news should be the same on whatever device you choose to consume it on web engineers should be working on building responsive and mobile-optimized sites. There doesn’t need to be a desktop web team and a mobile web team—but I get the impression from this article that this is what The Times has.

Frons adds another piece of advice without providing any evidence for his claims, offering it up as a “reminder”:

Remember that mobile is a push medium, that notifications have become crucial for driving traffic – reminding people that you’re there, stimulating awareness and encouraging usage.

I’d like to see numbers to back this up. I agree that notifications increase traffic, but that doesn’t imply that they’re crucial for a news company or that mobile is a push medium. Mobile is a multidirectional communication medium.

The Atlantic Website Redesign

We created a site that makes a new priority of visual presentation, that offers a cleaner reading experience across digital devices, and that gives us the flexibility we need, both in our articles and on our homepage, to join the speed and urgency of the web with the noise-cutting and impact that have always been central to The Atlantic’s ambitions.

And:

Oh, and the typefaces are new. Hawk-eyed readers will recognize the display and text fonts, both Lyon, as the same ones we use in print.

In addition to the typography, I really love the attention to detail in the Atlantic’s redesign—and they did it all in house. My favorite feature is a subtly which no one seems to get right. Almost every site with a sticky header ignores the fact that some people use the keyboard to navigate the page. Pressing the spacebar generally scrolls the page up so you can continue reading from the bottom, but this behavior doesn’t work when you use a fixed header. The text the reader expects to see ends up below the header, which isn’t a great experience. When your on the Atlantic’s new site and you press the spacebar you’re taken to the correct location on the page with the fixed header offset. These are the kind of details that add up and make the difference between good and great.

HTTPS on NGINX and WordPress in 5 minutes

Serving websites using the transport layer security (TLS) protocol has several benefits aside from security, and getting HTTPS on NGINX can take as little as 5 minutes.

In addition to offering your users an increased level of security, there are also several other advantages including increased SEO ranking from Google and deeper user trust and confidence in your service.

If you don’t know how to ssh into your server, this article is not for you.

This tutorial is given under the assumption that you’re comfortable using the command line, have sudo/administrator access to your web server, and are running NGINX on an Ubuntu or Debian server, and have a WordPress website you would like to server over HTTPS. This tutorial can be used as a reference for servers that aren’t using WordPress, as the WordPress-specific information is contained within WordPress configuration files and settings.

1. Purchase an SSLMate certificate

First you’ll need to sign up for SSLMate — you can use another service, but the SSLmate part of this tutorial obviously won’t apply. When you sign up for the service initially you’ll add your credit card, but you don’t actually purchase a certificate right off the bat — you do that via the command line, which is pretty neat if you ask me.

2. APT Repo + Install Certificate

Next you’re going to want to add the SSLmate to your sources.list so you can apt-get install the package. They have a page with options to select different servers and you’ll want to visit there if you’re using a server other than Ubuntu 14.04 which is what I’ll be referencing in this example.

The `sudo` prefix in the above commands can be removed if they are run as root user. The SSL mate packages should now be on your server, allowing you to run the purchase command to by the certificate.

Replacing ‘HOSTNAME.com’ with your website’s name (I used ‘tucsonlabs.com’):

sslmate buy HOSTNAME.com

SSLmate will begin the purchase process, which involves a sending you a confirmation email. It might seem like your server is hanging after you’ve confirmed the purchase, but be patient and your certs should download. When it’s finished you should have 4 files that look something like this:

www.HOSTNAME.com.chain.crt	www.HOSTNAME.com.crt
www.HOSTNAME.com.chained.crt	www.HOSTNAME.com.key

You’ll want to make a directory for these and move them there. SSLmate recommends using /etc/sslmate for NGINX.

sudo mkdir /etc/sslmate
sudo mv www.HOSTNAME.com.chain.crt	www.HOSTNAME.com.crt
www.HOSTNAME.com.chained.crt	www.HOSTNAME.com.key /etc/sslmate

3. Link Certificate / add server block

At this point you have your certificates, but your NGINX server is unaware of them and it’s probably only listening on port 80. To get SSL working, it’s necessary to add the location of the generated keys to a new server block set to listen on port 443. You can also add this to an existing server block, but it should be separate from your default that’s listening on port 80. Don’t nest this server block within another block — they need to be separate. My config files are located in /etc/nginx/sites-available/HOSTNAME.com — yours may be in a different location.

4. Restart NGINX and Verify HTTPS Work

Everything should be set up properly at this point. To test that it’s working restart NGINX.

`sudo service nginx restart`

You should be able to navigate to https://HOSTNAME.com. If you get a sever error here, double check that NGINX restarted correctly and you’ll trouble shoot your errors.

The only thing left to do is add a 301 redirect and force WordPress to use SSL for the sign in and admin pages. At the bottom of your server configuration that’s listening on port 80 you’re going to add a 301 redirect:

5. Configure WordPress to use HTTPS

Sign into your website’s admin panel and navigate to settings, general. Change your WordPress Address and Site Address to use ‘https’ instead of ‘http’ and press save. Next open your website’s wp_config.php file add the following to force SSL on the sign in and admin pages.

define(‘FORCE_SSL_LOGIN’, true);
define(‘FORCE_SSL_ADMIN’, true);

Then restart NGINX server, and you should be set. You may have to search and replace post content for images with an http url to prevent a mixed-content warning from appearing.

6. You’re done, grab a beer!

To recap if you’re using Ubuntu or Debian and running NGNIX, it only takes 5 minutes to server your WordPress site over HTTPS using SSLmate. It’s easy, adds a higher level of trust to your service, offers your users an extra layer of security, and it can improve your website’s search engine ranking with Google.

Resources:

Jeremy Keith – Switching to https – Useful for those Apache users out there.
Digi Cert SSL checker – Helpful for debugging.
WordPress Guide To NGINX – To cry yourself to sleep.

UPDATE: The ssl_certificate should be above the ssl_certificate_key.

Scott Jehl on Measuring and Improving Overall and Perceived Website Performance

In viewing the time to first byte, we get some insight into the time the web server takes to process a request from a given location and connection speed, and perhaps how much network latency is factoring into the round trip to the server and back (which is, as Ilya Grigorik kindly points out, the web’s current performance bottleneck).

Lot’s of solid performance advice in here as well an interesting look at the recent Wired website redesign and how a few small changes can significantly improve perceived web performance.

NPM releases a private module system

I hope this helps fund the project in the long run. It seems like an in demand feature for organizations wanting to leverage NPM with code not meant to be shared publicly. $7 a month seems like a steal for unlimited packages.

Jason Snell reviews the new MacBook:

The MacBook’s retina display is physically 2304 by 1440 pixels. In standard “2x” retina mode, that means the 12-inch display should look like a non-Retina display at 1152 by 720 pixels. While that’s an option in the Display preference pane, by default the MacBook displays at a scaled resolution that’s the size of a 1280 by 800 pixel display, more or less the same amount of real estate as an 11-inch MacBook Air. That’s also the resolution that the 13-inch Retina MacBook Pro displays at, but on that screen it’s the native 2x resolution—here, the MacBook is drawing a 2560 by 1600 pixel interface and then scaling it down to fit in 2304 by 1440 pixels.

I’m surprised that the new Macbook doesn’t ship with the native resolution set by default. My guess is that it might be related to LCD panel cost, but either way it seems like a smart move to scale it down — working with less than 800px vertical display pixels feels cramped.

High performance HTML

That’s click bait for me. There was only one performance tip in here — inlining CSS. Otherwise it’s mostly basic HTML authoring advice, or if there are performance benefits to some of the style suggestions, they’re not discussed.

I wasn’t aware that li tags don’t require being closed though.

The original source code for jQuery. Including annotations from Jon Resig:

I want to just take a moment to note how little has changed in how these functions work, at an API level. There’s a strong chance that you could take circa-2006 jQuery-using code and drop in a modern version and have it still work. Granted much more was added later on, as it increased in scope beyond my simple use cases, but almost all of the API that we see here was left intact. I’m definitely proud of the fact that the API was “good enough” to last over the next decade — and beyond.

It’s kind of amazing that the original version of jQuery wasn’t even 700 lines of code — a good reminder that even really big projects start out small. Via Jeremy Kieth.

Numbers from Stackoverflow’s 2015 Developer Survey

Software development has a gender balance problem. Our internal stats suggest the imbalance isn’t quite as severe as the survey results would make it seem, but there’s no doubt everyone who codes needs to be more proactive welcoming women into the field.

From over 25,000 web developer survey respondents, 91% identified as male. I’m interested to see how much this differs from their internal stats because it seems in line with my own personal observations — which is a shame.

CSS Guidelines from Harry Roberts

Even though my authoring style doesn’t match Harry’s one-to-one, there’s a lot of overlap and definitely some sound recommendations for front-end folks looking to write more maintainable CSS.