Date: Mon, 13 Jan 1997 12:32:01 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: msmith@atrad.adelaide.edu.au, config@freebsd.org Subject: Re: Config Manifesto comments? Message-ID: <199701130202.MAA13966@genesis.atrad.adelaide.edu.au> In-Reply-To: <19576.853064978@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 12, 97 02:29:38 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard stands accused of saying: . > > Well, I'm happy to be convinced otherwise, but I remain skeptical. If > > you can come up with something that can handle interactive activities, > > and asynchronously-posted server-side events without a client-side > > scripting language, then I'll happily go along with it. > > Well, define "interactive activities" please. :-) Naturally you're not 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." Anyone who's used a Microsoft product over the years will be familiar with School One. Apple software at its best is an example of School Two. 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. Users usually start asking about desk lamps and rubber hoses at that level. > going to be able to do cute shaded draggy-bars and stuff in HTML, but > you can certainly do forms and menus which provide the same basic > functionality for the things you want to control (like filesystem > sizes), just not with quite so much flash. I can do without the flash > if it buys an easily distributed management station capability and > provides the closest thing to a "standard L&F" these days. 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. Your interface objects aren't bound to one another; I can't pick an item off a list, edit its details in some fields, then go on to another without swapping back and forth between several pages. That seems to defeat the whole point behind a graphical interface. It's got buttons and bitmaps, but it works like a pile of pieces of paper. Bad. 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 isn't, and unless you've seen something at Usenix that us out here in the boonies haven't, I don't see it happening soon. > And doesn't server-push buy you a reasonable facsimile of async > server-side events? Just think of all those cameras. It's crude, but > it basically works. 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? 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 some stuff into a CGI script and have it talk... er, yeah, that sounds like a Romeo-substitute, just like he talked about in that manifesto thing. Meanwhile I have a tiny window on my screen with the names of my six machines, each is currently coloured green. One of them goes yellow, and a small alert pops up to tell me that the load average has just hit fifteen. Damn, someone is playing with PC-Emu again 8) > > Well that's just bloody wonderful, isn't it? I can just guess how > > well _that_ is going to be received. 8( > > Well, I'm going to make one last-ditch effort before giving in to that > most contemptible of fates, but naturally no guarantees on that. > They'll probably just blow me off. :( Tell them about their new employee that's doing a black port to Domain/OS. Only don't get him fired until he's finished it 8) > > The only thing that we win on using an HTML interface in this case is > > the ability to display on non-x-capable (Windows, Mac) systems. I > > Not *just* that, even when running locally it provides you with a > decoupled GUI interface, 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. 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). > about, and you just let someone else sweat the browser (and there will > be new and interesting browsers coming out for some time to come), I'm sure there will. You can bet your (whatever) that they won't match our license expectations though, right? > whenever someone selects one of them. Everyone, and I mean everyone, > is scrambling to produce HTML driven configuration utilities these > days, and I really do think that the handwriting is on the wall here, > Mike, in big, tall letters. ;) This sounds like the lecture that the guys doing the 68k microcomputer architecture at IBM got around 1979. You can bet I like it about as much as they did. 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 moral stance. > Jordan -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701130202.MAA13966>