Neat idea!
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 the pointer.
--Randy
From jecel@lsi.usp.br Mon Sep 9 09:43:46 1996 Sender: root@ns2.internetco.net Date: Mon, 09 Sep 1996 12:56:00 -0300 From: Jecel Assumpcao Jr jecel@lsi.usp.br Organization: University of Sao Paulo - Brazil X-Mailer: Mozilla 3.0Gold (X11; I; Linux 1.2.13 i486) MIME-Version: 1.0 To: self-interest@self.sunlabs.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:jecel@lsi.usp.br
Randy Smith wrote:
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.
I think my idea would limit you to having an outliner for at most one morph in this case. This is even worse than it sounds, since closing that outliner and "opening" another is a bit difficult due to the problems of selecting a given morph in such a nested structure.
Unfortunately, I have not used the Self 4 interface enough to know how common this kind of situation is.
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.
You might think of my idea as having the ouliner stuck *under* the morph. This is actually backwards conceptually - I would say it makes more sense to have the outliner in the morph than the other way around. Then you would sprout the outliner from the morph. But it makes more sense visually to draw the outliner around the morph. That makes sprouting the morph strange, of course, since it should stay in place and the ouliner should move out of the way.
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."
It might be best to simply reuse the visual pointers already present in the interface. Maybe making them "bidirectional" by having them stick to the edges on both the morph and the outliner to show the neither is "contained" in the other. Or the pointer could start in an empty box in the outliner's title to be consistent with the (wrong) idea above that the morph is *in* the outliner.
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 the pointer.
Right - it should be easy to get rid of the connecting line. But you wouldn't be allowed to drop the pointer head on other morphs (changing what morph the outliner is related to) or the outliner would start to look like a traditional tool. Other than that, it would be great to reuse the sprouting pointer conventions (and code).
self-interest@lists.selflanguage.org
-
Jecel Assumpcao Jr -
randall.smith＠Eng.Sun.COM