[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] New Update Manager UI : Your thoughts
- From: Peter Manahan <manahan@xxxxxxxxxx>
- Date: Mon, 11 Jun 2007 17:05:58 -0400
- Delivered-to: email@example.com
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
Good luck on your project.
equinox-dev-bounces@xxxxxxxxxxx wrote on 06/08/2007
> Prashant, I would suggest that you look at doing a UI on the new
> provisioning work rather than on the old Update Manager. As
> know, we have embarked on a rewrite of Update Manager. The UI
> that is just starting. The benefit is that the code you do is
> relevant and has a chance of really influencing or being included
> 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
> complicated things possible. Ironically the simpler they are,
> 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".
> many things to OK or agree to, too many clicks required. We
> flows that adapt to the situation. For example, if the user
> 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
> 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
> Java tooling, it should be possible/natural (but not required!) as
> matter of policy to drill into what they are about to get and see
> (if not modify it if allowed by the policy in charge).
> These are just some issues. I've not even touched on the first
> install story...
> We really need to think outside the box and not go for incremental
> changes to the current Update Manager UI.
> "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>
> [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.
> equinox-dev mailing list
> equinox-dev mailing list
Description: S/MIME Cryptographic Signature