Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] Java IDEs comparison

Imagine IntelliJ and Eclipse are both movie critics, and we're competing to see who can be the best critic.  IntelliJ uses software which lets them discuss using in-line YouTube embeds, so they can easily call attention to a scene or vocal inflection.  Eclipse uses text-only mailing lists, requiring that discussion points be explainable in common prose.  In this scenario, it is likely that the IntelliJ community would develop a sophisticated sense of color and sound, while the eclipse community would be unable to discuss anything besides story structure.

This is a forum thread where the Atom developers are discussing coffeescript syntax.  Although the discussion is about syntax, you'll see that it naturally segues into "how will we do highlighting?", and they toss around some visual mockups.  They can easily and naturally discuss visual concepts.

Here's a VSCode bug report on GitHub.  The UI is jumpy, so the user just uploaded a gif of the jumpy UI, right inline with their text.  How many sentences of monospaced prose in Bugzilla would be required to communicate what this gif communicates?

There has been some good discussion on whether or not we need more cathedral, more bazaar, or just plain-old more people.  But I think it's important to remember how important tools are in all these scenarios.  Beautiful artwork is valuable in cathedral-based and bazaar-based ecosystems, because both architects and the common person have eyes that can see.  People come to bazaars and cathedrals because they can tell where to come in.  Imo, we're made our devs blind and hidden them in a maze.

If you started an IDE project from scratch today, you could have forums on discourse and issue tracking, code review, and CLA on github in one day.  Obviously it's not so easy for eclipse to make this change.  But is the history an asset or a liability?  Die an innovator or live long enough to see yourself become legacy.

Ned Twigg
Lead Software Architect, DiffPlug LLC
340 S Lemon Ave #3433, Walnut, CA 91789

On Thu, Sep 8, 2016 at 7:58 AM, Doug Schaefer <dschaefer@xxxxxxxxxxxxxx> wrote:
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.


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>

>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 <>
>> My blog <> - My Tweets
>> <>
>> _______________________________________________
>> ide-dev mailing list
>> ide-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>ide-dev mailing list
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit

ide-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top