My wish list

Started by etienne-sf, October 01, 2020, 15:03:09 PM

Previous topic - Next topic

etienne-sf

Hello,

This tool is really great. It works very well, is very stable and easy to use.
The Ctrl-Z (and Ctrl-Y) works perfectly.
The documentation is very complete and good!
And the "HTML Report" is really really nice !

Congratulation !

I'm myself building an open source project, and I would like it to be as clean as archi
:)



So believe me (BEFORE YOU LOOK AT WHAT'S BELOW) : I really like this tool, and I'll keep on using it!
And because I use it... I took the time to write down the things that frustrated me, or that I would like to be enhanced.
I'll probably contribute in the future, but I have work on my current open source project...





My opinion is that a neat and clean schema helps people to get understand it. And I always take the time to have clean schemas.
But with archi, it's not always that easy.

To do this I often use yEd to draw schemas. yEd is a very impressive tool, the most effective I know to draw schemas.
So here are some wishes which, I think, would greatly enhance the user experience when using archi.exe. And you know, "Christmas is coming!" :)
(FYI, I use the    4.7.1 version, 202007151058 build, on Windows 10, as a non admin)



I added the value for each point, with a [Should Have] or [Nice to Have] tag

About Bend Points:

* [Must Have] When moving an item, it also moves the Bend-Points of the Relations of this item. It's really a piety, because this breaks the manually defined Bend-Points, and they must be manually moved one after the other. Real waste of time. When moving an item, it must let the bend-points at their location.
* [Should Have] Handle that allows to move Bend-Points on relations should be really visible (not very small quite invisible dots)
* [Should Have] A right-click on a Bend-Point should allow to remove it (it's documented in the doc, but it's very counter-intuitive to have to align the two parts around the bend-point)
* [Should Have] The place where the text (name or label) of a relation should not be a Bend-Point. It should be easy to place this text around the relation. It's especially annoying to move a relation's text, once you've defined several Bend-Points. And it's very annoying that the text moves, when moving an unrelated Bend-Point.
* [Should Have] The place of a relation's text should try to respect the place that the user chooses, when a connected item or the relation is moved.
* [Nice to Have] Bend-Point should be selectables like other items, when selecting an area or with Ctrl+click. This allows to:
   * easily align Bend-s (with the icon align left, align up, align center, align top...)
   * Drag Bend-Points along with other objects, when moving them on the view
* [Nice to Have] A click on a relation should be easier. Currently, the click must have a precision about one pixel-wide, especially on zoomed out views
* [Nice to Have] It should be easy to align Bend-Points with the center of other object. For instance, it's hard to do with junctions.



About relations:
The Magic Connector is great !
* [Should Have] When creating a new Relation, the focus should be on this relation. This allows to add Bend-Points or to name it with the F2 key
* [Should Have] When moving two items with a relation between them, all the Bend-Points of their relation(s) should move along. Currently, they must be moved manually afterward.
* [Should Have] It is possible to choose of the relation's label is displayed on the source, the middle or the target. But if source or target is choosen, then the label sticks under the line. So this can not be used for complex schema, when several relations are connected to the same item (because you need lot of space between relation, to properly understand to which relation this label belongs to). Even with source or target, it should be possible to manually set the position of a label.
* [Nice to Have] The target of a relation should not be around the source or target object: it should be within (typically, by default, in the middle of it). Of course the relation would be displayed as stopping when encountering the source of target object (that is: not drawn over the object, despite the source or target point that can be within the source or target object). This allows to have several visible relations around an object, without overlapping. Currently with archi, too much relations starts or stops at angles of the source or target objects. And the default target/source of a relation should be the middle of the item. This makes better relation display, when the item is moved.
* [Nice to Have] When the name or label of has been moved on the view, moving it again needs two clicks: the first get back to the default, and the next allows to change the position. It would be easier to not have to get back to the default position.
* [Nice to Have] Being able to define the size of the text of a relation would often avoid to add a Label: I often use labels to add line-breaks in names. But then, I must update the label each time I update the name (ok, not that often, but there is a real risk to have a label that becomes different than relation's name)


About the views:
* [Should Have] It would be useful to be able to change the item's type. For instance when :
   * dragging a wrong object type, changing it to the good one would be nice (for instance from an Application Event to a Data Object, or from some relation type to another). Of cours, it may be complicated dependending on the connected object. But it's even more complex to do it "by hand"   
   * Changing a relation type, for instance an agregation to an association (or the reverse) would be nice. For instance, by reusing the list displayed by the Magic Connector. This would change the relation in all views, whereas, when removing it and re-creating it, it's easy to forget to re-add the relation in a view that used the previous one.
* [Should Have] Another great enhancement would be to be able to merge two objects. In some cases, a new object is created, instead of reusing one that already exists. The current only way to solve that, is to remove one from the model (and lost all its relations and view displays), and hope we don't forget when recreating properly the views and relations.
* [Should Have] Order / "Bring to front" and Order / "Bring to back" should be available also when several objects are selected. Currently, when several containers needs to be moved to the back (or items to the front), it's very complicated
* [Bug] If you copy an item, scroll the view, then paste item, the pasted item(s) appear in unpredictable places, often even non visible when the view is zoomed in. It would be nice that the pasted item always appears near the copied one, or in the middle of the current display.
* [Nice to Have] The Horizontal scrolling works in the opposite side, compared to all the tools I know (Visio, yEd, Photoshop, Firefox...). It makes it quite hard to switch from one to the other. It would be nice to scroll like the others.
* [Nice to Have] When placing several relations or objects of the same kind on a view, it's fastidious to click for each on the palette before creating a new relation or item. It would be nice to double-click on the relation-type on the palette, and be able to then add several relations on the current view (the Esc key or a click on the View background would free the current object or relation selection on the palette.
* [Nice to Have] It would be nice, like in other tools, that a control+drag'n'drop on an object allows to create a copy of the clicked item
* [Nice to Have] when zoomin in or out, it would be nice to zoom in or out where the cursor is, and not to just zoom in or out the center of what's drawn: this allow to change the part of the view that is displayed
* [Nice to Have] The "Analysis" which displays the views that uses an item is excellent! It offers a super way to navigate through the model. To make it better, it would be nice if the selected items was better highlighted, when double-clicking on such a view link. My dream would be a little animation that shows the selected item ;-) but if it could just center the view on the selected object, it would help to identify it, especially on complex views (especially for relations)
* [Nice to Have] It would be nice to be able to move the items with the arrow keys. My opinion is that it would be a better usage of these keys
* [Nice to Have] The copy/paste of appearance feature is very useful. It would be nice if it worked like in MS Office: select an item or relation, click on the copy/paste icon, then on the target item. The should be a way to help displaying what target item it is, especially for relations: it is almosts impossible to paste an appearance on a relation (how to be pixel precise with this mouse icon?)   
* [Nice to Have] When moving the mouse over the palette's items, the hint (that explains the kind of relation, object...) is often partly or mostly unvisible, as is is display out of the window. So it's out of the screen when the archi window is displayed in the full screen.
* [Nice to Have] When zooming out, in views with junctions, even when perfectly aligned, the junctions and their relations seems unaligned
* [Nice to Have] In a lot of such tools, it is possible to have standard way of displaying the title for each view (title, date of modification, who did the update...). It would be nice to have it here. It makes the result more professonial

About alignement :
* [Should Have] It should be possible to align items that are contained in different containers. For instance, I have two business processes in a raw. Each of them contains sub-processes. I would like to align the sub-processes, but it's not possible. It should also be possible to aligne items contained in a container, and the container itself
* [Nice to Have] When moving items, the alignement capability is very nice. But it is slow to display: one has to move one step, wait to see if it's aligned, move another step... To be easier to use, it would be nice that when moving an item, it would stick to the alignement places, for instance stick when aligned with another item. It would be quicker to move an item, and keep it aligned with others
* [Nice to Have] The capability to distribute the selected items, horizontally or vertically, would be nice


About the doc:
It is very complete and clear!
* [Nice to Have] A table of content would make it easier to find the section we need.


About the HTML Export:
It's just Excellent! A very effective way to share the result.
* [Nice to Have] Ability to have a link to a particular view in the published HTML site. Currently, it is possible to copy a link to a view. But then, the navigation and properties iframes are not visible. The easiest way, seems to me, that opening a page by pasting a link to a view, it is displayed without the navigation iframe, like now. And a link (like in the javadoc) that allows "Frame"/"No Frame".
* [Nice to Have] Ability to define a default view. The "Default-View" is not displayed by default, for instance. This view could be the home page, and contain a link toward the other views.
* [Nice to Have] The "Documentation" box, for items (or "Purpose" for the model) accepts HTML. This is VERY nice (and easier than filter the HTML :)). It would be nice to display a rich text component instead of this basic text box. This would allow one to have better presentations (set text in bold, italic, color, make tables, insert links...). If this component allows to paste a formatted text (coming from Word or other such tools), it would be nice also.
* [Nice to Have] When a View a selected, its description should be displayed in the documentation, on the lower left part of the screen.


About properties:
- [Bug] It seems that updating the description is not seen as an update of the model. And I had strange behaviour of the Ctrl+Z, there.




I hope you're still positive after reading that.
And I hope at least part of this will be implemented, at some point, in the future.
:)

Etienne

Phil Beauvoir

#1
Hi Etienne,

thanks for your very detailed wish-list.

You might find it useful to have a look through the issue tracker to see if any of these have already been tracked or mentioned (https://github.com/archimatetool/archi/issues).

Clearly it would take a long time for one person to attempt all of your wish-list items, and some are dependent on the Eclipse frameworks we use (GEF, Draw2d). Missing functionality such as changing concept type, merging objects can be achieved with a jArchi script.

Generally, though, Archi, coArchi, jArchi and support of these is really a lot of work to maintain, so if there are any things that someone could investigate that would be helpful. Many drawing issues are dependent on the Eclipse GEF and Draw2d frameworks - some other tools that use these frameworks also have similar issues.


Just a couple of quick points:

* [Bug] If you copy an item, scroll the view, then paste item, the pasted item(s) appear in unpredictable places, often even non visible when the view is zoomed in. It would be nice that the pasted item always appears near the copied one, or in the middle of the current display.

Pasted items appear where you click first.

* [Nice to Have] When placing several relations or objects of the same kind on a view, it's fastidious to click for each on the palette before creating a new relation or item. It would be nice to double-click on the relation-type on the palette, and be able to then add several relations on the current view (the Esc key or a click on the View background would free the current object or relation selection on the palette.

Shift + click does this. Single click then resets it.

> * [Nice to Have] A table of content would make it easier to find the section we need.

Depends on the PDF viewer. A table of contents is part of the PDF.

* [Nice to Have] The Horizontal scrolling works in the opposite side, compared to all the tools I know (Visio, yEd, Photoshop, Firefox...). It makes it quite hard to switch from one to the other. It would be nice to scroll like the others.

Right. I'll change it for the next version.


Overall, though, we are always trying to improve Archi in all areas, while also maintaining coArchi and jArchi. At least for me, all of this is a full time endeavour and a huge undertaking. In fact, a lot of time is spent just ensuring that Archi continues to run on all operating systems (for example, each time a MacOS update happens, or an Eclipse update) - but we (we = 2 people) are trying our best!

If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

etienne-sf

Thanks for your response.

I know it's a huge list.
If some can be take into account, when working in this area, it's very nice.

And perhaps I'll be able to participate to the project, by implementing some others.


I note the Shift + click on the palette : Excellent !
:)


Thank you for your work on this tool.
Etienne