Am 07.07.2008 um 23:22 schrieb Eben Eliason: > On Mon, Jul 7, 2008 at 4:59 PM, Noah Kantrowitz > <[EMAIL PROTECTED]> wrote: >> On Jul 7, 2008, at 12:52 PM, Eben Eliason wrote: >> >>> On Fri, Jul 4, 2008 at 6:42 PM, Ivan Krstić >>> <[EMAIL PROTECTED]> wrote: >>>> >>>> That said, the URI handler approach should be used sparingly. >>>> It's one >>>> thing to allow starting an audio player by clicking an MP3 link >>>> in the >>>> browser, and another to arbitrarily execute code (e.g. through an >>>> execution environment such as Pippy or eToys) from a web page >>>> with a >>>> single click. While Bitfrost is designed to mitigate the side >>>> effects >>>> of arbitrary code execution, it's very unwise to make it trivial >>>> for >>>> the user to trigger such execution unknowingly. >>> >>> I really don't see anything wrong with injecting a modal alert, >>> displayed by Sugar, into this process if we must. Clicking on an >>> mp3 >>> in Browse would reveal this alert, and ask for confirmation that the >>> user wishes to open it. It would, of course, offer a list of >>> activities which support its mime-type (assuming there are more than >>> one). It could potentially include a way to set the default handler >>> as well, such that the next time it is revealed for the same mime- >>> type >>> a different default is chosen. I recognize that we try at all costs >>> to eliminate this form of dialog, but I also recognize that we might >>> not want to allow an activity to arbitrarily launch other activities >>> without the user's consent. >> >> Repetitive modal dialogs are useless bordering on harmful when was >> the last >> time you read an IE dialog carefully. > > In my post I acknowledged this fact, and I certainly remain cognizant > of it. We've tried very hard to prevent them. However, if the cost > of eliminating them completely is to prevent making this type of > inter-activity functionality work smoothly, I'll go for the dialog. > Basically, my reasoning in this circumstance is that the modal dialog > is actually a /better/ user experience than being dumped into the > Journal and left to fend for yourself (not knowing which button to > press, etc.) > > Additionally, I think that the dialog is slightly less awful for two > reasons. First, it will likely be the case that kids will simply > click OK or press enter instinctively anytime they explicitly click on > a link or button with the intent of launching something else. > However, I would expect them to think twice about it if they were > automatically presented with one or many of these dialogs without > taking an action to reveal it, which is a primary reason we need it at > all. Second, I think we can actually mitigate the level of awful by > providing other useful actions, taking it a step above "Did you really > mean to do that thing you told me to? [yes] [no]" dialogs. In > addition to the "Cancel this launch operation" and "Yes, really launch > this URI with the default activity" buttons, we can offer "Launch this > URI with a non-default activity", "Keep object pointed to by URI in my > Journal" (for non-local URIs), and "Show object pointed to by URI in > my Journal" (for local URIs). Finally, the possibility of adding a > "Edit the object pointed to by this URI such that it updates in the > activity I'm launching it from" option could make it much more > powerful in the future. > > I think that a variety of useful user-facing options for how to handle > this will make the dialog less like an arbitrary > just-click-ok-and-curse-this-machine-for-asking-me-useless-questions > type of experience.
At the risk of being ignored again I still think a menu instead of a dialog would be less intrusive. - Bert - _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
