Re: [platform-vision] Minutes from December 3/2014

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Hi Max, you are probably thinking of the
original Oomph which is a "workspace setup wizard" for plugin
developers. Eike is working on a brand new native installer for Eclipse
that is using some of the Oomph underlying technology, but with completely
different UI. This is an installer that aims at a novice user. You download
a small installer, it pops up and asks which EPP package you want, and
it installs that EPP package and is then out of the picture. This has sometimes
been called the "Oomph installer", which is probably different
from what you have seen.

For performance tests, go to any Eclipse
platform integration build download page, and there is a "performance
test results" link right near the top of the page. It is still a work
in progress - it is Linux only, and is missing the graphical summaries.
Those pieces are coming soon. Here is a link:

http://download.eclipse.org/eclipse/downloads/drops4/I20141202-0800/performance.php

John




From:      
 "Max Rydahl Andersen"
<manderse@xxxxxxxxxx>
To:      
 "For discussion
regarding the future of the platform" <platform-vision@xxxxxxxxxxx>,

Date:      
 12/04/2014 03:41 AM
Subject:    
   Re: [platform-vision]
Minutes from December 3/2014
Sent by:    
   platform-vision-bounces@xxxxxxxxxxx

---

> 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.

+100.

> 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.

+1

> 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
_______________________________________________
platform-vision mailing list
platform-vision@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-vision