Explaining Hard Things to Humans – My Small Part to Make WordPress More Welcoming

Fred Meyer from WPShout gave this really good talk on writing for technical knowledge at WordCamp US earlier this month. It really resonated with me. I work with a bunch of really smart people everyday who are savvy with technology. Some of the concepts Fred talks about seem like common sense, but are so often overlooked (even by myself from time-to-time).

In one particular example, Fred calls out the language in the WordPress installer itself. Currently, once the installation is successful you see a message:

WordPress has been installed. Were you expecting more steps? Sorry to disappoint.

This could be interpreted many different ways, but the potential to sound flippant or snarky during the initial steps of an interaction with your software is a bad idea. Not to mention, not all software installations go as smoothly as planned. The individual using your program could be at their wit’s end; frustrated.

I was inspired by Fred’s talk and took action. WordPress is open-source, right? So I did what all folks should do, I submitted a patch to change the wording.

WordPress has been installed. Thank you, and enjoy!’

SMWCon Spring 2015 in Review

In early May I helped to organize the Spring Semantic MediaWiki Conference or SMWCon. We had 25 people from around the world come together for three days to learn and share about Semantic MediaWiki and it’s use in various industries. It was an honor to host such an event here in my hometown of St. Louis. I wanted to take a few minutes to share my experiences as an amateur event organizer and reflect on one of my personal accomplishments for 2015.

—-

When planning an event my mind always goes to the worst possible scenarios. What if people don’t come? What if they can’t find the event location? What if the food is terrible? What if the presentations are off-target?

For the most part, if you worry about these things and do something to address them, you’ll be fine. Don’t be overly anxious. Writing things down and keeping “To-Do” lists really helped keep things organized. Remembering to follow-up with people (venue folks, caterers, etc.) will prevent miscommunication and last-minute dashes to fix things.

Another tip? Make sure you have coffee and snacks around. Nothing fancy is needed. We made a trip to Costco the day before the event and grabbed some mixed nuts, granola bars, chips and soda.

I’m glad to say that everyone appeared to have a good time and everything 1 generally went off without a hitch.

I was an attendee at the last Spring SMWCon. Since that was also my only SMWCon experience, I based a lot of my work off of the great organizers that hosted us in Montreal. One thing I didn’t go a good enough job on was encouraging diversity in the audience and in speakers. What we had wasn’t bad, but man I would have like to have more unique voices present.

That said, we did have one of the most diverse group of industries represented. eSport statisticians, geneticists, geophysicists, independent developers, Tibetan Buddhist philosophers, MITRE, NASA, NATO, SNPedia, and more represented the diverse use of Semantic MediaWiki. We actually remarked during one of our sessions that this SMWCon had a much more ‘enterprise’ vibe than past conferences. It’s remarkable how many wikis exist behind firewalls that the public never know about and what amazing things people are doing with the software.

This lead into an interesting discussion around future of SMW and SMWCons. The discussion is ongoing, but the consensus is that there should be more events around enterprise 2 MediaWiki usage.
All of the presentations were interesting and chatting with some of the attendees opened my eyes to new uses and interests I never knew existed.

Some of my favorite sessions are listed below. We recorded the presentations and they should be up online soon.

smartMediaWiki

Wolfgang Fahl presented on an idea he has called smartMediaWiki. His tutorial was in-depth and allowed for all attendees to participate. While some of his concepts are beyond my meager understanding, the amount of effort he put into his presentation is commendable upon itself.

 

Cargo and the future of SMW

Yaron talked about his new extension, Cargo. It’s an alternative to SMW, which is interesting as it’s a much smaller code base, but nearly just as powerful. His approach to semantic data is different (standard database schema instead of triples) and the history of his involvement with SMW made for an interesting talk. Where Cargo (and SMW) go in the future is still very much unknown, but Yaron brings forth the idea that both can live in harmony.

 

The Why and How of Wiki Farms

Cindy’s presentation on the interworking of MITRE’s Gestalt framework was eye-opening. I manage two independent wikis and have never though much about the complexities of running dozens – or hundreds – of wikis. Her talk covered how one might manage multiple wikis without going insane – and still leaving plenty of room for customization and uniqueness.

 

SMW Grammars & Variables

John McClure is not a man to shy away from big challenges. His presentation tackled the promise of a semantic web – multiple independent sites interconnected among one another with a common ontology. His passion was present and his goals noble. The conundrum is who is willing to do the work? So many wiki folk – yes even those within the Wikimedia movement – are rather ‘heads down’ on what they’re working on. John’s vision is of a standard grammar we can all leverage to systematically interconnect the various repositories of information we all maintain.

 

Quantifying Accountability

James and Daren gave a great ad-lib presentation 3 on how they use MediaWiki to help document information around the training of astronauts for their EVAs. Their presentation was a great example (among many) of folks who are not ‘wiki people’ leveraging the software as part of their jobs. Both are engineers and training astronauts is their primary career. Even with that full-time gig they find time to develop their own extensions and adapt the SMW platform to fit their needs – all while releasing their code to the public.

 

How to get your bug fixed in MediaWiki

Mark gave a great overview on how to take a PITA bug and get it fixed. His introduction to the MediaWiki bug ecosystem was really helpful. I now feel more confident in submitting bug reports and improving the software.

 

We had a panel on the third day around the topic of “The Future of the Semantic Web, SMW and MediaWiki”. The three panel members 4 did a great job discussing the changes yet to come that will impact us all.

I love the SMW and larger MediaWiki community. There are a lot of good people involved. Each working hard in their respective industries trying to not only accomplish the work before them, but giving back to the community as well. If you have an inkling of interest in attending (or organizing!) a SMWCon I can’t recommend it highly enough.

The best advice is that which you do not expect

I was invited by my friend and all around good guy Dan Shown to talk at his Digital Media and Society class at my alma mater, SLU. I was there to share with his students what a career with a Communication 5 degree could look like. I had the great misfortune of presenting after Jon Michael Ryan who runs around shooting amazing videos.

That’s right, the cubicle dude follows up a guy with slow motion videos. It was amazing that the students even stayed in the room when it was my turn to talk.

But talk I did! I don’t pretend to be a guru, ninja, expert, or any other ego-boosting superlatives, but I have learned a few things and was happy to share. The most important thing I wanted to hit on was that the ‘tips and tricks’ to succeed as an adult have very little to do with tools, software, programming languages, or social media platforms. It has to do with being a well-rounded person who is, at the very least, content with life.

What follows is a pretty version of my talk. Who knows, something I said might be correct and even useful. 🙂

The first thing I mentioned wasn’t about what tools to learn. I reminded students  to not work more than 40 house thinking that’s the path to happiness and success. Working 60 hours thinking your boss will recognize you for that extra effort and that it’s the only way to stand out or get ahead? Won’t happen. It’s not worth the damage it will have on your relationships. Friends, family, partners, are all more important.

You can get an amazing amount of work done in 40 hours – if you’re actually working! Just because the office culture is a particular mindset, doesn’t mean you have to follow along. Keep that strong work ethic and get your stuff done.

Reflect before making decisions – even in situation where your boss is telling you to do something. A lot of people, when given a task want to complete it immediately and without question. When the boss says, “We need a blog” don’t turn around and say “OK HERE’S A BLOG”. Use your education, your experience, your research. Think about they why of the question. What are they trying to accomplish. How will a <blog> help along those lines? Who’s your audience. Ask questions, find out as much as you can, then execute.

Have empathy. Put yourself in the shoes of the people using your thing, your service, your product, your art.

Don’t dismiss critique. Embrace it. Silence does not mean acceptance. Feedback, even harsh, direct, ugly feedback, is better than apathy.

Be able to defend your decisions. If it’s sticking to APA style, picking colors using solid color theory, or explaining typography, make sure your design decisions 6 are based in all the stuff you’ve filled your head with. Not because “I like the color green”.

I closed my dribble talk with a truncated quote from Paul Graham.

Don’t ignore your dreams;
Don’t work too much;
Say what you think;
Cultivate friendships;
Be happy.

Community is as Important as Code

I’m a fan of the ATP 7. On a recent episode they talked about the amount of time one of the hosts, Marco Arment, spends on responding to email regarding his podcasting app Overcast. The gist 8 is that Marco doesn’t respond to much, if any, email regarding his app. I don’t think that’s the best thing for the community that’s developed around his code. I encourage developers creators of anything to rethink how they handle communication from their customers.

Marco is a successful one man shop. He’s the engineer behind the successful tumblr and Instapaper among other accomplishments. I like him and I think he’s one of the good ones 9. He obviously knows what he’s doing.

I understand where he’s coming from when it comes to feedback and engaging with folks, especially over things like bugs and feature requests. It takes time that  isn’t coding and that can sometimes feel like ‘not work’.

But nurturing the community around your product/service 10 is work and it’s incredibly important. Just as important as every line of code you type.

Ignorance is Bliss

People don’t know you’re a one-person shop. They don’t think about the expectation of support from one $5 app from a larger company 11 compared to that of a smaller company. They don’t know that the app was made by a team of 10 in an organization of 10,000.

They might do a little research, ask a friend what they recommend, and then hit the App Store to download something to solve their need or want.

Frankly they shouldn’t care. Some level of support is expected. I don’t view it as an entitlement, but perhaps more of an expectation of doing business. If you contact a business, of any size, I don’t think it’s crazy to expect a response.

Look at the use and success of tools like Yelp. Why does Yelp exist? What’s the most unusual and valuable part of that service? The reviews! Businesses (smart ones at least) care about what people are saying on Yelp. They respond with sincerity and engage with their customers.

Ignorance also goes the other way. How you respond is how you will be perceived. Not caring what customers think of your company and product is inviting ignorance into your work.

It’s also a humbling thing to receive feedback and questions. You do not know it all. No one does. Ignoring or mocking the idea of responding to email from people shows arrogance. I can’t believe I’m referencing a Reddit comment as part of my argument, but, in this thread asking “What is the most unflattering thing a person can do to themselves?” someone said:

“It’s nice to be important, but it’s more important to be nice”

While you could argue that responding to emails might not help your code – responding to people is being nice. That’s more important than one more bug fix or one little tweak to the UI. Letting people in, shedding some of their ignorance and empowering them with knowledge is helpful to you and the community at large.

Community Props You Up

People will help support you. There is an admonishingly large amount of prior work in this area. Look at the Apple community boards. A giant company creates a place for others to help each other. Panic, a much smaller company, has a nice Q&A site setup for their community. These are for-profit companies. Looking at the open-source communities you’ll see even more – like local Meetups around Ruby, Drupal, PHP, WordPress, Small-Business owners, photographers, marketers, etc. Wikipedia in its entirety is all about people helping each other to make something.

Word of mouth is still the #1 best way to grow a product or service. It’s incredibly powerful – more so than almost any other form of marketing. It’s genuine, it happens naturally, and it’s often more deserving than spending millions on a campaign. The people helping other people are doing it out of love for the things that you create.

Outside feedback is invaluable. Working in a small team or inside of a large organization it sometimes becomes difficult to get a genuine outsider view of your work. Developing a community around your products or services helps to break out of that echo chamber and get a fresh set of eyes on what’s going on. Invaluable help from interested folks. Ya can’t beat that.

Ignoring the 700th email of a particular issue, say a bug, is wrong.

These +1 numbers on an already existing issue are indicators. They should sway you. Influence your to-do list. Your response. A handful of responses in one direction could mean a lot. A “canary in the coal mine” on what your community wants, or more importantly, needs.

Trust is Scary

Putting faith into a community of people you don’t know is scary. Terrifying even. I help to host events for the local WordPress community here in St. Louis. Every month, at the end of one of our meetups, we ask what topics folks would like to hear about next month. We take an informal poll and pick a topic. Then we ask who would like to present. Numerous times it’s someone I’ve never met who has never spoken up.

I have yet to be disappointed with a presentation. I put faith that if someone is willing to step up and speak in front of a group of strangers, they’re doing it out of good will and are motivated by something other than financial or professional gain.

You Work For Each Other

They took their time. That’s what is valuable. Your customer’s time. Not the novelty. Not the accuracy. Their time. It doesn’t even register to them that their bug report or suggestion is the 500th in a long line of similar suggestions. Their time is equally important as your time. Thinking and acting otherwise shows hubris and arrogance. They are working for you by using their time to give feedback, ask a question, or file a complaint.

By not responding, by not putting it out there, you have nothing to point to say, “Yes, I hear you.” It enters a void of your inbox and only encourages more silent tosses into the abyss. Creating a community helps alleviate these emails. People who enjoy your creations will help you and other people who are looking for information.

It Pays Off

Terry Gross had this great interview with David Remnick the editor from The New Yorker.

At the end of the interview Gross asks if Remnick asks him about his time and how he manages responding to every inquiry regarding The New Yorker.

From the transcript:

REMNICK: Bring it on. The odds are tough. I remember when I was in my 20s, I sent William Shawn a query letter, and I got an answer. And I never forgot getting an answer.

GROSS: What was the answer?

REMNICK: The answer was no (laughter). But I never forgot the time that was taken to write a cogent, short note about why not. And I also remember when I submitted my first piece to The New Yorker, which was happily accepted by Gottlieb – by Bob Gottlieb – he answered that day – that night. And I’ll never forget that. And I know in my heart that I’m falling short all the time in a million different ways, but I try to answer emails, letters, phone calls because I know not only is it the right human thing to do, I think, but also, once in a blue moon, it’s going to pay off. Once in a blue moon, you are going to get a short story, a suggestion, an idea that’s going to find its way into The New Yorker and be something or someone brilliant. And that’s part of the job. And it’s a delightful one.

Who knows what responding to a simple request for feedback will turn into? What might seem like a boring response to a question asked for the 300th time might turn into something much more.

Writing is Thinking

Listening and responding helps you to think about your creation. The entire product or service is evaluated in a new light.

Automattic requires all new hires to work the help desk. Why is that? Shouldn’t those developers be writing code? Shouldn’t project managers be catching up on the team’s progress? No. Learning how the product works and understanding how customers approach the product works to improve the product.

Writing up a FAQ with that experience from the customer’s view helps you think about how your creation works. Where can it be improved? What keeps coming up as a difficulty? What’s not clear? What can I go back and make better?

That comes from wiring and thinking about things in public. Pushing the ‘Submit’ button and letting others see it. Responding to what they put out there.

In Summary

I encourage all creators of things, whether it’s an iPhone app, a web site, a community, a non-profit – whatever – to deeply consider the work and art of community feedback and dialog. Consider it to be just as crucial to the growth and stability of your work. Just as writing code, organizing topics, or wrangling volunteers is. They go hand-in-hand with happiness and success and are not nearly as scary or time-consuming as one may think.

In the end you grow as a person and professional, your product or service grows in its capability and focus, and the community as a whole benefits from learning and sharing from one another.

Ive Got Some Feedback

Jobs’s taste for merciless criticism was notorious; Ive recalled that, years ago, after seeing colleagues crushed, he protested. Jobs replied, “Why would you be vague?,” arguing that ambiguity was a form of selfishness: “You don’t care about how they feel! You’re being vain, you want them to like you.” Ive was furious, but came to agree. “It’s really demeaning to think that, in this deep desire to be liked, you’ve compromised giving clear, unambiguous feedback,” he said. He lamented that there were “so many anecdotes” about Jobs’s acerbity: “His intention, and motivation, wasn’t to be hurtful.”

This incredibly in-depth piece on Jonny Ive, the Senior Vice President of Design at Apple, reminds me a lot of the lessons and insights learned from Mike Monterio’s book Design is a Job.

To do good design work is to relish in good feedback. Don’t think designers or developers want you to say, “I like it!” when you really don’t. We all need to be honest – brutally and politely so – with one another to make better design.