Community
Participate
Working Groups
Eclipse 3.4M6 I20080330 I would like to see an option where you have an eclipse/install folder that actually installs updates into a base eclipse system. As it is now, to get the base system to upgrade it requires going through the Software Updates and installing the features through there instead of using the dropins folder in eclipse/dropins for the installation. See bug 224243 for original comment.
Yes, Yes, Yes! I was about to enter the same request -- mine was a bit more ambitious. Forgive bluntness below, but I was just at a conference with potential and current end users for my open source project and the number one issue was installation -- the very first experience they have! The main target user for my tools are smart science types with minimal programming skills and a long memory and consequent low tolerance for frustration. A typical comment was, "can't you just provide a complete application for us to use"? Well of course I could, but that would mean building targets for all platforms, testing them and then serving all 250+ MB to each user but I'm half considering it. The dropins folder _seriously_ improves situation, but then you lose all of the nice management features. For now, I am going to need to maintain two install guides, one for dropins and one for "serious users" :) for plugin installation. Forgive bluntness, but a truly user focussed tool does not require 10 screenshots to explain how to add functionality. The process for en-users should be exactly equivalent to OS (well, maybe not Vista) install process: 1. User downloads software. 2. User drags software to appropriate folder. 3. User uses software. (Perhaps installed perspective is opened by default.) 4. User gets _by default_ a message when software is updated - "new versions are available.." It seems that with the fine work in p2, we are actually not very far from that ideal. Accomplishing it would do wonders for user acceptance from all of us out here making end-user tools.
Mike, try enabling the automatic check for updates for your users. This will give them a nice popup that they should update. It can even dl the bytes before prompting. Also know that if you are writing an rcp app, then p2 is modular enough to allow you to check for updates at any point in time without bringing up a UI. In short I think you should find what you want, or close enough. One thing you should definitely strive to avoid is telling ppl to put things in the dropins, this is the worst for the user.
Also in the future, we would like to be able to attach policies to repositories (on the user side) that would say which kind of behavior to adopt wrt the content available in the repo. For example, never consider for update, always install everything, etc.
Pascal, I appreciate the point about auto updates. For 4) I was just suggesting that for the end user behavior would be closer to OS expectations if this was on by default. Its not really a biggie and I agree that the updating mechanism is much better for p2. Still, I'm not sure that it is even possible?, but for a plugin/feature to turn on the auto download feature this would probably be bad manners. :) Anyway, unless I am missing something important, "I think you should find what you want, or close enough." I haven't. :) My use case involves users who download a standard Eclipse Distro (IDE for Software Architects..) and then install my plugins. They are really only (initially) interested in running my software, but of course there are all kinds of reasons to use the standard distros instead of building custom ones. The problem is that the very first thing they have to do after starting Eclipse is navigate to an obscure menu and go through a number of steps, including entering URLs, etc.. This might not seem like a major step to professional Eclipse users, but to a first time (non-Eclipse) user it makes the whole process less elegant, more confusing and prone to users. Sometime it is very hard for us to see the cognitive dissonance of this sort of thing for the average user. The process of dragging a file into one place is much more natural for users; it maps to their expectations, and they don't have to learn a new set of concepts. I agree that dropins is not a great option, but when I polled users who had tried p2 if they would rather just drop a file set into a directory I got a very strong positive response, and my goal is to give users the shortest and simplest path to installation with minimal to zero opportunities for frustration. If there were a default folder for Eclipse distro that took in some kind of bundle, took hints from the bundle to get plugin sites, and installed the bundle properly into Eclipse, that would solve the issue
(In reply to comment #3) > Also in the future, we would like to be able to attach policies to repositories > (on the user side) that would say which kind of behavior to adopt wrt the > content available in the repo. For example, never consider for update, always > install everything, etc. > Hmm, if there were someway to enable this behavior transparently, would that perhaps accomplish my goal? Another possibility that would achieve same goal is to provide a tool extending Admin UI that would allow the creation of an End-User agent. This agent would grab the latest distro, grab plugins from pre-specified sites, unpack the distro, install the plugins and launch Eclipse transparently. I'm not familiar with the Admin UI, but from my reading of the current page this wouldn't be possible -- the end user would have to install the end user ui, make changes to the profile, and then still install using the update manager..?
OK, perhaps the Installer will do the trick. Things are moving so fast its making my head swim. http://wiki.eclipse.org/Equinox_p2_Installer
for initial user expereience issues you might also consider a Welcome page that tells people how to get more funciton and cheatsheets that guide them through the process. You can also implement drag and drop function for installing stuff into your app. all you really need is a drop zone and the provisioning code under the covers. See the director.app for examples of how to actually install stuff with code.
Miles I can hear two problems: - one is about the initial installation that still requires too many steps, which is why you want something simplified to be integrated into the SDK - second about the number of steps involved to udpate. Here are the things that we want to work on in the future: - ability to just d&d a content.xml file - ability to click on a webpage and trigger the install in eclipse - implement something like what is suggested in the initial bug >The dropins folder _seriously_ improves situation, but then you lose all of the nice management features. Could you expand a bit what you mean? Overall we are in violent agreement :)
Pascal, you got it. Basically at this point I just wanted to see that folks on p2 are feeling my pain. ;) I can understand that you need to get the grounding infrastructure in place before extending it. But if I was Eclipse god I would otherwise put this ahead of every other platform feature as this is the number one barrier to acceptance, IMHO. (Right before OS X for Cocoa...) I do feel strongly that my use case will become more and more common, and that is a good thing. e.g. Users who need the full set of SDK capabilities but don't know it. :) I'm sure I'm not the only one who wants to offer folks visual or DSL tools that smoothly and naturally transition from a point and click world to the full set of functionality. > - one is about the initial installation that still requires too many steps, which is why you want something simplified to be integrated into the SDK > - second about the number of steps involved to update. Right, and one is by far the most important. If I can get past that first hurdle and show the users that they are getting something that is really valuable, they will then be willing to deal with a few extra steps down the line. > Here are the things that we want to work on in the future: > - ability to just d&d a content.xml file > - ability to click on a webpage and trigger the install in eclipse > - implement something like what is suggested in the initial bug Yep. I like 1 best actually, as then -- if I am understanding correctly -- you can provide users a single unchanging content.xml file that adds the update site and grabs the plugins transparently. That would avoid having to package a separate .zip file for each build. 3) does seem a little more full proof as for example when network issues intervene, but 1) matches user experience with OS update managers. 2) would be really nice when your user target is less sophisticated but has an Eclipse install. > >The dropins folder _seriously_ improves situation, but then you lose all of the nice management features. > Could you expand a bit what you mean? I just mean that when you use dropins, users then can't take advantage of auto updates, change update sites, find out where things came from, etc..
(In reply to comment #7) > for initial user expereience issues you might also consider a Welcome page that.. Jeff, I appreciate the suggestions though they don't address immediate issue which is bootstrapping issue -- UE *before* they get my code. :)
Sorry for all o the responses, but if p2 wants a feature request on any of #8 I'd be happy to write it up. :)
Feel free to open enhancement requests (with a back link to this bug for context), of course with patches ;-). Again thanks for your feedback. These types usability problems were on the 1.0 list however we did not get to it.
I don't think any additional complexity that would come from this can be properly managed and maintained.
