[cme-dev] comments on experience with CME UI

[Stan Sutton <suttons@xxxxxxxxxx>]

Hi All,

I've been playing around with the CME
UI as part of an effort to see to what extent I can capture Cosmos concern
models in Conman.  As a result, I now have some experience in using
the UI and have some feedback to report.  My comments are listed below.

I realize that some of my comments address
well-known limitations of the current UI, and that many of the limitations
in the UI have good reason for being (i.e., we haven't needed to fix them
for the demo).  I don't intend to belabor those issues.  Still,
I would seriously like to be able to use the UI to do serious concern modeling,
so I've tried to be thorough in my observations, at least with respect
to my own experience.

If it's not clear otherwise, I do like
the overall look and feel of the UI and I generally enjoy working in it.
 I would really like to be able to do more with it!

Regards,

Stan

1. When you add a concern under an existing concern, the tree item above the added item collapses completely.  This is only a minor inconvenience if you're just adding one or two new concerns that are just one or two levels down from the root of the item, but it's a real problem if you're adding a large number of concerns (which you have to do one at a time) that are four or five (or more) levels down.
2. At the top level the concern model is divided into three parts:  Workspace, Contained Relationships, and Features,  but through the UI a user can add new concerns only under Features.  I can see that this simplifies the UI (in some obvious ways and in some ways that are probably not obvious to me).  However, in practice people will want to add concerns that do not represent features.  For example, I want to add top-level concerns to represent the Cosmos schema and (under those) elements of particular Cosmos concern models.  The Cosmos schema does not correspond to a feature, and actually "features" may be a category some levels down into a Cosmos model.  Thus it would be useful to allow users to add new concerns at the top level of the Conman concern space.
3. I was able to add new concerns (specifically the root of a Cosmos schema) at the top level of the Conman concern space (i.e., at the same level as Features, etc.) by modifying the ConmanBuilder class in org.eclipse.cme.ui.internal.builder.  When I do this, the new elements show up appropriately in the UI (which is good).  However, when I right-click on these items, the selections available on the context-sensitive menus are not the same as the selections available on items under Features, although I expect that they should be (and it would be more useful if they were).  The following table compares the available selections under Features and under the new top-level item that I added.  (Note:  In order to get around this limitation on the functionality of context-sensitive menus for new top-level parts of the concern model, I ended up inserting the Cosmos schema, i.e., the CosmosElements item, under Features as well as at the top level of the model.  In this way I can view the Cosmos elements at the top level of the model and work with it under Features.)

   Under Existing Top-Level Item "Features"				Under New Top-Level Item "CosmosElements"
   Root	One level down	Two levels down	Menu selections	Root	One level down	Two levels down	Menu selections
   Features			New concern, Search for	CosmosElements			Search for
   	CosmosElements		Delete, New concern, Extract concern, Compose new concern, Search for		Concerns		Add to concern, Search for
   		Concerns	Same as above			LogicalConcerns	Same as above

4. The "Search for" selection in the context-sensitive menus contains options that are really only appropriate to Java (or Java-like) units.  They don't apply to other sorts of units, packages, or to concerns in general.  However, I would probably like to do some "quick searching" for concerns in a Cosmos schema, for example, according to the sorts of relationships that apply to Cosmos model elements.  This all suggests a couple of things:  a)  It would be nice to make unavailable those search selections that are nonsensical for a particular type of item, and b) it would be nice to have a mechanism by which appropriate kinds of search could be added for a particular type of item (for all I know, such a mechanism may already exist and it may just need to be made more evident).
5. Empty packages are not shown under the Workspace concern in the Concern Explorer view.  They do show up in the Package Explorer view.  I would like them to show up in the Concern Explorer view because I want to use the UI to populate them with selected units.
6. Another limitation of the UI that those familiar with it will already know is that you can't use the UI to create relationships among concerns.  But I would really like to be able to do this.  (Note also that I'm interested in relationships that apply directly between concerns, not just relationships that may apply between units and be propagated to concerns that contain those units.)
7. Limitations (and other features) of Add To Concern

1. Relationships under Contained Relationships can be added to a concern, but relationships elsewhere cannot be (and these are the same relationships, just accessed from different parts of the model).  Apart from being inconsistent, this is problematic because the relationships under Contained Relationships are disorganized and difficult to work with.  Thus users are actually likely to want to work with relationships, including adding them to concerns, starting in other parts of the model.
2. Similarly, units under Workspace can be added to a concern, but units elsewhere cannot be (and these are the same units, just accessed from different parts of the model).  The units under the Workspace are well-organized by the workspace project/package structure, but users can be expected to want to work with units under concerns in other parts of the model as well.
3. It's not possible to add a concern to another concern, but this is an entirely sensible and useful thing to do.
4. An exception to points 2 and 3 above is that a unit or a concern that is the target of a relationship can be added to a concern, even if the relationship itself (and possibly the concern that contain the relationship) cannot be.  (So, for instance, if you find a concern Foo under Features, you cannot right-click on it and add it to another concern, whereas if you find concern Foo as the target of a relationship somewhere else under Features, you can right-click on it and  add it to another concern.)
8. Also, when you create a new concern by extraction or composition, the result ends up only under the Workspace concern.  If extraction and composition apply only to units, then I understand that the result should end up at least under the Workspace.  However, it seems to me that users will most of the time want to extract or compose into a new concern elsewhere in the concern space (say, under Features).  It would be nice to have the ability to target the new concern to both the Workspace and to some number of additional concerns.
9. It would be useful to be able to copy and move concerns, units, and relationships--at least those that are not tied to some physical structure (like the workspace) or intensional specification.
10. It doesn't seem possible to change the name of a concern (but I don't get all of my concern names right the first time).
11. The regular Eclipse search (flashlight button) doesn't work in the Concern Explorer view.  The search operation is available, but it doesn't seem to work properly in general, at least, not in the Concern Explorer view.  And there are things that can be searched in the Package Explorer view that apparently can't be searched in the Concern Explorer view, namely projects, packages, and units.
12. There's some flaky behavior in the handling of scopes in the CME Search view, especially in the relationship between scopes in the query wizard and scopes in the main CME Search window:

1. In the main CME Search window, if you set the scope of a query to be Workspace or Entire Concern Model, and then invoke the query wizard to specify and run a query, then the scope set in the main window determines the scope over which the query is evaluated, even if the scope is set differently in the query wizard
2. In the main CME Search window, if you set the scope of a query to Other Concerns, and then invoke the query wizard to specify and run a query, then the query is evaluated with respect to the Entire Concern Model, regardless of how the scope is set in the query wizard
3. In the main CME Search window, if you set the scope of a query to Entire Concern Model or to Workspace and then invoke the query wizard, the query wizard comes up with the scope set in the same way.  However, in the main window, if you set the scope to Other Concerns, then the wizard sometimes (but not always) comes up with the scope set to Entire Concern Model.  (I don't know what determines whether this last bit works correctly or not.)
4. This is unlike the above items, but it seems possible to run a query against Other Concerns without having specified any other concerns.  The behavior in that case seems to be Entire Concern Model (but I'm not sure whether this is intended)