[sugar] Pippy VS Develop

[Eben Eliason]

On Tue, May 20, 2008 at 10:16 AM, Jameson Chema Quinn
<jquinn at cs.oberlin.edu> wrote:
> Here is my thinking on view source.
>
> Possible use cases:
> 1. within same activity: "get properties" in an svg editor, "view model" in
> OpenSim, "go to definition" within develop itself. To be really useful, the
> UI for these should be as streamlined as possible.
>
> 2. Separate activities: "view html" in Browse-->Write (in text-only mode,
> preferably); "view raw svg" in svg editor --> Write; "edit activity bundle"
> --> Develop or Pippy, depending on activity (should be global default for
> Python-based activities)
>
> Note that, due to bitfrost/security constraints, option 2 means at least one
> step through a trusted UI (although lack of xorg security makes this a
> little bit silly). The obvious such step, and the one currently implemented,
> is to bring up an item in the journals detail view, ready for launching in
> its appropriate activity. This is a good first approximation, but it is not
> ideal in a couple of ways: it means that any user choice between use-cases
> must go in a separate step; it currently lacks an obvious "oops, go back"
> option (without using the frame, which requires a more-advanced
> understanding); and it pollutes the journal with another item which could
> have been avoided if the user chooses not to view it or even perhaps if the
> user views it without editing it (Develop, for instance, has the ability to
> view an installed activity in-place without a bundle in the journal; the
> first edit causes it to make a backup copy in the journal, and all saves are
> to the journal of course).

I think we can do better.  The concept of dumping one into the Journal
and expecting the user to do the rest just doesn't sound like a very
good experience, and the confusion with the back button, or lack
thereof (I see both as independently frustrating) is also an issue.
However, I see no reason why we can't handle both of your proposals (1
and 2) within a single trusted UI that serves as the "intermediate
step" without being an unnecessary one. If the view source key always
reveals a standard UI containing at /least/ "View bundle (in Develop)"
and potentially other specialized functions such as "View HTML (in
Write)", then the "intermediate step" serves both as the trusted
layer, as well as the layer that presents the various options and
allows the user to make a decision that makes sense for them. (The
paren around the (in activity) above indicate a potential choice for
the user; I think it's really wise to expose source with various
mime-types so that any supporting activity can ultimately be used to
view it.   As long as every SVG editor I have exposes its source as
text, I should be able to use any text editor to view it.  Naturally,
activities that wish to handle their own view-source operation can
expose that as something they themselves support.)

> Looking at the use cases, one tempting way to streamline the UI is to use
> modifier keys. Shift-view source would always point to Develop, while
> unmodified view source would default to Develop but be overrideable by a
> given activity (for all other use cases). (extra credit if there is some
> transient UI when you use an overrided view-source to remind you about
> shift-view-source.) There would be no built-in possibility to choose between
> more than two use cases for a given activity, though an activity could
> custom-code something if necessary.

I think this is ultimately the wrong course.  If we can come up with a
solution that presents options in a meaningful way without prior
knowledge of the user, we are much better off in my opinion.  I think
my above proposal is a potential direction which could make this work.

- Eben