Encountering slow navigation to a card containing very large fields? Do this one simple trick.

[Richard Gaskin]

Thank you, David. That does indeed help a lot.  Very interesting task, 
actually. Very glad to have read that.

In most workflows there's little need to display such long lists for 
users to wade through.  But in your case it's clear that the nature of 
the work requires laborious review of details, so even a super-long list 
is not a design problem at all, but arguably essential.

That said, if I understand this correctly, only the subset of records 
that first match the search criteria will need to be reviewed - is that 
correct?

If it is, you can omit the display of the first list, enjoying not only 
ending the need to have that field's rendering eat up time, but also the 
speed boost from handling that data in a variable.

But the results list does need to be displayed.  And since that list may 
be long, I concur with those who have recommended the DataGrid as a 
solution.  Sure, it takes a little setup, but the payoff is that it will 
only render what can be viewed on screen at any given time, which should 
give you the smooth card-to-card speed you're looking for.

-- 
  Richard Gaskin
  Fourth World Systems


David V Glasgow wrote:

> Maybe context would help.  I receive digital evidence from police Hi Tech Crime Units, consisting of lists/tables of messages, search histories, web histories, files downloaded, etc etc.  These relate to online activities of alleged internet offenders. Some consist of data relating to a few months activity, others may be 10 years or more - so vary hugely in the sheer quantity of data. This is what is imported into the first field.
> 
>  I have established a number of sets of keywords/tags  which can be cycled through using ‘filter with’ to find list items which might indicate particular forms of malign motivation of the alleged offender. So, a user clicks button “Filter with X keywords” looking for, for example,  coercive/aggressive tags.
> 
> All ‘filtered with' lines containing selected tags appear in the second scrolling field. Sometimes nothing much will be found, but sometimes this field may become 50 to 74% the size of the field containing the original  imported data.  This (second) field can be scrolled and eyeballed until something of forensic significance is spotted.   Clicking on that line scrolls the first field to display and highlight the line in its original context (i.e showing preceding and following lines).  
> 
> With respect to Bob’s observation about the work to display a background group being 'already done’ if the navigated-to card contains the background group containing the field, that is pretty much what I assumed is happening.  The intriguing question is why the work necessarily  is ‘undone’  when navigating to any card not containing the group.  Does it consume such significant resources the default is to clear it?  It would be nice to be able choose to preserve or cache the work if that has such a significant impact on performance as in this case.