Building composite types should be easier

[jri]

The most cumbersome aspect of the current type builder is when the user want add child types to a parent type.

Both cases must be supported seamlessly (currently they are not):

1. the child type does exist already, and is about to be reused.
2. the child type does not yet exist, and is about to be created on-the-fly. All properties of the new child type (as well as the new assoc def) must be configurable on the spot, including data type, cardinality, assoc type and so on. In particular the new child type might be composite as well.

Note: only the user's underlying needs are described here; no design decisions. The design still needs to be discussed. That discussion should respect these facts:

• The topicmap is predestined for building/visualizing hierarchic structures. The detail panel ist not.
• The detail panel is predestined for visualizing/manipulating linear structures, in particular when it comes to manually re-ordering list items. The topicmap is not.

From my point of view we could benefit a lot from a design idea that Gerben has implemented in his Web Memex frontend: a combined search/create widget (invoked by left-clicking an empty canvas spot). This solves the general problem of an integrated search/create operation in a very elegant way.

[irau]

Indeed designing an interface for easily creating new composites is not a simple task. I have made some suggestions on ​https://my.deepamehta.de/topicmap/35836/topic/53305 but I agree that we have issues with the detail panel not being ideal for modeling hierarchic structures. I had a look at ​http://webmemex.org/ and I assume you mean the dialog that appears when a user clicks the "create link from ..." or "create link to ..." box (see attached screenshot). To me it's not quite clear yet how we could use this concept to easily create a new composite in DM. Maybe you could add a sribble to the ticket?

[jri]

​https://my.deepamehta.de/topicmap/35836/topic/53305

I think your approach is very good. But with your actual design decisions I see serious problems.

1. The name of the Child Topic Type can either be selected from the list of existing Topic Types (Click Dropdown-Icon) or a new name can be entered

In this point lies the strongest power of your approach. You provide the user a seamless way for doing both, reusing existing types, and creating new types on-the-fly. That is indeed what is currently missing and what is urgently needed, BUT ...

Your design omits the fact that a type does not consist just of a name. It also has an URI, a data type, index modes etc. When the user creates a new type on-the-fly just by entering a new name where are coming these other information from? You could possibly show an embedded form to let the user enter/change these values. But what would be the exact condition for making this form visible for a certain child type box? Consequently that form should be visible for all child types boxes displayed in the detail panel then. This means the detail panel would turn into an editor for (existing) child types, which is quite a departure from the original task of adding child types.

Further problems occur if the new child type is set to be composite? Further and further nested forms would be embedded in the detail panel. You would end up with an arbitrary number of child types and nesting levels, and would offer the user the possibility to change every single setting of every child type ... all at once! The entire composite structure would be squeezed into the relatively small space of the detail panel. The detail panel would sheer explode and pour a shower of input fields, menus und checkboxes over the user.

The topicmap provides a much better opportunity for each of the tasks at hand:

1. visualize complex type hierarchies
2. manipulate those hierarchies in-place (reveal existing types, create new types, create associations)
3. select individual types/associations for being edited (in the detail panel)

All the basic topicmap operations are already there and must not be re-invented for the detail panel.

My proposal is a redesign of the type editor which consequently builds on the respective strengths of both, the topicmap, and the detail panel.

• The topicmap is great for visualizing and manipulating graphs and hierarchical structures. A composite type is a hierarchical structure anyway, displayable as such on the topicmap already. So, let's also build/manipulate them directly on the topicmap!

• (Besides for editing the selected topic/association) the detail panel is great for visualizing/manipulating linear structures. In particular to allow the user to re-order items via drag'n'drop. So, let's use the detail panel mainly for that: define the order of a parent type's child types!

How would a user work with the map based type builder?

1. Create a type and set it to composite.

2. Reveal or create a child type -- directly on the topicmap. That's where the mentioned combined search/create widget enters the stage. It offers the user a seamless way for both, revealing an existing type, or creating a new one. For its mode of operation see #1055.

3. Create an association between parent type and child type. The association will be automatically typed to "Composition Definition", and the detail panel will enter edit mode. The user might want retype to "Aggregation Definition" (other types will not appear in the type menu). Reasonable default values for role types, cardinality, "include in label" etc. are filled in already.

4. Repeat steps 2. and 3. to add further child types.

5. To change the child type order select the parent type and enter edit mode (you can just double-click the parent type). The detail panel will show a column of child type boxes (like now), BUT besides the child type name they are completely empty and allow for no other interaction as drag'n'drop (like now).

Conclusion: the new map based type builder basically ...

• makes use of the existing general topicmap manipulation functions (create/reveal/select topics and associations)
• provides additional user support (assoc auto-retyping, limited menu choices)
• removes the redundant functions which currently exists twice (in the detail panel / on the topicmap), e.g. edit assoc type, include in label.
• leverages the new combined widget, which solves the original problem of seamless search/create operations in a generic way, that is not only for building types but for all kind of information work!

Thank you very much, Ingo, for feedback!
That's what DM wants :-)

[irau]

Hi Jörg,

some thoughts and questions on your proposal for creating composites with a one-click-search-and-create feature (comparable to that on ​http://webmemex.org):

In #1055 you write, the combined Search-and-Create widget

[...] has the potential to completely remove the current separate Search and Create widgets from the Webclient's toolbar, and allows for performing combined search/create operations directly on the topicmap.

wouldn't this mean, that the action ...

1. Create a type and set it to composite.

should be performed in just the same way, just by clicking a free area on the topicmap?

2. Reveal or create a child type -- directly on the topicmap. That's where the mentioned combined search/create widget enters the stage. It offers the user a seamless way for both, revealing an existing type, or creating a new one. For its mode of operation see #1055.

That would indeed be quite practical. I would expect the new child typ (whether newly created or just selected) to be revealed nearby the dialog on the map.

3. Create an association between parent type and child type. The association will be automatically typed to "Composition Definition", and the detail panel will enter edit mode. The user might want retype to "Aggregation Definition" (other types will not appear in the type menu). Reasonable default values for role types, cardinality, "include in label" etc. are filled in already.

If I understand You right I would just draw the association between parent and child topic on the map and DM would automatically realize that I don't want to draw just a general association (like today - with the association type just being the simple default association and role types also simply being default). That would indeed make things much easier for the user.

4. Repeat steps 2. and 3. to add further child types.

5. To change the child type order select the parent type and enter edit mode (you can just double-click the parent type). The detail panel will show a column of child type boxes (like now), BUT besides the child type name they are completely empty and allow for no other interaction as drag'n'drop (like now).

Why would we need to get rid of all the editing features for child topics that we have today when editing a composite? Do I get You right, that you want to move the editing of 'cardinality' and 'association type' strictly into the association itself?

Maybe in a next step we should actually scribble what is written down here to get a better feeling for the real life interaction with DM.

So much for the moment
Regards, Ingo

[jri]

Replying to irau:

wouldn't this mean, that the action ...

1. Create a type and set it to composite.

should be performed in just the same way, just by clicking a free area on the topicmap?

Yes, exactly :-)

To support the Create case the overlay (#1055) would feature both, a Type pulldown menu (stateful) and a Create button. Clicking the Create button creates a topic of the type currently selected in the menu. Between overlay invocations the state of the type menu would be remembered. This supports the user with creating a bunch of topics of the same type, which is in particular handy when building composite types.

2. Reveal or create a child type -- directly on the topicmap. That's where the mentioned combined search/create widget enters the stage. It offers the user a seamless way for both, revealing an existing type, or creating a new one. For its mode of operation see #1055.

That would indeed be quite practical. I would expect the new child typ (whether newly created or just selected) to be revealed nearby the dialog on the map.

Yes!
The topic finally revealed/created through the overlay would appear exactly on the position where the initial click (that opened the overlay) occurred. The overlay itself would also appear next to that position. We might decide either to anchor its upper/left corner or its center to that position.

3. Create an association between parent type and child type. The association will be automatically typed to "Composition Definition", and the detail panel will enter edit mode. The user might want retype to "Aggregation Definition" (other types will not appear in the type menu). Reasonable default values for role types, cardinality, "include in label" etc. are filled in already.

If I understand You right I would just draw the association between parent and child topic on the map and DM would automatically realize that I don't want to draw just a general association (like today - with the association type just being the simple default association and role types also simply being default). That would indeed make things much easier for the user.

Yes, indeed!
The functionality I've described would rely on the Association Auto-Typing feature (#931) as introduced in DM 4.8. DM can auto-type a newly created (generic) association based on the types of the 2 connected topics.
Try this: associate a Person with an Institution. DM will automatically type that association into Organization Association and thus allow you to further specify that person's role in that organization (CEO, Founder, Employee, ...)

4. Repeat steps 2. and 3. to add further child types.

5. To change the child type order select the parent type and enter edit mode (you can just double-click the parent type). The detail panel will show a column of child type boxes (like now), BUT besides the child type name they are completely empty and allow for no other interaction as drag'n'drop (like now).

Why would we need to get rid of all the editing features for child topics that we have today when editing a composite? Do I get You right, that you want to move the editing of 'cardinality' and 'association type' strictly into the association itself?

Yes, exactly!
"Cardinality", "Association Type", "Include in Label" etc. are structurally neither part of the parent type nor part of the child type, but part the association that connects these 2. Note that the same child type might be (re)used in several parent types, with an individual Cardinality setting in each one. (Same for Association Type, Include in Label etc.)
These information is bound to the association, so it is consequent to let the user edit it there.

I see no need to offer the user a possibility to edit all the settings of all the child types at once. This abundance of menus, input fields and checkboxes appears to me rather intimidating than useful.

And how would a designer justify the decision to present all child types of a single hierarchy level instead of presenting all hierarchy levels of a single child type? Possibly the latter would make even more sense.

Just a (historical) side note: the design of the current composite type editor is very very old. It is there since the very first DM release (I guess) and it was never revised since then. Actually I would not even call it a design at all, but an ad-hoc solution based on the DM facilities available at that time. It never felt right to me.

Maybe in a next step we should actually scribble what is written down here to get a better feeling for the real life interaction with DM.

Just give me 4 weeks and you could make first real experience with the new type editor ;-)
(Unfortunately in reality we can not have it in 4 weeks because of my other duties.)

Thanks + Cheers,
Jörg