RE: Draft for selecting processes in web applications (addition to Step 3.d)

HI Detlev and all

Detlev, I really appreciate what you've provided and it's a great starting point.  My main feeling upon a first reading is that the wording of this may be too complex for a newer evaluator.  Perhaps we could explain the different scenarious more simply?  I'd like to keep the gist of what you're saying, but just to provide clearer use cases?


Regards

Vivienne L. Conway, B.IT(Hons), MACS CT, AALIA(cs)
PhD Candidate & Sessional Lecturer, Edith Cowan University, Perth, W.A.
Director, Web Key IT Pty Ltd.
v.conway@ecu.edu.au
v.conway@webkeyit.com
Mob: 0415 383 673

This email is confidential and intended only for the use of the individual or entity named above. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify me immediately by return email or telephone and destroy the original message.
________________________________________
From: Detlev Fischer [detlev.fischer@testkreis.de]
Sent: Friday, 17 August 2012 4:43 PM
To: Eval TF
Subject: Draft for selecting processes in web applications (addition to Step 3.d)

Hi everyone,

as promised, I have tried to come up with draft (probably within step
3.d) for including complete processes.
Feel free to shred this to pieces...

regards,
Detlev

-----
Step 3.d: Include Complete Processes in the Sample

1. For any critical process identified in Step 2.b: Identify Key
Functionalities of the Website, the *process base page* is included in
the sample. The process base page is the page that acts as launch pad
for other states called up when traversing the process.

2. For processes with branches incl. error handling, record the
*default branch of the process*. The default branch is the simplest
use case, describing the default way through the process. It assumes
that there are no user input errors and no selection of additional
options. For example, in a checkout system, the user would proceed to
checkout, confirm the default payment option, provide all required
payment details correctly, and complete the purchase, without changing
contents of the shopping cart, using a stored user profile, selecting
alternative options for payment or shipping address, providing
erroneous input, and so forth.

3. For processes that consequently call up or generate further pages
(new URIs), add these *derived process pages* to the page sample,
directly where possible or by specifying the actions on the base page
of the process that led to it (e.g., "fill out form correctly and
press "Submit"). The page description should indicate that this
derived page is part of the same process as the first page, for
example, through consistent numbering.

4. For each page of the process, the *page process record* should at
least describe as list all steps / user interactions that lead to
consequent process states on the same page. Optionally, it can include
screen shots for these states. Whenever a process calls up a new URI,
consequent states should enter the page process record of that derived
process page / URI in the sample.

5. The page process record need only specify additional states to be
evaluated, i.e., all elements that are added, modified or made visible
on top of the base page.

6. For processes with branches that are commonly used or entered and
are critical for the successful completion of the process, register
*critical alternative branches* of the same process. Branches may
terminate where they re-enter the default branch of the process, or be
covered until their completion. For example, adding a new shipping
address will be registered as a critical alternative branch that leads
back to the default branch of the process.

---------
Finally, two bits that might be added later in Step 4 "Audit the
selected sample" to help operationalize checking processes in the
still rather vague Step 4.a: Check for the Broadest Variety of Use
Cases:

* Those parts of the base page that remain unchanged need not be
evaluated again when evaluating a particular page state.

* When evaluating elements in alternative branches that are found to
be substantially the same as those already covered in the evaluation
of another branch, the evaluation may simply record pass/fail and
clearly refer to the comment made at the other location.

--
Detlev Fischer
testkreis - das Accessibility-Team von feld.wald.wiese
c/o feld.wald.wiese
Borselstraße 3-7 (im Hof)
22765 Hamburg

Tel   +49 (0)40 439 10 68-3
Mobil +49 (0)1577 170 73 84
Fax   +49 (0)40 439 10 68-5

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites

This e-mail is confidential. If you are not the intended recipient you must not disclose or use the information contained within. If you have received it in error please return it to the sender via reply e-mail and delete any record of it from your system. The information contained within is not the opinion of Edith Cowan University in general and the University accepts no liability for the accuracy of the information provided.

CRICOS IPC 00279B

Received on Friday, 17 August 2012 12:32:47 UTC