Bug 162673 - Show advanced/reduced list of Features on Demand
Show advanced/reduced list of Features on Demand
Status: CLOSED FIXED
Product: platform
Classification: Unclassified
Component: Plugin Manager
6.x
All All
: P1 (vote)
: 6.x
Assigned To: Jaroslav Tulach
issues@platform
:
Depends on: 162819 162820 163411 163496 163837 163838
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-15 08:46 UTC by Jaroslav Tulach
Modified: 2009-05-13 07:23 UTC (History)
5 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Proposed look (102.59 KB, image/png)
2009-04-15 08:47 UTC, Jaroslav Tulach
Details
Current implementation (45.11 KB, image/png)
2009-04-15 09:17 UTC, Jaroslav Tulach
Details
The patch (19.28 KB, image/png)
2009-04-15 09:25 UTC, Jaroslav Tulach
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2009-04-15 08:46:33 UTC
As discused:

> >>> We are about to reach beta and I want our code to align with our
> >>> plans. Ergonomics UI spec[1] talks about interaction with welcome
> >>> screen. The screen is currently being reimplemented by Standa and
> >>> will be ready for beta. However, the UI spec[1] also prescribes
> >>> what shall appear when user invokes the "Activate Features..."
> >>> link. And here we have an inconsistency. Our current dialog is
> >>> not showing what has been designed.
> >>>
> >>> The problem is that the UI spec[1] suggests just high level items
> >>> to be visible (about 10), while in reality we bloat the user with
> >>> ~40 items. I feel responsible for this inconsistency and I want
> >>> to take the responsibility for fixing it. I see three options and
> >>> I'd be glad to hear your opinion that will help us select the
> >>> best solution.
> >>>
> >>> #1 - change the UI spec and accept ~40 items. I guess this is a
> >>> question for Ondřej, our UI representative, whether this is
> >>> acceptable.
> >>
> >> If we direct users to this dialog right from the welcome page,
> >> this is bad from users' perspective and impacts the initial UX. At
> >> this point, many users do not have enough knowledge about what
> >> individual modules they need for the way they use the IDE.
> >
> > +1
> >
> >>> #2 - really reduce the number of kits - the current list is kept
> >>> in http://wiki.netbeans.org/NB67VisiblePlugins
> >>>
> >>> I propose to reduce it to something like:
> >>> ||Codebase||Display name||Category||Cluster
> >>> |
> >>> |org.netbeans.modules.team.kit|Team|Base IDE|ide
> >>> |org.netbeans.modules.cnd.kit|C/C++|C/C++|cnd
> >>> |org.netbeans.modules.groovy.kit|Groovy and Grails|Groovy|groovy
> >>> |org.netbeans.modules.java.kit|Java|Java|java
> >>> |org.netbeans.modules.mobility.kit|Mobility|Mobility|mobility
> >>> |org.netbeans.modules.php.kit|PHP|PHP|php
> >>> |org.netbeans.modules.ruby.kit|Ruby and Rails|Ruby|ruby
> >>> |org.netbeans.modules.identity.kit|Identity|Web & Java EE|identity
> >>> |org.netbeans.modules.j2ee.kit|Java EE|Web & Java EE|enterprise
> >>
> >> This is IMO the ideal way to go. If there is a concern of loosing
> >> fine granularity for power users, we can provide a control element
> >> allowing to switch to fine-granularity view (see the "Advanced
> >> view" checkbox in the attached picture. Upon being checked, it
> >> would display all modules as they are presented now).
> >
> > note that this low granularity approach means that 'category'
> > column in plugin manager doesn't make much sense anymore.
> >
> > i like the 'advanced view' button
Comment 1 Jaroslav Tulach 2009-04-15 08:47:47 UTC
Created attachment 80109 [details]
Proposed look
Comment 2 Jaroslav Tulach 2009-04-15 09:17:54 UTC
Created attachment 80112 [details]
Current implementation
Comment 3 Jaroslav Tulach 2009-04-15 09:25:38 UTC
Created attachment 80113 [details]
The patch
Comment 4 Jaroslav Tulach 2009-04-15 09:31:48 UTC
Please review. I guess I got quite close to the proposed UI spec.

Surprisingly I needed no new API. I've just reused the features mode, which was already available, added a checkbox 
into the Installed panel to switch between the features/kits mode and that is all that needed to be changed in the 
autoupdate.ui module.

In ide.ergonomics I am adding new "features provider".

I'd rather see Dmitry to integrate the change, as it is mostly in his module. But as it also includes ide.ergonomics, 
I can commit it myself later today if you are OK with the patch.
Comment 5 Jiri Rechtacek 2009-04-15 10:20:38 UTC
I like a proposal to make bundles of modules bigger that current one (ccing Petr who driving this). Why not make a
bundle of modules by its target cluster?
JR01: I don't like an idea of Advance view. It's kind of workaround which returns over and over again. Autoupdate UI
should be as simple as possible and Advanced view might confusing to users.
JR02: Another possible UI trouble, inconsistent grading of modules in different tabs (Available vs. Install tab). It
could be better use as same grade (i.e. cluster) for all tabs.
JR03: In the proposed implementation a feature (e.g.J2EE) might return wrong state "I'm active" even thought some of its
modules are still in disable state. Need to fix it, a feature is active if and only if all of them modules are active.
Comment 6 Ondrej Langr 2009-04-15 11:02:57 UTC
Jarda, looks pretty good, I'm happy to see the coarse granularity there finally! 

One thing .. the green background of the "Activate" button is missing. Could you please fix that? We've had troubles
with users over-looking the Activate button. The core problem is, indeed, it's position, but integrating it with the
column of "uninstall" checkboxes is a little more complicated then it seems, so this should work as a short-term solution. 
Comment 7 Jaroslav Tulach 2009-04-15 13:13:55 UTC
Thanks for your reviews. Integrated as: ergonomics#895ce04678b2

Re. JR01 Advanced View: I kept the checkbox there, but it is not necessary to manipulate with it. As Tools/Plugins 
opens advanced mode, while Welcome screen shows the coarse one.

Re. JR02: Using feature view in updates would be much bigger change and I do not want to risk it.

Re. JR03: Thanks, you are right. I needed to change it in 9eafc61f761b

Re. green button: reported as issue 161847, I hope Dmitry will take care of it.
Comment 8 Petr Jiricka 2009-04-15 22:56:51 UTC
> Jarda, looks pretty good

Agreed!

> In ide.ergonomics I am adding new "features provider".

Why ide.ergonomics? I think this is a generally useful change, independent of the Ergonomics feature. Why not put it
closer to the core? Currently, there is an inconsistency between distributions that contain the ergonomics cluster and
those that do not.

> bundle of modules by its target cluster

Is a cluster really the unit of granularity? I think it should not be tied to clusters: clusters are an implementation
detail, and we have e.g. been talking about not showing the profiler in the list of plugins. So possibly profiler should
not be shown, even if it has its own cluster.

> JR01: I don't like an idea of Advance view.

I must say I disagree. For most users, the coarse grained view is appropriate, but for power users, Advanced view is useful.

Re. JR03 - is this really correct? I tried in ergonomics build 553, and I noticed that when I activate "Java EE", "Java"
is shown as deactivated (because some plugins from the Java category are not activated), which feels wrong.  
Comment 9 dlipin 2009-04-16 10:14:30 UTC
DL01: "Features on Demand" UC appears at the Settings tab. Does it make sense for the user to show it? "Edit" button 
does not work either.
DL02: By default, after ergonomics IDE starts, the Installed tab is in non-advanced mode and all the features are shown 
as inactive. This does not look good since it does not reflect the current state. At least one should be shown - 
like "Base funcitonality" or "Basic features" or "Base IDE" or similar.
DL03: Maybe worth not showing the category column at all with the "Advanced View" unchecked.
Comment 11 Marian Mirilovic 2009-04-16 15:41:21 UTC
ok, nice implementation ... from my point of view not in synch with rest of the dialog, but this is Ondrej's call ... 

I reported couple issues, so let's discuss particular problems there
http://www.netbeans.org/issues/buglist.cgi?issue_id=162818,162814,162819,162820,162822,162824,162850

I have couple questions here as well:
MM01: what will happen when user installs own module, do we want to show it in Basic view as well ?

MM02: for patches ... 
 - for 6.5: patching module means find the chain to all visible parents depending on this module, increment spec
versions + update Descriptions
 - for 6.7: all steps as for 6.5 + find kit which is displayed in Basic View & update description ... became more and
more complicated .... unless issue 141714 is implemented

MM03: when I remember it correctly Jano tried to avoid every usage of "Advanced View/Setting" UI component in the past,
argument was usually : "User doesn't want to go to Advanced ... it's like we divide users to losers and power users ...
they don't want to be losers by default." ... does it mean we are changing direction ?

MM04: expected to update Help pages as well, once we are done with implementation

MM05: we have 4 views on our "module system" / 3 of them visible for end-user and she needs to do some decision based on
those views, I would say it has to be difficult 
1. available from Installer
2. Installed panel - basic
3. Installed panel - advanced
4. (real list of all modules)
Comment 12 Petr Jiricka 2009-04-17 07:59:45 UTC
Re MM03: ...avoid every usage of "Advanced View/Setting" - would it be enough to rename the checkbox to e.g. "Detailed
View"? This would effectively eliminate the normal/power user caste system.

Re MM05: we have 4 views on our "module system" - I think #1 and #2 should be the same - the Basic view should show the
same thing as the installer.
Comment 13 Marian Mirilovic 2009-04-28 08:13:35 UTC
final implementation has to be tuned as has been discussed at meeting on Friday Apr 17, 2009 - added list of blockers
Comment 14 dlipin 2009-05-12 17:10:12 UTC
Jarda, should we close this issue as fixed now?
Comment 15 Jaroslav Tulach 2009-05-12 21:07:28 UTC
Closing as fixed, all blocking issues are resolved.
Comment 16 Marian Mirilovic 2009-05-13 07:23:52 UTC
v/c


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo