Tag: design

Don’t iframe Me In
I review plugins for WordPress.org, and one of my pet peeves is when I see a plugin that purports to connect your site to their service…. using an iframe.

I have a stock reply to those:

Having the admin dashboard be just an iframe isn’t permitted.

We don’t permit plugins to phone home like that (for two main reasons – security and appearance – too often people assume that they just signed into WORDPRESS and not your plugin). Please change your code to use an API or just link back to your site so they can configure things there.

The minority of the time, this is accepted, fixed, and moved on. The majority of the time, people complain that it’s ‘easier’ or ‘not confusing’ or ‘someone else is doing it.’

If everyone on the planet would stop using someone else doing something wrong as a reason to allow them to do it, I’d be so happy… But that isn’t the point. The point is that using an iframe in a plugin is a bad idea in general, and a horrible idea for your admin panel.

Let me step back. Like everything else, iframes are awesome to a point. They’re a great, easy, way to include content in your site without having to include a mess of code. When YouTube was new, iframes was the only way to include videos, and they looked like this:
```
<iframe width="420" height="315" src="//www.youtube.com/embed/dQw4w9WgXcQ" frameborder="0" allowfullscreen></iframe>
```
You’ll notice the iframe has to specify a height and width, which means I can’t adjust my site quite as much as I want to. The other major issue here is that I’ve had to specify http, which means if my site runs https, I will have security issues. Now, there are workarounds to this (and YouTube now uses a src of //www.youtube.com/embed/oHg5SJYRHA0 to mitigate the security issue), but there’s another, cooler, aspect to how it’s all working.

If you use WordPress, you don’t have to paste in the iframe at all, ever, because you have embeds! What the embed does is use the magic of oembeds to … well … embed! This allows WordPress to reach out to YouTube, ask how it wants to embed itself, and use either embed code or iframes or html5, or whatever else we come up with! It does this using an API (application programming interface) which let’s it talk back and forth. This same principle applies to your plugin pages. If you use an iframe, it’s a quick and dirty way to include content from your service (like a login form) on the plugin-user’s site.

So why don’t I like people to use it? Let’s start with the login issue. The admin page could be changed to point that iframe anywhere it wants, making it easy to send you to a page that looks a lot like the ‘right’ page but isn’t. This is a lot harder to do if, instead, you have an API that securely transmits data. If someone can edit the php code of your plugin, either one is possible to be redirected, but the API details are a little harder to fake.

An iframe is also a problem when you consider layout. Yes, it can make design easier in that you are in full control of the design, but you’re not in control of the rest of the site. I like the eggplant color for my admin dashboard, and if your iframe clashes with that because you don’t ‘look’ like WordPress, then it’s jarring for a user. Another worry? Adblock or Ghostery, the two most popular browser extensions ever, will often block those things.

Finally, and for me this is the biggest one, your users won’t know where their account is. Look, I know it should be obvious when you have something that ‘makes’ an account with a service that the account belongs to the service. And yet. One of the places I help out is with WordPress.org password resets. 90% of the emails are for people trying to reset the password on their own blogs. You can’t convince me that people actually know what they’re doing anymore, if they ever did.

So please, don’t put an iframe in your plugin as the only way I can access your admin area. It’s lazy, it’s insecure, and it’s confusing. It’s 2014. Trust me, people understand allowing their blog to connect to Twitter now.
22 August, 2014
The Wheel Is Fine
“I have an idea for a plugin!” he said to me. Everyone does, but I encouraged this question. “I want to make the media embeds in WordPress more responsive.” I paused. There are already a lot of those, like Responsive Video Shortcodes. So I asked what made his different. “I’m going to make NEW shortcodes!”

I see a lot of plugins. Many times I see plugins where people want to tweak a normal part of WordPress, like the gallery or the embeds. The problem I see is that instead of extending those, they decide it’s better to make a plugin that recreates all the shortcodes and embeds, but with a new name, so users have to remember to use (which is default to WordPres) or [youtube] (which is in Jetpack) or [someothervideotool] (which I made up for an example).

Now I’m guilty of this myself! I have a private plugin which is HTML5 video embeds and it gives the video in HTML5 format, which I could do in the default embed code, but it also plunks a link underneath that says “Can’t see the video? Click here.” And the Click Here goes right to the mp4 video. Because I have some rather dim people. But. I don’t have to reinvent the wheel here. I could instead filter that shortcode just to put my little blurb on the end! Doesn’t that seem smarter?

The first time I thought about this, I said “What I need is to filter and slap something on the end!”
```
function halfelf_oembed_filter($html, $url, $attr) {
    $html .= "<p>I am a monkey.</p>";
    return $html;
}
add_filter( 'embed_oembed_html', 'halfelf_oembed_filter', 10, 3 );
add_filter( 'video_embed_html', 'halfelf_oembed_filter', 10, 3 );
```
This puts “I am a monkey” below every embed, which is great for stuff like YouTube and Twitter. The second filter is for videos when you’re using Jetpack. And this works great, I could even wrap the HTML in something, like a div or js code, and enforce responsiveness. You can check the URLs, see if it’s youtube or whatever, and apply different settings per URL. Works nicely. I actually have my just div-wrapping for padding reasons.
```
    $html = "<div style='padding: 5px;'>".$html."</div>";
```
This works brilliantly, however … I’ll get to that in a second. Now, for my friend’s initial idea, once we banged on this, he said he was just going to use the other plugin, but embed-filtering was way easier than trying to over-ride the shortcodes and reinvent the wheel. It also makes it easier to upgrade.

But then there’s my problem with my site and the need for that “Hey, get the MP4 here!” message. You see, 90% of the videos I have on this particular site are locally uploaded, and since I always upload an mp4 and a webm (and sometimes an ogg), how do I parse it?

First of all, I’m using the Video Shortcode, so I know there’s a simple filter for wp_video_shortcode_override (it works roughly the same as img_caption_shortcode but that’s not what I want to use. I don’t want to replace everything, that’s my whole point here. I just want to make a link! In addition, I know I’m only going to want this when I have a video with a defined mp4, so why not just filter wp_video_shortcode instead?

So that’s what I did:
```
function halfelf_video_shortcode($html, $attr) {
	
	if ( !empty( $attr['mp4'] ) )
	{
		$html .= "<p>Can't see the whole video? Click <a href='".$attr&#91;'mp4'&#93;."'>here</a>.</p>";
	}
	
	return $html;
}
add_filter( 'wp_video_shortcode', 'halfelf_video_shortcode', 10, 2);
```
This slaps a link for my tech challenged friends on browsers that refuse to tolerate videos.
23 June, 2014
All is Revealed
I had some issues with SEO Slides in the past, mostly around how it’s not quite what I need while also being more than I need and less. I banged around this for a while, before I remembered that I’ve seen a lot of people use WordPress for slides in a way that I never really loved, while others used something decidedly not WordPress.

Step back.

I don’t believe that I should use WordPress all the time just because I’m a WordPress person. I thought about what I want from my slides:
1. A way to load them locally or remotely
2. A way to control them and see my notes
3. Usable on mobile
4. Embed-able by me and me only
5. “SEO” friendly
That last one really means “HTML should be readable so a screen reader could make sense of it for the blind.” And that’s really the primary reason I ended up with SEO Slides to begin with. But when I stepped back to really think about what SEO Slides did, and what I needed, I realized that while I really do love it, it made it harder for me to make slides.

Let me explain. SEO Slides’ interface is not the WordPress post editor. I suspect, if it was, I’d be happy since I can mangle HTML there all day long. But SEO Slides doesn’t let you at the source code of the page, you have to use their GUI, and I was having a hell of a time with things like centering and floating and wrapping… All things I’m a boss at with HTML.

In addition, I’d recently discovered serious limitations with pageload, especially on mobile. The fixes in 1.5.0 didn’t fix it for me (actually it became worse with my slides taking over fifteen minutes to load, at which point I gave up). This is not to say I don’t love SEO Slides and what it does, it just didn’t fit my personal workflow. As much as I loved it when I did my EDD presentation for WP Sessions, I wasn’t satisfied.

So as I contemplated my vodka over Passover, I came to the possibility that maybe WordPress was totally overkill for slides. Maybe, like with a Gallery, it was too much and too complicated for something that should be more simple. To me, HTML is simple. It’s straight forward, direct, and I still use it every day. With the exception of paragraph tags, I wrote this post in HTML mode.

I did what comes naturally to me. I went and poked around what some of my friends have done (and kept up or not…) and finally decided that I was going to try out reveal.js.

Wow.

Installing was simple, just a git clone. And while the directions claimed you can’t use speaker notes unless it’s running locally, I found this not to be the case. Maybe it’s because I’m on Chrome, or maybe that’s not updated. Either way, it’s awesome for me since I can suddenly control my slide-deck on my laptop. Making my own slides was also pretty basic, I made a folder for each deck, tossed in the images and the index.html, and went to town. It’s really that easy to do, though I wish there was a basic, example, and not just the big one. Still, a search and replace of HTML is super fast.

It loads faster than SEO Slides, works better on my iPad, and the only thing I can’t do is embed. I’ll live. I’m also sure it can be done, since http://slides.com/ (the freeium version that hosts it for you) has an embed ability. The other massive gain is that it’s smaller. When you upload media to WordPress, you get multiple images, and I have to pre-load each page (or load it on the go). This gets heavy since I like background images and pretty things.

With reveal.js, I just upload one image and I’m done. It loads everything at once, since it’s one HTML page, and the image (while large) is just reused. And that was good enough for me. Also I get to use remotes.io to remote control my slides from my notes (I use the iPhone app Scan, by QR Code City, and paid for it because I hate ads).

I may go back to SEO Slides (who should consider an import from reveal… Hmmmm) but this works for me now. We’ll see if I love it in the long term. I suppose I should actually read stats and see if anyone but me even cares about the slides…
14 May, 2014
Defaults Matter

We tout decicions and not options. We laud people who make it work, simply and efficiently. So how do we decide what the default decisions should be?

I was looking at a new plugin for an affiliate program, and it set up the links based on region. The way this plugin worked, if you don’t have an account specifically for that country, the plugin author had it set to use his ID if the user didn’t enter one. This is a small issue, in that the user may, unwittingly, be letting the dev earn money of their site. It’s also just not permitted. You don’t put up links or ads on someone else’s site without them checking a box to allow it, it’s gauche and against the .ORG guidelines.

Without knowing the issues of the affiliate app, I pushed back, and was surprised that the plugin dev was doing this because if he didn’t, the code would break. The affiliate program didn’t have a fallback to show a default location if you didn’t have an ID for that area, it just errored out. Thankfully, this developer and I worked out a solution. If there was no ID for the region, the plugin wouldn’t display the affiliate links. There was also a checkbox “Use the developer’s affiliate code in regions where you don’t have one!” that explained this would help feed and clothe the dev.

Another example. A plugin made a shortcode to play MP3s, and by default if you don’t have an MP3, it played one of him from his domain. Besides the fact that you’ll crash your server if you get popular enough, the fallback for that should be for the shortcode to output “Oh noes! No MP3 picked!”

This got me thinking about how we determine the defaults for anything. We pick what we want to support most, we guess at what people will use most, and we test what we can think of. But that isn’t easy at all. Start factoring in upgrades. You add a new feature and you want people to use it, so you turn it on to aid discovery (Jetpack does this). Not everyone likes that and gets mad that the first thing they have to do is disable it! So you think about alert boxes “Hey, you upgraded and there’s a new thing!” but then people hate dismissing those alerts.

Picking the right defaults for your intended audience matters. The affiliate code guy knew about an error if he didn’t do that, and compensated in a way that would be seamless for the users, but a little unethical (I felt) because it took advantage of their ignorance to make money for him. I’m kind of hip on educating the masses. The shortcode guy just didn’t think about the long-term ramifications. Neither actually meant to be harmful, but both were thinking about their users and their familiarity with things. Both were cognizant of the fact that a product not working because of incomplete settings should not break.

Determining your default settings is a race between education and simplification. It should be as simple and straightforward as possible to make things easier for the new users. At the same time, it should be made totally obvious in straightforward ways what the defaults can be changed to. This can be done with help screens in your plugins, but also in the welcome pages and the in-line explanations of setup. You can hide aspects of the code from users until they’ve finished pre-requisites.

Defaults are the one place where you have to actually try to know what the users will be thinking, so don’t worry if you get it wrong. You can always iterate.

9 May, 2014
Bad Browser Complacency

Back in the day, you may have seen notices on browsers like “This site best viewed in Internet Explorer v4.” Since then, we’ve moved into the belief that a website should work on as many browsers as possible, and degrade nicely when it can’t. So imagine my surprise when I’m looking at photos online and I get a message saying I’m using an unsupported browser.

I happened to be using Chrome on my iPad, so I clicked the link which took me to http://www.corbisimages.com/BadBrowser and I saw this:

I was taken aback. Not that they say ‘IE 7 and up’ as it’s something I try to support as well. Frankly making sites look awesome on IE is about as easy and fun as a dental student doing your root canal. You’ll get there in the end, but it may hurt like hell.

Now, Corbis has certainly one of the more out of date designs for a photo sites I regularly visit (there are 10), but it’s not the most egregious. Yes, there are worse ones. Still for a site to have an alert like this in 2014 and to omit Chrome is rather shocking. Someone remarked it looked like that site was designed circa 2003 and Chrome, if you didn’t know, only came out in 2008. So while I remember this new design for Corbis being rather recent (2012 or 2013, but that may have just been some tweaks), it’s clear they’ve not visited that page in at least six years.

I talked to my family about web design at a recent brunch, stressing that I do not do website design per se, but I am happy to help them find people and upload their content. At that time, I pointed out that the trick to a website was to frequently update it and make it more modern. “It’s like the runway shows,” I replied. “What’s in this season was weird last season and may be out by next season. So making a site and never changing it is as smart as never updating your wardrobe.”

People judge by how things look. If someone only wears a black turtleneck and jeans (Steve Jobs), we create a specific mindview of them and it rarely changes. Someone who always wears avant-garde clothes that are nearly unwearable (Katy Perry), we create another. If that person always wears a suit jacket (Tim Gunn), we have yet another view. Neither is right or wrong, of course, and they all have their places.

We update our wardrobes when we gain and lose weight, when we decide we want a change, when we feel different, when we have to change, when we want to. While I tease that Brian Gardner is never satisfied with a web design and is always changing, I’m often just as guilty of this as I don’t feel things fit forever. If I’m not afraid of changing my wardrobe, why would I be afraid of changing my website?

And yet. We worry a lot more about the change of design, to the point that sites like Corbis haven’t significantly changed or adapted since 2002, when the site was born. Since then, 12 years have gone by, browsers have changed, security changed, and the viewing experience is wildly different. Corbis on a phone? Yeah not a great experience.

When your site never changes with the times, never grows to adapt to it’s new audience, you lose respect in the world of the Internet. We have to keep up with the times, test and retest on as many browsers as humanly possible, and make sure that it all works. We can’t just say “Yes, this one design is good” and more so, we can’t say “This site works best on…” anymore.

Unless you’re the sort to say “This jeans only work with turtlenecks.” Then, by all means, never change.

2 May, 2014
Why Can’t Multisite…

Many times people complain that WordPress isn’t ‘complete’ because it doesn’t have the features they feel are indispensable. While explaining, and educating, to people that they can’t always get what they want out of core is often fruitless, the point remains that WordPress cannot, and should not, do everything. That’s a part of a longer post, but once you are willing to accept the fact that WordPress will never be everything to everyone, we can move forward.

There are practical reasons why Multisite doesn’t do everything people envision, and there are also some weird impractical reasons. Sometimes the answer to this is a very simple one, sometimes it’s confusing, and sometimes it’s technical. But there are reasons, even though we don’t like them, and over time they change or go away as issues are resolved.

Here’s a list of the common questions I get and their answers.

Why can’t I manage everything about all sites from the network admin?

It would slow your site down. You’ve probably heard me say something like “WordPress Multisite was intended to be multiple separate sites managed by one install of the WordPress files.” When I say that, I don’t mean ‘managed’ the way some people envision managed. When I say ‘managed’ what I mean is “You manage your network settings from the network dashboard, and you manage your per-site settings from the per-site dashboard.”

Not every site has the same settings, anyway. The point being, if WP had to query every site for every setting (like all your comments), it would get really really slow when you have 11k comments on your blogs. And you’d be mad.

Why can’t I set all defaults from the network?

Oh you want them to be all the same? I’m not sure you should be using Multisite, but since you are, this one is annoying.

In normal WordPress, you shove everything into wp_options and call it a day. On Multisite you have an options table per site, so wp_2_options and so on, but you also have wp_sitemeta. Some settings and plugins have been coded in a way to fall back, so it grabs defaults from that table. But. Not everything has been, because there’s a tacit assumption they don’t need to be.

Now there are plugins that will let you force in defaults on new site creation, but given that every single site admin can go in and change them, it would defeat the point. They’ll just change them! Thankfully, it’s a growing trend for plugins to include a Network Admin Settings page, where you can determine how to control things for your network. But that’s only going to be for things like caching and probably Jetpack. Not ecommerce. Yet.

Why can’t I share media?

Because media is content and content is per-site.

There’s a plugin called Network Shared Media which purports to being able to do this, but by it’s nature, content is sacrosanct and separate.

Why are usernames using characters like – . _ are not allowed?

Because they’re not permitted in subdomain URLs and since the blog URL is generated from your login name, it’s not allowed. The site admin can do it from the back end, though. This is highly imperfect, and perhaps should be changed (so maybe we could also have less than four characters in a name, which not even an admin can fix). The logic to do the detection would be a pill though, and you’d still want to do it on things like a mapped domain.

Why can’t I just map a domain!?

That’s being worked on. Eventually WP will have that superpower.

Actually that brings me to the biggest reason why Multisite can’t… It’s not that it can’t, it’s that it probably shouldn’t, or it will be able to do so eventually. If you consider what the original intent of Multisite was, much becomes clear. Open Source Development doesn’t move at your pace, not even if you’re Matt Mullenweg. It moves at the pace of everyone involved in the coding and testing, and it moves at the pace of their ability to innovate. That means sometimes what you want isn’t there yet because it’s not easy, or because it’s not ready, or maybe because no one agrees with you right now that it’s a priority.

After all, sometimes we’re wrong about Open Source Developmen.

7 April, 2014