Add drag/drop within the same account

[Yamakasi]

Would it be an idea to add de possibillity to drag/drop messages within the same account between folders ?

[marclaporte]

I hope we can support drag and drop messages even between accounts

[marclaporte]

@jasonmunro Are you OK if we use https://github.com/SortableJS/Sortable ? This is our usual tool in Tiki.

Thanks!

[dumblob]

Or maybe one of the following:

https://github.com/bevacqua/dragula https://github.com/mindplay-dk/zero-drag

[andonov85]

It looks like moving data between lists, so SortableJS looks appropriate to me.

[marclaporte]

https://github.com/mindplay-dk/zero-drag/commits/master

Last commit 2018. IMO, that disqualifies it.

[marclaporte]

https://github.com/SortableJS/Sortable/blob/master/Sortable.js is indeed bigger than https://github.com/bevacqua/dragula/blob/master/dist/dragula.js

Last commit in 2020-09 (15 months is not a disqualifier but a concern) https://github.com/bevacqua/dragula/commits/master

Another topic: should we use minified version?

• https://github.com/SortableJS/Sortable/blob/master/Sortable.min.js (43 KB)
• https://github.com/bevacqua/dragula/blob/master/dist/dragula.min.js (13.6 KB)

[marclaporte]

Here is what Sortable says: (not an objective point of view) https://vimeo.com/311584137

[marclaporte]

Using the data from:

• https://github.com/SortableJS/Sortable/
• https://github.com/bevacqua/dragula/
• https://www.openhub.net/p/SortableJS
• https://www.openhub.net/p/Dragula
• https://www.openhub.net/p/_compare?project_0=SortableJS&project_1=Dragula

Both are very popular in terms of watches, forks and stars.

SortableJS: pull requests: 14 open vs 456 closed Dragula: pull requests: 51 open vs 134 closed

SortableJS: issues: 338 open vs 1262 closed Dragula: issues: 97 open vs 406 closed

In general, for pull requests and issue management, SortableJS has more activity and is better maintained.

SortableJS has had 99 committers vs 33 for Dragula.

One more factor: we have a front-end developer (@andonov85) who knows SortableJS well, and can support it.

So IMO SortableJS wins here, even if heavier.

[marclaporte]

So I did a bit more research. Here is a good way to discover options: https://github.com/search?o=desc&q=drag-and-drop&s=stars&type=Repositories

The top 2 most starred (SortableJS and Dragula) have been discussed above.

3rd most starred is: https://github.com/Shopify/draggable https://www.openhub.net/p/draggable-library

It has an impressive demo: https://shopify.github.io/draggable/ But in 2019 "Draggable is no longer maintained by its original authors." "Maintence of this repo has been passed on to new collaborators and is no longer worked on by anyone at Shopify." "We are still looking for more maintainers!" Source: https://github.com/Shopify/draggable/commit/84b8a5f54c0f9fbc830f22e3b580993a341d0df0

4th most starred is: https://github.com/taye/interact.js https://www.openhub.net/p/interact_js

5th most starred is: https://github.com/haltu/muuri https://www.openhub.net/p/muuri

[dumblob]

I've opened my stash and typed "drag" and this is what I got (except for those mentioned in this thread already)

https://github.com/desandro/draggabilly https://github.com/catc/displace https://github.com/gtramontina/draggable.js https://github.com/giraysam/viiny-dragger https://github.com/yckart/DragValue.js

Feel free to take a look at them (some are so small that they don't even need any maintenance nor development any more - they are 100% stable with zero missing features and no known bugs).

[marclaporte]

@andonov85 What do you think?

[andonov85]

I like https://github.com/desandro/draggabilly, in fact its author is a creator of other very cool libraries https://desandro.com/, so this is my favorite on the list of smaller size libs. Comparable to https://github.com/SortableJS/Sortable I think their size is proportional to the features they offer out of the box. We use almost all the features of Sortablejs, with a simple configuration and without the need for additional code, which we will eventually have to write again for the library that does not offer these features. I put this as a great advantage of Sortablejs, along with the others that @marclaporte has described above.

[dumblob]

We use almost all the features of Sortablejs, with a simple configuration and without the need for additional code, which we will eventually have to write again for the library that does not offer these features. I put this as a great advantage of Sortablejs, along with the others that @marclaporte has described above.

I don't think the difference in size is a disaster but what you wrote seems to me out of context here in Cypht. We have 40k+ installations and only quite few (hundreds?) are through Tiki IMHO.

So IMHO we should focus only on Cypht alone as our context when deciding how Cypht will behave (especially on devices connected through constrained network connections).

IMHO >80% of all the mentioned libraries in this thread adhere to the requirements (in this order):

1. ensure seamless UX on touch devices as well as "persistent pointer" equipped devices
2. ease the work with draggable objects code-wise (especially due to the 1. requirement)

Everything else seems debatable.

Because Cypht is lightweight not just by itself, but more importantly bandwidth-wise on client, I'd say the next most important parameter really is size. It's not about potential features Cypht might use in the future (this is one of the historically biggest SW fallacies). Nor about features we can use right now "because we can" (i.e. because the library has it and it's easy to implement/use it) - that's also wrong as it burdens future maintenance & development (due to the general feeling/consensus to maintain a kind of backwards compatibility - be it UX-wise or UI-wise or API-wise or just expectations-wise despite the given functionality was originally a nice-to-have it's always enormously painful to change or remove it).

So I'm still undecided on which one to choose. I'm though confident that in case of Sortablejs we need more compelling arguments to outweight the size requirements of Cypht usage scenarios (not Tiki usage scenarios).

Maybe this whole discussion is a straw man and it'd be easy for Cypht to just wrap the few calls Cypht will use from some tiny lib fitting Cypht use cases to promote the dragging functionality into an internal quasi-modular API in a way so that Tiki can easily throw away the tiny lib and instead provide a shim wrapper on top of Tiki's Sortablejs. Or maybe some other solution...

Note it's never "either or". The world is not black & white. We should thus not try to find a one-size fits all solution but something which makes it easy to optimize for both projects (Cypht & Tiki) individually without compromising each other.

Thoughts? Suggestions?

[marclaporte]

I acknowledge your point of view.

There are many other features in Cypht that could use some attention (like filters!). The time we invest here takes away from other things we can improve.

I am against picking libs that have seen no commits in over 1 year. I know some will say it's because they are feature-complete. But active projects are much more likely to adapt if and when we need them to.

All the proposed options have been looked at and I think the current proposal with SortableJS is "good enough". It is easy to change later if desired.

[marclaporte]

@dumblob I like https://github.com/desandro/draggabilly because it's lightweight and active but @andonov85 informed me it doesn't support multidrag which is something we want right away (ex.: pick 4 emails, and move to a folder). It also doesn't support cloning (lower priority but some could want drag-copy of emails)

[dumblob]

I'm fine with accepting Sortablejs as a temporary solution ("temporary" should be part of a comment in the source code of the corresponding PR).

I also fully understand how uneasy and tedious it feels if someone is such a protester as I'm here (I've managed mid-size dev teams for several years in my past).

Let me first apologize for forgetting that the first requirement "seamless UX on touch devices" encompasses multidrag and thus the percentage I've used >80% is plain wrong.

Multidrag is super difficult to get right on mobile devices (there are multiple ways to achieve it, but from my experience libs generally do get it wrong :cry:).

So thank you @andonov85 and @marclaporte very much for pointing this out!

Now let me emphasize a few things.

1. I feel the preference for the black & white solutions here in this thread. I'm in no way a fan of those. They lead to highly compromised solutions and unnecessary suffering (in this case it's mainly the ~40k end users on low bandwidth connections - Cypht currently sends maybe about 140k JS on first connection). Please use your (technical, social, research, ...) abilities to find smooth solutions which fit both/all projects (incl. their user bases) instead of (unconsciously or not) sharpen the distinction between such options.

2. My experience clearly suggests any "project activity" measure is an utterly wrong assumption especially speaking of such (very) small SW libs.

   1. We absolutely do not want the libs to change in any way in the future. By definition that only brings more work for us. Thus we should put some non-negligible effort into ensuring we will not need them to adapt/change/whatever in the future.

      Note, we don't talk security bugs here as that doesn't apply in our case.

   2. Reality is much more complex and more often than not (especially with such smaller projects we're discussing here) these feature-complete projects offer better and faster support unlike projects which still develop their libs and thus have a plan which is by definition a prioritization question, unknown deadlines, larger community involvement (i.e. slow), more difficult to make PRs for them (because the code is more complex and usually must maintain certain level of backwards compatibility), etc.

3. The main killer feature of Sortablejs (multidrag) never worked on mobile devices and it still doesn't. This is a recurring topic in the Sortablejs tracker. The most recent bug is ~1 year old with zero response from devs. I.e. this clearly shows "project activity" has nothing to do with our use case in Cypht.

   The best workaround is to simply defer loading of Sortablejs (to save bandwidth) and let it load only on non-mobile devices.

4. We need to be active to really see through the dense nest of arguments and capabilities of individual libraries. In that vein I've now asked about multidrag in several drag lib repos. Let's see what'll come out of this.

   1. Edit: displace is out of question.

That's why I'm still undecided.

[marclaporte]

@dumblob Thank you for the detailed insight on multidrag and touch.

[marclaporte]

@jacob-js Please do a deep dive on this.

Some guidance: https://dev.tiki.org/How-to-pick-a-software-library

[jacob-js]

3. The main killer feature of Sortablejs (multidrag) never worked on mobile devices and it still doesn't. This is a recurring topic in the Sortablejs tracker. The most recent bug is ~1 year old with zero response from devs. I.e. this clearly shows "project activity" has nothing to do with our use case in Cypht. The best workaround is to simply defer loading of Sortablejs (to save bandwidth) and let it load only on non-mobile devices.

I don't perceive this as a bug; for me, it's functioning as intended. The issue is summarized as follows: Multidrag prevents scrolling through the list of items; instead of scrolling, it triggers the drag-and-drop effect on an item.

In my opinion, this is a matter of preference — whether you consider it a bug or not. Even in a non-multidrag scenario, scrolling through the list will still produce the 'dragging and dropping' effect unless you perform the scroll outside of the relevant list.

However, if you label the feature as multidrag-non-single drag, we could categorize this as a bug. As long as Multidrag can also function for a single element, I don't see a need to restrict the selection of that element beforehand.

[marclaporte]

Deep dive analysis is happening here: https://dev.tiki.org/Decision-Analysis-for-Drag-and-Drop-Library-for-usage-in-Tiki-and-Cypht