[FEATURE] Performance improvement: Don't reload whole dashboard when closing a ticket

[CodeShakingSheep]

Is your feature request related to a problem? Please describe.
I have a kanban board with ~180 tickets. Whenever I open a ticket, edit it and then close it, upon closing the ticket a full reload of the board is performed which takes very long (> 10 seconds).

Describe the solution you'd like
From a technical perspective I wonder why the whole board needs to be reloaded although only 1 ticket was changed. So, I would prefer a solution where only the edited ticket is reloaded on the board (but not the whole board itself).

Additional context
Bare metal self-hosted version 3.1.4.

[gloriafolaron]

Appreciate the insight here and agree -- this loading process is something we've been making updates to as we refresh and make improvements throughout the system. This is one area we'd like to tackle.

If you have time sometime, even if it's just a via email and with some questions -- I'd love to learn more about what your workflow looks like that you have 180 to dos on it. It's helpful for us to have a better understanding of how folks are setting up the projects to get there.

[pvi-github]

Hello,

As the ticket editing form seems to be a modal overlay we could intercept the POST submitting with javascript (not only the close ticket event), to do the post through a background javascript call and then close the modal overlay without reloading the page.

Now for kanban update we could implement a web service that provides a json structure of the data needed for the ticket div into the kanban and a javascript updating function that seeks and updates the DOM (updates and/or moves) for a given ticket id (or several tickets id to make it more generic see why here under)

Further thought we could have also a heartbeat functions that gets from an other WS the list of ticket id that were updated since last call (and then update these through the previous logic) => kanban would become dynamic without reloading.

[pvi-github]

For the volume in real life 180 tickets is not uncommon even for tiny projects.

50 user stories => 50 tickets.
50 user stories => x 2 or 3 technical tasks for sprints => +150 tickets
20 or 30 generic tasks (infrastructure, design, project managements) => +30 tickets
20 or 30 bugs => +30 tickets

I think for a fantastic tool like Leantime it should be able to deal with 500 tickets without even leaving a droplet of sweat.

[gloriafolaron]

@pvi-github I hope I didn't make it seem like 180 was unreasonable -- because you're right and I don't think it is either. It's easy to get to --

We've just found that, when looking at the spectrums of folks using PM tools or a Kanban view, there is good chunk of them that will find the view overwhelming and even abandon a Kanban entirely because of it.

Now, in our case, if it's loading like this -- that's one reason to abandon it but these interviews were done with regard to experiences in other tools built specifically for Kanban usage.

There's a cognitive load challenge that comes with too many and then the brain just stops viewing them.

The conversation, though, brings up 2 things for me --

1. Correcting the way things load (on our roadmap as we go through and improve code, this has been a priority) and then

2. Looking at: are there any ideal scenarios to support completed tasks to a better view or another way to visualize them?

We have some roadmapped ideas around post completion (it's hard to see what you accomplished recently once your done list grows) but I'm wondering if there are other ways as well that we can test.

We have found folks are more likely to abandon a project (depending on the team and role size) and start a new one before they are to clean up the one they're currently in. There may be ways we can help support this cognitive load as well.

Would love any thoughts you'd have on this.

Thanks!

[CodeShakingSheep]

@gloriafolaron I love both of your suggestions. Making the kanban board dynamic is a must-have for me in regards to performance. So, I appreciate you guys looking into that.

Regarding my work flow, it's a long-term project which has been running for ~1 year and ~150 of the 180 tickets are in the 'Done' column. I believe currently there's no option to archive done tasks or anything similar to get them off the board to make the board shorter, right? That's why I also love your second suggestion about implementing a dedicated view for completing tasks. If you need any more input with this let me know.

[pvi-github]

@gloriafolaron thanks for your feedback.

There are 2 different topics (with connections but...) :

1. Making Kanbans more "light" and easier to use for day-to-day work
2. Avoid that people throw in the towel

For 2 ease of use is only one of the possible components of the cocktail. We have also:

1. Pleasure to use : fun, dopamin production => That's how social networks keep people
2. Hype : the feel to be part of the "extraordinary people" => For this you're already on an interesting path : Opensource, cool and welcoming community, nice logo, good website...
3. Productivity & speed : doing things quicker, faster, easier, better than others.

Suggestions for 1: the principle of dopamin (pleasure hormon) production is that it's produced by the body as a result of rewarding message (good job Steve!) or sense of achievement (yes I did it on time)!
Here you can use the dashboard and the reports to add value : histogram of tasks that i started and finished... today, yesterday, since the beginning of the week, since the beginning of the month, last months, etc.

The reports can also provide value : most active contributors,

And the workflows can serve too: if the task is finished before the deadline or with a lower hours spent than planned => Notification of great achievement (that can be kept as a track record of wonders)... after several "rewards" of the same kind (brainstorming to find other kind of rewards) people could earn badges that would be shown on the team avatars...

Suggestions for 2: here we need to enter more deeply in the project management practices. Let me i propose some food for thought:

1. Stories are not really tasks : stories need to define involved personas, describe the use case as a story (in cooperation with people who can speak about the user needs), then get technically analysed (by people who can tell how to satisfy he need), then approved, then split into realization tasks and evaluated through for example poker planning sessions...
   You could consider to working on the user experience to :quickly create personas names and stories titles in a interface then work on each of them, then create the tasks to satisfy the need and run poker planning sessions to size effort.
   We already have retrospectives : we lack planning & story design.
   This would remove stories from the task list and improve Leantime users ability to launch projects.
2. If we get back to the agile concept of backlog : the idea is that items in the backlog are technically analyzed and the effort roughly evaluated then they are prioritized and distributed in sprints.
   If the project team is sized to cope with X efforts points / "standard sprint time" (let's imagine 3 weeks) and all the tasks have their effort points evaluated then we could automatically create sprints, distribute tasks into sprints, and save tens of hours to project managers.
   After that the Kanban can be simplified by a default filter : current sprint could be considered by default.

I stop there because I've been far too long. If you find this useful and want to discuss that further we will find a way.