World: r3wp

The fundamental thing which makes one GUI better than others is consistency. 
 period.   design is all about making the looks and feel work for 
target a target audience, but if its inconsistent accross the experience, 
then its instantly unusable for anyone. 
.

IMHO that is  ;-)

IMHO ppl are more turned on widgets,  general functionnallity, simplicity 
than on esthetical issues.  Ashley when do you plan to release  new 
widgets (tabpannel with scrollable header, menu, listview) i'm going 
to start working on treeview widget as usual how do you want data 
to be submitted to it  (data block structure fo ex: [ node_label1 
[ leaf1 leaf2 leaf3 subnode_label2[leaft1 leaf2] etc.. ]])?

I am inclined to agree that consistency is important in GUI design 
(imo. down to the last detail, it reflects competency), but *the* 
most important thing is that form meets function, and a part of this 
is selecting the best possible visual metaphor for the task at hand. 
 While widgets are a means to this end, it's all too easy to overuse 
them.

Now having said that, style is important too.  To most observers, 
WinXP looks better than Win2k looks better than Win98 looks better 
than Win95 looks better than Win3x looks better than ... etc.  Now, 
if you go back the way and use a Win95-style app in WinXP (even the 
Rebol security requester) your (or at least my) first reaction is 
'what's wrong with this app'?

I've thought much lately about the difficulty in introducing a third-party 
style into any given OS environment (which we as cross-platform developers 
must consider short of using native libraries) and it is difficult. 
 The subtleties of eg. OS X and WinXP are far different, so is there 
a happy medium?  I'd like to think so, but having tried /View on 
OS X, I'm not so sure that my previous attempts at platform-neutral 
GUI style are as successful as they could have been (though anti-aliased 
fonts may be a key missing feature).

Chris - hopefully RT does solve linux and os-x situation with fonts 
....

as for me, I can accept different look, even a bit different app 
logic, but not behaviour - keyboard navigation ...

I am e.g. ok with IOS look, but can't stand styles, which don't work 
like native ones ... then each click, key-press which behaves differently, 
is pretty annoying ...

On the one hand, I think that 'form follows function' allows some 
deviation from platform-native style, though this is recommended 
more on a per-application basis (ahem, declaration of interest here). 
 On the other, we can select certain graphics based on platform (system/platform) 
... sorry Petr, still on a riff here ...

we are imo in new era of alternative designs - back to the amiga 
days, where OS is NOT the main part. Your context is the app you 
are working with.

... and maintain small libraries of OS specific graphics.

Petr, I'm going to disagree with you here (re. alternate designs). 
 I think I've made my position clear...

Carl's idea, that e.g. 'list style has to allow borderless design 
is pretty right. Go and look at MS - they WILL come to our living 
rooms with some devices, and you would not want your OS to pop-up 
- but apps will be important. Well, I speak of a different target 
market, but ...

e.g. http://www.mythtv.org, look for screenshots of UI - very View 
like ...

database related apps are different, of course. But then look even 
into MS - they are changing UI guides every 2 - 3 years, with new 
OS, or new Office ...

Your point?

that some kind of apps do not strictly need to keep OS metrics, as 
OS is then just a medium - irrelevant ...

I have heard many times, that if someone will not keep OS guidelines, 
then such app will be throwed out the window. Hah! What an excuse 
.... look at ad-aware - it does not know even keyboard. Look at those 
antivirus suites .... so- my point is, that we don't need to necessarily 
be 100% compatible - that is old ...

Well I'm going to disagree then.  Unless your alternate style (or 
indeed, functionality) is good, then I think users will question 
the competency of your app.

Ah well, riff broken -- back to work...

I work with 300 users, met thousands, I don't agree with you too. 
Someone created a myth imo ... I think that who pays most attention 
is - computer geeks to have something to talk about :-) Each IS here 
has its own set of logic. I am after consistency, but not necessarily 
consistency with OS as a crucial point of app UI usability ...

In that case, you could have agreed with my original point and let 
me finish...

just to not understand me wrong - I reak KDE (or was it GNOME) material, 
few referenced here articles on that topic, I can agree, but I just 
don't think that different design is a show stopper. at Devcon, there 
was a mention of Skype - how does IM messengers keep most other OS 
apps usability logic? :-)

reak=read

shadwolf
	tabpanel with scrollable header - being added to 0.3.8
	menu - see note below
	listview - being added to 0.3.8

 treeview – data structure should be simple & consistent with other 
 widgets ... sub-blocks are the obvious way to go but I'll leave the 
 implementation choices to you ;)

Menu Widget


I am of the opinion that a menu widget is more trouble that it is 
worth as:


1) Its use is being discouraged in modern UI design (toolbars have 
made them obsolete to a great extent) - they feel just so Win95 these 
days

2) Mac OS X does not use them at all (at least at the application 
window level)

3) A fully-fledged menu widget is practically a UI in its own right 
with menu entries having icons, toggles, key shortcuts and various 
other mini widgets

4) The underlying REBOL popup system needs fixing first (this also 
impacts the edit-list, drop-list and context-menu widgets)

5) It's just too complex to meet the definition of a simple RebGUI 
building block widget - our time is better spent on other widgets 
that are required

6) How many users clamour for menus these days? Most folks I've met 
prefer pressing a single button / icon and positively detest multi-level 
menu selection

All my opinion, so feel free to disagree.

UI Design


Chris / Pekr touch on very important points here ... we have to live 
with the fact that we are trying to create a cross-platform UI. This 
UI must:


1) Look & feel relatively familiar to users on Windows, Mac and Linux

2) Be internally consistent (e.g. RebGUI widgets behave in a consistent 
manner, have a similar look to each other, etc)

3) Be externally consistent where expected (e.g. scroll buttons at 
each end on Windows, grouped on Mac; tab-panel look, etc)

The way to achieve this, IMHO, is:


1) Don't try to mimic one particular OS too closely (i.e. try to 
pick a neutral look - I think users of an OS are more tolerant to 
something that looks different as opposed to something that looks 
like it belongs to another OS)

2) Adopt the lowest-level of common functionality across OS's where 
possible (e.g. down arrow functionality is pretty well defined)

3) Make allowances for minor, but common, differences (e.g. tab-panels 
are rendered quite differently between Windows and Mac, system fonts 
differ, buttons appear quite different)


So in practical terms I want to gradually move away from a WindowsXP 
look and start adding a few conditional look & feels depending upon 
OS. These will not fool anyone into believing a RebGUI app is native, 
but at least Windows users will not be left feeling it's a Mac / 
Linux app or vice versa.

menu: I agree, what I like a lot are circular context menus (right-click). 
There icons are arranged in a circle around your mouse cursor. Makes 
selecting the function very fast and is totaly easy to use. Adding 
a tooltip feature to show a short text in case of a mouse-over makes 
sense. More I wouldn't add.

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