How is Google front page different from a shell prompt?

It’s not expecting proper syntax and arguments, and there is a button with the text “search” on it, so it gives you an idea of what it does.

It works around the same principles – you type something in, the machine parses it and things happen.

By taking a common denominator (at the very least, the laws of physics), you can find that anything works around similar principles as anything else, but it doesn’t make them equal as even what appears to be details can make a huge difference. Our DNA differs only by less than 2% with a chimp’s DNA, but we can build skyscrapers and walk on the moon.

And it’s not just search – Google has a lot of other functionality built into their site – calculator, currency checker, maps, etc.. Google UI is considered super user-friendly, while shell is scary. Why is that?

A simple answer would be because it tries to fit the user, and not have the user fit it. In other words, people really just want to search, so Google tries to make results more relevant and starts interpreting the input.
Somebody with bad spelling wanting to convert euros to dollars will type “convirt cetimenters in inces” and the result page will show a unit converter.

Taking a poorly designed GUI (the one shipped with msysgit) as an example does not win any argument. You could find a command line tool with no man and no –help, and you would end up doing even less than with the aforementioned GUI.
It takes more work and skill to come up with a good GUI than to come up with a usable CLI, but if done in a smart way, the GUI can trash the CLI in productivity and training requirements. So one could make the case that a CLI is only useful for when there is no good GUI (and for scripting, of course).
Now if I had to come up with an example, I could stay in the DVCS world, and start arguing about how it’s more convenient to work with TortoiseHg Workbench than with the already quite good Mercurial CLI…

@ Victoria:
Try TextWrangler; that’s what I used before I learned Vim, and it is a wonderful text editor with a good GUI and a good command-line interface, which is capable of editing big files and doing search and replace very well.

MrJones2015 wrote:

@ StDoodle:
Offering multiple ways to do the same thing has nothing to do with usability.

I would disagree; the SUM-explaining site linked in the article you refer to mentions three main aspects to usability: “… completion rates and errors (effectiveness), task-times (efficiency) and task-level satisfaction (satisfaction).”

Being able to do user-input in the way that works best for me seems helpful for all three.

Now, I’ll grant a few things. First, I know that’s not the be-all / end-all to usability, but I do feel it contributes. Second, there are likely some technical definitions to the “usability testing” world that further limit the aspect of the “multiple input” path, but all I can say is I’ve used several CAD programs (and done hand-drafting), and I feel that at least for me and other CAD-monkeys I’ve discussed this with, being able to customize your UI has at least felt like it made it easier to do our jobs, and made them seem less arduous.

Welcome to the gadfly table!

I added your link to the bottom under updates.

I love the power unix command line gives me. When I start my computer after 15 seconds text based login screen shows up. I log in and my system trows me in busybox ash. I love it and I only really start X when I use QEMU to test my OS. I have around twenty shell scripts in my ~/bin along with my toybox utilities. Everything is fast and lightweight. I can just type ed somefile and it starts under a second. Also the power of posix compliant shell is amazing. I have written package manager, text editor and gopher browser in shell scripts. I still have to say that it is not very luser friendly. It is powerfull and easy to write programs to but takes some learning.
PS: Posting from my phone because acute lack of javascript enabled browsers that run on sane speeds on my computer (700MHz Pentium III, 64MB of RAM, 30GB HD)

@ Alec Benzer & @ Michael Chui:

This is a very, very good point. A small “command” box along with a key binding would make working with a lot of these “office” applications so much easier. It would also make writing manuals an instructions easier (type this in, vs go here, find a button that looks like this, flip the toggle, check the box, etc..).

Seriously, someone should fork Open Office and create a command box that would let you do stuff like:

– document lanscape
– page current columns=2

Etc..

@ Roee:

Yes, but at the cost of flexibility. In the shell you can pipe I/O between apps, use wild cards, and etc… In GUI, not so much. Also, “search type GUI” is still relatively uncommon. Traditional GUI with a million buttons and hidden panels is still the “default” – mostly because it is easy to put together, whereas good search-box that does not suck takes effort and finesse.

@ Allen:

Very good points. Though I would argue that the Github thing is not really a GUI vs. CLI example, but a workflow example. Or rather an example where work does not “flow” so to say by enforcing a context switch.

Usually when you get a pull request you see it in your mail, or as a notification when you log into the site. At that point you are in your browser and you have your hand on the mouse. It is only logical to have a button there that would perform a common action – you stay in the browser and all is well. The alternative, as you say is to open a terminal, navigate to your project and type in a command which breaks the flow and forces you to switch context. Then you have to go back to the browser to continue reviewing other stuff.

@ Victoria:

Mac terminal has tab completion to aid you in typing long paths. You can type in a few letters of the folder and hit tab to expand it. I don’t think the bash version on mac does this but a lot of Linux systems are configured to try to guess what command you are typing and tab-expand it for you too, or provide suggestions when you make a typo.

Oh, and here is something to fuel your nightmares.

In all seriousness though, I’m glad to hear my favorite text editor conquered a crazy database file when all other failed. Old school design from the age when bandwidth was measured in baud wins again. :)

@ StDoodle:

Never actually used AutoCAD but yeah – that sort of design is a good idea. Your comment reminded me of GNUPlot which is basically a visualization/graphing tool with a command line interface. Most people balk at this at first, but then you realize “oh, shit – I can script this thing and make my graph the same exact way every time”. :)

@ MrJones2015:
Just found this, definitely worth reading
http://www.evanyares.com/cad-usability-sucks-part-3-its-not-cad-its-yo u/

@ StDoodle:
Offering multiple ways to do the same thing has nothing to do with usability.

“As a user researcher with a primarily qualitative background, I have to confess that when I was asked to conduct a usability benchmark study on AutoCAD, I was not exactly jumping out of my chair.”
Source: http://dux.typepad.com/dux/2009/09/a-case-study-in-largeapplication-us ability-benchmarking.html

While there are many things I don’t like about Autodesk, the user interface for AutoCAD has always been one of the better examples, I think, of how a program can be set up. Even the 2013 version has improvements for the command line, and you can use all sorts of input methods from it cli to toolbars to pull-down menus to… gasp, even a ribbon. I would hazard a guess that the flexibility to use whichever method you prefer, or any mix, is no small part of how it become so ubiquitous.