Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] New Update Manager UI : Your thoughts


Many of the current quirks around the update manager Jeff mentions were introduced to have it function as an update mechanism for commericial products (ie thats why the license acceptance is there as the lawyers absolutely mandated it). The nesting of features was added in order to facilitate a single point of "controlled" update to protect the "pristine" environment of the product being updated.  The policy files were added to prevent updates to plugins from eclipse.org as well as to redirect updates to local mirror sites.  It was putting a square peg in a round hole trying to get all those productization content into update manager. We eventually stopped using it for a slew of reasons but most of them around the fact that the products were more than eclipse and the current update manager isn't an installer/updater,  it is basically an addon manager like the one firefox has.

So it would be useful to understand/define the intended role of  the new update manager UI as well before going down the same path it went previously.

Putting on my "what do I want as a commercial product hat" I would like the ability to choose whether or not to ship the Update UI with my product.   When products contain more than just eclipse  have the eclipse update UI and a separate update UI for the rest of the content that confuses people.

The main thing it  should do what every installer of eclipse content has to do (including the current update manager)  which is protect the user shooting themselves in the foot by creating an invalid/broken eclipse configuration. Typical users should never get into the situation where they have content not working.  Thats why there are all those checks in update manager about missing dependencies etc.

Good luck on your project.

Peter
equinox-dev-bounces@xxxxxxxxxxx wrote on 06/08/2007 09:21:20 PM:

>
> Prashant, I would suggest that you look at doing a UI on the new
> provisioning work rather than on the old Update Manager.  As you may
> know, we have embarked on a rewrite of Update Manager.  The UI for
> that is just starting.  The benefit is that the code you do is more
> relevant and has a chance of really influencing or being included in
> Eclipse.  The downside is that you will have to put up with some
> instability and lack of clarity etc inherent in early code bases.
>
> As for peeves etc, one of the things we really want to see is clean,
> easy to execute workflows.  Keep the simple things simple, make the
> complicated things possible.  Ironically the simpler they are, the
> less UI there is :-)  Provisioning is one of those things that
> people just don't want to deal with.  There are too many hard
> questions and normal users cannot assess the correctness or impact
> of the various answers.  Anything that improves the day to day
> workflows would be great.
>
> In Update Manager I think we went overboard in the "process".  Too
> many things to OK or agree to, too many clicks required.  We need
> flows that adapt to the situation.  For example, if the user is
> connected to trusted repos, why ask them about signing and licenses?
>
> Figuring out ways of categorizing and presenting the various
> installation options is another one.  Users are often overwhelmed
> with choices.  Much of the time they just want to say "get me 'the
> Java tooling'" or some such.
>
> There should be a smooth progression from the simple to the
> complicated.  For example, if someone says they want to instlal the
> Java tooling, it should be possible/natural (but not required!) as a
> matter of policy to drill into what they are about to get and see it
> (if not modify it if allowed by the policy in charge).
>
> These are just some issues.  I've not even touched on the first time
> install story...
>
> We really need to think outside the box and not go for incremental
> changes to the current Update Manager UI.
>
> Jeff
>
>

>
> "Prashant Deva" <prashant.deva@xxxxxxxxx>
> Sent by: equinox-dev-bounces@xxxxxxxxxxx

> 06/08/2007 08:44 PM
>
> Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

>
> To

>
> equinox-dev@xxxxxxxxxxx

>
> cc

>
> Subject

>
> [equinox-dev] New Update Manager UI : Your thoughts

>
>
>
>
> Hi everyone,
>  I will be doing the new update manager UI for eclipse as part of google soc.
>
> Before I come up with a prototype, I would like to get some feedback
> from you guys.
>
> It would be great if you all could list your personal pet peeves
> with the current update manager ui of eclipse
> and also if you could list down any functionality that you would
> like to see in the new ui.
>
>
> Thanks,
> Prashant_______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


Back to the top