Chromecast

Ordered the Google Chromecast the other day. It’s a little HDMI dongle you put into your TV to make it smarter. Amazing gadget, I must say, it’s been a while since I was this excited about a piece of electronics. It’s not that it’s that full-featured — right now it’s only actually useful if all you need is YouTube and Netflix (which happens to be the case for me) — rather, it’s the implications of the device that excites me.

It doesn’t have a remote control, and the device does nothing on its own. The remote is your phone or your tablet or your desktop. All the device does is receive streams from the internet, and you “suggest” those streams from your handheld. In essence it downgrades your “smart-TV” (or in my case, upgrades my dumb-TV) into being simply a display capable of receiving input. It removes every single bit of UI and interaction from the television itself, and propels it onto that thing you have in your pocket regardless.

The concept alone blew my mind when the implications sank in. I doubt it’s controversial to say that television UIs have sucked for decades. Just pick up your remote control and look at it, chances are you’ll find more than twenty buttons, 90% of which you’ve used only once. Alright maybe you picked up an Apple TV remote — vast improvement over most other remotes, but why is that? Right: fewer buttons. Which is why requiring all interaction happen on your smartphone is such a novel idea: by virtue of being a sheet of capacitative glass, your television remote now has only the buttons necessary, and only when you need them. 

It’s just great.

What’s even better is not having to switch on your television and change to the “HDMI” channel. The Chromecast is always listening for input, so if you tell it to play Netflix, it’ll turn on your TV for you, on the right channel no less. When you turn off the television again (alright, I suppose you do need your remote for that — and for volume), your Netflix app will pause the show you were watching. 

This is how television is supposed to work. They’ve cracked it.

Yeah sure, it’s early. Most people will need set-top boxes for a while still. For a 1.0, however, the Chromecast is remarkable. If only Netflix would auto-play the next episode in a TV show, if only Pocket Casts was Chromecast enabled… But hey, this dongle auto-updates transparently in the background. Who knows, maybe next time I turn on the televison, there it is. It is Chrome-based, after all.

Chromecast

Ordered the Google Chromecast the other day. It’s a little HDMI dongle you put into your TV to make it smarter. Amazing gadget, I must say, it’s been a while since I was this excited about a piece of electronics. It’s not that it’s that full-featured — right now it’s only actually useful if all you need is YouTube and Netflix (which happens to be the case for me) — rather, it’s the implications of the device that excites me.

It doesn’t have a remote control, and the device does nothing on its own. The remote is your phone or your tablet or your desktop. All the device does is receive streams from the internet, and you “suggest” those streams from your handheld. In essence it downgrades your “smart-TV” (or in my case, upgrades my dumb-TV) into being simply a display capable of receiving input. It removes every single bit of UI and interaction from the television itself, and propels it onto that thing you have in your pocket regardless.

The concept alone blew my mind when the implications sank in. I doubt it’s controversial to say that television UIs have sucked for decades. Just pick up your remote control and look at it, chances are you’ll find more than twenty buttons, 90% of which you’ve used only once. Alright maybe you picked up an Apple TV remote — vast improvement over most other remotes, but why is that? Right: fewer buttons. Which is why requiring all interaction happen on your smartphone is such a novel idea: by virtue of being a sheet of capacitative glass, your television remote now has only the buttons necessary, and only when you need them. 

It’s just great.

What’s even better is not having to switch on your television and change to the “HDMI” channel. The Chromecast is always listening for input, so if you tell it to play Netflix, it’ll turn on your TV for you, on the right channel no less. When you turn off the television again (alright, I suppose you do need your remote for that — and for volume), your Netflix app will pause the show you were watching. 

This is how television is supposed to work. They’ve cracked it.

Yeah sure, it’s early. Most people will need set-top boxes for a while still. For a 1.0, however, the Chromecast is remarkable. If only Netflix would auto-play the next episode in a TV show, if only Pocket Casts was Chromecast enabled… But hey, this dongle auto-updates transparently in the background. Who knows, maybe next time I turn on the televison, there it is. It is Chrome-based, after all.

3.8

When 2013 ends in a couple of weeks, it’ll have been the year where I went from contributing only circumstantially to WordPress, to contributing quite a bit. In fact, despite having had the honor of releasing a default theme this year, it’s not until the end of 2013 — today actually — that I feel like the bulk of the work I’ve done on WordPress is actually released. For me, 2014 is when WordPress gets really exciting.

It’s with quite a bit of pride that I find my name in the release credits for the just-launched WordPress 3.8 “Parker”. This particular release was brought about in a different manner than previous releases: it was developed alongside 3.7 through “feature plugins”. Along with a group of developers and designers I worked on one such plugin called “MP6″, a nonsense-codename with a cool banner. Our true purpose was to redesign the entire WordPress admin. The ease of use of the WordPress admin has always been my favorite part of the software, but I’ve always had little niggles with it. With plugin commit access, this time I was able to put money where my mouth was. So we worked hard to bring you visually lighter and simpler design, with a bunch of usability improvements in tow such as scalable icons, larger fonts and more contrast. My good friend and creator of the initial mockup that excited us to work on this for months, Matt Thomas, details everything you’d want to know about the design.

To celebrate the occasion, I’ve made sure my green and blue Twenty Thirteen color schemes are now in the WordPress theme repository. Yep, it’s now easier than ever to dress last years theme in new clothes. Heck, you can get the default Twenty Thirteen colors without using post formats now.

I think 3.8 will be a watershed release, and I can’t wait to hear what you think of it. It’s certainly deserving of the name “Parker”, who happens to have uttered one of my favorite quotes:

Don’t play the saxophone. Let it play you.

Good Decisions, Else Options

There’s a mantra in the WordPress development community: decisions, not options. It’s meant to be a standard to which you hold any interface design decision: if you make a decision for users it’ll ultimately be better than forcing them to make decisions themselves. It’s a decent mantra — if you’re not mindful you’ll end up with feature creep and UI complexity, and it’s orders of magnitude more difficult to remove an old option than it is to add one in the first place. Adding an option instead of making a decision for the user is almost always bad UI design.

Except when it’s not.

The problem with a mantra like this is that it quickly gets elevated to almost biblical status. When used by a disgruntled developer it can be used to shoot down just about any initiative. Like Godwins law for WordPress: once you drop the “decisions not options” bomb, rational discussion comes to a halt.

The thing about open source development is that it’s much like natural evolution: it evolves and adapts to changes in the environment. Unfortunately that also means features once useful can become vestigial once the problem they used to solve becomes obsolete. Baggage like this can pile up over years, and maintaining backwards compatibility means it can be very difficult to rid of. Sure, “decisions not options” can help cauterize some future baggage from happening, but it’s also not the blanket solution to it.

The problem is: sometimes the right decision is unfeasible, therefore beckoning an option in its absence. WordPress is many things to many people. Some people use it for blogging, others use it for restaurants, portfolios, photo galleries, intranets, you name it. Every use case has its own sets of needs and workflows and it’s virtually impossible to make a stock experience that’s optimal for everyone. Most bloggers would arguably have a better experience with a slew of WordPress features hidden or removed whereas site owners might depend on those very same features for dear life. By catering to many use-cases at once, user experiences across the board are bound to be unfocused in some way or other.

The “Screen Options” tab is an example of a feature that would probably not exist were “decisions not options” taken at face value. Screen Options exists on the idea that not everyone needs to see the “Custom Fields” panel on their Add New Post page, yet acknowledges that some users will find that feature invaluable. It is an option added in absence of a strong decision, for example, to limit WordPress to be a blogging-only tool. I consider it an example of an exception to the mantra for the good of the user. Sure, the UI could use some improvement, let’s work on that, but I really appreciate the ability to hide the “Send Trackbacks” panel.

I’m a fan of WordPress. I’m a fan of good decisions, and I’m a fan of good UI design. I believe that if we relieve ourselves of arbitrary straitjackets and approach each design objective with a sense of good taste and balance, we can make excellent open source software. Cauterizing entire avenues of UI simply because it adds options, however, negates the fact that sometimes those options exist in absence of a higher-up decision that just can’t be made for whatever reason.

Do's and Don'ts of Icon Fonts

Having worked on icon fonts a lot in this past year, I’ve learned many things about them I did not know before. In some ways they’re more useful than I thought (yes, icons can actually be pixel-perfect), in other ways less so (pretend Firefox doesn’t exist until it reaches version 25). Since icon fonts are booming these days, I thought it useful to share some do’s and don’ts that I’ve picked up over the course.

An icon font is a font that contains symbols and graphics instead of letters and numbers. Remember Wingdings? These symbol fonts are incredibly useful because they allow webdesigners to do things they can’t do with PNG or GIF graphics:

  • it’s HiDPI out of the box
  • they scale well (more on that later)
  • it’s easy to pick colors using only CSS

They’re so pleasant to work with that it’s easy to get carried away by the obvious benefits over PNGs. Unfortunately there are a number of limitations to be mindful of. Most of these can be mitigated by using icon fonts properly.

Scalability at small sizes

Just because icon fonts are technically vector graphics, doesn’t mean they all look great at any size shown. Especially at small sizes, icon fonts start falling apart. This is why good icon fonts are designed according to a pixel grid.

A pixel grid is a minimum resolution at which embedded icons show up crisp. Typically such a resolution is 16x16px (which translates to font-size: 16px) or 20x20px (which translates to font-size: 20px;). If you use the icons outside of their intended grid, the icons will get blurred and details become fuzzy. If you show an icon intended for 16px at 17px, it will look positively atrocious.

We’re used to this from the Nintendo 8-bit days: there’s only so much resolution to work with. Unless you place your pixels precisely, your graphics won’t be clear. Being vector graphics doesn’t change this one bit: at 16x16px it doesn’t matter how scalable your icon is.

Remember, even if you’re used to being able to use many different font sizes for actual fonts, icons are a different thing. Not only are our brains trained to recognize letters, but fonts themselves are designed to render letters for maximum legibility. Fonts rely on the fact that we read horisontally, and hints letters so that subpixel antialiasing ensures horisontal crispness at many arbitrary sizes. This subpixel antialasing does not translate to icons. Icon fonts won’t ever look as good as normal fonts do at arbitrary sizes.

Let there be no doubt in anyones mind: using icon fonts for web graphics is a hack!

It is a glorious, wonderful hack. But it is a hack. We have to be mindful how we use it.

Crossdomain fonts

Firefox blocks a stylesheet from example.com from loading a font hosted on cdn.example.com. It is an intended font piracy/hotlinking measure. The workaround is simple, but easy to forget when you’re pounding your head against the desk unsure why icons show up fine in Chrome but not Firefox.

The easiest workaround is to base64 encode the font file itself and embed it in the stylesheet. By being embedded directly in the stylesheet, no domain hops are necessary, and Firefox loads the font. Most icon font bundles (such as Genericons) come with base64 in tow, but if you’re making your own icon fonts, I recommend using FontSquirrel’s Webfont Generator which will optionally base64 encode for you.

Inserting icons

Because icon fonts are hacks, most icon font packs been through a rather lengthy process to make them as easy to use in webdesigns as possible. Ideally it’s a matter of referencing a stylesheet and copy/pasting a snippet of code.

But don’t get carried away. Behind the scenes numerous decisions have been made in order to make your icon fonts that simple to use. Some of those decisions have consequences outside of just the icons.

This is going to vary from icon font to icon font, but let me go through how the Genericons copy/paste tool works.

Glyphs

Right on the Genericons homepage, the third copy option next to the big icon preview is “Copy Glyph”. This is intended only for use in your Photoshop mockups. You download the icon font and install it on your system. Now in Photoshop you can paste the glyph in a textarea, set it to the Genericons font and the icon will show up.

It is not intended to paste in your actual HTML. Remember, icon fonts is a hack, and a screen-reader wouldn’t know what to do with a weird unicode symbol. Incidentally that means we can only rely on using CSS’s :before selector to insert the glyphs. That means using icon fonts in an accessible manner can never work on IE7.

Copy HTML

For casual users who want to insert Genericons as they would smileys, the “Copy HTML” feature is provided. In effort to make it as easy as possible to get the ball rolling and an icon showing, some helper CSS is provided with Genericons where every icon is mapped to a preset of named classes, for example:

<div class="genericon genericon-calendar"></div>

That’s a lot of CSS classes inside a redundant empty div, don’t you think? Yep. It’s not great code. But it’s really easy to insert, so the casual user doesn’t have to worry about the CSS. It’s perfect if you mean to insert a star icon in the middle of that article you’re writing in your CMS of choice.

Copy CSS

This is the option non-casual webdesigners should use. While also the least easy way to insert an icon (since you’ll effectively be re-writing some of the bundled helper CSS), it’s not actually as hard as I may be presenting it here. You should be using this method because:

  • it’s the most accessible — screen readers don’t even attempt to read the icons aloud because they’re inserted using only CSS
  • it’s the cleanest — there are no extra CSS classes and no redundant markup
  • you have the most control: since you write all the CSS, you don’t have to unstyle some of the bundled Genericons helper CSS you don’t need

The process is to essentially manually attach the icons to the :before selector of the class needed:

.my-element:before {
	content: 'f408';
	display: inline-block;
	-webkit-font-smoothing: antialiased;
	font: normal 16px/1 'Genericons';
	vertical-align: top;
}

The content: 'f408'; part is what you get from the “Copy CSS” tool. You can structure your own CSS as you wish to minimize code duplication.

In summary

Using icon fonts is a wonderful hack that brings many convenient features, but unless you’re using them right, you’ll end up with fuzzy graphics. Knowing is half the battle, and here are the rules:

Rule #1: When showing icons small, do not stray from the font pixel-grid (unless you have a good reason). If the grid is 16×16, show the font at font-size: 16px exactly.

Rule #2: Don’t rely too heavily on the helper CSS, that is intended only for casual use.

Now go use some icon fonts.