Archive for the ‘Codeando’ category

¿Bueno, y por qué (para qué) Safari para Windows?

junio 12, 2007

Cuando le conté a mi socia-diseñadora que Apple había decidido sacar una versión para Windows de Safari, su conocido navegador para la Internet, se le abrieron (aún mas :-)) los ojos de la emoción.

Es entendible, como buena diseñadora grafica (mi buen amigo Nex también es un ejemplo) ama los productos Apple.

Yo también soy un fiel seguidor. Me gusta la mística que rodea los productos y que les da esa aura especial que los fabricantes de productos para PC envidian. Siendo sinceros, ¡todos los que trabajamos en el campo de las TI envidiamos la gigantesca labor que hizo Apple para evangelizar a sus clientes! ¡¿Cuándo una empresa de tamaño mediano ha tenido tanto despliegue mediático?!

Volviendo al tema y para responderle la pregunta a Lite, la razón por la cual lanzaron la versión Windows del Safari se encuentra en el dispositivo que será lanzado a finales de este mes: El iPhone.

En torno a la presentación que hizo Steve Jobs en la conferencia para desarrolladores que organiza Apple (WWDC 2007) se habían tejido muchísimos rumores: El lanzamiento de una nueva serie de iMacs, actualizaciones de hardware para los existentes, un disco duro flash, etc. Pero hubo dos rumores que me llamaron la atención: Una posible alianza entre Apple y Google y el lanzamiento de un SDK para el iPhone.

De la alianza con Google todo quedó en un rumor, es mas, no deja de ser curioso que el sitio web que acompaña a la presentación del Safari para Windows sea Yahoo!.

El SDK o Software Development Kit es una serie de herramientas que permiten a los desarrolladores crear aplicaciones para un dispositivo o un software específico.

Entre las mas conocidas se pueden encontrar las creadas por las empresas productoras de juegos electrónicos (recuerdo que con don Cavorite nos entretuvimos por mucho tiempo con un SDK para Doom).

El caso es que muchos esperaban que Apple dispusiera de una serie de herramientas que permitieran a las personas crear sus propias aplicaciones para ser instaladas en el iPhone, lo cual tiene mucho sentido, pues el iPhone es mas un pequeño computador portátil que un simple teléfono con reproductor de MP3.

Pero no… esta vez don Steve Jobs desilusionó a mas de uno, pues aunque será posible escribir aplicaciones para el iPhone, éstas no se harán desde un SDK sino a través de Safari, el navegador web de Apple (que por cierto será el único navegador disponible en el iPhone).

¿Que quiere decir esto? Pues que si eres un desarrollador web podrás hacer una aplicación para que se ejecute a través del navegador, pero no instalarla de forma independiente en el iPhone (como ocurre con miles de aplicaciones disponibles para los teléfonos celulares).

Safari en tu escritorio se convertiría entonces en tu herramienta de trabajo para probar tus creaciones. Creo que la idea es buena, pero me molesta que Apple se cierre tanto y solo brinde unas reglas con muy pocas posibilidades para jugar.

Pero bueno, los desarrolladores web no son los únicos beneficiarios del Safari. Hay muchos gomosos que quieren sentir que es tener una aplicación hecha por Apple en su computador de escritorio y esta es una buena forma de hacerlo.

Dudo mucho que el Safari le arrebate al Firefox su 15% de participación en el mercado. ¿Para qué tener un navegador descafeinado si con el Firefox y sus plugins tengo todo lo que podría necesitar?

Que me corrijan los maqueros, pero hasta donde tengo entendido no hay plugins para el Safari. El Safari también tiene plugins, don Vik me mostro este sitio que se ve muy interesante.

No mencionemos la seguridad, pues aunque limitará los famosos Active-x que tan vulnerable vuelven al Internet Explorer, desde su lanzamiento, como muy bien anota Dux ya se encontraron fallas.

Creo por lo tanto que el Safari se volvería en la muestra gratis de Apple para los usuarios PC, para hacerlos sentir un poco “diferentes” y usar un navegador de apariencia sencilla y con una supuesta mejor velocidad que el Internet Explorer.

Claro esta, cuando hagan una buena versión y no ese remedo de navegador que presentaron al mundo esta semana.

Anuncios

Nos reservamos el derecho de admisión

febrero 12, 2007

Reconozcámoslo. A todos nos hiere en lo mas profundo de nuestro orgullo cuando el portero de un bar nos dice que no nos deja entrar por aquello de tratarse de una fiesta privada. Todos lo hemos padecido. Recuerdo mucho que una vez no me dejaron entrar “al bar de moda” porque usaba unos tenis. ¡Obviamente nunca jamas volví a ese lugar!

Cuando un amigo me hacía una consulta sobre los objetivos que debe tener una tienda en línea, le dije que el primero era que hiciera que sus clientes se sientieran tan bien atendidos como cuando van a su almacén.

Hoy entré de nuevo a Walmart Video Downloads y me encuentré con esta advertencia:

Clic para ampliar

Mas o menos nos dicen que el sitio sólo funciona con Internet Explorer 6.0 por lo que me invitan a descargarlo del sitio web de Microsoft…. Es decir, Walmart se reserva el derecho de admisión y yo que vine con mi Firefox 2.0 puesto, debo cambiármelo por un Internet Explorer 6.0 para entrar a la tienda….

¡Qué lastima! Walmart se fué por el camino mas fácil en vez de poner a su equipo de desarrollo a trabajar un poco mas haciendo que su aplicación funcionase como debería ser.

Me sentí de nuevo por allá en la prehistoria, donde algunos sitios incluían la advertencia de “solo funciona con internet explorer a una resolucion de 800×600 o superior”.

Auch!

febrero 6, 2007

Me agrada cuando veo que un sitio web “de los grandes” empieza a hacer las cosas bien usando correctamente el html y los css, pero definitivamente, este no es un buen ejemplo:

Gazapo en Wallmart Video

No sé si la gente que hizo el sitio de Walmart Video downloads sabe que hay mas navegadores diferentes al Internet Explorer… el caso es que, de los errores o problemas en la correcta visualización entre navegadores, ¡éste es el mas garrafal de todos!

p.d. El modo beta (tan común en estos días) no debe ser pretexto para semejantes adefesios.

p.d. Les propongo una apuesta… ¿Cuánto se demorarán en corregirlo?

Cambiar

diciembre 25, 2006

La semana anterior trabajamos dejando todo al pelo para la salida en producción de una herramienta de software que instalamos en una de las empresas prestadoras de servicios públicos mas grandes del país (el nombre no importa porque tal vez algunos de mis lectores ya saben de qué hablo).

En este artículo no voy a hablar sobre las tecnologías empleadas o el diseño del producto. Quiero hablar sobre un factor que en muchas ocasiones, aquellos que nos aventuramos en el negocio del desarrollo de software olvidamos: El miedo al cambio.

Independientemente de la herramienta que vas a instalar, de las capacidades de los futuros usuarios, incluso, de la necesidad misma que se busca cubrir, siempre, siempre en gran o en menor medida encontraremos una resistencia al cambio.

Pensándolo bien, esta resistencia no sólo la encontramos en nuestros usuarios: En muchísimas ocasiones somos nosotros mismos quienes buscamos todos los peros posibles para seguir usando o trabajando sobre lo viejo y conocido en vez de tomar lo nuevo e incierto.

La verdad, no creo en eso de “mas vale viejo conocido que bueno por conocer”. Ejemplos sobran y creo que todos los tenemos. ¿Porqué entonoces, siempre encontramos peros y razones para no hacer la transición a lo nuevo?.

Creo que el miedo al cambio es un estado natural del hombre. Nos gusta repetir lo que ya aprendimos, nos gusta hacer lo que siempre hacemos. ¿Porqué? Creo que la respuesta está en la comodidad. Si ya sabemos hacer algo, ¿Para qué cambiar? ¿Aprender de nuevo? ¿Arrancar desde cero? Noooo que jartera.

Si no me creen, recuerden sus días de estudiante y díganme si es mentira que todos “escrituramos” un puesto que defendimos durante todo el semestre. A mi me gustaba la esquina izquierda, al frente del pupitre del profesor. No sólo porque podía ver todo mas claro, sino también porque en muchas ocasiones ese era el mejor punto para recibir una buena señal de la wlan instalada en la universidad.

Amamos las rutinas, odiamos los cambios intempestivos. ¿Quién no se molesta que por alguna razón la ruta a nuestro trabajo sea otra? ¿Quién no ha sentido extraño durmiendo en un lugar diferente? Intenten cambiar la rutina que siguen todas las mañanas… nos sentiremos completamente inseguros. Parece que tenemos un checklist en el cerebro que nos brinda la seguridad necesaria para hacer todo:

  1. Tomar los periódicos del dia: Listo.
  2. Ir a la cocina: Listo.
  3. Abrir la nevera: Listo.
  4. Tomar el yogourt: Listo.
  5. Tomar el cereal: Listo.
  6. Calentar el pan: Listo.
  7. Sentarse a leer: Listo.
  8. Desayunar: En progreso.

Y si por alguna razón nos toca llevar un orden distinto todo se despelota… ¡Listo! a algunos nos va a pegar mas duro que a otros, pero todos vamos a sentir en gran o menor medida el cambio en nuestras amadas rutinas.

Volviendo al cuento del software, creo que esta condicion sicológica se convierte entonces en un factor determinante en el éxito de una implantación. El planteamiento es muy sencillo, si el software no se usa no sirve. Así tenga el mejor código en sus entrañas, la mejor GUI con las mejores prácticas de accesibilidad, si no se usa, es como si no se hubiera hecho nada.
De nada sirve que le digamos al gerente que tiene “el estado del arte” en sus manos, si los usuarios del sistema no emplean una herramienta como debería hacerse, creo que nuestro trabajo estará destinado al fracaso.

Pero bueno… ¿Qué se puede hacer? Me atrevo entonces, a presentar una serie de claves para que el proceso de resistencia natural al cambio sea mas llevadero.

  1. Identifica y trabaja con los lideres. Las labores de presentación, validación y capacitación no deben estar concentradas exclusivamente en los que dentro de la estructura del proyecto llevan el título de “lideres funcionales”. Busca identificar entre los usuarios de un sistema a las personas que sobresalen entre los demás. No solo es posible que tengan una gran experiencia acumulada, sino también que, si cuentas con el apoyo de ellos en la implatanción del software, será mas fácil que los demás usuarios también te apoyen, pues seguirán el ejemplo de sus líderes naturales.
  2. Nunca menosprecies la experiencia. Por encima de todo, las personas saben de procedimientos no de herramientas. Es muy probable que el operario experto en el software que será cambiado pueda convertirse en el mejor usuario de las nuevas herramientas. Busca su opinión. Ellos viven día a día los procedimientos y de seguro podrán hacerte valiosas sugerencias para lograr un mejor ajuste de tu herramienta. Te darás cuenta que los lideres funcionales en muchas ocasiones ignoran algunos puntos simplemente porque no usan diariamente las herramientas.
  3. Vende los beneficios. A casi todos los usuarios no les interesa el motor de tu base de datos, el lenguaje de programación o el doctype que empleaste. Si tu herramienta mejora tangiblemente los procesos, reduce los tiempos que toma una transaccion o permite realizar mejor una acción, has logrado darle peso al mejor argumento de ventas: Ahorro de tiempo. Tiempo que los usuarios no van a desperdiciar, tiempo que se traduce en beneficios y en tiempo libre. Ese es el mejor argumento. Si tu producto permite realizar una acción de una forma eficiente y mas rápido, lo lograste. Ahora sólo es vender la idea.
  4. ¡Prueba y prueba! Un error en una presentación o en la semana de salida en producción puede destruir semanas de trabajo buscando la aceptación de tu herramienta.
  5. Paciencia. Por ser el último de mis consejos no es el menos importante. Siempre nos encontraremos con un usuario inconforme, molesto y en muchas ocasiones un poco agrio. No lo anules ni lo menosprecies. Es muy probable que en medio de tanta corrosión encuentres la razón de su comportamiento: Tal vez es la persona mas insegura para cambiar. Escucha sus razones, sus temores y sus deseos. Estoy seguro que encontrarás las claves para que tu software sea mejor.

Introducción al xhtml y css

octubre 1, 2006

A modo de memorias de la charla que di el viernes 29 de septiembre en el marco de la Semana del Conocimiento en ParqueSoft, les presento los documentos que usé de base para la misma: