Why Solving the Problem Isn’t Enough: Video and Slides

“Be human first… then solve the problem.”
– Taco V.

On October 3, 2017, Community Manager Taco Verdonschot from Yoast shared his support expertise with a group of international participants, from his base in the Netherlands. He passed along insights about the importance of using empathy – not just solving issues – to deliver outstanding support to WordPress users.

The workshop was the second in a series that evolved from the 2017 Community Summit, with the aim to share best practices for WordPress support. The first session covered theme support, and the recap can be viewed here.

If you have suggestions for other support-related subjects you’d like to see in the future, feel free to comment here – we’re open to ideas.

Video (53 min.)

Slides

Links From Slides

12 – http://www.lifehack.org/465044/7-intricate-differences-between-empathy-and-sympathy
13 – http://www.lifehack.org/465044/7-intricate-differences-between-empathy-and-sympathy
14 – https://yoa.st/empathy
18 – https://yoa.st/sw-taco-example1
19 – https://yoa.st/sw-taco-example2

#support, #support-workshop

The Developer’s Guide to Supporting Your Themes – Video and Slides

Thank you to everyone who joined me yesterday for a remote workshop, in which I shared tips for supporting WordPress themes. Participants attended from around the world, and folks asked some great questions afterwards. The presentation was recorded, and the video, slides, and notes are below.

This session was the first in a planned series born at the 2017 Community Summit, with the goal to share best practices for support across the WordPress world. Stay tuned for updates on future workshops.

Video (38 min.)

Slides

Notes

1 – Welcome to The Developer’s Guide to Supporting Your Themes

2 – I’m Kathryn Presner, and I’m a Happiness Engineer on the Theme Team at Automattic. I help people with theme questions on both WordPress.com and self-hosted sites – troubleshooting when there’s a problem, reproducing and reporting bugs, and customizing their sites to look and work how they want, whether through custom CSS or a child theme.

3 – I support over 100 themes on WordPress.org and over 300 free and premium themes on WordPress.com.

Do any of you enjoy doing theme support? Do you think of it as a necessary evil? I’ll give you tips on how to handle support so it’s less stressful, more enjoyable and satisfying.

4 – Be nice, empathetic, human, professional – If you show you’re human and care, you will help users realize you’re a real person just like they are.

Example – https://wordpress.org/support/topic/how-to-make-the-date-and-title-permanently-show-up

5 – A few nice words about a user’s site are always an added bonus, help to humanize you.

6 – Acknowledge when people are uncomfortable with your instructions, offer reassurance and explain how things can be undone.

7 – Be patient, even with thread-hijackers.

8 & 9 – This is a user who jumped into the middle of a thread where I was helping someone with a theme – asking about a completely unrelated problem. I could see that they were frustrated, and also a new user, having jumped into a couple of other threads and started a few of their own. Instead of chastising and telling them to start a new thread, I tried to find someone to help with their other thread. I ended up jumping in to help them there.

Example: https://wordpress.org/support/topic/running-motif-theme-on-org

10 – Gauge Skill Level: beginner, expert, in between – Ever heard “talk to me like I’m in kindergarten” or “I’m a total novice”? Try to adjust your explanations for the user’s level. Avoid jargony technical explanations, especially if the user is a beginner. Read between the lines if you’re not sure.

11 – Example: https://wordpress.org/support/topic/adding-banner-ads-above-header

12 – Example: https://wordpress.org/support/topic/newbie-social-icons-and-widgits

13 – Remember, folks are often frustrated at own their beginner skills!

14 – Think outside the theme: plugins, other themes – sometimes what a user wants to accomplish is much simpler or more logical with a plugin or even by switching to a different theme. Think about which route makes most sense.

15 – This user is halfway there. They’ve installed a plugin to add custom CSS, but they need help with calling in a Google font. Example: https://wordpress.org/support/topic/changing-the-font-type-in-sidebar-widgets

16 – I’ll often think of things later and add them as a p.s. and I think that’s fine!

17 – In hindsight I could have also given them a direct link to the font they were looking for on Google fonts.

18 – http://macmanx.com/2014/06/04/custom-fonts-without-plugins-for-wordpress-themes/

19 – Offer resources: Codex, tutorials, hire someone – What if something is “out of scope” for the kind of support you’re able to offer? What about that user who completely wants to change their theme, and refuses to consider a different one that might be better suited? Try to always give them somewhere to go, even if you can’t directly solve their issue, point them in the right direction, whether it’s a tutorial, Codex function, or even sending them to jobs.wordpress.net where they can hire someone for a custom job.

20 – Example: https://wordpress.org/support/topic/motif-theme-display-on-ie8

21 – Foster community: let volunteers help, acknowledge – If you give support in an open venue the WP.org forums, leave space for volunteers, especially if a question is simple. Don’t necessarily answer every thread immediately. Praise community members when they give a great answer. It’s motivating and encourages them to come back and keep helping others.

22 – Example – “Ernest, thanks for the input about the Jetpack CSS interference.”

23 – Provide theme docs, FAQ, screenshots, screencasts – The most common thing users have confusion with is how to set up their site to look like your demo, so be sure your documentation explains how to do that step-by-step. Don’t forget screenshots, screencasts, even animated GIFs can be helpful!

24 – List steps & point to documentation. Don’t skip steps or assume anything.

Example: https://wordpress.org/support/topic/featured-content-slider-3

25 – Example: https://wordpress.org/support/topic/archive-list-4

26 – Be realistic: enhancements, bugs, older browsers, uncommon devices – Be honest about bugfixes or enhancement requests, if something isn’t likely to change, say so. Set realistic user expectations. If a new feature is unlikely to be added, don’t lie, encourage to look for alternatives. If a bug is minor or doesn’t affect a lot of people and is unlikely to be fixed in the immediate future, don’t say it will.

27-29 Example: https://wordpress.org/support/topic/adding-new-widget-area

30 – Limit channel-wwitching different thread/forum/venue – What if someone asks you a simple CSS question…. for a theme that’s not yours? If you can help, help – let them know where to go next time. Frustrating to have conversation cut off before it’s begun. Always imagine it’s someone’s first time in the forums

31 – Help someone even if it’s not your theme? If bit’s a simple question and you can, why not?

Example: https://wordpress.org/support/topic/how-to-change-navigation-bar-and-box-color-on-hemingway-rewritten-1

32 – Refer out if better expertise lies elsewhere – Kind of the opposite of what I just said about channel-switching, but… sometimes it turns out that the issue isn’t with something WP-related. Try to point them in the right direction.

33 – Example: Referring a user to an AdSense forum.

34 – Best Practices: child themes, custom CSS editor – Don’t assume users realize they shouldn’t edit the original theme files or risk losing all their changes when they update the theme. For CSS-only changes, suggest using the built-in custom CSS editor – if user needs theme-file change, explain how to make child theme.

35 – You can have a template answer – TextExpander is an amazing app for Mac. Example: Guiding a user in making a child theme so they don’t lose their changes every update.

36 – Screenshot of a pluggable function – Best practices goes both ways: wrap functions in an function_exists conditional so it can be redeclared it in a child theme

37 – Happy Users = Happy You!

38 – Screenshot of a user happy they were able to make a change. “Fabulous. I also figured out how to resize it, etc. I never thought I was going to be able to do this!!! Very happy.”

39 – What About You? What are your biggest challenges? What do you want to get better at?

40 – Where to find Presentation: https://www.slideshare.net/zoonini/the-developers-guide-to-supporting-your-themes

+make.wordpress.org/themes

#support, #support-workshop, #themes

Support Team Summary for January 22nd

This week focussed on tools, specifically what we have and what we want.

What we Have

We already have a lot of tools, so we took the liberty of adding all of them to the now ever-evolving Helpful Tools handbook page.

What we Want

We would all love to have what’s described under Meta Ticket #716.

We would all love to have a way to move threads from the general forum into their perspective plugin or theme forum, though this does not appear to be possible under the current forum architecture.

We would all love to have a tag blacklist, so people will stop tagging threads as “WordPress” and “HELP” and such.

Read the transcript of today’s meetup.

#support

Support Team summary for January 15th

For today’s meetup the support team welcomed @karmatosed from the Theme team and @joedolson from the Accessibility team and the agenda was “How can support assist those two teams?”

This resulted in the following points being discussed.

  • There are always themes that need reviewing and any help offered there will be greatly appreciated.
  • Cross team training for support to learn more about themes would be good.
  • Tammie introduced us to the idea of learnups.
  • What constitutes an accessibility support topic?
  • Tagging topics correctly to make it easier to find or monitor via email or RSS.

Learnups

Everyone got excited at this idea and one example was summed up like so:

“Pick your favorite theme and answer 4 questions. At least one is outside your ‘normal wheelhouse’.”
So like if you’re the bee’s knees for css, try editing functions.

Theme team learnups have happened on Google Hangouts to be recorded and on Slack. A Support Challenge learnup can be scheduled or even an afternoon sprint to reply to support topics.

This is a great idea and will be explored further. Think of it as an online mini contributor day for support.

What make a topic about accessibility?

Joe had some questions about how does the support team work, are there any requirements or training involved etc. Most of the support team started by getting involved in the forums or IRC. Except for having some PHP and CSS experience and remaining calm there really is not much to do to get started in support.

A legitimate accessibility topic is anything that impacts people using assistive technology or with a disability that doesn’t impact people in other environments.

Using good tags on topics

For accessibility support a real problem is finding topics. This lead to a conversation on how to tag topics and Mika wrote up a good post on that subject. Joe’s forum account was upgraded to moderator to permit him to use some of the search in the backend as well as remove tags from topics that are incorrectly tagged “a11y”.

This meetup ran a little on the long side (over 1 hour) but it was good and inviting people from other teams was really useful. It resulted in some good conversations and there will be more of these meetings as well as possibly scheduling a learnup session.

Read the transcript of today’s meetup.

#support

How to Properly Use Tags

This came up in this week’s slack chat. Using tags can be a fine art, and we may end up doing a tag-scrub some day soon, to get more people into helping triage posts in the forums.

Tags usually aren’t used properly, and it’s OKAY that the masses don’t. This is actually a great job for someone who wants to get involved in support. By reading a post and determining it needs specific attention, you can improve the chances of someone getting help promptly.

When you see a post, look at what the poster is asking and try to use a tag that makes logical sense for the issue. To help you get started, we have some standard tags that we use and encourage their appropriate use.

Team Tags

The following tags are used by the various make/teams on WordPress.org to track posts that need their attention.

  • Accessibility – a11y
  • Questions about the theme review process – thememod
  • Questions about the plugin review process – pluginmod
  • Moderator please come fix this – modlook
  • Not Safe For Work – nsfw
  • WordPress.com theme not in the .org repo – wpcom-theme

Proper Use of Modlook

Don’t use it if you are a moderator. This should go without saying.

Be very careful with ‘modlook’ – Abuse of that tag will get your posting rights revoked. It should be used to flag moderator attention for things like duplicate posts, spam, abuse, harassment, etc. It is not to be used for getting help faster. That just gets you negative attention.

When you use ‘modlook’ try to use it in conjunction with another tag. For example, if the issue is a spammer, use ‘modlook’ and ‘spam’ tags. If the issue is the post has personal information (like passwords) use ‘modlook’ and ‘private info’ – Basically try to make sure if a moderator is reading the post, they’ll see why the post needs attention. This is especially important when we’re talking about duplicate posts 🙂 If you’re tagging spam and think it may not be obvious who is the spammer (things like ‘buy viagra!’ are pretty obvious), put the username of the spammer as another tag. Just in case. The mods will delete the tags once it’s handled.

It’s also a great idea to actually reply to the legit posts. Telling someone “I’m alerting the moderators to this post. Never post your passwords in public!” is totally awesome!

Keep in mind, we do not remove URLs from posts unless there’s a good reason. And by good reason we mean abuse, harassment, or legal reasons. Asking a URL be removed, or a post deleted, because someone is upset that Google picked up their URL in it’s search is not a good reason. If you don’t want something to be searched by google, don’t post it in a public forum.

Plugin/Theme Tags

This one is simple. Tag a post to match the slug of the plugin or theme that’s having the problem.

For example. If someone is having a problem with Akismet, tag the post akismet. If it’s Hello Dolly, tag it hello-dolly.

Pay careful attention to that plugin slug! Complicated plugins like https://wordpress.org/plugins/joes-awesome-twitter-widget may have the name “Joe’s Totally Wicked Cool Twitter Widget Plugin!” on the plugin page, but that slug of joes-awesome-twitter-widget is what you want to use for the tag.

If the theme is one downloaded from WordPress.com, use the tag wpcom-theme

Company Tags

If someone specifically mentions a hosting company, make sure that company is tagged. Many hosts keep people on payroll in order to monitor posts tagged for them. The same goes for things like theme and plugin shops. It’s helpful to them to have, for example, GoDaddy or StudioPress tagged.

When in doubt …

Don’t tag 🙂 Come on over to the #forums room in Slack and ask us for help. Someone’s almost always around.

#support

Discussion: A Better Do and Don’t List

The following are cribbed from another site’s Dos and Don’ts. They should not be considered the be all and end all of guidelines, but they’re a good start. I’m thinking that perhaps a simplified ‘dos and dont’s’ list may help some people who see our massive list of guidelines and panic.

This list is not perfect and I want your help

Please suggest changes and improvements. I don’t want to make it much longer, so if we can consolidate and combine, that would be good. There’s no point in even trying to get through everything, so really I’m trying to spell out the basics of etiquette on the forums.

Good Manners and Respect Dos and Don’ts

  • DON’T use “um,” be snotty to another user, or make the argument personal
  • DO know the difference between differences of opinion and personal attacks
  • DO treat others the way you want to be treated
  • DON’T present your opinions as facts
  • DON’T post the same opinion over and over in the hopes of wearing other people down or “winning” a discussion; just move on
  • DON’T be a gosh-darn dirty spammer
  • DON’T be vulgar; if you’re not sure, don’t say it

Starting New Threads Dos and Don’ts

  • DO search for existing topics before starting new threads
  • DO make a new topic if you find yourself saying “I have the same problem but …”
  • DO link back to a related topic (or closed) when approriate
  • DON’T use all-caps or excessive punctuation in thread titles
  • DON’T treat the support forums as your personal blog
  • DON’T get all meta and use the forums to rant about the forums

Posting Messages Dos and Don’ts

  • DON’T post in a thread until you’ve read the whole thread
  • DON’T post “Me Too!” messages; add something of substance to the conversation
  • DON’T sign your posts
  • DO use proper spelling, capitalization, punctuation, et cetera
  • DON’T post just to pimp your site or product, et cetera
  • DON’T post the same thing in multiple areas; pick a spot and go with it

Warnings, Bans and Trolls Dos and Don’ts

  • DO take any mod warnings you get seriously
  • DON’T bug the mods to remove moderation on your posts
  • DO help us out and report trolls, flame wars, and troublemakers by tagging a post with “modlook”
  • DON’T abuse the modlook tag

#forums, #guidelines, #support

Week One Of My WordPress Internship…

So many posts! Where to start!? The sheer amount of unanswered posts in the Support forums was a bit daunting at first. My first week as a WordPress Support intern was all about getting myself accustomed to the forums:

On my first day, I spent three and a half hours racking my brain and creating all manner of complex JavaScript to eventually solve an error in a user’s jQuery. It turned out that it was a very simple fix (the user was calling the wrong selector) – it shouldn’t have taken me nearly as long as it did to spot this.

I fell into this trap of spending too long on one problem several times throughout the week. I’ve soon realised not to leave it so long before reaching out for help or moving on from a post.

At the end of my first week, I feel as though I am a little quicker at spotting bugs in other people’s code and better at identifying the forum posts that I’m able to answer.

Week two: I’m going to continue with forum support and will also be contributing to the Codex.  Any advice/tips would be much appreciated. 🙂

P.S: I missed the weekly IRC Support chat on Thursday (sorry!) but will make sure I’m at the next one. Look forward to speaking with some of you then.

#forums, #gnome, #internship, #opw, #support

Support Internship: Introduction

Hey everyone.

I’m Siobhan. I’ll be interning at WordPress this summer as part of the Gnome OPW. My internship will be centred around support (forums, training, documentation) and my mentors are Mika Epstein and Hanni Ross, with Jen Mylo and Andrea Middleton acting as program administrators.

A little about me: I’m from Barry, South Wales and studied Computer Science at the University of Reading. Last year, I was lucky enough to spend a few months working as a developer at a digital agency in Florence, Italy – it was here that I started learning more about and getting involved in Free and Open-Source Software. I have since gone on to work on various WordPress projects on a freelance basis.

I feel very lucky to have this opportunity to get involved with and give back to the WordPress community.

I’ll be posting updates on my internship here every Monday for the next three months, and you’ll also be able to find me lingering on the #wordpress, #wordpress-sfd, and #wordpress-gsoc IRC channels.

As a final note: I’d like to wish the other seven WordPress GSoC/Gnome OPW interns a great summer. Good luck everyone!

#gnome, #internship, #opw, #support

Docs is trying to build pathways to support

A Twitter discussion this morning spawned a conversation about the lack of breadcrumbs to support in the Codex, namely for theme authors looking to ask questions about the theme review guidelines.

The Docs team is compiling a list of articles that point out some of the support pathways, such as mailing lists, IRC, the forums or other channels.

We welcome any input and discussion: https://make.wordpress.org/docs/2013/01/10/missing-breadcrumbs-to-support/

#docs, #pathways, #support, #wptrt