How best to report issues?

Hi there Skritter Team.

Now that there is no longer a beta version, I’m not sure how best to alert you to problems.

The easiest method for the user was to use the beta feature of sending a screen shot directly through the app. That was really efficient. No real interruption in one’s study.

Now: do we report here? Do we have to email you? Much more tedious and interrupts learning for too much time.

Anyway, three small problems identified below.

The first, the exact same character has both a simplified and traditional card.

Second, the traditional radical is correct but this is not the normal traditional stand-alone version of the simplified 网 .

The third: this is not the correct traditional form of 讚 .

I’ve come across other little problems like these but it was right in the middle of review and I didn’t want to be bothered with the time it takes to report them, now that there’s no beta feature.

Maybe include the pic-report feature in the actual app?

You can report errors directly from the app for vocabulary. Just open the Info panel for any vocabulary and use the “Submit Correction” button on the bottom of the screen. That goes into our correction inbox and gets sorted by issue type.

If you’re seeing an issue with specific decks please let us know those details in the error report and we’ll see what we can do. Alternatively, you could copy the deck and make edits directly.

If these are from some of the new user-made HSK decks, perhaps consider putting them on hold for a while–we’re actively making official decks for all the upcoming HSK content, and part of the process is checking to make sure all the simp/trad mapping is correct!

Edit: I did fix up 給讚 on the Traditional as it looked like an entry issue and not a deck creation issue.

1 Like

Thanks for fixing that, I noticed!

I understand there is a reporting feature on the info panel. However there is no longer a way to include a pic. That was a little bit faster.

I guess the info panel will do - but it requires a written explanation.

Short answer:

the correction process does require a written explanation, but it is super helpful for us as a team and how we handle issues, feedback, corrections for lots of super awesome Skritter users.

Long answer:

Since this post is a question about How to best report issues? I’d like to dig deep into that question, and address that for anyone reading this, and also give a little behind-the-scenes insight into all this stuff.

First, I think it is important to establish that there needs to be a distinction between Beta feedback, and Corrections.

These should not be treated as the same thing, and it would be super helpful to us for anyone reading this if that distinction is honored.

When we get a screenshot on a beta build (via Apple) we get info about the device, build, and the associated TestFlight email. It’s a quick and easy way to quickly share info with us, and we can hopefully use those details to track down bugs and fix them before we release the app as a live production build.

That’s exactly what we’re looking for when we release beta builds. Rapid testing of new features, regressions, things of that nature, along with any details about the when and the where when things go wrong. We can then collect all the feedback in bulk, fix things up, and then release the next build or push the latest to production. Mission accomplished!

There are some issues with this submission process for Skritter, and now that I’m writing this reply it honestly might actually be best for us to disable this kind of reporting in the future :thinking:

That’s because what we don’t get from these emails are the super important things for when the issue is at the account or vocabulary level.

Skritter username and associated email are not provided with the screenshots, and it makes getting those details unnecessarily complicated. To make matters worse, we don’t actually have a way to reply directly to screenshots and establish a conversation. We can follow up manually, but it doesn’t mean that the email for TestFlight is the same as the email on Skritter.

Sometimes we can guess who the user is, but that isn’t always the case. So, we’ve gotta dig up all that info manually if we can and a new email and hope the user sees it and opens it. If we don’t know those details already, our first point of contact goes like this:

"Dear skritter user, thanks for your email. We’d love to help, but could you please let us know your username and the email address related to your account so we can take and dig into your account and assist?

No fun. Especially when the user doesn’t reply because the TestFlight email is in an inbox they never check because they made it 15 years ago or something like that. We’ve certainly seen it all at this point :sweat_smile:

The alternate method of reporting report bugs and issues (not corrections) is to use the Contact button in the app, which we vastly prefer.

When issues come in via the Contact button in the app or the website, we get tons of helpful data right out of the gate. Username, account-associated email, build version, and a quick and easy way for us to establish a contact in the context of the issue being reported.

As an added bonus on Help Scout, users can even see previous conversations with us right in the app or on the website. Wahoo!!!

On our end, we get an alert in our Help Scout inbox, which our entire team can view, tag, add notes on, and even pass along to the appropriate team member with the tap of a button. From our end, this is smooth as butter :butter: and 100% the best way to report bugs or account-related issues.

Corrections and item-related issues are a different beast, and the best way to report them is slightly different.

To provide some context, our database has over one million entries and grows larger every day. There are mistakes, of course, and do our best to fix them up in batches on a regular basis. While we’ll never have 100% perfect entries, we are constantly and continually improving and expanding the character, word, and sentence-level content in Skritter. While a vocab item might have an issue with reading, audio, example sentence, etc. they’re not bugs in the software sense, and really shouldn’t be treated as such.

The app is largely working and doing its thing, and fixing the item will not require a beta or production update.

Because of that, the best way to report corrections is to use the Submit Correction button from the vocab info screen. When a correction is submitted this way it automatically gets tagged in our system by issue type, and we get tons of details about the vocabulary in question along with a direct link that opens up the item directly in our database.

No muss, no fuss, no fat finger typos, or time spent typing the entry in a search query-- we just press a button and the item in question can be fixed up during the next batch of corrections we do!

Honestly, these days we can actually do lots of cool things on our backend, which are pretty cool. Not only can we fix corrections, but we can also add sentences, update audio files, audio Skritter-made images, deck art, and in-app videos, and lots more on the fly with a single save button. Those updates then automatically go out to the website and new mobile apps and are updated the next time you sync your account or open a deck-- no local data refresh needed!

I hope those details help answer the questions about how to best report issues. This is a super long reply, but I wanted to give some additional context behind how it all works, and why we encourage everyone to use the flows we’ve built out. We know it takes a little bit more effort to send an email in the app using the Contact form or using the Submit Correction button, but it saves us an insane amount of time on our end, which is time we can then spend making more content, fixing more issues, and making more updates to the apps that all you wonderful and passionate people reading this far are using to study Chinese and Japanese :heavy_heart_exclamation:

Jake and The Skritter Team


Hi jake,

A little summary of what to do and when, so that we can help you correctly, would be nice. Also, I can’t find a contact button or contact form in the iOS app.

Menu button, Help, then contact (via email.)

I think the priorities are:

  1. Actual Bugs : use Beta reporting (if still available), better yet use app contact form

  2. Errors in vocab/database/recordings/definitions/trad-simp etc. : use Submit Corrections in info panel.

@SkritterJake Is that about right?

Yup! That basically covers it. As I’ve done with the last few beta builds, I’ll also try and post some detailed notes on what’s coming out and what to look for. It’s helpful to shape the conversation if we’re chatting on the forum as well.

3.6.0 beta will be coming soon!!!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.