<br><br><div class="gmail_quote">On Fri, Aug 28, 2009 at 11:12 AM, Jens Alfke <span dir="ltr"><<a href="mailto:snej@google.com">snej@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Aug 28, 2009, at 10:51 AM, Brady Eidson wrote:</div><br><blockquote type="cite"><span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Baskerville;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">I would *NOT* be on board with the spec requiring anything about "where the file goes on the filesystem." I have never been convinced by the argument that users always need to be in charge of where in a filesystem directory tree every single file on their computer needs to go.<br>
</span></blockquote></div><span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Baskerville;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>
<br></div><div>I wouldn't want the spec to require that either. At that high level, I think it should just state that:</div><div>• Local storage may contain important user data and should only be deleted by direct action of the user.</div>
<div>• The user must be allowed to decide whether code from a particular security domain is allowed to store persistent data locally.</div><div>• The user must be able to see how much disk space each domain is using, and delete individual apps' storage.</div>
<div><br></div><div>The first item (which is basically already in the spec) allows web-apps to store user-created content safely. </div><div>The second item helps prevent abuse.</div><div>The third item helps the user stay in control of her disk (and provides the 'direct action of the user' mentioned in item 1.)</div>
<div><br></div><div>My suggestion involving the Save As dialog is just to show a feasible way to implement those requirements on a desktop OS in a way that makes it fairly clear to the user what's going on.</div><br></span><div class="im">
<blockquote type="cite"><span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Baskerville;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">I'm a huge fan of the "my mom" litmus test. To my mom, the filesystem is scary and confusing. But using the browser to manage browser-related things is familiar and learnable.<br>
</span></blockquote></div></div><br><div>What I like about using the regular Save As dialog box is that almost every user has some experience with it, and knows that it means <i>this app wants to put files on my disk</i>. Naive users tend to just hit Enter and let everything be saved to a default location, which is fine. (In OS X, the default collapsed state of the Save panel supports that.) Users who are savvy with the filesystem know how to navigate to a different directory if they want, or at least look at where the file's going to be saved by default.</div>
<div><br></div></div></blockquote><div><br></div><div>This works well for storing user generated content (save-as, open what i saved earlier), doesn't work so well for application data that is less user perceptible.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div></div><div>It also doesn't look like the type of security-nag dialog that people instinctively OK without reading.</div>
<div><br></div><font color="#888888"><div>—Jens</div></font></div></blockquote></div><br>