search

sfu-dhil / wilde

eXist/XQuery app for detecting copying in a collection of XHTML documents.
GNU General Public License v3.0
2 stars 9 forks source link

Work on improving the response time of the Reports page. #35

Closed rcastong closed 4 years ago

rcastong commented 4 years ago

This is now a topic of discussion rather than an issue I would say. Colette shared that she still waits 17 second for the table to load. Therefore we need to think about how to best address this.

JT had proposed that we provide access to data on multiple pages (one page for each of the different "sorting" criteria used on the current page). In discussing with Colette on Skype she's also opened to the idea of using a dynamic search mechanism on the page. So instead of using sorting or whatnot a user would perform a search. Would staticized data be possible here? Iwas impressed by how fast that is.

ubermichael commented 4 years ago

I hope this is fixed now. If it isn't, please reopen the issue. There isn't much more we can do here, other than redesigning the navigation entirely.

rcastong commented 4 years ago

Should I ask Colette to test?

rcastong commented 4 years ago

@ccolliga Feel free to discuss the issue here/below ...

joeytakeda commented 4 years ago

My guess is that the the table filtering mechanism struggles with a table of this size.

I've run some tests to test this hypothesis using the Google Chrome profiler:

Javascript Status DOMContentLoaded load Difference
On 4809.4 ms 13052.1 ms 8242.7 ms
Off 1234.3 ms 1335.0 ms 100.7 ms

What this suggests to me is that something is happening between the content of the page loading (DOMContentLoaded) and the actual final load (i.e. when you can click links etc) of the page that relies on some bit of Javascript.

As the table gets larger, the page will take longer and longer to load. So I think there are two options:

  1. We split the table into separate pages for Browse by Date, Browse by Newspaper, Browse by Language, Browse by City. This has the added benefit of disaggregating the data, which might yield some interesting results (for instance, the distribution of articles per date will be readily visible to the user since the articles will be grouped by date).

  2. Or we eliminate the filtering mechanism completely and just let people Ctrl + F and sort the table when they need to find things. Not very elegant, but it'd reduce the load time.

ccolliga commented 4 years ago

Hi Joey,

2 is not a desirable option. I think #1 is an option, or what Remi writes above: "the idea of using a dynamic search mechanism on the page. So instead of using sorting or whatnot a user would perform a search." I think you also mentioned this option in our meeting, Joey.

rcastong commented 4 years ago

It seems that we will go forward with #1. I will close this issue and create a more appropriate one.