References Menu Suggestion

[Hans]

I find references ugly to use and the diverse element context tab
nastily nested (3 unnecessary clicks into the hierarchy!):

One can add requirements to elements simply by dragging them into
the element - wonderful! But: If I likewise want to add a use case
as a reference to the same element I need to click and click to get
that done - and to browse and access it:
I don't find it in the tabbed dialog - but somewhere else!

Why not make it simple: Instead of the Requirements tab in the
Property dialog, make it a general References dialog which is capable
to hold all kinds of references, Reqs and other beasts (the types of
which could by shown by text or better: icon within the ref listview).
(So: remove complexity in favour of usability and overview!)

Next, add a hot spot at the elements top right edge which pops up a
reference list: activation of an item will open that element.
So: one click to browse and hop!

Regards
Hans

[Hans]

Btw: The external files link behaves likewise complicated: I usually want to see the links from scratch instead of exploring with many clicks if there are some to access them.

Regards
Hans

[thomaskilian]

Maybe the Relationship Matrix would solve most of your problems?

[Hans]

Hi Thomas,

Relaltionship matrix is not a solution: count the clicks necessary!
That window  is an overshoot: I'm not browsing a cube, simply I want to inform me on the links to the chose elements and browse them if necessary. One click should be enough. And, by the way I propose, it's possible.
BTW: I also don't see a single reason why adding a link to an element should be any different from adding a requirement - simply by drag-drop. And I don't see any reason why links, relationships shouldn't be altogether.

Regards
Hans

[Hans]

BTW: Who remembers the good-old UI guidelines published by Apple (with comitment by IBM and Microsoft)?

Regards
Detlef

[thomaskilian]

First off you would need a good concept where a link should be create and where a nested structure should be the result. Maybe some kind of click-drag and ctrl-click-drag to distinguish both?

[Hans]

Hi Thomas,

why would you like all that? Is it really worth remembering whether this has to be dragged with control or that with shift if this is a reference called link and that a reference called referenced use case?

After having clicked into a heap of thises and thats, I simply want to make use of them  as painlessly as possible, and working with a good amount of objects within the overburdened UI of EA really is painful!
It should be easier.

Regards
Hans

[thomaskilian]

You didn't get my point. Dragging one element over another can either mean to create a link (as you suggest) but it is currently already used to create composite elements (e.g. try dragging a UI control over a Screen element).

[Hans]

As far as I know, dragging a use case to a class won't work, dragging a file from Explorer into any element within EA won't work either.

Whether in some circumstance a drag-drop will mean a special thing depends on the context.

I likewise use to override operators just because they mean certain well-understood things in certain contexts: sorry I'm not a Java guy.

Regards
Detlef

[thomaskilian]

Detlef (I still remember this discussion about your name ),
it is hard to tell whether working that way will bring improvement (for me). I could imagine that dragging objects around could easily lead to unwanted dependencies/associations (btw., which kind would you create, directed, undirected, bi-directional, what stereotype?). I simply got used to working with explicitly choosing a relation and re-use it via F3.

And - I rember Apples GUI since I use it at my iMac. I'm also sure that EA would have a much better GUI if it would have been desigened on a Mac. But () the community would then be much smaller, the product more expensive, and likely I would not be able to use it at work (where I have to use Wintel).

[Hans]

Hi Thomas,

you may be not sure right now, but I am sure you you will estimate the relief
to achieve more with less effort.
For example, right now, right clicking a thing you certainly do expect
to give you a *context* sensitive menu.

As to the UI Guideline, that was a common agreement between MS,Apple,IBM, and
some others. It held, above all that any UI shall be shallow.
It wasn't MS specific that this rule was broken quite alot.
However, as to Apple's one-button mouse, it shows quite nicely that can work
intuitively and mouse-orientedly even with the handicap of missing 2 or more
other buttons.

Regards
Hans-Detlef

[Paolo F Cantoni]

For an excellent high-level discussion on UI design see:
http://www.maplefish.com/todd/papers/Experiences.html

The pattern language should be extended...  but this it an excellent start!

Paolo