World: r3wp

Look & Feel: Getting close to OS look but still let it look different 
is a good idea. Users won't expect exact behaviour. The GUI must 
be simple to use. That's it. Tooltips are IMO a very good quick-and-dirty 
help-feature.

Shadwolf/Tree-Widget: I used Cyphre's one. The main trouble I found 
out is changing the tree. A path access structure would be nice. 
Things like: add-entry tree/1/2/3 "New Entry" or with a named path: 
my-tree/material/copper/price or so.

I'm looking forward to see a tree-widget in RebGUI. This will make 
it mostly complete for a good bunch of applications.

As Ashley gave us right to disagree, here is a slightly different 
POV :-)

To menu or not to menu. Menu widget, as well as tree one, is a case 
for subdialect. Just go and look at Cyphre's one. You just use sub-language 
to define it - item, action, icon, accelerator key, position in structure 
(block of blocks) etc.

I agree that pop-up system needs fixing first

Some time ago, I read article about icons, toolbars, and what is 
wrong with them. I have to say, I do prefer menus, really. I work 
in various environments, seeing tonnes of icons. Robert answered 
the trouble with icons for himself, maybe he even did not notice 
there is the trouble at all :-) Suggesting tooltips - that is the 
first obstacle with toolbars. Basic operations as printing etc. are 
self-explanatory. But! Go, start few apps, which allow you to hide 
menu - use icons only. You will get in troubles instantly, waiting 
for tooltips (=text representation) to explain you the meaining of 
the icon.

Of course, buttons are easy to press. But only once you already know 
what action it will invoke. But then you don't even visually orientiate 
yourself upon icon image itself, the action you take is somehow conscious, 
and you just press some button on toolbar on some position, because 
you simply know, what it does ...

Ok, those were icons vs. menu. As for tree-view, menu, grid data 
blocks. It is still the same problem, of how to efficiently use rebol 
structure (block of blocks) to represent tree (=in the meaning of 
hierarchy here). If we think twice, we can see that similar discussion 
is being held in XML group. We parse XML, and want to store it somehow 
efficiently, being able to navigate to some path(node), to read some 
item, but also to change it etc ...

I agree with Robert, that RebGUI is almost complete. That is still 
the main obstacle with VID, it is feature incomplete. Although there 
are some styles out there developer can use it, it simply does not 
come with standard rebol distribution. I am a bit disappointed, that 
Gabriele said in RT Q&A group, that we will at least know, WHAT actually 
is planned for VID and that we will know it "soon". But if "soon" 
means two months from conference just to tell what is planned, then 
how "soon" such plan can be realised, right?

Look at the latest announcements using the word "soon" and extrapolite, 
than you know.

:-)

just my 2cents regarding menus: what I really would like as well 
is what Robert told about, circle menus. They're far better than 
rectangular menus (in most cases anyway used for  context menus). 
The big advantage is, if done correctly that one can use them blind 
via forming a habit. This means of course that the content must not 
change (anyway a principle a good UI should obey). So one can simply 
right click (or whatever action to activate the menu) and go with 
the mouse in a certain direction and release, all in a fraction of 
a second and be sure to have selected the right item. For beginners 
the menu can appear and be visible, but for somebody who formed a 
habit it doesn't even have to be long enough visible to actually 
see it - because the whole item selection was faster than that it 
could appear.

One of the drawbacks is, that one can't put as many items as in a 
rectangular menu, best is 4, but maxium probably 8 items if there 
are 8 sectors for the circle. But I like to think about it in that 
way that one can form the mouse menus more levels (probably only 
two make sense), in that way that after selecting one item a second 
circle appears which can offer more choices. And because this can 
get habitual again it's very userfriendly for both experts and beginners 
without forceing either to something. For instance I think the useability 
of Operas mouse gestures is an example for tree menus which don't 
even appear. But in principle one could think that upon pressing 
the right mouse button a circle appears and moving to the item downward 
opens another menu so that moving again to the right selects the 
close window item. The only problem with submenus might be that it's 
kind of hard to find a good middle way for the distances the mouse 
cursor has to travel and error tolerance.

Wouldn't that be really something worth implementing in Rebgui ? 
:-)

I gonna try to implement these menus sooner or later, but looks as 
right now it might be rather later. :-(

Also I would like to agree with Pekr, that icons and bubble help 
aren't really always the best ways to represent things. One could 
argue (and agree with some studies or opions) that icons are not 
helpful in learning an interface and as Pekr told, once you know 
them you don't know them because they have a good symbol or picture 
in them, but because you spacially remembered the position and can 
go straight to the point you know the sought for command is. Same 
with bubble help. Actually it's just kind of way to explain your 
bad icons, because else nobody knows what they are doing. 

So I agree that bubble help should be there in order to have them 
because people will still use a lot of icons and have to explain 
them, but better use a compromise as done with Opera, where you have 
the fancy icon but can turn on the textdescription of the icon, so 
that it appears below. Then you know what the button means, but have 
the fancy picture too. Stupid thing is just that you lost some screenspace 
to the BAD picture above the GOOD textual description. :-) Ok some 
people tell me now vice versa. But really one should think about 
what a small icon tells. The designer of course knows there meaning 
- but he's not the only later user.

MichaelB: thanks for your thoughs, you think along the same lines 
as I do. Could you please show me an example of  "circle menus"? 
I am not sure I get the idea of how it is supposed to work ...

Pieces of cake. I like the idea. Cake pops up with mouse in the middle.

right

there is a master thesis or something about this I once read, I try 
to find it ... other than that there was one Rebol guy who tried 
to do it, but it was slow

Since i am weak on math: Has someone a formular to find the right 
piece for the mousecursor?

http://www.infres.enst.fr/net/zomit/zomit-net/more.html

under publications there is the thesis of Stuart Pook "Interaction 
and Context  in Zoomable User Interfaces" ... actually I looked into 
it, I'm not 100% sure this is the one I remember, but I guess so 
... page 54  there is for instance something about these menus and 
before that there is also an investigation of different kinds of 
menus
by the way, did I tell that I like Zooming User Interface ? :-)

and about the example: unfortunately I never used one - just that 
you have a pie which is put into pieces and because one knows where 
is north and south and so on, one can use it without even looking 
at the menu. (of course it can't be too finegrained, because who 
can move the mousepointer within an angle of a view degrees ?)

so Pekr: I don't know whether you use Opera, but I just imagined 
they could use some kind of pie menu in the background for their 
mouse-gestures, you just don't see them. Maybe that's a bit simpliefied 
but I really think that in general it is not such a bad model

Very cool. Does not need to be a pie, we could use text-facesaround 
the mouse?

( the java-demo: http://www.infres.enst.fr/net/zomit/zomit-net/cdi.html
)

what do you mean ? I don't understand. I almost forgot how I like 
these things. :-) Actually the fastest zooming I have seen - I know 
the piccolo toolkit a little bit, and I don't remember it to be that 
fast with so much text

and I would like to have a Rebol UI done the zooming way, but after 
my little tests I found it to be too slow for larger amount of data, 
especially text - but I thought about something similar but with 
steps, so no smooth zooming, this should be possible with Rebol

Slow with new draw too?

maybe I'm wrong and I didn't try anything fancy, but don't you think 
we might have problems in rendering the same stuff from the page 
you gave the link - I guess these things are accelerated by the graphics 
card and AGG is not, no ?

Ho fast is this on your machine? On mine it is slow, but thats the 
machine.. http://www.rebol.com/view/demos/rzoom.r

pretty smooth - maybe I have to try it one day ... what I did was 
put a lot of text in Carls first test of the transformation matrix 
example, where he wanted to know if the behavior is correct - and 
if you have a lot of text and zoom into it, it gets slow - but there 
are people here who know better (and might prove me wrong) - for 
me it would be too nice if somebody proves me that the same stuff 
as in the link is in sufficient speed possible with Rebol, even if 
there has to be some clever arrangement of the objects to be shown 
- I mean that objects not visible don't get rendered

That Zomit interface works poorly with a touch pad.

Or a mouse in my case. ;) Anyone have any links / screenshots to 
some good [non-HTML] implementations? (Windows or Mac OS X)

Anyone ever played The Sims?  Is this what you mean by circular menu?
http://www.piemenus.com/images/sims-shadowed-pie.jpg

I guess so, Second LIfe has also pie menus. 

Graham: this didn't mean that there are other ways to use menus and 
of course depending on the input device there are better ways. If 
you have keyboard shortcuts for everything you can even be faster 
in doing things. If you have a scroll wheel zooming into is pretty 
natural as is paning with a extra button - but didn't anybody feel 
that in this zoomit demo one could surpisingly well use the interface 
and especially with what speed ? (just compared to putting the same 
functions to a traditional context menu)

Also one should just try to use mouse-gestures in Opera - after using 
them you always want to use them - even though I often out of habit 
do the same in IE or somewhere else and it doesn't work - the most 
important thing to note for me is that it's worth having an interface 
one can form habits in using it - only then usage will be very fast. 
If one puts the one or other stumbling block into it, it will never 
flow, you always have to concentrate on what you're actually doing. 
Just imagine driving a car and having always to think about how to 
steer or shift (for many of the european people :).

Take a look at: http://www.think-cell.com/and watch the Flash, there 
you see the best circular menues I have every used so far.

Yes, that's actually quite intuitive. Bit hard to get all the design 
elements from the small flash demo, so what would the practical minimum 
/ maximum number of "items" be? 3 - 8? Should the "menu" appear centered 
on the cursor? Are the circles solid or partially transparent? Are 
they textual or iconic?

in the flashdemo they looked iconic - what I wouldn't like too much 
- see "rant" above :-)

but still I think the power comes from the possibility to use them 
blind if done nicely like in the java applet above ... only to have 
it circular doesn't have to help too much, exept that it uses the 
space around the cursor better

I am not against being innovative, but .... not sure that actually 
replace classical menu by circular one, removes reasons we try to 
abandon menu for :-)

If you want take a look at the manual, more screen shots.

Ashley, I'm going to send you a screenshot from my installation.

Robert - so you find Circular menus kind of help-full?

- I thought the discussion was more or less about traditional menus 
at the top of the window or screen. I think context menus are very 
helpful as they support nicely the object-verb pattern and as long 
as they are designed the way that they don't change unexpectedly, 
they are good and the user can form habits (Jef Raskins book "The 
Humane Interface" is a lot about this stuff)

- and they should support this kind of blind usage - then they're 
a big leap I think

I've never been a big fan of traditional context menus as they tend 
to get overloaded (you know things have gone too far when they are 
scrollable and have sub-menu's!) and the "target area" for selection 
is just too small (selecting the 3rd item quickly requires good mouse 
targeting). The first problem is an [application] design issue, but 
the second is solved nicely by this style of menu. 


Having said all that, I'll probably add two widgets: context-menu 
and bubble-menu which will be functionally and declaratively identical 
but with different look & feels.  Besides, I'm intrigued by the design 
challenge of this particular widget - I'm thinking multiple faces 
(one for each menu option) with a draw effect for the bubble and 
text ... hmm, but how to only register mouse clicks within a circular 
area ... and how to have pixels outside this area be transparent 
...and ...

One one trick could be a big sensor over the whole window.

And Chirs had a similar problem for non-rectangular faces. The idea 
was use a shadow-bitmap where colors represents choices.

Ashley, have you reconsidered allowing images to be inline rather 
than a file! type only ?

Already supported. Try the following:

	display "" compose [image (help.gif)]

oh ..?? when was this introduced?

I must have missed the ann.

No announcement. ;) I think it was introduced around 0.3.2 when the 
layout function was split off into a separate script.