Content
View differences
Updated by Jens Ulferts almost 6 years ago
### User Problem
#### User
_Users with access to more than ca 30-50 work packages among which are:_
* Project manager
* Project member
* Product owner
#### Problem
The initial loading of the work package table can be quite slow especially if a large page size is selected. The large page size is typically selected by users who want to plan and/or get an overview.
#### Pain
* Wait
* Decrease page size which limits the value of the view
### Business Case
#### Confidence
* Slow backend
* Overhead of transporting data from backend to frontend
#### Urgency and Priority
We get a lot of complaints regarding the poor performance
### Solution
We currently load data for the whole pageSize. So if a user chooses to display 300 work packages per page we load 300 work package from the backend. But we can only, and thus only need to, display a much lower number on the screen when the page loads. Therefore, we can:
* Load only as many work packages as can fit the screen, regardless of the page size the user selected.
* Render the table for the subset,
* Load the rest (or all) of the actually desired page without the user noticing.
* Render the whole of the table.
#### Out of Scope for the MVC
* Remove page size in favor of infinite/virtual scrolling.
* Speed up backend
* Speed up table rendering
#### Differentiation
* A pleasant working experience without being interrupted by wait time
#### Next iteration
* Increase Backend-Performance (JSON in DB, signaling)
* infinite/virtual scrolling
### Launch and Growth
#### Measures
* No more complaints about poor performance on initial page load
#### Messaging
_If you were to write a press release, how would you describe the value to customers?_
<figure class="table"><table><tbody><tr><th>Headline</th><td></td></tr><tr><th>First Paragraph</th><td></td></tr><tr><th>Customer Quote</th><td></td></tr></tbody></table></figure>
#### Go to market
_How are you planning on getting this into users' hands?_
#### User
_Users with access to more than ca 30-50 work packages among which are:_
* Project manager
* Project member
* Product owner
#### Problem
The initial loading of the work package table can be quite slow especially if a large page size is selected. The large page size is typically selected by users who want to plan and/or get an overview.
#### Pain
* Wait
* Decrease page size which limits the value of the view
### Business Case
#### Confidence
* Slow backend
* Overhead of transporting data from backend to frontend
#### Urgency and Priority
We get a lot of complaints regarding the poor performance
### Solution
We currently load data for the whole pageSize. So if a user chooses to display 300 work packages per page we load 300 work package from the backend. But we can only, and thus only need to, display a much lower number on the screen when the page loads. Therefore, we can:
* Load only as many work packages as can fit the screen, regardless of the page size the user selected.
* Render the table for the subset,
* Load the rest (or all) of the actually desired page without the user noticing.
* Render the whole of the table.
#### Out of Scope for the MVC
* Remove page size in favor of infinite/virtual scrolling.
* Speed up backend
* Speed up table rendering
#### Differentiation
* A pleasant working experience without being interrupted by wait time
#### Next iteration
* Increase Backend-Performance (JSON in DB, signaling)
* infinite/virtual scrolling
### Launch and Growth
#### Measures
* No more complaints about poor performance on initial page load
#### Messaging
_If you were to write a press release, how would you describe the value to customers?_
<figure class="table"><table><tbody><tr><th>Headline</th><td></td></tr><tr><th>First Paragraph</th><td></td></tr><tr><th>Customer Quote</th><td></td></tr></tbody></table></figure>
#### Go to market
_How are you planning on getting this into users' hands?_