Thursday, November 28, 2013

Design for All: Finding the good examples around

In this post we were supposed to find good examples of accessible design. I don't know how most people started this search, but I begun by the most obvious place to me: my own computer. Most modern operating systems have accessibility options and Windows 7 is no different: the Ease of Access Center concentrates most accessibility features in a single screen:


When you open this window, it automatically starts reading the options to you out loud. I will also scan through every option, so if you have either difficulty reading or of mobility (or both), you can make your selection by waiting for the system to say the name of the desired option then just pressing the space bar (by far the largest button on the keyboard). Points for limited vision and dexterity. You can also set up alternatives for sound alerts (for the hard at hearing), alternate input devices (for several disabilities), higher contrast and larger fonts (visibility) etc.



Speaking of visibility, these guidelines for blind people are amazing. We had them everywhere in the subway system in São Paulo. Blind people can follow them using their canes, so they know where to go and where not to go. This example is very interesting (it comes from Japan): it moves sideways every time it comes near a manhole, so in the event that it might be open for work, blind people do not risk falling in. It even helps people with good vision: the obvious asymmetry in the design calls attention to the manhole ahead. Points for visibility, no matter if your blind or just totally distracted.


Speaking of moving around, this is a bus stop in Curitiba, Brazil. Even though it is elevated, it was actually designed with accessibility in mind: buses line up to the side of the tube and you board horizontally, with no ramps or stairs. You climb in through stairs, ramps or this amazing elevator for people with limited mobility or mothers pushing trolleys. You also pay when you climb into the tube, not when you board the bus, so there is no fumbling around for money, smartcards or bus tickets. Less lines, faster transit all around.


This is an accessible bathroom: no pesky doors in the way, the sink is low enough to use from a wheelchair (or to be used by children!), there is a very low shelf for the bathing products and rails all around (very nice to the elderly and also to wheelchair users). The dual shower heads allows for a no-compromises bath for people of all different heights and levels of dexterity.


Last but not least, one of my favorite examples of design for all from Robson Square in Vancouver, Canada. Instead of an obvious "accessible" staircase, with signs telling people with limited mobility where to go, ugly rails separating the ramp from the stairs etc, this is just an integrated space where people of all levels of mobility can get from one level to the other. Rails are integrated to the design with minimal disruption and stairs and ramp blend together in a single, beautiful structure. This is the perfect example that a universal design is possible and that accessibility does not need to be an afterthought or be something glued together to the "regular" design.

Sunday, November 24, 2013

Foundations of Human-Computer Interaction - Module 5 - Interface efficiency, KLM, GOMS

This module was filled with insights into my master's thesis. Maybe because my thesis is finally (!!!) materializing inside my head, maybe because it simply did have many concepts which bug me constantly, like the quantification of (in)efficiency of human-computer interfaces. But now I'm not only quite sure of what I am to propose as a thesis, but how to defend and quantify the results of the work.
Phew! Thanks Prof. Lamas! It must have been all that cheese bagel I had last week (just kidding, the meeting was great to solidify my ideas on tangible computing).
Without further ado, let's move to the concept map:

In this one I resorted a lot less to quantifications and special colors (maybe because the methods themselves are quite linear and self-explanatory, or maybe because they make sense to me).
Overall, this was a very information-dense module: lots of interesting things to learn from a rather small pool of key concepts. Good information efficiency, I guess!

Ubiquitous Computing Module V Assignment: SWOT analysis and rough timeframe for implementation

BYOD for Asio EduERP/School calendaring

Strengths
  • All required technologies are here, just not correctly deployed/integrated
  • Easy to assemble a team experienced in development and interface design
  • Direct interest of the University in improving the existing system
  • Direct interest from users (students and staff) in integrating scheduling in their existing workflow

Weaknesses
  • Not all stakeholders might see the use for the system (do not use computer based calendars etc)
  • Multiple platforms make for very widespread testing platform (many opportunities for incompatibility)
  • Might incur in unpredictable costs (large volumes of SMS messaging, for example)

Opportunities
  • Create a de-facto standard for academic calendaring
  • Synergies between service providers and universities can bring new partnerships
  • Steer universities away from closed-sourced implementations in the future

Threats
  • Asio is fully standards compliant, but closed-source, access to code might be impossible
  • Asio has own closed source alternative: Asio Edu App
  • Resistance to FOSS is still a reality in many Universities
  • No sponsorship, no project
  • Timeframe is very limited and inflexible - must work within the academic calendar

Rough Timeframe


Thursday, November 14, 2013

Getting around Tallinn University in a wheelchair: From Mare to Terra's Room T407

From the parking in front o Mare:


Not gonna use this ramp, sorry!
Sign says this way, but actually the bridge is on the second floor.

Elevator it is!

A-Ha! The bridge.
These doors are mighty heavy by the way.
Across to Silva/Astra
Up to the 4th Floor we go...
Silva, 4th Floor. Terra to the left.
Still to the left. Lots of wheeling around.
In the end of this corridor? No, still to the right.
4th Floor, doors to Terra to the right. Sweet!
Oh no. Stairs! Bummer...
No way. Dead end, right?

Bonus Round: I found a solution!

Go back to the 3rd Floor and back to Astra.

This little door with no sign whatsoever? Secret wheelchair elevator... Sweet!
Accessible buttons. Too bad this elevator is hidden!
Finally in Terra!


Ta-da! Took me a lot of time though :(

Sunday, November 10, 2013

Foundations of Human-Computer Interaction - Module 4 - The Human Processor Model, Fitts’ Law



In building this map I had to resist very hard not to follow Card's design of a little user's head when positioning the elements. I am actually glad I did, because I could maintain my habit of aligning equivalent elements (with the exception of working/long term memories, which I had to push diagonally to fit the recognize-act cycle). I wound up using four color codes: light blue for most concepts, yellow for the recognize-act cycle, gray for figures (time, capacity) and green for principles of operation and their consequences.
Not the best map I've ever built, but I believe most concepts are well represented, even if some are left unnamed (I decided some principles of operation were more important for their effects and naming them would be overkill).

Sunday, November 3, 2013

Ubiquitous Computing Module IV Assignment: Design Issues

In this post, I will try to analyse what are some of the issues the project of ubiqutifying ASIO EduERP might entail. By moving away from the centralized calendar website to the user's personal choice of calendaring application (be it on the web, on a mobile device, on a desktop or all of the above), we are basically inviting issues of multiple interfaces. There is no predictable point of entry, there is no single interface, but myriad apps with their own sets of features, constraints and limitations. The single most difficult thing, in this case, is knowing when a given feature is or isn't available to the user on his chosen platform - Can he accept/decline invitations?  Can he push changes back to us?
The safest route is to assume no interactivity whatsoever is available on his chosen platform, and implement all of them as web applets[1]: whenever there is need for user input, a simple, responsive website should be developed for the given input. Should the user's platform provide for that functionality, the website is redundant and can be ignored. Should it be needed, the user can resort to the web solution. Communications between system and user should use a widespread platform, such as email or text messaging (user's choice) containing human-readable information and links to the applet solution as well as the WebDAV content (computer-readable), so whatever context the user finds himself in (reading through his mobile device or desktop computer) he can take the appropriate action (open the web applet, receive the WebDAV link and let his application deal with it, leave the message for another time/context).
Likewise, the system should be able to issue and deal with redundant communication[2]. The existence of multiple points of entry dictates that at least some users will choose to, at different moments, use different interfaces for the same information. That must be not only be designed for, but even be encouraged. The system should, therefore, be able to deal with modal changes (some input coming from the web, other through WebDAV, etc) and sometimes modal redundancy (same input from different sources). These multi-modal inputs should never introduce new complexity, but should always simplify communication with the system. Instead of issuing arcane error messages, the system should just deal with it sending confirmation messages that sound like natural conversation (i.e. instead of saying "you reversed a given option", say "you seem to have changed your mind, are you sure?").

In this way, some of the following design issues are addressed: multiple interfaces, smartness, existing practices, feature parity, seamless of interaction and ubiquitous access. Understanding user's needs is also such an important feature that its lack was the main drawback of ASIO EduERP that inspired the creation of this project, so it is also (hopefully) addressed by it.




References:

[1] Hassler, V.; Then, O., "Controlling applets' behavior in a browser," Computer Security Applications Conference, 1998. Proceedings. 14th Annual , vol., no., pp.120,125, 7-11 Dec 1998.

[2] Stanciulescu, A., "A Methodology for Developing Multimodal User Interfaces of Information Systems", Ph.D. thesis, Université catholique de Louvain, Louvain, Belgique, 2008.