Bug 447468 - Mappings should be identified by ID (in addition to label)
Summary: Mappings should be identified by ID (in addition to label)
Status: NEW
Alias: None
Product: Sirius
Classification: Modeling
Component: Diagram (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 8
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2014-10-16 02:51 EDT by Nikolay Manolov CLA
Modified: 2014-10-16 12:04 EDT (History)
2 users (show)

See Also:


Attachments
problematic dialog (18.61 KB, image/jpeg)
2014-10-16 02:51 EDT, Nikolay Manolov CLA
no flags Details
button that opens problematic dialog (11.69 KB, image/jpeg)
2014-10-16 02:53 EDT, Nikolay Manolov CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nikolay Manolov CLA 2014-10-16 02:51:45 EDT
Created attachment 247911 [details]
problematic dialog

When working on the specification, the .odesign tree editor displays Labels, when those are explicitly specified. This is confusing to the developer. Labels are what should be displayed to the end-user. The ID of the element (in addition to the label) should be used in the specification. 
The problem arises because, it is often times the case that different elements will have the same label. In that case one can no longer distinguish between different mappings/tools. 
This is especially problematic when using the dialog for selecting Mappings (indicated in the attached picture).
Comment 1 Nikolay Manolov CLA 2014-10-16 02:53:30 EDT
Created attachment 247912 [details]
button that opens problematic dialog
Comment 2 Maxime Porhel CLA 2014-10-16 04:56:53 EDT
See the reused tools property section of a Layer (1.0.1): in the selection wizard, the candidates are displayed with the path to them: Viewpoint label > diag label > layer label > ... > tool id 

This is better than simply the label of each element but this does not seem to be the best way to present elements. 

We have several options to correct this:
 . show a tree
 . use the tooltip to show the containment path or some information to help the user
 . change the label:  label (id) for example.
Comment 3 Pierre-Charles David CLA 2014-10-16 05:15:00 EDT
Agreed that showing the identifier would be better. Not sure we can fit such a change for 2.0.0 (which is planned for next week), but this would not change any API so it could come in a later 2.0.x.

Proposal for later:
* a tree with the same overall structure as the VSM itself (filtered with only the relevant elements), with a filter/search bar. Two  problems with a tree: i) to give context we need to show the intermediate parent elements even if they can not be selected because they are not of the correct type; ii) the tree must be at least partially expanded when dialog opens so that at least some of the actually selectable elements are visible, but this can quick use a lot of screen space, making it necessary to scroll to find the element the user is looking for.
* for each element, show the identifier, and if the element has a label which is different than its identifier, also show it in parentheses and/or greyed.

We should also make sure we implement this in a way that is consistent across all similar elements in the VSM editors, and stays that way (i.e. with no need for manual tweaking when we add new elements in the metamodel).
Comment 4 Maxime Porhel CLA 2014-10-16 12:04:04 EDT
This also true for Style selection dialog in the different style customizations properties.