Prev: Processing array subsections, a newbie question.
Next: Ada related perl scripts update
From: Georg Bauhaus on 14 Jun 2010 11:59

> What about an operator continuing repeating the same sequence of actions
> ignoring popping up message dialogs crying that it FAILED.

(See below)

The idea is that as an application interface designer, you provide
a GAI, not a GUI. That is, a Graphical Application Interface that
is somewhat like a scripting interface.

This obliges the GAI (sic) programmer to provide rock
solid GAIs that can not mess things up yet will provide all
possibilities to operators with suitable knowledge.
No damage, many degrees of freedom.

> Record the time between window creation and the cancel button press. If the
> delay is too short, give another warning. After tree warnings the operator
> receives one point. Three points are mailed to his superior. (:-))

Credit point systems won't work here, though repeated pop ups
could create more work heat throughout the organization.
Case in question: an operator sees a dialog window and has a healthy
attitude towards dialog windows. That is, he/she presses ENTER after
ignoring both any text and, quite naturally, the consequences
of dismissing the dialog which is actually a rescue dialog. Using a
big red button instead of a standard gray OK did not change behavior.
(Some handbags are red, too, after all...)

The dialog said, in attempt to get the operator's attention,

"If you press ENTER, you will get fired!"

Guess what?
This message has no effect on the operators' attitude
towards dialog windows. The dialogs look exactly like
at home where they get in the way (and out of the way!)
without noticeable consequence. Like blowflies on the screen.

He/she won't get fired, either.

Reasons:
- Firing requires work in superior organizational units,
and recruiting efforts.
- There isn't a massive threat from the insurance company
in case of not so massive consequences of dialog dismissal.
- Effects on others (clients, passengers, ...) overall are such
that they do not affect superiors' standing, hence provide
no incentive to request effort and/or money for a solution.

Therefore, occasional itching (error dialogs) can be safely
ignored.

Solution?
Ignorance is not so easily employed when there is nothing to
ignore! Therefore, a strategy might be to disable all
interface functions after dialog dismissal and require attention:
Print in bold letters:

"You Lose!"

This creates ... panic, cynicism, lies?

But! There is attention, at last!
And ... a need for work, making phone calls, experts sent for etc.
Work that nobody wanted to know about in the first place,
right? :-)

From: Dmitry A. Kazakov on 14 Jun 2010 12:44
On Mon, 14 Jun 2010 17:59:49 +0200, Georg Bauhaus wrote:

>> Record the time between window creation and the cancel button press. If the
>> delay is too short, give another warning. After tree warnings the operator
>> receives one point. Three points are mailed to his superior. (:-))
>
> Credit point systems won't work here, though repeated pop ups
> could create more work heat throughout the organization.
> Case in question: an operator sees a dialog window and has a healthy
> attitude towards dialog windows. That is, he/she presses ENTER after
> ignoring both any text and, quite naturally, the consequences
> of dismissing the dialog which is actually a rescue dialog. Using a
> big red button instead of a standard gray OK did not change behavior.
> (Some handbags are red, too, after all...)
>
> The dialog said, in attempt to get the operator's attention,
>
> "If you press ENTER, you will get fired!"
>
> Guess what?
> This message has no effect on the operators' attitude
> towards dialog windows. The dialogs look exactly like
> at home where they get in the way (and out of the way!)
> without noticeable consequence. Like blowflies on the screen.
>
> He/she won't get fired, either.
>
> Reasons:
> - Firing requires work in superior organizational units,
> and recruiting efforts.
> - There isn't a massive threat from the insurance company
> in case of not so massive consequences of dialog dismissal.
> - Effects on others (clients, passengers, ...) overall are such
> that they do not affect superiors' standing, hence provide
> no incentive to request effort and/or money for a solution.
>
> Therefore, occasional itching (error dialogs) can be safely
> ignored.
>
> Solution?
> Ignorance is not so easily employed when there is nothing to
> ignore! Therefore, a strategy might be to disable all
> interface functions after dialog dismissal and require attention:
> Print in bold letters:
>
> "You Lose!"
>
> This creates ... panic, cynicism, lies?
>
> But! There is attention, at last!
> And ... a need for work, making phone calls, experts sent for etc.
> Work that nobody wanted to know about in the first place,
> right? :-)

Well, seriously speaking, the rule is, never show anything that does not
require a choice (operation's interference). Warning dialog does not offer
any choice, down with it.

As for recording operator's actions, it is not just a joke. For example a
forklift truck control system we designed can log some driver's actions.
Drivers are identified when they turn the truck on. So the manager can
study the driving style of the workers when trucks get damaged or costs
raise. If the trade union leaned that... (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Warren on 14 Jun 2010 16:34
Georg Bauhaus expounded in news:4c1606e8$0$7666$9b4e6d93(a)newsspool1.arcor-
online.net:

>> May be this is getting off-topic a little...But I think there is a place
>> for both?
>
> The place that integrates GUI and command line operation is called
> Plan 9 (by Bell Labs). ...
>
> http://cm.bell-labs.com/plan9/

Do you know if it boots in VirtualBox yet? The
last time I tried, it hanged coming up.

Warren
From: Stephen Leake on 15 Jun 2010 02:48
Ludovic Brenta <ludovic(a)ludovic-brenta.org> writes:

> Nasser M. Abbasi wrote on comp.lang.ada:
>> On 6/14/2010 1:03 AM, Ludovic Brenta wrote:
>>
>>> I prefer command-line tools over GUI tools, so when I write a utility
>>> for my own use, I never give it a GUI.
>>
>> May be this is getting off-topic a little...But I think there is a place
>> for both?
> [...]
>> I think these days, in the web era, langauges with little GUI support
>> build into them can cause these language not to become popular. [...]
>
> ..
>
> PS. For file management, I rely on the command line and emacs dired.

Emacs dired is a GUI. It's implemented using the most modern GUI toolkit
available at the time it was first implemented. It's been updated a few
times, to take advantage of fonts and color.

"GUI" means "Graphical User Interface". That means something that uses
spatial relations in a display. It does _not_ mean overlapped windows,
bit-mapped displays, or rodents.

--
-- Stephe
From: Randy Brukardt on 28 Jun 2010 22:51
"zeta_no" <olivier_henley(a)hotmail.com> wrote in message
news:472c5f8a-111f-429f-acf5-b50b76079241(a)3g2000vbg.googlegroups.com...
....
> Sorry, I know Ada is about content and the image it radiates,
> esthetically, maybe the least of your concern (I don't point you
> directly Ludovic) but the web site of ADAIC is a time machine to
> ~1993. I came across that site often and I left it as many times
> because I though this was an obsolete site!
>
> Seriously, it needs refreshing!

For what it's worth, it's been redesigned several times, but to date none
seemed to be enough of an improvement in order to actually do the work. (New
pages have a simplified design without the frame so it doesn't waste so much
screen real-estate. That didn't get a go-ahead, either.)

Yet another refresh is in progress, supposedly will be ready for launch
"soon". No idea when "soon" really will be.

Randy Brukardt, "soon" to be former AdaIC webmaster.



First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Processing array subsections, a newbie question.
Next: Ada related perl scripts update