Discussion on:
View:
Show:
Usability is indeed a very big issue, and what you have said here is more profound than many people will realize. People with all manner of disabilities - physical disabilities and learning disabilities - are people outside of the statistical 'norm' of the population. But they have far more potential for success and achievement than they can find in the things that are designed for the 'norm' by the 'norm'. It can become a road that leads in two directions: one path is taken by falling behind in school, in work, and in life. The other path is taken by finding other ways to do things that work outside of the 'norm'. That's why such a high percentage of successful entrepreneurs also have some kind of disability (typically a learning disability) to live with. The list of people who have found their own success despite such a disability is astonishing, and includes many of the people we consider as having made the most profound contributions to technology, society and culture. Imagine how much longer that list might be if we designed our world so that everyone was able to achieve their full potential by being able to use whatever they needed to use and no-one was left behind.
For-profit orgs don't care about such things though as it eats away at their profits. I guess the lack of replies to this excellent article could indicate the lack of interest the majority of programmers have in this subject.
... It could just indicate how few of us have had the opportunity to see this excellent statement about one of the failures of today's society. It was only after I had the chance to read my latest copy of the 'Visual Basic at TechRepublic.com' newsletter, that I knew the blog existed.
Oyez!! Cellphones....
You could write a book about interfacing with a cellphone, as well as those idiots that you find at the kiosks the cellular carriers contract with.
You've touched a nerve.
No, my friend, I don't want to play games on my cellphone. I just want a phone and service that is functional.
If I want to play games, I will find a bowling alley.
TYVM
You could write a book about interfacing with a cellphone, as well as those idiots that you find at the kiosks the cellular carriers contract with.
You've touched a nerve.
No, my friend, I don't want to play games on my cellphone. I just want a phone and service that is functional.
If I want to play games, I will find a bowling alley.
TYVM
While those things are nice to say, and they are important for a small percentage of the population, I've yet to meet an employer that would even give me the time (money) to implement those types of features. We're talking triple to quadruple development time here. As a software developer, you can't please all of the people all of the time. You do try to add in all those tags, keyboard shortcuts and roll over types of things, but that is the first feature to get cut when management gets iffy with the timeline. There are also technological limitations with the features that people expect nowadays. How to you make a flash display so a blind person can read it? Should all red and green be eliminated? What about those that can't see blue? It's a catch 22.
-D
-D
These are some common concerns, of course. Let me say in the most innoffensive way possible that your training is incomplete, young IT jedi!
Not too long ago, I would have agreed with you completely, but over the past year or so I have had the opportunity to see many things that are not part of the traditional development focus. One quick example is an application called Dragon Naturally Speaking, which allows many people with accessibility issues to use computers very effectively. Dragon has the capacity to permit the individual to interact with and use many other programs, including various web browsers, through voice command rather than the mouse or keyboard. Dragon is available in essentially EVERY common language in the world, and is poised to become a very powerful business productivity app.
Traditional development does not train the developer to think of this program and code accordingly.
Another fine example is Kurzweil, and the many other scan-and-read applications that are commonly available. These applications allow a person to scan or paste in text that is then read back to the user as audio. This feature is also available in Adobe Acrobat, by the way, and has been at least since Version 6. The vision-impaired have no difficulty accessing information through these programs, yet again the traditional design training does not see them.
I guess what this means is that traditional design training only sees the typical web browser format and does not teach the designer to consider ALL the possibilities for accessibility and usability. Many of those possibilities are still pigeon-holed as being add-ons for disabilities rather than potential mainstream applications. What your comment suggests to me is that we still have a fair bit of work to do to get designers to see that there is a whole world out there beyond the borders of traditional design.
Not too long ago, I would have agreed with you completely, but over the past year or so I have had the opportunity to see many things that are not part of the traditional development focus. One quick example is an application called Dragon Naturally Speaking, which allows many people with accessibility issues to use computers very effectively. Dragon has the capacity to permit the individual to interact with and use many other programs, including various web browsers, through voice command rather than the mouse or keyboard. Dragon is available in essentially EVERY common language in the world, and is poised to become a very powerful business productivity app.
Traditional development does not train the developer to think of this program and code accordingly.
Another fine example is Kurzweil, and the many other scan-and-read applications that are commonly available. These applications allow a person to scan or paste in text that is then read back to the user as audio. This feature is also available in Adobe Acrobat, by the way, and has been at least since Version 6. The vision-impaired have no difficulty accessing information through these programs, yet again the traditional design training does not see them.
I guess what this means is that traditional design training only sees the typical web browser format and does not teach the designer to consider ALL the possibilities for accessibility and usability. Many of those possibilities are still pigeon-holed as being add-ons for disabilities rather than potential mainstream applications. What your comment suggests to me is that we still have a fair bit of work to do to get designers to see that there is a whole world out there beyond the borders of traditional design.
You are misunderstanding me. It's not that those tools are not available, it's that those tools are not kept as up to date as they need to be for effective programming for them. There is not a tool built that can interpret a flash intro, other than a text box, and that holds true for most of the more popular web based apps. Another problem here, is a significant lag time, often more than a year or 2, between when a popular web feature comes out and is used on a large scale and when there is a tool that enable the disabeled to interpret it. To say nothing of those that are not widely used.
The tools you list are fine for what they do, but they already work for what they were designed for. Dragon has always been an undeveloped application and works quite well with large blocks of text. Other than news sites, large text blocks are not desired in today's web apps. It's about graphics and embedded pieces. It's not that developers dont' consider all of the choices, because they don't. There are too many things to consider for that to be practical. It's because the choices are generally already made by the feature being requested. There just are only so many ways to implement the new popular features.
The tools you list are fine for what they do, but they already work for what they were designed for. Dragon has always been an undeveloped application and works quite well with large blocks of text. Other than news sites, large text blocks are not desired in today's web apps. It's about graphics and embedded pieces. It's not that developers dont' consider all of the choices, because they don't. There are too many things to consider for that to be practical. It's because the choices are generally already made by the feature being requested. There just are only so many ways to implement the new popular features.
but from the other side of the coin. "Dragon... works quite well with large blocks of text"? Dragon is not designed for text-to-voice, it is designed for voice-to-text, allowing persons with accessibility issues to manipulate not just text but a variety of other applications using voice commands rather than mouse or keyboard. It also allows persons without accessibility issues to up their productivity in the same areas.
A person using Dragon to access and manipulate web pages in a browser still gets all the benefits (?) of such things as Flash inserts, etc. The central question of usability as it relates to design is not whether these things are a help or a hindrance to a user, but whether they are built into the application in such a way that one user can manipulate them with the same ease as any other person. We assume that there is some tangible benefit to having certain features built into an application (there's a whole 'nother discussion to be had if they are just there for 'bells and whistles'...), and that benefit has to be potentially the same for all users. That's the designer's task.
A person using Dragon to access and manipulate web pages in a browser still gets all the benefits (?) of such things as Flash inserts, etc. The central question of usability as it relates to design is not whether these things are a help or a hindrance to a user, but whether they are built into the application in such a way that one user can manipulate them with the same ease as any other person. We assume that there is some tangible benefit to having certain features built into an application (there's a whole 'nother discussion to be had if they are just there for 'bells and whistles'...), and that benefit has to be potentially the same for all users. That's the designer's task.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle

































