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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.