[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: inline outliners
But not so sure about your last case there... what if you have a
tightly-packed run of very small morphs (like on a tool bar) and you're
trying to look at a bunch of them at once? Even of most of these
outliners were collapsed, it could be a pain and visually obscuring,
confusing or misleading.
We talked about having outliners pop-up adjacent to the morph, yet stuck
to the edge of the morph so that the two moved together. But stuck in a
"loose" way, so that some simple gesture could undo the connection.
Perhaps simply grabbing the outliner would free it from its morph. Some
animation or direction indicator might be used to show a disconnected
outliner's desire to "return home."
If this appeals, it should be easy to do using the same mechanism that
is used for the sprouted "pointers" from outliner slots. If you sprout
the little button (or pointer thing) at the end of a slot it runs out and
sticks to appropriate target outliner, and will even follow it around if
the target moves. But if you grab the pointer, you just end up holding
> From firstname.lastname@example.org Mon Sep 9 09:43:46 1996
> Sender: email@example.com
> Date: Mon, 09 Sep 1996 12:56:00 -0300
> From: Jecel Assumpcao Jr <firstname.lastname@example.org>
> Organization: University of Sao Paulo - Brazil
> X-Mailer: Mozilla 3.0Gold (X11; I; Linux 1.2.13 i486)
> MIME-Version: 1.0
> To: email@example.com
> Subject: inline outliners
> Content-Transfer-Encoding: 7bit
> Here is an idea I had some time ago. I thought I had posted it
> here already, but looking back though my old mail it seems
> that I didn't. Sorry if I am wrong about this...
> It really messes up the "single object identity story" in the
> Kansas user interface to have both morphs and outliners for
> the same object present on the screen at the same time.
> I can feel a little better about this if I think about the outliner
> as the morph for the mirror of the object - then we have two
> morphs for two objects. I would prefer, however, to have the
> outliner appear with the corresponding morph embedded in it
> as its title. Instead of having the outliner say "aCircleMorph"
> it would show the circle morph near its top. The outliner
> would pop up in such a place that the circle morph would be
> at the exact same spot it was before.
> What if the morph has other morphs embeded in it? No problem -
> the whole morph-tree would be the "title" for the outliner
> and the user would have to understand that the outliner was
> for the "lowest" morph of the bunch.
> What if the morph is embeded in some other morph? This is
> very tricky to solve, but I would "grow" the outliner under
> the given morph but over its sibling and parent morphs. The
> outliner would be pseudo-embeded in the morph's parent
> visually, but shouldn't have any effect on layout. One
> problem with this is that browsing more than a single
> submorph would lead to a great visual clutter. If it is
> easy to sprout and shrink outliners for these embeded
> morphs, however, limiting oneself to looking into one
> morph at a time won't be such a big bother.
> -----=============( Jecel Mattos de Assumpcao Jr )===========-----
> http://www.lsi.usp.br/~jecel/merlin.html | mailto:firstname.lastname@example.org