Re: Interfaces

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



You know, the fact about needing to remember how you get somewhere is interesting to me. I could “see” that as a mouse user, having to remember visual interfaces and where to click when could get confusing. Perhaps we blind people have our own little command line, even in visual interfaces. We use the keyboard only, so we tab around interfaces, or do keyboard commands to activate something quickly. Although, yes, if an interface is big and clunky, we do have to tab around a lot to get to where we need to go. But usually, it’s not that bad; we can usually use a keyboard command to do much of anything on interfaces, making a new message, opening a window, saving a file, renaming a file, all that.

On Jun 8, 2020, at 2:13 PM, George N. White III <gnwiii@xxxxxxxxx> wrote:

On Mon, 8 Jun 2020 at 13:59, Beartooth <Beartooth@xxxxxxxxxxx> wrote:
        In another thread, Bob Marcan wrote:

> Seems almost nobody is using the command line.
> GUI for everything.
> I like to see how will they solve the repetitive task.

        Well, what follows seems typical enough to be of possible interest.

        I've been around long enough to know only too well that the CLI is
preferable when feasible. The problem is remembering the commands, to the
point where your fingers know them. I began with a prodigious memory, and
ran it flat out for decades; so now in old age it's way full.

        But visual spatial memory, fortunately, seems to occupy a
different register. It's slower and less sharp. To answer what I has
clicked on, I was not able to rattle off a list, but had to go back and
reconstruct it -- including recovering a couple times from errors. But I
got there. The first false fork with the CLI'd've lost me.

As an undergraduate, I could get a timesharing account.  It used
a teletype terminal and you could (with luck) save your code to
paper tape.  In grad school I had access to an IBM mainframe
and a keypunch machine.   With those systems it was really
important to read and understand the manuals and put a lot
of care into every line of code.  You also had to be frugal with
resources, so it was important to understand how memory and
mass storage were configured.

Today, youngsters learn that computers allow you to try things and
nothing really bad happens when you get it wrong, so we have
moved from engineered to experimental workflows.  The latter,
however, seem somehow tangled up with GUI's ("What does that
button do?").   I have found it hard to get students in a
command-line workshop to try experiments like creating a file,
storing it in a tar archive, deleting it, and restoring from the
archive.

How is it that "a picture is worth a thousand words" yet current
GUI's hide important details.   For years we had folders that all
looked the same even when they reside on very different filesystems. 
Why do icons for disks often look like trashcans?  At least Gnome
now uses a file cabinet icon for Files app, but it could be animated
to convey some information about the status, such as starting to
bulge when it is over 80% full, falling over when the disk's S.M.A.R.T.
status indicates a failure, etc.

I find that many younger biologists who delve into remote sensing
or GIS, both often stretch the capabilities of the average PC,
are vague on the difference between RAM and mass storage,
so after seeing a device full error will ask if they can have the
RAM upgraded.  My Prius can display a simple diagram showing
when energy is flowing into the battery, etc.  Why don't GUI's have
similar diagrams for CPU load, storage space, and RAM usage?

--
George N. White III

_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx

_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux