Re: Dream GUI toolkit (Was: GUI programming.)

From: MSCHAEF.COM (mschaef_at_io.com)
Date: 05/15/04 

Date: Sat, 15 May 2004 15:55:21 -0500

In article <40A121DB.EFBEAE99@Sonnack.com>,
Chris Sonnack <Chris@Sonnack.com> wrote:
>"MSCHAEF.COM" wrote:
>
>>>> makes for 1,310,720 possible window sizes. Are you going to
>>>> design a nice layout for each of those?
>>>
>>> Yes. In exactly the same way--only better, because it's done
>>> by hand--as your auto-layout stuff does.
>>
>> lol... didn't we recently debate this, Chris? :-)
>
>Heh. I think you're right. And I wanna make clear I'm pretty
>mellow about this.... re-reading my post..... might have been
>a little over the top is spots.... no angst intended, ya?

Of course. Same things holds true for me, regarding my choice of language.
I think my wording is stronger than my intent.

>This might be a fruitful path to explore. I'd like to know a bit
>more about some of these capabilities.
>
>* At some point, if the window gets too small, what strategy?

Most auto layout systems I've worked with can calculate a minimum size
that works pretty well. I've never thought that controls disappearing or
getting obscured just because of the window size is a particularly
appropriate strategy. Controls should only be affected by things that
pertain directly to their semantics (ie: hide a button when the hardware
doesn't support that feature or gray it out when that function isn't
available.)

>* Proportional sizing for some elements (e.g. textboxes), but
> not others. They should be proportionally *spaced* though.
>* To what degree can you impose layout rules? For example,
> maybe I don't want related controls "spreading out" when
> the window gets bigger--I want their distances kept. But I
> may want other elements to change.

Most auto layout systems can do this pretty well. In Tk, there are ways to
specify how the control should expand seperately from the expansion of the
whitespace around the control.

>Might be interesting to define a basic GUI and explore various
>ways of doing it....

The best way to learn is to do.

>What possible value is there in having a simple dialog sizable?
>Sizable windows exist for a reason, and if no such reason exists?

To show more or less content in list boxes, edit boxes, preview panels,
graph displays, etc. To make it easier to see what's underneath. I find
myself, all the time, wishing I could see more of what's in a dialog box.

>I don't subscribe to the unicy theory of total user control.

Neither do I, but I'm also don't subscribe to the delusion that I can
anticipate all my user's use cases and environments.

>The
>GUI of my apps is part of *my* art, and you WILL see it as *I*
>designed it. If you don't like it, tough, use something else. (-:

I would _never, never, never_ buy software from a vendor that I knew
thought like this. Just to be clear: _Absolutely Never_. This even extends
past simple GUI style to things like workflow model, and overall design.
Steve Jobs has _long_ history of making decisions for "artistic reasons".
That's a big part of the reason why the original NeXT box only had an
optical drive, the original Macintosh had no expansion slots, and Apple
produced it's dismally selling Macintosh Cube a few years ago. All of
these things had design that was heavily canted in favor of "art" instead
of function. All of these products had trouble with marketplace
acceptance. (Macintosh quickly incorporated expansion options and more
memory, NeXT switched to hard disks before folding the hardware business,
and Apple discontinued its Cube).

As a user of software, I couldn't really care less about any artistic
aspirations of the developer. What I spend money on when I buy software is
a tool that I can use to get particular tasks done. If the "artistry" gets
in the way of the functionality, that's a big time losing move, IMO. That
said, a tool that combines both can be a real treat to use.

>More seriously, try to think like an average user. The less "other"
>stuff (meaning stuff not directly connected with what they are doing)
>you throw at them, the better.

Sure, but a resizable dialog box isn't thrown at the user unless they're
looking pretty hard (and then, they typically know what they're doing).
When it becomes an issue is when they need to see more of what's in the
dialog box, and try to resize it like they're used to resizing other
windows. All of a sudden, they can't do what they need to do, and they
have a new exception to learn about why some windows can be resized, and
others not.

If we were talking about some kind of feature that doubled the number of
controls in the window or something, I'd see where you're coming from.

>There are logical reasons for being able to move a window. I can see
>no *logical* reason for making all windows sizable. I just can't.

Yeah, there are some windows for which it doesn't add much value for the
user to be able to resize the window:

http://www.icegiant.com/images/options_box.gif

That said, auto layout would have made it easier to design and extend
with new capabilities. The backend of that dialog box is a Lisp program
I'd love to allow to extend the options dialog box with new controls.
That'd be easier to do if there was a layout engine in the back end doing
the dialog box layout.

>I would consider that an even bigger win! This thread started over
>the idea that visual==bad, and that's my reason for speaking up.

Yeah, I would _never_ say that visual==bad. If you can have both, that's
the ideal.

>In fact, that's worth emphasizing: I don't have that much issue
>with auto-layout (given sufficient tweak/rule control by ME :-),
>but creating a complex layout without seeing it? Why?!?!

Yeah, there is a cost attached to auto layout without a visual tool. I
don't think anybody would argue that point. That said, the cost is worth
it, to me, if I end up with a dialog box design that's more flexibile than
a list of rectangle coordinates. The ability to use a hierarchy of boxes
to logically specify the relationship between controls can be very
valuable.

>>> The only real difference I see is that I have to write the resizing
>>> code myself, but (personal style!!!!) I prefer having that level of
>>> control.
>>
>> What productivity do you gain by writing the code yourself?
>
>It's not about productivity, it's about control of my art! (-:

I've never felt like I've lost any control with auto-layout. It's not
like I'm saying: "here's an object, drop the corresponding controls on the
dialog as you with". That approach is almost guaranteed to fail. What
auto-layout forces you to say is "here are my controls, here are the
relationships between them, and here is how they should fill out my
dialog". That's a lot more powerful to me than a purely coordinate-based
visual tool which effectively requires you to say "here are my controls:
put this one here, this one there, this one the other place,..."

> Like many long-time programmers, I write my web pages
> "from scratch." It's as much art as science, and I
> think it's good to be close to the material.

Then you're absolutely familar with doing auto layout design textually.

>To be honest, I can't conceive of how an auto-layout could even
>begin to work on that page. May be my lack of experience with
>modern layout tools, but every control there is carefully placed
>(often to the pixel!).

Does the pixel resolution matter? Or is it that accurately specified to
enforce higher level constructs (ie. line these up, make these the same
size, divide this line into thirds, etc.)

In any event, I'd suggest downloading a copy of Tcl/Tk, and spending an
hour or two playing around with the layout facilities. It might make where
I'm coming from a lot more clear, plus it's a fun tool to play wirh. :-)

>The thing is, the whole look is "destroyed" now. With a single
>new combo, it *might* work to just open the three group boxen to
>the right of Test Info, but it might not look right to my eye.
>I might determine a new layout is required.

And if you do, you'll likely want to keep the control groupings the same,
but move the groups themselves around. In which case, a hierarchy-driven
layout tool can save some time.

>Frankly, I would be astonished if it could do the job anywhere near
>my requirements. I'm not kidding, I am REALLY anal about this stuff!

My hunch is that the computer could get you 90% of the way, and let you
tweak things to fit your standards. Even if it isn't perfect after the
auto layout, it'll still save _lots_ of time.

>Actually, in terms of the app, it's probably not a minor change,
>but that's a side issue. I'd say I'm more concerned with the
>final look and usability than I am my time re-designing it. The
>latter is a one-time cost. "Look and feel" is forever.

Sure, but if you can adjust the dialog box more quickly and effectively,
it'll be easier to converge on the layout that works best. To put it in
other terms, if I was moving cross-country to California, I _could_ pretty
easily decide to walk. That might take a couple weeks, and in the grand
scheme of my life, it's a pretty nominal cost to pay. However, if I drove,
flew, or rode a train, that'd work too, and I've more time to spend on
things that will matter a great deal in the long run (where to live in
California, what kind of housing to procure, etc.)

>But,... just to hammer the point, you're talking to someone who
>considers GUI design an *art*. You'll find very few artists who
>would agree that auto-layout meets their artistic needs.

My guess is that I'm at least as anal about how my interfaces work as are
you. :-)

>> Like the time we last discussed this, your position reminds me of
>> the folks who resisted compilers in favor of "retaining control"
>> by coding entirely in assembly. :-)
>
>Ouch! :-) I think (or wanna believe?) there's a difference. It's
>not control for the sake of control (well, maybe a little bit :-).
>
>It's really about getting it artistically perfect.

Exactly.

-Mike 

-- 
http://www.mschaef.com