User Experience Improvements for Uncanny LearnDash Groups

One of the biggest challenges that users of our Uncanny LearnDash Groups plugin face is figuring out how everything works. It’s a plugin that started off with quite a basic footprint, but over the last 2 years we have continued innovating and adding some really exciting features. As we have done that, we know that it has increased the learning curve a noticeable amount, both for users of the plugin directly and for LearnDash Group Leaders.

Because of that, the next few releases of the plugin will focus more on user experience. We need to make our giant plugin easier to manage, and that starts with today’s release of Uncanny LearnDash Groups 3.4.

The Group Management table

The biggest change in the 3.4 release is to the main Group Management page interface. When we launched the very first version, it was really simple; there was a way to add users and there were simple course and quiz reports. It was simple and uncluttered. Then we added a function to email users, an assignment management page, an essay management tool, a way to manage user progress… and it just got really busy and confusing.

Here’s an example of what part of the Group Management table header looked like before Groups 3.4 (this isn’t even all of the buttons!) versus today’s release.

learndash-group-simplified-interfaceIt’s a big change, to be sure, but we think simplifying the UI into menus instead of buttons will make the Group Leader experience a lot less daunting. For existing users, your existing shortcode attributes and settings will all be carried over, so don’t worry about these changes disrupting anything you might have customized.

Essay and Assignment Management

Front end interfaces to manage essays and assignments were late additions to our Uncanny LearnDash Groups plugin, primarily because we really don’t use them much on our own LearnDash sites. That remains the case, and until we recently worked with a client that does a lot with essay questions (I reviewed one example where a single instructor was assigned 3,000 essay questions to review), we didn’t know how inefficient our model was.

LearnDash Essay Review Table

In today’s release, we’re adding new columns so that you can see a user’s answer and approve it right from the list of essay questions. No more clicking to load up a modal and approving it there, now instructors can power through grading activities and turn things around faster.

Because of all of the new columns, we needed to do something with the clutter. Columns can now be turned on or off (with the little checkboxes above the table) and you can drag columns to whatever order you want. The system will even remember what columns users had shown and hidden when they visit the report at a later date. You can even resize the columns!

The filter for Graded and Ungraded should make it a lot easier (and more performant) to see only the types of essay questions you need to review, and First and Last Names columns make searching easier.

Performance improvements

Some of our plugin users really pushed the boundaries of how we expected LearnDash Groups to be used, and in some cases our model didn’t perform well on certain sites. We never expected to see groups with over 10,000 seats or thousands of users, and while we still don’t think it’s a great approach in many situations, the plugin will at least perform better in those situations.

The Uncanny LearnDash Groups 3.4 release is a big one, so make sure to test it on a Staging site before you update and have a look at the changelog for even more updates!

How to ask for WordPress plugin support (the right way)

Uncanny Owl recently passed a big milestone for our Help Desk: Ticket #10,000. We started using a Help Desk system in 2016, before we started selling plugins, and it’s perhaps our most valuable tool. It’s the first thing we check in the morning, the last thing we check at night, and using it ensures that the thousands of customers that depend on us stay happy.

After a few years of providing support to over 3,500 different people, we know all too well what makes a WordPress support ticket easy to resolve and what types of inquiries are going to drag on for some time. Everyone wants a quick fix to their question or problem, and while we as plugin vendors do our best, there’s a lot you can do as a plugin customer to make the process more efficient. In this article, we’ll outline the best ways for making sure that your problem is resolved quickly and accurately.

Help Desk Stats

Be specific

Last Thursday I took a call from a plugin customer who wasn’t very happy with our product. Despite us having a 10 minute call about it, I still don’t know why he was unhappy. The best answer he could give me was that “nothing worked”. I tried to dig deeper, to find out what functionality he was using and even why he bought the plugin, but he could only tell me he bought it to make his site “better”. I know he was frustrated, but he couldn’t articulate specifically what he was expecting that the plugin wasn’t doing.

Receiving a ticket that tells us that a “plugin isn’t working” makes it difficult for us to help and means that we have to follow up asking for more details, which in turn delays resolution. Tell us what you’re expecting to happen that isn’t happening; let us know what you are experiencing now. If you see an error message, include the error message.

Be kind and stay calm

We know that you’re reaching out to us because you’re experiencing a problem that’s causing anxiety and asking us may be your last resort. We do our best to empathize with the situation and we approach tickets as if they were about our own site. When we receive a ticket that starts off with an introduction like, “Hey guys, love your plugins, but I’m running into an issue right now with XYZ and I’m hoping you can point me in the right direction”, it’s going to set the right tone for the conversation and put everyone at ease. We’re also going to stay focused on resolving the issue.

While it is (fortunately) very uncommon, taking the opposite approach slows things down and adds tension to the relationship. Early last week, a customer reached out to point out a small error in a line of code that we shipped out (that had negligible impact on functionality). It could have been a simple interaction: “Hi Uncanny Owl team, I noticed a small issue in this file on line 123, it should be ABC instead of XYZ, can you confirm the fix and include it in the next release?” That would have been fantastic, we would have investigated and confirmed it immediately, and the ticket would have been closed. Instead, the user led with, “Do you guys even test anything before you push updates?”—and then we’re automatically on the defensive. We then have to be more careful about planning our reply and approach to a resolution.

Provide a test case

Last week we had a ticket that effectively said, “Some of our users report that they can’t complete a course, please fix it ASAP.” I didn’t know what plugin they were using of ours, what was supposed to trigger course completion, etc. It took about 4 emails back and forth to put together enough detail to understand what users were doing and what was expected but didn’t happen.

Here’s an example of a great test case related to a real (and recent) issue with one of our plugins:

Hi, I’m using the Uncanny LearnDash Toolkit Pro plugin with the Autocomplete Lessons & Topics module turned on. I have autocompletion enabled globally, but for the first topic of a course I have it disabled at the topic level. When I visit the topic as a user, I’m able to click forward to the next topic and the first is marked as completed. It shouldn’t be marked complete because of the topic-level override. Any idea what I’m doing wrong? Here are some screenshots so you can validate my settings.

That is a fantastically helpful ticket to us because we know exactly what the customer is using, we know how things are configured, we know the steps they’re taking and we know the expected vs. actual result. This kind of example makes it really easy for us to validate the issue in our test environment to assess if there is a problem in our plugin or if it’s a unique behaviour to their site. Be very descriptive, outline the steps someone could take to reproduce the issue, and include additional details like screenshots whenever it’s appropriate.

WordPress plugin support

Outline what you’ve done so far

Once again, the more we know the better. Using the ticket above as an example, it would absolutely help us to know if the user tested with different module settings or with the plugin disabled entirely to see if the results were different.

Let’s take an example with one of our plugins.  Perhaps the site admin wants LearnDash Group Leaders to see the admin bar, but for some reason it’s not showing up.  In our Hide Admin Bar Toolkit Module, they have the Group Leaders unchecked (so those users should see it).  This suggests another plugin is conflicting with the settings in the Toolkit.  Before reaching out to us, maybe the customer already disabled all plugins (except our Toolkit) and changed the theme temporarily to confirm the issue still happens. Knowing that would save everyone time, because that’s the very first thing we would suggest if we suspected a conflict.

That leads us to a related and very important recommendation.

Get a Staging site ready

With elearning sites in particular, testing updates and issues on a site that’s independent of your live site is critically important. Having a Staging site available for that purpose is a must, and if it can be used for resolving issues as well, all the better.

Sometimes we simply can’t trace a plugin issue through descriptions and screenshots alone. We do need access to see what’s going on and to test things. I can absolutely confirm that we do not want access to your site unless there’s no alternative, and if we need it, we don’t want to test things on your live site. If an issue seems like it’s going to need troubleshooting directly in your environment, it’s going to be easier and safer for everyone if that testing can be done on a clone of the live site rather than the real site. If you suspect the plugin vendor will need to see what’s going on in the environment or the conversation is heading in that direction, get a Staging site up and running.

Do some initial troubleshooting

If you’re new to WordPress this guidance is going to be hard to action, but as you get more experienced you’ll start to understand what’s likely to be causing certain errors and where to look to trace them.

If you see a white screen, a page in /wp-admin/ only partially loads, or you actually see a “500” error message, there’s likely a fatal PHP error on the site. Typically there’s going to be an associated message in the web server error log, so you’ll want to check there first for a “Fatal Error” and pass that on to the plugin developer. The WordPress debug tool can also provide really important clues about system-level errors.

If something on a site just looks wrong or unlike screenshots on a plugin developer’s website, or interactive elements on your site aren’t working properly, it’s likely a javascript or CSS conflict. Check the browser console (View > Developer > JavaScript Console in Chrome) for more information, and if you find any errors, they will be immensely helpful to the plugin developer.

Include one issue per ticket only

This one is really important when you want a quick resolution for your ticket. Our team has multiple developers, each of whom has different areas of expertise. We have 3 customer-facing staff handling support tickets and 4 developers behind the scenes providing assistance. Tickets that include several issues slow things down by an order of magnitude, because now we have to split tickets up behind the scenes, assign them to different developers and staff, then wait for an update on all of them before we can reply to the customer. After all, we don’t want to send pieces of updates and end up in situations where only part of the ticket ends up getting answered.

A few weeks ago we had a customer submit a 3-page PDF file outlining 5 completely unrelated issues they were having. None of the 5 had a simple answer, all required testing and validation, and we had to address all of them before we could properly reply (beyond sending an initial confirmation warning the user that it would take longer to investigate all 5 questions). Turnaround time would have been improved for the customer, and things would have been more efficient for us, to have received 5 separate tickets instead.

We want to help

When something goes wrong with a WordPress plugin, it’s absolutely a scary moment and you just want it fixed as quickly as possible. We as plugin developers want the same. By helping us to understand the problem, making it easy for us to test it ourselves and by giving us all relevant information, your tickets will be turned around faster and your issues resolved more quickly.

Give the tips above a try the next time you need to send in a support ticket and let us know in the comments if they helped!