Once we get rid of the tabs, there is room for more improvements. I’ve changed the main structure of the activity a bit, using the action bar for the connect actions and leaving the secondary toolbar for the transfer status and the main button to transfer all the files:
I’ve used the same tabs as in the activity charts to filter the list, being able to filter by type (all, courses or activity logs). Then you can individually send files just like now or press the “send all” button that will send all courses and activity logs (or only the type currently selected). The progress would look the same as it is now, with the progress bar and the information about the pending files and total filesize.
For this, I’m not sure about keeping the “send all” button when there is some active transfer… what do you all think?
Now that we have a single unified list of the different transferable files (courses and activity logs), the problem is that we lose the tracker summary that appeared in the “Activity” tab (the one with the trackers submitted, pending, etc). I don’t see a way we can include this section in the single page without making it completely confusing, so my proposal is that we extract that part to a different screen.
In this separate screen we could have the summary, and a list of the activity logs, and also the archived ones (to cover one of the other new issues: https://github.com/DigitalCampus/oppia-mobile-android/issues/978). This part is independent of the Bluetooth transfer, so the send buttons are not related with the in-app transfer process, but the native Android share mechanism.
Thank you for putting together these mock-ups. I like your proposal to consolidate the screens and to provide an option to transfer all files at once. Does the user only see the list of courses and activity logs to transfer once they’re connected to another device?
I might suggest swapping the placement of ‘activity logs’ and ‘all’ filters and making activity logs the default, if that’s the type of data that’s most frequently sent. @NickGordon do you have any additional thoughts?
If a file transfer is in process, can you make the Send All button inactive until the transfer is complete?
How does the user navigate to the second screen with the summary, list of activity logs, and archived logs? Would it make sense to also show files received on this page?
I think for the current sprint, we’ll need to work with the mockups @jjoseba has provided - but taking into account @Julie comments. We can always review and update in a later sprint, as think it will make more sense when the LMH team have had a chance to actually try this out.
Cheers,
Alex
I really like the filter view - Looking great. Here’s some feedback on @jjoseba’s mock-ups:
The send all button could be problematic - especially with the filter on all. If a user accidentally pushes it, it will start sending all courses to the next user. I would also assume the use cases for this button would be to either send all of the activity data or all of the courses - not usually both together.
If we keep this view, I’d request that activities file names (ie. tester_201903160108.json) are changed to a readable label (such as “Activity data - A.Little - March 16, 2019”) so that a user can understand what data they are transferring.
Especially with small activity file size, it’s difficult to know if data transfer actually happened or not. On the receiving device, could we add an animated pop-up that data has been received? Likewise, on the sending device, confirmation that data has been sent?
I think the tracker summary is a really huge loss. It is the users’ biggest cue if data has been transferred or not. I’ve mocked-up some alternatives that keeps the tracker in:
Mock-ups: This basically just adds a menu overlay on top of the mock-ups that Joseba made:
@jjoseba let’s discuss Nicks suggestions in our call later… it looks good to me, though I’m wondering if this is going to end up then having the same number of ‘clicks’ through to the functionality - this was one of Nicks concerns about the current bluetooth interface. But maybe having a better UI in general would compensate for this?
What I’m most interested to know about is how much this is going to change the time estimates we’ve made, and so how it affects us being able to implement this in the current sprint (or if other issues/tasks need to be moved to a follow up sprint)
Hi!
After taking into account your comments and talking with Alex, I gave it another go.
Here are the additions/changes I’ve made:
I agree that it doesn’t make much sense to transfer both courses and activity logs at the same time (as a user transferring courses would probably be receiving activity logs instead of sending them), so I’ve removed the “all” filter from the list, only having the two types of transfers.
By default, activity logs are the first type shown when the connection is established
Regarding the “turn bluetooth on” in your mockup, @NickGordon, what that button really does is enable the bluetooth discoverable mode (the app asks to turn the bluetooth on as soon as it enters this screen). Following this, I think it can be a nice idea to make the part of the device name clickable and that it does the same as the toolbar button. This is not visible in the mockups, it’s just a proposal.
Instead of the activity log filename, show it in a more readable way
When the user presses the “send all” button, hide the button and disable the individual transfer buttons until the transfer finishes, so only the current progress is shown.
I preferred the separated activity screen as I proposed (I’ll argue later why), so I kept it that way. The idea is that it is reachable as another option from the drawer menu, so the actions are splitted in two different screens:
Sync devices: everything related with transferring files between two Oppia apps
Activity log: related with the local activity tracking and its current synchronization with the server
In the archived activity logs I’ve added a secondary action to be able to manually remove them, just in case we need to make space in the storage. These are the files that have been submitted to another device but not to the server, once they are submitted to the server it doesn’t make much sense to keep them any longer.
Some additional things:
For this, do you mean like the points notification?
This is how I pictured it, but I’m open to suggestions. Do you think it would be useful to have the list visible when there is no connection?
I think that’s all, @alex could you please check if I’ve missed something?
Thanks @jjoseba, I don’t see that you;ve missed anything here.
@Julie and I will follow up on this on our call on Thursday so we can finalise what specifically we do in this Jan sprint on this. But of course we can always make follow up changes in another sprint if it doesn’t quite work for LMH - it might be tricky for LMH to really know/decide what needs to be changed until there is something they can ‘play’ with
@jjoseba, we had a call with Nick and Julie, so can confirm to go ahead with your 2nd version of the mockups for the current sprint @NickGordon, @Julie - we can always update/tweak in a later sprint (and/or when we get some feedback from the field)
