[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ide-dev] Ctrl-1 driven development
|
> As to the rest… If installable components were easy to discover and user didn’t mind doing this, we wouldn’t see comments about Eclipse missing basic functionality, like XML support.
I don't think we disagree on that one either, maybe just a different point of view. My point is that installing new features is a standard procedure and it should not be something we should try to avoid with more "complete" EPP packages to show our users that what we ship is complete. Instead of avoiding installing, a better approach would be to make it as easy as possible up to the point where it is almost invisible so that the user does not need to bother to think about installing new features that he may need but rather the features are just there at the time he starts using them. Think of it as an equivalent of OSGi's "lazy loading" - "lazy installing" -- it is invisible to the end user, you don't know when it happens and how it is done exactly but it works and let's you get the job done. What Torkild proposed in this thread previously seems like a good way to achieve that. I think that Eclipse does provide a complete solution, we just need to make it act as one rather than as several semi-complete packages.
> When our competition ships a complete product and we ship a box of parts with a “some assembly required” sticker, we don’t position Eclipse in a good light. Rather like in the car world, we have a relatively small community of folks who like to tinker with their IDE, but the majority of people just want to get the job done.
As you mentioned, components are not easy to discover which means this is a problem with discoverability rather than with completeness of what we ship. EPP packages do not address the discoverability issue but the perceived completeness of what Eclipse ships issue and even for that issue it's not the best solution.
Thanks,
Szymon
Konstantin Komissarchik ---2015-10-21 18:10:46---I agree with you on one point… EPP should be installing everything as a top-level feature so that up
From: Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx>
To: Szymon Ptaszkiewicz/Poland/Contr/IBM@IBMPL, Discussions about the IDE <ide-dev@xxxxxxxxxxx>
Date: 2015-10-21 18:10
Subject: RE: [ide-dev] Ctrl-1 driven development
I agree with you on one point… EPP should be installing everything as a top-level feature so that updates work properly. As to the rest… If installable components were easy to discover and user didn’t mind doing this, we wouldn’t see comments about Eclipse missing basic functionality, like XML support. When our competition ships a complete product and we ship a box of parts with a “some assembly required” sticker, we don’t position Eclipse in a good light. Rather like in the car world, we have a relatively small community of folks who like to tinker with their IDE, but the majority of people just want to get the job done. Thanks, - Konstantin
From: Szymon Ptaszkiewicz
Sent: Wednesday, October 21, 2015 4:45 AM
To: Discussions about the IDE
Subject: Re: [ide-dev] Ctrl-1 driven development > because Eclipse.org was pushing the "lowest common denominator"
Well, to me that was a tradeoff.
One significant advantage of using the "lowest common denominator" is that whatever you install on top of it, it is installed as the root feature which means "Check for updates" works as one might expect. And in order to install anything you need to go to Help > Install New Software... and then browse the list to find what you need. You achieve 2 goals: user has to browse the list manually so he gets familiar with what he can find there and "Check for updates" works.
In case of EPP packages, we try to be smart and collect features that certain group of people may need, but as shown in this discussion this is not always easy and there are different opinions whether functionality X should be part of package Y. So we achieve 3 goals: packages don't meet users' needs (or at least are controversial), "Check for updates" does not work and we have endless discussions how to provide better packages and possibly release it more frequently to mitigate the lack of "Check for updates".
The tradeoff is that we replaced flexibility of a thin base package (be it Eclipse SDK or a thin EPP package) with predefined suitability of EPP packages which is not always really suitable. In order to explain the difference to a regular user, you need to explain what root features are there and this is an advanced topic even for professionals and experienced Eclipse users. To me, it is better to give a thin base and then let the user choose what he needs to install while at the same time he learns what other cool features are there, rather than give them what we think he may want and either way expect him to find and install additional stuff. Explaining how to install a new feature is a basic discussion and can be done with any user even newcomer, but explaining why some features benefit from "Check for updates" and some not is a lot more difficult.
To summarize, I'm not sure if we are "recovering" in the right direction.
Szymon
"Max Rydahl Andersen" ---2015-10-21 12:35:43---On 20 Oct 2015, at 18:57, Wayne Beaton wrote: > FWIW, I regard the Eclipse SDK as the output of the
From: "Max Rydahl Andersen" <manderse@xxxxxxxxxx>
To: "Discussions about the IDE" <ide-dev@xxxxxxxxxxx>
Date: 2015-10-21 12:35
Subject: Re: [ide-dev] Ctrl-1 driven development
Sent by: ide-dev-bounces@xxxxxxxxxxx
On 20 Oct 2015, at 18:57, Wayne Beaton wrote:
> FWIW, I regard the Eclipse SDK as the output of the Eclipse project,
> not one of our front-line "consumer" downloads.
exactly and it is only recently (last year?) we finally got the download
page to not serve the "basic" package as default.
I think alot of users missed things like code recommenders, maven and
xml for years purely because Eclipse.org was pushing
the "lowest common denominator".
It will take some time to 'recover' from this.
/max
http://about.me/maxandersen
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ide-dev
