| 22 | Feedback indicates that users are not happy with having to register with every project separately. |
| 23 | |
| 24 | Initial proposal of UI flow: https://www.fluidui.com/editor/live/preview/p_xuIwayLOet0gFoFlBHZJtpmbqnxF5Z7O.1394002154909 |
| 25 | 1. splash screen |
| 26 | 2. if no project attached, prompt credential input. this screen can accommodate Google sing in later. |
| 27 | 3. project selection. multiple choice. project info screen opens with (long) click on project |
| 28 | 4. attaching. using previously supplied data. tries login, if fails, try registration. give users introduction/hints in the mean time. |
| 29 | 5. successful. if no conflict. |
| 30 | 6. conflict resolution. one screen for every project that returned "bad password" (account exists but password is wrong). give user a change to correct his data (name or email if not users account; password if user registered before with different password), only for this specific project. |
| 31 | |
| 32 | Store user data to pre-populate fields in further attaches. |
| 33 | |
| 34 | Concerns with initial proposal: |
| 35 | * Users that already have different accounts with various projects or prefer having separate id-password combinations with all project accounts |
| 36 | -> offer to supply login information separately for each project. add button to screen 2. possible to pre-populate name/email field from previous data. |
| 37 | * Storing the users password for further attaches raises concerns |
| 38 | -> add checkbox to screen 2 to opt-out |
| 39 | -> or do not store password in general. require re-type if further attaches and later point in time. |
| 40 | * Conflict resolution needs to be adapted based whether project uses name or email as identifier |
| 41 | -> "uses_name" attribute allows distinction |
| 42 | * WCG does not allow registration on client. Treat separately. |
| 43 | -> prompt screen that forwards users to WCG homepage. |