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."

Comments

I can't be the only one who

[lightspawn]

misread the title as "Rabid open source development"...

PHP + Perl + Links

[ptaff]

Perl and/or PHP can be pretty powerful to access databases and lotsa libraries; PHP can be compiled as a Command Line Interface which gives the console user a plus.

Links is a text-based web browser - building a console interface can be very simple using HTML and Links - you don't have to play with ncurses' mess.

The problem with GUI speed is not so much caused by design - it's the darn mouse that slows down everything... instead of doing a simple Ctrl-S to save, it's all these 6 steps (or more!):

• Take your hand off the keyboard
• Grab the mouse
• While looking at the screen, go to the menu
• Click on File
• Click on Save
• Get your hand back on the keyboard

Big words...

[clambake]

I will never understand why people feel the need to use big words just to make themselves sound smarter. Case in point, saying "Rapid Open Source Development for the Unix Console" when what they really mean is "Perl".

Gui doesn't suck, gui design does.

[evilad]

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.

Re:Gui doesn't suck, gui design does.

[pmz]

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.

I think GUIs take a lot more effort and time to do well than most people will admit. This is one reason the UNIX CLI is still around (it's quick, it's dirty, but it works reasonably well).

Mainstream GUIs often have these problems: the fonts tend to be small making them hard on the eyes, grey and white backgrounds with black text are hard on the eyes, there tends to be more information packed into one screen often requiring scrolling (time consuming and hard on the eyes), GUI layout managers are mastered by few leaving some pretty darn ulgy forms (again, hard on the eyes), many GUIs imply the mouse for intuitive navigation, etc.

It also doesn't help that GUIs are enormous programs, which are inherently unreliable and often not predictable. One reason Windows gets such a bad rap is that Microsoft produced a huge program in about 1% of the time it should have taken if they wanted to do it well.

Interface

[Samus]

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.

Speed vs Training

[FortKnox]

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

The key phrase here is a well trained operator. GUIs are pretty, and can be slow, but almost anyone can plop their butts down and start working on it immediately. Console apps, fast as they are, require sometimes days of training before working on it, then weeks (or months) of experience before getting truely fast at it.
This tradeoff is what businesses look for, and if its a spot with a high turnover ratio, they don't want to throw money away on training. Sometimes its just better to make it more user friendly than speedy.

I just wanted that point to come across for why companies go for web design. Right now I'm putting a J2EE front-end on a mainframe backend for a company to trade a 2 week training class to a 1 day relaxed training class to operate the software. It is something where speed is desirable, but web speed isn't that slow for the internal app.