Phase 1 Revision 2

Setup Wireframe feedback:

Some of my comments might be out of scope so please excuse me in advance if any of these suggestions/comments are out of sync with where the group has arrived vis-a-vis scope.

1. I don't think we'll need to support sync filter, at least not in the first round.
2. Only supports one sync source directory: I just want to confirm that is what we want.
3. It seems to me that upload status and download status should never be showing at the same time since the application will be either syncing up or syncing down at any given time. Additionally I don't think the "Restore" functionality has been adequately modeled in the wireframe.
4. "Sync Items" display is not clear to me. What does local items mean? Local items remaining to be sync'd to cloud? It seems we should have a progress bar showing completeness of any given synchronization run. Ideally it would show both byte progress as well as file progress.
5. Are we assuming that directories will be synced recursively? And if so, are we assuming that the local directory tree will be captured in the duracloud item name? The wireframe is a little ambiguous on this point as it only shows a flat list of items.
6. The DuraCloud "prefix" filter in the DurAdmin application is not all that useful and I think it would be a mistake to include it in DfR. We're planning to phase it out soon in favor of a search feature. I don't think it will be very useful in this case. The pending list of items to be synced is probably not all that interesting to the user. The items that are currently being synced and perhaps the next 20 - 50 items might be interesting. But the list of the next 50 or so items should be accessed in a separate view. The complete list of items to be synced may be very short or possibly very long. In the case of a long list, I can't see any benefit in displaying it. In other words, the item list does not seem all that useful, and we might consider a diptych display rather than the Duradmin-esque triptych.
7. Having the ability to see the recent sync activity for an individual item seems useful to me, but the user will likely inspect that info if the file in question is currently being worked on or the user has been alerted to some kind of problem with it. Or perhaps if the item is on deck to be synced. Therefore I think in addition to the information that is already being displayed, perhaps it should also show a comparison between the local file and the remote file so that differences can be better understood. For example, in addition to mismatched checksums, the similarly named files might be of significantly different sizes. It might be nice to know when the remote file was last changed versus the local file, etc. Also we might want to provide convenient links for accessing the local and remote files.

1. I am glad Tim and Peter looked ahead though we will need to restrict the features implemented for each iteration.
2. The implementation for each iteration can consist of functional and mock components since this is not in production until post grant period.
3. I like the wizard-to-job notion (a "Sync" is equivalent to a job in my mind and IMHO seems a good name) for this kind of tool and each "Sync" consists of one directory specification (directory to space). We can also put constraints on a Synch for features we cannot support yet. However, in the wizard, we could put a check box whether to recursively look at subtrees.
4. This UI is more oriented to "on demand" synchronization, a place we may want to go. For now, however,once the automated sync is set up you should not see this UI unless you want to change settings. We only need a "sync" status display to show jobs that have run (history), scheduled, and in progress status (sych (job), files and/or bytes). So lets discuss if this is one display (setup), two (setup and ondemand) or three (status).
5. We can start with only one Sync able to run at a time.
6. I am not sure if the can fit an "analyze/compare" (differences) UI into the mix yet but that would be nice.