Date: Wed, 17 Jul 1996 17:10:30 -0500 (EST) From: John Fieber <jfieber@indiana.edu> To: Tim Vanderhoek <hoek@freenet.hamilton.on.ca> Cc: freebsd-chat@FreeBSD.ORG Subject: Re: FreeBSD keyboard Message-ID: <Pine.BSI.3.95.960717161328.252F-100000@Fieber-John.campusview.indiana.edu> In-Reply-To: <Pine.SOL.3.91.960716124149.18582A-100000@james.freenet.hamilton.on.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 16 Jul 1996, Tim Vanderhoek wrote: > > Have you ever driven in, say, Boston? :-) > > I think I'll try not to. :) Excellent choice. Boston is a great place though. The computer museum is geek heaven. They even have Dan Hillis' tinkertoy computer on display there. > So how would you rework the signing so that a driver would be able to > comfortably recognize the desired sign and its meaning? Creative positioning could be a good start. Typically each road will have two signs, eg 37 North and 37 South. Signs for north-south routes could be stacked vertically, east-west routes side by side. Then there are the signs that indicate not the road, but a route TO the road. Those signs could be different to avoid confusion (I just turned where it said 37 south, but the sign *here* says 67!). There are a variety of options, but to work they must be applied consistently. Fortunately, the example here represents a worst case; things are usually not so confusing. > by a picture? The exit for the highway denoted by the icon with > something that looks like a cherry would have a great big sign with a > cherry-like icon on it? :) I haven't seen it here in the midwest, but on the east coast, many main roads have icons. The MassPike is a silly looking tophat, I forget what the Garden State Parkway is, but they have one. The New York Thruway has a pretty distinct sign. I'm sure there are others. > > This is speculation, but I would venture a guess that your own > > name is a special case and it may be processed visually rather > > than linguistically. > > Maybe, but then you would expect small changes in font and point size to > ruin this ability. If you were a computer, yes. But you are human with astonishing image processing capabilities. You can quickly identify a letter with independent of its typeface. There are probably quite a number of words that you can visually chunk as a single "icon", while less common words require digesting the letters and then getting the word from that. I'm getting a little far outside of my expertise here so I'll stop at that. > I haven't used the Macintosh finder (confined to UNIX & Windows3|(95)). Windows 3 has no counterpart to Finder; 95 does, but it with my brief exposure, its more complex without notably more functionality. > However, dragging, clicking, etc. can only replace so much. At some > point, you have to fall-back to either a menu-based interface or a > command-line interface, I believe. The two are essentially the same... Exactly the reverse could also be said. Command interfaces can only replace so much. Try putting together a modern magazine using something like TeX, then something like PageMaker. The person using PageMaker will be home having a barbeque while even an experienced TeXer is still hacking away. If your task can be effectively represented visually, there is a good chance that a visual interface will be powerful. The unix pipe model doesn't really fit that category. You can represent a pipeline visually, but it doesn't buy you much. > made faster if all text files were denoted with a small icon. But, once > given this file, how is the GUI supposed to determine wether the user > wants to diff it with another file, concatanate it to another file, view > the file, edit the file, etc. Drag the file(s) and drop them in/on the tool you want. Even unix/motif can do this. If you have access to an HP box with vue, try dragging a file from the file manager and dropping it in the text editor window. > `A GUI makes it easy to do simple operations and impossible to do complex > operations.' - paraphrase from I have no idea who. And wrong. Its damn hard to drive a screw with a hammer, but that exactly what GUI and Command line bigots try to do all the time. The typical echange is that each camp picks an example of an application that simply has no counterpart in the other camp and say "See! (CLI|GUI) sucks because you can't do X!". It is etremely rare that a CLI way of doing a task can be directly mapped into a GUI implementation, and if it can, its usually less efficient than the CLI version. However, if you just look at the end result, often times you can come up with a different way of doing it in a GUI that IS efficient. For obvious reasons, it is usually futile to turn good GUI programs into a command driven model. The unix community, with their general disdain for GUI fluff, sit in a corner, sharpening their CLI tools, even tools that would be much better as GUI things. They are very good at this and even the tools that should be GUI based are reasonably sharp. The others are extremely sharp. (But, GUI tools they do have are typically so pathetic, they shouldn't be shown in public, yet they are often held up as examples of why GUI doesn't work.) Meanwhile, the Mac community, with their general disdain for CLI fluff, sits in corner hammering every task into a GUI environment, whether appropriate or not. The exercise of hammering natuaral CLI stuff into GUI clothes doesn't result in very powerful stuff, but the Mac folks learn a whole lot about building GUI and stuff that does natuarly fit that model is impressive indeed. Windows, OS/2 and Amiga sit in the middle with the worst of all worlds compromise: dull GUI tools and dull CLI tools. If I had the money, I'd be very content both a mac and a unix box. -john == jfieber@indiana.edu =========================================== == http://fallout.campusview.indiana.edu/~jfieber ================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.960717161328.252F-100000>