This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Show advanced/reduced list of Features on Demand | ||
|---|---|---|---|
| Product: | platform | Reporter: | Jaroslav Tulach <jtulach> |
| Component: | Plugin Manager | Assignee: | Jaroslav Tulach <jtulach> |
| Status: | CLOSED FIXED | ||
| Severity: | blocker | CC: | dlipin, jrechtacek, mmirilovic, olangr, pjiricka |
| Priority: | P1 | ||
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
| Bug Depends on: | 162819, 162820, 163411, 163496, 163837, 163838 | ||
| Bug Blocks: | |||
| Attachments: |
Proposed look
Current implementation The patch |
||
Created attachment 80109 [details]
Proposed look
Created attachment 80112 [details]
Current implementation
Created attachment 80113 [details]
The patch
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. 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 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. 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. http://www.netbeans.org/issues/show_bug.cgi?id=162814 http://www.netbeans.org/issues/show_bug.cgi?id=162818 http://www.netbeans.org/issues/show_bug.cgi?id=162819 http://www.netbeans.org/issues/show_bug.cgi?id=162820 http://www.netbeans.org/issues/show_bug.cgi?id=162822 http://www.netbeans.org/issues/show_bug.cgi?id=162824 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) 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. v/c |
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