Many great open source GIS tools are available for data manipulation and mapping projects. Many of these, however, only have command line interfaces (CLI) available. As such, there are a lot of folks for whom these tools are virtually inaccessible.
Oddly enough, every time I look for the "command prompt" in one operating system's START menu, I get the feeling it's hidden deep in the menus for a reason. Could it possibly be that some users are discouraged to even use a CLI when so many wonderful graphical user interface (GUI) tools are available? Okay, forgive my sarcasm, but it seems that we prefer to scan the screen looking for "event" driven controls rather than read about a list of commands that we can type in.
At risk of entering into the larger GUI vs CLI wars, I wonder about what approach to take when introducing new users to these great tools: create a GUI or help them stretch.
I think it goes without saying that GUI-addicted users find command line interaction as exciting as elevator music. Not only does the CLI of their particular operating system appear unfamiliar to them, the fact that it "just sits there" waiting for them also introduces a sort of dependency on the user - you must know what you need to type or nothing will happen. Their verdict, as discriminating as it may be, is that CLI is archaic and hard to understand because it doesn't pour forth speech in their mother (msgbox) tongue.
This is a whole area of advocacy that I haven't seen addressed: how to make that leap between user interaction paradigms without coming across as "Mr. IhateMouseClicks". I know that once they've seen the power of a few CLI sessions helping to solve their problems, they may be more interested in flexing some new muscles.
Of course, with Geographic Information System (GIS) applications comes the regular need for visualization and interaction, often through maps. So I can't discount everything graphical - nor am I trying to. But I've found that in many cases, the tools we have at our disposal better fit the CLI paradigm. That is they have a "Command
I'd like to hear how others have helped to bridge this gap, particularly between traditional Windows users and Unix-style applications. How do you bridge the gap between excellent command line interface-based tools and users who need them but who were raised on GUI bread? I'm interested in a female perspective too - maybe this problem is just a male thing (like not wanting to read the map when driving, preferring to just wander through the operating system waiting for buttons to appear).
I propose creating a non-profit society: CLI Advocacy. Its sole purpose would be to combat the "GUI is the only way league". Or perhaps it should be "CLI Users Anonymous" - after all I feel I'm more in need of a good support group than being involved in a direct attack.
Tyler
How do you bridge the gap between excellent command line interface-based tools and users who need them but who were raised on GUI bread?
Categories
Web
Read More Entries by Tyler Mitchell.
Become an O'Reilly Member
Visit the Digital Media Forums
Subscribe to the Digital Media Blog Feed
Subscribe to the Digital Media Newsletter
Dungeon and Dragon with CLI
I'm not sure if many of you remember those days where you would play the game of dungeon and dragon on the command-line like this.
>go south
** You are in a room with a door at the north end and a chest on the south wall.
Now if we could just do the same on a command line window in way that it is very simple.
>Send Message
>>To who:
>My Pal
>>huh?
> John Smith
etc...
Next time I can type:
>send message to my pal.
It'll know to bring up an email window to send a message to John Smith.
Now this is the killer app.
Re: Another RunRev user
I find it extremely sad Revolution is not open-source.
Not through a "let's open source the world" attitude.
But RunRev being closed source and proprietory stops many many people (students all over the world) - that can't afford even a Mac-Mini but are getting into Linux - from learning a great methodology.
I firmly believe RunRev has more to gain if the project were open-source than otherwise; it would attract much deserve interest, they still could charge for support / books / materials - it would be a gift for humanity.
But they rather confine the technology to a upper class niche of mostly Mac users. Nice one!
Unix Tools as Visual Programming Components
in a GUI-builder Environment
Here's an interesting, somewhat related paper:
"Unix Tools as Visual Programming Components in a GUI-builder Environment"
http://www.dmst.aueb.gr/dds/pubs/jrnl/2001-SPANDE-VUFC/html/vufc.html
Not that I understood it all, but he does some interesting stuff representing Unix text processing commands in an Active X object.
Tyler
Another RunRev user
I'm surprised more people have not seen the grace and flexibility of Revolution. It was one of my 5 key technologies.
Another Way to GUI
I had similar problems until LinuxFormat included Runtime Revolution 1.1 on their CD.
This has an event driven simple scripting language to a windowing interface, which can open, read and write to CLI processes, amongst many other things.
I do all processing in CLI scripts and files, then call them from RunRev windows, buttons, mouse clicks etc with a bit of RunRev scripting logic.
Then I build (compile) the RunRev windows into a freely distributable 2MB executable and stick it on the desk top or run several from a shell wrapper or another RunRev window set up as a menu.
No programming.
Yew Beauty.
Stomfi
Brisbane, Australia
People transitioned from CLIs...
Thanks for the memories kollivier! My first GIS course was in a similar setting, though maybe worse.
The GIS in Forestry course was the only one taught at the school, so us Geography majors had to expand our mind and hang out with foresters for a while.
It was an interested classroom dynamic, consisting of a lecture a week and then an applied lab. The lecture consisted of the lecturer writing text commands on the board - showing an example of how the program was used (it was ESRI's PC Arc/Info). Our task was to furiously write down every command (don't forget the spaces!) diligently into our lab manuals. If had to write fast since, in good university style, he'd be back to use the first blackboard again in a few minutes.
The lab consisted of typing in those commands into the computer. Quite a few good stories come to mind about "typos" (or more accurately described as "transcribos") totally ruining any chance of getting the lab done. I remember desperately searching for a manual, a tutorial guide, anything but my poorly transcribed notes! As trite as it may sound, the saving grace of the lab was always teamwork. At least 1 out of the 7 or 8 students in each lab got it right (or portions of it). So it was a good team-building exercise!
The application I'm talking about in this weblog is a bit artificial for some GIS users, since many who have had some formal training are more than familiar with command line "Arc/Info" GIS. In fact, it may be the only reason they ever heard of Unix (before NT4 came out there weren't too many stable desktop PC platforms for this app to run on).
The neat thing is that with the open source data conversion and mapping tools available, that kind of environment can now be mimicked. This can help to draw the user to interact with some more powerful tools while keeping the environment somewhat similar.
Thanks for the notes!
Tyler
Peanut Butter and Chocolate
I'm very much the same way, using remote access tools to get to my servers. I find it a lot faster, even on our LAN, to ssh in and run commands than using a graphical remote desktop client - even on Windows. Many balk at the sight of a CLI, but some balk at the absence of it. For example, when you find the program you need to use doesn't have any command line options. That's when I start to shout "conspiracy!"
Tyler
teaching GUIs and CLIs
I see what you mean. It only took a few support phone calls for me to realize that it can be much more difficult to describe how to interact with a GUI than with "language" commands.
Tyler
bash, ls, grep, less, and vi
I think the first step is teaching someone the basic commands: bash, ls, grep, less, and vi. Once they are comfortable with these and doing things like:
$ grep -ri box . | grep flex
their CLI adventure can begin.
Oh Kaptain, my Kaptain -
This is a nice idea but only works if you have the supporting kaptn file. What would be nice is if the kaptn file could be made from a man page or info page. This could give a default GUI descripton file to be used by a gui builder that might be HTML, Tk, etc. Then changes in the documentation are reflected in the gui.
Ex.
info --show-options-gui find | guibuilder
teaching GUIs and CLIs
What I do at the start of a new course that propagates the use of the CLI: first I try to convey to the students what I mean by handsignals only. Obviously they don't understand. Then I use plain language. Thus I demonstrate that complicated messages are easier to transmit when you use a language than using signals.
They soon get the message...
Paai
Easing the Transition
The web application PhpMyAdmin provides a GUI to the commands available in the mysql command line interface, but it also does something very nice, which is to show every SQL command that it executes. When I first started using it three years ago, I wasn't able to remember all the various SQL commands or the order they need to be in. Through enough usage, however, I became familiar enough with the commands that I could type them from memory. Now I'll use PhpMyAdmin half the time and the command line the other half.
Peanut Butter and Chocolate
I've found that a combination of command line and GUI works the best. There are many different Linux programs that take this approach, such as all of the different CD-Burning front-ends for cdrecord and mkisofs, then there's grip which is a great example of an easy-to-use tool that uses standard command-line apps behind the scenes.
Even with increased bandwidth, I still find myself more likely to stick with using command-line programs when I have to remotely connect to a machine and get work done, just because it's more responsive. Plus the value of pipes can't be ignored. But when it's time to rip a CD, it's grip all the way for me.
Perhaps what you should do is build the command-line version and then develop a GUI front-end for it.
Oh Kaptain, my Kaptain -
I was sure I'd seen tools before that generated GUIs for command line tools; I did a quick dig and found one, though not the one I remember (which was in TCL?):
http://kaptain.sourceforge.net/
I'm guessing this is for 'normal' command lines (so Kaptain can just exec() the call), but the apps you're using may be complicated by interacting with a different shell, like SQL*Plus for Oracle in days of yore. In emacs, writing a mode based on 'comint' allows you to Kaptain-like things interacting with a shell session rather than just exec commands, but I don't know if Kaptain goes this far.
People transitioned from CLIs...
I once was "tech support" for a GIS class with just such a CLI-based GIS program. (Can't remember the name, but it was made by OSU.) The professors swore by it, but students were frustrated by how easy it was to 'hit the wrong key' and confusion over commmands, sometimes with the result that they had to start over. IIRC, it wasn't highly tolerant of them making mistakes (nor was it simple to 'undo' them), and this is typical of CLI programs. I got called to peoples' computers a couple times to try and figure out "what happened", and typically it was that they did not follow instructions in the *exact* order they were asked to, generating erroneous maps or landing them in some other area of the program they were unfamiliar with. Needless to say, many students walked out of class frustrated with the program. Not to say that this couldn't happen with a GUI-based app, but CLI apps typically expect the user to "know what they're doing" and thus provide less guidance.
Experiences like this have led me to the conclusion that CLIs are for a specific group of people - those who need or prefer efficiency, power and flexibility over intuitiveness. In other words, people willing to put in some learning time so that they can get more work done faster. Often, though, this is not the case for beginners/new users. Beginners typically just want to get started as easily as possible - to get a feel for the technology and learn what is possible. Consider it taking the program for a test drive. Pitching a CLI to these people is like trying to pitch a stick shift to a first-time car buyer, who is nervous and is still trying to grasp basic concepts - it's just another thing they need to learn and worry about, and it doesn't matter to them which they use. They could care less about the most efficient paradigm - they just want to know how to *use* it, and the sooner the better.
People who I think *would* be open to CLIs are people who already know the basic tools, but need more power and efficiency than the GUI can provide. i.e. GIS professionals. These folks will probably take some time to learn the CLI tools, and will make good use of them. IMHO, as more people start using the computer for day-to-day work, interest in the CLI will increase, not decrease.
But I think trying to start GIS users off on the CLI is more likely to alienate beginners and make GIS look like this intimidating and complex thing that they don't want to be a part of. So maybe the best route, rather than trying to transition potentially un-interested users, is giving users a choice.