I can tell you from conversations I've had and observations that I've made,
that many of the designers of the new screens have never even seen a shop
where batch entry takes place.  Most of these new coders are used to making
WEB pages, and the concept that  a company needs to key 10k + orders per 8
hour shift is just not known to them, therefore, the idea that the number of
keystrokes matters just doesn't make sense to them.

I can honestly say that what's missing here is the fact that not one person
in the ***new design** team has ever even seen the order entry screen of the
legacy system let alone entered an order in the legacy system, and that, in
my opinion, is a detriment to all.

For an entry clerk to have to enter Montana as a State code, they have to
enter an M nine times!!  Unless they can remember every state code's ordinal
position within the LIKE State codes, they have to look away from their
source document to ensure they have entered the correct State code, and that
my friends, slows data entry people down...period.



Ray Shahan






> -----Original Message-----
> From: Greg Stigers [SMTP:[log in to unmask]]
> Sent: Monday, March 08, 2004 4:10 PM
> To:   Shahan, Ray; [log in to unmask]
> Subject:      Re: Old vs. New or Browser vs. View
>
> > One was the
> > entry person using the mouse to ENTER the screen
> I would expect any well-designed data entry screen to place the cursor in
> the first field on the screen. A well-designed GUI should provide unique
> but
> intuitive accelerator keys that allow one to 'jump' to a field of choice.
> For instance, normally, it is enough that someone provide their ZIP code,
> from which their city and state is derived. Remarkably, not everyone knows
> what their ZIP code is. Some people do not even know the name of the city
> in
> which they actually live, although one hopes for minimal intersection
> between those two groups among one's customers. For the former group, one
> must take their stated city and state, rather than start with their ZIP
> code. The ability to navigate quickly from the keyboard is vital.
>
> > these folks however,
> > had issues with the drop-down menus for State, Dates, Company Codes
> fields
> > in the new screens.
> It should still be possible to type a state abbreviation or a standard
> date
> into the text field. MS Money allows this, while providing the calendar
> control for those who will not type. I find that I can just enter the day
> of
> month, and Money assumes I mean that day of the current month and year.
> Clever, that. Likewise, it should be possible to type a two-letter state
> abbreviation, and a bare drop-down list should bring one to the correct
> choice, at which point, the system should either except the match and
> place
> the cursor in the next field, or at least allow the user to tab over to
> the
> next field.
>
> Designing a good interface is not a trivial effort. This experience brings
> into question how well designed the interface was, and whether the design
> team included a user feedback loop in their design process. It also
> exposes
> the collective knowledge that users accumulate on how to use a product,
> which knowledge increases productivity, and therefore has a value on which
> their employers should place a price. It is both an investment that the
> company has made, and an asset which is at risk when moving to a new
> interface. Companies want to hire people with experience, but do not
> recognize that when an experienced employee leaves or is let go, they take
> with them that experience which is as real an asset as any piece of office
> equipment that we do not let go out the door.
>
> Greg Stigers, MCSA
> this space for rent
>
>
>
>
>
> ========================================================================
> This e-mail message has been scanned for Viruses and Content and cleared
> by School Specialty's email filtering solution.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *