Sorry if this is duplicative of other discussions, but is there a desire for some sort of step in the Plasma (or other KDE app) development process for a review/checkpoint around the Visual Design Group principles?
This particular example is minor (and I personally like the direction it took), but on the face of it this merge request and this VDG principle don’t seem to be in alignment, at least if the Shake Cursor feature is considered an “Accessiblity” feature as would be indicated by its System Settings placement.
Would it be helpful, in cases like this, to have some sort of checklist item for merge requests to see if there’s a potential conflict with any VDG guidelines, and to document whether something should change, or whether it’s an intentional variance? That’s probably happening anyway within Nate’s head when he approves items, but just thinking about ways to potentially document that work so others who are less capable of doing ten different jobs than Nate can keep the train rolling as well?
Note that this does not apply to accessibility features which are generally always off by default.
Note the generally.
The reason why accessibility features are off by default is that they generally do not make sense for average user. Things like sticky keys, screen reader, visual bell etc… do not make sense for people without disability’s.
But for every rule there are exceptions: The shake cursor makes also sense for users that are not visually impaired, especially if you have a big monitor or use multiple monitors.
Yep, I agree 100% with the ultimate decision there and understand the generally language doesn’t mean it’s all the time.
I was just thinking of whether or not there should be something documented around making sure those decisions are made consciously / with awareness of the Human Interface Guidelines and noting any perceived points of conflict, just out of maybe helping encourage consulting those guidelines during the review process? Not a big thing, just a curiosity about the process