I’m a bit late to the party, but hopefully not too late!
As far as the workflow, the current flow was requested by multiple users, is how legacy Skritter works, and is more aligned with other similar products. Plus the other way requires an extra tap/click. It could be a setting though.
They’re not a set of radio buttons. They are buttons and behave like them. One of them is highlighted to indicate how you will be graded if you do not click any of the buttons. Clicking on any of those buttons (including the highlighted one) advances the prompt.
Pro and advanced versions of the same UI are generally a bad way to solve an underlying issue with the functionality you present/allow and are hard to maintain. Allowing the functionality but making it less visible (think keyboard shortcuts, right-click context menus, nested menu options, etc.) is one way to solve the issue though as power users will still seek out and use the feature if it’s available.
The arrows are more of discussion point among the team than I’d like to admit We’ve discussed options like those you proposed. They’ll likely move around and change before they reach their final form. Personally I’m on team above the canvas area (for mobile).
I don’t doubt that, people’s workflows differ, and I haven’t user tested this, my opinions are my own. Unless I misunderstood @jr0026, however, it seems we are at least two that feel this way.
I also don’t mean to advocate to change the existing behaviour, but to add an optional one. You could, for instance, have full auto, semi-auto and manual progress. I know how much work features are, though, so I won’t be too upset if you choose not to implement this, but it would certainly be very useful for me. The combination of the invisible navigation buttons and this, however, makes for a crappy workflow on my part.
It would also be interesting to know where the users that requested this behaviour came from, was it from desktop, mobile or tablet (or any combination of these)?
Well, with the risk of going deep down the rabbit hole of polemics, I beg to differ.
Yes, I see they are implemented as HTML buttons, but that’s an implementation detail, as is the underlying implementation of the event system that sends a given event to the object that represents the widget that occupies the given screen area upon which you tap, it’s not really relevant as buttons are anyway conceptually a superset of radio buttons.
Of course, there are probably many definitions of a radio button, but I think Wikipedia’s is as good as any:
which I’d say fits the description of the grading buttons quite well. You have even implemented this behaviour explicitly: when you tap any non-pre-selected button, you remove the selection from that (by changing its colour) and then you select the one you tapped (by changing its colour). Only after this do you advance the prompt.
This is exactly the behaviour you’d get from an HTML radio button, should you add an event handler that submits its form when it’s checked. This is, as I stated, not entirely uncommon, but it’s discouraged for complex forms as it is not something users are used to, and will thus generally be unexpected. You can of course argue that you are making a highly specialised UI, and you can bend or break UX/UI guidelines and best practices when you see it fit, and I’d agree, but in this case, as I’ve tried to point out, I find it a bad choice.
Another note on the arrows, they sometimes cover part of the character, where strokes should start, making it impossible to draw a stroke in the correct place. For example, on my phone, the third stroke in 好 is affected by this. As these arrows are now invisible, this makes for a kludgy experience.
We’ve discussed options like those you proposed. They’ll likely move around and change before they reach their final form. Personally I’m on team above the canvas area (for mobile).