View Source question

[Eben Eliason]

On Mon, May 19, 2008 at 3:10 PM, Eben Eliason <eben.eliason at gmail.com> wrote:
> On Mon, May 19, 2008 at 3:01 PM, Morgan Collett
> <morgan.collett at gmail.com> wrote:
>> On Mon, May 19, 2008 at 8:47 PM, Eben Eliason <eben.eliason at gmail.com> wrote:
>>> I believe the only two reasons that view source isn't yet what we all
>>> hope it to be is a) because, when we got down to it, it became a
>>> little difficult to specify exactly what that hope is, and b) because
>>> there are so many other items on the plates of developers that the
>>> last thing worth dedicating time to then was an unsatisfactorily
>>> specified new feature.
>>>
>>> I don't think anyone disagrees with the desire to "pull back the
>>> covers" though, and I also think that doing so can certainly have some
>>> practical applications.  As Walter mentioned, in Browse their may be
>>> options for viewing the HTML source, the CSS and JS is applicable, and
>>> ultimately the bundle code of the activity.  This latter piece can be
>>> made standard, and simply hasn't been yet because the means of
>>> accomplishing this is the Develop activity, which is still in
>>> development and testing.
>>>
>>> To throw my thoughts on the table, I'd vote for the view source key to
>>> reveal a modal alert which contains the various options for "what to
>>> dig into" in some form, one of which would always be the bundle
>>> itself.  Through some API the activity could indicate what it can
>>> offer, and perhaps also indicate whether or not it intends to handle
>>> the request itself (that is, the Browse activity may wish to reveal
>>> the HTML source itself).  This all clearly needs some more thought,
>>> though.  Do others have refinements to the notion of this dialog,
>>> regarding how an activity can offer up some goodies for peeking at
>>> and/or how we can handle revealing those goodies through itself or
>>> other activities? At least this approach will give a consistent
>>> jumping off (or in, so to speak) point for the view source key,
>>> regardless of what other interfaces or activities are then revealed
>>> once an option is selected, and it provides a default behavior which
>>> will work for every activity without explicit activity participation.
>>
>> I think one of the difficulties is maintaining some sort of context
>> for progressive View Source operations. For example, View Source on a
>> web page shows the page source in Write. View Source again should
>> ideally dive into the Browse source, not the Write source...
>
> Well, the model I'm proposing has pros and cons, but I think a pro is
> that it does "handle" the circumstance you mention.  From within
> browse, the view source dialog might offer "HTML", "CSS", "JS", and
> "BUNDLE".  Clicking any of the first three could open them up in
> Write, or in Browse itself if it wants to build support for it.
> Clicking on the last would, for instance, open a Develop project. (To
> be clear, I envision providing options for any supporting activities
> for each available option....we shouldn't lock kids into using those
> we choose up front, like Write and Develop).  This in any case, the
> new context is still "just some activity", be it Browse, Write,
> Develop, or something else.  Hitting view source again would
> appropriately reveal the options which always appear for that
> activity.
>
> This gives up the arguably powerful onion-skin model for a simple and
> consistent one whose behavior can be more clearly defined, and which
> takes advantage of all the other (and future) activities on the system
> which are capable of revealing various types of sources.  This is a
> tradeoff I'm willing to make; others may feel differently.

Sorry, an addendum:

Naturally, this means that to "dig deeper" you have to switch back to
the initial activity, for instance Browse, and press view source
again.  We could try to design the modal dialog in such a way that the
"layer" idea is retained, perhaps stacking the options vertically in
rows, with BUNDLE at the bottom.  Just because the act of viewing one
option switches contexts doesn't mean we have to lose the notion of
layers completely.  It's just less automatic.

- Eben