Display relate as button

I’m wonderig if it won be better to have a dedicated tab on party as it’s easy to have more than 5 o 6 relates on the party form and it will bloat the UI if it’s shown on the top of the form

The point is to limit the number and that it is information that user always wants to see.

Here are some screenshot with the result:


Sao Sale

I think it is better to use a full line with links because of the different height between links (icons + text) and the other widget (label and field).

I’m wondering if we should display those button on the dialog box. It works but it may be a little weird for the user. Also when editing a form from a Many2One, usually we do not care too much about the links.

Some things that come to mind at the first glance:

  • It takes a lot of vertical space.
  • Lots of information (counts) will be loaded and unused in many cases
  • It’s not immediately clear why we want those links while at the same time we have a relate button at the toolbar (the one we already have available nowadays) that will have in some cases the same entries but in other cases it will have more or different ones. Looks like a duplicated feature to me.
  • I don’t see any advantage to know the number of related records for most documents.

Why don’t we simply change the behaviour of the existing relate button and make it load the counters when the user presses the button and the dropdown menu is displayed?

If desired, this horizontal menu could be shown instead of the vertical one, but the vertical one allows for more items. If the horizontal menu is used, maybe it could be a user option to have it always opened by default.

Just my 2 cents.

2 Likes

I agree with @albert.
Coming back to my initial comment where comparing this functionality with similar implementation on NAV, I would like to show how this other system uses a fact box panel to show related information (right panel). IMHO this is a mix of both points due to it is visible by default, it does not take vertical space, is resizable and can be hidden completely by users if they want (there is an option to show it again).

I prefer to take vertical space than horizontal because vertical scroll is more common to users than horizontal.

The main goal is to show that there is something.
When looking at a sale order, it is good to know there are complaints or that there are two shipments etc. This allows the user to have a quick picture of what is going on (or not going on).

Relate buttons are more an advanced features. We see often that users ask question on how to find something which is in a relate but they do not know because they do not see it.

Well we display on the form the most important one for discoverability and quick view.

Well almost nothing is duplicated because we reuse the existing actions.

See:

Also it will make the display of the drop-down very slow compare to the current implementation that use a cache on the record. (menu actions are not form related as they are also on list/tree).

That’s why we keep the relate.

As usual option is the non-answer. We need to have something that works for everyone.
Also this feature is the first step to Include dashboard in base module, we can not make them optional otherwise dashboard will be pointless.

They are displayed in a group so developer can activate the expandable feature. But it will probably requires to have a feature to remember the user choice.

But the proposal not only takes horizontal space, but also allows modules to add new links, eventually using all horizontal space. What will happen when it is filled in? Add a three dot button that show the remaining entries? Horizontal scroll?

I’m not talking about duplicated for the developer but for the user.

I think that if we have a discoverability problem with linked documents, we should address that problem…

Also the fact that it is useful for the user to have “Customer Shipments” easily available in the party form does not mean that the count information is useful. So maybe like in window domains, count should be an opt-in feature.

I think that one of the things that does not convince me about the proposal is the fact that links are part of the form. I have the feeling that we should solve that at the toolbar level. And that, does not prevent to have the “link” feature for other uses.

I agree with @albert and @sergyo that the current proposal seems not really fit to provide improved accessibility to the relates.

The two horizontal bars on the screenshots are irritating in twofold aspect:

  1. The toolbar buttons to work directly with the record are more distant from the record than the displayed related documents. This could at least changed by switching them.
  2. There are two 'tool’bars, but with different concepts. Mixing the concept of a real toolbar with a bar showing related documents is counterintuitive. Most notably if they are designed in the exact same way.

I concur with the disputable benefit of the counts (of the documents) compared to the performance penalty they will likely have. Are there any numbers for the impact they will have in a substantially well populated database?

I think users will look even less for relates if a subset is shown via buttons. The user will rather wonder why some items will miss from the buttons and if this is a bug and why there is no consistent solution. This could be different, if the user could configure the bar herself. Like favorites for related documents.

Coming back to the original intention of this issue to show counts for the relates without having to open them: why not displaying the count directly on the relates? I saw in this discussion no argument, that doesn’t apply as well to the buttons. It could even be made a setting in the code of a relate. And yes, it should be possible to disable the display, if it implies any performance penalty.

There will be an horizontal scroll until someone implement something else for <group/>.
But there are a lot of free space as everybody said.
Also modules that add new links should take care of not design like for any other addition a module does. But it can also replace or remove as it is a tag on the view like any other thing.

So there is no problem because we have exactly the same duplication with buttons.

And this is what I’m doing. I show the important relates on the form.

Not having counts means it is not an important link so it should stay only a relate.

I tested putting links at the bottom, it does look quite good:


I’m thinking about supporting search_value to limit on party the counting to pending records based on their state. And I’m also thinking about an option to hide link if the count result is all 0.

I prefer to have links on the bottom. One reason is that they are together with the buttons, so the user knows that the bottom part is where he can do its work.

That makes sense for me, por example for parties associated to sales it does not make sense to show the purchase button. If the user wants to create a new purchase for the party the relate option can be used.

Does it really make sense to use a search_value or a domain directly? If we hide the button when there is no count a domain should be enougth to always show only pending records.

I agree, that it looks better but this proposal still moves the problem of mixing concepts to the bottom instead of the top. It just looks good on the chosen models. The party model doesn’t have action buttons at the bottom. The sales model has the very least of possible links and action buttons (think of additional modules like sale_subscription, sale_supply_drop_shipment, sale_opportunity, sale_advance_payment just to name some).

The more I look at those screenshots the more I like the idea proposed by others to create a vertical menu on the right side named ‘Important links’. It could be switched on/off just like the main menu.

Advantages:

  • Quick access to important links.
  • Evtl. display of numbers of related documents (the performance questions are not answered so far).
  • Easy switch to display those items or not to gain valuable space on the main work space.

Disadvantages:

  • If sao could be improved to make it possible to resize the width of the left menu (just like it is possible on the gtk client), i.e. also the width of an evtl. coming right menu, this would be a very good addition. This menu currently takes a lot of space depending on the device you are using.

I am joining two screenshots of EDMS Mayan showing the initial dashboard and the right menu on a selected model. I think they can serve well as an example how a right-side menu can be advantageously integrated.

The counting is based on the domain of the action. I think it is good to include search_value instead of enforcing more restricted domain because it allow user to clear it and see the full set.
So the search_value will be used to limit on pending records.

Although I agree that buttons look better at the bottom than at the top, I still keep my remarks that we’re duplicating part of the feature already provided by the relate button.

I agree with Cédric that a menu on the right takes horizontal space which is more valuable than the vertical one. However, I tend to look at how gmail solves this kind of problems and here’s a screenshot of the left menu and the right panel (which allow you to have extensions) when they’re hidden:

                    

For the menu in the left, gmail automatically expands it (overlapping the list of e-mails at that moment) when the user is on top of one of the icons for more than a second.

So, it is possible to:

Remove the link button at the top (maybe only when working on a desktop or large enough display) and replace it with a vertical menu which by default shows only the icons with the badge on top.

Badges would only be computed when the keywords have the count set to true. We could decide that counts are not computed if more than one records are selected, as it would be visible in tree view too.

If desired (although it may not be necessary) we could have another boolean at the keyword named “highlighed” (or important). It could make important keywords to be shown alphabetically first. Later non-important keywords could be shown.

I don’t like think the following would be necessary but: we could add a “more” button (more) and display the rest of the keywords in there. But as we can have a vertical scroll, I don’t think that would be necessary.

So IIUC the button will be shown only if the domain returns a record but the badge will shown the count of the domain + the search value? Am I right?

From what I see the current implementation uses the xml view definition to define the links inside the form, so anyone can move the links to a diferent part of the view (top, bottom, in a separate tab,etc.) using the view inheritance system.

In order to implement your proposal we should probably have a dedicated xml tag for toolbar and let the client show as a toggable widget on the (right/left) part form. Something like:

<form>

</form>
<toolbar>
   <link1/>
   <link2/>
<toobar>

Then we can make it look like:

or

If we go this way we should probably also add support for printing reports and exucting actions for this toolbar.

Then the state and the actions can also be added to the toolbar so we ensure that they are shown on all the tabs.

This are my toughts after reading your comments, not sure if it’s the way to go but just something to think about.

My proposal is not to define this at the view level but use existing keywords.

Yes, that’s what I had in mind too. But wanted to go step by step :wink:

Indeed this is similar to my previous comment (but I didn’t want to upload images of other ERPs :wink:).

So it seems that there are some other ERPs that they do in a similar way.

Yes, we may go step by step but probably it should not be to hard to support the generic action button.

I like the idea of having most relevant links on the form and add more non relevant options as relate/action/report on the toolbar. This will allow user to focus on important things.

I vote for the rigth (or left) panel. At this time I have a lot of problems with the vertical espace in some screens with a large font configuration. Adding more icons at the top (or the bottom) would increase thoose problems.
Just my opinion.
Cheers!

1 Like