I don’t remember exactly the actuel registration flow but @goob 's proposal is the most useful one in my opinion because it merges the migration tool in this flow .
Keep in mind that this tool will be used more and more in future
The green field ‘validation was successful’ I see it skeptically.
A validation run takes several minutes in my tests. (Old account, some hands full of posts). It takes even longer with old and very very active accounts.
So the validation process and actual import are not close together.
Maybe the validation process itself could be striped down very hard to just a syntactically test and not to check every post?
The Pull Request Migration: Fixing import issues / Speed up repeated unknown pod detection by tclaus · Pull Request #8257 · dias has a history of what is and should have done in the validation process.
If the user should see if everything is OK, the validation should only take less then 10? seconds.
Btw, I have dozen of users coming from the Framasphere closing pod to diaspora-fr.org everyday. As diaspora-fr is running the develop branch, I could propose to some of them to be beta testers and try the migration that I would launch manually with the command line. I would need at least Fix archive import for reshares of down pods by jhass · Pull Request #8017 · diaspora/diaspora · GitHub to be merged first though. Also probably Migration: Fixing import issues / Speed up repeated unknown pod detection by tclaus · Pull Request #8257 · dias. Let’s motivate ourselves and also progress on those topics?
1 Like
The more I think about it, the more I’m wondering if it is a good idea to modify the registration flow to include the migration. I can’t find a way to make it visible for users who may want to migrate without disturbing the new ones who will wonder what this is about and probably already find diaspora complicated. The point of @tclaus saying that the validation takes a lot of time and that we will need to ask the user to come back anyway just confirmed that we can’t insert this in the middle of the registration flow.
So what about simply adding a sentence to explain to the users which may be interested that they need to go to the settings to do that once registered?
1 Like
I like it. (As I liked your first proposal)
- no frills
- easy
- only few people are affected
- those who are interested in the function, would know how to use it
Here is how it could look like:
(Yeah, I revamped the UI. I needed a color so I picked that orange but this can easily be changed if you have suggestions. It is responsive now.)
I’m not sure about the wording, especially this one: You’re about to create an account on diasporaaa*. One diaspora* account is enough to reach the whole network, you don’t need to create a new account here if you already have one on another pod.
Other suggestions welcome, but please keep the text short, people are not reading…
I like it- really. Now you have the new problem how to adapt this design-language to all other parts of Diaspora…
For me: I really like the into. New users can create a new account without to make a decision on this step.
Import the stuff in the settings. For me: OK.
To discuss the new design, I opened a PR: New registration page by Flaburgan · Pull Request #8285 · diaspora/diaspora · GitHub to avoid this thread to go out of topic. Let’s focus on the migration flow 
2 Likes
If have updated the UI - PR https://github.com/diaspora/diaspora/pull/8274
Here the UI is minimal, just as the early preview.
An extra “validation” step is not included, because its just a internal pre-work, not a check for the user because of its runtime.
A User must register first (Fla has a concept to inform new User how they can import their account later), then upload profile and even photos.
Yes: Photo - upload is now included.
With this PR I’ve rebased to another PR which makes it able to upload zipped Json files.
All together is deployed on the societas (https://societas.online) pod which can be used for life testing.
Be warned: it is the first time, that this feature is deployed in the wild (as I know). Use Test-Accounts to import, not your real ones.
1 Like
Just set up a test account, shared with a few people (including you), posted a few things, with photos, reshared a couple of posts, and then migrated.
UX:
- It was simple as I knew what I was doing. It might not be immediately obvious to less clued-up users that they have to export their data and photos from their existing pod first. We can think about the best way to achieve this.
- I was expecting to have to store and import a key manually, so I’m glad that this is handled automatically.
- The UI was generally fine, although it can be refined. I stupidly raced ahead through the process without taking notes or screenshots, and without reading all the text presented to me in the warnings pane. I’ll do it with another account (maybe a real one) tomorrow and check more carefully.
- One refinement would be how the file names to be imported are presented. When I clicked the buttons to import data and photos, those (very long) file names were presented to the right of each button, overlaying other text. I’m sure we can find a way to refine this.
- The UX when the migration is set in motion could be more clear – at the moment there’s just a ‘flash’ message that’s on screen for moments and could easily be overlooked. Perhaps the migration pane could change to a message something like ‘Your data and images are now being migrated to this account. This can take a few minutes. We will contact you when the process is complete.’
- I’m really glad it’s possible to migrate more than one account into the new account. I wasn’t sure that was going to be possible.
Result:
- The process worked pretty quickly. Of course, this test account had hardly anything in it and the pod I moved to (@tclaus’s) is probably lightly used and running very quickly.
- All posts, including photos uploaded into posts, and including reshares, were successfully migrated. ✓
- All contacts were successfully migrated, including the sharing relationships. ✓
- The account on the pod I migrated from appears to have been closed successfully. ✓
- I have received notifications from a migrated contact on the first post I made from the new account and from a migrated contact on a reshared post that was migrated. ✓
- The screen name and avatar I had set were not migrated. I don’t know whether or not this is intentional.
- I didn’t receive any kind of notification that the migration process had been completed. An in-app notification would be a minimum, and an email would also be good. That might be outside the scope of this PR, however.
Anyway, it looks in a pretty good state, with a few refinements to be made, to this lay user. I have no idea what’s going on ‘under the bonnet’ in terms of security and what have you, so that would have to be checked by people who do understand that stuff, although I assume most of that work has been done in the back-end code.
One thing I would like as part of a migration feature is the ability to be able to decide which contacts are migrated. Obviously with people I am sharing with, I can unshare before migrating. But it is harder with people who are sharing with me but with whom I’m not sharing. One reason for someone to migrate is to escape stalking or other harassment, so some means of doing this would be good. Again, probably outside the scope of this particular PR, but I mention it here so it’s at least in the discussion.
One other question: is it possible that a pod running an older version of the software will have the export buttons for photos and data but not have the code to accept a ‘close account’ request from a remote pod when those data are migrated? Again, that’s a back-end question, not a UI question, but it occurred to me when I tested the process. If so, there’s a danger of duplicate and/or orphan accounts from people who ‘migrate’ but don’t realise that their old pod can’t process the close account request.
Thanks! I will try with an old account tomorrow or soon, and pay more attention to exactly what happens.
1 Like
The migration code has been here for a long time (last improvement in 0.7.5), only pods not updated for more than two years would have problems. So I would say we’re safe here.
I just tried a second test, using an old but little-used account on diasp.org.
Posts were successfully imported, including those from 8 years ago, long before the destination pod went online. Contacts that I am sharing with were also imported, with their aspects in place.
The one contact who was ‘only sharing with me’ was not imported. I don’t know whether or not this is intentional. I had ‘ignored’ that account before exporting my data, so it might be that this makes a difference to whether or not the contact is imported. I am happy in my personal case for ‘only sharing with me’ contacts not to be transferred, as I have no interest in having followers, but for some people, who post a lot publicly and/or use diaspora like a blog, it would be a big disincentive to migrate if they would lose all their followers in the process.
I set some profile information (bio, location, gender, birthday) in the new account before migrating to see if this was over-written. It wasn’t, but then again there was no information in the account I transferred. I’d have to test it again with an account with some information in it to check what happens.
Ideally there would be options to select which profile information was imported. This could be done via a pop-up list. Under ‘Your profile (name, bio, birthday, gender, etc.) will be updated from the imported account’ there could be a link ‘Choose which elements are imported’. Click this and a list with check-boxes appears:
- avatar
- bio
- location
- [etc]
It would be good to have the option, because not every import will be into a newly created account. Also, if someone migrated their main diaspora account and then remembered another older account they also wanted to merge, the old profile data from that account would (I think) overwrite the current info from the main account. So having the option which if any of this info to import would be useful.
It would also be good to have the option whether to import ‘only sharing with me contacts’. But if that is not supported in the back-end migration code, that’ll be outside the scope of this work. It could possibly added in a second iteration.
One oddity I noticed after the import: I had left the /user/edit page open, and later noticed that the green ‘download my profile’ and ‘download my photos’ buttons were visible. I refreshed the page to see whether they would still be there, as I wasn’t sure whether they are part of a new page design or had appeared during the merge process. When I did this, the flash message ‘Your account migration has been scheduled’ appeared again at the top of the page. It would be worth looking into this to check whether or not a second account closure request is sent to the originating pod when this is done. It would be worth also suppressing the flash message in this case.
I hope that’s useful, and thanks again.
2 Likes
@tclaus, I have made some suggested edits to the two larger text blocks in your PR. I’ll put them here so they are more easily discussed, as it would be good to get refinements from other people.
For app/views/users/_edit.haml line 237 onwards:
diaspora* allows you to migrate from one pod to another.
To do this, first export your data and photos from the pod you want to move from. Then, import those data and photo archives into this account.
Your old account on the other pod will be deleted once this process has completed.
There is no way back; that account can’t be restored if you change your mind.
For app/views/users/_import_account_modal.haml, line 11 on:
Import another account
You are about to import and merge another account into
&{account_name}Here is what will happen:
• Your profile (name, bio, birthday, gender, etc.) will be transferred from the imported account
• Your settings (theme, default post visibility, etc.) will be transferred from the imported account
• All your aspects and contacts from that account will be added to this account
• All posts and comments from that account will be added to this accountThe imported account and all its linked data will be deleted from the previous pod.
Your contacts do not need to do anything; they will automatically be connected to this account.
If your old pod is offline when you migrate, your contacts and posts will still be imported, but your contacts will receive a notification that you have started sharing with them from this account.
I have an alternative suggestion for the list of ‘what will happen’, below:
The following will be changed to match the imported account:
• Your profile (name, bio, birthday, gender, etc.)
• Your settings (theme, default post visibility, etc.)The following will be added to this account:
• All your aspects and contacts
• All posts and comments
All comments welcome!
1 Like
I think it won’t be, and that’s the wanted behaviour. But we can discuss that.
Actually, the text is from me but I wasn’t sure about it and @supertux88 answer in Backup and restore – account migration - #116 by supertux88 that most of it wasn’t accurate. So don’t spend too much time re-wording it right now, maybe we should simply start from scratch again.
I just had a thought, with the closing of Framasphere (in exactly one month) a lot of users will do the export / import at the same time. But telling to other pod that a user migrated isn’t instantaneous. What will happen if two users sharing with each other are migrating at the same time? With messages about migration crossing each other…
Oh, yes. I noticed also that download profile uses the same database field than upload profile…
Your investigation is indeed very useful. Could you create Issues for each of them?
So we can decide what blocks the next release and what is a plus for later.
I’ll try! to work out which are the useful ones – and create issues for them.
@flaburgan, are you able to create new labels in Github? If so, one for migration would be really useful to hold all of these issues and PRs together. (One for gems or dependencies would also be useful, unless that’s covered by upstream).
One further idea: how about the following addition to the first landing page after the sign-up page – /getting_started?
OK, just a rough mock-up, colour and text are draft only, but a button here could be useful.
Click that button and ‘getting started’ hints are disabled, and you are taken straight to the /user/edit settings page (and scrolled down to the migration section if possible).
We’d need to make it clear that this is not an option for new users to choose so that they don’t miss out on getting started hints and get confused by the migration section in the setting page, but is this a good approach? @tclaus @flaburgan?
Hey @tclaus so I have time to work on diaspora this evening and tomorrow morning probably.
I would like to be able to do the first real migrations using the rake task as it would be easier to monitor what is happening this way. Do you think that you could improve it include the photo import? That would be great.
1 Like