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