Critiques for Week 01

Name: Design-Time Accessibility
Type: Challenge
Discussion:  The paper consistently discounts "ad-hoc" modifications as an effective means to ensure accessibility, and insists, instead, that a design-time approach is essentially the only way to properly address accessibility.
Location: Introduced page 2, explained on page 5.

It must first be asked if it is actually true that the only valid point which accessibility can be addressed is at design time. Before insisting that major changes be made to the way that software developers approach design, it must be shown that these specific changes are, indeed, necessary. There are many obvious objections to these assumptions.

The Unified User Interface approach requires designers to enumerate user requirements for every conceivable individual ability and external environmental context. Is this a reasonable expectation when it could involve hundreds of different abilities and millions of combinaitons of abilities and even more external environmental factors? Can designers be expected to predict, with any sense of comprehensiveness, every possible individual who uses their software or context in which it appears? Why not encourage developers to ensure that their design is easily modifiable so "ad-hoc" solutions, which can be created for specific contexts and can be tailored for individual users, are more effective?

Name: Unified Interfaces focus on Design
Type: Challenge
Discussion:  This section discusses the theoretical aspects of designing the user interfaces
Location: section 2.1.1 and throughout the paper

Achieving the goal of developing user interfaces for all seems to be hazy and clear explanation is required. The paper jumps right into design without expalining how this design can actually respond to actual user needs.

Focus of the designer seems to be on the Design phase of User Interfaces without considering the Users involved. Users seem to be given a second priority which should not be the case. Reference http://www.uiaccess.com/accessucd/analysis.html  from book “Just Ask: Integrating Accessibility throughout Design” by Shawn Henry.

Name: Dedicated UUI Language
Type: Opportunity
Discussion:  While discussing a United User Interface (UUI), it is mentioned that an interface specification can be build using a dedicated programming language instead of a traditional one
Location: 2.1.1 Unified interfaces, page 2

It would be helpful if more details were provided about the benefits of a dedicated programming language over a traditional one.  It seems that libraries could be created for a traditional language in order to simplify making an implementation specification as well as having the advantage of a wide variety of development tools available to a more commonly used language.

It is important to compare and contrast the benefits to a development team given by both a traditional and a dedicated language.  This includes vital aspects such as cross-platform compatibility, ease of development, availability of development tools, and ability to develop an interface for the broadest possible user base. It is not clear that the system being proposed is superior in all these aspects.

Name: Design patterns
Type: Opportunity  (NOTE: This is an opportunity for a project also)
Discussion:  Many dialogue patterns should be used in designing accessible interfaces.  Which patterns are most important?
Location: 2.1.1 Unified interfaces, page 3

Designing for the broadest possible selection of users may not always be possible due to various constraints, be they time or budget.  It is important to determine which patterns are most important to have when the system ships, and which could possibly be added later.

There are several factors that could be used in determining how important it is to use a particular pattern during the design phase.  They include the number of users it would assist, the ease of specifying that particular pattern, and the difficulty involved in adding that pattern after the design phase is complete.  There may be other aspects to discover as well.

Name: The "Dialogue Artefact" Abstraction
Type: Challenge
Discussion:  The paper suggests that developers regard UIs in terms of various "Dialog Artefacts"increasing the level of abstraction in the design process.
Location: Introduced page 3 and discussed throughout

The paper is written, necessarily, under the assumption that developers are not making software properly accessible. Why assume, then, that they can adequately develop their own specifications that give rise to accessible software? The enumeration of various "Dialog Artefacts" that are tailored to various users and usage contexts is crucial to the Unified Design philosophy. If so, why does the paper not describe any sort of standardized specification for these enumerations, so that they could be drafted by usability experts and shared freely with the development community?

It is not demonstrated how this abstraction is helpful in addressing accessibility concerns. It is missing the existence of, or at least pointing to, a set of concrete examples of effective dialog artefacts that cater to specific individuals. It may be more beneficial for developers to focus more on these specific requirements in general, rather than the abstract notions required for their design and implementation. Developers need to be instructed how to design UIs in an accessible way, not on how to design their UIs in the first place.

Name: Dialogue Artifacts
Type: Opportunity
Discussion:  This term is introduced without giving a formal definition of what it means.  A formal definition would help to clarify what is meant by this term when it is used in the paper.
Location: section 2.1.1

This term seems to deal with accommodating different user needs and different contexts where an application will be used, which is central to the main idea of the paper of accommodating a range of user needs.

This term should be defined, eg. as individual messages that need to be communicated as part of a dialogue. An example could be given to clarify its meaning.

Name: Evaluation
Type: Opportunity
Discussion:  Figure 1 shows evaluation is one phase of iterative software development cycle.
Location: page 3

User interfaces for all expand the targets of evaluation. Furthermore, the adaptation–related behaviors of UI4A only can be evaluated in context. Thus, evaluation becomes a challenge for UI4A. 

Planning for evaluation of adaptation-related behaviors will require a considerable amount of work to ensure that the evaluation actually evaluates everything that needs to be evaluated. To evaluate the results in context, it would be helpful for the development to identify the contexts for which the interface is designed.

Name: Adapting to users and context
Type: Opportunity
Discussion:  Labeled as metaphor independence and automatic adaptation capabilities, the paper states that the system would be able to adapt to different users and contexts of use.
Location: near end of section 2.1.1

Although it makes sense that users will have different needs, users that are grouped in a particular category may not necessarily have the same needs.  For example, some seniors may need accommodations for hearing or sight impairments, but others may not.

In addition to classifying users' needs based on their classification in a particular group, users should also be able to specify their specific needs, such as speech output or large fonts.

Name: interactive application (see also design patterns discussion above)
Type: Opportunity
Discussion:  Except putting all alternative dialogue patterns into a single software application, we also can use another way.
Location: Ch 2.1.1 page 4

A possible technique to reduce the resources required.

We can treat every alternative dialogue artefact separately and take all the necessary implementation steps to arrive at an alternative interface version. If several different artefacts have same implementation, we can treat then together. Then we save a lot of resources.

Name: Accessibility on a Per-application Basis as Opposed to a Per-platform Basis
Type: Opportunity
Discussion:  From the discussion in these sections, it is apparent that UI4All and Unified User Interfaces are intended for the development of accessible applications, not accessible systems or platforms.
Location: 2.1.1 Unified interfaces (paragraphs 3, 4), 2.2 Early applications and demonstration phase

Upon reviewing these sections, UI4All and Unified User Interfaces are partly intended to help to develop accessible applications for personal computers, including Microsoft Windows, MacOS X and Linux based computers. If a person was going to use one of applications on such a computer, they are most likely going to want to use the rest of the platform as well. In circumstances where no accessible applications is running and the platform does not have any adaptive technology in place, disabled and other disadvantaged persons would have no means to access and start the needed applications. Besides, personal computers are often the only mean through which disabled and other disadvantaged people can participate in society and day-to-day living in an independent manner. It would be more helpful to make the platform (i.e. personal computer) accessible.

Since UI4All and Unified User Interfaces show promise with making individual applications accessible, maybe we should use this research to develop accessible platforms. Future research could develop strategies, specifications, and toolkits/libraries to make the interactitve facilities of the different platforms in a standard and consistent manner.

Name: Development of interface
Type: Challenge
Discussion:  This section is too general.  It seems to imply that an accessible application can be developed on any platform with appropriate ways totranslate the application to the specific platform's capabilities. If one platform has capabilities that another does not have, it may be more difficult to have the same system work on multiple platforms in the same way.
Location: section 2.1.2

If a system like the one described is to be developed, cross-platform usability is one of the aims.

There does not seem to be a clear solution.  Perhaps the application could be modified for target systems to give as much accessibility as possible.  For example, a system which allowed use of speech synthesis to convey information to a blind user where this was available may be able to use audio tones on another where speech synthesis was not available, provided this was a practical solution.

Name: Platform Independence and Responsiveness
Type: Opportunity
Discussion:  This section discusses the importance of platform independence for the successful development and implementation of a unified interface. How would this affect the responsiveness of applications developed with this unified interface?
Location: 2.1.2 Unified interface development(, paragraphs 4, 9, 10)

According to this section, the unified interface is supposedly independent of any interaction platform or graphical environment, i.e. platform independent. If the unified interface cannot directly "call" the interactive facilities for any platform, the responsiveness of the applications and their interface may become noticeably delayed. In my experience, a noticeable delay in resonsiveness of an application or assistive technology is one of the most unsatifactory experience, especially if the delays occur continually and frequently. These delays leave the user with a sense of not being efficient. As been defined by ISO, usability must meet criteria for efficiency and satisfaction. With the feeling unsatisfied and inefficient, the criteria for usability are not being met. Therefore, we need to address the performance of the unified interface and applications developed with it.

To ensure the viability of the unified interface, we must ensure it has sufficient performance and responsiveness that applications developed with it do not have unusually long delays in their resonsiveness. People will notice a delay as short as 0.5 second and expect a respond to their action (e.g dialogue box opens after they select the appropriate button) less than 0.5 second later. According to the discussion in this sections, tools have been develop to generate toolkits/libraries for the differnt platforms, such as Microsoft Windows and X Window. Next, research is needed to develop strategies and tools to optimize the performance/responsiveness of these toolkits/libraries for their respective platforms.

Name: Unified Design
Type: Challenge
Discussion:  A "Unified" approach to User Interfaced design is called for, with UIs being independent from both platform and specific interaction models and metaphors.
Location: page 5

The principals of Unified User Interface design suggest that the creation of a UI be decoupled conceptually from actual programming implementation. It is obvious that this increases cross-platform compatibility, but the paper doesn't explicitly describe how this compatibility benefits accessibility.

There should be concrete evidence suggesting that a decoupling of design and implementation would have tangible benefits for making software accessible. Does this process simply make the development of an accessible UI easier? If so, how are these suggestions superior to the design practices of software engineers who specialize in such things, and who have intimate knowledge of their systems and their target users? Furthermore, there are no specific standards regarding the format of the enumerations and design requirements necessitated by the UUI design process. If we expect developers to come up, individually, with their own "unified" designs, are they really unified in any sense?

Name: Single Responsibility Principle and Interface-Segregation Principle
Type: Challenge
Discussion:  The concept of a Unified User Interface violates two specific design principles: Single Responsibility Principle and Interface-Segregation Principle.
Location: Section 2.1.2, p. 5

In the eyes of usability, having a Unified User Interface would be ideal since it allowed everything to be generic and accessible to everyone. However, solutions to usability issues should still follow basic design principles.

Robert C. Martin lists Single Responsibility Principle and Interface-Segregation Principle as two design principles of agile software development in his textbook "Agile Software Development: Principles, Patterns, and Practices".

Single Responsibility Principle states that each class or object should have only one reason to change, i.e. it has one responsibility. Since the implementation of the Unified User Interface requires it to be constructed as a composition of abstractions at different levels of interaction, it would have to be able to do the jobs of each of the abstractions. That has many responsibilities.

Also, in creating such an interface violates the Interface-Segregation Principle, which states that clients should not be required to implement methods that they will not use. Once again, since it's an abstraction of so many jobs at all different levels, it is likely that there will be methods in the interface that some clients would never use.

Name: User Setting Storage
Type: Opportunity
Discussion:  A system is to adapt automatically to a user’s preferences.  What happens when the user has to use a different system?
Location: 2.1.2 Unified interface development, automatic adaptation mentioned on page 6.

If the system is to adapt to the user’s preferences, then there should be some easy way of reusing those preferences when the user switches systems in order to avoid or reduce the time needed to re-train a system.

A solution would be easiest in a networked computer setting, where a user’s accessibility preferences could be stored along with the rest of their user profile.  Using a public terminal, say an internet café terminal, would be more difficult.  Maybe settings should be exportable to USB memory, or even storable and easily accessed online.

Name: Metaphor
Type: Challenge
Discussion:  One of the main characteristics of this framework is metaphor independence used to cater for the interaction needs and characteristics of diverse target user groups,
Location: page 6

Metaphors can potentially improve the ease of use, user satisfaction of user interface. Moreover, new metaphors emerge very quickly. This poses a challenge to unified user interface development process. 

It is unclear how unified user interface development process could support emerging interaction metaphors. For a metaphor to be effective, it needs to be complete enough to encompas all the elements that it is used to describe and it needs to be clear to its users. While this technology might allow implementing new interaction techniques, there is no guarentee that any metaphors that accompany them will apply to all facets of the existing application.

Name: evaluation
Type: Challenge
Discussion:  How can we know that it is a good design for the users? Does system behavior match the user’s task requirements? Are there specific problems with the design? Can users provide feedback to modify design?
Location: 2.2  page 7

Evaluation is the process of characterizing and appraising something of interest [1].Evaluation is essential for ensuring good design that proves viability of investing in new expensive system. [1] http://en.wikipedia.org/wiki/Main_Page

Questionnaires and surveys would be helpful to evaluate the design. You can plan a set of central questions for users such as open-ended, closed, scalar, multi-choice, or ranked question.

Name: Classified Disabilities
Type: Opportunity
Discussion:  This section discusses areas that the UI4All has been tested with and to be used with. They all focus on mental and physical disabilities. What about issues with individuals' personal abilities?
Location: Section 2.2. p. 7

There are more disabilities than just mental or physical ones. Although English seems to be universally understood, users prefer to read content in their first language.

Instead of only focusing on the obvious disabilities (such as mental and physical), there should be more focus on people's individual abilities. For example, not everyone understands the terminology in the technical and research world. There should be a way to accommodate for that. True Universal Access 4 All needs to include linguistic accessibility.

Name: Analyzing and modeling interactions
Type: Opportunity
Discussion:  What are the more suitable units for analyzing and modeling interactions?
Location: Section 2.3, p. 7

The author states analyzing user actions such as keystrokes is not enough to provide contextual insights needed for UI4All. He does not mention how to overcome this problem or what was done to resolve this issue in the demonstration projects.

Potential solutions to this problem should be proposed to allow the reader to know how to resolve this problem. A computer can only know a user through key strokes and mouse movements. What else should be used? Perhaps the system keeps a profile of the user in storage for all applications to access. The user would have to provide the information in the profile ahead of time.

Name: Getting Applications Developed with Unified User Interfaces
Type: Opportunity
Discussion:  This section and previous sections discusses what Unified User Interfaces is, How it was developed, and what are it advantages over traniditional UI development. Yet there is no discussion on how Unified User Intefrace was be released to the developers and how developers will be convinced to develop applications with Unified User Interfaces.
Location: 2.3 Comparison with prevalent user interface development practices

The success of any UI, development environment, or operating system depends upon a vibrant and innovative developer community. For Unified User Interfaces to be used and accessible applications to be developed, the developers need to be support with the proper tools, training, documentation, and expert knowledge/assistance.

The supporters and sponsors need to considers developing the following products and services to convince developers to create applications with Unified User Interfaces.

• Tours/leatures to educate developers about Unified User Interfaces and it advantages
• Released the tools, specifications, and toolkits/libraries for the common/popular platforms, such as Microsoft Windows, MacOS X, and Linux
• Advanced and innovative tools to simplify, minimize drugdery, speed up the design and analysis of the unified interfaces
• Guided education on Unified User Interfaces such as courses and workshops
• Self paced educational materials such as videos, books/manuals, articles, examples, and Web sits

Name: Empty Terminology
Type: Challenge
Discussion:  The paper employs a table of very specific terminology to describe its principals, but these terms are never introduced.
Location: page 8

A central purpose of this paper is to summarize effective Unified User Interface design principals to people unfamiliar with them. In the tables which contrast this approach to current design practises, several terms are employed that haven't been mentioned anywhere else in the paper, such as "Polymorphic task hierarchy" and "Middle-out" processes. These terms are not ubiquitous, and it seems as if the paper is written under the assumption that the reader is quite familiar with Unified User Interface design jargon. This assumption contradicts a central purpose of the paper.

There should not be any terminology used in the explanation of this design philosophy that requires pre-existing knowledge of it. If these terms are indispensable, the reader should be briefly introduced to them, or should be explicitly pointed to a paper in which they are defined. "Middle-out" is used in oposition to "Top-down" which means general to specific development and in oposition to "bottom-up" which means development that builds from details to general components that combine the details. In order to do "middle-out" development we need to know what the middle refers to. It is not a commonly understood development direction, but is only used once in the table on page 8. Where there are no convenient definitions easily found with Google, ther are a number of instances where the term is used in conjunction with describing developments. "Middle-out" is increasingly being used to describe developments that start with whatever is known, (often neither details or generalizations, but rather issues) and then moving both to genealize and specialize these mid-level issues until a fuller picture of the problem/solution is known.

Name: Levels of concerns of Design for All Diagram
Type: Challenge
Discussion:  This section provides a diagram and talks about the “Levels of concerns and implications of design for all”.  
Location: Section 3 (8^th page) and Section 3.1 (9^th page)

The levels of concern seem to be incomplete.

One of the biggest concerns of Design for all should be the users however, the diagram/description fails to mention their role.  Also missing is peripheral devices (printers, scanners, any special devices impaired users might need).  A universal design would need to consider these.

Name: Benefits to industry
Type: Opportunity
Discussion:  It is emphasized that the Health Telematics industry can benefit from increased accessibility.  Which other industries could benefit most from a universal user interface?  Which benefits would those industries realize?
Location: 3.2 IS4ALL, p. 10

Identifying those industries with the most to gain can assist in the widespread adoption of accessibility standards.

Creating a process whereby a company’s services could be audited for accessibility could determine how they could be improved by accessible design.