From: Lex Spoon [mailto:lex@cc.gatech.edu]
[...]
Overall, Multiple-Windows seems like a safer default.
I agree, but maybe it should be exactly that --- a default, with navigation buttons appearing on browsers if a developer decides to change that default?
A more interesting question is: what should the interface do to support *both* behaviours? For example, sometimes I know how to get where I'm going and want to navigate through several layers quickly and without retaining intermediate context (senders and implementors are typical). I'd be quite happy to shift-click to have the system present the next layer in the same window (or, for simplicity, to throw away the existing window and replace it). At other times I'm exploring, and really appreciate the ability to retain context in the windows.
Just my Friday evening £0.02...
- Peter
On Fri, 30 Nov 2001, Peter Crowther wrote:
From: Lex Spoon [mailto:lex@cc.gatech.edu]
[...]
Overall, Multiple-Windows seems like a safer default.
I agree, but maybe it should be exactly that --- a default, with navigation buttons appearing on browsers if a developer decides to change that default?
I read this and it made me think what I came to think you said below. :)
A more interesting question is: what should the interface do to support *both* behaviours? For example, sometimes I know how to get where I'm going and want to navigate through several layers quickly and without retaining intermediate context (senders and implementors are typical). I'd be quite happy to shift-click to have the system present the next layer in the same window (or, for simplicity, to throw away the existing window and replace it). At other times I'm exploring, and really appreciate the ability to retain context in the windows.
But I'm not longer sure that I think you said what I thought above.
One quick solution to the "history vs. multi windows" debate is to implement the history with multiple windows (hey, they're just objects, and in morphic, just morphs!). Instead of staggering new windows, stack them exactly (better, make the original window set the bounds and "contain" all the subwindows). Maybe have a bookmorph navigator up top.
Or just use a bookmorph.
Hmm. A quick dork reveals that I don't know much about bookmorphs, being unable to drag a window into one :) or even resize it.
In any case, that would certainly be a simple to implement history mechanism that would work across Browsers of various sorts.
Cheers, Bijan Parsia.
Hmm. A quick dork reveals that I don't know much about bookmorphs, being unable to drag a window into one :) or even resize it.
Hmm, I seem to be a broken record. Well, I haven't posted this in a while, so here goes.
In short, there's a preference for this -- systemWindowEmbedOK. So you can turn that on and then embed windows all you like. However, I agree that windows should be regular morphs, too, and thus that this preference looks a little funny. This preference is there for good reason, though, which you'll probably discover if you turn it on!
The awkwardness I'm hinting at is *accidentally* dropping windows into holders. This gets annoying in a hurry! However, drawing the line at system windows doesn't seem quite right. First, this is annoying with *all* largish morphs, not just with windows -- I've frequently seen people shift a background image an inch to the side, only to have it "disappear" into a holder. Second, people seem to take qutie a while to catch on to the precise rule that is being used, which can be painful to watch. The rule is that the mouse's position determines whether a drop will happen, and it actually has nothing to do with the position of the dragged morph.
Here's an alternative, that solves both problems: use the usual rules for pegs and holes from the physical universe. That is, if a peg is smaller than a hole, and the peg is directly over a hole, then it can be dropped into the hole. Otherwise, it will just sit on top of the hole. This avoids accidents, and has very intuitive rules for humans.
When I suggest this, some people expect that would just trade one annoyance for a new one: what happens when you *do* want to drop a big morph into a small holder? This case is actually easily and quickly solvable in three ways, however. Any 3 year old would come up with three good options:
1. Squeeze the morph smaller. 2. Stretch the holder bigger. 3. Force it. (i.e., use the "embed" menu)
I played with a system like this for a while, and it seemed fine. The code was very simple, too -- there's already a method in PasteUpMorph that decides whether a morph may be dropped; that method can check whether the bounds fit or not.
-Lex
PS -- the next layer of windows-as-morphs fun begins when you try to make things like "activate" work when there are windows at different levels of embedding. One tough case is a window embedded in another window -- the current logic doesn't let them both be active, and thus it's hard to type into the inner window!
On Sun, 2 Dec 2001, Lex Spoon wrote:
Hmm. A quick dork reveals that I don't know much about bookmorphs, being unable to drag a window into one :) or even resize it.
Hmm, I seem to be a broken record. Well, I haven't posted this in a while, so here goes.
For the record, fix it :)
In short, there's a preference for this -- systemWindowEmbedOK. So you can turn that on and then embed windows all you like.
Ah right, I forgot.
However, I agree that windows should be regular morphs, too, and thus that this preference looks a little funny.
Nope, it's there for a good reason.
This preference is there for good reason,
See?
though, which you'll probably discover if you turn it on!
Don't have to. I'm a philosopher and knew this *a priori* :)
The awkwardness I'm hinting at is *accidentally* dropping windows into holders. This gets annoying in a hurry!
Oh yeah, I remember getting very annoyed by that ;)
[snip]
When I suggest this, some people expect that would just trade one annoyance for a new one: what happens when you *do* want to drop a big morph into a small holder? This case is actually easily and quickly solvable in three ways, however. Any 3 year old would come up with three good options:
- Squeeze the morph smaller.
Yick.
- Stretch the holder bigger.
Blargh.
- Force it. (i.e., use the "embed" menu)
Eh...that doesn't seem like *force* to me. That's more like asking mom or dad to do it for me.
By gum if I'm going to force it I want splinters to fly!
[snip]
PS -- the next layer of windows-as-morphs fun begins when you try to make things like "activate" work when there are windows at different levels of embedding. One tough case is a window embedded in another window -- the current logic doesn't let them both be active, and thus it's hard to type into the inner window!
Ouch!
Cheers, Bijan Parsia.
Hmm, I seem to be a broken record. Well, I haven't posted this in a while, so here goes.
For the record, fix it :)
Actually, I have. This has been on my mind a little over three years -- I remember when the preference went in, and thinking what an awkward state we had reached.
http://swiki.gsug.org:8080/sqfixes/1288.html
Yick.
[...]
Blargh.
Everyone says this. But what *exactly* is wrong with it?
-Lex
On Tue, 4 Dec 2001, Lex Spoon wrote:
[snip]
Yick.
[...]
Blargh.
Everyone says this. But what *exactly* is wrong with it?
Er..well, since you cut all the context, I can't remember.
I really don't have *too* much experience to go by, but it's something like this: If I'm collecting a bunch of things to throw in a book, I want it easy to throw them in and I want the book to be small, so I can see my desktop.
Hmm. Actually, I might be perfectly happy with a collapsed bookmorph with the ability to drop stuff on a new page. Maybe have little drop sensitive toggles?
I find bookmorphs a little hard to resize (you resize the *page* yes?) and sometimes find them a bit, in my casual experiments, hard to control (somtimes I'd like a fixed book size and variable page sizes, I think).
Does this help?
Cheers, Bijan Parsia.
For what it's worth, I notice that the Mac UI deals with drag & drop by making the dragged item either transparent or translucent, so that you can see the item underneath that you might place it in.
Also, the accepting item is highlighted when passed over. (I guess Squeak already does this in some cases such as when dragging methods into new categories.)
(I was also a bit surprised to notice that the Mac also uses the location of the mouse to determine the drop point, not the middle of the morph.)
Anyway, this is not to say that there isn't a better way. :)
- Doug Way dway@riskmetrics.com
Bijan Parsia wrote:
On Tue, 4 Dec 2001, Lex Spoon wrote:
[snip]
Yick.
[...]
Blargh.
Everyone says this. But what *exactly* is wrong with it?
Er..well, since you cut all the context, I can't remember.
I really don't have *too* much experience to go by, but it's something like this: If I'm collecting a bunch of things to throw in a book, I want it easy to throw them in and I want the book to be small, so I can see my desktop.
Hmm. Actually, I might be perfectly happy with a collapsed bookmorph with the ability to drop stuff on a new page. Maybe have little drop sensitive toggles?
I find bookmorphs a little hard to resize (you resize the *page* yes?) and sometimes find them a bit, in my casual experiments, hard to control (somtimes I'd like a fixed book size and variable page sizes, I think).
Does this help?
Cheers, Bijan Parsia.
For what it's worth, I notice that the Mac UI deals with drag & drop by making the dragged item either transparent or translucent, so that you can see the item underneath that you might place it in.
Also, the accepting item is highlighted when passed over. (I guess Squeak already does this in some cases such as when dragging methods into new categories.)
That combination might work well. Squeak will highlight projects you are about to drop into, but it doesn't always help very much because project windows are so small -- you often can't see the highlight! With translucency, you could see the highlight.
Doing it for bookmorphs seems sensible, though mildly overkill somehow. But I guess if we are going to allow huge morphs to drop into moderately-sized bookmorphs, then it would make fine sense.
(I was also a bit surprised to notice that the Mac also uses the location of the mouse to determine the drop point, not the middle of the morph.)
Hmm, interesting.
-Lex
On Wed, 5 Dec 2001, Lex Spoon wrote:
For what it's worth, I notice that the Mac UI deals with drag & drop by making the dragged item either transparent or translucent, so that you can see the item underneath that you might place it in.
Also, the accepting item is highlighted when passed over. (I guess Squeak already does this in some cases such as when dragging methods into new categories.)
That combination might work well. Squeak will highlight projects you are about to drop into, but it doesn't always help very much because project windows are so small -- you often can't see the highlight! With translucency, you could see the highlight.
Alternatively, the highlights could be drawn in an overlay plane (just like the HandMorph - maybe even the Hand itself should draw the highlighting ... yes, it should, considering multiple hands ... thinking aloud here). Then the dragged morph wouldn't have to be translucent, but other styles may be used (like the attached screenshot from Galeon).
-- Bert
That combination might work well. Squeak will highlight projects you are about to drop into, but it doesn't always help very much because project windows are so small -- you often can't see the highlight! With translucency, you could see the highlight.
Alternatively, the highlights could be drawn in an overlay plane (just like the HandMorph - maybe even the Hand itself should draw the highlighting ... yes, it should, considering multiple hands ... thinking aloud here). Then the dragged morph wouldn't have to be translucent, but other styles may be used (like the attached screenshot from Galeon).
Ah, the hand could just take on a different appearance if dropping is available! It could be highlighted, or it could be some other shape. That would seem a best of both worlds.
-Lex
This sounds interesting and worthwhile ....
Cheers,
Alan
-----
At 10:14 PM -0500 12/5/01, Lex Spoon wrote:
For what it's worth, I notice that the Mac UI deals with drag & drop by making the dragged item either transparent or translucent, so that you can see the item underneath that you might place it in.
Also, the accepting item is highlighted when passed over. (I guess Squeak already does this in some cases such as when dragging methods into new categories.)
That combination might work well. Squeak will highlight projects you are about to drop into, but it doesn't always help very much because project windows are so small -- you often can't see the highlight! With translucency, you could see the highlight.
Doing it for bookmorphs seems sensible, though mildly overkill somehow. But I guess if we are going to allow huge morphs to drop into moderately-sized bookmorphs, then it would make fine sense.
(I was also a bit surprised to notice that the Mac also uses the location of the mouse to determine the drop point, not the middle of the morph.)
Hmm, interesting.
-Lex
On Sun, 2 Dec 2001, Lex Spoon wrote:
Hmm, I seem to be a broken record. Well, I haven't posted this in a while, so here goes.
Me too ... :)
[...]
The rule is that the mouse's position determines whether a drop will happen, and it actually has nothing to do with the position of the dragged morph.
Starting in Nov 99, three times I have posted a change to HandMorph>>dropMorph:event: that uses the center of the dragged morph instead of the mouse position to determine 'dropability'. So far, no reaction, let alone inclusion in the update stream.
Sean McGrath
Peter Crowther peter.crowther@networkinference.com is widely believed to have written:
From: Lex Spoon [mailto:lex@cc.gatech.edu]
[...]
Overall, Multiple-Windows seems like a safer default.
I agree, but maybe it should be exactly that --- a default, with navigation buttons appearing on browsers if a developer decides to change that default?
A more interesting question is: what should the interface do to support *both* behaviours?
Acorn RISC OS has a possible solution to this, at least the UI paradigm part. Normally we use the red button to open a new fileviewer (or follow a web link, etc) and the blue button to open a new file viewer _and_ close the original (or open a new web window on the selected link).
If you read the above it will surely sound confusing - in one case the red opens a new window, in the other it doesn't - BUT the key that makes it all work is the underlying logic. I'll try to explain it:- Red button is 'select'. This (just like in Smalltalk) marks an item or text location. D-Clicking on it will select and do the default action, which in a fileviewer is to open the selection; for a file it will invoke the appropriate application and for a directory the application is a new fileviewer. Yellow button popsup a window-context menu (almost as good as Smalltalk!) Blue button 'adjusts' the selection. This is an interesting concept that allows extension of the text selection (like shift-red in squeak) or adding/removing to the selections in a list. It is also used as a way to do a sort-of opposite select-click. For example, blue-d-click on a file invokes the appropraite application _and_ closes the fileviewer. For a directory, it opens a new fileviewer and closes the orginal (could reasonably be implemented as 'diving', but happens not to be) and in a web browser it follows the link by opening a new window (which is extremely useful and I have munged my mac to be able to do the same when the three button mouse is attached). On scroll buttons etc it also has the useful property of _reversing_ the action - so I can scroll up and down without moving the mouse all over the place!
So how could this be useful in Squeak browsing? Perhaps make blue-click on a category/class/protocol/message open a new browser instead of changing the current one? Maybe in a messagelist browser, make it _add_ the found implementors/senders instead of making a new browser?
As a concept it seems to work really well. Despite the sort of apparent complexity that is probably making Macbigots scream, it is very popular with kids, who take to it incredibly quickly.
Just a thought for a cold friday morning.
tim
squeak-dev@lists.squeakfoundation.org
-
Alan Kay -
Bert Freudenberg -
Bijan Parsia -
Doug Way -
Lex Spoon -
Peter Crowther -
Sean McGrath -
Tim Rowledge