For my own sanity, I decided to merge a two of my blogs into this one. I made sure every post on each blog I imported came with its own category.
I first imported nomad.codes. It is a site I used to show off travel and adventure-related photos. You can peruse the category #adventure if you would like to check it out. I will continue posting this kind of content here and will sunset nomad.codes.
Then, I imported an old photo blog my roommates, Michaella and Chris, and I put together when we were in an apartment with an amazing view of Denver and the front range. Definitely check out the photos in the #skylab category.
There are a couple other old blogs I have floating around, but I don’t think I’ll import them just yet.
Not only is it an awesome editor by itself, but right now there an incredible amount of creative work by developers to enhance Gutenberg. The best part is, all of the things they are building are accessible for anyone to use. No need for shortcodes! No need to know code! It’s all right there for you and will only grow stronger with each day.
Of course there are fears of plugin compatibility and loss of content, but I think it’s irresponsible for folks to immediately rush to take advantage of folks fears by recommending the classic editor plugin.
I’m excited to finally release the work my team has been hard at work on for the last few months in Jetpack 6.8. This release is special because we are introducing Jetpack blocks for the new editor.
Some of the blocks should be familiar to longtime Jetpack users and we’re even introducing a shiny new one for Jetpack users called the Simple payments button. It’s a block that makes accepting credit card payments as simple as it gets.
When I was looking into nifty Raspberry Pi projects, I stumbled across the PirateBox project. The website describes it well:
PirateBox is a DIY anonymous offline file-sharing and communications system built with free software and inexpensive off-the-shelf hardware.
In other words, it’s a bit of preconfigured software you can run on a Raspberry Pi that lets folks chat, share files, and peruse forums on an offline network created by the Pi. Oh, and it’s GPLv3! Open source software FTW!
I have always disliked sharing files via Airplay (Mac-only), Dropbox, or other methods. They work, but require some mental overhead and for everything to magically work. There’s also sharing via USB, but with USB C, that got slightly more annoying.
To me, PirateBox sounded perfect. I could quickly fire up a network from my backpack and share files with those around me. I could use it at meetups or WordPress events after loading it up with some WordPress stuff so folks don’t have to deal with sketchy internet to download software. All pretty pragmatic uses.
I also really like the idea of firing it up when I’m working at busy coffee shops and at conferences to see what folks do with it. Will they try to add malicious software? Will they add poetry and selfies? I guess I will find out!
Yesterday, I downloaded the PirateBox software and loaded it onto a Raspberry Pi Zero W. That’s the itty bitty Raspberry Pi. The folks who put the PirateBox together did an excellent job. It was super straightforward to set up and didn’t require a monitor, or any attached keyboard or mouse. I spotted the PirateBox network on my Mac, joined it, and connected via SSH.
For those of you unfamiliar with SSH, you can crack open Terminal (in Mac) or a console in Linux and talk to another computer. PirateBox walks through the process right on the site.
After I followed the short and sweet setup instructions, I opened a browser window and was greeted with the PirateBox interface.
I tested out just about everything (except the forum) to make sure it worked. Then I decided it was time for me to do some design magic to the interface. It was not the easiest process to figure out as I had to locate the files and understand their build.
How to customize the interface
The important files are all over the place and were somewhat of a mystery to locate. This should help out folks in the future.
The home page
Much to my surprise and delight, there is some basic, but functional localization of the web app. If you want to change text on the home page, you will likely need to change it in multiple places. You will need to change it in the HTML and in the corresponding file in /mnt/sdshare/share/content/locales/. Bonus points if you translate your new or modified strings!
The file browser HTML
I found the file browser HTML to be one of the quirkiest bits. It’s split into three parts. The two you likely will want to mess with are located in /mnt/sdshare/share/Shared/. This is also where your uploads end up by default.
The two files are the first half of the page and last half of the page. The first half is HEADER.txt. Why it is a txt file is beyond me. The second half is in README.txt. Again, why these are this way are a mystery. However, they are just basic HTML and are easy enough to modify.
The chat content
If you for some reason want to clear out the chat or remove a comment, you will need to modify at least one file. The important one is /opt/piratebox/www/cgi-bin/data.pso. If you remove content from this file. the next time someone uses the chatbox, it will regenerate the second file, /opt/piratebox/www/chat_content.html, which is used to render the chat and. This will remove the content. If you want it gone from the chat view immediately, you will need to remove the same content from both.
I wanted to add some breathing room, make it feel friendlier (for my non-pirate friends), and make it look good on high resolution screens so I did just that.
As you can see, it’s not perfect. The header’s a bit big, but hey I did this in an afternoon and I can fix that up as I iterate. I also need to style the upload a bit nicer.
It’s also mobile-friendly and should be fairly accessible. I think a few of the chat box’s form fields could use labels so maybe I’ll add those the next time I mess with it.
For those curious, here’s what the final build looks like.
It’s just a Raspberry Pi Zero W with an SD card and power supply. I put it in a nifty case I found on Amazon, but that’s unnecessary. It might even be cool to strip off unused ports to lighten it and put it in a book, wallet, or maybe even a clever laptop case.
What do you think of this idea? What cool things would you use it for? Leave a comment!
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.
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.
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.
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.
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 providewhat 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?).
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.
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.
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.
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.
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)?
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.
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.
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.
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!
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!
There are enough WordPress plugin and theme listicles out there to match a single day of Buzzfeed-generated articles (probably not), but I think it’s time we took a good look at some of the truly inspiring plugins out there.