Slashdot Mirror
Rapid Open Source Development for the Unix Console?
Adam Weiss asks: "With Web Interfaces and GUIs being all the rage these days, it seems hard to find much about console application development. Web Interfaces and GUIs look pretty and impress people, but I've noticed that it's awfully hard to beat the speed of a well trained operator on a well designed console interface. Some of the HR folks at work use a console app to access employee records while others use a Windows GUI. The console folk can lookup and update three records in the time it takes the the GUI folk to clicky-clicky through one. So, are there any mature Open Source toolkits that would enable rapid development of console applications. Sure, there's curses, but that's low level pain in the arse. I'm talking like something that is specifically designed for building database applications- kinda like an extensible version of Microsoft Access Forms for the green screen. Something that's pretty easy for the simple stuff, but lets you break out and get complicated if you need to. (unlike Access) I know there's gotta be plenty of obsolete commercial stuff that makes these kinds of projects easy. I just want to know if there are any Open Source alternatives that are somewhat modern and well maintained."
Do the gui users have to point and click? It should be a pretty trivial task to make the gui useable point and click and keyboard navigable.
If the same amount of time and effort was spent making the gui ergonomic and "keyboard accessible", I suspect that you would find that their speeds were about equivalent.
A long time ago I read a book called "About Face." It was a book on user interface design by the guy who created Visual Basic (I think). Now don't discredit the book because its associated with a VB guy. From what I remember there weren't any code samples it was all theory. Basically it was talking about all the things your average GUI programmer was doing wrong back then. One idea that stuck in my head was that often people make the mistake of writing one screen to both view/edit and input data. The idea was that data input screens need to be designed for speed and efficiency but this layout is ugly and cumbersome when trying to view or edit a record. A manager of a data entry department at a local company in cincy said that everytime his people have to take their hands away from the keyboard and use the mouse he loses 3 seconds. So if you design a GUI screen that doesn't require the mouse, has lots of short cut keys and other conveniences like auto tabbing to the next field when the current field reaches the required amount of characters you should be able to achieve just as much throughput as a console app.
In Republican America phones tap you.
I know other people have said it, but let me give more concrete examples.
Keys can be associated with every field on the screen. The convention is to mark those keys with an underscore (prefacing the desired key with '&' in the label definition on most GUI systems), and CTRL-thatkey will jump to that box.
Reasonable default values are another key to console-app speed, and there's absolutely no reason why they can't show up in GUI apps either. In fact it's almost exactly the same amount of work.
The GUI has other advantages over console use as well, because of the wider array of widgets you can use. A notebook tab interface is easy to write in a GUI, but I doubt many console libraries make it quite as easy. (There may be isolated counterexamples.) Tab navigation is usually as easy as a keypress, CTRL-PgUp (mozilla) or CTRL-Tab (wxWindows tab control, some exceptions in wxGTK if certain widgets are included in a tab that might eat the CTRL-Tab) for instance. The ability to embed things into the GUI display might be useful.
I'd suggest going GUI and just being very methodical about making shortcuts for everything (and showing them on the screen).
Failing that, if you have time to learn it I'd suggest building the app in Emacs, or at least looking at it, along with the Lynx+web suggestions I've seen.
I, too, use the all the keyboard shortcuts I can, and find them surprisingly available.
:) ), the users may suggest features that genuinely enhance their productivity. I wouldn't be surprised if getting them to use the keyboard may be the least beneficial effect of the new interface.
But the point he was making is cogent none the less. If you go into the office and tell your staff they have to start using the apps. they've been using for years "the way you think they should be using them," you'll probably note the conversation around the water cooler goes silent as you approach for several months. And not in a good way. People usually need a motivation to re-train that is a little more upbeat than "because you're inexcusably slow."
If you have the tools to make the development cheap, a new app interface is a great approach to the problem. You get to have meetings, everyone gets their input, several features they've always wanted are added. They "buy in" to the new interface, and they all start at the same point when learning the new system.
In the case where the Linux developer is not the only smart person in the organization (it happens