Menu: tree vs list view

Fellow friend @timitos puzzled me a lot by explaining the concept of “list” and “tree” view in the main menu. And indeed - when I get as close as 7 cm to my monitor, I really can see that there is a difference in icons. I hadn’t seen that for ~2 years in tryton, and my glasses are not that bad…

So I learned that tree and list view (more or less) display the same contents in a different structure. But in the main menu, they are ordered in a hierarchic manner. I never understood that concept and now think there is some room for improvement.

What about this idea:
Let’s actually use a “tree” icon for the “tree” view - like this one for example:

tryton-menu-baum

And let’s not put these different views in a hierarchy which does not exist, but in one line:

tryton-menueintrag-neu

So the desired view could be triggered by clicking the corresponding icon easily, it would be clear that these are quite a similar thing - and as a side effect, we would slimline the menu quite a bit.

Cheers,
Wolf

This would reduce down the number of items in the main menu, but I think there are a few things that may make this complex / difficult to implement:

  • The main menu itself is a tree view.
  • Which view should open when clicking on the rest of the line, or the word?

/1: True. But it seems as if some of the branches end in two quite equivalent twigs - whenever we find the same word there. So I cannot see a counter-argument there.

/2: Do we know which view is used more often - list or tree view?

What I was trying to explain was that it is just the tree view version of this: Administration > User Interface > Menu, and so can be displayed, and functions, in the same way as any other tree view *(note this link has a hard coded view ID which may stop working if the view id changes…).

The reason I suggested that this may be complex / difficult to implement was because these changes would potentially affect how all tree views in Tryton work. At the moment a single icon can be displayed at the start of a single column of data. The actions are associated with a row of data. Also at the moment if you have multiple actions for a single row, you get a pop up dialog asking which you want to run (like when opening an item from the general ledger).

I’m not suggesting this is a bad idea, or impossible, just perhaps more complex that it first appears.

For now I have seen only three cases where we have both menu entries for the tree and list. It is for the party and product categories and for the stock locations.
A possible improvement could be to use a single menu entry with the two actions list and tree (as @dave said this will display a choosing popup like for the sale reporting).

I can see five in my simple setup - and it could be more in a more complex one:

parties > categories/categories
articles > categories/categories
accounting > accounts > accounts/accounts
accounting > taxes > tax numbers/tax numbers
stock&inventory > location/location

This makes a lot of sense to me.

There are also charts of accounts, analytic chart, account types at least.

There’s also a simple approach that does not require the popup, which is keeping the current menu structure but name the menu entries “Category Tree” and “Category Llist”.

Maybe a better approach, that requires more work too, would be to have an icon in tree views that allowed changing between tree and list structure.

For me, the most annoying part of tree views is that records are created in a way that the parent cannot be changed. I end up telling users to use the List View to avoid problems.

And in the case of analytic accounts is specially problematic because the parent is readonly but root account is required.

If someone has a magic solution to make a model compatible with tree and list view, please explain?

But the behavior is quite straightforward, you always create siblings of the selected record. But also I’m pretty sure that we have children field on all the form.

For me the root field is a legacy and should be replaced by stored path (Replace root field by path (#11017) · Issues · Tryton / Tryton · GitLab).

Per your comment, I guess I miss something important here. AFAIU models that currently have a tree view are already compatible with tree views…

I understand that in some cases the fields being shown are slightly different. For example, in party category the “rec_name” field is shown in the category list, whereas the “name” field is shown in the tree view.

I was thinking that the way to support that would be that in a single action window we define one tree view and one list view. The client then would have to recognize this and show the button if two views are available. The existing switch view would only use one of the two views.

But as I said, I have the impression that you see other problems that this solution is probably not considering… Could you elaborate on the problems you see? Is it because of the way data is structured in the client when the main view is a tree vs a list?

For me it has never been very intuitive. Now I have been checking and found several problems testing on party category tree view:

  • I start with no categories. I click on “New” and create category “a”.
  • Press “New” again and create category “b”. I cannot add it as a child of a (parent is readonly).
  • I move to category “a” and create two children “aa” and “ab”. Before saving the form, in the tree view of children the names are not shown because the field shown is “rec_name” which is not computed until I save.
  • I switch to tree view.
  • Now if I press “New” when the “a” category is selected, the parent field of the new record is readonly (record must be sibling of a) but if I press “New” when the “aa” category is selected, the parent field of the new record is readwrite.
  • So I do the latter and create the “aba” category and choose “ab” as parent.
  • I switch to tree view but now the “aba” category is shown as a children of “a” category.
  • I reload and now “aba” is shown as child of “ab” category.

If technically possible I’d be in favor of making parent read-write because even if the user is allowed to use the children field:

  • It is not obvious for the user why the parent is read-only
  • If the the user made a mistake and wants to change the parent of the field using the tree view is not always easy, specially with large structures.

The data model is completely different between a tree and a list. I do not see how the same data model could be reused for both case except by showing only the roots of the tree on the list.

Please fill one issue for each problem.

I can not see how you can manage that editing one field change the position of the record in the tree. But if you know how please submit a patch.

Done:

1 Like

Created issue 11391 on this.