From: Bob Proulx <bob@proulx.com>
To: help-gnu-emacs@gnu.org
Subject: OT: User Interfaces (was: Feeling lost without tabs)
Date: Sun, 3 Aug 2014 19:20:21 -0600 [thread overview]
Message-ID: <20140803183156281503782@bob.proulx.com> (raw)
In-Reply-To: <87zjg1njav.fsf@debian.uxu>
Emanuel Berg wrote:
> Bob Proulx writes:
> > Yes. But at some point the brain can become
> > overloaded. I have some ham radios that have had
> > feature creep to the point that they are no longer
> > possible to be operated without the manual open
> > beside them. That is bad. Was it left function,
> > right function, then action button? Or was it push
> > and hold left function 1s until beep, then action
> > button? Or right function hold 1s, left function,
> > then action? I have truly awful "computerized" radio
> > like that. Others with less features are more usable
> > because sometimes you don't have the manual in front
> > of you.
>
> Fatigue is of course a big source of such
> "biomechanical" mistakes. At that point you should
> probably have a break. At the same time if you have too
> much material in your brain you might think fumbling
> and stumbling is OK just so the thing gets done, then
> the break will be all the more enjoyable as you can
> feel good and let all that dissappear completely.
Taking a break is all well and good. But if the interface was your
car and driving it caused that level of fatigue then it would be
counter productive. Operating a vehicle shouldn't be so stressful as
to be dangerous. For example we know that to stop you press on the
brake pedal. Pressing the brake pedal stops the car. This is easily
learned and doesn't cause fatigue. And it needs to be easy.
If a childs ball bounces out into the street every driver should be
ready to step on the brake. Because very frequently a child may soon
be chasing after that ball and running into the street after it. Be
ready to stop suddenly!
Conversely in a bad user interface example if the brake pedal was
multi functioned and one needed to set the right mode of operation
that would be bad. Let's say it needed a mode switch. One mode
caused the pedal to accelerate and another caused it to brake. And
worse it might not be obvious which is which. That would be a very
bad thing. It might require an open user manual to operate. It would
be dangerous if you could not stop immediately if required.
The Emacs interface is close to this problem. There is only a limited
number of keys for direct commands. After that we have all of the C-x
key map. Then the C-c key map for some modes. And so forth.
Commands that we execute all of the time are easily remembered. But
commands that we don't do very often are harder to remember. But C-g
is always immediately available to interrupt the current action. :-)
> > https://en.wikipedia.org/wiki/HOTAS
>
> So is there something we text-editor users can learn
> from the pilots?
In my mind, yes. Keep the fingers on the home row of keys. Make
commands easily executed while keeping the hands in the standard
typing position. Needing to move the hands from the standard typing
position causes a higher operator workload.
> > Because the keyboard is a general purpose interface for
> > human text it doesn't really make a good match to an
> > airplane cockpit. Meaning that it will be more
> > complicated because there is a mapping from one to
> > another. The keys are binary. Most flight controls
> > are analog.
>
> The stick and throttle are, I take it the movements are
> recoded digitally at some point?
In the general aviation planes I fly the controls are connected to
steel cables connected to the flight control surfaces directly. I
push and pull them directly. It is always analog.
In today's fighters and most new airlines everything is computer
controlled. Fly by wire. You provide input and the computer drives
the flight controls. It will be analog on both ends and digital in
between.
Sometimes this is good because the addition of the computer came make
things more efficient. Sometimes this is bad because there is no
"feel" to the controls. No feedback. For example in Flight 447 crash
the two pilots gave opposite input and the computer averaged their
inputs together which is clearly undesirable. The two pilots were
opposing each other and did not know it due to lack of feedback.
> What about the data that are read by the pilots? Are
> they typically analog or spelled out with letters and
> digits? I think I would prefer analog, more smooth and
> relaxed. In a text editor though I can't think of
> anything that could be purposely expressed the "analog"
> way?
The traditional instruments are analog. Usually called "steam
gauges." Most of the newer instruments are digital. The analog steam
gauge gives you a pie-chart type of display. The new digital gauges
with numbers give you a lot of data and require a different type of
learning to deal with what is what. It is a hotly debated topic as to
which is better.
> Interesting. This reminds my of an article I read in
> the magazine "High Score". There was a Formula 1 game,
> one of the first games for Windows 95, and for this
> reason it got some attention. The game was nothing out
> of the ordinary, I think. But anyway there was a
> profession race car guy they had testing the game. He
> said just like you the biggest difference was you get
> zero information from your body. He said he didn't have
> an advantage playing the game from being a professional
> race car driver.
Exactly.
> In another article in that magazine, but I think in
> another issue, they did the same with a sailboat
> simulator. They showed it to some Captain Haddock old
> fart and asked if you could learn anything from it, and
> he said absolutely not, you should do that in a real
> boat.
Haha. I both agree and disagree. To a point you need to learn the
rules first. Then you need to learn it for real. The simulator
allows you to learn without causing expensive damage or possibility of
hurting anyone. But you can reach the end of what you can learn from
the simulator and then you need to move on.
> Well of course... problem is, kids don't sit
> around boats all day as they do computers. If two kids
> were to learn it I absolutely think the kid with the
> experience from the simulator would have an advantage -
> he would know the terminology, how to process the
> instruments, he would have something to relate
> (compare) to, and his brain would just have a head
Simulators are great procedural trainers. A lot of what is done is
for repetitive learning. Do the tasks that you need to do again and
again and again so that they become reflex. Like practicing a musical
score on an instrument. Practice, practice, practice makes perfect.
For example the new moving map gps systems are quite complex. The
Garmin G1000 has 101 control inputs! Burning aviation fuel is
expensive. It is much better to sit on the ground in a simulator and
learn how to drive the electronics where it is free and you can always
step out and take a break than it is to do so while you are flying and
needing to concentrate on other things like not running into other
airplanes or the ground.
I see people who have a lot of experience flying flight simulators.
They are actually quite good flying under instrument conditions. For
getting their instrument rating they are definitely ahead. But the
sim isn't good at recreating a visual approach and landing. Even on
an instrument approach the GA pilot always lands visually. (Only the
big guys have zero-zero (visibility-ceiling) landing capability.) The
sim also isn't good at recreating a crosswind landing environment.
Trying to land a small airplane is just so different that they are
starting from the same starting place as someone who has never flown a
simulator. Even the new professional sims have enough delay to them
that I don't think they are good enough yet.
> start. Also, a simulator can run different
> scenarios. Don't pilots train in simulators all the
> time? Why shouldn't aspiring Haddocks do as well? All
> said and done, nothing beats the real deal...
Commercial airline pilots are always doing recurrent training. Much
of that is in really good simulators. An airline pilot might take a
checkride in a simulator. It is that real there. The first time they
fly for real they will have a full load of passengers. But they will
also have an experienced captain pilot next to them to ensure that
things go safely. It is the responsibility of the senior captain to
finish the training that was begun in the sim.
General aviation pilots do not have a senior captain. We only rarely
fly in sims. We have flight instructors that we fly with to teach and
polish. Or we might fly with other pilots. It is only required that
I have three takeoffs and landings in the last 90 days to carry
passengers. Longer than that and we are required to fly solo and
practice to get re-currant. And I need a flight review every two
years. Most pilots I know fly often and do their best to keep their
skills sharp. There is a saying, "A good pilot is always learning."
> Configuring Emacs all they long and having the shell
> tools and everything behave exactly as you like, and
> then do the same to the place you are in while doing
> it, tweaking everything, I think computing can be
> physically and even more so mentally enjoyable - and it
> is a huge difference from a busy office with crap
> software and stressed out people running all over the
> place - still, compared to what is instinctively and
> immediately a joy for almost anyone who ever does it -
> I'm not an aviator but to some degree I can imagine - I
> don't think it will ever come to that... Mission
> Impossible.
Both computers and flying is fun. But they are different types of fun.
This is getting really off topic so this will probably be my last
comment on this but... I just got back from the EAA AirVenture Fly-In
in Oshkosh. It is aviation heaven. Search for it if you are
interested. 10,000-15,000 airplanes fly in for the convention. I
flew in with my taildragger. Then among other things I volunteered
and helped to park arrivals. An aweome experience! It is impossible
to describe to the non-enthusiast. Fun! :-)
Bob
next prev parent reply other threads:[~2014-08-04 1:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.5726.1405828965.1147.help-gnu-emacs@gnu.org>
2014-07-20 14:19 ` Feeling lost without tabs Dan Espen
2014-07-20 18:11 ` Bob Proulx
2014-07-20 18:34 ` Emanuel Berg
[not found] ` <mailman.5777.1405879906.1147.help-gnu-emacs@gnu.org>
2014-07-20 21:44 ` Emanuel Berg
2014-07-21 17:02 ` Bob Proulx
2014-07-20 23:52 ` Dan Espen
2014-07-21 22:54 ` Emanuel Berg
2014-07-21 23:33 ` Bob Proulx
2014-07-22 2:44 ` Dan Espen
2014-07-22 21:23 ` Emanuel Berg
[not found] ` <mailman.5833.1405985639.1147.help-gnu-emacs@gnu.org>
2014-07-22 22:02 ` Emanuel Berg
2014-08-04 1:20 ` Bob Proulx [this message]
[not found] ` <mailman.6530.1407115234.1147.help-gnu-emacs@gnu.org>
2014-08-04 22:10 ` OT: User Interfaces (was: Feeling lost without tabs) Emanuel Berg
2014-07-20 18:28 ` Feeling lost without tabs Emanuel Berg
2015-11-03 14:07 ` swe20144
2015-11-03 14:21 ` Dan Espen
2015-11-03 15:22 ` Yuri Khan
2015-11-03 15:46 ` Dirk-Jan C. Binnema
2015-11-03 17:31 ` Michael Heerdegen
2015-11-03 17:47 ` Charles Philip Chan
2015-11-03 21:24 ` Michael Heerdegen
2015-11-03 15:37 ` Filipp Gunbin
2015-11-03 16:25 ` editing, searching minibuffer content [was: Feeling lost without tabs] Drew Adams
2015-11-03 15:53 ` Feeling lost without tabs Aziz Yemloul
2015-11-03 15:56 ` Charles Philip Chan
2015-11-03 20:07 ` Bob Proulx
2015-11-03 23:48 ` Kendall Shaw
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140803183156281503782@bob.proulx.com \
--to=bob@proulx.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.