On 09/08/2016 03:38 PM, Greg Watson
The project release review documentation contains a
section on usability and a reference to the User Interface
Guidelines. Projects are expected to explain deviations from the
guidelines and standards. How many projects actually complete this
section for a review (I admit that I am guilty here), and how
often is it raised as an issue as part of the review? Answers: few
and none. The documentation requires me to certify that the API is
Eclipse Quality, which does impart some sense of importance. Why
don’t I also have to certify that the release conforms to the User
Interface Guidelines as well?
This document covers only the Eclipse-specific UI Guidelines. Those
UI Guidelines are somehow encouraged by the Platform frameworks, so
those are not the ones that are the most frequent and annoying in
The annoying ones are typical basics of ergonomics: using wrong type
of widget (link vs button, combo vs radio, buttons expressing choice
when sometimes radio would be better...), weak wording and labeling
that assumes users already knows much, validation happening late
upon another user action when it could be instantaneous as user
types, not making the most probable next action very accessible,
require user to read a complex screen or text to take a simple
There are multiple sites on the Web giving concrete tips to improve
a UI, and improving UX happens by using such UI principles and
putting ourself in their user's shoes as we're creating or changing
So IMO, we also need to find out a good resource of basic UI that
we'd also take as a complementary guideline.
Having project signing "the project team did it best to enforce UI
Guidelines recommended by ... and ..." on release would make sense,
at least to bring attention on those guidelines.
Even if projects don't respect them, it wouldn't be a blocker, but
at least we could easily ping them to highlight some possible UX
bugs to fix in the future, with a reference to a common rule.