Begin of the insertion### **Current status**

End of the insertion There are several issues when trying to provide sorting between multiple Begin of the insertionpages if we were to roll out the drag and drop features with the current way of pagination



End of the insertion Begin of the deletion pages:

* End of the deletion How can the user move between pages while dragging? Begin of the insertion

Neither backend nor frontend currently knows the entire order, as it is the frontend that inserts/updates the entire sorted set of work packages

It is not possible to retain a complete order, since new work packages may be added outside of manual ordering (e.g., lists filtered on status will return new work packages with that status)

End of the insertion Begin of the deletion
* End of the deletion The frontend Begin of the insertionhas no knowledge ofEnd of the insertion Begin of the deletion cannot saveEnd of the deletion the Begin of the insertioncontent /End of the insertion Begin of the deletion fullEnd of the deletion order Begin of the insertionof other pages

The page sizes are user specific, different page sizes would currently result in losing elements that are not onEnd of the insertion Begin of the deletion since it only knowsEnd of the deletion the current page Begin of the insertionof the last saving user



### **Known frontend approaches**End of the insertion

Begin of the insertionThis section looks at potential solutions from the user's side and their technical implications. We do not look at how the drag & drop order would be saved for each solution.



**A) Keep currentEnd of the insertion Begin of the deletion **Solution idea**

* DisableEnd of the deletion pagination Begin of the insertionapproach**

(+) It's what OpenProject users know already (Least suprise argument)

(+) Users can select a pagesize that fits their needs

(–) Drag & Drop between pages is not UX-friendly, needs buttons/controls to move an element between pages

(–) No known reference implementations that use drag & drop and pages together



**B) Restrict maximum elements to one page, not allowing displaying more than N elements**

(+) Same view (pagesize)End of the insertion for Begin of the insertionall users. It's clear that at max N elements can beEnd of the insertion Begin of the deletion manuallyEnd of the deletion sorted Begin of the insertion

(–) What is the correct size for N? It will wildy differ between use-cases (gantt chart, lists)

(–) Not possible to see what the elements after N are

(–) Approach is not feasible for automated queries where a user wants to exhaust all results. This would thus be special for manual sortingEnd of the insertion Begin of the deletion listsEnd of the deletion and Begin of the insertionthe frontend switches between paginated/restricted results.

(–) For large N, this might result in sluggish behavior for weaker devices / mobile



**C) Virtual scrolling:End of the insertion Begin of the deletion gantt charts.
* Possibly:End of the deletion Load Begin of the insertionall results, but only display the visible slice**

(+) Frontend has complete knowledge of the results

(+) Controls are very easyEnd of the insertion Begin of the deletion small pages consecutivelyEnd of the deletion to Begin of the insertionunderstand. You scroll where you want to be. Same behavior as on mobile apps

(–) SlowEnd of the insertion Begin of the deletion improveEnd of the deletion initial loading Begin of the insertionsince the entire result set needs to be known, or at least a slice of the data (i.e., all work package IDs returned from the query)



**D) Infinite scrolling / Load more: Start with N elements, load M elements after button click / scrolling to the end**

(+) Controls are easy to understand, you click "Load more" or scroll to the bottom to load more elements

(–) We would need to fetch all N+M elements if some otherEnd of the insertion user Begin of the insertionhas loaded more and sorted them. Returned elements would differ per query depending on whether someone sorted the lists

(–) Sluggish as soon as "Load more" has been clicked multiple times (basically the same as a single page)





### **Known drag & drop approaches**

This section looks at potential technical approaches to persisting the order



**Current**

Frontend persists the entire order of ids \[id, ..., id\] upon every request

(+) Backend has no maintenance effort

(+) Backend does not need to know or compute positions of other elements

(+) Newly added elements do not have a saved order and are automatically returned in the end of the list

(–) Not possible to update individual elements

(–) Not possible to collaboratively insert elements from two devices, the later executed order wins

(–) Not possible to sort in filtered lists, since saved position will be absolute numbers from 1 .. N in the visible work packages

(–) Frontend needs to know the entire current order (breaks ordering of other pages)



**Order as attribute of work package**

Save the position as an attribute of the work package

(+) Order is always known to the frontend for each work package

(+) Updating order can be reduces to (INSERT before/after position) depending on what the position is (integer, float, string rank)

(– / +) Order is global, two lists will never have a different order. Updating one list will update all others. This may be desirable in some cases, but will definitely be undesirable in others (i.e. maintaining order of my personal todo list)

(–) Backend needs to perform maintenance of the position in case values get too large



**Relative order as global attribute of query**

Instead of returning only the sorted list of work packages, return the position of each work package to the frontend

(+) The frontend can perform delta updates on the positions (even in separated page) by simply switching positions or adding positions in such a way that the value sits between to elements

(+) Collaborative updates become possible without destryoing each others' order

(–) Still not possible to move items between pages, since their order again is not known.

(–) Positions are not absolute and do not correspond to pages (i.e., they will be large numbers to allow moving elements between)

(–) Backend needs to perform maintenance of the position in case values get too large or small (i.e., when fractioning)

(–) Frontend will need to know positioning scheme to assign initial positions when switching to manually sorted mode, or backend needs to save positions when returning queries



### **Comparison with other vendors**



Jira:

Global lexorank (string-based) order saved as attribute of work package

Default rank: unknown



Gitlab:

Global relative order saved as attribute of work package

[default order is 1073741823](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/db/schema.rb#L1164) and results in position that equals end of list / board



Trello:

Per-board (i.e. global) integer/float order saved as attribute of work package

A board will never have insertions that are not made by a userEnd of the insertion Begin of the deletion experienceEnd of the deletion