Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] Inconsistent Eclipse user experience

Pascal, this seems like a physical solution similar to my proposal...divide and conquer. We're trying to do the same thing except this approach would require very significant bundle reorganization to accomplish which I see as a non-starter. Also I'm guessing that there's a non-trivial amount of overhead associated with a bundle (which is why we bundle things no ? :-).

Note that in the end we still end up with either approach in a position where,as you say, we will still need some tooling to help users *decide* what they want (or analytics to tell us). One of the positives of my proposal is that since the set of ui contributions is file-based (using the *same* base install) it's far easier to iterate on. Folks could even contribute their own extension filter file sets through the market...

BTW, the tooling equivalent to what you're currently sweating blood over is to allow the tree showing the UI Contributions to support Drag and Drop and have the resulting registry reader respect the defined order over simply ordering them in bundle order (or even order within a bundle).

Eric

Inactive hide details for Pascal Rapicault ---03/11/2014 04:53:24 PM---Along the same line, another solution would be to split Pascal Rapicault ---03/11/2014 04:53:24 PM---Along the same line, another solution would be to split all the  contributions done through XML into


    From:

Pascal Rapicault <pascal@xxxxxxxxxxxxx>

    To:

Discussions about the IDE <ide-dev@xxxxxxxxxxx>,

    Date:

03/11/2014 04:53 PM

    Subject:

Re: [ide-dev] Inconsistent Eclipse user experience

    Sent by:

ide-dev-bounces@xxxxxxxxxxx




Along the same line, another solution would be to split all the contributions done through XML into their separate bundle. For example if I have a UI plugin with a view and one menu contribution, then I would have 3 bundles. One with the code, one for the XML of the view and another one for the menu contribution (this could probably be automated at build time).
Then someone trying to compose an IDE would just have to pick and chose the right bundles to include.
There would be a runtime overhead because of the number of bundles that would result from this split but I'm pretty sure that this becomes irrelevant pasted the first run because of the caching . lazy loading mechanism in Equinox.

Now these mechanisms are fine but they are means to achieve Integration but they don't do it automatically and it is unclear if real users would be willing to do it.

Pascal

On 11/03/2014 4:10 PM, Eric Moffatt wrote:

    OK...here's my take on an approach that tries to live in the reality of our current state. Take everything below with a grain of salt and bear with me if I'm off the mark on some of the packaging details...

    Right now we define an EPP by aggregating a set of Features, each specifying the bundles required to support it. Each bundle may contain any number of contributions to the UI *all* of which get picked up with the bundle (the key issue with our bloat IMO). The XSLT approach was an attempt to help here but I don't think it had the necessary tooling support to succeed (see below).


    Bundle structures are pretty well fixed in place, nobody's got the time to go over them all and there's really no 'proper' way to split them up based on their contributions anyway. We need a fine grained mechanism to deal with this without directly having to modify the existing bundles.


    What we need is a way to uniquely identify and filter out any given contribution (be it Menu[Item], KeyBinding, View, Editor, Perspective...). Let's say we have a file defining the filters (could even be an XLST file if appropriate) for a particular bundle. This means that we can now re-package the *same* bundle with different subsets of functionality, giving far greater flexibility to anyone wanting to package up certain capabilities but not others even when using the same bundle(s). A bundle's 'install' is now a tuple, the bundle itself and the file defining which UI contributions are to be exposed to the application when reading the registry.


    The sticking point here may well be that we need a way to uniquely identify those contributions we want from a particular bundle. Maybe it's better if the file identifies the ones that we *want* rather than the ones to filter out. The advantage of this approach is that any work needed to add ids to contributions would only have to be done for contributions that are 'in' EasyEclipse...for the tooling below I'm going to take some way to do this as a given (otherwise I think the exercise is doomed due to the amount of actual effort / coordination required)


    As far as the tooling goes what I see is something akin to the current Plug-in Registry view except that the tree being shown for a given bundle would be a 'checkbox' tree, allowing the product packager to directly select the contributions they want. Conversely a tree that given a 'product' (list of Features) could show all extensions for a given extension point. This has the added advantage that it would be able to show all the handlers / key bindings for a given Command under the command in the tree (meaning that if you uncheck the Command then all its handlers and bindings also get filtered (similarly for other related contributions such as EditorActions/ViewActions...).


    This is of course not a complete solution. It doesn't help much with preferences but surely each 'install' could also come with a pre-defined default preference definition. Note that we while it'd be great to also be able to filter out unwanted prefs we'd have to address the problems associated with the separately defined PreferencePages (which will still have UI for the preference). It also doesn't solve cases where some contributions are related in non-obvious ways (i.e. an editor whose implementation requires a particular view to be available...).


    A final thought (YAY!)....early on there was some discussion about providing an 'all in' install since download speeds have gone up and disk space is cheap. This approach could be extended upwards to include which features are to be included. Think of an update site called 'local' which simply removes the filter from the desired feature ( / bundle... ) from the filter, exposing the code that's already on your drive...


    Back to slides,
    Eric



    Inactive hide details for Eric Moffatt---03/11/2014
          02:50:01 PM---Miles, I think you've pretty well nailed the
          base issue; our Eric Moffatt---03/11/2014 02:50:01 PM---Miles, I think you've pretty well nailed the base issue; our UI is an aggregation of many different
      From: 

    Eric Moffatt/Ottawa/IBM@IBMCA
      To: 

    Discussions about the IDE
    <ide-dev@xxxxxxxxxxx>,
      Date: 

    03/11/2014 02:50 PM
      Subject: 

    Re: [ide-dev] Inconsistent Eclipse user experience
      Sent by: 

    ide-dev-bounces@xxxxxxxxxxx




    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



    Inactive hide details for Miles Parker ---03/10/2014
        02:00:40 PM---Right. This is what I think of as the
        “right-click” probleMiles 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
      From: 

    Miles Parker
    <miles.parker@xxxxxxxxxxx>
      To: 

    Discussions about the IDE
    <ide-dev@xxxxxxxxxxx>,
      Date: 

    03/10/2014 02:00 PM
      Subject: 

    Re: [ide-dev] Inconsistent Eclipse user experience
      Sent by: 

    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
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev


GIF image

GIF image


Back to the top