[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ide-dev] Inconsistent Eclipse user experience
|
In EasyEclipse, we have been looking in minimizing the number of entries
by reorganizing the content of contextual menus into coarser
"cagetories" related to the tasks the user would want to do. For example
in the context of an editor, the type of operations you are trying to do
are: "navigate the code" (open selected type, find references, etc.)/
"edit" (copy / paste / format content) / "refactor" / "SCM".
For example I don't think that having a run and debug button in this
context really make sense.
Of course, having these higher level categories is not ideal for the
discoverability of functionality but at least it avoids the case of
scrollbars in the menus like I have seen (btw, some stats posted by Max
back in January reveal that the average screen resolution is something
like 1366x768.). To solve this I have been thinking about adding a
search capability in the menus (IDEA has this for selected menus) which
would help the user new to the IDE to find the desired entry and then
learn the paths where it is located so it can go there with his mouse
the next time. Of course there is the quick search but this one would be
scoped. The downside is that the menu widgets would not be native.
At this point I have not found any magical mechanism to do the cleanup
of menus. It is just sweat and blood :) In general people are writing
their plug-ins in complete isolation and having another button or menu
entry is not an issue. It may be good if there was a way for them to
realize where their menu contribs appear as they often have entries
ending up shown in unexpected places thanks to the magic of IAdaptable.
The other thing would be to provide clear examples of how to contribute
actions because it would greatly help people rather than having them
copy / paste / tweak XML.
On 11/03/2014 3:22 PM, Miles Parker wrote:
Eric, that’s a great overview of current approaches. I think the common denominators is they all rely on individual plugins being good citizens, and of course noone but {insert one’s own project name here} is. I am probably one of the minority of IDE users who actually use the Customize Perspective to reduce clutter. (If you didn’t want to see all of my project's menu items littering everything, why did you install it?) And to be fair to all of us platform consumers, some of those mechanisms are complex to implement.
In short....even with all these abilities in place we're still where we're at...perhaps a new approach is needed ?
Yes! IMO, the overarching goal is simple: dramatically reduce the mouse-click count and mouse distance travelled to perform common operations. There are (at least) two parts to this:
I. We need to identify *what* is most important, using:
a) a mode that is more dynamic and requires less user intervention, but at the same time exactly *isn’t* the random menu hiding that Microsoft did in the late 90s to try to automagically reduce their bloat,
AND/OR
b) a mechanism to allow packagers to bless certain functions, overriding the plugin opt-in mechanism.
II. We need to figure out *how* to expose those most important things:
a) your could simply promote the items that fit (I) (so for example they show up at the top of the context menu.
b) It might be worth thinking about entirely new affordances (gestures? "Instant hovers" like w/ Graffit? I did something like this with butterflyzer where you get a quick popup when you have a command key held down) to provide access to commonly used functions.
I'll outline some ideas for a possible approach in a separate email...;-),
I look forward to that. :)
On Mar 11, 2014, at 11:47 AM, Eric Moffatt <emoffatt@xxxxxxxxxx> wrote:
Miles, I think you've pretty well nailed the base issue; our UI is an aggregation of many different bundles, each with their own extensions but with no finer-grained control over what is 'important' to a particular role. I'm very glad that 'bloat control' has finally reached the level where the community is *actively* looking for a mechanism to get a handle on this...
We've actually implemented a number of approaches to mitigate this over the years:
Perspectives: Tries to 'bundle' the views appropriate to a work flow within that perspective. The problem here is that it's not enforced (i.e. you see *all* views in the ShowView dialog), can't prevent other bundles from 'polluting' a given perspective with their own views (including adding them to the 'shortcuts', making them 'first class' citizens of the perspective. This also lead to the 'progressive discovery' approach..."Would you like to open the Debug Perspective ?" which is OK but represents a single hard-coded path to a particular perspective.
ActionSets: An attempt to limit the number of visible command elements (mostly menu items / TB's) by 'chunking' them into groups to which common visibility behaviors are applied. Aside from being the bane of our existence these also suffer from the lack of fine grained support.
Activities: Another attempt to limit the visibility of various UI elements...apparently not used much due to complexities in defining the 'Activity' definition.
There's also been some work on a lower level approach, removing extensions 'on the fly'; see 'https://wiki.eclipse.org/Product_Customization' and 'https://wiki.eclipse.org/Equinox_Transforms'. Aside from the issues of having to hand-craft the XSLT I think that this is near to the correct approach (i.e. removing the complexity in the UI *before* the application starts). Again this also suffers from being less than flexible after defined (how do I as a user get something back if it's been 'filtered' ?).
Finally, of course, there are the EPP packages...
In short....even with all these abilities in place we're still where we're at...perhaps a new approach is needed ?
I'll outline some ideas for a possible approach in a separate email...;-),
Eric
<graycol.gif>Miles Parker ---03/10/2014 02:00:40 PM---Right. This is what I think of as the “right-click” problem. Supposedly the Eclipse context menu is
<ecblank.gif>
From:
<ecblank.gif>
Miles Parker <miles.parker@xxxxxxxxxxx>
<ecblank.gif>
To:
<ecblank.gif>
Discussions about the IDE <ide-dev@xxxxxxxxxxx>,
<ecblank.gif>
Date:
<ecblank.gif>
03/10/2014 02:00 PM
<ecblank.gif>
Subject:
<ecblank.gif>
Re: [ide-dev] Inconsistent Eclipse user experience
<ecblank.gif>
Sent by:
<ecblank.gif>
ide-dev-bounces@xxxxxxxxxxx
Right. This is what I think of as the “right-click” problem. Supposedly the Eclipse context menu is “contextualized”, but that when you right click on an editor and there are 37 items on the menu, it’s clear the context isn’t refined enough! When “Paste” is the 15th item on that list, it’s evidence for even the most casual user noone is in a position to force a disciplined high-level design for the overall product. That’s why efforts like EasyEclipse are important. You need someone who cares about the typical end user — (and who makes money -- maybe not 1% money, but *some* money -- by caring) — to be able to make the hard choices about what get’s in by default and what doesn’t. But even with that effort, without providing tools to support deeper contextualization, we lose the advantage as soon as people start using plugin-ins, which is after all one of the strongest features of the Eclipse ecosystem.
The basic dilemma of Ux design is the same design conundrum as with all technologies from babylon on — how to give maximum information and control with minimum effort and cognitive load? One answer is to contextualize (the most extreme example being the original iPod scroll wheel). Mylyn has gone a long way toward addressing the issue of content-based contextualization, but the community hasn't effectively addressed the issue of role or activity-based contextualization. The closest thing we have for that in Eclipse-land is Perspectives and that’s far too coarse grained and cognitively disruptive. But the great thing about Eclipse is that all of the underlying technologies to make a truly contextualized experience are all there. It’s “just” a matter of developing some approaches (and metaphors?) that support transparent, fluid and user-guided role contextualization and filtering UI and execution elements based on that.
On Mar 9, 2014, at 8:58 PM, Andrew Eisenberg <andrew@xxxxxxxxxxxx> wrote:
I wouldn't be surprised if uninstalling Groovy-Eclipse could address some of his problems, but the post shows a larger problem with the IDE work we are (or at least I am) doing. Too often features are implemented so that a handful of vocal users are happy, but the silent 99% don't have their needs fully met.
As a simple example, consider this statement: "Sometimes, selecting a launch configuration with arrow keys and hitting enter twice to run it works. Sometimes, it runs a previous launch configuration. Using the mouse is fully reliable but less efficient." I'm pretty sure it's because sometimes he has the editor active and the expected thing runs, but sometimes some other view is active. This makes sense to power users and the behavior is consistent with the rest of Eclipse, but it is probably non-intuitive for new users.
The problem is that determining and implementing the most intuitive workflow for new users that doesn't annoy power users is not a cheap or easy process. It involves something like user studies and active engagement with all of the community (not just the 1% (no, not *that* 1%)). I admit that this is something that I have failed to do enough of.
On Sat, Mar 8, 2014 at 11:32 PM, Max Rydahl Andersen <manderse@xxxxxxxxxx> wrote:
I think it's worth noticing he mentions groovy eclipse which to make it work "hot patches" the JDT.
Pretty sure he should try uninstall groovy eclipse and see if that doesn't improve his eclipse experience.
This shows how great it would be if jdt could be better at allowing other javavm based languages to integrate better so tricks like hot patching aren't needed.
/max (sent from my phone)
On 09/03/2014, at 06.02, Doug Schaefer <dschaefer@xxxxxxx> wrote:
Interesting post. I'd love if we could find some way to enforce consistency in the IDE. There's lots of things we can override. I wonder if it's enough. Food for thought.
I love the comparison with netbeans and intellij. Eclipse has so much to offer. We just need to find a way to manage the product as a whole to make it great.
Thanks for this Stephan.
Sent from my BlackBerry 10 smartphone on the Rogers network.
Original Message
From: Stephan Herrmann
Sent: Saturday, March 8, 2014 8:35 PM
To: ide-dev@xxxxxxxxxxx
Reply To: Discussions about the IDE
Subject: Re: [ide-dev] Inconsistent Eclipse user experience
Have you guys seen this:
http://www.eclipse.org/forums/index.php/mv/msg/668948/1267143/#msg_1267143
Sounds like another client for this group :)
best,
Stephan
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev
