I am not sure about the disaster thing really. As we are also having the discussion about other IDE's look at IntelliJ just for a second (http://www.jetbrains.com/idea/download/index.html)
They have 2 downloads. One that is free and one that is everything. That makes it at least very simple for users of the IDE. Even if you dont agree on that, 90 % of the downloads are from 4 pre-packed IDEs for Eclipse. How about an "Ultimate" edition for Eclipse. Why do I have to make a choice whether I want to develop J2EE, Modelling or RCP or be a Tester ? We all know that you can do multiple things with one IDE at the same time. The download page makes us think we have to make a choice. Von: Pascal Rapicault <pas...@rapicault.net<mailto:pas...@rapicault.net>> Antworten an: Cross issues <cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>> Datum: Dienstag, 30. Juli 2013 14:05 An: Cross issues <cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>> Betreff: Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse? An all in one IDE is a recipe for disaster and will contribute to even more FUD around Eclipse. Also I fail to see which improvements to the user experience can be done since we would not have a specific persona to focus on. Instead I think we should focus on improving the integrations between the tools that are known to be installed together (yes ideally we would need user input on this). IMO this will have a better chance of success since it is much more focused and would also involve less ppl. On 07/30/2013 12:13 PM, Konstantin Komissarchik wrote: > so they are actually useful to end-users. Actually, we have no evidence that users find packages useful. They download them because what else is there for them to do. Then if they are experienced, they know what’s included and how to install the missing pieces. If not, they thrash on forums wondering why Eclipse for Java Developers doesn’t come with an XML editor. We can certainly measure the value of maintaining a menagerie of packages. All it would take is to put out an everything package alongside the existing ones and compare download numbers. While it wouldn’t happen overnight, a single Eclipse IDE would have a unifying effect on the community, ultimately leading, I believe, to higher overall quality. - Konstantin From: cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org> [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mickael Istria Sent: Tuesday, July 30, 2013 2:46 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse? 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<mailto:cross-project-issues-dev@eclipse.org>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ------------------------------------------------------------- compeople AG Untermainanlage 8 60329 Frankfurt/Main fon: +49 (0) 69 / 27 22 18 0 fax: +49 (0) 69 / 27 22 18 22 web: www.compeople.de<http://www.compeople.de/> Vorstand: Jürgen Wiesmaier Aufsichtsratsvorsitzender: Christian Glanz Sitz der Gesellschaft: Frankfurt/Main Handelsregister Frankfurt HRB 56759 USt-IdNr. DE207665352 -------------------------------------------------------------
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
