Re: UI Design

[M. Grabert]

On Sat, 25 Jan 2003, Stefan Urbanek wrote:

> Hi,
>
> This is how I see it...
>
> I draw a sketch of window layout with some app, like drawing with a pencil on 
> a paper. With this 'paper/pencil' approach I can be more productive and 
> creative. I tune it to get most of it and to make it usable. When I am 
> satisfied with the design, then i can start thinking about autoresizing of 
> views depending on the window size.  I can do that in Gorm.

no comment ;)

> What I want more? 1. I want it to be localizable
> 2. I want it to adapt to font size changes
> 3. ...
>
> Where is the problem? Relayout depending on the contents.
> Now I have my UI designed and I want to make it adapt automaticaly. Possible 
> solution should be to specify relative distances between objects. This can be 
> achieved by having NSPoint, NSSize as objects, not as C structures, where I 
> can two types of each. One with absolute positions and another with relative 
> to other NSPoint, NSSize. With current implementation, we have only absolute 
> points and sizes, we cannot specify the size as:    {half of some width, same 
> height} or point as    {5 points to the right of that point, same y}. Yes, 
> THIS is what we really want - specify either relative or absolute position 
> and size of a view. Because points and sizes are not objects, just plain
> structures, we have to do it another way: store an additional information 
> about the points and sizes of objects.
>
> To sum it up:
>
> 1. design and tune the interface.
> 2. autosizing
> 3. autolayout depending on contents

And here lies the problem. It's not as simple as that. It's not only the
position of widgets. It's the overall (not only look but) 'feel' of the
GUI. What happens if you press the right mouse button?
A context-sensitive menu? nothing? The deault of the operating system?
Click-to-Focus? Sloppy-Focus? ...

If you design it like this, your design will be similar/the same on all
platforms, but it won't follow the standard GUI guidelines of the OSes.
Or just take the 'HELP' function for example.
Just look at the many of the OPENSTEP (MACH/Enterprise) Applications; they
follow the way OPENSTEP MACH/NeXTSTEP works, and thost applications
doen't feel like Windows apps (similar thing with MacOS X). I think that's
the issue here.

You're right, you CAN have a platform independent (file) format to specify
the GUI, but it's either "native" for just one/some OSes, but not for
every OS.

On the other side, I see quite a few applications (on any OS) that doesn't
follow the OS' GUI guidelines. These examples are usually examples of a
bad GUI design altogether. But especially on MacOS (X) a non-standard GUI
is not the way to go. So we should be not really platform-neutral, but
we should care more of the GUI guidelines of each OS in order not to
'horrify' uses.

Okay, OpenStep has it's own guidelines, and they are good, but only when
all applications follow these guidelines. If you're trying to be platform
independend, these rules should be softened.

> The most important thing is, that the FIRST step should be done ONLY by a 
> designer, without any forcing/assistance of automatic layout. Relayout design 
> should be done by the designer, when the interface is finished. Either as 
> grouping objects, or specifying relative sizes and positions in similar way 
> as we specify outlet/action connections.
>
> Be it Gorm or Renaissance visual editor, I think, that both should keep that 
> order of UI design steps.
> I see no sense in creating one UI to be adaptable to an UI philosophy of a 
> hosting OS. That is one-size-fits-all solution and the result will be 
> unusable,
> but portable UI.

Well, I agree fully. But we have to make a compromise. I personally think
ideally there should a file format specifying the (relative) position of
widgets that are common to the operating systems we care of, but have the
OS 'depended' GUI stuff in different files, so it will be easy to port a
GUI to different platforms.

But that's just an ideal theory. I don't know whether this is feasable at all.
Maybe we should just stick to the OpenStep guidelines and do it our own way ...


Max