Bugzilla – Full Text Bug Listing
| Summary: | [plan item] Capabilities/Perspectives/Components | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jim des Rivieres <jeem> |
| Component: | UI | Assignee: | Kim Horne <eclipse> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P4 | CC: | aiproulx, champion, daniel_megert, darin.eclipse, dejan, eclipse, gunnar, jed.anderson, julianj, mfaraj, Michael.Valenta, michaelvanmeekeren, Mike_Wilson, mkomor, nikolaymetchev, pombredanne, some_guy_coding, Tod_Creasey, vimalvachhani, yharms |
| Version: | 3.1 | Keywords: | plan |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 49688, 71320, 84252, 84255, 84806, 87269, 117568 | ||
| Bug Blocks: | |||
|
Description
Jim des Rivieres
Kim, last release, the intro team developed a Role widget that became part of the Atlantic stack of products. Im not sure if you have seen it or are aware of it, but it is relavent to this defect. In fact, I believe it is the source of this defect. I will mention here what we have learned from this exercise because from your perspective, it gives us feedback about the usability of the capabilities' apis and what extra apis can be added to better suite the "Roles" concept used by Atlantic and that can be yused by many other products. Atlantic needed to use Categories to filter their UI from the huge contribution set that exists in the product. They used Categories (aka Capabilities) as "Roles" and they needed a way to expose these Roles to the user (especially the new user) in a nice way. The preference page that was shipped with SDK 3.0 did the job, but had some issues (from the user's perspective). Here is what the problems where: 1) the selection tree that was presented in the Capabilities preference page did not scale. In Atlantic, thay has quite a number of categories with many activities and you almost forgot what was at the top of the tree by the time you got to the bottom. There was no "expand all" or "collapse all" buttons. 2) enabling an activity that depended on another activity was confusing in the UI. The dependant activity was enabled but that was not shown to the user immediately. YOu had to reopen the preference page to see that new change. For the new user this was a mystery as to why this new activity was enabled. :-) Now, I see the preference page has addressed some of these issues. You now have enable all/ disable all button. great. Maybe collapse all, expand all is also good for scalability. The UI tree also now has logic to automatically select dependant activities. Great. What is still needed is the following: 1) an ICategory needs an icon associated with it. For the Atlantic Role widget, we had to create out own extension point that was used to bind an icon to a category. These icons where used in the welcome UI to display categories. 2) apis that allow the following: given a category, give me all categories that will be enabled/disabled if this category is enabled/disabled. For Atlantic, we needed to prompt the user with a list of categories (aka roles) that will be enabled if he enabled a certain category. This was a bit difficult with the current apis because I had to do the logic of taking the current category, looking at all its activities (and all there dependant activities) and figuring out given this set of newly enabled activities, what categories will be enabled. an api would be great. 3) apis that allow the following: given a activity, tell me whether or not I can disable this activity. Again, we needed to know this because if a user disabled a category we did NOT want to disable other categories under the hood. We did not even want to prompt the user. He does not need to know. So, we had to, given a list of activities from the category we wanted to disable, we had to figure out if there is any enabled category that had any of these activities enabled. if yes, then we did not disable this activity when disabling the category, because disabling this activity disabled another category and we did not want that. Again, an api would have made sense here. 4) the notion of advanced, intermediate or beginner Roles (aka categories). Atlantic used Categories for what they called Roles. A role is a "hat" that you put on when you want to start Eclipse. You might want to be a Java Developer today. Tomorrow, you start the workbench and you want to be a tester. They defined a large number of roles. This fits great with your notion of Categories. In fact, they are identical. Now here is the twist: they defined something on the line of Beginner J2EE developer, and Advanced J2EE developer. So they needed to introduce the notion of skill level into categories. They did that by defining two categories, but calling them the same name, but one beginner one advanced. If somehow you can incorporate that into the activity binding definition, meaning that I can bind an activity to a category, but tell you that this is only an advanced feature. Intro can use this notion and all the new user to seelct a Role and select a skill level too. Im doing this same work for the Eclipse SDK. If these apis are there, then the intro team will just use them. please let me know if I made sense in all of this... 2) A The concept of Some questions (more to come) : Would icons be useful for activities as well as categories? Points 2 and 3 COULD imply that categories have enabled state of their own. Is that what you'd like to see? I would have no objects to get/setEnabled on a category as long as their state was tightly coupled to the state of the categories child activities. I would really hate to see category state be an independant beast apart from activity state. Is there a way we could accomplish point 4 without explicitly using the concept of user level? Dare I say it... I'm gonna hit myself...but multidimensional categories indexed by string? (In reply to comment #2) > Some questions (more to come) : > Would icons be useful for activities as well as categories? It does make sense, but if its too much work, it might be overkill. Depending on what a UI wants to expose, icons for activities do make sense. In fact, we are thinking of exposing activities in the SDK welcome, only because the SDK simply defines two Catregories, so including activities scales. But in a product that has a lot of Categories, this does not make sense. You could still use activity icons in the Capabilities Pref page. > Points 2 and 3 COULD imply that categories have enabled state of their own.Is > that what you'd like to see? I would have no objects to get/setEnabled on a > category as long as their state was tightly coupled to the state of the > categories child activities. I would really hate to see category state be an > independant beast apart from activity state. If you had a simple boolean flag in mind for state, then there is a bit more to the story. The "state" that you talk about can be a boolean flag that is used for enablement of tha Category. For that, you simply use what you use today, that is: a Category is enabled because all its activities and dependant activities are enabled. Simple and quick. BUT there should also be the notion of "state" in addition to the above enablement. A Category can be in one of four states, enabled, enabled-locked, disabled, disabled-parent. Allow me to explain: 1) enabled: This is a Category that is enabled because all because all its activities and dependant activities are enabled. ie: its getEnabled() flag is true. This is 3.0 logic. 2) enable-locked: This is a category Foo that is locked because it can not be disabled. It can not be disabled because there is another enabled category BigFoo out there that is enabled forcing this category to stay enabled. That is all activities and dependant activities of Foo are a subset of all ativities and dependant activities of BigFoo. 3) disabled: Category disabled because at least one activity or dependant activity is disabled. Again, same logic as 3.0. 4) disabled-parent: Category (BigFoo) disabled because at least one activity or dependant activity is disabled. BUT if this category is enabled, the it will enable at least one more category with it. This is why I called it a parent. Meaning, all activities and dependant activities of this BigFoo are a superset of all ativities and dependant activities of some Foo category. These states can be used by a UI to prompt the user for info. Eg: if I try to disable a category that is in enabled-locked state, Im told sorry, cant be done, because some other category BigFoo is still enabled. Or if I try to enable a category that is in disabled-parent state, Im told hey, do you know that you will enable Foo also? With the above state logic, a category can be asked about its state and can be asked about dependant categories. Hence 2) and 3) api requests below. > Is there a way we could accomplish point 4 without explicitly using the concept > of user level? Dare I say it... I'm gonna hit myself...but multidimensional > categories indexed by string? Skil level is something that we know is needed. People out there have worked around this by using two categories that are the same. Welcome can use it because a lot of product out there as users about there skill level before they customise the UI to a given task. So all Im saying is that its a good thing to have. Now with that said, Im not sure what you mean by : "Dare I say it... I'm gonna hit myself...but multidimensional categories indexed by string? " are you talking implementation wise? (In reply to comment #3) > there should also be the notion of "state" [...] > 1) enabled > 2) enable-locked: > 3) disabled > 4) disabled-parent Please add a fifth state: 5) disabled-locked: This capability can't be activated neither with the preferences dialog nor by any trigger point. These capabilities should not be displayed in any open preferences/view dialog. We need a mechanism to deliver our applications with various optional functionalities (which can be paid and activated later) while still using only one uniform destribution. Grouping these options into plugins and delivering them later wouldn't be an alternative because of the support cost generated by such an aproach. nice feature, but I dont believe it would do what you have in mind. You are using the fifth state as an authentication key. You want to be able to deliver functionality but choose when to enable it. While needed, if Im a advanced Eclipse user, I can simply go to the plugin directory and edit the correct plugin.xml to remove the disabled category and Eclipse will then show all the hidden actions. If I understood you correctly, then you are asking for a licensing key feature, and I would suggest you open a separate feature for that. If Im way off, please elaborate. Well, sort of. We don't really need an licence key, we would want to store those capability options in a database. So the first step would be to implement the possibility to completly disable a capability. Many of the goals of this plan item have been achieved. If there are any further improvements required they will be addressed after 3.1 ships. Marking as fixed. FYI: we've made the preference page a plugable componenet we've defined trigger points in schema and allow for a plugable trigger point advisor we've added image bindings to categories and activities we've added new API to help manipulate activities Marking as verified for the I20050509-2010 testpass. Re-opening to cover ongoing work in R3.2. Summary set to match work item from the R3.2 plan. New text for the item is: The UI component has several frameworks for customizing the presentation, filtering the set of available options and supporting task-based UIs tailored to the user's role. This support should be simplified and made more flexible. [Platform UI] Darin, does Debug have any input on how UI can improve (through documentation or otherwise) on making it easier to use Capabilities/Perspectives/Contexts. here's another scenario that should be considered for documentation clarification https://bugs.eclipse.org/bugs/show_bug.cgi?id=106189#c6 Marking as FIXED. We have clarified the capabilities/activities/contexts story in our documentation and have determined that our existing support was suffecient. Closing. |