Today we discussed the notion of testing individual snippets (or widgets, or components, or pieces) for accessibility. There was some discussion if it was really realistic to look at pieces in isolation, as context would play some role. Ultimately, though, it was decided that there are several levels of testing that can occur with regards to usability:

1. Functional testing: testing individual pieces, at a code level. Perhaps able to be automated?
2. User testing: involving individuals who use assistive devices or suffer from afflictions or disabilities
3. (???) Testing - examining how usable a product is, including context-specificity and perhaps engaging specific targeted (expert) users

My primary goal is the second in the list. We can all run code through automated systems, but I want to really see how users are able to use what we create. I also think the scope of individual elements needs to be as limited as we can make it. Yes, ultimately there is transfer by what else is within the context, but we need to find a simple solution first.

I also think we need to be cognizent of the fact that context/interference for a sighted user is dramatically different than it would be for a non-sighted user. Someone using a GUI has to deal with seeing the entire screen at once. Someone using a screen reader is effectively looking at the screen through a straw (need to find the reference I got that from) — they are not overwhelmed with the competing items visually displayed on the page.

I’d like to see some test suites developed and worked through with users. It’s far too easy to make assumptions on what works and what doesn’t. Eventually those can be rolled into more complicated scenarios, but in the immediate present, I would like for my role in the User Experience group to look to, well, the User’s Experience….

I recently set up a profile on LinkedIn.com (http://www.linkedin.com/in/afhill). I soon found myself trolling around for “connections” to add. Along with any social network comes the delicate dance of “friending” and “unfriending” (to use Livejournal terminology).

Establishing someone as a connection offers benefits, but it also comes at a cost. On livejournal, setting someone as a friend gives you quicker access to a users’ post (on your friends list), but it also assumes they are in your “trusted circle”, and can access anything you post for “friends only” (note, users can configure custom friends groupings that only include a subset of your entire friends list). For whatever reason, some users seem to beg for friends, which is essentially akin to saying, “can you share your secrets with me? Please huh pretty please?”

LinkedIn.com doesn’t allow users to share their deepest darkest secrets (”omg Jimmy got the cutest haircut the other day!!!!11!!”), but there still appears to be that draw to amassing the largest group of connections you can. I have received several requests from users to connect. If I won’t be privy to life-altering revelations, what are the merits in connecting with these virtual (literally, not figuratively) strangers?

Perhaps I am naive in assuming a connection with someone means they can speak to my professional capabilities, and networking is based on a foundation of actually being familiar with someone. Maybe it really is just like high school, and the popular kids win.

The time has come for me to think about what to take over the summer trimester. For the past year, I’ve only taken a course at a time towards my masters. However, as it drags on, I find myself wondering if I should try to accelerate things.

I have the following courses to complete:

• COMP 630 — Issues in Database Management
  This course focuses on the fundamental design considerations in designing a database. Specific topics include performance analysis of design alternatives, system configuration and the administration of a popular database system. The course also offers an in-depth analysis of the algorithms and machine organizations of database systems.
• COMP 655 — Operating Distributed Systems
  This course covers the concepts and design of distributed computing systems and distributed application programming. Topics include the basic concepts of distributed systems (e.g., transparency, heterogeneity, network process communication), CORBA and related OMB technologies, and front-end development tool
• COMP 671 — Verification and Testing
  This course focuses on the issues of delivering high quality software, especially in large complex systems. Topics include testing strategies (e.g., black box, white box, regression, etc.), unit testing, system integration, system verification and support tools. It also reinforces the need for requirements that are testable and traceable from the early design stages.
  
• COMP 691 — Capstone
  This course challenges students to complete a major project that integrates ideas from the other graduate courses. Projects may take many forms, and may include or exclude programming effort. The student is required to make a final report to demonstrate the outcomes from the project.

I have already decided I want to write my capstone on Usability-Supporting Architectural Patterns (unless something accessibility-related really peaks my interest soon!), and my goal had been to present my research at World Usability Day in November. So I suppose that means I should do my capstone this summer. However, I was also thinking about enrolling in that database course, then I could take one course in the fall, and finish in the winter trimester.

There are no formal class meetings with the capstone, you have an adviser you work with. However, I don’t want to overload myself and not have the time to devote to this that I would like. Hmmmm…

I am the Accessibility Point of Contact for 2007. I am currently enrolled in a project management class, so I am going to try to run the accessibility initiatives as a project.

So what do I need to do (from class notes and our textbook)?

A project charter is a document that formally recognizes the existence of a project and provides direction on the project’s objectives and management

Scope statement: a scope statement is a document used to develop and confirm a common understanding of the project scope. It should include
* a project justification
* a brief description of the project’s products
* a summary of all project deliverables
* a statement of what determines project success

Common elements of a project plan:
* introduction of overview of the project
* description of how the project is organized
* management and technical processes used on the project
* work to be done
* schedule
* budget information