Daily Tips & Tricks for Web Enthusiasts

Get new tips and tricks in your inbox every week!

You can also follow @CoreAssistance on Twitter (where I tweet about each day's tip), subscribe to the RSS feed, browse the archive, or start with the first tip.

Understanding Private Browsing

Browsing the Web •

As you browse the web, your web browser saves a lot of information about what you’re doing in order to improve your experience online. Here’s a list of some of the things that your web browser normally remembers:

  • Cookies are stored so websites can recognize you automatically, making it possible to log in once instead of every time you load a new page.
  • Some files from the sites you visit (like stylesheets, scripts, and images) are kept in a local cache so you don’t have to download them every time, making web browsing faster.
  • The information you type into certain form fields is saved and made available the next time you fill out a similar form, saving you time.
  • A list of the websites you visted is kept so you can find that one page you visited last Tuesday.

Most of the time, having your web browser store this stuff is useful and desirable but sometimes you might not want it to. That’s where private browsing comes in. In a private browsing session your web browser doesn’t keep a record of anything.

  • No cookies or local storage entries are kept after your private browsing session ends.
  • The browser cache is disabled.
  • Autofill for forms and searches is turned off.
  • Browsing history is not saved.

Private browsing mode is useful for several reasons. Some sites, like Google, will remember you (even if you don’t log in) and tailor content (like search results) based on your previous activity. If you want to see the raw, unaltered content you can use private browsing to make these sites “forget” about you temporarily.

Another handy use for private browsing is to log in with multiple accounts using the same web browser, or log out without actually logging out. This is possible because the temporary cookies and local storage kept for a private browsing session are totally isolated and separate from your normal cookies and local storage. Changing one has no effect on the other.

A Word of Warning

Now, all of that said, it’s important to understand what private browsing does not do. Just because your web browser isn’t keeping a record of your private browsing session doesn’t mean no information is being revealed or saved elsewhere.

  • Your IP address is not concealed.
  • Your network traffic is not hidden, meaning your ISP, employer, or even people on the same network can still see what you’re doing.
  • The websites you visit can still see that someone is visiting them, and they may even be able to tell it’s specifically you using methods involving your IP address and other browsing data.
  • Your browser may not disable browser extensions when in private browsing mode, and some of those extensions may be recording your browsing history.
  • If your computer is infected with spyware or other malware, or you have monitoring software like a keylogger installed, that software can still keep track of your activity in a private browsing session.
  • Other parts of your computer do keep some records, at a lower level, that can be used to reconstruct part or all of your private browsing history. This includes things like DNS cache entries, examining certain file time stamps, and more. Fairly technical stuff, but not impossible.

Remember, private browsing can be useful in a lot of situations, but it’s not magic. Now that you know how it works you can use it with confidence.

You Might Not Need jQuery

Resources & Links •

Even if you’ve never used jQuery, You Might Not Need jQuery is a great place to find snippets of JavaScript for common tasks. You’ll find useful bits of code for ajax, effects, element manipulation and selection, events, and utilities.

Make Small MP3s that Sound Great

UX & Accessibility •

If you create and share audio on the web you probably create MP3 files. MP3s enjoy wide support and have a lot of flexibility when it comes to how they’re encoded, making them a great choice for everything from sound effects to music and podcasts.

However, that flexibility can raise a number of questions, most of which boil down to a single concern: How do you strike a good balance between audio quality and file size? The higher the quality the better the listening experience, but if the audio takes too long to download there might not even be a listening experience, so it’s important to strike a good balance when encoding your MP3s.

The quality and size of an MP3 are determined primarily by three factors:

  • The sample rate defines the number of samples per second, and determines the range of frequencies that can be encoded in the audio. This should almost always be set to 44.1 kHz (44100 Hz), which will allow your audio to encompass the effective range of human hearing. Lower sample rates sound noticably worse, and higher sample rates waste bandwidth and disk space.
  • The bitrate determines the amount of data used to store each second of audio. A 128kbps MP3 uses 128k of space to encode a single second of audio, for example. The higher the bitrate, the more information is stored, and the better the audio sounds.
  • The choice between mono, stereo, and joint stereo determines how many audio channels the MP3 will contain and how those channels are encoded.

Joint Stereo

The joint stereo option warrants a bit of explanation, both because it’s usually the best option and because it does some neat stuff behind the scenes.

In most stereo audio both the left and right channels contain mostly the same information, with occasional differences. Joint stereo is designed to encode audio that fits this description more efficiently by encoding everything that’s the same between the left and right channels once, then encoding everything that’s different between the left and right audio channels separately.

Imagine a piece of music with the vocals and instruments distributed equally to both the left and right channels, with a short guitar solo in the middle that pans from left to right. A regular stereo MP3 will encode all of the audio twice, once for each channel, despite the fact that most of the audio (except the solo in the middle) is the same. Joint stereo, on the other hand, will only record the identical audio once, and then encode separate left and right channel information only when they differ. This results in smaller files (sometimes significantly smaller if most of the audio is the same across both channels).

To put it another way, if your source audio is mono (single channel) and you encode it as both a stereo MP3 and joint stereo MP3 (with all other settings being equal), the joint stereo MP3 will be half the size of the stereo MP3 because it’s not encoding the same information twice.

It’s also worth pointing out that there is no file size difference between mono audio encoded as a mono MP3 or a joint stereo MP3.

Joint stereo also has an important impact on how the bitrate applies to the audio. A 128kbps stereo MP3 is actually two separate 64kbps channels of audio. On the other hand, a joint stereo MP3 encoded at 128kbps uses all 128kbps for both channels when both channels are identical, and only splits the bitrate between the channels when there are actual differences.

My Recommended MP3 Settings

I always set the sample rate to 44.1 kHz (44100 Hz) for the reasons mentioned above. I also always use joint stereo unless I want to convert multi-channel audio into mono, in which case I’ll encode as mono to save myself a step.

As far as bitrates go, I use the following bitrates for these scenarios:

  • When I want a smaller file at the expense of some audio quality: 96kbps.
  • When I want to balance file size and quality: 128kbps.
  • When I want high quality audio at the expense of file size: 196kbps or 256kbps.

There is one exception to this. If you have audio that’s only people talking, with no music, 64kbps will do just fine, as pointed out by Marco Arment on Twitter. This applies to some podcasts, but if there’s music somewhere in there 96kbps or higher is probably best.

What About Variable Bit Rate MP3s?

So far all of the bitrate information I’ve talked about pertains to constant bitrate MP3s, meaning they use the same amount of information to encode every second of the audio. The MP3 format also supports something called variable bitrate, or VBR, which uses a variable amount of information for every second of the audio. Less information is used for less complex audio, and more information is used to capture more detail when the audio becomes more complex.

While VBR MP3s do tend to be slightly higher quality at slightly lower file sizes, the tradeoff is compatibility and a compromised user experience. Many audio players, even today, do not fully support VBR MP3 files. One common issue is skipping forward or backward in a VBR MP3 and finding yourself in a different place than you expected to be.

I do not encode any audio as variable bitrate MP3s, and I recommend you don’t either.

Be Careful with Code Formatting

JavaScript •

Usually code formatting is a matter of personal preference, with no impact on how code actually works, but there are exceptions.

Let’s start with this if statement:

if (foo) {
    // Do something if foo is true.
} else {
    // Do something else if foo is false.
}

Some people prefer to format their code differently, and would write the if statement above like this:

if (foo)
{
    // Do something if foo is true.
}
else
{
    // Do something else if foo is false.
}

So far, so good. This code looks different, but it works exactly the same.

Now let’s look at a function that returns an object:

function foo() {
    // Imagine some code here.

    return {
        property1: value1,
        property2: value2
    };
}

Good times, no problems here. But what if we try to format this differently, like before?

function foo()
{
    // Imagine some code here.

    return
    {
        property1: value1,
        property2: value2
    };
}

Everything might look fine, but making these formatting changes actually broke the function! Depending on where and how this code is run the foo() function will either return undefined or the code will refuse to run at all and throw a syntax error.

Why? It has to do with semicolons!

Yes, you heard me correctly: semicolons! As you may know, semicolons in JavaScript are (mostly) optional. The reason they’re optional is that JavaScript parsers have a step called automatic semicolon insertion (ASI) which inserts semicolons for you. The problem with the function as written above is, after the parser adds semicolons, you get this:

return;
{
    property1: value1,
    property2: value2
};

So now you’ve got a return statement with nothing attached, meaning one of two things will happen:

  1. The function will return undefined when it hits the return statement and the code following it will never be run.
  2. The parser will throw a syntax error when parsing the code because there’s an object hanging out down there doing nothing, and will refuse to even run the code in the first place.

This also applies to arrays. This is okay:

return [
    value1,
    value2
];

But this is not:

return
[
    value1,
    value2
];

So, regardless of how you format your code, watch out for situations like this. Generally speaking, you’re fine formatting blocks and scopes however you wish; however, object and array literals may need to be treated differently depending on your preferred style.

Specify Automatic Form Functionality

HTML & CSS •

Form fields have four attributes that give you control over their automatic behavior: autocomplete, spellcheck, autocapitalize, and autocorrect. The first two included in the HTML spec, while the other two are non-standard but still worth implementing.

Autocomplete

The autocomplete attribute tells the browser if it should provide autocomplete functionality for a form field. Aside from the basic choices of on and off for the value of this attribute, there are a wide variety of choices to specify what, exactly, the browser should put in a given form field. Here are some examples:

  • name
  • username
  • new-password
  • current-password
  • email
  • address-line1
  • postal-code

That’s just a sample. There are a bunch of other possible values covering things like payment details, personal information, and more. You can find a complete list with details for each possible value, along with a handy table, in the WHATWG Standard.

Adding the autocomplete attribute to form fields when appropriate can make filling your form out a lot easier for everyone, especially people using mobile devices that are difficult to type on.

Spellcheck

Just what it says on the tin: the spellcheck attribute controls the automatic spell check functionality of a form field. Possible values are true, false, and default. This attribute comes in handy if you have a text field that’s going to accept something like a special token (like a coupon code), URL, or programming code.

Autocapitalize

As I mentioned above, the autocapitalize attribute is non-standard. It’s only supported in Safari on iOS and Chrome. Possible values are sentences, words, characters, and none.

Despite being non-standard this attribute can still help a ton of people and make your form a lot easier to fill out, and including it has no negative impact. Browsers that don’t support it will simply ignore it.

Autocorrect

The autocorrect attribute is also non-standard, and this attribute is only supported in Safari on iOS. Possible values are on and off.

Again, this has the potential to help people have a better experience filling out your forms, and there’s no downside to including it.

These four attributes, when used wisely, can make the difference between a frustrating form experience and a pleasant one. Implementing these usually only takes a few minutes. This is time I’m sure your visitors will consider well-spent.

Powerfully Potent Proofreading

Writing •

You should always find someone else to proofread your writing if you can, but sometimes that isn’t possible. Not to worry! When you’re on your own there’s one easy thing you can do to boost the effectiveness of proofreading your own work: change contexts.

During the act of writing and editing you can easily get too familiar with your surroundings. You stop noticing the room you’re in. You stop paying attention to the text editor you’re using. You stop noticing details. The individual letters and words you’ve written merge together into an abstract blob that represents the concepts you’re writing about. That’s your brain doing its job; it’s designed to take intricate details and abstract them away into simple concepts. This is quite useful for day-to-day life, but it’s murder when you’re trying to edit or proofread.

The good news is that you can get your brain to truly notice your words again simply by changing the context. This technique works best if you can change both the context of your work and your own context.

To change the context of your work try printing what you’ve written and edit it with a pen. No printer? No problem: Print to a PDF, or copy and paste your text into an entirely different app with a different typeface and text size. The idea here is to move your words around and get them to both look and feel as different as possible so your brain notices them again.

As a concrete example, I write these tips in the WordPress dashboard, but I preview them on the site when I proof them. Everything about how the words are displayed is different when I do this, which helps me catch a lot of things I would have missed otherwise.

Another great way to change the context of what you’ve written is to read it aloud. This may not be possible if you’re in a quiet environment, but even whispering it to yourself is better than nothing.

To change your own context simply go into another room to edit and proofread. Maybe it’s your living room, a conference room, the break room, a coffee shop… as long as it’s different enough to jar your brain out of complacency you’ll be able to proofread more effectively.

Empathy is Key to Great Design

Design •

Design is all about solving problems, but the problems we solve are rarely ours alone. Whenever you’re designing something that will be used by other people it’s important to take their perspective into account. Each person is unique; no two people will experience the same problem in exactly the same way.

Being able to put yourself in the shoes of other people is required to craft great solutions. If you don’t take the time to see things from the perspective of others you’ll end up making assumptions and guesses that will degrade the quality of your work. The more you practice being empathetic, the more you practice being a great designer.