Linked by Thom Holwerda on Fri 8th Feb 2008 20:46 UTC, submitted by irbis
Graphics, User Interfaces "It's one of the more popular culture wars in the free software community: GUI versus CLI (graphics versus the command-line). Programmers, by selection, inclination, and long experience, understandably are attracted to textual interactions with the computer, but the text interface was imposed originally by technological limitations. The GUI was introduced as a reply to those problems, but has undergone very little evolution from 1973 (when it was invented at Xerox PARC) to today. So why can't we do better than either of these tired old systems?"
Thread beginning with comment 300448
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Two parts to the essay
by TemporalBeing on Mon 11th Feb 2008 15:28 UTC in reply to "RE[3]: Two parts to the essay"
TemporalBeing
Member since:
2007-08-22

I do it by typing pic_i[TAB][ENTER] on my machine; but the point here is, that you can not generally automate the WIMP software.


Actually you can - by using tools such as Tk and Tcl. DejuGNU (build on Tcl/Tk) does this quite well to produce fully automated GUI test suites to ensure GUI components work well.

I think the bigger issues comes down to that a lot of programmers don't like writing GUIs, so they avoid them - despite the fact that GUIs are a lot, lot friendlier to end-users.

You can do almost anything with a GUI. But 'plugging' different applications together through GUI components is a bit harder - but, as I said above - it can be done. You just have to adjust your toolkit appropriately, which may mean learning another programming language that can do the job (like it or not).

Reply Parent Bookmark Score: 1

RE[5]: Two parts to the essay
by marafaka on Tue 12th Feb 2008 07:17 in reply to "RE[4]: Two parts to the essay"
marafaka Member since:
2006-01-03

I do not believe into orthogonality of GUI and textual interfaces, because text is graphics and images convey meaning. I wish people would see over the implementation details and understand, that the goal is to mimic normal human conversation, not draw pixels or walk the rodent around the keyboard.

If 50 years ago textual interaction was limited to console with one-line edit buffer, it doesn't mean that the proponents of language interfaces still want to force fixed-width green-on-black ASCII characters down people's throats. We just want to at least retain the functionality we always had so we don't get lost as our clients are.

GUI applications are wrong because designer is forced to reinvent the interface for every single application, because the application is tied to the pretty picture you draw to the end-user, because you limit your application to a certain platform and the single way you physically access it, because your application becomes monolithic and because it becomes unautomatable.

What you mention about Tcl/Tk is nice, but the implementation is still wrong; I want to talk to the computer, not gesticulate to it.

Reply Parent Bookmark Score: 1

TemporalBeing Member since:
2007-08-22

I kinda agree, and I kinda don't. Let me try to explain...

Every program sets out to accomplish a given task. Some tasks are better for users via GUI and some via CLI. It doesn't mean that you can't implement them as either - just some are better suited one way or the other. As such, users will be able to use the program better when its UI is the one that is better for that task.

That said...I try to provide both kinds of interfaces for my programs. Why? Most users like GUIs better - it's more natural to them, so providing a GUI is good. However, at the same time CLIs are better for scripting and other tasks that admins and some (not all) developers like. So there's an audience in providing both. Providing both pushes the core of the tasks to library APIs, so you get better, more extensible code architecture/design too.

Some systems (e.g. IBM AS/400) do things the old Green-Screen way - for that you need to interface appropriately, and provide transitions appropriately. (Yes, I've done worth that way!)

Also - there is no reason to be tied to a single platform with a GUI any more. There are a number of toolkits out there (Gtk, WxWindows, Qt, KDE/Qt, SDL, etc.) that enable software to cross the platform barrier from a single code-base. Furthermore, it's very easy to do.

It doesn't help to stay stuck to CLIs, nor does it help to go overboard on GUIs. There's uses in both.

True, GUIs do provide more information as the graphics used have meaning to the user. However, as DejaGNU and other toolkits do provide - they can be automated.

I'm not going to say CLIs are the end-all-be-all. They aren't. And a GUI does not necessarily mean a big monolithic application - it doesn't.

A GUI will typically be a bigger application than a CLI as there is a lot of code for handling events from the GUI. However, ClIs are not that small either b/c they have to parser the I/O a lot more - and that is a lot harder to do than in a GUI, and often results in a lot of redundant programming too.

In either case there is a core functionality. You don't have to reprogram that core functionality every time you have a new program - that's what libraries are for - whether using shared, static, or convenience.

As the saying goes - there's more than one way to skin a cat. ;-)

Reply Parent Bookmark Score: 1