Fuente: tweet de Fierita Catalano

Fuente: So you need a typeface?

• Multitasking!, finalmente vamos a poder tener varias aplicaciones abiertas al mismo tiempo. Para ello, y según Apple para minimizar el gasto de la batería, se desarrollaron varias API para cumplir con la mayoría de los requisitos de las aplicaciones que se ejecutarían en background, entre ellas destacamos “background audio”, “VoIP”, “background location” y “Fast app switching” (esta última guarda el estado de la aplicación, la deja de correr y cuando volvemos a ella restaura dicho estado). Para acceder a la “barra de aplicaciones” que se están ejecutando, basta con hacer doble clic en el botón de inicio del iPhone/iPod/iPad, desde cualquier aplicación.
• Carpetas y más aplicaciones, se elevó a 2160 la cantidad de aplicaciones que podemos tener en nuestro dispositivo y, para hacer frente a esa maraña, la posibilidad de ordenarlas en carpetas.
• iAd, Apple entendió el negocio de la publicidad en móviles y lanzó su propia plataforma de anuncios para hacerle la contra a AdMob. La característica principal es que se pretende que los anuncios sean interactivos (no un simple banner que te redirige a un sitio, cerrando la aplicación), y estarían hechos con HTML5 (nada de Flash!). En teoría, compartirían el 60% de los ingresos con los desarrolladores.

Algunos comentarios más sobre la presentación del iPhone OS4:

• Nada de Flash, Steve Jobs volvió a criticar a la aplicación de Adobe como poco eficiente. Lo que habría que analizar, objetivamente, es si Flash es realmente malo o si las aplicaciones realizadas en dicha plataforma están mal hechas. Pero Apple ya tomó una desición.
• En los nuevos términos y condiciones se prohiben aplicaciones desarrolladas con Flash y luego compiladas para el iPhone. Esto es un fuerte golpe para Adobe, que en pocos días lanza su suite CS5, con la funcionalidad de desarrollar aplicaciones para estos dispositivos. Lo mismo pasa con otros programas que cumplían la misma función.
• Esta actualización del sistema operativo estará habilitada sólo para el iPhone 3GS y el iPod tercera generación. Tal vez versiones más antiguas no se banquen los nuevos requerimientos de hardware (o Apple quiere que compremos nuevos dispositivos…)
• Muchas de las características incorporadas en el nuevo OS representan un ataque directo a Android, que disponía de multitasking hace tiempo; y a Google, que está comprando AdMob, la principal plataforma publicitaria para móviles.

Sería como un tapón de clonar con esteroides, pero muchísimo mejor. Para tener una mejor idea, vean las siguientes imágenes:

Y les dejo el vídeo donde muestran las bondades de esta nueva característica:

UPDATE: en blog de Fabio me entero que esta funcionalidad ya estaba disponible como plugin para GIMP, que es la alternativa open-source para retoque fotográfico. Así que al final no era taaan novedoso.

Fuente: FastCompany vía ALT1040

En la madrugada de hoy (Miércoles 24, feriado en Argentina), hackers han logrado ingresar a la base de usuarios de Geelbe, y se han robado (según ellos dicen) alrededor de 70.000 usernames y contraseñas de sus usuarios.

Han publicado, en un blog, los datos de acceso de 461 usuarios, pero nada garantiza que no publiquen los datos de los restantes usuarios. Por el momento, la gente de Geelbe está aconsejando a todos sus usuarios que cambien las contraseñas de otros servicios en donde utilizaban la misma clave.

Dejando de lado el cómo accedieron a la base de datos, lo importante es que todas las contraseñas estaban encriptadas codificadas en base64, es decir, convertidas en una cadena de texto totalmente reversible. Esto es una pesadilla de seguridad, y nos indica el poco cuidado puesto por parte de este sitio “exclusivo y privado” en resguardar la información de sus usuarios. Afortunadamente, como todo lo relacionado al pago lo manejan a través de otra empresa (NPS-Sub1), los datos de tarjetas de crédito nunca se vieron comprometidos.

Para los usuarios, ¿cómo saber si sus contraseñas están siendo almacenadas de manera segura? Si cuando piden recuperar la contraseña, les envían la contraseña original: ALERTA! Significa que están guardando la clave en algún formato que se puede recuperar. Lo ideal es que les envíen una nueva password, generada al azar. Esto sería un indicio de que la contraseña almacenada no se puede recuperar (aunque tal vez la sigan guardando en un formato no seguro).

Son capítulos cortos.

Creo que están perfectamente logrados. Son 50 total, entre Delicious, Twitter, Facebook, Digg, Posterous, Flickr…

Link: http://icondock.com/free/vector-social-media-icons

Hay dos tipos de validación:

1. Validar que la tarjeta de crédito pertenezca a la marca indicada:

Con los primeros dígitos de la tarjeta, podemos identificar su marca. Las principales:

• Visa: comienzan en 4
• Mastercard: comienzan en 51 a 55
• American Express: comienzan en 34 ó 37

2. Validar que el número de la tarjeta sea correcto

Los números de las tarjetas se generan con un algoritmo, llamado Luhn Formula Mod 10. Para que la tarjeta sea válida, el resultado de la formula debe ser un número de dos dígitos divisible por 10. Aquí la explicación formal del algoritmo: http://www.beachnet.com/~hstiles/cardtype.html

¿Para qué sirve esto? Sencillo, puedes evitar que el cliente ingrese mal los datos de su tarjeta, y si la operación se realiza online con algún gateway de pagos, evitar malgastar transacciones con las tarjetas de crédito.

Básicamente, podemos acceder a distinta información de distintos sitios (mayormente redes sociales pero cualquiera se puede agregar) de una manera unificada. De esa forma, no debemos aprender las características de cada API de cada sitio, sólo basta saber interactuar con YQL.

Por ejemplo, podemos extraer y manipular información de Twitter, Facebook, Flickr, WordPress, etc…

Recomiendo que lo lean: An API for the Web: Learning YQL

Es interesante como (casi) todos terminan entiendiendo que un sitio Flash no es la solución, y aceptan que desconocían las desventajas de hacerlo de esa manera y las distintas alternativas que existen al momento de desarrollar un sitio web.

Es por ello, a servicio tanto de clientes como de desarrolladores web, creé esta lista de “Porqué no se debería utilizar Flash para diseñar un sitio web”.

Atenta contra usabilidad del sitio.

Tal vez esta sea una de las mayores contras de utilizar Flash.

Cuando estamos navegando un sitio web realizado en (x)HTML y llegamos a una página que no nos interesa, simplemente pulsamos el botón “Atrás” de nuestro navegador y volvemos al contenido anterior. Lo mismo sucede con la dirección URL de la misma: si es de nuestro interés, podemos agregarla a nuestros favoritos o enviarla por mail a un amigo.

En estos casos, usabilidad sería poder utilizar las herramientas que nos brinda el explorador para hacer de nuestra de navegación una experiencia agradable.

Bueno, olvídensen de poder realizar esto con Flash, ya que (en la mayoría de los casos) toda la navegación se realiza dentro de un mismo archivo SWF. Entonces, cuando hacemos clic en “Atrás”, en realidad no estamos yendo al contenido Flash anterior, sino a la URL anterior. De esta manera, se pierde toda posibildad de poder referenciar a un contenido en particular dentro del sitio.

No es leído por los robots de los buscadores. La exposición del sitio en buscadores es pobre.

Si bien es cierto que se han realizado avances en materia de lectura e indexación de archivos SWF por parte de los robots de los buscadores, dichos avances nunca podrán asimilar la capacidad semántica que podemos brindar con (x)HTML.

En el código (x)HTML, utilizamos distintos tags para indicar (a los buscadores, al navegador y al usuario) qué contenidos son importantes, cuáles relevantes, qué hace referencia a otros sitios, qué es una imagen, qué es un título, etc. Con la próxima llegada del HTML5, esto se potencia aún más.

Bueno, esto no se puede realizar con Flash. Debido a que es un código cerrado y carece de semántica, los robots de los buscadores no pueden interpretar el contenido del sitio con la riqueza que lo harían con los (x)HTML.

Esto se traduce a que el sitio en Flash rankeará (dejando de lado otras variables) peor que su gemelo realizado en HTML, generando un volumen menor de visitas.

Si a esto le sumamos que otros sitios de Internet no podrán referenciar directamente a contenidos que están dentro del archivo SWF (no los podrán linkear, ver punto sobre la usabilidad), la posibilidad del sitio en Flash de lograr un buen posicionamiento es mucho menor.

Es un software propietario

Otra desventaja de utilizar Flash es que no es un software de código abierto, tales como (x)HTML, CSS y JavaScript. Para generar un archivo SWF (el Flash que finalmente veremos en nuestro navegador) debemos utilizar, en la mayoría de los casos, el software Adobe Flash. El archivo SWF generado es inmodificable, para realizar cambios debemos contar con el archivo FLA original. Muchas veces, éstos quedan en el poder de los diseñadores, y muchas otras veces se terminan perdiendo (ya que no es necesario subirlos con el sitio, y luego desaparecen con alguna formateada).

En cambio, con (x)HTML, CSS y JavaScript no precisamos de ningún programa (si nos damos maña, podemos resolver todo con un Notepad), y todos los archivos son modificables. Esto implica que es más sencillo realizar mantenimiento del código, actualizaciones, etc.

Además, con Flash estamos obligando al usuario a tener instalado el Plugin necesario para reproducir este tipo de archivos. Esto no sucede con (x)HTML, Javascript y CSS, que son nativos en cualquier navegador.

Requiere mayores tiempos de carga y el usuario debe instalar un plugin

Otra desventaja más es que los archivos SWF son más pesados que sus primos (x)HTML (con imágenes y todo). Esto implica que el usuario tiene que esperar hasta que la película SWF se termine de descargar para poder visualizar el sitio, y es bien sabido que “tiempo de atención” no es algo que sobre en Internet.

Los usuarios abren, cierran y visualizan páginas de Internet en segundos. Hay millones de sitios dando vuelta. Si el usuario ve que tiene que esperar más de 10 segundos para poder visualizar un contenido, lo más probable es que abandone dicho sitio y se vaya al sitio de la competencia (que no está a una cuadra de distancia, está a solo un clic de distancia).

La atención y el tiempo disponible son muy fugaces. Entonces, ¿por qué abusar de la paciencia del usuario? Si queremos captar su atención e interés (AIDA, para los publicistas), ¿es una buena estrategia que tenga que esperar para ver el contenido?

Además, no nos olvidemos que, para poder visualizar un archivo SWF, el usuario debe tener instalado y actualizado el Flash Player (para cada navegador que utilice). Es decir, otra molestia más.

Muchas animaciones se pueden lograr sin problemas con (x)HTML, CSS y Javascript

Por último, muchos de los motivos utilizados por los diseñadores Flash es que con (x)HTML, CSS y JavaScript no se pueden realizar animaciones.

Puede que haya sido cierto hace un par de años: las páginas web eran muy estáticas y la única forma de mover el elemento “X” de A a B era con Flash. Actualmente, se han realizado muchos avances con JavaScript y se han escrito muchas librerías (jQuery, MooTools, etc) de código abierto que permiten hacer maravillas con (x)HTML.

La mayoría de las animaciones que hoy vemos en sitios Flash se pueden realizar sin problemas, con menor carga y de manera más eficiente, con (x)HTML, Javascript y CSS. Además, con la próxima introducción de HTML5 y CSS3, las posibilidad se extienden mucho más.

Así que ya saben, si un diseñador les ofrece como única alternativa un sitio en Flash, ¡cuidado! Es muy probable que dicha persona no se haya podido actualizar y desconozca las ventajas de realizar el sitio con (x)HTML, CSS y Javascript.

Extraído de ElBlazer

Una empresa de hosting con la que colaboro, tiene incompleta la sección de ayuda del sitio web. Les pregunté porqué no la completan, se podrían ahorrar muchas horas de soporte. La respuesta fue: “Por más que la completemos la gente no la va a leer y va a terminar llamando igual”.

OK, es verdad que los usuarios no son muy “amistosos” con la idea de leer. El tiempo en Internet es veloz, tenemos mucha información para leer y procesar, y no dan los tiempos para ponerse a interpretar un extenso archivo sobre cómo configurar el mail, si hay un número de teléfono al cuál llamar.

Pero mi pregunta es: ¿la gente realmente no lee, o estamos haciendo las cosas mal?

Por ejemplo, los clientes de esta empresa de hosting reciben, al momento de darse de alta, un detalladísimo mail con todas las configuraciones que precisan. Si leyeran detenidamente eso, prácticamente podrían prescindir del servico técnico de la empresa. Pero dicho e-mail tiene varios errores:

• No tiene diseño, es casi texto plano.
• No hay índices ni se explica, al principio del mail, que contenidos encontrarán en él
• No hay títulos visibles

El mundo de la publicidad nos ha enseñado valiosas lecciones sobre diseño y redacción si queremos captar la atención del target. ¿Por qué no las ponemos en práctica?

Eso, amigos, es parte de la usabilidad. La web es un soporte más, y como tal, hay ciertas reglas que no podemos obviar:

• KISS (keep it simple, stupid). Esto es infaltable. Lo quiero sencillo.
• Colores y diseños user-friendly. Lo quiero lindo.
• Índices o menúes de navegación y títulos explicativos. Lo quiero rápido.
• Información organizada de manera sencilla y entendible. Lo quiero sin complicaciones.

En otras palabras, creo que depende de nosotros motivar a los usuarios.

Como podemos observar, un desarrollador web en Argentina gana menos que sus pares de Perú, Venezuela, Colombia y Chile, entre otros.

Aquí la gráfica: http://www.cuantocobro.com/informe-sueldos.php?informe=pais&rubro=it-desarrollo-web&moneda=USD&x=18&y=18

Link: http://www.smashingbuzz.com/2009/12/50-most-creative-and-unusual-404-error-pages/

En Smashing Magazine, la gente de Zurb nos enseña a crear botones realmente muy bonitos con CSS3, sin JS ni trucos raros.

Botones con CSS3

Si bien no se verán tan “pretty” en IE, su funcionalidad será la misma y serán más atractivos que el “default” del sistema. Además, se complementa mejor con nuestro diseño! Y, ya sabemos que tan importantes son los botones: son el “call-to-action” de nuestras páginas.

Highlights más importantes:

• Darle un sutil degradé, lo recomendable es con una imagen (como background-image), pero más adelante podremos usar directamente los gradients de CSS3
• Texto grande, constrastado, con sombra (text-shadow)
• Sombra al botón con -moz-box-shadow ó -webkit-box-shadow (más adelante, podremos usar box-shadow directamente)
• Bordes al botón con border-radius

Artículo completo: http://www.smashingmagazine.com/2009/12/02/pushing-your-buttons-with-practical-css3/