[jawsscripts] Re: A last-gasp attempt at this 3270 problem of mine
- From: "Travis Roth" <travis@xxxxxxxxxxxxxx>
- To: <jawsscripts@xxxxxxxxxxxxx>
- Date: Tue, 12 Jun 2012 07:51:53 -0500
Hi Steve,
Sounds like quite the project!
I cannot say I followed everything that was going on.
But I was wondering: if there are screens that are informational only,
instead of a hotkey for every piece of info, could you pull the data
together and then present it in a usable logical order in the JAWS viewer?
The newest JAWS viewrs even support HTML so I'd think you could make some
nice tables, and the JAWS user could use table reading commands?
As for sorting data, again, if you could pull all the data, then present the
data in the viewer based on the user request. You could either assign hot
keys, or easier for a user to remember: one hot key displays a list of
choices of which he can choose for the sort and then the corresponding data
is shown in the viewer.
I agree with you: to many hot keys is counter productive or sometimes
downright impossible. That's why I prefer to look for ways to use keystrokes
the user is already going to be familiar with such as table reading, and
ways to provide users choices e.g., via lists. See JAWS research-it dialog.
See Windows, and most any other GUI of the past decade.
Well not sure if this helps but maybe ...
-----Original Message-----
From: jawsscripts-bounce@xxxxxxxxxxxxx
[mailto:jawsscripts-bounce@xxxxxxxxxxxxx] On Behalf Of Steve Matzura
Sent: Tuesday, June 12, 2012 7:35 AM
To: jawsscripts
Subject: [jawsscripts] A last-gasp attempt at this 3270 problem of mine
Yesterday I spent a very productive three hours framing, labeling, testing,
triggering, and documenting a very busy screen on a 3270-emulation-based
application. This thing was dancing on the ceiling by the time I was
finished with that screen. You could hot-key-read any one of 35 fields on
the screen, with or without field names, which meant that I had to define
two windows for each and every field, and just in case you wanted to modify
any of those fields, you got a complimentary left-mouse-button click on that
area of the screen which would force the PC Cursor to that location so you
could type something in if so desired or if that area of the screen were
even designated as a field in the 3270 window definition back on the
application's home-base computer. Really neat stuff!
Then, the second part of my day came crashing in. A summary screen
consisting of eleven lines of what amounted to a history view of account
activity in reverse chronological order, displayed in a spreadsheet type
layout, which needed to be broken up into its individual fields, of which
there were six per line, and searchable and/or filterable by certain
criteria within the data, such as show only payments, show only bills, show
only meter readings, etc.
Ideally, this should be available from the application itself, but it isn't.
If JAWS had the capability to define frames within frames, and I don't mean
just define another separate frame that just so happens to be a sub-area of
another frame, or if the ability existed to load a separate set of frames
and hot-key triggers for different screens all with the same window name or
control ID, I'd be set! Anybody remember old JFD and how you could do stuf
like that back then? I was also thinking of trying to write a script which
could navigate these eleven lines of data and read only those lines where
certain information was displayed, like the code or text to indicate a
payment, for example, so the end-user could press a key and have the eleven
lines filtered the way they needed, but I couldn't for the life of me figure
a way to do this and get it coded in an hour or two! Frames are great
things, but they're not smart in any way, shape or form. You can't tell a
frame "read this if you contain certain data, keep silent otherwise."
At least, I don't *think* you can. The only possible way I could think of to
do this was if the information was color-coded in some way, but it isn't.
Everything on the screen is the same color except the modifiable fields, of
which there turned out not to be all that many.
And I haven't even gotten to tell you about another data select screen where
you put a selection mark in front of a summary line, hit a function key, and
get one of half a dozen selectable new screens with detailed information on
the summary item you selected! An incredible amount of data is available
through this system. I've been in the data-mining industry for years, but
not since I worked on stuff for the securities industry have I seen stuff
like I saw yesterday. And they want the customer rep who operates this thing
to have access to it all so that customers can check on any aspect of their
account with this company. The customer service industry has come a long
way. The reports this system produces must be real eye-openers!
... but I digress ...
Then there's the question of just how many key combinations can one person
be expected to remember for one little old application if I were to define
frames for every single field on every single screen, most of which wouldn't
even make sense to be used as such, not to mention I'd run outa keys before
I ran outa fields!
It was for this reason that I have prepared a report, not yet submitted,
that states that scripting for this application will not go far enough to
satisfy the access requirements of a JAWS user to work with it and get the
job done for which the application was originally written in any kind of
efficient manner. However, before I submit this report, I thought I'd throw
it out to you all for one last-gasp effort to see if there's anything I
haven't tried that I should, etc. Your input greatly sought and appreciated.
__________o?=
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
__________�
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
Other related posts:
