From owner-freebsd-config Sun Jan 12 22:42:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA22766 for config-outgoing; Sun, 12 Jan 1997 22:42:49 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA22761 for ; Sun, 12 Jan 1997 22:42:46 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id WAA15356; Sun, 12 Jan 1997 22:42:30 -0800 (PST) To: Michael Smith cc: config@freebsd.org Subject: Re: Config Manifesto comments? In-reply-to: Your message of "Mon, 13 Jan 1997 12:32:01 +1030." <199701130202.MAA13966@genesis.atrad.adelaide.edu.au> Date: Sun, 12 Jan 1997 22:42:29 -0800 Message-ID: <15352.853137749@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 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