Author: Michael Arestad

Improving the WordPress experience

This is a copy of a post I initially wrote for a8c design.

The experience of creating a WordPress site can vary wildly. Occasionally, I hear how someone set it up without any major roadblocks. I more often witness nightmare-level setup experiences. Together, with help from the community and hosts, we’re working to improve the process of building a WordPress site.

The fractured flow of the past and present

Putting together a WordPress site is never the same twice. Ultimately, the goal is to create a website with a nifty domain that is available for someone to see. Unfortunately, it is often easier said than done. There are two general paths one could go in to create their WordPress site: the self-hosted route (more control, but more manual setup) and the hosted route (something like WordPress.com where control is limited).

The self-hosted path

The phrase “self-hosted” is admittedly confusing. It doesn’t necessarily mean the user is hosting the site on their own server. It refers to any setup where the user has full control over their site because they either have purchased server space on a host like Dreamhost or, occasionally, they have built and are operating their own server space (super cool to hear when someone does this). Another way to put it is the site’s admin will have FTP access which allows adding, removing, or modifying files on the server and they are also able to install plugins or themes to their heart’s content.

The self-hosted site is like owning a house. You can do what you like with it. You can add a fence or take down a wall. You can paint it whatever color you like. However, when something breaks, you have to figure out how to fix it yourself or pay someone to fix it for you.

The self-hosted path can be somewhat treacherous. I have attended and hosted many WordPress meetups aimed at helping folks out with their WordPress sites. I often meet folks who have encountered unexpected roadblocks when attempting to put together a site as a result of inexperience and complicated flows.

For example, many folks think of websites as a domain. (Those familiar with this process can skip to the next section of this post.) A domain is just an address that points to a server where their site would live, but they don’t know that just yet. So they buy a domain. Then they struggle exploring the settings panels of the site they purchased a domain from trying to figure out just how to get to their site.

Eventually they figure out there’s this other thing they need to pay for called a host. When they find a host, they might notice that hosting usually comes with a domain. All of a sudden the price of their site just went up and they may be feeling a bit irritated at this point because they now just paid extra for a domain without realizing it. Their options are either to get hosting, try to get their money back on their domain, or try to transfer their domain. The latter is probably the most tricky for inexperienced users since anything involving domains is a slow process laden with jargon.

So now they have a host and a domain. With luck, they are connected possibly due to some help from the host’s support team. They are usually pretty friendly and helpful. They see these kinds of requests often.

Now they just need to get their WordPress set up. Again, this can be done multiple ways. With luck, the host will have a one-click install application within the host’s control panel. With even more luck, the user will find it and run it. If they don’t, they may end up attempting the “famous” five minute install. It will not take five minutes. Especially not the first few times they attempt it.

Screen Shot 2017-07-24 at 11.10.21 AM

In fact, the “famous” five minute install is mostly famous because it never takes five minutes. It should probably be named, “the famous thirty minutes to an hour install.” This is because it involves steps most folks have never done or even heard of before. How many of you even heard of an FTP client before trying something like this? And setting up a database is… well… it feels like just clicking something might break it since most of the wording is unfamiliar.

There can be any number of complications when doing the five minute install. Some may not even be the user’s fault. I have met folks who tried some fringe host I’ve never heard of or a free host, both of which are incapable of running WordPress, but don’t make it clear to newer users.

Let’s fast-forward a bit assuming they get WordPress installed and running. They have their password. Their domain is hopefully connected. Now they just need to do the thing they were hoping to get to right after they purchased the domain: building a nifty website.

Most folks jump right in to picking a theme. For many reasons, the look of their site is higher priority than creating the content. For those of you who have created many sites, you know that isn’t super necessary. In fact, it likely should be the other way around. So they scroll through infinite themes in the theme directory. They feel that theirs should be unique so they start looking at premium themes. They finally find one they like, pay for it, download it, figure out how to install it… and viola! It ends up looking nothing like the demo site. In fact, it’s nearly impossible from the user’s perspective to make it look like the demo site. How did they get that carousel on the home page? How do I put my articles in those spots? Many struggles, forum posts, and web searches later they have something vaguely resembling the beautiful demo site they thought they could achieve with the theme.

Then they find out they need SEO and a contact form and maybe even a web store. How hard could it be to add those? WordPress has plugins! The first two aren’t too hard. They grab the first SEO plugin they see and a contact form. Both are popular and somewhat straightforward to use. Then they find out creating a storefront is more difficult. Maybe another day…

Now it’s time to create the rest of the content and have a successful site!

That’s the potential route of someone who has a self-hosted site. It doesn’t include things like how the host handles traffic sites (the site might go down), how a plugin update might break things, how certain plugins can slow down the loading of their site, or how to recover a hacked site.

The hosted path

The hosted way is what sites like WordPress.com are where the customization is somewhat limited and the user has no (or limited) access to modify, add, or delete files on the server through an FTP client. Usually they can’t add plugins or themes since those can both include malicious code.

While the self-hosted way is like owning a house, choosing the hosted path is more like getting an apartment. You can customize it a bit, but you can’t just knock down walls where you like. However, it’s unlikely you will do much to break it and, when you do, the landlord has to fix it instead of you.

The experience is a bit nicer in some ways in that it is harder to get lost and folks don’t need to mess with FTP clients or much jargon. On WordPress.com the user can start by picking a theme. Then they can choose the domain they want or add it later followed by a plan. It’s pretty quick from start to site creation.

However, the hosted path can be treacherous as well. In the past, a user might start self-hosted only to realize they need functionality not available within the hosted site’s feature set. They put all this work in to their site and now need to go the self-hosted route, which used to be a bit of a bummer because it involved exporting content and trying to recreate functionality along with the joys of setting up a self-hosted site.

But, hey. We’re working to make it much better and we’ve already got flows in place that dramatically improve the experience through WordPress.com.

A unified WordPress experience

At Automattic, we have been working for the past few years from different angles to help unify and improve the WordPress experience as whole benefitting the community, the hosts, the developers, and, most of all, WordPress users.

Working with hosts

We are continually working with and reaching out to hosts to do what we can to make the WordPress experience better. This includes encouraging simpler setup flows bringing one click installs into the process rather than at the tail end. It also includes getting Jetpack and Akismet preinstalled and set up without the user having to do too much or pay extra. Dreamhost does a pretty good job of this. We also work with the community to encourage hosts to upgrade to newer versions of PHP so users aren’t stuck with older versions we no longer support.

The future of moving a site

Right now, if a user starts on WordPress.com and the needs of their site grow beyond what is available on our platform, we offer multiple ways for them to move to or from a self-hosted setup.

The first path to move to a self-hosted setup is similar to what I previously mentioned in that we let the user export data as usual. They can then import everything on their self-hosted site.We also allow the download of many themes so there’s a good chance they can use the same theme. As a bonus, we also encourage installing Jetpack which gives them back all of the features they had on WordPress.com. This means if they had custom post types set up, they will just work correctly after activating Jetpack.

The second path is a pretty hands-off version of the first. It’s called Guided Transfer and includes the migration of a WordPress.com site to one of our recommend hosts. It includes migration of all the content, stats, themes (sadly not premium themes), and setting up Jetpack on the host so the user still has all of the features they are used to. They can even continue to use WordPress.com’s interface to create or add content if they like. It’s fairly seamless, but can be slightly rough if their theme can’t be transferred.

Now, it is also possible to move a site from a self-hosted site to WordPress.com. It’s fairly manual and involves exporting data from your self-hosted site and importing it into the WordPress.com website. If the user had Jetpack installed, all of the features they used there will be available on WordPress.com as well. We can also move over followers and stats upon request.

Basically, we have created a product that allows a user to move the content to a place that gives them the tools they need to grow their site. It’s a two-way stream and helps our hosting partners, our users, and hopefully lightens the workload on developers tasked with migrating sites.

The future path is something even simpler and friendlier. It would involve an interface allowing seamless transfer from one place to another with the option to select a host or something like WordPress.com. Let’s see if we can come up with something.

The Jetpack

Screen Shot 2017-07-24 at 12.43.04 PM

Another major move to unify the WordPress experience has been through Jetpack. We have built a product that provides a bridge between the WordPress.com platform and self-hosted sites. The latest iterations involve an interface that matches up with WordPress.com’s and even encourages using WordPress.com to manage or create content. It also includes the ability to sign in to your self-hosted site with your WordPress.com login.  These features are pretty handy for those of you with multiple sites and even if you don’t, there are several pretty useful ones for any site.

Several of the features provided benefit developers, hosts, and the users. For example, there is a feature that serves your images from our servers (Photon). This lightens the load on hosts. It also serves the images at the proper size for the device it is loading on. This means it loads them extra crispy and detailed on devices with high resolutions. This makes the users happy since their photos will always look super sharp.

Screen Shot 2017-07-24 at 12.44.03 PM

Behind the scenes, there are all sorts of developer-y things baked into Jetpack that a developer can hook into to make the site hum exactly the way they want. For example, Photon has an API that lets them apply Instagram-like filters if they want. They could make all the images on the front page black and white or with a color tweak.

The ideal

Ideally, we want to build a system that doesn’t particularly care where the user starts or ends up as long as it gets the job done well. We want them to be able to create a site that has everything they need without going through too much trouble. If they need to move it, that’s fine.

We want to build paths to WordPress that benefit our hosts. Making the setup flows easier and the maintenance painless is super important. If we cut down the setup time dramatically, more people will successfully build sites and stay on their host.

And we want to benefit our WordPress experts and developers. You folks are the backbone of this ecosystem. We are working to provide pretty nifty tools and toys you need to do your work well. We’re going to continue to provide what we can to help you build really nifty sites. The less time you have to spend struggling through site migrations or restoring broken sites, the more time you can spend on the fun stuff.

The Next Level™ ideal

Even more ideally, we will build a system that works so well one could build their entire site right from our mobile apps without having to jump through too many hoops to get it set up.

And even more Next Level™… VR setup flows! How dang cool would that be? Rami Abraham made a pretty cool video of what that could be like somewhere on the internet. @ him for more info on it.

What do you think?

Got any ideas you’d like to try or see us try? Let’s continue to work together to make building the web pleasant and maybe even pretty fun (dream big, right?).

Organize your CSS properties however you dang like

Over the last several years, I have read several lengthy articles on how everyone should organize your CSS and why one method is better than another. In fact, I have even bought into several of these ideas in the past, but let’s take a look at what these systems are trying to solve and why they are largely unnecessary these days.

Generally, there seems to be a slowly-fought low-emotion war between alphabetization of CSS properties and “logical” groupings of properties. The methodologies tend to hinge on readability versus reducing the risk of duplicative code and are largely written to satisfy hypothetical problems . Let’s do a quick refresher on alphabetical versus “logical” groupings.

Alphabetical

For those of you unaware (and still here), alphabetical ordering is just as the name suggests. The properties are ordered alphabetically. Organizing alphabetically is done with the idea that it is predictable and it’s unlikely you’ll have duplicate properties.

Example:

.alpha {
  background: #fff;
  color: #333;
  font-size: 1rem;
  font-weight: 300;
  left: 0;
  line-height: 1.5;
  margin-bottom: 20px;
  padding: 0 20px;
  position: absolute;
  top: 55px;
  width: 70%;
}

“Logical” groupings

This is the category I have leaned toward in the past. It allows people to group things together in a way that is logical to them. Keep font stuff together. Keep positioning stuff together. Keep animation stuff together. You call it.

Example:

.logical {
  background: #fff;

  position: absolute;
    top: 55px;
    left: 0;

  margin-bottom: 20px;
  padding: 0 20px;
  width: 70%

  color: #333;
  font-size: 1rem;
  font-weight: 300;
  line-height: 1.5;
}

Neither are better for any reason

Yep. Spoiler. Neither matters all that much and you can use every method on the same project without the universe imploding. Time to debunk some stuff!

Ease of reading

I think we can all agree that alphabetical isn’t perfect. It’s starts to get pretty funky when you get into absolute or fixed positioning with various authors making various recommendations. It’s also only super quick to skim when you know what property you’re looking for. It’s also not super intuitive to gather all the font or box-model properties to see what’s going on.

Most “logical” groupings (even ones in different orders with different conventions than ones I regularly use) are straightforward to read. There aren’t too many problems. Usually people get positioning, box model, and typography properties grouped nicely even without training. Heck, at this point I would recommend not even bothering to stress too much where things go. Let people do their own thing. Worst case scenario, you have to skim through fifteen properties. More realistically, though, it’s usually only a couple.

But none of the above matters. Ease of reading is a straw man argument by me. It’s easy to knock down because all that matters is the easy of finding a property. This is just as easy with either method and more often than not, in my experience, starts in the browser. Yep. Digging through inspector where all of our sweet line breaks and comments get reduced to a single list, but once you find it there, you can hope to the file and modify your property. You don’t even have to look that hard!

I have one more minor point to make about readability: Most of the time, property lists are short. We’re talking two to six properties. Both methods often end up looking and operating just fine at that length.

Reducing the risk of duplicate properties

Use a linter. Seriously. We have tools that pay attention to this so we don’t have to. Alphabetical is still suspect to minor duplicative properties unless you eliminate shorthand properties like the following.

.duplicate-line-height {
  font: 15px/20px serif;
  line-height: 1.5;
}

In addition to a linter, implement a code review process on all code. Even just one extra set of eyes will catch these things. Not only that, but you’ll grow much quicker as a developer when you implement a good code review process.

The takeaway: Do what you want

I get it it. You’re passionate about things and like them to be predictable. So do I. It’s satisfying to write that way, but it turns out, it’s not essential to writing really beautiful CSS. Use multiple patterns in your project if you want. Encourage people to try different things with their property ordering. Some might work. Some might make you cringe a little, but relax. You no longer have to stress about keeping everyone’s properties in a single opinionated order. You can do yours exactly how you want and they can as well.

There’s an additional benefit to mixing it up. When properties aren’t in a predictable order, you actually have to spend a little time reading them. Don’t worry. We’re talking additional seconds, not minutes. Don’t panic. More often than not you’ll end up improving on code you never would have seen if you just skimmed down a list for your desired property.

What do you think?

Have I gone mad? Am I way off base? Is this going to be nightmare-fuel for you (I hope not)?

Design.blog

A fellow designer and coworker of mine at Automattic, John Maeda, has been curating articles on the fairly new design.blog since August last year. After WordCamp US, he invited Mel Choyce and me to write an article for it each.

He also asked me to design the cover. Designing the cover felt similar to coding for CSS Zen Garden, thought I had a tad more control over the HTML. Javascript, however, was a no go. I did some fancy Sass tricks to generate the absurd CSS for the animations. I hope you like it.

Here is my cover, which includes the links to Mel’s and my articles. You should also peruse and follow the various articles and covers produced on design.blog. They are quite delightful.

Safari, I want to love you, but I just can’t

I have been using Safari as my default browser for the last few months. I really wanted to see what Apple has been up to with their browser and wondered if I could use it effectively for designing and building websites.

The gist is that the browser is pretty dang nice for the most part. I love a bunch of the built-in features like their reader-mode (a must on hard-to-read sites). That said, it’s not the greatest for development or for having a bunch of tabs open.

Continue reading “Safari, I want to love you, but I just can’t”

blog. to .blog

I’m super excited to finally ditch my old blog.michaelarestad.com blog address for something a bit nicer. Thanks to my generous employer, I now am the super proud owner of michael.blog. I went through the process of setting up the domain on get.blog and I have to say, it was pretty dang slick. I moved all my content over via the importer (a little rough) and it’s now ready to go.

But what about old links?

Well, after a bit of googling, I found a plugin call Redirection by Automattic‘s own John Godley (I love it when my coworkers have already made the tool I need). It took some time, but after reading his instructions, I found it to be fairly simple to set up. Now it will redirect any links to my old site right on over to my new site. Pretty spiffy! Thanks John!

.blog everything

I also picked up a few other .blog addresses here and there including one for my pup (yeah I’m that guy). There are tons of sweet .blog domains available. Go get one!

Reclaiming my hard drive

In the middle of a Zoom call a couple weeks ago, I got a system notice that I was running out of space on my startup disk. It said I had 1.6 gigabytes free and the number was dropping rapidly.

Crap.

I did some quick measures to get through the call by deleting some unused virtual machines and unsynched an entire dropbox repo. Boom. Back up to 43.2 gigs. Nice. Good enough for the call.

After the call, I knew something had to be done. It’s not easy to figure out which folders and files are taking up space on a Mac out of the box, so I nabbed a paid app from the app store called DaisyDisk. I had seen it earlier and knew it was semi popular. Might as well take it for a spin.

Immediately after installing it and scanning my hard drive, it made it really easy to dig in and see where my space was going. 67 gigs were used in a folder called MobileSync. It’s the backups folder for devices. I hopped into iTunes and removed all my old backups. 67 GB gained.

I then opened up my applications and started removing ones I hadn’t used in some time as well as ones Apple had replaced like iPhoto and iMovie 9.9.

Removing Adobe apps was a little rougher using the Creative Cloud application. An app has to be updated to uninstall it. Yes, I could have just deleted the files, but I wanted to try the interface. I removed some of my unused Adobe products giving me a bit more space.

Now I’m back up to 128 GB of space. Not bad. I’ll have to do some more digging into Photos and Movies to see if I can kill their cloud caches or something. They add up to around 27 GB of space. Yeesh. I thought the cloud was for keeping stuff off my hard drive.