Las computadoras del 2001
En la película "2001: Odisea del Espacio" la computadora del futuro lejano (2001!) tiene un papel estelar.
Muestra qué altas estaban puestas las expectativas en 1968.
2001: A Space Odyssey (film)
http://en.wikipedia.org/wiki/2001_(film)
http://www.imdb.com/title/tt0062622/
2001: A Space Odyssey is a 1968 science fiction film directed by Stanley Kubrick and written by Kubrick and Arthur C. Clarke. The film deals with thematic elements of human evolution, technology, artificial intelligence, and extraterrestrial life, and is notable for its scientific realism, pioneering special effects, ambiguous and often surreal imagery, sound in place of traditional narrative techniques, and minimal use of dialogue.
HAL 9000, la computadora de la nave espacial Discovery One, toma control de la misión por que piensa que es demasiado importante para dejarla en manos humanas menos confiahles, y asesina a los tripulantes, todos menos uno.
Esa computadora, llamada HAL (casualmente las letras contiguas a I, B y M en el alfabeto) con pantallas planas cláramente rotuladas con la marca SONY, es la idea de lo que iban a ser las computadoras en ese futuro lejano, el año 2001.
En su momento dijeron: "Much was made by MGM's publicity department of the film's realism, claiming in a 1968 brochure that "Everything in 2001: A Space Odyssey can happen within the next three decades, and…most of the picture will happen by the beginning of the next millennium."
Acertaron en una cantidad de predicciones tecnol[ogicas pero, como se puede ver en la foto de arriba del protagonista en el interior de HAL, le erraron por mucho a lo que sería el tamaño de las computadoras.
En 1990 ya era notorio
"... the daily experience of using computers far too often is still fraught with difficulty, pain, and barriers ... "
"The lack of usability of software and the poor design of programs are the secret shame of the industry."
Mitchell Kapor en el Software Design Manifesto a 10 años de lanzada la PC.
The Sofware Design Manifesto
Kapor: "A Software Design Manifesto"
"There is a conspiracy of silence on this issue. It’s not splashed all over the front pages of the industry trade press, but we all know it’s true. Users are largely silent about this. There is no uproar, no outrage. Scratch the surface and you’ll find that people are embarrassed to say they find these devices hard to use. They think the fault is their own. So users learn a bare minimum to get by. They underuse the products we work so hard to make and so don’t help themselves or us as much as we would like. They’re afraid to try anything else. In sum, everyone I know (including me) feels the urge to throw that infuriating machine through the window at least once a week. (And now, thanks to recent advances in miniaturization, this is now possible.)"
"The lack of usability of software and the poor design of programs are the secret shame of the industry. Given a choice, no one would want it to be this way. What is to be done? Computing professionals themselves should take responsibility for creating a positive user experience. Perhaps the most important conceptual move to be taken is to recognize the critical role of design, as a counterpart to programming, in the creation of computer artifacts. And the most important social evolution within the computing professions would be to create a role for the software designer as a champion of the user experience."
Mitch Kapor bio
By capitalizing on the need for easy to use computer software and by becoming active in shaping public policies that affect acceptable use of computer systems, Mitch Kapor will go down in history as one of the more influential computer professionals of the 1980's and 90's.
Asignaturas pendientes
Word & cia. son básicamente lo mismo que cuando reemplazaron la máquina de escribir: nunca hubo un salto cuántico.
Por ejemplo no hay una forma práctica de crear colaborativamente una red de documentos.
El concepto de "documento"
Con las primeras PCs los usuarios iban de un lado al otro con "documentos" registrados en disquetes. Ahora los podemos mandar por email.
Pero hay algo que todavía persiste: el "documento" como unidad y como contenedor de solamente sí mismo.
Tendemos a hacer documentos completos, enormes a veces, por que no hay una manera simple de reusar cosas tan elementales como por ejemplo un glosario. ¿Cómo poner en un documento una referencia a un párrafo de otro? Se puede, aunque el procedimiento es incómodo, pero es frágil por que si el documento se envía entonces las referencias se pierden a menos que el receptor tenga toda la constelación de documentos y los haya almecenado de una manera que no está implícita pero es encesaria para que las referencias funcionen.
Aparece entonces otra aberración, el hecho de que todos los que están trabajando en relación con el documento deben tener copias individuales posiblemente en distintos niveles de desactualización. Y que sea tan dificultoso saber cuál ha sido la evolución del contenido.
MS Word (o cualquiera de los otros programas similares) es el mejor ejemplo de una aplicación que la gente sufre en vez de disfrutar. Hay muchos que aman el MSWord por que es lo que conocen, desde la infancia. Algo así como el síndrome de Estocolmo.
Colaboración
No hay un software efectivo para trabajar en proyectos distribuidos. No vale un repositorio compartido de documentos online, eso es patético, y podríamos haberlo tenido desde siempre.
Me refiero a una jerarquía de documentos, centralizada a nivel Empresa y también con repositorios menores para individuos. Donde no haya que hacer acciones especiales ("excise" según Alan Cooper) para trabajar. Simplemente trabajar, sin "abrir" y "cerrar" documentos.
Feature creep
MSWord es un ejemplo acabado de "feature creep", un defecto de diseño según el cual la acumulación de "features" aumenta el valor del producto final.
Los informáticos están acostumbrados a idear los programas en términos de funciones y componer esas funciones en la resolución de trabajos. A partir de esa configuración mental particular les parece que ofreciendo una paleta suficientemente abundante de funciones las personas normales van a poder actuar de manera similar.
La realidad es que a las personas que no son informáticos les resulta muy difícil pensar de esa manera y las aplicaciones diseñadas se esa manera requieren gran cantidad de soporte, formal o informal, para guiar a los que no tienen la configuración mental necesaria hacia la resolución de sus tareas.
Asignaturas pendientes
Feature creep
MSWord es un ejemplo acabado de "feature creep", un defecto de diseño según el cual la acumulación de "features" aumenta el valor del producto final.
Los informáticos están acostumbrados a idear los programas en términos de funciones y componer esas funciones en la resolución de trabajos. A partir de esa configuración mental particular les parece que ofreciendo una paleta suficientemente abundante de funciones las personas normales van a poder actuar de manera similar.
La realidad es que a las personas que no son informáticos les resulta muy difícil pensar de esa manera y las aplicaciones diseñadas se esa manera requieren gran cantidad de soporte, formal o informal, para guiar a los que no tienen la configuración mental necesaria hacia la resolución de sus tareas.
La disconformidad en el ambiente ...
Lo relevante del video anterior no es el video en sí sino la forma en que se propagó viralmente.
Por que interpreta la frustración de la gente por las promesas incumplidas de la TI.
Siempre pasa lo mismo
Cada vez que se anuncia una nueva tecnología parace que va a resolver todos los problemas de una manera fulminante.
Con el tiempo el alboroto se diluye y la nueva tecnología comienza a abrirse paso poco a poco, como son las evoluciones humanas. Por razones técnicas, económicas, poíticas y legales, y por la capacidad limitada de los humanos, los resultados no son inmediatos ni excelentes.
Pero el caso de las computadoras es especial, por que sus promesas fueron más grandes y su evolución más frustrante.
Esto último se debe a que frecuentemente hay anuncios, generalmente tecnológicos, que generan mucha cobertura de prensa pero finalmente no se reflejan rápidamente en resultados prácticos excepto tal vez en los juegos.
Por ejemplo la arquitectura de 32 bits ya estaba presente en los procesadores Intel 80386 sin embargo los sistemas operativos tardaron muchos años en aprovecharla. Algo similar para ahora con el salto a 64 bits, que se anunció hace años pero no se propagó sino lentamente
Kapor es uno más
El su Software Design Manifesto dice "In sum, everyone I know (including me) feels the urge to throw that infuriating machine through the window at least once a week".
Etc ...
Se puede seguir, hay abundancia de ejemplos pero tiempo escaso para enumerarlos.
Que cada uno identifique las aplicaciones que le molestan y emprenda su propia lucha.
--
--
No está resultando fácil
From the CHAOS Report:
| Resolution type | 1995 | 2001 | 2009 |
|---|---|---|---|
| Successful On time, on budget, fully functional |
16% | 28% | 32% |
| Challenged Late, over budget, and/or less than promised functionality |
53% | 49% | 44% |
| Failed Canceled or never used |
31% | 28% | 24% |
Standish "The CHAOS Report"
The Standish Group International, Inc. is a market research and advisory firm specializing in mission-critical software and electronic commerce.
They don´t say what CHAOS means, but it might be "Caring, Honesty, Accountability, Ownership, and Success.
From the 1995 Chaos Report:
| Resolution type | 1995 | 2001 | 2009 |
|---|---|---|---|
| Successful (On Time, On Budget, Fully Functional) | 16.2% | 28% | 32% |
| Challenged (Late, Over Budget, And/Or Less than Promised Functionality) | 52.7% | 49% | 44% |
| Failed (Canceled or never used) | 31.1% | 28% | 24% |
The most important aspect of the research is discovering why projects fail. To do this, The Standish Group surveyed IT executive managers for their opinions about why projects succeed. The three major reasons that a project will succeed are user involvement, executive management support, and a clear statement of requirements. There are other success criteria, but with these three elements in place, the chances of success are much greater. Without them, chance of failure increases dramatically.
CASE STUDY CONCLUSIONS
The study of each project included adding up success points on the "success potential" chart.
Project Challenged Factors % of Responses:
Opinions about why projects are impaired and ultimately cancelled ranked incomplete requirements and lack of user involvement at the top of the list.
| Failure Criteria | Points | |
|---|---|---|
| Lack of User Input | 13% | |
| Incomplete Requirements & Specifications | 12% | |
| Changing Requirements & Specifications | 12% | |
| Lack of Executive Support | 8% | |
| Technology Incompetence | 7% | |
| Lack of Resources | 6% | |
| Unrealistic Expectations | 6% | |
| Unclear Objectives | 5% | |
| Unrealistic Time Frames | 4% | |
| New Technology | 4% | |
| Other | 11% | 12% |
| 67% | 33% | |
Galorath analysis shows that about 21% of a large companies IT budget is wasted due to such issues.
Why Software Fails
We waste billions of dollars each year on entirely preventable mistakes
http://www.spectrum.ieee.org/computing/software/why-software-fails/0
About "Clear Business Objectives" by Standish
ROI ACTION: Review all of the requirements for a positive ROI impact. Eliminate requirements that add little or no value to the ROI.
Work on functions and features that have the highest gain first.
Constantly review where you stand with budget versus actual expenditures.
Replace features with more valuable ones if business needs change.
Look at all ongoing and planned projects; do the ones that add value and gain first.
Para quién hacemos el software?
 |
 |
El target
Desarrollamos para las computadoras? Error! El taget de los desarrollos de sistemas no son las computadoras sino la gente que va a usar el sistema.
Se llama "UCD" por "User-Centered Design". Es sintomático que se deba explicitar eso cuando debería estar implícito desde siempre.
Por razones históricas del tiempo cuando las computadoras eran muy costosas se priorizaba el uso de la máquina por sobre el tiempo de la gente, había razones de costo. Eso ya no es así, desde hace muchos años, pero la formación de los informáticos no ha cambiado.
Kapor on developers
"By training and inclination, people who develop programs haven’t been oriented to design issues. ... It is simply to say that the perspective and skills that are critical to good design are typically absent from the development process, or, if present, exist only in an underground fashion. ... We need to rethink the fundamentals of how software is made."
More Than Interface Design
"Software design is not the same as user interface design."
"The overall design of a program is to be clearly distinguished from the design of its user interface. If a user interface is designed after the fact, that is like designing an automobile's dashboard after the engine, chassis, and all other components and functions are specified. The separation of the user interface from the overall design process fundamentally disenfranchises designers at the expense of programmers and relegates them to the status of second-class citizens."
"The software designer is concerned primarily with the overall conception of the product. Dan Bricklin’s invention of the electronic spreadsheet is one of the crowning achievements of software design. It is the metaphor of the spreadsheet itself, its tableau of rows and columns with their precisely interrelated labels, numbers, and formulas—rather than the user interface of VisiCalc—for which he will be remembered. The look and feel of a product is but one part of its design."
Talento
Por más que se purifiquen los procesos, para hacer algo "outstanding" siempre es necesario una couta de talento.
Los tres modelos
- Modelo conceptual
- Modelo manifiesto
- Modelo de implementación
Los tres modelos
Cuando un usuario opera un sistema hay tres modelos en juego: conceptual, implementación y manifiesto.
La fricción entre el usuario y el sistema se deben a desajustes entre estos modelos.
El modelo conceptual es la definición semántica del sistema y se debe modelar en base al modelo mental, la idea que el usuario tiene sobre la semántica del sistema.
El modelo manifiesto es básicamente la UI, la interfase que el sistema publica hacia el usuario. Para el usuario la interfase es el sistema.
El modelo de implementación es la forma en que el sistema está implementado en la computadora incluyendo las tecnologías participantes, y en principio no produce fricción, el implementador es libre de hacer la implementación que más le conviene y eventualmente de cambiarla sin alterar el modelo manifiesto.
Un típico defecto de diseño que suelen cometer los informáticos es "publicar el modelo de implementación", es decir, diseñar el modelo manifiesto a aprtir del modelo de implementación. Por ejemplo si el modelo de implementacíon tiene uan abse de datos con tablas para representar diversas entidades, el modelo manifiesto ofrece una interfase para actualizar cada una de las tablas participantes.
La fricción
La fricción se produce cuando el modelo manifiesto no acopla bien con el modelo mental del usuario, o sea cuando el modelo conceptual es defectuoso.
El usuario trata de hacer funcioar el sistema según sus conocimientos históricos pero el sistema se niega a reaccionar adecuadamente por que espera otras acciones. Al usuario le parece que el sistema "no anda", "no entiende", o "es incomprensible". Pocos usuarios investigan hasta hallar la manera de hacer funcionar el sistema y ganan prestigio, más prestigio cuanto más ininteligible era el sistema. En diseñador del sistema no pierde prestigio, posiblemente su empresa gana mucho dinero vendiendo soporte técnico.
Cuando el soporte técnico no se puede cobrar entonces se convierte en un costo recurrente. Un costo que se habría ahorrado diseñando el modelo manifiesto en sintonía con el modelo mental de los usuarios.
Hay más costos. Al soporte técnico se suna la pérdida de ventas por propaganda negativa de los usuarios: "para usarlo tenés que saber muchísimo!". Si el sistema es para uso interno entonces el costo adicional es el salario del personal involucrado por la cantidad de tiempo adicional requerido para operar una UI más ininteligible, tanto del operador como del emplado amigo que está tratando de ayudarlo.
Gmail
La aparición de Gmail en el mercado hizo que cambiáramos el modelo conceptual de las dos clases de email: en nuestra PC en casa o en la web. Ahora tenemos solo email.
Casos de uso
Expresan la funcionalidad del sistema.
Son el puente entre dos culturas, la de los informáticos y la de los usuarios.
Casos de uso
La escritura de casos de uso es posiblemente la actividad de desarrollo que más impacto tiene en el producto final.
Es la bisagra entre los dos mundos, el de la gente de TI y el del resto de las personas.
Los casos de uso no deben ser escritos como documentación para expertos de la TI. Se debe usar el lenguaje del dominio, de modo que los puedan estudiar y discutor los usuarios.
Deben relevarse especialmente en el nivel de los usuarios que hacen las tareas, no solamente en el nivel genrecial. Y estos usuarios deben ser un factor significativo en la aprobación de la funcionalidad que los casos de uso espresan.
El relevamiento en los niveles de management expresa qué es lo que se quiere lograr como un objetivo más global, mientras que el relevamiento en los niveles operativos expresa cómo se hacen las cosas, que es el objetivo de los casos de uso.
El libro de Alistair Cockburn
Writing Effective Use Cases"Alistair Cockburn's Writing Effective Use Cases is an approachable, informative, and very intelligent treatment of an essential topic of software design. "Use cases" describe how "actors" interact with computer systems and are essential to software-modeling requirements. For anyone who designs software, this title offers some real insight into writing use cases that are clear and correct and lead to better and less costly software."
"The focus of this text is on use cases that are written, as opposed to modeled in UML. This book may change your mind about the advantages of writing step-by-step descriptions of the way users (or actors) interact with systems. Besides being an exceptionally clear writer, the author has plenty to say about what works and what doesn't when it comes to creating use cases. There are several standout bits of expertise on display here, including excellent techniques for finding the right "scope" for use cases. (The book uses a color scheme in which blue indicates a sea-level use case that's just right, while higher-level use cases are white, and overly detailed ones are indigo. Cockburn also provides notational symbols to document these levels of detail within a design.)"