Data mover / migration / export tool

[rfc2822]

Recreated from https://github.com/bitfireAT/davx5/issues/112

---

Originally opened by @rfc2822 on 2022-07-31T12:17:16Z

This issue is to track ideas and implementation of the "Data mover" we have already talked about and that should be integrated into DAVx⁵.

@devvv4ever Could you please provide information about what's the purpose of this tool and how it could look like?

[rfc2822]

Original comment by @devvv4ever on 2022-08-03T09:42:08Z

There are a few use cases/things for a migration tool that come to mind:

Main and necessary functions that should be covered in initial release

• People want to get away from Google and want to take their data with them to a new server. Or they want to get their locally stored data (local/SIM address book or locally stored events) onto a server
• They often ask for some kind of backup. They usually like to have data in a file that they can copy and/or backup somewhere
• Users want a simple way to transition their data from one server to another

Extended functions

• Cleanup functionality is also often asked for (delete duplicate entries)
• Load ics/vcf files and repair it's data
• We should consider taking tasks data off Samsung Notes, Google Notes, Evernote or One Note and make them VTODO/VJOURNAL compatible so that it can be used within open protocols.

Experimental functions

• Some persons asked for "automatic server cloning" - they want to replicate data from one server to another on a regular basis

We should guide users through this process with a reasonable bunch of details and information (i.e. show number of entries) and give feedback

Another use case: People have set up DAVx5, after that the Base URL changes (currently not possible to change this in DAVx5) and they need to create a new account but still have unsaved data in the old account. They could then move data from the old account to the new one (but with possible duplicates of course :-/ if they already have some data on the new account and the same on the old one - we might have to think about that case too).

[rfc2822]

Original comment by @devvv4ever on 2023-01-03T20:00:49Z

This is my idea of a migration tool with the example of copying contacts from one account to another.

[rfc2822]

Original comment by @sunkup on 2023-01-04T09:32:43Z

Nice, looks good!
Using Workmanager to perform the actual move/backup operation, it would not matter if the user closes (or even kills) the app, as work requests are passed to and handled by the system/workmanager. DAVx5 can just query in whatever state the work is, when restarting/resuming after having been killed/closed.

There should be no need for the information about not kiling or closing the app in the bottom :)

[rfc2822]

Original comment by @devvv4ever on 2023-01-04T10:53:07Z

Nice, looks good! Using Workmanager to perform the actual move/backup operation, it would not matter if the user closes (or even kills) the app, as work requests are passed to and handled by the system/workmanager. DAVx5 can just query in whatever state the work is, when restarting/resuming after having been killed/closed.

There should be no need for the information about not kiling or closing the app in the bottom :)

Ah, thats good to know :D

I also thought: when a user clicks the checkbox of an address book the selection window should always open and pre-select all contacts (that is the normal case I guess?). Checkbox should have the checked state whenever there is 1+ contacts selected. If they want to un-select the address book at all they need to have 0 contacts selected in the dialog and save this selection.

[rfc2822]

Original comment by @sunkup on 2023-04-25T08:42:51Z

I also thought: when a user clicks the checkbox of an address book the selection window should always open and pre-select all contacts (that is the normal case I guess?). Checkbox should have the checked state whenever there is 1+ contacts selected. If they want to un-select the address book at all they need to have 0 contacts selected in the dialog and save this selection.

Or we use an icon indicating that the address-book is only "partially selected". I have seen the "indeterminate checkbox" being used for that a lot,

but personally I find it very confusing, so if we were to add another icon, I would use something different, like the "Rule",

"Checklist Rtl" and "Event List".

What do you think @devvv4ever ? :)

[rfc2822]

Original comment by @devvv4ever on 2023-04-26T15:23:32Z

Mhmmm the "rule" is be a good approach I think :)

So basically then the select icon (like in the 2nd screenshot) would not indicate that it can be clicked but rather show a state of current the selection (optionally in an additonal color):

None: icon "Event List" (in grey color)
At least one selected: "Rule" (in orange color)
All selected: "Checklist rtl" (in green color)

[rfc2822]

Original comment by @patrickunterwegs on 2023-04-26T15:40:28Z

If say if you anyway show the number of selected entries next to the checkbox, is the checkbox actually necessary?

I'm afraid it might get so easy to understand, that the user can also click on the card to select entries. Maybe you can remove the checkbox and users can just use the select all option?

By the way this would be a beautiful thing to do in jetpack compose 😉

[rfc2822]

Original comment by @devvv4ever on 2023-04-26T15:50:05Z

If say if you anyway show the number of selected entries next to the checkbox, is the checkbox actually necessary?

I'm afraid it might get so easy to understand, that the user can also click on the card to select entries. Maybe you can remove the checkbox and users can just use the select all option?

True. We could try leaving it without any icon :) Lets see how it is looking then. Could be a bit much text then and icons can always make things more appealing. I'll try that in GIMP first and check it out!

By the way this would be a beautiful thing to do in jetpack compose wink

;-) Yeah... Maybe in 2024 or so ^_^

[rfc2822]

Original comment by @devvv4ever on 2023-04-26T16:07:40Z

No Icon vs State Icons

What do you think? @patrickunterwegs @sunkup

[rfc2822]

Original comment by @sunkup on 2023-04-27T08:39:08Z

Hmm, this is really hard. I think with and without icons would work. I guess it really depends on whether colors are used or not. When the green and orange colors indicate that all or some contacts have been selected, we don't really need the icons anymore.

At the same time I am not a huge fan of the green and orange colors though, as I feel they convey a meaning. Ie.: green=good/well done and orange=bad/error/false - indicating that you should select all contacts. Also, now that I actually see it in front of me, I feel the icons make the view look a bit cluttered when all three are so detailed.

How about this: We use green only if all contacts have been selected and a light blue (instead of orange) if contacts have been partially selected. Optionally we could try using the less detailed icons for all or no selections instead.

None: 0/100 in grey color (maybe "Check Box Outline Blank")
At least one: 63/100 in blue color (maybe "Rule")
All selected: 100/100 in green color (maybe "Check Box")

Thanks for the designs, it makes it so much easier to consider! :D

EDIT:
Coming back and looking at this another time I feel the icons are just fine. They do clutter the view a bit, but they make it so much easier to grasp what is going on quite quickly. UX wise I think we should keep them and just make the partial selected ones blue or no color (grey/black) :)

[rfc2822]

Original comment by @patrickunterwegs on 2023-04-30T18:35:31Z

Personally I am not a big fan of those icons, so I like the textual approach a bit more. Also the green and orange colors are nice (I guess in the left screenshot the partially selected entries should also be orange). But anyway, this is maybe just my personal taste preference ;-)

One thing to consider about the colors:
If you consider implementing dynamic colors/M3 in the future, the dedicated green and orange should be avoided.
Instead it would be good to just take the primary color for the case when all are selected. For partially selected maybe the secondary color (or also the primary color) could be taken. And for none selected I guess you would anyway have done it through opacity and not by using an explicit grey color). Anyway, that's just some sidenote to maybe consider for the implementation.

[rfc2822]

Original comment by @devvv4ever on 2023-05-02T20:18:00Z

I got a step back with the colors. Only using one neutral blue color on a selection with 1+ items. That would avoid using any primary and secondary colors as Patrick mentioned. And the icons are also not colored driving attention a bit away from them and maybe make them more supportive and less cluttering.

What about these approach(es) ;-) @patrickunterwegs @sunkup

[rfc2822]

Original comment by @patrickunterwegs on 2023-05-02T20:26:28Z

I hope I was not confusing with my explanations, but I actually meant it's good to have the elements that you want to highlight in the primary color. It was just about the 'half' selected collections where the color could not match in the future.
If you choose an individual color now, you will face the question which color to use again when you switch to material 3 (if you switch). 😉

But to make it short, I personally like the highlight color in the primary color, ie green 😉

[rfc2822]

Original comment by @sunkup on 2023-05-03T08:13:47Z

Nice!
If we were to not use the icons, the colors of fully vs partially selected lists should be different.

But I am quite happy with the left variant (with icons) 👍

What is your own opinion on this though @devvv4ever ?