If you enjoyed Matt’s post about the original Super Mario Bros. check out this video about Super Metroid’s hidden tutorials. I had posted this years ago internally while working at Automattic in a thread about new-user experience, specifically in regards to how WordPress (both .org and .com) can learn a lot from video-game design.

I think this still holds true, both for new users and for how new features are rolled-out and introduced to users that have already achieved mastery with the platforms. Even if you don’t like or never played the Metroid series, this video may inspire you to do so.

Stuttter, like WordPress on the surface, is both product and organization.

Spiritually it is a conduit for rethinking WordPress from the outside in. It’s a way to independently test the waters for what we can do with it, without deviating from it’s history, beauty, charm, and chutzpah.

For me, it’s an empty canvas for code, and a place to create without prohibition. For everyone else, hopefully it’s a bunch of little widgets and do-dads that are valuable enough to maybe consider sponsoring or paying for.

The name comes from what happens when I’m nervous, which doesn’t happen very frequently. I struggle to find the sequence of words that I think will most quickly bring calm, so I stumble and stammer for a bit until I find my stride. (Someone I adore, who does this quite endearingly, is Elon Musk.)

There is a brief period of excitement while ideas are unraveling, and that’s what Stuttter represents.

Like how auto-makers take off-the-shelf components and wrap them to design next-generation vehicles; how architects take pre-existing materials and specifications and add their flair and signature; how Apple, Adobe, and Automattic leverage open-source libraries to create beautiful software experiences; Stuttter is how I identify uniquely powerful aspects of open-source GPL friendly software, and extract them into neatly packaged design implementations for WordPress.

Right now, you can follow Stuttter on GitHub, Flox, WordPress.org, and Packagist, until we get some websites up. Here are the first pass logo and icon, if you’re interested in using them:stuttter

stuttter-circle

The WP Chosen plugin tames the power of WordPress’s filters, settings, and options with the simplicity and versatility of the Chosen jQuery library.

I took some time to think about the recent passing of an old friend, and concluded the way to celebrate his life (and contributions to mine) was to build and open-source something I’ve wanted for a while, the way I think he would have.

❤️

Yesterday, I tweeted about the recent Volkswagen debacle:

It got me thinking about the WordPress community, who the major players are, and where I might fit into it all on any given day.

I’ll start with Automattic and work my way across from there. Full disclosure, if you didn’t know, I worked at Automattic for a few years, so some of my observations are based on internal influences from a company half the size with a different CEO, and 4 of Matt Mullenweg’s hairstyles ago.

Automattic, is a powerhouse. They have enormous momentum that’s intimidating to compete with even when you’re trying to carve your own niche. Interested in e-commerce? Woo. Hosting? WordPress.com. The cloud? Jetpack. Backups? VaultPress. Together they’ve solved a number of small problems in huge ways, and are uniquely qualified to do so with Matt at the helm and millions in the bank.

If you’ve read The Year Without Pants then you got a decent (if bland) idea of how the sausage is made, but my not being a part of Scott’s retelling is a metaphor for my experience at Automattic. I didn’t really bond with the team like I’d hoped, and it was the second time I had attempted to replace Andy Peatling (the first being leading the BuddyPress project) and by this time I had already felt like my reputation was in a downward trajectory.

Ironically, my experience at 10up was pretty similar. A position opened up and I was asked to follow the enormous footsteps of two beloved engineers. I failed to gel with a company made entirely of friends from the WordPress community, I never found my stride, and I still had wandering thoughts of BuddyPress & bbPress on my mind. 10up is an agency’s agency. They move fast, work hard, and aren’t afraid to kindly cut the anchor and sail on if something is dragging behind. Needless to say, I couldn’t hang.

The folks at WebDevStudios are doing awesome stuff with BuddyPress, but inside the WordPress community I’ve heard people say some surprisingly negative things about them. Code quality being bad, they’re unprofessional, etc… I don’t see it, I haven’t seen it yet, but if it’s true, these criticisms aren’t unique to WDS. I’ve seen worse code and experienced less professionalism from other hugely successful businesses. If those are WDS’s only problems, they are the company to bet on. They’ve doubled in size since last year, and aren’t showing any signs of slowing down.

My friends at HumanMade have a reputation for contributing huge amounts of time & effort to pushing WordPress as a platform farther than even the folks at Automattic have been able to pull off. I think this is accurate; they’re a talented bunch of engineers that love WordPress but aren’t consumed by it, which pays off by allowing them to influence it’s direction gently and with outside perspectives.

CrowdFavorite is, well, a favorite of mine. They’re an agency that’s known for going after and catching the whales, and being coy (in a good way) with the stories of how they caught them. From my perspective, they’re the agency that goes their own way and likes to challenge the WordPress status-quo, which is to say I like them a lot.

Pippin Williamson and his team have a reputation for their enormous momentum and huge earning potential if they maintain their current pace. Output, output, and more output. It’s intimidating, and inspirational, and having known Pippin a long time, I’m both happy for him and proud of what he’s accomplishing.

There are a bunch of other businesses, agencies, and independent WordPress developers out there, so it’s difficult to cite examples without injecting my own biases or forgetting some really influential people. Envato, Alley, Voce, Range, Reaktiv, WPEngine, Pagely, XWP, and on and on…

And me? Some days I feel like my ideas are far-fetched & silly, or the entire WordPress core team is against me, or they feel like I’m working against them even though I’m trying to work a few steps ahead without being a distraction. The rest of my days are spent working on my own little corner of the internet trying to mop up what’s left of the mess of my own career, since I’m back where I started 5 years ago with some added experience & perspective, and maybe a chip on either of my shoulders about it all if I’m being totally honest.

It reminds me a bit of an article about Jonathan Blow in The Atlantic in 2012, who earned a funny reputation in the video game industry, and once he had the zeroes in his bank account to prove his voice had value, his voice suddenly did have value. The same voice, but being backed by currency gave it breadth and range.

In many ways, his opinions of his industry are not dissimilar to mine with WordPress (though when given the opportunity I try maybe to be a bit less brash to the people pouring their hearts into their passions with their own foibles and comeuppances.)

There are a lot of similarities between the independent game scene and what’s going on with WordPress right now. There are huge, major players taking on and solving massive problems at a scale that no 1 individual can compete with anymore, but that also means there’s opportunity for someone to identify one specific sharp snaggy corner and file it away so no one hurts themselves on it again. I hope Flox achieves that with it’s offerings; I hope we manage to produce something widely popular so I can afford to relax for a while; I hope to earn a better reputation than I feel like I have with my colleagues and friends through cool & valuable output.

Reputations are usually accurate, and surprisingly fickle. One person or company can devote their entire focus to something and lose it instantly, while another can have questionable ethics and still manage relative success. My point, I guess, is that reputations are earned one way or the other.

It’s scary, and rewarding, but it’s easy to get caught up in the distraction, politics, and bureaucracy of it all, and accidentally live up to people’s perceptions of who they think you are instead of who you know you are and what you’re capable of achieving.

Focus less on reputation, and more on ethical output, and you’ll be just fine.

With each new software release that I’m fortunate enough to contribute to, I usually take some time (or lots of time) to reflect on a few different things that I think are critical to the project and myself:

  • What went right?
  • What went wrong?
  • What did I learn?
  • What can I do better?

With BuddyPress 2.2 imminent, here’s a brain-dump of my random and unrelated thoughts for January 2015, in no particular order:

  • Significant improvements have been made to cache-coverage, but many more are necessary, and some of our existing implementations are not ideal.
  • User statuses are pretty messy. A user’s status is a numeric value in the users database table, and there is no API in WordPress for interacting with it. Just like post statuses, anyone concerned with workflow (or activation flow in this case) is pretty much on their own.
  • The Member Type API is sweet, and I’m excited to see how developers use it. Hopefully I get to use it myself soon.
  • It seems like each ticket takes longer to test, confirm, fix, patch, and push.
  • How strictly do we enforce cache coverage, unit-test overage, inline documentation coverage, and all of the other nuances? I fear we are over-complicating each others lives with anti-progress and slowly forgetting what made BuddyPress fun to work on in the first place.
  • I need to write more unit tests.
  • I need to increase cache coverage.
  • I need to write more inline documenta… Ehh… maybe I’m okay here.
  • I sure wish PHPUnit were faster and easier to run. Netbeans has decent integration, but I haven’t figured out how to efficiently implement it into my workflow.
  • It’s been really great not juggling immense client and customer expectations in January, thanks to the funders of my recent IndieGogo campaign.
  • The old BuddyPress Default and Legacy templates are starting to look really out-of-date to me now. I wish we didn’t have so many templates to style and that creating themes was easier.
  • I continue to struggle with the cost of switching contexts during the day, between writing code, impromptu meetings, and random pings. Working nights used to help with this, and I need to come up with a healthy plan to improve my ability to come back to things once I switch away from them. I feel like I used to be better at this when I was younger.
  • That squirrel outside my window is looking pretty well fed considering it’s January.
  • I bought too much Lego over Christmas.
  • I need to take more small breaks and be more physically active during the day.
  • I need to prioritize blogging.
  • I need a nap, and it’s only 11am.
  • BuddyPress 2.2 is going to be sweet.
  • Boone did a really good job juggling both WordPress and BuddyPress core development. Note: be more like Boone, at least in this capacity (I don’t think I can eat that much pizza anymore.)
  • I’m excited for a vacation my wife and I are planning in March to celebrate our wedding anniversary. It will probably be much needed by then.
  • I broke my ankle 1 year ago, and it’s still not quite right. Likely won’t ever be the same I suppose. Guess I’ll never play the piano again.
  • Penny (our new rescue puppy) tested positive for heart-worm. Poor thing. Hopefully it’s not too bad and we get her all fixed up.
  • You are great. <3

I’ll probably regret making this, but here we go…

osx-yosemite-sam

Yosemite Sam from: http://wallpapers-junction.com/Cartoons/Yosemite-Sam-Cartoon-Wallpapers.html

Yosemite from: http://en.wikipedia.org/wiki/Tunnel_View

Responsive design has become a quick-and-dirty way to say “Hey! We looked at this on not-just-a-PC!” Our users deserve so much better — something that intentionally works with the ever-increasing array of input methods. Keyboards, cursors, touch, voice, & motion; the digital world has never been simultaneously as accessible and as overtly complicated as it is today.

Netflix does a pretty good job at wrangling the chaos, designing experiences around the input method, reducing touches and navigational elements on more simple devices and taking advantage of all available screen real-estate to maximize an interfaces usefulness.

Maybe we’ll call it “Input Aware” or “Device Aware” design — I guess I don’t really care about the name as much as distinguishing the approach from the myriad of responsive hacks and shims floating aimlessly around our collective github toolboxes.

I was recently reminded of the spectrum of media-types available to the CSS2.1 media spec, which largely got me thinking about how bad we are at utilizing them:

  • all — Suitable for all devices.
  • braille — Intended for braille tactile feedback devices.
  • embossed — Intended for paged braille printers.
  • handheld — Intended for handheld devices (typically small screen, limited bandwidth).
  • print — Intended for paged material and for documents viewed on screen in print preview mode. Please consult the section on paged media for information about formatting issues that are specific to paged media.
  • projection — Intended for projected presentations, for example projectors. Please consult the section on paged media for information about formatting issues that are specific to paged media.
  • screen — Intended primarily for color computer screens.
  • speech — Intended for speech synthesizers. Note: CSS2 had a similar media type called ‘aural’ for this purpose. See the appendix on aural style sheets for details.
  • tty — Intended for media using a fixed-pitch character grid (such as teletypes, terminals, or portable devices with limited display capabilities). Authors should not use pixel units with the “tty” media type.
  • tv — Intended for television-type devices (low resolution, color, limited-scrollability screens, sound available).

CSS2.1 even comes with a handy media-groups spec to pair media-types to devices based on their anticipated attributes:

Media Types Media Groups
continuous/paged visual/audio/speech/tactile grid/bitmap interactive/static
braille continuous tactile grid both
embossed paged tactile grid static
handheld both visual, audio, speech both both
print paged visual bitmap static
projection paged visual bitmap interactive
screen continuous visual, audio bitmap both
speech continuous speech N/A both
tty continuous visual grid both
tv both visual, audio bitmap both

Typical responsive design approaches target the screen type (and maybe print) which is accidentally celebrating doing-responsive-design-wrong. To correctly respond to different devices, we need to target more than max-width and min-width in the screen media-type, and let browsers and rendering engines on our televisions and refrigerators do their jobs.

Unfortunately for me, the software libraries I live most of my life in right now (WordPress, BuddyPress, and bbPress) are all pretty bad at this. The WordPress iOS app is a crippled version of WordPress’s relatively fantastic interface; WordPress itself barely functions on small screens and touch devices; BuddyPress & bbPress do the bare minimum to inherit surrounding styling, but don’t own the experience or set a great example in this regard as much as they might in others.

The greater tech community needs to target more input devices, intentionally design better experiences, and stop patting ourselves on our backs for doing the bare minimum of design.

Sure… it’s an iterative process, and yes… we’re all working hard and putting in the long hours together to improve the digital world around us, but it’s a great time to lift up our heads, unsquint our eyes, and design for the world around us instead of for ourselves.

If you use Netbeans on Mavericks, and updated to Beta 6 (Build 13A558) you may have noticed your menu bar items fail to appear, looking something like this:

Netbeans no Menu

This comes from the default Java menu bar nib files being accidently removed from the build: /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/*.lproj/DefaultApp.nib

The workaround is to install the full Java SE 6 JDK from http://support.apple.com/kb/DL1572. This reinstalls the Java SDK in the correct locations, and will be deleted on the next Mavericks update (so there’s no harm in this temporary fix.)