Categories
Uncategorized WordPress

I am this years WordCamp Philly Keynote Speaker

Cheesesteak Wapuu designed by Tracy Levesque

We’re pleased to announce that Aaron Jorbin will be the Keynote speaker for WordCamp Philly 2015!

Source: WordCamp Philly Keynote Speaker – Aaron Jorbin | WordCamp Philly 2015

On Saturday, I got a phone call asking if I would be interested in presenting the Keynote address at WordCamp Philly.  I didn’t have to think very long.  WordCamp Philly has long been one of my favorite WordCamps.  It’s a great community and they put on a solid event year after year. On a personal note, It’s also the place I met the woman I love.

If you are near Philadelphia, get your ticket today.

 

Categories
Uncategorized WordPress

WordPress › Let WordPress Speak: New in WordPress 4.2 « Make WordPress Accessible

Photo By via http://public-domain.pictures/

WordPress 4.2 is shipping with a useful new JavaScript method: wp.a11y.speak(). This is a utility to make it easy for WordPress core to create consistent methods for providing live updates for JavaScript events to users of screen readers – with the side benefit that developers of plug-ins and themes can also make use of it either on the front or back end.

Source: WordPress › Let WordPress Speak: New in WordPress 4.2 « Make WordPress Accessible

One of my favorite changes coming in WordPress 4.2 is a new accessibility API to help with communicating changes on the page to Screen Readers. Core is using it in a number of places (including shiny updates) to improve the experience for users of screen readers. I’m excited to see plugins start taking advantage of it as well. The first step in accessibility is making something usable. The second is making sure the experience is top notch. This helps support step two.

Categories
Code Uncategorized WordPress

WordPress in a next generation PHP world

HHVM has now released it’s second long term support release and PHP 7 is in the final stages of implementing changes. It’s an exciting time for PHP and to be a PHP developer which means it is also an exciting time to be a WordPress developer since it creates an opportunity for WordPress to once again embrace forwards compatibility.

While I was at PHPUK, one of the most common conversations I had was people being critical of WordPress for supporting PHP 5.2 as a minimum.  Many of those same people became less critical once they find out WordPress runs great on PHP 5.6 and that many people run it on HHVM.

For the last several weeks, WordPress has been running it’s unit tests on PHP7 nightly builds. They’ve been running on HHVM for months. Right now, the unit tests are not passing for either one and as far as I know, have never passed for either one.  This is a problem.

I’m planning on spending some time during the 4.3 development cycle focused on these next generation platforms. Rasmus has put together a php7 vagrant box and JJJ created an addon to Varying Vagrant Vagrants to enable HHVM there. WP engine also has it’s own WordPress HHVM vagrant box. I intend to use all three of these to help.

Davey Shafik has put together a great two part series on the changes coming in PHP 7.  The two changes that are most likely to cause issues for WordPress sites are the removal of all deprecated features and the deprecation of PHP4 style constructors. This is going to affect many widgets along with all sorts of other code.

It’s exciting to see PHP moving forward.  The competition between HHVM and PHP runtimes is making PHP faster and is only going to push the language forward. It’s a great time to be writing PHP.

Categories
Uncategorized WordPress

Don’t on Emoji in WordPress 4.2

WordPress 4.2 is almost here.  Yesterday marked the release of Beta 4 and if everything goes as planned, the first RC will be available next week. One of the
“features” that people are talking about in both positive and negative terms in emoji support. I put feature in quotation marks because really, emoji support is a bug fix.

The mission of WordPress is to democratize publishing.  WordPress aims to be usable by anyone, anywhere.  Part of this means to be usable in any language.  To help accomplish this, WordPress 4.2 is changing it’s tables to use utf8mb4 by default. Gary Pendergast summed up why this change was needed

In Unicode terms, utf8 can only store characters in the Basic Multilingual Plane, while utf8mb4 can store any Unicode character. This greatly expands the language usability of WordPress, especially in countries that use Han character sets. Unicode isn’t without its problems, but it’s the best option available.

In addition to supporting more character sets, utf8mb4 also supports emoji.  The problem is that browsers don’t always support emoji correctly. In another post on the Make WordPress Core blog, Gary describes these problems:

  • Some browsers don’t know how to render emoji , or they have bugs in their implementation . Notably, Chrome either doesn’t work or has bugs, older versions of IE don’t work, and Firefox has bugs.
  • Not all sites will be able to upgrade to utf8mb4, which means they’ll be unable to save emoji characters that they enter.

Not being able to use emoji makes everyone a sad panda (), so we need to fix this.

Fixing WordPress to work in more languages exposes emoji. Since emoji support isn’t great yet, WordPress needs to shim it. Most users won’t understand why their site works in some browsers but not others. Some people find emoji annoying. Others find them fun. But as of WordPress 4.2, we all can at least find them.

 

Categories
Uncategorized WordPress

Modernizing the WordPress Toolbox at PHPUK

Speaking at PHPUK was an amazing experience.  I walked in only knowing one person, and walked out having had a hundred conversations and making some new friends along the way.

Speaking about WordPress at a PHP Event was a new experience for me. I’m used to feeling like many people know who I am at WordPress events, so going somewhere as an unknown was a different experience for me. I’m not used to sitting at a speaker’s dinner spending a large amount of time defending WordPress. I’m not used to so much WordPress hate (I guess I don’t spend enough time on reddit r/php), but I felt that the people walked away with a better understanding of why WordPress does what it does.  WordPress is flawed software.  If it wasn’t flawed, it wouldn’t be so much fun to work on.

Outside of the conversations I had, the keynote by Jenny Wong on Integrating Communities really stood out to me. It is something that the technology world needs to do and I’m glad Jenny tackled this important topic in a truly inspiring way.

And in case you are wondering, that is a WordPress bowtie I am wearing. Props Andrea.

 

Categories
Uncategorized WordPress

Auto Activating WordPress Plugins is the right choice

During the WordPress 4.2 cycle, one of the goals was to do some work aimed at improving the experience of users when updating and installing plugins.  While the decision was ultimately made to scale back to just updating for this release, the code that installed plugins also automatically activated plugins when a user installs them.  This generated a lot of controversy, but is ultimately what we should be doing for users.

The End User

Most end users of WordPress doesn’t have a staging site, doesn’t keep there site in version control, and doesn’t install plugins to activate them later on. When they install a plugin, they start using it right away. When they install a plugin, they want to either play with it to see if it works for them, or they set it up and start using it.

One of WordPress’s biggest strengths are it’s philosophies. One of them is that WordPress designs for the majority:

Many end users of WordPress are non-technically minded. They don’t know what AJAX is, nor do they care about which version of PHP they are using. The average WordPress user simply wants to be able to write without problems or interruption. These are the users that we design the software for as they are ultimately the ones who are going to spend the most time using it for what it was built for.

By following this philosophy, it is really easy for see that auto activation is the right path.

How about an option?

Some of the comments about this is that it should be a checkbox.  People think that the solution to a complicated and controversial decision is to add an option.  The WordPress philosophies once again guide us to say that an option shouldn’t be our default answer. We need to make smart decisions instead.

When making decisions these are the users we consider first. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration. As developers we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in. It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.

Yes, there are right times to add options. Andy Adams points this out when he wrote:

Instead of making a theme either fully-customizable or configuration-free, I’ve realized that the ultimate goal is to add “just the right options” to make the user experience more pleasant

There are absolutely use cases for not auto activating.  Some developers like to use the UI to do installs locally and then check out the code before deciding to install a plugin.  There are also plugins such as ones that enable a maintenance mode or help with debugging that you want easily available, but not necessarily activated.  These are the exception though, not the rule.

Why Installs are not a part of 4.2

This leads us to now.  Despite auto activating being the right decision, the decision was made to remove auto installs in large part do to auto activation.  This is a decision I ultimately advocated for taking.  The problem wasn’t the activation, it was the experience of what happens after activating.  The UX needs to be cleaned up there.  We need to make it possible for some plugins to opt-out and we need to make it easier for users to take action right after installing a plugin.

Shiny installs will be back, and when they come back I fully intend to advocate for auto activation. This may change with more information, but right now it is the right choice.

Categories
About Aaron Uncategorized WordPress

Five Years of Contributing to WordPress Core

Five years ago today, my first patch was accepted to WordPress core. Oh how the time has flown.

This last year has been one of my most exciting years as a part of the WordPress contributor community. At the end of September, I was given commit access to WordPress Core. I was excited to join a group that includes some of the smartest people I know, while also being terrified at the responsibility being handed to me. It’s been fun so far.

One of the coolest things in WordPress core that I worked on this year is the “Log Out of Other Sessions” button on the bottom of users profile screens. This seems like a simple button, but adding this iteration (which was a part of the 4.1 release) was the result of live user testing I organized as a part WordCamp San Francisco 2014.

In celebration, I made two commits to core today. One of them was to start user testing WordPress with PHP 7. I’m excited to see how we perform vs. the nightly builds there. The other introduced a new version of grunt-patch-wordpress which is one of my favorite parts of WordPress that I’ve been able to spearhead.

I’m lucky to share my committiversary with my partner who got her first props one year ago. I’m even more lucky that WordPress helped me meet her.

Five years of contributing is a long time. I’m especially happy that five years in, I’m more excited than ever to help build the software that powers so much of the web. Here is to another five years!

Categories
Current Events Uncategorized WordPress

User Testing WordPress at WordCamp San Francisco

 

WordPress 4.1 release lead John Blackbourn conducting a user test

Three days before WordCamp San Francisco, during the weekly WordPress Dev Chat, I came up with and proposed the idea that we should use the conference as an opportunity to do user testing. It was a last minute idea, but it’s one that I found valuable and that I would encourage others to do as well. In fact, I think it’s something more WordCamps should try.

The Preparation

Before the event, I setup a test site with the current version of WordPress Trunk along with the feature plugins that we wanted to test. For WCSF, this was Focus, WP Session Manager, and Improved Author Dropdown. I set these up on a public url so that users could do the test on there own machines. I think it is incredibly valuable to test people in as close to there natural environment as possible. While sitting at a conference isn’t where most people blog, if they normally use linux and you only have windows, using there windows laptop with there browser settings will help you understand there problems.

Recruiting Participants

We didn’t do a great job of recruiting participants in large part since we put this together at the last minute. I tweeted about the user tests, put up a sign and John Blackburn asked the volunteers at the happiness bar to send people over. Due to us doing this primarily during sessions, we ended up with people who self selected out of the sessions.

The Tasks

Another key preparation point is deciding what you will be testing. I like to have a simple script of what I say to each participant. I started by asking participants there names, and if I didn’t know them, a tiny bit about them. I also got there email address so that I could create an account for them. This helped to frame the test and also put there experience in context. Once they were logged in to WordPress, I asked each participant to create a new post. As the big feature I was looking for the reaction to Focus. I wanted to see how they reacted to the change when you enter into the editor. I wrote down the first reaction that users had. I then had them change the author. This part of the test was two fold. I wanted to see how they transitioned out of focus, while also seeing if found the Author drop down more usable. Most users used the select2 based drop down in the same way that they use the normal drop down.

After that, we asked users “If you wanted to get an idea of all the places you were logged into WordPress, where would you look?”.   This was to test the new session manager UI.

The Outcome

Now that 4.1 has been released, we can look at the results and see how they guided us.  One thing that we learned was that we needed to focus on discoverability of the new distraction-free writing.  This helped lead to us adding a feature pointer.   Users not immediately seeing a benefit in the list of user sessions helped us recognize that we might want to scale the feature back.  In the end, we decided a simple log out of all other sessions button would be the best option.

 

Categories
Current Events Uncategorized WordPress

WordPress Hanukkah Releases

Colorful dreidels2” by Adiel loOwn work. Licensed under CC BY-SA 3.0 via Wikimedia Commons.

WordPress 4.1 is the fourth major version of WordPress and the sixth overall version of WordPress released during the festival of Hanukkah.  The first release during latke time was WordPress 1.2.2 which came out on December 15, 2004. It was a patch release and the notes highlight it as:

This release fixes a few bugs and security issues and is recommended for all 1.2 users.

The following year, the first major release during Hanukkah took place when WordPress 2.0 “Duke Ellington” was released.  This release featured WYSIWYG editing, and many other great features.  My favorite part of the release notes is this gem:

Faster Administration — Call it AJAX, call it DHTML, call it Larry, but we’ve paid close attention to streamlining some of the most common tasks in managing your blog

It would be four years before the next WordPress release during Hanukkah when WordPress 2.9 “Carmen McRae” was released on December 19, 2009.  Carmen featured trashing posts, a built in image editor and a feature that has continued to be updated (including in 4.1)

Easier video embeds that allow you to just paste a URL on its own line and have it magically turn it into the proper embed code, with Oembed support for YouTube, Daily Motion, Blip.tv, Flickr, Hulu, Viddler, Qik, Revision3, Scribd, Google Video, Photobucket, PollDaddy, and WordPress.tv (and more in the next release).

The following year, WordPress 3.0.3 was released on December 8, 2010. This release was a security release that fixed some XMLRPC security bugs.

After taking 2011 off, WordPress 3.5 “Elvin” was released on December 11, 2012. It featured a long desired update to media.  It also brought in a new default theme (just in time)

3.5 includes a new default theme, Twenty Twelve, which has a very clean mobile-first responsive design and works fantastic as a base for a CMS site.

Last Hanukkah was an early one (and featured a rare Thanksgivukkah ).  While there was no major release, RC1 of WordPress 3.8 came out on December 4, 2013.

A few more releases and we’ll be able to create a WordPress menorah.

Categories
About Aaron Uncategorized WordPress

PHP UK – Here I come!

In just about two months, I’ll be making my international speaking debut when I present “Modernizing the WordPress Toolbox” at the 10th Annual PHP UK conference in London.

I’ll be talking about how updated we have updated the WordPress toolbox and build process from what would be considered antique at best.  I’ll also talk a bit about where it’s going to go and how our philosophies align with our tools.

This will be my first time speaking at a PHP specific conference and my first time speaking outside the USA.  I’m excited.