Author Archives: Boone Gorges

Circle back to those who refer work to you

· 1 Reply

I get a lot of requests to do BuddyPress and WordPress dev work, and I can only take a fraction of that work myself. So I end up referring a lot of work to other developers. Sometimes I hear back from the client that one of the referrals worked out (or didn’t). Unfortunately, it’s very rare that I hear from the developer himself about it.

It’s unfortunate not because I need the gratification (although it’s nice to hear “thanks for the referrals” sometimes). It’s unfortunate because I want to be a good referer. I read every job inquiry carefully, and I try to make good matches between inquiries and what I know about the developers on my list. I look at how big the job will be, what kind of work it is (plugin dev, theme work, troubleshooting, etc), what field the client comes from (education, journalism, retail, etc), and other stuff like that, and match it up with the devs I think would be best for (and would most enjoy) that particular referral. When I never hear back from these friends, I don’t have the data I need. Stuff like: If you refused the job, why? Too busy? Not the kind of work you generally like to do? Did the referral make your lousy-client-sense tingle? If you took the job, how did it go? Was the client good to work with? Should I continue to send work like this?

So please: if you know that one of your client inquiries came from a friend’s referral, ping that friend at some point down the road. The more info you share, the better the referrals you’ll get from me.

As a side note, I’ve been chatting privately with David Bisset about coming up with systematic solutions to the kinds of problems I’ve described here (among others). But in the meantime, an occasional email will do the trick 🙂

‘Tis the season to support good things on the web

· Leave a reply

Today I’m going to spend down some of my PayPal slush fund by making donations to online causes that are important to me. I do this every year, usually on a day in December (Christmas! Last chance for tax breaks! etc). Doing it in a single day makes it fun, like an event. Here’s a partial list of where I’ll be sending moolah today:

You don’t have to give to these specific causes (though you should – they are awesome!), but you should get out there and support some of the causes that you believe in. Even a couple bucks can be meaningful. ‘Tis the season!

Anthologize Dev: Update 1

· Leave a reply

The Anthologize fun has begun!

A few months ago, I held a successful Kickstarter campaign to support some development on Anthologize. In the past week or so, I’ve started work in earnest. This first round of development has consisted of a number of unglamorous but important cleanup tasks. A rundown of what’s been done so far:

  • Improvements to the way that TCPDF stores its cache files, to avoid permissions errors that can mess up PDF export
  • Improvements to the way tags and categories appear in HTML export mode
  • Improved compliance with WordPress coding standards
  • Rewritten plugin initialization, for better stability across various setups and decreased memory footprint
  • Localization improvements
  • Better compatibility with PHP 5.4+

This round of development was brought to you by Siobhan McKeown, an early and enthusiastic supporter of my Anthologize campaign. Siobhan is the proprietress of Words for WP, a delightful consultancy focused on writing documentation, publicity, UX, and other copy for WordPress-based businesses. She’s the best at what she does, and rumor has it that she also has a very famous musician for a cousin. Thanks, Siobhan!

Commons In A Box, ready to unbox

· 3 Replies

It’s been a long time coming, but it’s here: Commons In A Box. Today we’re releasing version 1.0-beta1, the first public release. For some background on Commons In A Box, here’s today’s press release, my Commons Dev Blog post explaining some of the features of Commons In A Box, and the 2011 press release announcing the project.

The primary goal of Commons In A Box, in my view, is to reduce the barrier of entry to setting up BuddyPress community sites. BuddyPress is an extremely powerful and flexible platform for developing social WordPress sites, but getting a BP site right takes knowledge (which plugins are worth installing, which ones work best together, etc) and elbow-grease (customizing your theme, keeping a complex system up to date). These practical requirements have made BuddyPress seem imposing to many users – including, and perhaps especially, the users that need free community software the most, such as educational institutions. Commons In A Box lowers these barriers in a serious way, by helping with plugin selection and installation, and by providing a beautiful and flexible default theme. My hope is that Commons In A Box will serve as a gateway for a swath of potential users into the world of BuddyPress, WordPress, and free software more generally.

The process of pitching, planning, and producing Commons In A Box has been interesting, frustrating, and rewarding. In the upcoming weeks and months, I may write more about this process, and what I’ll personally take away from it. In the meantime, I’ll say that I’m very pleased to be ending this first stage of development, and pushing it into the wild, since software – even imperfect software – is infinitely more valuable when it’s out there, being used, than when it’s mouldering on a developer’s machine. Shipping FTW!

Learn more about Commons In A Box.

Introducing Participad: Realtime collaboration for WordPress

· 15 Replies

Today I’m releasing the first public beta of a new WordPress plugin: Participad. Participad integrates an Etherpad Lite install into your WordPress installation, enabling realtime collaboration on the WordPress Dashboard or the front end of your WP site. If you’d like to download Participad, learn more about its features, or play with a demo site, check out participad.org. In the rest of this post, I’ll give some of the technical background about Participad, and some explanation of why it was built.

Participad was developed as part of some work I’m doing for thatcamp.org. If you’ve even been to a THATCamp unconference, you know that the first thing that generally happens in a session is that someone starts a Google Doc for collaborative notes, and tweets the link to the #thatcamp Twitter stream. In one sense, this is great – it’s very much in the spirit of THATCamp to have shared, crowdsourced, online notes for each session. But Google Docs, for all its coolness, is not the ideal tool for the job. For one thing, Google Docs are tied to a user’s account, making it very difficult to assemble a persistent, searchable archive of all THATCamp notes. There’s also the concern of storing user-generated THATCamp content on Google, which is alternatively benificent and malevolent, depending on the swings of the market.

Etherpad provides an ideal solution to the Google Docs conundrum. It’s a free software project that can be locally hosted, giving organizations and admins full control over the software and the data within. Etherpad has recently been rewritten as Etherpad Lite, an implementation in Node.js that is far more lightweight and easy to install than the original Etherpad, and, notably, has a rich REST API for integration with external software. This is what makes Participad possible: Participad uses iframes to display the Etherpad interface inside of WordPress, and then uses the EPL API to sync content between Etherpad Lite pads and the associated WordPress posts.

Participad is shipping today with three “modules”, each of which is a separate implementation of Etherpad Lite in your WP installation:

  • Notepads are the solution to the THATCamp/Google Docs problem described above. Notepads are a WordPress custom post type that can be created and edited from the front end of the blog by any logged-in user. Participad comes with a widget and a shortcode for displaying the Create A Notepad interface. And Participad redirects the Edit link seen on the front end of WP blog posts, so that it leads to a front-end editing interface. Content is synced back to the WP database every two minutes, or whenever a user clicks away from the Edit interface. In the spirit of THATCamp, Notepads can be “linked” to WordPress posts and pages, and a Participad widget can be placed in a sidebar that will display a list of a post’s Notepads. And because Notepads are just a species of WordPress posts, you can access lists of Notepads via an archive page.
  • Frontend is the Participad module that allows you to enable front-end, Etherpad editing for *any* WordPress content type. Turn it on, and the Edit link for any post will lead to an Etherpad interface, embedded in your theme where your static content would normally appear. Participad has a permissions schema that works with your WordPress installation, ensuring that only the users with the proper rights to edit a given piece of content through WP are able to edit that content through Participad as well.
  • Dashboard enables Etherpad editing throughout the Dashboard of your WP installation. All Edit screens – posts, pages, and other posts types – will have their WP editors (the Visual and HTML tabs) swapped out with a Participad tab. Autosave works just like it does in WP, and content is synced back to the WordPress database when you click Publish or Update.

I have a feeling that these three modules will cover most of the potential uses of Etherpad in WP, but if you have an unusual need, Participad is designed to be extensible. Build your own module by extending the Participad_Module class, in your own WordPress plugin.

Full instructions on setting up Participad can be found at http://participad.org/faqs/. Please note that Participad requires a separate Etherpad Lite installation, and for the moment, that installation must be accesible on the same domain as your WP install.

If you’d like to follow development, contribute fixes or improvements, or suggest future features, please visit Participad’s development home at github.com/boonebgorges/participad.

A few highlights from BuddyPress Vancouver 2012

· 7 Replies

BuddyCamp Vancouver 2012

The first-ever BuddyCamp was held last weekend in Vancouver, in conjuction with WordCamp Vancouver. It was a fantastic event in so many ways. Here are a couple of personal highlights for me:

  • First and foremost, it’s always a thrill to spend face time with people I work with remotely. My Wisconsinite-in-arms John and I have worked closely for years on BuddyPress, and we see each other a few times a year at WP events. I’ve worked with Ray and Bowe for nearly as long, both on free software projects and client work, and this weekend was my first time meeting either in person. The list of other current-and-future-BP-community-members I met IRL for the first time this weekend is too long to spell out here. But there’s no question that these connections were the best part of the event.
  • Had a great time on Hack Day, where I believe I gave props to eight different people in commit messages – several of whom were first-time contributors. Of special note was #4600, which took me and Stéphane Boisvert a good 90 minutes to sort out. That’s the kind of over-each-other’s-shoulders, team bugfixing that I wish I got to do more of.
  • It was a pleasure to have Matt in attendance. Somehow, we’d never managed to meet each other before this weekend. He was generous with his thoughts on the state of BuddyPress and directions for further development, and he was gracious about those points where he and I disgreed (aside from the “intellectually lazy” line ;). Gave me lots to think about.
  • I hesitate to call BuddyPress’s founding developer a “prodigal son”, but it was certainly a kick to commit Andy’s first contribution to the project in several years!

The fact that this kind of event took place in the first place – much less that it was so successful – is, I think, hugely important to BuddyPress. It demonstrates that there’s a vibrant community around the software and its uses, the kind of cohesion that makes meetups like BuddyCamp worth traveling for. So I’d like to extend my sincere thanks to the organizing team of BuddyCamp Vancouver, whose hard work enabled a really incredible weekend for a lot of folks (or at least for me!): Cyri Jones, Joey Kudish, Jill Binder, Roland Frazer, all the BCIT and Capilano University students who helped out, and to the sponsors who made it possible. Thank you all so much!

Now, who’s gonna organize the next BuddyCamp? 🙂

Antholocheers

· 7 Replies
Totals

Antholocheers

I’m happy (and, frankly, a little surprised) to announce that my campaign to fund a round of Anthologize development, which ended last night, successfully met its funding goal of $2,500. Donations came from friends and strangers; individuals and organizations; and from the WordPress, ed tech, digital humanities, and other miscellaneous communities of awesomeness. Close to $1,000 (or more, depending on how you count – more on this in a moment) came in within the last 24 hours.

First off: Whoo! And thanks!

Second, here’s an exact breakdown of the funds:

  • The final tally from the Indiegogo campaign was $2,665.
  • I got an email late yesterday from the team in charge of the OpenLab project at CUNY City Tech. They pledged an extremely generous $1,000 for the Anthologize campaign. For bureaucratic reasons, their donation couldn’t come through Indiegogo, so we’ll be working out a different way to deliver the funds.
  • The Roy Rosenzweig Center for History and New Media agreed (amazingly) to match, dollar for dollar, all donations to the campaign. Their contribution comes to $3,665.

This gives us a grand total of $7,330, which translates to about 98 hours of development time. It’s worth saying again: Whoo! And thanks!

Next steps: In the upcoming week or so, I’ll be reaching out to donors to collect any information necessary for their awards: mailing addresses, links to their websites, etc. Over the course of the next few weeks, I’ll be talking to other members of the Anthologize dev team about a roadmap for using these dev resources. And I’ll be starting to work down those 98 hours around the middle of November, when my work schedule eases up a bit. That’s also when I’ll start blogging in earnest about progress on the plugin, as well as some more general thoughts about crowdfunding for this sort of project, about the viability of free software projects not owned by any specific institution, about the role of Anthologize in publishing, and other such philosophical delights. These posts will “sponsored by” the contributors who pitched in $75 or more, which means that I need to write at least 15 of them 🙂

I’m looking forward to the next stage of Anthologize. I hope you are too – you made it happen.

For your keyboard health

· 3 Replies

It only took a few months of working full-time with computers for wrist fatigue to kick in. After a stretch of 10-12 hour days at the keyboard (at the time, it was the chiclet keyboard of a Macbook), my wrists would feel tight, and my fingers weak. I’d just quit my job working for the state to be a freelancer, and I began to panic that my body wouldn’t hold out!

So I made a couple of drastic adjustments to the way I work. The one that’s had the most general benefit has been my standing desk, which allows me to keep my eyes straight forward, and my forearms parallel to the ground. Aside from this, there are two other big changes I’ve made to my setup. These are directly related to the keyboard itself.

  1. Dvorak – August Dvorak, inventor of the Dvorak keyboard layout, famously quipped that a text that would require 12-20 miles of finger travel on a QWERTY keyboard would take just one mile on Dvorak. This is probably an exaggeration.. Still, it’s hard to deny that Dvorak has a lot of intuitive appeal: vowels appear in the home row of the left hand, the most common consonants in the home row of the left hand, and typing English words generally requires fewer row jumps and other ugliness.

    Switching to Dvorak was hard – far harder, in my experience, than switching to a standing desk, or to Linux, or even to Vim. For a few weeks, I spent an hour or two per day doing drills in Master Key. Then I switched to using Dvorak in the morning, until my brain would hurt so bad that I’d switch to QWERTY by around 10am. When I could finally make it until noon using Dvorak, I quit QWERTY altogether, as code switching between the layouts was proving more difficult than Dvorak itself.

    During the transition, I was a slow typist (30-40 WPM for prose around the time of the final switch, down from 90-100 on QWERTY). This affected my work efficiency. Worse still, the stress of hesitating the slightest bit before each key press was actually making my wrist fatigue worse than it was with QWERTY. But I persisted. After about six weeks using Dvorak full-time, I was up to maybe 60-70 WPM. (I’m since up to at least my pre-Dvorak speeds.) And, most importantly, I finally started to reap the ergonomic benefits of Dvorak. I’m able to type with far less wrist movement than before, with the result that I have much, much more stamina – those 10-12 hour days tire my brain way before they tire my fingers. Totally worth it.

    (Side note: A lot of people – people who are not touch-typists to begin with, I guess – put stickers on their keyboards to show the Dvorak layout, or even pop the keys off and rearrange them. I never did this. It forced me to learn the layout much more thoroughly. Plus, it is an order of magnitude more bad ass to type Dvorak on a QWERTY keyboard.)

  2. Kinesis Freestyle keyboard – I’d been typing for a long time on chiclet-style keyboards: first the Macbook, then the Macbook Pro, then an Apple USB keyboard. These keyboards are beautiful and quiet. But they don’t give much feedback. And touch-typing on them requires you to crook your wrists outward, in order to get your fingers resting on the home row. On the recommendation of my main man Marshall Sorenson, I bought myself a Kinesis Freestyle. It’s got nice, clicky keys. And it takes the idea of ergonomic keyboards to an extreme: the two halves of the keyboard are actually separate pieces, separated by an 8″ cable (a 20″ version is also available). Now I can keep the two halves positioned in such a way that I don’t have to bring my wrists too close together, and I don’t have to bend them at a funky angle to touch type.

    Kinesis Freestyle 2

    Kinesis Freestyle 2

    I love this keyboard so much that, now that I’ve switched away from the Mac, I’ve bought myself a new, non-Mac version of the Freestyle. (I just got it in the mail yesterday, prompting me to write this post.)

It takes a bit of work – and some risk – to make radical changes for the sake of ergonomics. But it’s an investment in the future. And don’t we all want to Win The Future?

Bonus! Buy my old keyboard

Needs a good home

Needs a good home

[EDIT 2012-10-03 – The keyboard has found a good home. Take good care of her, Will!]

I won’t be needing my much-loved Freestyle for Mac anymore. Wanna buy it? It’s in perfect working order, and I’ll clean it up real nice before sending it out to you. These puppies are $100 new (and, actually, it looks like they’re discontinued at the moment, until the Freestyle 2 for Mac comes out). I’ll be happy to let it go to a faithful reader of this blog for $50, continental US shipping included. (If you’re outside the contintental US, contact me first to ask about shipping.) If I don’t get any bites, I’ll put it on eBay, but I’d rather see it go to a friend. Leave a comment or drop me an email: boone /at/ gorg dot es.

Anthologize campaign update, and a sneak peek

· Leave a reply

My Anthologize development fundraiser is going great so far – as of this writing, $870 has been pledged. Put that together with the generous match from CHNM, and you’ve got $1,740. This translates to over 23 hours of dev time. A huge thanks to those who have already made pledges – you’ll be hearing from me individually once the campaign is over on October 10.

Aside from some miscellaneous cleanup and compatibility issues, my first goal during the development period will be to get the plugin running better in more server environments. Our most reported bug is that Anthologize Exports time out due to memory limits. This is an especially vexing problem on inexpensive, shared hosting, which is what much of the Anthologize target audience uses for hosting their WordPress sites. I’ve started to sketch out a plan in this Github ticket for making Anthologize exports less memory-hungry.

It’s always hard to estimate these things, but I’m guessing that 23 hours will be enough to do the initial plugin cleanup, and to get most of the way toward the rewrite of the export process described above. That’s progress!

Remember, more pledges mean more development. If you want to see more fixes and enhancements to Anthologize, you’ve got until October 10 to donate.