The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Hanging on to character-user-interface applications?

Is anyone out there hanging on to legacy CUI applications (think telnet) or even designing new ones?  Some people I work with seem to think that for high-volume, high speed data entry, CUI is the only way to go.  I'm skeptical, though, and I wanted to get some other opinions.  Is CUI dead?
Rex Gozar Send private email
Monday, August 22, 2005
Still use telnet and other CUI everyday.

At home it's because the online things I chose to do are mostly in text, they don't need to be wrapped in html (nor is it even provided anyway)

At work most tasks are graphical, but some are only available in the envrionment through text based, performed in various shells on various systems.

Still have to use a mainfraim with no GUI.

Tuesday, August 23, 2005
I still do work on character based systems.

And, I am schedule to retire the last character based version of my reservation software this fall.

And, I still sub-sub-contract myself out to consultants that need my skills for green screen systems. (pick database, and Screen Gen, and al-file).

For data entry, those character systems do tend to be better. However, being the same person who wrote the original system, and then being the person who  is going to write the replacement in a windows environment, then I can concentrate on what the problems will be, and also know what key sequences users are comfortable with.

My conclusion is that a GOOD windows system can equal a character based system for data entry. However, you as a developer have to keep this concept in mind. So, I would even say that EXTRA effort is requited in the windows side.

Since I make such EXTRA efforts on the data entry side, then where does the windows interface really make a difference in the applications? The MOST improvements I find are in the reporting side.  When I say reporting side, two areas come to mind. The first is that you are now not limited to a fixed character layout for the report. Thus, report layout is much better, and far more flexible.

However, where things REALLY start to make a difference is the process of prompting a user for input for reports.  Prompting a user for report input is a DIFFERENT process then is data entry. To me, this is where windows systems really shine over character based.  The obvious areas are where you can select SEVERAL options from a listbox by clicking on them. Here is some screen shots of what I mean:

For example, I have a ton of reports that ask the user for a start date, and a end date. I also want to use a calendar for this prompt. In a windows environment, I can display the start and end date calendars at the SAME time. And, often the “default” is one month (so, the start cal, and end cal are pre-set for the user).  The enter key defaults to preview. So, we are down to LESS key strokes then the character based system. You can achieve this type of thing in a character based system, but it is usually not very good. Thus, windows tends to be more mode less for data entry then a text based system. This don’t make too much difference for data entry (since you follow some order), but the instant the process becomes non data entry, then windows really starts to shine….

There is also the issue of training users, but worse is that companies that still use green screens tend to “think” they are in the stone age. Long time users of the system don’t care, but new users now do find character based systems that don’t use a mouse quite difficult to learn. And, even now, I still often see people reaching for that mouse when showing me a problem with my green screen software…..

And, the main reason why many of these upgrades of my old software occured was needing word, and email integration.

Albert D. Kallal
Edmonton, Alberta Canada
Albert D. Kallal Send private email
Tuesday, August 23, 2005
There are some areas where command line tools are just unbeaten, esp. for automation and scripting.

When you have 1000 data files to read but your graphical tool can only load one at a time, you are lost. With the command line, you create a list of the data files and feed it with a little script to the command line tool - two steps to go for any number of files.

The power of the text tools is that you can pipe them together, using the output of one as the input of the next.

Additionally, you can simply use the command line tools out of your own applications, feeding them with input and parsing the output. Thus you can always add a graphical frontend for the command line tool when needed.

Last not least, even graphical executables can usually take command line parameters to build a hybrid.
Wednesday, August 24, 2005
Ahh. links2 / lynx rocks.  You can design in HTML for your data entry, and get some great UI in the bargain, all wrapped in CUI.
Michael Johnson Send private email
Wednesday, August 24, 2005
It depends on who the clients of the software are. In an enterprise Unix/Solaris setting, my experience has typically been producing applications which primarily work through the command line, so that developers and support people can use the application in batch mode, or with more flexibility, but still provide GUI capabilities for end-users who run X-servers (and are not interested in flexible parameters).

In my day-to-day, for the past few years I've only been working on the command line. My tools are text driven, vi/vim runs in a terminal just fine, and debuggers/profilers run great without having access to an X-server. About the only thing I use a GUI for is e-mail.

...but, things would be much harder if I worked on the Windows platform. The command prompt Windows provides is a completely different animal.
Andrey Butov Send private email
Wednesday, August 24, 2005
Of course, vi is not a high-volume data entry application, nor are command line utilities.

I'm asking about data entry applications, like a claims processing system for an insurance company, which would involve claims entry, payment processing, etc. with thousands of transactions.  Is anyone out there nixing the move to GUI and developing NEW applications in character-based screens?
Rex Gozar Send private email
Thursday, August 25, 2005
My company's been in business for 30+ years, and our application has historically been Text-based, green-screen.  About 6 years ago we started migrating over to a GUI front-end.  Our existing customers are the biggest road block in migrating the "heavy-use" apps to GUI.  The biggest problem seems to be the staff and their ingnorance (fear) of anything new.
Interestingly, one of those apps that we have resistance on is our claims-entry process.  Our text-based app can be run heads-down, just using the number pad.  This allows for very high output from the processors.  The thought of having to use a mouse to change tabs, or even using <tab> instead of <enter> to move from field to field is their biggest concern.  Our task ( in SD ) is to create the app so that it is just as fast to enter claims in a GUI app as it is in a TUI app.  We're still trying to figure it out.
Ken Send private email
Friday, August 26, 2005
I do this in embedded devices all the time: create a little command shell & expose it via a command server listening on the telnet port. That gives me the ability to log in & run diags or get debug info. Even when designing little PC utilities, I will try to extract the core functionality into a library which can be called from a cmd-line interface or a GUI interface. cmd-line interfaces are useful if you need to automate tedious jobs using scripts.
John Foxx
Friday, August 26, 2005
Ken (above) knows his situation better than I do, but from his own description, it doesn’t sound like a case of irrational user fear/ignorance. Learning new things is a pain, so unless there are benefits, who wants to do it?

"Our task ( in SD ) is to create the app so that it is just as fast to enter claims in a GUI app as it is in a TUI app."

Sounds like the development team wanted the users to go through the trouble of learning a UI so they can migrate to an app that, in its initial form, makes their job *harder.* Is anyone surprised there’s resistance? Even if the new GUI matches the TUI’s performance, it’s still requiring users to learn something new without any benefit as far as they are concerned. If you want them to not grumble, that GUI has to be *better.*

My experience is consistent with Albert Kallal’s (farther above). GUI is not inherently better than character-based for form-style data entry. How does a GUI make data entry faster or more accurate? A mouse? How much help is that when your hands are always typing away on the keyboard? No wonder users rather hit a function key or whatever than use the mouse to get to the next page/tab. Resizable windows? What good is that for a form? Menus, accelerators, list boxes, and check boxes, pictured/masked fields? Character-based forms already have that. Proportional font? Big deal; we’re not reading a novel.

A TUI is not automatically better than a GUI for data entry, but going GUI is not going to automatically be as good or better. Whether TUI or GUI, a *well-designed* UI  that is optimized for the user’s tasks and goals is going to be better than one that’s not-so-well-designed. Enter key instead of tab to advance to the next field for pure number-pad entry? I’m guessing there is an advantage to the user to keeping his left hand free, maybe just to keep a finger on where they are in the hardcopy they’re punching in (watch them do data entry and find out). Now, *that’s* a well-designed UI. I don’t see any reason why we GUI-makers can’t make design choices like that too using all the capabilities a GUI offers.
Michael Zuschlag
Friday, August 26, 2005
I'm kind of disappointed in that I still don't have a clear idea of what people are using (CUI vs. GUI) in their enterprise workplace.  Maybe I haven't been asking the right question.

If your company uses software for operations and accounting, is it character or GUI based?  I'm not really asking what software houses are building, but rather what are your end users really using now?
Rex Gozar Send private email
Tuesday, September 13, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz