Re: Automatic restoration of published shares
Mimi Yin <[email protected]>
| Newsgroups | gmane.org.osaf.design |
|---|---|
| Message-ID | <[email protected]> |
On Oct 2, 2007, at 10:13 AM, Morgen Sagen wrote: > I usually have one or two test collections on the hub that I don't > normally want to appear in Chandler, but we could call that a corner > case (I could always create a separate server account to own these > test collections). Do we want the user to be able to select which > collections get restored (like the Restore Published Shares dialog > does today)? Or should Chandler just restore all the collections > their server account owns? Yes, I think we should just call this a corner case and let users deal with it themselves, either by deleting collections from Chandler Desktop after restoring them or using a separate account as you mentioned. > Should there be any indicator in the UI > that the restore process is happening, or should it be all in the > background? If in the background, where do I display errors, and will > the user be surprised to see collections suddenly appearing in the > sidebar? I suppose that could be a pleasant surprise. :-) I think we should make it modal. It's a set-up task after all, just like reload, so I think it's okay to lock down the UI and make the process 'transparent' so that users are sure to see errors and whatnot. > > Next, how should the restoration be triggered? We could add a button > to the account dialog, or perhaps we trigger it when the accounts > dialog is closed. I suppose the restoration process could take place > at the beginning of each sync. Let's kick it off when users close the accounts dialog and see if we get any complaints before adding more UI. > > Anyway, those are quite a few questions for one email, and I'll let > Mimi ponder those. :-) > > After typing all this up, I guess my feeling is this should all be as > transparent as possible, ideally with no additional UI to hook up > Chandler to existing published shares. The best bet would would > probably be to have the process take place at each sync so the user > doesn't have to do anything special to trigger it. Yup, I think we're on the same page then. > > ~morgen > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > Open Source Applications Foundation "Design" mailing list > http://lists.osafoundation.org/mailman/listinfo/design _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design