Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 12 Jan 1997 22:42:29 -0800
From:      "Jordan K. Hubbard" <jkh@time.cdrom.com>
To:        Michael Smith <msmith@atrad.adelaide.edu.au>
Cc:        config@freebsd.org
Subject:   Re: Config Manifesto comments? 
Message-ID:  <15352.853137749@time.cdrom.com>
In-Reply-To: Your message of "Mon, 13 Jan 1997 12:32:01 %2B1030." <199701130202.MAA13966@genesis.atrad.adelaide.edu.au> 

next in thread | previous in thread | raw e-mail | index | archive | help
> Ok.  There are two schools of interface-design thought that are relevant
> here.
> 
> School One says : "make the interface pretty.  present the user with lots
> of options, and when they hit OK, check all the answers and put up an 
> error message about some of them."
> 
> School Two says : "design your interface so that the user cannot enter
> erroneous data in the first place, insofar as 'erroneous' is an error
> that we can detect or are aware of."

Right.  And, unfortunately, there are also very few people around who
are implementing UIs from the 2nd school these days - not even us
(just look at most of sysinstall's "forms").  It's just harder, as a
general rule, to provide frameworks which do on-the-fly validation of
user input.  It's not impossible, and I've written forms packages
which provided for both, it's just harder.

As you say, I'm not here to argue principles or fundamental questions
of moral rectitude - there are dozens of ways to skin a cat and all of
them have their strengths and weaknessess.  I'm just trying, at this
point, to figure out which approach has the greatest likelyhood of
actually being implemented in this coming year and also which is the
most future-proof, since we're not likely to be doing all of this a
3rd time.  Just getting it done a second time has already taken years! :-)

> HTML, by its very nature, restricts you to School One, except at the
> most anally restrictive end of the implementation scale, where you
> have sacrificed any attempt at integration and are basically asking
> questions one-by-one.

I don't buy that.  I think of it as more akin to a hypercard stack.
Annoyingly page-based, often stupidly organized, but you can still
cluster things by concept.  My top networking page is going to have a
list of all my networking service types, with pointers to other
documentation at the bottom (HTML *does* allow you to do a nice job of
integrating your relevant documentation with the actual installation
procedures, if you plan for that in advance and Do It Right).  I click
on, say, DNS Services and I get a sub-page allowing me to add, delete,
query or change entries, or maybe just figure out what DNS is at all
and why I'd want to set it up (links to tutorials and such).

Doing all of this with Tk would require a fair bit more work - we'd
need to select a help system (I kind of like the one in BLT), clone
docs from the Handbook and Tutorial into it (or write/incorporate an
HTML browser widget for Tk and move in the other direction :-) and,
what's more, Juliette would have to know about the documentation
properties for each UI screen or you could never keep them properly
associated when changes were made.

I dunno, HTML just sounds a lot easier to me! :-)

> But it doesn't.  Just keep reminding yourself that the user _isn't_ going
> to be using Netscape for their interface.  Think Chimera, for an LCD.

Ok, I just tried out version 1.65 on the FreeBSD pages.  It didn't
look particularly great, and something's funky with its popup choice
menu handling (everything's double-spaced), but the forms look usable
enough.  What does it not do which you need, exactly?  I'm willing to
look at all this as pie-in-the-sky material if no browser exists which
provides the features we absolutely *must gotta have*, but I'm having
a hard time believing that nothing truly exists.

> There are lots of moderately nice things that you can do with Netscape
> or friends that aren't actually in-band with the HTML spec.  Sure, if
> there was a decent browser with a sane license, I'd swallow my pride,
> learn its client-side scripting language and make it happen.  But there

I'd still like to hear more about why you feel client-side scripting
is so necessary to providing a functional interface.  Note that I am
saying "functional", not "snazzy."

> Er, yeah.  So here I am with my gonzo web-based monitoring tool.  I have
> a network of half a dozen machines that I'm watching.  So I have six
> copies of my noncommercial web browser running.  Great, eh?

Huh?  Not necessarily.  You can have your non-commmercial web browser
running with multiple pages open, and I also never said you couldn't
load netscape after you got your system up, simply that we needed to
get through "install time" using simpler HTML-based screens.  If
frames become the way to go for something non-essential to the
installation, what do I care?  If you want to use all the fancier
features of this tool, I think that a fully-featured browser would be
a reasonable prerequisite - just so long as none of the very lowest
level ``get the bits on the disk'' pages use such features.  With
frames and java support as prerequisite features, you can then visit
your cute SNMP replacement page and rock out.  If you don't have a
decent browser, you don't visit that page, sorry.  Get a better
browser and come back.

> So, you say, have a single browser talk to a server that's collecting
> status from all the machines and summarising it.  Yeah, you could put

No, I didn't actually say that.  That would be gross. :-)

> Argh!  Here we go again.  If you accept that a GUI interface is mandatory
> (eg. web browser), then I assert that Tk will do everything that you can
> do with HTML faster, in less memory, and with more independance. 

Well, I'm certainly willing to be so wowed by your Tk-based prototype
that I give up all thought of using that icky HTML stuff, but since
we're just debating intangibles here, I say that my intangible can
beat up your intangible and so there! :-)

> Hell, if people could swallow being stuck with Tcl for the client-side
> of things, we could find some win32-challenged contributors and make the
> client run under win32 and on the Mac as well.  There aren't many 
> platforms with a GUI web browser that Tcl/Tk won't run on (OS/2 is about
> the only one that comes to mind just now).

Hell, I don't *dislike* this idea, Mike.  You know I'm a big fan of
Tcl and Tk, and I'm just playing with Tk8.0 right now to see what
kinds of neat new features it has.  The idea of a Tk based client
application using a socket to talk to some nifty configuration server
running on your FreeBSD box scarcely fills me with horror, and it
sounds like a very clean way of solving the problem.  I'm just afraid
that like all clever, custom solutions, people will have difficulty in
understanding it and we'll end up with maybe 2 or 3 people working on
the code. :-(

I dunno, playing the other side of the argument for a second here, how
long do you think it would take you to code up a prototype?  How many
properties will Juliette try to support in the first version, and how
will Romeo determine the composition of its various configuration
screens?  Will Juliette feed Romeo raw Tk code representing the
interface to be created, or what exactly?  How will the templates be
written?  How will Romeo know the set of properties managed by a given
copy of Julliette, so that he knows to construct menus for them?

I'm willing to dive in and help you code this, heck, I just want to
know where you're going first! :-)

Now if you asked me those same questions about an HTML based system, I
could answer them without much thought.  One of the advantages of a
highly-constrained system is that it makes most of the implementation
decisions pretty obvious. :-)

> I'm sure there will.  You can bet your (whatever) that they won't match
> our license expectations though, right?

I wouldn't be too sure of that at all.

> Regardless, as I've already said, if you can show me a good set of
> metaphors for the sorts of things I'm griping about I'll happily
> change my tune.  My primary goal here is a working product, not a

Well, I'm still not really sure just what it is you *are* griping
about, so it makes any sort of rebuttal rather difficult to
formulate. :-)

Why don't we work from first principles and define the system in terms
of its objectives rather than debating this on a purely ethereal
plane?  What do we want to see here, and what should it look like?

						Jordan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15352.853137749>