Issue 11908

Title
Our estimation of the number of records is puzzling users
Priority
feature
Status
testing
Nosy list
nicoe, reviewbot, yangoon
Assigned to
nicoe
Keywords
review

Created on 2022-11-22.18:52:09 by nicoe, last changed 4 days ago by reviewbot.

Messages

Author: [hidden] (nicoe) Tryton committer
Date: 2022-11-29.16:06:54

Here's a review allowing to fetch exact count of records when clicking on the text.

I wonder if we should use a specific symbol to communicate that the number displayed is an approximation (either the infinite symbol or something like ~=)

Author: [hidden] (yangoon) Tryton translator
Date: 2022-11-25.08:28:23

The issue is that the user is using browsing a tables and knows that there is
something like 1M records but since the maximum number we will show is 100 * display_limit the client shows 100k+ which is a gross underestimation.

Thus they think that something is wrong.

But I have another example, let's say we have a table filled with millions of
random choices between heads and tails. If we make a search it will show 100k+,
if we make a search for heads it will show 100k+ also. Some people might find
this strange.

Thanks, now I understand the issue.

I wonder if we shouldn't use the infinity symbol when the number is above the
limit.

That would have been excactly also my proposal: Instead of showing fictive numbers that are difficult to interprete I would show some symbol like the tilde (~), the infinity symbol (∞) or the asterisk (*). If OTOH numbers shall be displayed it would perhaps be better to use " > number" instead of "number+".

Author: [hidden] (nicoe) Tryton committer
Date: 2022-11-24.23:59:22
* Mathias Behrle  [2022-11-24 11:30 +0100]: 

>Could you put me on the right track what exactly the problem is and where the
>confusion comes from?

The issue is that the user is using browsing a tables and knows that there is
something like 1M records but since the maximum number we will show is 100 *
display_limit the client shows 100k+ which is a gross underestimation.

Thus they think that something is wrong.

But I have another example, let's say we have a table filled with millions of
random choices between heads and tails. If we make a search it will show 100k+,
if we make a search for heads it will show 100k+ also. Some people might find
this strange.

I wonder if we shouldn't use the infinity symbol when the number is above the
limit.
Author: [hidden] (yangoon) Tryton translator
Date: 2022-11-24.11:30:41

Thanks for your input but in fact the numbers are already abbreviated.

Indeed it seems I was on the wrong track (also looking at 6.0). I assumed you talk about the counters on domain tabs. Those provide currently (99+) on the tab and 1000+ on the tooltip.

Then there is the record count in the upper right of the view that provides <number_of_first_selected_record>#<number_of_selected_records>@<client_search_limit><humanized_record_count>

Besides that it would be more consistent from a user point of view to have the <humanized_record_count> also on the tool tips this seems coherent for me so far.

Could you put me on the right track what exactly the problem is and where the confusion comes from?

Author: [hidden] (nicoe) Tryton committer
Date: 2022-11-23.15:11:33
* Mathias Behrle  [2022-11-22 23:55 +0100]: 

>I found those links for abbreviations of big numbers:
>
>https://ux.stackexchange.com/questions/131709/how-to-abbreviate-long-numbers
>https://experience.sap.com/fiori-design-web/formatting-numbers/#guidelines
>https://www.ibm.com/docs/en/planning-analytics/2.0.0?topic=2021-abbreviated-format-display-large-numbers
>
>May be an abbreviated format causes less irritations?

Thanks for your input but in fact the numbers are already abbreviated.
Author: [hidden] (yangoon) Tryton translator
Date: 2022-11-22.23:55:43
Author: [hidden] (nicoe) Tryton committer
Date: 2022-11-22.18:52:09

Currently we're setting in the client the maximum of records to (display_limit * 100)+ when there is more than this number of records for the search of the user.

Some users do not understand this because they know there is much more records than (display_limit * 100).

But on the other hand we can not just send the maximum number of records as it would puzzle them also if they refine the search and this maximum number is just the same as before.

Cédric suggested using (nb_records - limit) / 2 + limit when there is a record which is somewhere in the middle.

History
Date User Action Args
2022-11-29 16:10:31reviewbotsetmessages: + msg80239
nosy: + reviewbot
2022-11-29 16:07:02nicoesetstatus: chatting -> testing
2022-11-29 16:06:54nicoesetassignedto: nicoe
keyword: + review
messages: + msg80238
reviews: 436241003
2022-11-25 08:28:23yangoonsetmessages: + msg80207
2022-11-24 23:59:23nicoesetmessages: + msg80205
2022-11-24 11:30:41yangoonsetmessages: + msg80166
2022-11-23 15:11:33nicoesetmessages: + msg80149
2022-11-22 23:55:43yangoonsetmessages: + msg80135
nosy: + yangoon
status: unread -> chatting
2022-11-22 18:52:09nicoecreate

Showing 10 items. Show all history (warning: this could be VERY long)