Sergio Gago

Este es un tema en el que llevo pensando cierto tiempo, en parte gracias a Josep M., compañero de trabajo, con el que estoy haciendo ahora una muy productiva labor de arquitectura de la información y usabilidad en un proyecto.

¿Cómo ofrecer al usuario la posibilidad de elegir SU provincia con la máxima usabilidad? (Atención que hablo de su provincia)

Pues bien, a priori tenemos dos modelos básicos: La lista desplegable y el mapa, teniendo cada uno muchas variantes diferentes, y sus propios problemas y más. Estudiemos qué hacen algunos de los portales líderes en España (que se basan en la selección de provincia):

Idealista.com
Portal dedicado a la inmobiliaria. La navegación está basada en desplegables de 6 alturas, de forma que en los dos primeros solo tenemos que seleccionar el elemento buscado, y en el tercero, la provincia propiamente dicha, será donde tendremos que bajar hasta encontra el elemento buscado.

paginasamarillas.es
No hay mucho que decir. La provincia es un desplegable estándar de un solo nivel (más de 50 opciones), y una localida de campo libre.

fotocasa.es
Otro portal inmobiliario. Precisamente estos son los que más hincapié deben hacer en la localización geográfica. Optan por un modelo similar a idealista para las opciones (alquiler, compra…), pero se basan en un modelo de mapas para la localización de provincia. El resto de pantallas están basadas totalmente en mapas también, por localidad y zona (incluso barrio en ciudades grandes). La navegación del mapa es sensible y nos va indicando el nº de inmuebles encontrados).
loquo.com
Quizá uno de los portales de anuncios clasificados con más visitas. Utiliza (si no me equivoco) localización ip para redirigir al usuario a la ciudad adecuada, ya que en este caso son los anuncios los que están localizados geográficamente.
Aun así, como barra lateral nos ofrece todas las provincias donde existe loquo, por si algo ha fallado o simplemente quermos buscar en otro sitio.

infojobs.net
Portal líder de empleo en España. Aquí, lógicamente, la función de seleccionar la provincia donde quieres trabajar, es imprescindible. En este caso tenemos un desplegable de un solo nivel. (Luego veremos que también hay que valorar el espacio disponible).

atrea.com
Otro portal inmobiliario, del grupo BBVA, quizá menos conocido que idealista o fotocasa, pero que alexa no le trata nad mal. En este caso ofrecen las dos posibilidades: Tres listas desplegables de un solo nivel, que se autorrellenan con el anterior: País, provincia, y localidad. Y mapa que añade detalle en función de lo que vayamos seleccionando

enalquiler.com
En este portal ya asumimos que solo vamos a alquilar, de forma que los tres desplegables de 7 niveles son para el tipo de vivienda, la provincia y el precio. Eso si, los primeros elementos que muestran son los que más viviendas tienen. Tratando de simplificar el uso al mayor porcentaje de usuarios.

laboris.net
Otro portal de empleo que usa dos desplegables de un nivel tanto para provincia como para categoría.

niumba.com
Niumba es un portal de alquiler de viviendas para vacaciones, por lo que las zonas con las que trabajan están muy localizadas. De hecho, permiten buscar por provincia o por zona (costas sobre todo), pero al igual que atrea, permiten una búsqueda por desplegables de un nivel, o una selección por mapa, que contextualmente nos dice dónde estamos y qué oferta hay en ese punto.

segundamano.es
Portal de anuncios de intercambio propietaria del grupo anuntis. En la home no nos ofrecen ningún buscador, sino una lista enorme de categorías y subcategorías, y ya dentro de una de ellas podemos seleccionar la provincia en un desplegable de un nivel.
compraventa.com
Otro portal de anuncios de compra venta, en cuya home en lugar de pedirnos la categoría nos piden la localización, con mapa o con listado de todas las provincias. Está claro que se centran mucho más en el lugar que en la categoría de anuncio.

Estos son solo algunos ejemplos de portales que comen todos los días cantidaes ingentes de tráfico, pero sin duda hay muchos otros (que si queréis podéis dejar en los comentarios).
El primer problema que nos encontramos está en cómo clasificar este elemento. Si estuviéramos hablando de nuestro menú propiamente dicho, se puede concluir que las listas desplegables están hechas para formularios, y que se deben buscar otros elementos.

Pero tampoco estamos hablando de un elemento de formulario propiamente dicho (al estilo tradicional, se entiende). Estamos viendo un elemento que se nos muestra desde la home de nuestra página, y que de su utilización depende el resto de la navegación en el sitio, vamos, con una criticidad demasiado alta para ser obviada, sobre todo cuando hablamos de portales que venden ítems centrados geográficamente.

Entonces, tenemos que tener en cuenta los siguientes factores:

• Espacio disponible y criterios:
  ¿Con cuánto espacio contamos? ¿Cuántos elementos más tenemos en la página? ¿Será el único modo de navegación o el usuario puede elegir otros criterios de búsqueda? Si nuestra búsqueda es impepinablemente por localización, quizá necesite más peso.
  Es importante también el dónde lo vamos a colocar, y los criterios anteriores que le hemos hecho seleccionar. Por ejemplo, si tenemos que elegir un tipo de vivienda, una provincia, luego un precio y luego introducir un término para buscar, probablemente pocos usuarios introduzcan ningún término, porque después de seleccionar tres ítems, es más fácil darle a un botón que pensar en un término:La búsqueda más crítica, deberá tener el máximo espacio y estar situada en un “hotspot” de nuestra página. El usuario debe captar la criticidad del elemento. Si hay varios elementos de búsqueda, dividámoslos, fuera frustración!

• Usuarios target
  ¿Quién es nuestro público? ¿Gente que quiere vender en su barrio? ¿Gente que busca un piso en cualquier provincia de España? ¿El público conoce bien su geografía? ¿Qué nivel tienen de internet? En general, la gente es lenta tecleando y buscando, por lo que tenemos que simplificar y adelantarnos a sus pensamientos.Si tu público conoce bien el mapa, puedes ponérselo, será más fácil que encuentren algo en un elemento conocido donde ven todos los ítems a la vez, que estar buscando en una lista. recuerda: hay pocos usuarios que sepan que en una lista desplegable, si das a la “v” te irá directamente a “Valencia”.

• Accesibilidad: ¿Cómo se verá sin JS o sin imágenes?
  ¿Qué va a ocurrir a nivel de accesibilidad? ¿Cómo se quedará tu página si la desnudas y la dejas sin JS? ¿Y sin CSS? ¿Tus mapas son en flash?Si usas tecnologías no estándar, ofrece alternativas a la navegación (aunque menos visuales). Si usas mucho javascript, o ajax, también. Haz pruebas de navegación desactivando todo esto a ver cómo aparece. Acuérdate de los lectores de pantalla y de las versiones HTML plano.

• Dispersión de los datos
  ¿Estás en todos los sitios, pero mucho más en unos que en otros? Si el 90% de tus usuarios entran en tu portal para buscar jamones, pónselo en portada.Si Madrid y Barcelona ocupan el 95% de tus ofertas de trabajo, pónles un atajo. Es cierto que supone “menospreciar” a los usuarios de lugares con menos oferta, pero se trata de llegar a un acuerdo.

• Profundidad de los datos
  ¿Cuál es el nivel de selección? ¿Comunidad autónoma? ¿Provincia? ¿Localidad? ¿Otras? ¿Variadas? Este es un problema típico en las inmobiliarias. Si busco Valladolid, podríamos englobar, capital, y provincia, como mucho algunos pueblos grandes de alrededor. Sin embargo en Barcelona tiene sentido ver por separado la capital, del Vallès, Sitges, etc… ¿Hasta donde profundizaremos en nuestro mapa?En primera instancia, el usuario debe ser “universal”. No tiene sentido que un usuario que aún no nos ha dicho si es de Madrid o de Barcelona, pueda escoger Alcobendas. Según bajamos en la navegación podemos ir dándole más opciones, siempre con la opción de “todas las localidades”. Esto también depende de la dispersión de los datos. ¿Tenemos 500 inmuebles en Barcelona y 2 en Terrasa?

Para finalizar y concluir, me sigo quedando con los mapas, siempre, teniendo en cuenta los factores de arriba. Además, existe otro factor que he comentado y que también es muy importante: Nuestra Web debe ser homogénea. Las búsquedas de provincia deberán ser todas iguales.

¿Experiencias? ¿Opiniones?

Compartelo

Hoy navegando, he llegado por casualidad a la Web de una empresa de diseño Web, inicialmente muy parecida a las otras miles que hay por España. Pero cuando ha empezado a salir una sonrisa de mi boca ha sido cuando he llegado a su política de precios:

• 5 Pantallas destinadas a las diferentes necesidades de tu actividad o negocio, por ejemplo: Quienes Somos, Nuestros Servicios, Dónde Estamos, Solicita tu Presupuesto, etc.
  Con 5 basta, ni una más ni una menos.
• 1 Pantalla con un Formulario para que puedas recibir datos en tu E-mail (pedidos, información…).
  A sabe cómo está hecho el formulario… probablemente un “mailto:” en el action.
• 1 Pantalla para confirmación de envío del Formulario (siempre que tu servidor lo permita).
  Guau.. .tecnología punta
• 12 Fotografías que puedes distribuir en las 5 pantallas principales (facilitadas por ti).
  Ni una más ni una menos, no sea que tengamos que retocar más de lo debido en photoshop.
• Logotipo de tu empresa en cada pantalla (facilitado por ti).
  Por supuesto!
• 1 Diseño de pantalla estándar que puedes elegir entre los diferentes modelos que tenemos actualmente disponibles.

Y cuando dicen página estándar, dicen una colección de plantillazos sacados de variantes de template monster y derivados que aplican a varios clientes. Es más, peores derivados de template monster, porque ni siquiera cumplen estándares.

Precio: 250€, sin Iva, ni registro de dominio ni hosting.

Analizando un poco las webs generadas (estas cosas me fastidian más de lo debido, y le suelo dedicar algo de tiempo), vemos que:

• Están desarrolladas íntegramente con dreamweaver (vale, esto no es tan malo).
• El < ! DOCTYPE > brilla por su ausencia, así como el tipo de codificación utilizada.
• La mayoría de las etiquetas están en mayúsculas.
• Maquetan absolutamente todo con tablas (volvámos a los 90!)
• Por supuesto, no valida, se usan parámetros de estilo en el html no siempre válidos, y los alt de las imágenes no existen (y mira que el dreamweaver te lo pide!).

Eso si, puedes pedirles un presupuesto personalizado:

• Cada pantalla HTML con texto (tamaño a4): 35€
• Cada imágen: 2€
• Formulario: 38€
• Inserción de logotipo: 2€
• Pantalla HTML emergente (toma ya!): 10€
• 3 Banners rotativos: 6€
• Imágen de fondo por pantalla: 2€
• Midis por pantalla: 2€
• Contador de visitas: 9€
• Tablón de anuncios con CGI: 60€
• Lista de correo: 60€
• Diseño de interface con elementos de navegación: 60€
• Barra de navegación personalizada: 180€
• Mantenimiento y modificaciones. 9€
• Alta en 150 buscadores: 80€
• Ser un Webmaster de finales de los 90 en pleno fenómeno “2.0″ no tiene precio.

Y lo más divertido viene cuando en su página principal, “denuncian” a otras Webs por plagiar su plantilla… me pregunto qué pensarán sus clientes cuando vean que su web es exactamente igual que otra…

No se cuánto facturarán (ni me importa demasiado), pero al final tendrán fecha de caducidad…

Nota: No he puesto su Web a propósito, pero si alguien la quiere, me la puede pedir personalmente.

Compartelo

Desde que conocí la metodología de programación extrema hace unos años, me di cuenta de que estaba hecha para la Web. Aunque inicialmente estuviera pensada para cualquier tipo de desarrollo (sobre todo Java), realmente encaja a la perfección con un proceso de desarrollo Web normal.

La XP es uno de los muchos procesos ágiles que hay ahora mismo disponibles, y que se basa fundamentalmente en olvidarse de que no podemos adelantarnos a los cambios de requisitos, y a que los clientes siempre serán aleatorios y caóticos. De modo que nos propone varias pautas a seguir a la hora de gestionar nuestro proyecto. Copio los epígrafes del artículo en la wikipedia, adaptándolos a un desarrollo web medio - grande.

• Desarrollo iterativo e incremental: El desarrollo en espiral evolucionado. No podemos presentar directamente la imágen a un cliente, o a unos usuarios. Aquí entra la labor de bocetado, prototipado, pruebas de usabilidad, etc. Poco a poco vamos aumentando fidelidad a los prototipos hasta que desarrollamos la lógica de negocio completamente (donde el cliente ya pinta poco). Y como decía hace unos días: Da igual que tu algoritmo sea el mejor y más eficiente… si es feo, al cliente no le va a gustar!
  Y respecto a incremental, el hecho de ir añadiendo módulos, o funcinoalidades hace que el desarrollo sea menos caótico, algo nada nuevo dentro del desarrollo Web.

• Pruebas unitarias continuas. Hoy en día con Firebug, esto es más fácil que nunca. A la hora de desarrollar la GUI, trabajar con los efectos JS y el CSS (sobre todo con librerías), cada vez que vamos al navegador y pulsamos F5 para comprobar los efectos del último hack incluido no estamos haciendo más que pruerbas unitarias. Esto inicialmente estaba pensado para JUnit, y para la preparación de los casos de prueba de las clases antes de la programación de las mismas. Esto también lo podemos hacer en la lógica de negocio de nuestras clases. De hecho una técnica para fidelizar al 100% los prototipos es desarrollar toda la lógica de presentación apuntando a clases de prueba, que en lugar de sacar los datos de una capa de acceso a datos, tiene un contenido dummy (arrays escritos a pelo en una clase PHP). De esta forma, la interfaz da la impresión de estar terminada, pero realmente no hay nada por debajo.

• Programación por parejas: Esta es la parte que más me gusta, y que aunque parezca mentira realmente funciona. Mientras uno codifica, el otro va diseñando y realizando pruebas, preparando la codificación y comprobando lo que va haciendo el otro. Cuando hay un error que se nos atasca no hay nada mejor que pedir a alguein que lo eche un vistazo, y la programación por parejas va un poco por ahi. En el mundo del desarrollo Web es común hacer esto en parejas de diseñador gráfico - maquetador, o programador - analista, pero la idea es que haya cuatro ojos mirando el mismo monitor.

• Frecuente interacción del equipo de programación con el cliente. De hecho, el método propone que haya un miembro de la empresa cliente en el equipo de desarrollo. Esto es bastante inviable en el 99% de los casos, pero lo que si se puede hacer es un constante trabajo de pruebas y mejoras continuas. De nuevo, volvemos al prototipado y las pruebas con el cliente. Desde diagramas de casos de uso que sean entendibles, hasta documentación (no técnica), pasando, claro, por reuniones de seguimiento y de pruebas, documentadas y en acta.

• Corrección de todos los errores. Lo ideal es que cada “entrega” o “hito” no dure más de una semana. Cuanto más cortos mucho mejor, pues se genera menos ruido o caos en el código general. Y una filosofía que pocos apliacan. No se añaden funcionalidades hasta que se han solventado todos los errores de las existentes. En Web esto es muy importante. No nos sirve de nada implementar un mashup de google maps en nuestra aplicación, si la página no se ve bien en firefox!

• Refactorización del código. Aunque depende mucho del sistema que usemos (Java con struts y JSP, PHP, Ruby on Rails….), es importante refactorizar el código para aumentar la escalabilidad y el mantenimiento. En prácticamente todos los desarrollos informáticos acabas utilizando más librerías o implementando más funciones de las que necesitas. Muchas veces haces código duplicado, y otras podrías haber usado algún patrón de diseño para mejorar el código y hacerlo más claro. Lo idea es que cada iteración de la aplicación sufra una refactorización total, por supuesto sin modificar las funcionalidades. ¿Qué implica esto en el D. Web? Separar los CSS por tipo de presentación y módulo, juntar los JS de funciones similares, o separar los que no tengan nada que ver, buscar herencias y polimorfismos en el código e implementarlos, etc… Aquí la diferencia se nos dará en clarificación de código, y tiempo de carga (pasar de cargar código javascript de 80kb a cargar 30kb).

• Propiedad del código compartida: Todo el código es de todos y cualqueira puede modificar cualquier parte. Aquí estoy de acuerdo sólo si usas un buen control de versiones. Pero en los desarrollos Web es más común que un pequeño cambio afecte a toda la aplicación, de forma que se hace necesario que todos los desarrolladores conozcan todo el código y estén capacitados para modificarlo.

• Simplicidad en el código. Esto está claro, pero ampliarlo a simplicidad en la interfaz, en el diseño (no solo gráfico, sino de la aplicación), y por supuesto, cumplir con estándares y validaciones.

En general es útil cuando los equipos no son muy grandes (no más de 8 personas), y cuando son ágiles. La consultora tradicional tendrá muchos problemas para adaptarse. Sin embargo el equipo de jóvenes desarrolladores de una start-up, lo tendrán como el modelo ideal. Ergo concluyo: La programación extrema puede ser el mejor paradigma de programación para la creación de start-ups.

Más info en la web de difusión del extreme programming.

Compartelo

Pero no el posicionamiento en google, sino el de negocio, un posicionamiento que en muchos casos, se olvida.

Todo esto viene a través del artículo ¿Cuánto vale una web profesional? en Tecnotertulia, que me ha parecido muy interesante y me ha recordado a las charlas que tenía con mis socios hace tiempo (aunque no he podido dejar un comentario).

Y hoy publican “La Respuesta“, que en parte, contesta a lo que escribo en este artículo.

Divide los presupuestos de Webs en Gratuitos - De 500 a 2000€ - de 2000 a 9000€ - de 9000 a 22.000€ y de 22000 a 500000€. Clasificación que me parece bien, pero que yo diviría en función del personal y tiempo involucrado en el proyecto. De modo que respondan a estas preguntas:

• ¿El proyecto tiena la suficiente extensión para requerir un jefe de proyecto dedicado a planificación y seguimiento?
• El proyecto lo va a llevar a cabo una sola persona o harán falta distintos roles? Diseñador gráfico, analista, maquetador, programador, experto SEO, DBA…
• ¿Las herramientas de desarrollo requieren licencias? ¿Será de creación propia o se usarán módulos de otras aplicaciones (código libre)?
• ¿El proyecto requiere mantenimiento? ¿Se garantiza posicionamiento? ¿Hay que preparar documentación? ¿Formación? ¿Presentar memoria?
• etc…

Al final todo esto “cala” mucho en la empresa que desarrolla (y aquí quería llegar). Información sobre “cuánto cobrar” por un desarrollo hay mucha y muy variada, y cada uno te dirá una cosa, pero al final lo que importa es que cada uno encuentre su nicho de mercado (que no siempre tiene que ser el de los precios más bajos).

Si tus clientes son grandes empresas con grandes expectativas, no aceptarán presupuestos de 1000€, y si vas a vender una web a una pescadería que no va a entender la diferencia entre usar estándares o plantar su texto en una plantilla, probablemente 300€ será mucho. Cuando nosotros vendiamos webs por 600€, nuestro trabajo era medio, con bajones de vez en cuando, pero cuando cambiamos la filosofía a “desarrolladora cara” incluso para pymes no bajando de 2000 o 3000€ por proyecto, de repente empezaron a llover trabajos, encontramos nuestro nicho. Y si alguien decía que eramos muy caros, le decíamos que eso era porque lo hacíamos mejor.

Compartelo

AlphaWork services es una especie de google labs de IBM, donde desarrollar aplicaciones (sobre todo) Web punteras, e intentan innovar en la forma de mostrar la información que tenemos actualmente.

Uno de los últimos trabajos que he visto es el Many Eyes, una aplicación social para la visualización y preparación de información colaborativa. Es decir, que grupos de usuarios puedan representar de forma social la información que deseen usando varios tipos de gráficos, entre ellos evoluciones de tag clouds.

Recomiendo echar un vistazo al tour de la aplicación, donde podemos ver el potencial que tiene la herramienta.

Cosas similares se hicieron con Quintura, por ejemplo. También recomiendo la lectura del artículo de Yusef Hassan-Montero y Victor Herrero-Solana: Improving tag clouds as visual information retrieval interfaces, que ya se puso en un comentario de este blog.

¿Hasta donde pueden llegar las nubes de tags para las categorías? ¿Cuál es la utilidad real a nivel de usabilidad?

Compartelo

He leido en Sentido Web esta entrada que habla de PHP Maker , una herramienta que no conocía, y que me de haberlo hecho me habría ahorrado unas cuantas horas de trabajo.

A la hora de desarrollar aplicaciones web, en la parte de acceso a datos suelo implementar dos modelos diferentes, uno basado en consultas, y otro basado en “maestros”. Aunque no es nada nuevo, trataré de explicarlo un poco.

• Servicio de consultas:
  Sería una parte de la capa de acceso a datos que gestiona todas las consultas necesarias para ofrecer información a la lógica de negocio. Búsquedas concretas, ordenaciones, extracción de información de tablas diferentes en función de variables determinadas, etc… Id est: “Quiero ver los últimos 10 posts del usuario X en la categoría K”. Esa consulta implica varias tablas, y parámetros que nos ha pedido el usuario de antemano.
• Servicio de maestros:
  En ocasiones es necesario obtener toda la tupla de información de un registro, para cualquiera de las modificaciones básicas (CRUD - Create, Retrieve, Update, Delete, es decir: Crear, Obtener, Actualizar, Modificar registros). En esas ocasiones con un identificador nos puede valer para obtener toda esa tupla.
  Pues bien, este servicio hace unas labores tan concretas y tan optimizables, que tiene sentido separarlas en un servicio aparte, y que sea la lógica de negocio y el acceso a datos el que decida qué usar en cada momento.

Entonces, este PHP Maker, nos sirve para generar automaticamente scripts de acceso a datos a partir de una base de datos, y por lo tanto nos ahorra mucho trabajo.
Para ser sinceros, no lo he probado en mis propias carnes, pero tiene muy buena pinta. Y en la misma página ofrecen XMLMaker, o ASPMaker, que prometen soluciones del estilo. Merece la pena probarlo!

Compartelo

Me he reido un rato con este artículo de gentegeek.com, y se me ha ocurrido ampliarlo pobremente…

• Separarás contenido de maquetación y de comportamiento, hornado al padre Javascript, a la madre CSS y al abuelo XHTML.
• No usarás editores WYSIWYG, y de tener que hacerlo, comprobarás el código resultante a mano.
• Te sentirás emocionado por la Web semántica y tratarás de emplear microformatos.
• No pondrás reflejos ni estrellas “2.0″ porque sí.
• Buscarás la forma de meter la inteligencia social en todo proyecto web que realices.
• Tratarás la accesibilidad como un requisito obligatorio y no “si me queda algo de tiempo”, y validarás con WAI.
• No intentarás hacer engaños burdos para salir mejor en google y te centrarás en crear mejor contenido.

etc… XD

Y los originales:

• 1. Amarás a
  sobre todas las demás etiquetas
• 2. No usarás
  en vano
• 3. Validarás siempre tu código con w3c
• 4. Honrarás al XHTML y CSS
• 5. No usarás tablas en la maquetación principal
• 6. No utilizarás la etiqueta dentro del código
• 7. No harás Copy&Paste de otras páginas
• 8. No programarás sólo para Internet Explorer
• 9. No descargarás por el emule plantillas de templatemonster
• 10. No codiciarás la Web 2.0

Compartelo

Veo en Denken Über una referencia al artículo original de Google Watch, sobre el experimento de estos últimos, cambiando la homepage de google al estilo yahoo.

Es cierto que en la homepage de google ya tiene todas esas funcionalidades, pero la GUI de yahoo me gusta mucho más. Creo que es mucho mas usable, y si tuviera las pestañas que si implementa ya sería excelente.

Compartelo

Me retracto de lo dicho en ejemplos de newsletters ayer, al ver esta noticia en Sentido Web: Lo que outlook 2007 no permitirá hacer con los mailings.

Parece ser que ahora usará el motor de Word para renderizar mensajes (si, ese mismo que te permitía hacer unas páginas Web estupendas).

• Se carga los background-image, tanto en html como en CSS.
• Adós a todo posicionamiento no “static”. Sin floats, nos quedamos sin columnas. ¿Será la vuelta al mundo de las tablas?
• Elementos de bloque mal especificados, los paddings y margenes ya no son lo que eran.
• Sin flash. (bueno, esto no es tan malo)
• No se pueden imágenes como viñetas de las listas no númeradas (tampoco es tan malo).
• No permite Gif animados (nunca los usé en mailings).

Interesante ver el mismo mail en Outlook 2000 y en Outlook 2007
Supuestamente, todo esto son motivos de seguridad, pero luego podremos embeber código activeX, o JS para hacer cualquier cosa… a saber. ¿Alternativas? Eudora, Thunderbird… y sino… Gmail con tu nombre de dominio.

El artículo original en SitePoint.

Compartelo

A la hora de desarrollar una Web, es cierto que usar frameworks es una ayuda muy interesante. Anieto, ya escribió hace unos meses sobre los más usados.
Quizá el problema puede estar en que unos te dan unas facilidades que no te dan otros, y por supuesto, mezclarlos es una muy mala idea. Además, la actual, si se puede llamar “guerra de frameworks”, provoca que cada vez tengan más funcionalidades, y por lo tanto más peso. De forma que si lo quieres solo para una cosa concreta, o te buscas un snippet de código concreto, o rebajas manualmente la librería.

En coder battery, dan una lista de razones muy adecuada sobre porqué usar frameworks, que intentaré resumir.

• Te permite programar más rápidamente.
• Te ahorra trabajo
• Da consistencia a tu código.
• Te ayuda a escribir mejor código y más ordenado.
• Te permite usar lo último en herramientas técnicas
• Te da soporte gratuito
• Te permite tener un ejército de programadores para ti.
• Te permite separar presentación de negocio.
• Puedes tener la documentación lista.
• Es más multiplataforma
• Mejor acceso a la capa de datos del que podrías hacer tu.
• Mejora la seguridad de tu aplicación

Bien, estas afirmaciones, lo cierto es que tienen muchas caras. Empezando porque hay que sopesar el tiempo de aprendizaje que requiere una librería, o la elección de la más apropiada (usaré prototype o jQuery?), por no hablar de efectos espectaculares que nos dejan asombrados, pero que requieren cantidades inmensas de código.

Aumenta el peso de nuestra aplicación, y, cuidado, como tengamos errores o incompatibilidades con el resto de nuestro código, prepárense para analizar el código línea a línea a ver dónde carajo está el fallo (gracias! firebug!).

Y depende que frameworks, tendrás mejor o peor soporte, las herramientas serán mejores o peores, o tienen una documentación maso menos útil.

“In the other hand” , tenemos este artículo en inglés de Andy Smith: Why frameworks suck, muy interesante de leer, aunque un poco denso.

Me quedo con una frase:

If building an application with libraries is playing football with your buddies, building an application on a large framework is playing football in the NFL. You may get money, attention and busty cheerleaders, but what was a game about throwing a ball and doing your damndest to make your best friend eat mud becomes a game about offsides, holding and television breaks; it’s just not fun anymore.

Si desarrollar una aplicación con librerías es como jugar al futbol (americano) con tus colegas, desarrollar una aplicaión con un gran framework es como jugar en la NFL (liga de futbol americano). Puedes conseguir dinero, atención y animadoras “pechugonas”, pero lo que fué un juego de tirar una pelota y hacer todo lo posible para que tu mejor amigo caiga sobre el barro, se ha convertido en algo lateral, de participación y televisión; ya no es divertido… (traducción libre y muy mejorable).
Y la conclusión, al final de su artículo:

Frameworks suck because they are an avatar of enterprise, frameworks suck because they take away your freedom, frameworks suck because they build walls between coders, frameworks suck because they make you fit your project to the toolset rather than the toolset to the project, and frameworks suck because they take the fun out of programming, long live the library.

Los frameworks apestan porque son la representación empresarial, porque te quitan libertad, porque levantan muros entre programadores, porque hacen que tengas que cambiar tu proyecto a la herramienta en lugar de la herramienta al proyecto, y porque le quitan la diversión a la programación, larga vida a las librerías!.

Sin duda, la clave está en el término medio. Ni son la panacea para cualquier proyecto, ni debemos dejarlos de lado. En parte estoy de acuerdo en que en ocasiones adaptamos nuestro proyecto a una herramienta, cuando debería ser al revés, de modo que ahi entra la inteligencia y experiencia del analista, que sopesa los riesgos y las ventajas de usar un framework y los acepta y asume.

Vosotros, ¿que framework utilizáis? ¿Qué dificultades os habéis encontrado a la hora de implementar alguno?

Compartelo