| Re: [ide-dev] Java IDEs comparison |
The most common complaint I hear from product managers is that the menus
and toolbars are too cluttered and hard to understand. The UI Guidelines
we have is more a look and feel guide and frankly, it¹s a bit dated. It
doesn¹t deal with the big picture of user experience of the IDE with all
the plug-ins installed that a user needs.
Just my feel right now, but it really looks like we¹re understaffed to
make any big changes. We can create the best product development plan we
can but if we don¹t have the people to execute it, we stay where we are.
I do have hope for the language server effort. And, yes, I¹m willing to
blow up CDT¹s current language server if the new effort proves better and
is easy to integrate. I think that¹s the best we can do with what we have.
Just slowly pick things off one by one until something better comes along.
And the language server opens a door to that too.
Doug.
On 2016-09-08, 10:15 AM, "ide-dev-bounces@xxxxxxxxxxx on behalf of Gorkem
Ercan" <ide-dev-bounces@xxxxxxxxxxx on behalf of gorkem.ercan@xxxxxxxxx>
wrote:
>
>
>On 8 Sep 2016, at 10:05, Mickael Istria wrote:
>
>> On 09/08/2016 03:38 PM, Greg Watson wrote:
>>> 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 Eclipse
>> IDE.
>> 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 decisions...
>> 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 a UI.
>> 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.
>
>
>How about allowing only the projects that conform to UI guidelines to be
>part of the all-in-one distributions from Eclipse?
>I think the UX problems are more annoying when combined with the
>expectations raised by a single download.
>Perhaps we can reboot ³UI Best Practices Working Group² and give it
>a magic stamp that would allow project into distributions.
>
>
>
>> --
>> Mickael Istria
>> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
>> My blog <http://mickaelistria.wordpress.com > - My Tweets
>> <http://twitter.com/mickaelistria >
>> _______________________________________________
>> ide-dev mailing list
>> ide-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/ide-dev
>_______________________________________________
>ide-dev mailing list
>ide-dev@xxxxxxxxxxx
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
>https://dev.eclipse.org/mailman/listinfo/ide-dev
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ide-dev