ATJ Guide for Developers
This guide contains a checklist for implementers of the Access to Justice Principles. Technology changes frequently. Each year brings new surprises and opportunities for leveraging technology to increase access to justice. Unfortunately one of the consequences of this is that best practices, standards, and implementation advice quickly grow obsolete. This guide, therefore, does not attempt to provide concrete answers to implementation, but directs the reader to ask the right questions and steers the reader to resources and practice groups where answers will be updated with technology.
Because it is focused on features, purchasers, systems developers and architects, integrators, and information specialists employed by the courts may find this guide more applicable to their work than the Guide for Managers.
The guide is available for download in PDF format here.
Has user input been gathered? Does the project have plain-language help documentation? Does the project have an effective mechanism for feedback in place? Are user interactions with your project answered accurately, consistently, and reliably? Does the information in your project update with the times or is it static? Is the data of your project secured against loss? How will obsolescence be handled? What data about people is necessary for the project’s success? Are security controls necessary to protect confidential or restricted data in your project? Is integration of your jurisdiction’s Alternate Dispute Resolution (ADR) processes with the project possible? Is your project accessible in multiple places and formats? Does your project require a baseline of users to become effective or maintain its level of effectiveness? Does your project comply with Section 508? Does your project utilize the latest Web Content Accessibility Guidelines? Does the project’s GUI comply with best practices or industry standards? Does the project follow the best practices available in security? Has the project been tested for mobile compatibility?
Better understanding of user requirements is directly tied to the number of information exchanges with users: more tends to be better. There are multiple sources of information: customer support lines, surveys, interviews, focus groups, trade show experiences and user-shadowing are just a few examples. Studies show that successful projects average five different sources of information and do not rely too heavily on user intermediaries.
Provide an online help function in plain language, for example a Frequently Asked Questions list, or FAQ. Anticipating questions users might have requires that users’ input has been gathered and considered carefully. Recognize that users may need help with not only how to complete a task, but also what the available tasks or resources are, and why they should complete them.
Develop feedback and measurement practices to monitor progress toward reaching service populations, facilitating access, and providing understandable and usable resources. Both individuals and community organizations can provide feedback, both quantitative and qualitative. Consider using user surveys, user interviews, accessibility and usability checklists, and outcomes surveys. Other tools and techniques may be available in the future and are worth considering. Seek feedback for at least four areas of evaluation: technology inputs (outreach, accessibility, understandability, usability); technology use (actual use of the project and training, use of the project over repetition and time); user satisfaction on various occasions and uses; and outcomes (user and system outcomes). Evaluate and analyze the data you receive from your users. Repeat evaluations on a periodic as well as on an as-needed basis.
Resources: At the very least, an email address should be available for user feedback. Free online survey tools are available, e.g. SurveyMonkey at www.surveymonkey.com.
This question is of primary importance to any project. Inaccurate, inconsistent, or misleading results cannot be part of any project used by the justice system.
Static data and changing data pose different challenges. Changing data means new data will be entered into the system; this new data must be integrated accurately and without accidental redundancy. Static data on the other hand may be inflexible to new or exceptional situations and may grow stale with time. A good strategy for data integration grants many benefits by standardizing data exchange; it can improve information quality and drive down costs of data maintenance and updating.
Resources: A possible data integration strategy, the National Information Exchange Model, can be found at www.niem.gov. Other state courts have opted to follow this model in whole or in part, including California and Vermont.
Hardware and software are prone to failure at inconvenient times. Data should be redundantly stored to some extent to prevent one accident or act of vandalism from wiping out accumulated information. This can be done through cloud storage or hardware backups or proprietary services as circumstances dictate.
When a project, for example a filing method, is deemed in need of replacement, users should have access to information about why the old method is no longer available and how they can access a new method which suits their needs. Paper filing cannot be replaced entirely by electronic methods. Sometimes information becomes old or obsolete; there should also be mechanisms in place which alert justice system employees of this, even if the original workers on the project have moved on. A projected sunset or scheduled checkup posted to a group calendar may suffice.
Compare the data needed for the project’s success to the data actually being captured. Would additional data advance the project’s goals or would it qualify as over-capture?
Resources: PrivacyTrust has resources which guide data collection so that it is done in a secure and legal manner. The website: http://www.privacytrust.org/guidance/index.html.
Working with legal specialists within your organization, determine what information needs to be protected pursuant to statutes, rules, court orders and other legal authority. Identify technical requirements to implement the protections required. Hear from potential users and other interested parties what their concerns may be. Determine if the system, its processes and the technology is set up so that these concerns are addressed.
Identify the data elements which the court currently uses in hard copy to determine if a case is ADR eligible. If they match, incorporate those data elements with your technology project, so that the cases get correctly routed. Build a system which allows flexibility so that it may be integrated with an ADR system currently in place (e.g. ADR at the court’s discretion), but that it will also be capable of integration and use with other types of ADR (e.g. mandatory or at the option of the parties) should they be adopted or available for use in your court.
Identify potential access points where the target user population can make use of your project at convenient times. Access points can include physical locations as well as internet or other technology portals. Ensure that the point-of-access used does not affect the functionality of the project, i.e. a site that cannot be accessed from a mobile device.
Some projects are subject to what is called the network effect. To understand the network effect, think of a telephone: it is only useful to have a telephone if everyone else has one too. If your project is subject to the network effect, make sure the critical mass of users is explicitly stated as a goal during production and a part of evaluation.
Section 508 requires that the federal government’s Electronic and Information Technology (EIT) is accessible to people with disabilities. They set standards for accessibility, and provide tools, resources, and best practices to help meet those standards.
Resources: Section 508 has a website, www.Section508.gov. On the site, tools from everything from how to create an accessible Microsoft Office document to how to check a website for accessibility problems are available. One can also find resources pointing out the latest assistive technology devices, software, and hardware and product innovations in case your project requires accommodation for the disabled.
WCAG and Section 508 overlap to a great degree.
Resources: The W3C Web Accessibility Initiative provided a useful list of techniques, complete with examples and implementation details, which aid in complying with WCAG 2.0. It is available here: http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/Overview.html#content.
A clean GUI with the most important items placed consistently at the top and center of the display helps create a positive first impression of a website and eases usability. There is an entire field of research and study devoted to this; it is called HCI or Human-Computer Interaction.
Resources: Check the appendix of this document for a quick-fix checklist for any website.
Security can be too tight or too loose. Too little security can leave a system vulnerable to injection attacks, data theft, and fraud. Ethics breaches can arise if private data is available to unauthorized people because of weak security. Too much security can inconvenience customers or employees or reduce access to resources needed for a just result.
Resources: Security is a broad topic. For educational resources and useful links, consult KMBL’s website at: http://www.kmbl.us/Education_resources/Education_resources.htm. If you have a specifics (for example: intrusion detection) already in mind, the Software Engineering Institute’s Virtual Training Environment has an online repository of resources located at https://www.vte.cert.org/vteweb/Library/Library.aspx.
Design each page to be no more than a set usable maximum (this will change as broadband infrastructure changes and improves). This includes the base file plus all images on the page. Remember that some file types are optimized for mobile web application (e.g. SVG). Make sure page loads occur quickly. Limit the use of graphics, video, audio, or flash in your project’s mobile version.
Resources: The W3C has a list of mobile web best practices available here: http://www.w3.org/TR/mobile-bp/.
Has user input been gathered?
Does the project have plain-language help documentation?
Does the project have an effective mechanism for feedback in place?
Are user interactions with your project answered accurately, consistently, and reliably?
Does the information in your project update with the times or is it static?
Is the data of your project secured against loss?
How will obsolescence be handled?
What data about people is necessary for the project’s success?
Are security controls necessary to protect confidential or restricted data in your project?
Is integration of your jurisdiction’s Alternate Dispute Resolution (ADR) processes with the project possible?
Is your project accessible in multiple places and formats?
Does your project require a baseline of users to become effective or maintain its level of effectiveness?
Does your project comply with Section 508?
Does your project utilize the latest Web Content Accessibility Guidelines?
Does the project’s GUI comply with best practices or industry standards?
Does the project follow the best practices available in security?
Has the project been tested for mobile compatibility?