> A frequent complaint is that Eclipse contains too many things for usage, so many UI entries make usage more complicated and confusing. I can imagine that people doing some GMF stuff really don't want WTP at all because it introduce a lot of new menus, so a GMF user which is used to the Modeling package would spend more time to find the relevant menus for his work, and this is pretty annoying.
I agree to that, users already find the Eclipse IDE overloaded. If you have only one download with everything, Eclipse will feel more overloaded and bloated to users. Maybe http://www.eclipse.org/downloads/ can show only the 5 most popular distributions with a "MORE" button to show the other packages. I think it used to be that way in the past, but I may be wrong here. 2013/7/30 Mickael Istria <mist...@redhat.com> > On 07/30/2013 12:35 AM, Konstantin Komissarchik wrote: > > > Would user experience be better if there was only one Eclipse package on > the main download site that had pretty much everything that’s in the > aggregated repository? > > I really don't think so. > Packages are a good way to start which includes most available relevant > stuff for release-train. > > > **** > 1. *The package would be too large.* With modern download speeds, I > suspect most users would rather wait a few minutes longer for Eclipse to > download than spend time later trying to figure out how to install the > missing pieces. The disk space difference is also inconsequential these > days.**** > > A lot of people would feel better with something lighter to achieve the > same goal. If Eclipse goes to 1.5G to download whereas NetBeans is 200M, > people would probably try NetBeans first, and adopt it. > > > ** **2. *The users prefer to not include pieces in their installation > that they don’t use.* I can see that being the case for some advanced > Eclipse users, but I don’t believe this holds true across the user base. I > suspect that most users would rather spend time on their development > project than tuning their Eclipse installation. > > A frequent complaint is that Eclipse contains too many things for usage, > so many UI entries make usage more complicated and confusing. I can imagine > that people doing some GMF stuff really don't want WTP at all because it > introduce a lot of new menus, so a GMF user which is used to the Modeling > package would spend more time to find the relevant menus for his work, and > this is pretty annoying. > > > **** > > ** **3. *Too many plugins in one installation leads to poor user > experience.* If there are problems like that, we should be identifying > and fixing them.**** > > Eclipse is very heterogeneous in term of quality and ergonomics. That's > something I'm afraid that can't be fixed easily because of the community > being heterogeneous itself. Just hoping we increase and unify the usage > experience for all projects in the release train seems totally unachievable. > > ** **Thoughts?** ** > > Although people complain about installation taking some time, it's a > yearly effort. Having a single package with everything installed introduce > a lot of noise to end-user which can be very annoying and reduce > productivity every day. I really think that good IDEs are not the ones that > do everything, but rather the ones that do correctly what we want to do. > Packages are not-that-bad, and it appears that most of them already have > an interesting number of downloads, so they are actually useful to > end-users. I don't see any indicator saying that they are bad for adoption > of Eclipse. > > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> > My blog <http://mickaelistria.wordpress.com> - My > Tweets<http://twitter.com/mickaelistria> > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > >
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
