|
Notes |
|
|
(0039563)
|
|
dbaz
|
|
2011-08-01 11:52
|
|
For me a good approach would be: If you click in the "> 100" the real count is shown (related to feature request 18139). After that, the checkbox header is enabled again to be able to select all (related to feature request 18140)
PD: Now it is also possible to click in the selected row count to go to the seleted record. The click visualization for the "> 100" should be similar
PD2: If the query is going to take some time, an animated spinning circle or something similar should be shown while the count is being calculated |
|
|
|
(0040041)
|
|
rgoris
|
|
2011-08-09 14:01
|
|
I propose to launch a row count request when pressing the row counter in the top left of the grid.
Currently we already use the selected row counter as a button in case selected rows are outside the visible viewport. The same can be done for the total row counter. On hover it turns orange, on click the ">100" is replaced by the actual total row count. |
|
|
|
(0040052)
|
|
rgoris
|
|
2011-08-09 17:28
|
|
(as per email from Iciordia) - let´s do it this way.
as we discussed I think that our UI is already pretty sophisticated and I would prefer to keep it simple and avoid "additional" behaviour if it does not add huge value. So I am not for the count request when pressing the row counter.
Instead I would just implement the counter properly. If the grid knows the count of records (because all records fit in the current page) it should write the exact count (you know, just tell me!). If the number or records does not fit in the current page and the user wants to know the exact number of records it has push the scroll up to the end. Simple and obvious. It does not add any additional complexity to our ui and solves the problem. This solution does not just provide the exact count when requested but in all cases it is known by the grid (most Openbravo tabs have less than 100 records so you will get the exact number without any additional request). |
|
|
|
(0040054)
|
|
dbaz
|
|
2011-08-09 17:59
|
|
http://openbravo.uservoice.com/forums/13955-openbravo/suggestions/2088541-it-should-be-possible-to-request-the-count-of-reco?ref=title [^]
I think there is a point that you have missed, although maybe is pointless, since you affirm that most Openbravo tabs have less then 100 records. In large grids, the grid doesn't know where is the bottom of the scroll, so if you move the scroll to the bottom, it request new data, and it is added at the end, and then the scroll is moved to the middle of the scroll bar. Inside, for example, a 2000 records grid, maybe you have to scroll down (to the bottom) 50 times to see the end (to know the total count).
You can test what I am saying, for example, in "Tables and Columns" or in "Windows, Tabs, and Fields" in current pi |
|
|
|
(0040056)
|
|
rgoris
|
|
2011-08-09 18:15
|
|
i believe Ismael means that you would then have to re-drag over and over again to reach the end. Google Reader does the same.
Can be tedious but it is still a decent human task for a couple of thousand of records. |
|
|
|
|
I think the best solution is to "decide" when the user really wants to go to the end of the scroll. In that case it should be done in one shot without asking the user for several scroll actions to reach the end.
At this moment I see two clear cases:
-When the user drags the grid scroll to the end (maybe there are other scroll user actions that can be interpreted as "take me to the end", David?)
-When the user checks the "Select all" button (see related issue 18140)
Then we have the case of a user who wants to know the exact number or records. Once we have implemented a method to ask the grid "take me to the end", it would be simple to invoke that method when clicking the "> 100". Not sure if it makes our UI more complex (sounds like simple). |
|
|
|
(0041019)
|
|
mtaal
|
|
2011-09-16 13:12
|
|
First: currently scrolling to the next page is done by the putting the scrollbar at the end. So it is not really possible to make a difference to next page and end of set.
To get to end of the set a user can also change the sort.
Another solution can be to add a preference which allows enabling the count query for a tab. This would make the count shown to the user reliable and also would result in a correct scrollbar. Or maybe add a property to a table ('Extra High Volume').
But even then the select all is not solved.
The first 'problem' is that dragging to the end does not load all data either, it should only load the last page.
Secondly currrently selecting and processing records is done completely on the client using javascript.
If we want to support select all (also select non-loaded records) then it means that each button potentially needs to support a client side select and a server side select (select all) and processing. For example, delete currently does this:
- get the id's of all selected records
- send a delete request to the server with these id's
If we want to support select all then *in addition* we need to support this:
- if select all and not all records are loaded then, send the query/filter criteria to the server
- process the query there and execute the action
It is a fair amount of work to develop a generic server side select all (like a few days to a week). While imv there is already a fine solution: just increase the number of records to show in the grid or add a new preference 'Enable Count' or table property. |
|
|
|
|
I do not mean to interfere with the team's user interaction design but to me it is clear that the best and most intuitive option to get the actual count of records is to make the ">100" text clickable and that initiates the count.
Wanting to see how many records are returned by a query is a *very* frequent action for anybody that wants to analyze the data.
That action needs to be explicit and fast, rather than implicit (move the bar to the bottom) or slow (paginate to the end of 100,000 records, 100 at a time).
With regards to select all, I am not sure how pressing a need that would be, but I would not mix these two requests.
Certainly, there are valid business cases for taking actions on records in mass (for example: select all orders in draft status and book them) but it never happened to me to want to perform an action on more than 100 records at a time (people want to be careful in those situations and see all records that they manipulate).
If we want to implement a "select all", the interaction design adopted by GMail is a very successful and proven one:
1) You click on select all and only visible records are selected
2) A message appears stating that other records exist and giving you an opportunity to select all
3) If you select all, the action is taken on all of them.
I am not sure how much work that would be but, even in this scenario I would separate the priority of the request:
1) If you select all and there are non visible records that are not selected, the user should be informed. In other words, we should present a message alerting them that there are other records, even if we do not give them an option to select all.
2) Lower priority is to select all and take an action.
My 2 cents. |
|
|
|
(0041040)
|
|
rgoris
|
2011-09-17 13:52
(edited on: 2011-09-17 14:03) |
|
Record Count
I agree with Paolo. Let´s build the original idea (see first screenshot). Also build in a confirmation step. Would it be possible to have a loader (progress indicator) while counting the records?
Select All
The concepts of visible and invisible is not clear in our grids as there are two "visibilities": visible in view port, visible outside view port (when moving the slider bar. Gmail uses pagination, and select-all selects all items on a page (50 rows). In our case when having >100 records this won´t work (as it is not clear what the visible amount really is).
So I suggest to add a confirmation step (just as for the count) in case of a select-all action. This warns the user that the amount of records is high and that this might take a while.
See mocks. For counting replace "Select" with "Load" (if that´s really possible or "Count" if it is just a count.
|
|
|
|
(0041041)
|
|
mtaal
|
|
2011-09-17 15:58
|
|
To give some background information:
1) doing a count on request is quite doable, another solution can be to have the grid work in 2 modes:
a) non-counted which is the default, which gives an 'inaccurate' scrollbar
b) count mode, which gives an accurate scrollbar
It is quite easy to let the grid work in count mode, actually we currently send an extra parameter to prevent the count from happening, so working in count mode is not more then removing this extra parameter.
2) doing selectall also for non-loaded records is somewhat different from what we do currently. Currently it works like this:
a) select (all) records on the client, then press a button
b) the id's of the selected records are collected and send to the server
c) on the server the id's are used to execute the action
If we want to support select all incl. non-loaded records we can not send the id's from the client to the server but we need to send the query and the filter parameters to the server to be processed there and the action executed. This can be made generic so that the specific server side action implementation is not soo much extra work.
But overall, enabling count mode is far more easy (a few hours with visualization) compared to the select-all-with-action-on-the-server which is a few days (because of the new generic code on the client/server to send out the query/filters).
gr. Martin
gr. Martin |
|
|
|
(0041070)
|
|
rgoris
|
|
2011-09-19 14:34
|
|
Martin and I just discussed and we will first focus on the count. It will be implemented as follows:
1-User clicks on >100 counter
2-System loads and counts all records from the server
3-Loading activity status bar is visible while loading (either on the spot of the counter or using the common loading candy bar.
4-System replaces the >100 with the correct amount.
5-System stays in Count Mode until tab is closed.
Select all will be looked at in a later stage.
|
|
|
|
|
Rob,
what does it mean "System stays in Count Mode until tab is closed"?
I think it would be trivial to add a new small feature: after the system returns the real number records the scroll is resized to fit that count. Makes sense?
Ismael |
|
|
|
(0041074)
|
|
mtaal
|
|
2011-09-19 15:44
|
|
Hi Ismael,
The scroll is automatically resized, so that works fine. In count mode means that when the user then scrolls through the data that either the computed count is re-used or a new count is computed. So the grid switches from non-count mode (current behavior) to count mode (either by caching the computed count or recompute the count all the time).
gr. Martin |
|
|
|
|
Ok, clear.
It should cache the count, right? So only the full count is executed when the user specifically requests it.
Ismael |
|
|
|
|
I am a bit concerned with Rob's statement "System loads and counts all records from the server".
I would like to make sure that we are not planning to load all records and to count them on the client. There could be millions of very large records so this would take a huge amount of resources at all levels.
I think that the client should request the server for the count and the server should simply respond with the result (just the number).
Executing the count could be expensive for the server but at least it would not propagate the issue on other resources.
Everything else should continue working as it does now.
Can you please clarify? |
|
|
|
(0041084)
|
|
mtaal
|
2011-09-19 17:17
(edited on: 2011-09-19 17:18) |
|
Yes for sure the count is done on the server and it is done with a count query, so definitely not by iterating over the records.
To give some background info, the json webservice (which retrieves the data) when getting a request for page of data (so with a startRow and endRow parameter) will also do a count of the total records and return the totalCount together with the data itself.
If a 'noCount' parameter is passed-in then the count action is not done and the system returns a guessed count (there is some 'smart' logic which tries to make the best assumption about the count without doing a count, I can explain it separately if someone is interested :-).
As a default all our grids pass the 'noCount' parameter and receive a guessed count back.
So when we do the count action separately we need to add a caching mechanism for the count so that it is not repeated all the time, for example, pass the cached count to the server where it can be re-used or ignored if the server detects that the cachedCount is incorrect (the server knows the real count when getting the last page of data).
gr. Martin
|
|
|
|
(0044472)
|
|
rgoris
|
|
2012-01-20 17:15
|
|
|
After our little discussion yesterday, here´s a nudge to work on this one again. |
|
row-count.png (25,650) 2011-08-09 14:01