Se muestran los artículos pertenecientes a Junio de 2008.
Cadius Pamplona de Junio
Más vale tarde que nunca, y es que esta misma tarde se celebra el Cocktail Cadius de Junio en Pamplona. Hay novedades, como la nueva localización y que será el último antes de San Fermín. Además hablaremos sobre la más que segura colaboración con NavarraDotNet para organizar un evento de Experiencia de Usuario a cargo de Ilitia Labs basado en las últimas herramientas de desarrollo de Microsoft.
Los datos para hoy son:
- Día: 5 de junio de 2008
- Hora: 19.30
- Lugar: Bar Central, Plaza Yamaguchi
¡Nos vemos allí!
Librería de Stencils Yahoo! (Visio, OmniGraffle, PNG,...)
Gracias al blog de Yusef Hassan, he llegado a este repositorio de stencils de Yahoo para prototipado. Muy completo, se puede descargar para varias aplicaciones y en distintos formatos: Visio, OmniGraffle, PDF, PNG y SVG.
Lo veo realmente útil ya que incluye elementos muy actuales como carruseles de imágenes, pantallas de móvil, elementos de interacción del iPhone, controles como sliders o sistemas de paginación.
Ya están los stencils puestos en mi Visio : )
CSS: Dobles clases
Ayer surgió una pequeña duda en curso sobre estándares web. Cómo se comportan los navegadores con etiquetas que tienen más de una clase.
Pues bien, si las clases están definidas en la CSS individualmente gana en todos los navegadores la última de la CSS o la que más peso tenga (como toda la vida). Sin embargo si usamos en la CSS definiciones dobles la cosa cambia. Como me explico muy mal, he creado el siguiente ejemplo:
<html>
<head>
<style>
.rojo.verde {background-color:red} /*doble clase con más peso que una clase simple*/
.verde {background-color:green} /*clase simple*/
</style>
</head>
<body>
<div class="rojo verde">
HOLA
</div>
</body>
</html>
Pues bien Firefox e IE7 el div tendrá fondo de color rojo (pesa más) mientras que IE6 lo pinta verde (en este caso) y lo pinta rojo en el caso de que la clase .verde estuviera por encima de la clase .rojo.verde, es decir IE6 no es capaz de interpretar una doble clase y sigue aplicando la última definida o la que más peso tenga para él. Así que ¡¡cuidado!!
Capire: Junio 2008
Ya está disponible una nueva edición de la revista Capire. La cual como siempre está llena de buenos e interesantes artículos:
- Antes de la usabilidad, dos claves: propósitos y destinatarios. Marcelo Garrido P. (Amable)
- Desarrollando proyectos de gobierno Electrónico. Oliver Bell (Microsoft Asia Pacific)
- Sugerencias para definir un menú de navegación. Jorge Garrido P. (Amable)
- La Arquitectura de Información y la web 3.0. Luca Rosati (Trovabilità)
- Anuncios Google: ¿Lo usamos como trampa para cazar clicks? Amir Yazdani-Pedram (Amable)
CSS: olvídate del * html para IE6
Se acabó que en tus hojas de estilo para Internet Explorer, sí, sí, esas que pones a través de comentarios condicionales, tires de sucios hacks para diferenciar entre IE7 y los anticuados Explorer que tantos quebraderos de cabeza nos producen (léase Internet Explorer 6 y anteriores).
Si hasta ahora bastaba con poner * html delante de nuestras clases, id’s o elementos en la CSS para saber que sólo las versiones previas al IE7 serían capaces de interpretarlo, ahora vamos a darle la vuelta de tuerca a esto y a usar algo para que sólo lo entiendan las versiones posteriores a IE6 (el 7 y el futuro IE8).
- #identificador[id]
- .clase[class]
Así, nos aseguramos que aquellos navegadores (léase los de siempre) que no interpreten los atributos [id] y [class] (o cualquier otro como [href], [alt], [title]) no apliquen la regla.
Ejemplo:
Style.css
- #header {background:red none;}
StyleIE.css
- #header {background:green none;} /*Internet Explorer 6 y anteriores*/
- #header[id] {background:red none;} /*Internet Explorer 7 y posteriores*/
Gracias a Kilian Valkhof
Fireworks como herramienta de prototipado
He leido en el blog de Jorge Correa su visión sobre el prototipado directamente en XHTML+CSS, pero sobre todo da una buena impresión sobre el prototipado en Fireworks y cómo es la herramienta perfecta para ello. Separando así Photoshop para retoque fotográfico, Illustrator/Freehand para vectores y Fireworks para todo lo demás. En su día además ya comenté que existen multitud de recursos disponibles para Fireworks, así que cada vez tenemos menos excusas para usarlo.
En mi caso no puedo ser muy objetivo respecto al uso de Fireworks porque para mí siempre ha sido la herramienta perfecta, me permite hacer todo lo que quiero sin las complejidades de otras herramientas de Adobe y con la sencillez que un "inculto" del diseño gráfico necesita.
Con Jorge comparto los miedos al prototipado en XHTML+CSS sobre todo porque lo estoy viviendo actualmente. Un cambio de requerimientos en papel puede suponer un par de minutos al igual que en Visio/Omnigraffle/Fireworks, pero en HTML puede suponer 2 minutos o 2 horas o 2 días, aunque este análisis requiere de más tiempo y de un post dedicado exclusivamente a ello
.
Migas de pan accesibles y JAWS
Ayer mantuvimos en el curso una animada conversación sobre cómo se deben maquetar unas migas de pan, si los separadores deben ir en código o por CSS y qué implicaciones tiene para los lectores de pantalla.
Como no conseguí encontrar ningún recurso claro por la red, realicé mis propias pruebas en casa con dos versiones de JAWS distintas una antigüa (versión 5) y la última de todas (versión 8).
Me cree una pequeña página en HTML con unas migas de pan como estas (se han sustituído los "<" por "[" para poder visualizarlo):
[ul>
[li>[span class="screen-readers">Usted está en:[/span>[a href="/" title="pagina principal">Inicio[/a>
[ul>
[li>[a href="/categoria" title="nombre de la categoria">Categoría[/a>
[ul>
[li>Artículo[/li>
[/ul>
[/li>
[/ul>
[/li>
[/ul>
En el curso todos coincidíamos en que semánticamente la mejor forma de representarlas era mediante listas y sublistas anidadas, puesto que al quitar la hoja de estilos es la única manera en la que siguen teniendo sentido. Pues bien, los resultados fueron:
JAWS 5: No lee los caracteres ">" (ni ningún otro como "|", "#" introducido en el HTML)
JAWS 8: Lee los caracteres ">"
De forma que JAWS 8 leería algo como: "lista de 2 subniveles con 2 enlaces. Nivel 1 enlace "Inicio" mayor que subnivel 1 enlace "Categoría" mayor que subnivel 2 "Artículo" se cierra subnivel 2, se cierra subnivel 1, se cierra lista".
Como conclusión: No tiene sentido que Inicio sea mayor que Categoría, aunque jerarquicamente esté por encima, y puesto que el lector de pantalla ya reconoce que las migas están ordenadas en niveles y subniveles, no haría falta introducir en código ningún elemento separador. Aunque se recomienda introducirlos por CSS como separadores visuales.
Prototipos en papel de Vimeo, Twitter, Flickr,...
En el blog deeplinking publicaron hace ya algún tiempo bocetos/prototipos en papel de algunas de las nuevas aplicaciones más importantes de la web como Twitter, Flickr Places o Vimeo, destaca en especial la enorme galería que los chicos de Vimeo tienen colgada en Flickr, así como la versión original de Twitter (stat.us)
Prototipado en papel:
Los prototipos de papel son una forma de crear una imagen palpable de lo que será una futura aplicación o sitio web. Su creación y manipulación es rápida y elástica y permite a los usuarios imaginarse lo que será la futura aplicación en funcionamiento sin interferencias de tipo:
Técnico: plataformas, utilización de elementos multimedia como Flash...
Gráfico: colores, maquetación , tipografía que en muchas ocasiones desvían el centro de la discusión hacia asuntos cuya importancia es muy relativa en el proceso inicial. Según el conocimiento del interlocutor con el promotor del proyecto web, nos podemos encontrar debatiendo sobre el tono de verde de una pantalla, (secundario), frente a lo principal: secciones, datos necesarios, utilización futura del producto. Como símil con la "vida real", como discutir acerca de la pintura de un coche, cuando ni siquiera sabemos cómo va a ser.
(Alzado. Prototipos de papel. 14-01-2003)
Prototipado en HTML
Comentaba el otro día el interesante post de jcorrea sobre el prototipado en papel aunque centrándome más en la parte del uso de Fireworks como herramienta de creación de wireframes. Pues hoy entro a valorar la parte del prototipado en HTML porque me ha tocado de lleno sufrir una de sus consecuencias.
Jorge hacía mención a un post de la gente de 37Signals, y está claro que aunque siempre tratemos de aprender de la experiencia de las grandes y más importantes empresas del mercado para mejorar profesionalemente, es mucho más importante ser capaces de sacar nuestras propias conclusiones a lo que leemos y aplicarlo a nuestro entorno profesional. Por eso la gente de 37Signals, quizás intentando conseguir cierta repercusión a través de la polémica, se hayan aventurado con este post del que nosotros tenemos que sacar algunas conclusiones. Aquí están las mías:
- Ellos no dicen que prescindan del prototipado en papel, sólo que pasan de este al HTML, saltando el paso del diseño en Photoshop. we usually go right from a quick paper sketch to HTML/CSS
- Esto no vale siempre, hay clientes que siguen prefiriendo el pantallazo de Photoshop, algo plano antes de pasar a algo más interactivo.
- Si no estamos seguros de acertar con la línea gráfica o el cliente no es de confianza, estamos obligados a no saltarnos ese paso. O tendremos mucho más trabajo.
- Una maqueta en HTML+CSS+Javascript es muy espectacular, al cliente le entra por los ojos rápidamente y nos puede ayudar a la hora de "vendérsela".
Como siempre que alguien me da a elegir entre más de dos opciones, la respuesta es "depende". No podemos aferrarnos siempre a lo mismo, en cada proyecto y con cada cliente deberemos ser capaces de dar solución a un problema de la manera más óptima. Tener el conocimiento de las diferentes formas de afrontar un proyecto nos proporcionará el estar preparados ante cualquier reto que se nos presente.
.