Slashdot Mirror
Developing Attractive non-GUI Apps for Unix?
Lysol asks: "Many years ago I wrote a POS (Point of Sale System) in a language (that's amazingly still around) called PowerBasic. One thing I really liked about it was the ability to do inline assembly and compile to machine code, which was a very big deal for DOS-based Basic code. For my POS app I used many text graphic libraries that gave me a poor-mans GUI for DOS. Now I'm going back to school and I need to brush up on my C, and that got me thinking about developing it in Linux. When I deployed this system it ran on old 386 machines. A lot of newer systems run on expensive hardware and it would be cool to provide a free GPL POS on Linux that can function as aterminal/text based solution. If you've ever used a cash register, sometimes GUI stuff with a mouse is not the best...especially for end users." One only has to look at FreshMeat to find examples of text UI libraries (and I'm sure that list isn't a complete one), but which ones have you used that you found enjoyable to develop in? How easy would it be to develop a text-mode application that has a UI that is just as capable as any GUI?
"I first want to deploy it using a terminal interface instead of a GUI interface for the simple reason that there will be times when it's better to run thin machines without installing X11, and it might be easier to implement rather than jumping right into GTK or some X11 widget toolkit. So does anyone know of any character based UI libraries that are available for C?"
http://www.vex.net/parnassus/apyllo.py/808292924.
Yes, I know, you're a C programmer... but (a) this might be useful to someone, and (b) you should really consider using python, at least for your prototype -- it's much, much faster to develop with.
Just write the thing in Elisp. We already have mailreaders, mp3 players, Intercal development environments, and a web browser -- just glue the appropriate parts together and move on with life! Plus, if your users get too frustrated, just set some keybinds to locate `doctor' when they hit F1:
Dewey, what part of this looks like authorities should be involved?
Take your pick: GPL or BSD Licensed. :-)
The Doctor What (KF6VNC)
...but add my voice to the chorus cheering for curses. It's free, it's incredibly easy to understand, and support for it is never going away.
The O'Reilly minibook Programming with curses (which I used to think was a "Unix-Hater's Handbook"-style thing) is a great place to start. Good luck.
spawn_of_yog_sothoth
And that the "user interface" is little pictures of food you touch to select?
The moral is that the dumber the interface, the better. Even using a mouse is a learned skill that cashiers might or might not have learned. And using the tab key to cycle between options? Forget it!
Pushing simple buttons is the only answer. If you can't work with a touch-screen, the old reliable Function Keys are your next best bet and seem very popular in POS systems. Of course, don't forget to paint them different colors, and have them custom-covered with key labels like "New Customer", "Visa", or whatever...
To all intents and purposes, you have to design a POS system as if the user had never SEEN a computer, let alone learned anything about them. Fortunately, text-based displays work well with push-button input systems, but before you worry about what your going to draw on the screen, figure out how the brain-addled user is going to tell the system what to do.
paul
Silly Rabbit, sigs are for kids.
You sissies and your monitors...why don't you program like real men, using flashing LEDs to let you know what's going on.
Ahh, you too have no idea how coddled and pampered you really are. When I learned to code, LEDs weren't yet in widespread use, and all of the computers used HEDs (heat emitting diodes) for status displays. The only way to tell if a bit was set was to touch a HED and see if your fingers got burned. It was no fun at all coming off of an all-night hacking binge with my fingers covered in tiny pinpoint-sized burns from a particularly gruelling debugging session, only to go to work for twelve hours manufacturing watch springs in a dangerous sweatshop just so I could afford the computer time and a bit of coal to fuel young Timmy's iron lung.
I'm just glad I wasn't there the night that some fool decided to mess around with the system clock multiplier, causing all the HEDs to set fire to the console, burning down not only the data center but also two adjacent nursing homes and a Salvation Army warehouse used to store surplus 72oz cans of bean w/bacon soup.
Reservoir Zigs
Ah, none other than the Jamie Zawinski (of netscape/Mozilla/Lucid Emacs fame) has been working on this particular problem.
m l
Check out:
http://www.dnalounge.com/backstage/log/2001/02.ht
Where Jamie provides a pointer to:
http://www.linuxcanada.com/linuxpos.html
He also took a swipe at hacking up his own Linux based POS system:
http://www.dnalounge.com/backstage/src/pos/
- Any Day above Ground is a good Day (Michael Rich, 1997)
Along the same lines, I have been thinking for a while about a single simple API with multiple backends so you can write an app once and it will either target curses, gtk+, qt, win32 etc.
Obviously I'm talking about seriously simple GUIs here with nothing much more than a few input fields and some validation. No cross-widget realtime updating or drag & drop etc.
Maybe it wouldn't be much use to most ppl, but these are often the kind of simple apps I find myself writing. I think configuration tools would be a good example that could gain from this. (also, I have just thought, how about a HTML backend !?)
I guess my point is that people seem to be choosing ever growing widget sets and committing themselves to an API which is often way more complex than they need. If some ultra-simple, multi-targetted API was available people might run your app in future in ways you didn't possibly imagine.
Maybe I'll start designing it myself some time soon....
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
PicoGUI is a GUI for embedded systems I've been working on for a while. It's video library is pretty flexible, so much so that it can render to ncurses! This means that PicoGUI apps can run in text mode almost the same as they would run in a graphical mode. The advantages would be a capable GUI that's in active development, and an easy upgrade path to a graphical system. Oh, and it's client-server if that helps. PicoGUI has client libraries for C and Perl, and more languages will be coming.
Some disadvantages though... Currently the keyboard tabbing isn't fully functional, and mouse input probably isn't applicable here, so you might have to do some funky coding to move the focus from field to field, etc. Also, it's a relatively new GUI so it might be missing features here and there.
-- 2 + 2 = 5, for very large values of 2
Think of how nice it would be for them to be able to update their apps to something more modern, running on a Linux server which is far more interoperable than a Netware server. Cuz yes, while they might want to cut costs with their computers, it might make sense to have the *server* networked with some central location and sharing information with them.
With this sort of situation in mind, they can keep their old terminals, and either boot with DOS, launch a TCP/IP stack and telnet application, and connect to the server, running console applications from there (remember dumb terminals?), or maybe, if the computers are fast enough (small 386's will do), do a diskless linux boot from the server and have a much neater and less archaic solution.
However, the question arises, if all is working well under the current Novell setup, why change? well, the answer is: it's getting harder to find someone who knows Novell, and easier to find someone who knows Linux. AND yes, after all those years, the Novell boxes are starting to crap out.
off the top of my head, i can think of two companies I know which could (or do) benefit from having a way to develop a modern app in text-mode. One of them is a freight company which has a centralized system on a DEC Alpha server and has all the branch offices connect via frame relay. Had they needed to upgrade the 386 terminals in the branch offices, it would have meant they couldnt afford to link all the offices together. And i can tell you those 386's WONT run any graphical environment but work in textmode just fine.
The other is a hardware shop with at least 4 locations, running Novell based setups and requiring constant attention because the Novell servers are crapping out, and Novell admins are scarce in that town. A Linux text-based solution would be interesting, because they can more easily find Linux people, plus, at least in my experience, Linux is more stable; i've had Linux servers working without flaws for so long, when they actually needed me to go down there, i'd forgotten how to get there :)
I'll stop ranting now. :)
blessings,
"Only in their dreams can men truly be free 'twas always thus, and always thus will be."
--Tom Schulman
OH!!! I all this time I thought people were calling me up trying to sell me a Piece Of Shit!
Ok my karma is maxed out. When do I become Enlightened?
I just wrote up a comment stating basically the same as this just mintues before reading this post. I believe an XML defined windowing system would be great! It could be cross-platform allowing UNIX and Windows (and other OS's!) apps to run on each others machines. (over the network even!) I also like how it could be converted to HTML pretty easily, I don't know if you want to go as far as using it for text based stuff, but why not eh? I believe we could also solve the piping problem that we have with current windowed apps using this!
Development time is no issue... it is quicker to design a GUI using a guibuilder than it is to code something in curses.
The time-consuming part of GUI development is never the amount of time it takes to make the computer draw the pretty pictures you want it to draw. The difficult part is deciding how the information should be laid out on the screen, and how the user is going to interact with that information.
There are a few reasons that GUI apps often turn out to be so incredibly shitty for data entry or certain POS tasks, and none of them have anything to do with the GUI. First, they're often written by dumb-asses who believe that the difficult part of creating a GUI is is going clickity-click in the visual builder window. Second, they're often written by people who confuse ease-of-learning with ease-of-use, and no desire to learn the factors that go into ease-of-use for a data entry system.
I have no idea why you'd imagine a GUI system would be any harder or easier to write than a TUI system, when the difficult part has nothing at all to do with actually slapping up the code to do the TUI or GUI part.
Slashdot is jumping the shark. I'm just driving the boat.
How easy would it be to develop a text-mode application that has a UI that is just as capable as any GUI?
Quite easy actually. I've been doing a lot of ncurses programming lately. You can do some amazinly elaborate things with it if your a good programmer. A good technique really pays. If you start running into situations where you're brute-forcing it, I advise that you back off and do a little work on a good "framework" for your app(that's one minus about ncurses, there's very little "flamework").
Some key points about ncurses:
o It's very fast - Text mode applications are great for productivity. Their GUI counterparts always turn out to be slower for some reason. ...etc.
o Menus and Forms - The menu and form libraries are standard on UNIXes. You can fairly easily create fields for data entry that have built in validation routines
o Tables - Well, not exactly, but a clever way to make a very snappy table is to just use a menu. In text mode you can't tell the differnce. Ncurses menu-tables are more than what the Java 1.1 AWT library provides
o Well established - Curses programming has been around for a long time. The characteristics of many terminal types has been worked out(by ESR) and abstracted into the terminfo database. Its quite portable.
o Works Anywhere - You can run it over telnet, ssh, or just dump bulky X alltogether and run on the Linux console.
Here's some links:
Ncurses Intro by Eric S. Raymond and Zeyd M. Ben-Halim
Linux Journal Artical by ESR
Fujitsu ETI Programmers Guide
SCO ETI Programming
I really wish people would concentrate more ncurses programs. They're just damn efficient. Anyone who uses mutt and slrn and such knows what I'm talking about. If you're really clever, you'll librarify whatever it is that your working on so you can hook on a GUI version later after you've tweeked the behavior of the app without wasting a lot of clock-cycles on graphics programming.
I've used S-Lang considerably in the past on projects which needed a TUI. It was intuitive and had a very slight learning curve.
Check out http://www.s-lang.org/
But POS systems are fairly specialist. By removing excess graphics you can allow the end user to view the information they *need* in a clearly presented form. Anti-aliased fonts would be nice because higher resolution fonts can be more clear. Animated gifs don't really add any value though :-)
From an intranet development point of view, people like w.i.m.p.-driven interfaces as they're easy to learn but if they have to use them every day (possibly unlikely in a pure web field) they start asking for keyboard shortcuts because they're quicker...
If you watch a user on a unix-telnet system (like one used at a mobile phone company I worked for) you see them struggle to learn to 'archane' keyboard commands but once they have the experience they can switch between screens and get things done with almost amazing speed. The moment they we're 'upgraded' to a windows based system, they had to learn again.
The users never reach the levels of speed previously attainable because physically moving the mouse to the neccessary command buttons takes longer than, say, the time to move between keys on a keyboard.
Despite all this, I've still got to concede that 90%+ of all users, if given a demo of two new systems, will say they 'prefer' the graphical one over the text-based one. Talk about expensive window-dressing!
Most volume data entry people use only one application all day long, and a GUI does nothing to improve their productivity.
Ternimal/Console based applications are alive and well in the data entry arena, and until a GUI can improve (instead of decrease) productivity test based interfaces will be the platform of choice for volume data entry.