[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-vision] Minutes from December 3/2014

Oomph profiles for JDT have recently been created which makes it way easy to create a JDT development environment.

Just a question on Oomph - have you guys actually tried using it ?

I *love* the idea and intent behind Oomph but it is really really quirky to use. Big dialogs popping up with what I would consider
low-level-eclipse-lingo-talk. I wouldn't suggest we put this in any EPP package by default just yet.

And yes, I will try and get this written down in bugreports and raise with oomph team.

Performance testing of the platform is improving. We now have some results posted on the downloads page.

Got a link ?

Focus on user experience; make the user the first priority. Traditionally, adopters have been the first priority and it's been left to adopters to polish their Eclipse-based offering. We need to move some of that polishing into the Eclipse packages. This will require dedicated resources.


We need people with a strong interest in making the user experience great.

We need to take an holistic approach to the user experience. Most projects are--naturally--exclusively concerned with their own project's usability.

We've had some success with relatively little things like line numbers on by default and whitespace reduction. These are examples of little irritants that many of us don't quite understand, but still yield relatively large gains when we address them.

Think of EPP packages as end-user products. More extensive testing is required. We currently test to ensure that the features generally behave well together. Testing needs to extend to usability, key-binding and other such conflicts, etc.

Aside: Are Oomph packages the real SDKs?

What are these oomph packages ?

Should we try to tackle "big things"? Wayne brought up past complaints regarding complexity in the menus. Consensus was that it is probably not our best target. It's a very big problem that is hard/impossible to get right without making menus completely dynamic.

I think a simple improvement here would to actually get UI guidelines defined and be able to refer to them in bugzillas.

i.e. a plugin should not contribute a toplevel menu entry to context menu in the project explorer to enable it. That should be under the Configure menu.

A toplevel menu entry should not be contributed unless the menu entry is actually relevant for the selected element. i.e. Maven related entries should not be visibile if your project is not a maven project.

https://wiki.eclipse.org/User_Interface_Guidelines was last updated in 2007.

Any one know the status of ui-best-practices-working-group ? the mailing list still seem active ?

Consider building functionality that can identify misbehaving plug-ins and their corresponding root feature. This gives the user the opportunity to remove misbehaving features. Further, it informs the user of who to connect with to resolve issues (instead of just opening a bug against JDT). A UI might even provide a very easy way to remove the feature and links to the feature provider.

This sounds interesting but how would this be counted/detected ? by number of IStatus objects added to the log or examining caught stacktraces ?

Assemble a list of the most annoying bugs.

I think this would be interesting/good to get an attention to.

Does bugzilla not have a "show highest voted bugs"-dashboard somewhere that could be a good start for this ?

"Every Detail Matters" might be a better name for the "must not look goofy" effort.


We need to review the full experience: website > download > install > use > extend.


Based on what we talked about today, I've taken a stab at the (high-level) strategy:

Reduce friction for users (install, out-of-the-box experience, general usability)
Reduce friction for contributors (push Oomph as the way to realize a complete development environment)
Get Che building at Eclipse (and produce downloads/releases)
Actively recruit resources
Marketing focus on Developer Tools (Java developer tools in particular)

Lets discuss any concerns directly in the mailing list rather than wait for the next call.

The next call will be at 11am ET on Wednesday, December 17.

Okey - that date/time now written into my calendar so I don't miss it because it is not in my calendar.
I might miss it because I'm travelling that day - but i'll do my best.

/max http://about.me/maxandersen