Una vez publicadas éstas propuestas la gente que esté interesada en ellas se puede ir uniendo. Cuando hay varias peticiones para un mismo producto o grupo de productos parecidos, se negocia la compra con distintos proveedores eligiendo la oferta más adecuada, se envían las condiciones a los que estaban interesados en el producto y si lo acepta, se le mandan los datos para poder recojerlo.

Todavía hay que añadirle una serie de funcionalidades, seguimiento de las propuestas a traves de RSS, que se irán añadiendo poco a poco.

Este nuevo componente va integrado dentro del espacio que Xpression Kultur Elkartea ha creado para el colectivo universitario, junto a Foros, Tablón de Anuncios, ...TAmbién se pretender dotar de más secciones, Weblogs, Noticias, etc...

Muestra del Rediseño realizado por ketari.com.

Consideraciones Previas

Esta propuesta de rediseño carece de los estudios necesarios para determinar los contenidos, por lo que se tiene que tomar como una aproximación.

Este rediseño se ha realizado después de ver el trabajo realizado por la gente de Alzado en la que hacen un Rediseño de administracion.es aparte de darnos la idea, como es evidentes, hay coincidencias en el diseño, para eso están los maestros.

Se ha separado el contenido de la presentación

Mediante la combinación de XHTML y CSS (Hojas de Estilo) se ha conseguido:

• Reducir el peso de la página pasando de los 162 k actuales a los 30 k que tiene este rediseño más de 5 veces menos, con lo que se reduce el tiempo de espera en la descarga.
• Compatibilidad con todos los navegadores (Explorer, Firefox, Opera, Sólo Texto) y dispositivos (movil, PDA, PC, ...)
• Optimizar los contenidos para los motores de búsqueda (Google, Yahoo,...), siendo más facil la localización de contenidos desde los buscadores.

No se han utilizado tablas para el formateo visual de la página, se ha utilizado una Hoja de Estilos.

Además tanto el códido XHTML como la Hoja de estilo cumple los estándares de la W3C como se puede comprobar Validar XHTML Validar CSS

Accesibilidad

La página cumple con el Nivel Doble-A de accesibilidad creado por la WAI, recomendado por la Unión Europea para cumplir con las normas de accesibilidad y que será de obligado cumplimiento a partir del 31 de diciembre de 2005 (Ley 34/2002 Disp. Adicional Quinta).

Se ha evitado el uso de imágenes y en vez de ello se ha optado por enlaces en modo texto, evitando recargar la página con imágenes que distraigan del contenido, además todas las imágenes tienen el atributo alt como texto descriptivo de la imagen.

Todos los enlaces poseen el atributo title (título) y cuando se detiene el puntero del ratón sobre el enlace se amplía la información de lo que se encontrará si pincha en el enlace.

Es posible navegar a través del teclado en el menu principal todas las opciones tienen una letra subrayada, en Windows y con Internet Explorer 5 o superior, pulsando Alt + Tecla de accesso rápido (Letra subrayada) + Enter es como si hicieramos click con el ratón.

Estructura

El diseño actual divide la página en tres categorias, Una Ciudad para Vivir, Una Ciudad para Visitar y Ayuntamiento, en vez de esto hemos decidido agrupar la información sin distinguir entre ciudadanos de san sebastián y visitantes ya que hay cosas que interesan de igual manera a un donostiarra que a un visitante (Transporte, estado de Playas, ...).

Los contenidos los hemos agrupado teniendo presente en que puede ser útil para la gente y según su importancia la hemos puesto en un lugar más visible y destacándolo del resto cambiando el color, como en el caso de Servicios OnLine (Debería de ser uno de los más utilizados). Indudablemente habría que saber cuales son las páginas más demandadas, ya sea con entrevistas con el personal de los departamentos, ya sea con analizando los datos de las estadísticas actuales sobre la utilización del sitio.

También entendemos que la información turística debe tener su lugar en la página del Centro de Atracción y Turismo y por lo tanto hemos puesto una imagen con un enlace sobre Información Turística.

Se le ha quitado imágenes superfluas y se ha agrupado la información disponible en categorías a modo de directorio, las categorías no corresponden a la estructura interna del ayuntamiento sino a una agrupación mixta, parte se agrupa por departamentos (Deportes, Cultura, ...) y otra parte según la podría asociar el usuario (Bajo nuestra visión).

Cabecera

Se ha puesto el logotipo del ayuntamiento que existe actualmente y que a su vez es un vínculo a la portada, en vez del texto "toda la información a su alcance" estaría mejor "Ayuntamineto de San Sebastián".

Se han eliminado los banner con imágenes en movimiento, el usuario tiende a ignorarlos, y se ha puesto las opciones de cambio de idioma, el Buscador y el tiempo actual con la hora Local (estos es para los visitantes)

Por supuesto según el idioma elegido los contenidos de la Portada deberían de variar.

Barra de Navegación

La barra de Navegación tiene 2 niveles, el nivel superior tendría siempre las mísmas opciones, y el nivel inferios iría cambiando en función de la opción elegida en el nivel superior, la opción seleccionada tiene un color distinto.

Parte Central

Se ha decido que la estructura fuera un directorio, ya que es un formato que se entiende facilmente y permite la agrupación por áreas, estas áreas no coinciden siempre con la estructura del ayuntamiento, ya que muchas veces interesa que estén juntas opciones que pertenecen a distintos departamentos.

Se ha resaltado los Servicios OnLine porque entendemos que es una de las cosas realmente útiles que puede realizar el ciudadano, habría que aumentar los servicios que se pueden realizar desde Internet.

Hemos incluido una sección de Noticias, un calendario de actividades y la sección Foto del día dónde cualquiera pudiera enviar una foto de la ciudad, esto le daría más sensación de ser una página viva.

Pie de Página

Se ha incluido información básica dirección y teléfono, Ayuda, Preguntas Frecuentes (Hay muchas dudas que se repiten), un enlace para ver todo el contenido de la web, un enlace que explique la política de accesibilidad del sitio (Teclas de acceso rápido, ...) y por último la opción para contactar con el Ayuntamiento mediante un formulario.

Otras posibilidades

Se ha incluido en algunas secciones la posibilidad de estar informado de las novedades a traves de la sindicación de contenidos en formatos RSS, que es una nuevo formato para ver contenidos mediante un lector de Feeds

Conclusión

En la nueva estructura que proponemos prima la faclilidad de uso sobre el diseño mejor dicho se ha diseñado para facilitar el uso, lo que no quiere decir que el diseño no sea atractivo, lo que la gente le pide a una página web es que le sea util y lo demás es secundario, tenemos el ejemplo clarísimo de Google.

Rediseño de la Web del Ayuntamiento de San Sebastián

• www.donostia.org Ver Analisis
  • Propuesta de Rediseño realizada por ketari de la web.
• www.donostiakultura.com Ver Analisis
• www.sansebastianturismo.com Ver Analisis

Problemas de accesibilidad

Un error muy común a la hora de desarrollar una página web es tener en cuenta sólo a la "mayoría", es decir, a personas sin ningún tipo de discapacidad y que utiliza el navegador más extendido. Ésto, que es un error en cualquier empresa, en una entidad pública no es aceptable, ya que puede darse el caso que una web sea totalmente inaccesible para determinados colectivos.

Para que ésto no suceda basta con seguir los estándares que para ésta materia hay creados, cumpliéndolos, el sitio web es accesible para todos los colectivos y desde todos los dispositivos (PC, Móviles, PDA, ...) y cualquier tipo de navegadores (IExplorer, FireFox, Opera, Sólo texto, ...)

Es en este punto dónde la web de ayuntamiento tiene grandes deficiencias.

Para empezar vamos a suponer que una persona invidente que utiliza un navegador de voz entra en la página del ayuntamiento, o una persona con un navegador en modo texto o simplemente con el mostrar imágenes deshabilitado.

Definir el idioma en que está escrito.

Para los navegadores de voz es fundamental decirle cuál es el idioma en el que están escritos los textos, para que los pueda interpretar de una manera correcta, en el caso de las versiones en Castellano y Euskara tiene definido como idioma es (Español), y en las versiones en Inglés y Francés, no se le indica nada, si se utiliza un navegador de voz, la versión en Euskara utilizaría la pronunciación en Castellano(Ejemplo:Bizitzeko hiria lo leería Bicit zeco iria, tal cual lo leería un castellanoparlante sin conocimientos de Euskara).

Poner textos alternativos en la imágenes que así lo requieran

Algunas imágenes no tienen definido el atributo alt (alternate text, texto alternativo), siendo este texto el que aparece cuando no se muestra la imagen, bien porque el navegador tiene deshabilitado el mostrar imágenes (por rapidez) o bien porque utiliza un navegador en modo texto. En el caso de utilizar un navegador de voz será el texto que escuchará.

A continuación vamos a mostrar la página para el pago online del ayuntamiento, con y sin imágenes.

Pago Online con imágenes habilitadas

Pago Online sin imágenes

En este ejemplo se ve con toda claridad como la página sería totalmente inaccesible para una persona invidente que utilizase un navegador de voz. No sabría dónde pinchar en el caso de Tarjeta Visa, Mastercard, ... o Kutxa, Caja Laboral, Banco Guipuzcoano. Esto se podría haber solucionando utilizando un enlace de texto, o poniéndole a las imágenes el atributo alt.

No utilizar javascript si no es necesario

Otro problema de accesibilidad que tiene el sitio www.donostia.org, es la utilización de javascript en casos en los que no es necesario, el javascript es un lenguaje de tipo cliente, es decir, que se ejecuta en el navegador del usuario que visita la página, se puede tener o no tenerlo habilitado, pues bien si una persona no tuvise habilitado javascript en su navegador o simplemente utiliza un navegador antiguo que no dispone de javascript, no podría navergar por el sitio web del ayuntamiento, puesto que muchos enlaces en vez de utilizar el típico <a href="http://loquesea... utilizan código javascript.

También la validación y el envío de datos del formulario de contacto utiliza javascript, cuando es más seguro hacer la validación en el lado servidor.

Problemas de Usabilidad

A la hora de crear un sitio web hay que preguntarse que objetivos tenemos y como conseguirlos de la manera más sencilla posible. Ésto se puede conseguir mediante un diseño centrado en el usuario, es decir, que el contenido de la web tenga como objetivo hacerla la vida lo más facil posible al visitante evitandole complicaciones, si no hacemos esto el sitio web no tendrá éxito.

Para conseguirlo hay que tener en cuenta una serie de factores.

Rapidez en la descarga de las páginas.

El peso de la página de Inicio es 168 Kbytes, esto supone que con una conexión de modem a 56 k la página tardaría en descargarse completamente 24 segundos un tiempo excesivo, sobre todo si se tiene en cuenta que un sitio que tarda más de 5 segundos en descargar es considerado como lento.

Soluciones:

• Diseñar utilizando XHTML y CSS (Hojas de estilo en cascada), reduciendo considerablemente el tamaño de la página, ya que utilizamos un solo fichero para realizar el formateo de la página, además esto permitiría hacer cambios en toda la web de una manera muy rápida.
• No abusar de las imágenes, en muchos casos se utilizan imágenes innecesariamente.
• Evitar la utilización de archivos Flash cuando no aportan nada relevante, en la cabecera de la página hay un banner hecho en Flash que ocupa 16 k y que además te obliga a tener instalado un pluggin.

¿Es realmente útil la página?

Si se decide crear un sitio web del ayuntamiento se debe de analizar todos los departamentos y ver que servicios, informaciones, documentación y demás es susceptible de estar en la web, absolutamente todas las gestiones que se puedan hacer online deberán de estar disponibles y visibles en la web.

No hay muchas opciones disponibles para realizarse OnLine en la mayoría de los casos te proporcionan el impreso pero tienes que presentarte en el Ayuntamiento con la Fotocopia del DNI, no debería de haber problema para que introduciendo Nª de DNI y una clave, no se pueda hacer desde casa.

Es realmente util poder realizar, por ejemplo, el trámite de empadronamiento desde Internet sin tener que desplazarte hasta el Ayuntamiento, desde cualquier barrio se tarda un mínimo de una hora entre la ida y la vuelta, además de la cola pertinente, si contar los problemas de horario de muchas personas.

URL muy poco amigables y que no tienen relación con el contenido

Cuando vas a la página de Inicio en Castellano la dirección URL que te aparece es

http://www.donostia.org/taxo.nsf/fwHome?OpenForm&idioma=cas

en este caso una URL más correcta podría ser

http://www.donostia.org/es/

si vamos a la página sobre el Barrio de Amara Berri la dirección es

http://www.donostia.org/info/ciudadano/ss_barrios.nsf/voWebContenidosId/NT0000091A?OpenDocument&idioma=cas&idContenido=464663

cuando sería más interesante que fuera

http://www.donostia.org/info/ciudadano/barrios/amara_berri/

además de ser más sencilla, tiene relación con el contenido.

Además de todo esto, los buscadores (Google, Yahoo, ...) no suelen indexar las páginas que contienen mas de un & o ? en la URL, porque entienden que es una URL dinámica con contenido muy variable.

Para más información sobre los beneficios de utilizar URL Amigables Leer Artículo (Inglés)

Soluciones:

• Dependerá del servidor web dónde esté alojado, pero suponiendo que este alojado en el servidor web más común Apache se puede utilizar mod_rewrite para hacer las URL amigables.

Todas las páginas tienen el mísmo título.

Todas las paginas tienen el título Donostiako Udala :: Ayuntamiento de San Sebastián si tenemos varias ventanas abiertas no hay posibilidad de saber cual es cada página en la Barra de Tareas, serías mas correcto que en el titulo además nos informaran sobre el contenido de dicha página para poder distinguirla de las otras. Ejemplo: Playas Donostiako... o Pago Online Donostiako...

Se puede comprobar como no se distingue una página de las otras.

En este Ejemplo se observa la utilidad de tener los títulos de las páginas en consonancia con el contenido.

Más acerca de la utilidad de los títulos

Menus con listas desplegables

En la Página principal hay 3 listas desplegables con las opciones más comunmente utilizadas, sería más interesante que estas opciones estuvieran a la vista, en vez de escondidas, tenemos que pulsar 2 veces el ratón, una para desplegar la lista, comprobar si la opción que queremos está y luego pinchar en la opción deseada, demasiado, aquí se explica los Problemas de las Listas desplegables.

No existe un página de Error personalizada

Cuando por alguna razón la dirección URL no existe, bien porque esa página ya no existe o bien por una equivocación al teclear la dirección, es conveniente que exista una página indicando el error que se ha producido, sugiriendo cuales han podido ser las causas y dándole alguna posible solución, regularmente hay que analizar este tipo de errores para intentar dar una solución en el caso de se pueda.

Resultado que nos da ahora:

No hay una versión ara imprimir

Es conveniente que cada página tenga una versión para imprimir la versión impresa tiene que tener características distintas.

• No es necesario imprimir, menús, banners, ... solo es necesario el contenido, el logotipo, el título de la web y la ruta en que se encuentra.
• Limitar el area de impresión a 8,5x11 pulgadas (Formato A4).
• Los tipos y tamaños de letra deben de ser distintos en pantalla que para papel.

Esto además favorece el ahorro de papel, al no imprimir el contenido que no es necesario.

Solucion:

Utilizar una hoja de estilo para darle el formateo adecuado, en dónde aparezca el logotipo del ayuntamiento arriba, la ruta donde está el documento y el texto de la página.

Conclusión:

La web del Ayuntamiento de San Sebastián debería de hacer un rediseño del sitio web para adaptarlo a las normas de accesibilidad de la WAI para evitar que una parte de la población no tenga acceso a la web de su ayuntamineto.

Además la ley 34/2002 de 11 de julio en la disposición adicional quinta establece que antes del 31 de diciembre de 2005 las administraciones públicas adoptaran las medidas necesarias para que la información disponible en sus respectivas páginas de Internet pueda ser accesible a personas con discapacidad y de edad avanzada.

Desde Ketari hemos realizado una Propuesta de Rediseño de la Página de Inicio, este sería el Resultado Final, resolviendo los problemas que planteamos aquí.

Problemas de accesibilidad

Innacesible para usuarios con discapacidad visual

Podemos decir que está página es totalmente inaccesible si se utiliza un navegador en modo texto o un navegador de voz para personas con deficiencia visual, para comprobar ésto basta poner un ejemplo de como se vería la página principal con imágenes y con las imágenes deshabilitadas.

Página Principal de Donostia Kultura con imágenes

Página Principal de Donostia Kultura con imágenes deshabilitadas

Como podemos observar es imposible navegar por la Página de Donostia Kultura, ni siquiera podrímos cambiar de idioma.

Las páginas no tienen definido el idioma, ya hemos comentado en el Analisis de la web de Ayuntamiento de Donostia los problemas que puede dar ésto en Navegadores de Voz.

Está diseñada con Marcos (Frames)

Se utilizan Marcos (Frames), los marcos lo que hacen es introducir una página web en otra, esto produce varios problemas, por ejemplo los buscadores las indexan como si fueran 2 páginas distintas, lo vamos a ver mejor en este ejemplo real, vamos a Buscar Lugaritz en Google

Vamos a la página que nos da como resultado y ...

En esta página no aparecen los menús de navegación por lo que no podemos acceder a otras páginas de DonostiaKultura

Cuando en realidad la página correcta sería

No están tituladas correcatmente

Algunas páginas tienen como titulo Untitled Document, todas las páginas deben de tener su propio título que describa brevemente el contenido de la página.

Problemas de usabilidad

Contenido no actualizado.

En la sección Proximamente aparecen actuaciones de Abril del año pasado, sin palabras.

Además en las páginas correspondientes a cada Casa de Cultura no es posible ver las actividades que se realizan en esa Casa.

Menus con listas desplegables

Las listas desplegables no favorecen la usabilidad del sitio, las distintas opciones si son importantes deben de estar visibles.

Abuso imágenes como enlaces

Las imágenes no siempre son descriptivas de lo que te encontrarás si pinchas en el enlace, un enlace en modo texto con una breve descripción es más efectivo.

Página Principal con un contenido muy pobre.

Debería de tener información actualizada sobre actividades del día (conciertos, exposiciones, cursos, ...) o del fin de semana, con un enlace para más información.

No tiene buscador

Es fundamental para acceder rápidamente a lo que se busca, mucha gente no tiene paciencia para encontrar la información siguiendo los vínculos de la Página de Inicio.

No se ven las ventajas que tiene DonostiaKultura.com

Cuando cojes un libro en una biblioteca lo puedes renovar por teléfono, no hay razón por la que no se pueda realizar esta acción por Internet, pues en www.donostiakultura.com no se puede.

Festival de Cine Fantástico y de Terror

La web del www.donostiakultura.com/terror/ es sencillamente para salir huyendo de pánico.

Sirva como ejemplo como se vería la Página Principal con imágenes y sin imagenes.

Festival de Terror con imágenes habilitadas

Festival de Terror sin imágenes

Evidentemente personas con discapacidad visual no podrían pasar de la primera página.

Conclusión:

El sitio web del Patronato de Cultura requiere un rediseño completo, tanto a nivel de diseño como de contenidos, para que verdaderamente sea una web acorde a los tiempos.

Actualización 02/06/2006Han rediseñado completamente la página, así que el contenido de éste artículo pasa de ser de denuncia a ser informativo, ahora si podemos decir que es un sitio como dios manda.

Vamos a enumerar rápidamente deficiencias encontradas:

Inaccesible para navegadores de Voz o solo texto

Se utilizan constantemente imágenes de texto, sin el atributo alt, ¿por qué no utilizar texto?, no tiene definido en el documento el tipo de lenguaje

Utiliza Marcos (Frames)

Aunque cambies de página la URL es la misma, esto hace que los buscadores no indexen las páginas correctamente.

Carece de un buscador

Una página de información turística requiere de un buscador, un persona que esté preparando unas vacaciones no tiene tiempo de andar salseando en la página, un buen buscador es vital.

No hay una estructura común para todas las páginas

Depende en que sección estés el diseño cambia totalmente, es conveniente utilizar el mismo diseño para todo el sitio, muchas veces no sabes si has sido redireccionado a otra página

Información deficiente

No he conseguido encontrar una sección donde haya Fotos de la ciudad, increible ¿no?

Información fuera de lugar

Si entramos en la sección de concursos, encontramos los resultados de las pruebas para acceder a un puesto de trabajo en CAT, de verdad una persona que acceda a esta sección ¿Se espera encontrar esto? no sería mas correcto llamarlo ¿Bolsa de Trabajo?

Conclusión:

Me imagino que estarán en proceso de renovación total de la página, de todas formas casi es mejor desactivar temporalmente la página, que dar esta imagen.

Antes de nada hay que avisarle al cliente que mantener un Portal totalmente bilingue exige un dedicación importante, ya que hay que duplicar toda la información, puede ser percibido por el visitante como falta de seriedad o de respeto hacía su lengua, si no están traducidas todas las partes del sitio web.

A la hora de crear un sistema totalmente bilingue se nos presentan varios problemas, cómo organizar la información, metodos para determinar el lenguaje en el que se mostrará la página, estructura de la Base de Datos, ....

Decidir que partes van a estar en los 2 idiomas.

Primero de todo tuvimos que decidir que partes de sistema ibamos a traducir, solo los contenidos, también las direcciones URL, etc... decidimos que la traducción iba a ser completa.

Ejemplo de traducción de la URL:

En vez de

http://www.dominio.com/es/foros/musica

http://www.dominio.com/eu/foros/musica

Nos decidimos por traducirla completamente

http://www.dominio.com/eu/foroak/musika

Es decir, no sólo ibamos a cambiar la variable de idioma es/eu sino toda la URL, ésto añadía una complejidad al sistema.

Elección del Sistema para Desarrollar la aplicación

En nuestro caso ibamos a crear un sistema en Php y con los contenidos almacenados en una Base de Datos MySql.

Php

Las variables las recibiríamos via GET de la URL, es o eu, utilizamos el mod_rewrite para hacer más amigable la dirección:

En vez de index.php?lang=es
Saldría es/

MySQL

A la hora de diseñar la base de datos había 2 posibilidades:

1. Crear 1 sóla tabla con todos los datos y los campos que iban a ser traducidos duplicarlos poniéndo el prefijo del idioma delante.
   Ejemplo:
   • contenido (id, es_titulo, eu_titulo, es_contenido, eu_contenido, fecha, ...) y así sucesivamente.
     • Ventajas: En una sola tabla tendriamos toda la información
     • Inconvenientes: la tablas son más grandes con lo que ralentiza las consultas, es más dificil añadir un idioma.
2. Crear 3 tablas una con el contenido común a los 2 idiomas y otra por cada idioma.
   Ejemplo:
   • Tabla comun contenido (id, fecha)
     tabla idioma Español es_contenido(id, contenido_id, titulo, contenido)
     tabla idioma Euskara eu_contenido(id, contenido_id, titulo, contenido)
     
     • Ventejas: Tablas más pequeñas, facilidad para añadir un nuevo idioma
     • Inconvenientes: Hay que hacer 2 consultas cada vez que se quiera mostrar el contenido de una página.

Nos decidimos por la primera opción por un tema de rendimiento en la segunda opción había que realizar 2 consultas, sabiendo que la segunda opción es más correcta pero en un desarrollo web es más importante la rapidez, para una base de datos con pocos accesos el segundo caso sería mejor.

A las sentencias SQL habría que añadirles la variable del idioma y un guión bajo antes de los campos que estuvieran en los 2 idiomas:

Ejemplo:
$idioma = $_GET($lang);
$resultado = mysql_query("select id, ". $idioma ."_titulo, ". $idioma ."_contenido, fecha from contenido");

También teníamos que decidir si al cambiar de idioma iría a la página principal o mentendría la página en la que estabas actualmente

Decidir cómo se elige el idioma

Por último había que decidir que criterios utilizar para decidir en que lenguaje se le mostraría al visitante la primera vez, había 3 opciones:

1. En función de el idioma del Navegador:
   • Ventajas: Facil de implementar.
   • Inconvenientes: Con determinados idiomas puede dar problemas, muy poca gente tiene su navegados en Euskera.
2. Un idioma por defecto y la posibilidad de cambiar de idioma:
   • Ventajas: Aunque el idioma por defecto no sea el tuyo te haces una pequeña idea de los contenidos.
   • Inconvenientes: Tienes que decidir que idioma tiene que ir por defecto esto puede provocar rechazo por parte la gente que habñla el idioma que no está por defecto.
3. Una pantalla de acceso sólo para elegir el idioma
   • Ventajas: Tratas a los 2 idiomas por igual.
   • Inconvenientes: Haces la página menos accesible para los buscadores y puede hacer desitir de continuar a deteriandos usuarios.

En este caso nos decidimos por la segunda opción, la consideramos la menos mala aunque no es la ideal.

Una vez que el usuario se decanta por un idioma el sistema grabará una cookie con el idioma de usuario, y siempre que vuelva al sitio le respetará el idioma elegido.

Conclusión

Por supuesto que el sistema puede ser mejorable, lo hemos intentado contar de una manera rápida y esperamos que le pueda servir a alguien, naturalmente se admiten comentarios.