World: r3wp

Pekr, the help system might be done with some kind of layers. So 
far, I'm not sure Carl's specs are going to be followed. That depends 
on the architecture.

Multi-line tabs is generally considered bad design.

are there any "Carl's specs" for layers at all?

there was a spec document which specified layers, guides, etc. but 
it's lost now.

why is something like that lost? :-)

I just can't find it. Spent hours looking for it. Carl can't find 
it either.

Nested tabs are often cited on sites that document and discuss bad 
UI design.

Nested tabs are just workaround to achieve multple row tabs ...

Which are also considered bad design.

As are scrolling tab bars that don't show all of the tabs at once.

The "bad design" part being "too many tabs, use something other than 
tabs as a structuring model".

exactly.

Here's two examples from Mikrotik RouterOS, which migh eventually 
serve as an inspiration:

http://xidys.com/mikrotik/mikrotik-collapsable-ui.jpg
http://xidys.com/mikrotik/mikrotik-many-tabs.jpg

Yes, that should be possible.

and also with d'n'd reordering :)

I am fine with arrows, although some listbox/menu is probably faster 
solution ....

btw - in DOS era, we had one concept in UI, although it regarded 
only the grid - each user could save his/her grid setup. Now as reordering 
of tabs is possible, it would be maybe nice to allow to save UI set-up. 
But I did not think about such concept in deep, so not sure how it 
would eventually complicate the matter ...

Save UI setup - hm, yes, that should be possible, at last tabs order. 
There's not much else to save right now :)

last used tab, last focused item. there are a few things to save, 
but as long as they can be retrieved and set in code, it should be 
possible to do.

speaking of which: would it not be a good idea to have functions 
that can extract and impose facets on a face in one line of code?

like set-facet and get-facet ?

yes, only for the entire face.

that would make it simple to save a state

seems there are some issues with LOAD and SAVE in A110, so no r3-gui 
build today.

Hm, we may try it to see, how it works.

Imagine saving the size, ordering, freezening of grid columns for 
e.g. It would be tiresome for user set it each time app starts .... 
just an idea ...

Yes, I see no problem in allowinf this.

I disagree.  Nested tabs are not the same as multiple row tabs.  
With the former you can effectively book mark a deeply nested page 
.. the latter you can not

bad design
 vs "good design" is just a matter of opinion ...

there is no intrinsic rightness or badness

I agree that the tree view has replaced multi-line tabs in recent 
years.

There might be slightly different usability issues with nested vs. 
multiline tabs. Multiline tabs are plain confusing (where is the 
right button?), where nested tabs can be disorienting (where am I 
or what mode am I in?). I've built an app in VID Extension kit using 
the latter method, and the app can sometimes be disorienting to use, 
so I had to help out by using different colored backgrounds.

Doesn't the tab colours help orient you?

actually not, since some tabs contain nearly identical UIs. people 
are not used to looking at the tabs at any other time than when selecting 
them.

Well, I have several hundred screens in my app ... not sure what 
else I can do to organize them

Also the nested tabs allows me to refer to a particular screen by 
a path notation

I was surprised at how "narrow-scoped" some users are, when working 
in a program, almost down to a single face, not noticing the larger 
context or organization of the program, particularly if the program 
has many modes (tabs). I think that its important to design UIs around 
clearly marked mode of operation, or even better: Have mode-less 
operation.

Are nested trees any better?

MS approaches this by using a "control panel" of icons

I prefer flat list that can be searched, when there are no other 
options. Old MUI preferences windows on the Amiga and the KDE configuration 
or MacOSX settings program comes to mind.

Each icon then deals with a particular subsystem

Not sure abou that approach as then the user ends up with lots of 
open windows

Right. The problem is usually that an item you are looking for, doesn't 
reside in the subsystem that you think it does, so when there is 
no other way, at least provide a flat structure search.

So, what are the exemplar GUIs in dealing with lots of information?

What does the mac do forinstance?

there is usually a method for searching for what you want. a typical 
mac app even allows searching all menus in the menu bar.

The modern version of the system dialog does a list on the left instead 
of tabs. It might look like a column of links in a left-side navbar, 
but it is basically the replacement for the tabs.

I do not like multiline tabs either, and they violate some of the 
rules of good GUI design.


Sure Graham, good and bad design are matters of opinion; however, 
they are based on what "most users" can understand and efficiently 
operate.  If a GUI causes a user become "lost" or do the wrong thing, 
then it's not a good design.

I don't like multiline tabs either but they're not the same as nested 
tabs :)

There is now Carl's blog upon how to easily list styles in R2. I 
posted corresponding R3 code, although it might be preliminary:

foreach [name obj] guie/styles [print [name "-" obj/about]]

But - I would like the GUI team to think about following aspects:


Imo the guie/styles list is highly insufficient. Imagine you want 
to auto-inspect (load) list of styles into your GUI designer. What 
you get now is a flat list of styles, where apart from 'table, you 
have its sub-styles like 'table-cell, 'table-row, 'table-header, 
etc. I am not sure that in the case of an IDE, you want to see those 
styles listed. OTOH those are legitimate styles, from which you might 
want to derive something, or just being able to change their aspects. 


So, I propose to resolve this situation somehow. The implementation 
is up to gurus, just few wild ideas:


- use tagging - tag style as 'main/root/parent, whatever - but - 
that introduces another field to the styles? Maybe not, because I 
expect some tagging system being available anyway?


- create guie/widgets, e.g.: guie/widgets: [table [table-cell table-header 
table-row] - that way we will be able to list just/only widgets as 
table, not having the list poluted with widget internals


- the above aproach might not work well in the case, when you aproach 
styles more as a CSS, not as widgets. Because - even e.g. 'table-cell 
might be derived from a totally different style, e.g. a box, or field, 
so I have no idea of how to keep track of those dependencies, but 
this is the area I leave for gurus to think about. E.g. someone changes 
box style and your table is influenced and user might be confused, 
why it happened. But I expect style/parent or something like that 
being available?