Tag: essay

Why I Like Font Icons
I really like Font Icons and I’m willing to bet there was a period of time you did to, way before we had the Internet on our phones. Do you remember Wing Dings?

When I was a kid they were awesome. We used them to print up secret code letters in the ’80s, using the basic letter shift kind of cypher. Wing Dings is, at its heart, a font icon. This means it’s a font that uses shapes instead of letters, but unlike Wing Dings where I could type “cat” and get “hand arrow flag”, a modern font icon has special content terms like “f401” that you use instead. Of course those are hard to remember, and we all like to use shortcuts, which I’ll get to in a second.

The reason I love them is that I am a monkey with a crayon when it comes to design. Did you ever try to make an image that, when you rolled the mouse over it, it changed color? Like the official Twitter image you wanted to spin when the mouse hit it? We used to do that with images, CSS sprites, and combine all the images into one large image, load it once, and then with the magic of CSS have different bits load at a time. Sprites and Bitmaps can do that, but adding in new icon to the set took time and Photoshop and if you’d lost your designer in the meantime you were out of luck. Font icons lower the bar and make it easier for everyone who can’t design.

Font icons are easy to style. You can resize, recolor, flip, shadow, and apply rollover effects with just some basic CSS. They also scale well which means they were pretty much born for retina. No matter the size of your device or the quality of your screen, the font icon will never look jagged and blurry.

So how do we use them? It’s only three steps and the third is beer. Seriously, though it’s really that simple. Include the font family, just like you would a google font, or do it locally. Call the icon, show the icon.
1. Include the font in your site
2. Call the icon you want with the span html tag
```
<span class="genericon genericon-aside"></span>
<i class="fa fa-beer"></i>
```
3. Drink a beer [ficon family=FontAwesome icon=beer color=brown size=3x]
That beer is a font icon by the way.

There are plugins, for most of the popular ones, that will let you insert using shortcodes. Those are easy to use for when you want to put an icon in your post content. I wrote two of them, Genericon’d (which brings Genericons to your site with shortcodes) and Fonticode (which lets you apply shortcodes to most of the major font icons, provided they’re already included in your theme or another plugin). But wait, there’s more!

As I mentioned, you can use them in CSS, and by that I don’t mean you can style them. What I mean is you can use CSS to call a font icon and put it in a menu, which is a little trickier since you need to use the before call, and that is a little weird. I talked about how to do this before in ShareDaddy Genericons (which is now useless since Jetpack went and did that for everyone) but the point is that you have to mess with CSS and it looks like this:
```
div.sharedaddy .sd-content li a::before {
    font-family: 'Genericons';
	font-size: 16px;
	color: #fff;
}

div.sharedaddy a.sd-button>span {
    display: none;
}

div.sharedaddy .sd-content li.share-twitter a::before {
    content: '\f202';
    color: #4099FF;
}
```
As an example, this is a pretty basic one. The magic sauce here is that I say “Before all my links, use the font family Genericons with this size.” And then “Before Twitter, I want to show the content \f202″ That happens to be Twitter’s icon. The color I used is also the official Twitter blue. You can get even fancier and I suggest reading Justin Tadlock’s post on Social nav menus.

The obvious next question is where can you find font icons? Here’s a non-exhaustive list.
- Genericons
- Font Awesome
- Libricons
- Octicons
- Glyphicons (Halflings is GPL, the rest are CC and proprietary)
- Icomoon (free version is GPL, the rest are proprietary)
I will note that some of these are not GPL, so it’s on you to check the licenses for what you want to use them for. Like Glyphicons? You can use their Halflings font freely, but not the full Glyphicon pack. Similarly, Icomoon has a couple font packs that aren’t free and for full distribution, but does have one you can use. So please, please, be careful and be aware. You can use the non-GPL ones on your own site (most of the time) but you can’t package them in a theme or plugin.

Before someone asks, let me talk about Dashicons. That comes in core, so you don’t need to worry about including that. I wouldn’t use it on your site, since it’s meant for the WP Admin back end and nothing more and the size is a little off because of that. You can totally use it on your plugins. So instead of making an image, you can use a Dashicon to be the icon on the menu sidebar. This may one day change, but not today.

All this love doesn’t mean everything’s awesome. There are some issues, like how Icon Fonts Are Ruining Your Markup. And you should read Ten reasons we switched from an icon font to SVG for some great reasons not to. You also need to keep in mind accessibility, like screen readers, and for that check out Bulletproof Accessible Icon Fonts.

Nothing’s insurmountable, and the easy of a font icon without having to mess with GIMP or Photoshop or pretend I know what I’m doing with art is worth it all for me.
27 October, 2014
Why You Can’t (Always) Catch Cache

Or rather, why you don’t want to cache.

When speeding up a site, the first thing we always talk about is streamlining the site. Ditch the redundant plugins, clean up the code, get a lightweight theme, dump the stuff you don’t use, and upgrade. Once you’ve done that, however, we talk about caching, and that is problematic. Caching is tricky to get right, because you can’t cache everything.

Actually you can, but you don’t want to cache everything, and you really shouldn’t.

The basic concept of a cache is ‘take a picture of my website in this moment.’ We think of it as a static picture, versus the dynamic one we use for WordPress. That static picture is not so static, though. You call CSS and JS still, and you call images. But the idea there is not to call PHP or the database and thus your site will be faster, as those are the slowest things.

Great, so why don’t I want you to cache everything?

The obvious answer is latency. If you’re designing a site or making a lot of style changes, you need to disable caching because otherwise you get a lag between edits and displaying text. But there’s also server latency.

When we talk about things like PageSpeed (I use mod_pagespeed my server) to improve web page latency and bandwidth usage, we’re talking about actually changing the resources on that web page to the best practices. This sounds great but we have to remember that by asking the webserver to do the work before WordPress (such as having PageSpeed minify my CSS and JS), we’re still making the server do the work. Certainly it’s faster than having WordPress do it, but there will still be a delay in service.

The next obvious answer is security. There’s some data you flat-out don’t want to cache, and it’s pretty much everything in wp-admin (on WordPress). Why? If you have multiple users, you don’t want them getting each other’s content. Some are admins, some aren’t, and I know I don’t need my guest editor seeing the post about where I’m firing her and why.

Actually, we’ll extend this. Very rarely do I want my logged in users to see a cache at all. They’re special, they’re communicating and making edits on the fly. Having them see cached content, and constantly refresh it, will be more draining on my server than just loading the content in the first place. Remember the extra load caused by PageSpeed (or even your plugins) generating the cache? That would be constantly in progress when a logged in user made a change, so let’s skip it all together.

Tagging on to that, you also don’t want to your admins and logged in users to generate a cached page. This isn’t the same as seeing a cached page, I don’t want non-logged in users to see the version of the site a logged in one gets. A logged in user on WordPress gets the toolbar, for example. I don’t want the non-logged in ones to see it.

Finally we have to round back to security. If I have SSL on my box and I’m using HTTPS to serve up a page, no way no how do I want to cache anything related to users. In fact, I may not even try to cache JS/CSS either. The basic presumption of https is that I need security. And if I need security, I need to keep users out of each other’s pockets. The best example of this is a store. I don’t want users to see each other’s shopping carts, do I? And your store is going to be https for security, so this is just one more feature there of.

Of course, there are still things to cache. I setup PageSpeed on my https site so it will compress images, make my URLs root-relative, and compress and minify HTML/CSS/JS. But I don’t have a traditional cache with it at all. This does mean as we start to look towards an https-only world (thank you Google) we’re going to run into a lot of caching issues. All the quick ways we have to speed up our sites may go away, to be replaced by the next new thing.

I wonder what that will be.

22 October, 2014
Working With A Translator
Well I messed that up.

I’ve never been on a panel before, and I’ve never worked with a live translator before, except once and that was ASL which is different. This time, at WordCamp Tokyo, I was on a panel to talk about the Worldwide Community of WordPress, and other things, and we had a wonderful translator with us, Shinichi Nishikawa. But I’m afraid we made things very hard for him.

My father, who’s more experienced, gave me a critique later and I have some points to share with everyone.
- Speak one sentence, wait for it to be translated, then move on.
- Keep your English simple.
- No cliches, idioms, or slang. Not even technical slang.
- No jokes. They won’t translate. Don’t even try.
- Don’t laugh at yourself either.
It’s remarkably hard to do this. I’m getting a little better at it, because my father’s wife is Japanese. While she understands some English, I would say her English is better than my French, and she’s mostly fluent in French. So we dance between three languages to try to communicate. With that in mind, I find myself trying for the smallest, easiest, most common words when I want to explain something.

For example, at dinner she was trying to say that my father has no sense of direction. This is true, but in Japanese there’s a word to mean ‘you lack this skill.’ You can apply it to anything, and as we were talking about it, she asked what the word was, in English, for someone who has no sense of music. We explained it was ‘unmusical’ or ‘no sense of music’, but I also mentioned ‘tone-deaf.’ This lead to us saying things like “You are tone-deaf in driving!” Where English will put a modifier on the word, the Japanese have a second word to add in front that puts the proper emphasis.

Understanding that one, small, thing changes what words I want to use when explaining WordPress (or anything) to someone who doesn’t speak my language natively. I’ve done this before, with normal conversations and travel, but doing it for WordPress was very hard because we’re used to things like ‘doing_it_wrong()’ and even ‘Howdy, Ipstenu.’ Those are small words we think of as normal and simple, but their concepts are so large they lose something in the translations.

Besides just words, I’ve learned we definitely need to translate our brochures into the language of the country we’re in. Not having the pamphlet be in Japanese was a killer. Also our little DreamHost Robots need names!

Everyone thought our mascots were adorable, but they needed names. Since we have three stickers, one of them being tiny, I said we should call the little one “Yume-chan” because Yume (夢) means Dream in Japanese, and ‘chan’ is a diminutive. My father calls me ‘Mika-chan.’

Just for an example, Wapuu is the mascot of WordPress in Japan. So really anything small and cute like this needs a name.

Knowing that, I feel more prepared next time not just should I come again to Japan, but also in general for how I present at a WordCamp. Every time I come to one, I learn a little more and a little more about myself, WordPress, and how we all communicate.

WordPress democratized publishing in more than just your website, after all.
20 October, 2014
Automatic Geolocation

Traveling outside the USA always reminds me of how annoyed I am when I go to websites.

Like most of you, I have a bevy of websites I visit regularly. In my case, a large number of these sites are image or video related, and due to the legality of those things, I find myself restricted based on my current location. It annoys me, because if I pay for a service like my cable TV, why can I not watch it outside my home? Restricting my content based on my location is frustrating. I get CSI at home, but I can’t watch it while I’m here in Japan. This, of course, leads to things like illegally downloading movies, because there simply is no easy, quick, efficient way to acquire those things.

But worse than that is the tacit assumption that just because I’m in Japan, I want to visit the .jp version of a site. The number of sites that auto-redirect me to my current location’s language are not few, and most of them don’t have an easy way for me to click back and explain I’m not able to read Japanese.

For many years I’ve told people that forcing a language choice on users based on their IP is improper and unpredictable. It’s for the same reason I tend not to recommend blocking entire countries from your websites. The probability that you will hit innocents with a broad attack is very high. It’s higher than the chance of rain in Southern California.

So how do you do it right? You have to start by asking the right questions.

What language does the computer use?

You can detect that, you know. If my computer uses English, the odds are that I want to use English. Of course, a French speaker might use my laptop, but that’s on them, and one hopes they know to go to google.fr instead of google.com. Speaking of that…

What URL did I type in?

If I go to a URL directly, I may actually want that URL. This goes for you mobile apps too. If I go to Google.com right now, I get this:

That’s a nice, friendly question in English asking if I’m sure.

Have I been here before?

Cookies. When I go to a site, I get cookies. Those cookies can tell you what language I used the last time. So if you have a flag system where I can pick my language, please do try to honor that. There’s nothing a visitor hates more than having to reset their preferences every time. Facebook, this means you.

Where is my IP?

I know I said not to use this, but there’s a reason I want to ask this. If I take into consideration the URL, the browser locale, and the IP, I have a clearer picture of who’s visiting the site and what they want.

15 October, 2014
It’s Not GPL and That’s Okay

I’m probably starting a wildstorm here, but I want to put this out there. I don’t always use 100% GPL products on my sites, and that’s okay.

Please put down your pitchforks!

I am a happy Open Source person. If you give me a choice between two equally good products, one being Open Source and the other not, I’ll pick Open Source any day of the week. But. There’s a reason I use Apple Pages and not Open Office. Pages works for me. It fits my workflow, it fits my brain, and it makes me write more easily. Since I’m often sprawled on the couch writing with my thumbs on my iPad Mini, it makes perfect sense to use Pages and iCloud.

But there’s another place I don’t worry too much about GPL or Open Source, and that’s when I’m coding something that is only ever going to be for me.

I was working on a new site and we were looking for icons to properly represent how we felt. We needed a toaster. We didn’t have one in Font Awesome or Genericons, so I pulled up Symbolicons! The catch? It’s not GPL. But the thing was, we knew we’d never be distributing these icons. It was for one website, so why did it matter?

And the fact is that for this use case, it did not matter at all!

Understanding what I’m doing, who it’s for, and where it’s going to be used is highly important. And understanding what I want to support and maintain is equally important. For the most part, open source doesn’t come with Apple Care or companies like OWC who specialize in bailing people out or helping them extend things. WordPress doesn’t come with that, for good or not, it’s really a ‘figure it out as you go’ sort of product.

There are use cases to consider. Who’s going to use the computer? What do they know? Is it worth teaching them Linux or can they keep using their Mac? Much like I do when I’m mentoring someone, I don’t try to push my ideals on someone, or assume my way and my solution is the only solution. When I look at GPL, yes, it’s my default. I always start there. But I don’t stop there and I don’t let it blind me to what things need to be, because the best solution may not be open source, it may not be GPL, and it may not be WordPress.

So long as you’re not violating a license, use what suits your needs. But do pay attention to those licenses.

13 October, 2014
The Bias of Transparency

When I was in elementary school, we used to go to SeaWorld all the time. I loved seeing the animals, I loved being able to pet and feed dolphins. I loved the whole data dump of the ocean information. I went back in the days where the trainers were in the water with the orcas. I fed one once, and patted it’s nose. I danced with a seal (and sea lion). I really fell for the whole “Humans and animals together!” patter.

And then I grew up and read about how SeaWorld got those animals in the first place.

Your personal feelings on movies like Blackfish aside, even SeaWorld admits today that they were wrong in how they captured orcas back in the day. They were cruel and wrong, and SeaWorld hasn’t done that in 35 years. But the part of me that is upset with them is the part that wants to know why it took Blackfish to make them step up and say that. And the part of me that’s livid is the part who asks why they don’t disclose their history as a learning experience?

Transparency in development is not a new thing. Technology used to be a magical black box, but the more people embrace open source, I feel they’re more willing to express their issues and explain things that have happened. Even when you don’t understand the whole explanation, being told something like “Yes, the outage was caused because some electrical work caught fire” is much more satisfying than “The outage has been resolved.”

When I talked about why an outage didn’t inspire me to change my webhost, much of the reason was because of communication. While it could have been better, my host was transparent with me such that I knew what was going on. Perhaps not as fast as I wanted it, but I did, at all points in time, know what the deal was.

Being up front about problems gets messier when you start to talk about things like security. Earlier in the year, MailPoet had a security vulnerability. They fixed it, pushed the fix, and then it was reported on and everyone found out. People were surprised to find that the exploit was hunted down by people now that the information was in the wild, and others pointed fingers at the reporters for publicizing of the issue.

It’s a double edged sword. If they don’t report on the situation, people don’t understand how important it is to update. If they do make it public, the bad guys know what to look for. That’s why you get things like the accidental DDoS from TimThumb. People knew to attack for it, and they did. It’s the same thing with the HeartBeat vulnerability or the recent Bash issue. Once a vector is found, it will be exploited.

There isn’t a perfect answer here. There isn’t a perfect balance between information and education and secrecy. We want people to know “Hey, fix this!” but we don’t have a way to tell them without telling evil people. This ends up making us want to keep secrets and hide the truth, which just isn’t going to work in the long run. The only practical answer would be to fix this as soon as possible and hope no one hits us in the meantime.

8 October, 2014