> >>> We are about to reach beta and I want our code to align with our
> >>> plans. Ergonomics UI spec talks about interaction with welcome
> >>> screen. The screen is currently being reimplemented by Standa and
> >>> will be ready for beta. However, the UI spec 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 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
Created attachment 80109 [details]
Created attachment 80112 [details]
Created attachment 80113 [details]
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
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.
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.
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.
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.
> Jarda, looks pretty good
> 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.
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.
btw, Marian filed a number of issues on the current implementation.
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
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)
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.
final implementation has to be tuned as has been discussed at meeting on Friday Apr 17, 2009 - added list of blockers
Jarda, should we close this issue as fixed now?
Closing as fixed, all blocking issues are resolved.