Diseño y desarrollo de un sistema de gestión de contenidos para el ámbito publicitario
118
0
0
Texto completo
(2)
(3) a Jara...tenı́as que llegar tú para ponerme las pilas de nuevo.... i.
(4)
(5) Agradecimientos Gracias a Marga por tu infinita paciencia y la oportunidad de terminar esto. Gracias a todos los que no habéis parado de recordarme que esto seguı́a pendiente (mis padres, mi hermana, Jaime, Kitchen Garden, en su momento Evoluciona y al resto de segovianos y fuentepelayenses locos a los que en algún momento he dejado tirados para poder terminar ”mi proyecto pendiente”). Mi cabeza no se olvidaba, pero siempre viene bien tener a alguien cerca que se interese igual o más que uno mismo en conseguir un objetivo importante.. iii.
(6)
(7) Índice general Resumen. xv. 1 Introducción 1.1. 1.2. 1. Objetivos de una web corporativa . . . . . . . . . . . . . . . . . . . .. 1. 1.1.1. Objetivo de presentación . . . . . . . . . . . . . . . . . . . . .. 2. 1.1.2. Objetivo de posicionamiento . . . . . . . . . . . . . . . . . . .. 3. 1.1.3. Objetivo de ventas . . . . . . . . . . . . . . . . . . . . . . . .. 3. 1.1.4. Objetivo de nuevos mercados . . . . . . . . . . . . . . . . . .. 4. 1.1.5. Conclusión sobre los objetivos . . . . . . . . . . . . . . . . . .. 4. Soluciones de optimización . . . . . . . . . . . . . . . . . . . . . . . .. 5. 1.2.1. Web mantenible y estructurada . . . . . . . . . . . . . . . . .. 5. 1.2.2. Web visualmente agradable, usable y moderna . . . . . . . . .. 5. 1.2.3. Web rápida: optimización de rendimiento . . . . . . . . . . . .. 6. 1.2.4. Web bien posicionada: SEO . . . . . . . . . . . . . . . . . . .. 7. 1.2.5. Web colaborativa . . . . . . . . . . . . . . . . . . . . . . . . .. 7. 1.2.6. Conclusión sobre soluciones adoptadas . . . . . . . . . . . . .. 7. 2 Análisis y requisitos de la aplicación web. 9. 2.1. Toma de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9. 2.2. Análisis del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.1. Modelo de artistas . . . . . . . . . . . . . . . . . . . . . . . . 11. 2.2.2. Modelo de art-buying . . . . . . . . . . . . . . . . . . . . . . . 12. 2.2.3. Otros modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . 12. 2.2.4. Análisis detallado . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.4.1. Caracterı́sticas identificadas: Artistas Representados. 2.2.4.2. Caracterı́sticas identificadas: Artistas Externos . . . 14 v. 14.
(8) 2.2.4.3. Caracterı́sticas identificadas: Campañas . . . . . . . 14. 2.2.4.4. Caracterı́sticas identificadas: Fotógrafos . . . . . . . 15. 2.2.4.5. Caracterı́sticas identificadas: Ilustradores . . . . . . . 15. 2.2.4.6. Caracterı́sticas identificadas: Directores de arte . . . 15. 2.2.4.7. Caracterı́sticas identificadas: Imágenes . . . . . . . . 15. 2.2.4.8. Caracterı́sticas identificadas: Vı́deos . . . . . . . . . 16. 2.2.4.9. Caracterı́sticas identificadas: Clientes y Agencias . . 16. 2.2.4.10 Caracterı́sticas identificadas: Newsletter . . . . . . . 17 2.2.4.11 Caracterı́sticas identificadas: Usuarios . . . . . . . . 17 2.2.4.12 Caracterı́sticas identificadas: Contacto . . . . . . . . 17 2.3. Arquitectura de aplicación . . . . . . . . . . . . . . . . . . . . . . . . 18. 2.4. Resumen de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.4.1. Casos de uso: Website . . . . . . . . . . . . . . . . . . . . . . 20. 2.4.2. Casos de uso: CMS . . . . . . . . . . . . . . . . . . . . . . . . 20. 3 Diseño abstracto del software 3.1. 23. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1.1. Casos de uso: Website . . . . . . . . . . . . . . . . . . . . . . 24 3.1.1.1. Caso de uso 1: Acceder al website . . . . . . . . . . . 24. 3.1.1.2. Caso de uso 2: Seleccionar idioma . . . . . . . . . . . 24. 3.1.1.3. Caso de uso 3: Navegar el carrusel principal . . . . . 25. 3.1.1.4. Caso de uso 4: Suscribirse a la newsletter. 3.1.1.5. Caso de uso 5: Navegar a las redes sociales . . . . . . 27. 3.1.1.6. Caso de uso 6: Renderizar galerı́a de instagram . . . 28. 3.1.1.7. Caso de uso 7: Navegar a secciones de artistas . . . . 28. 3.1.1.8. Caso de uso 8: Seleccionar artista . . . . . . . . . . . 29. 3.1.1.9. Caso de uso 9: Seleccionar imagen de artista . . . . . 29. . . . . . . 26. 3.1.1.10 Caso de uso 10: Salir de pantalla de imagen única de artista . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1.1.11 Caso de uso 11: Seleccionar vı́deo de artista . . . . . 31 3.1.1.12 Caso de uso 12: Salir de pantalla de vı́deo único . . . 31 3.1.1.13 Caso de uso 13: Navegar a sección de art buying . . . 32 3.1.1.14 Caso de uso 14: Seleccionar campaña . . . . . . . . . 33 vi.
(9) 3.1.1.15 Caso de uso 15: Seleccionar imagen de campaña . . . 33 3.1.1.16 Caso de uso 16: Salir de pantalla de imagen única de campaña . . . . . . . . . . . . . . . . . . . . . . . . 34 3.1.1.17 Caso de uso 17: Navegar a la página de contacto . . 35 3.1.1.18 Caso de uso 18: Enviar mensaje de contacto . . . . . 35 3.1.2 3.2. Resumen de casos de uso . . . . . . . . . . . . . . . . . . . . . 36. Navegación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.2.1. Navegación de Website . . . . . . . . . . . . . . . . . . . . . . 37. 3.2.2. Navegación de CMS . . . . . . . . . . . . . . . . . . . . . . . 39. 3.2.3. Modelado de contenidos: Modelo E/R . . . . . . . . . . . . . . 41. 4 Diseño concreto del software e implementación de la aplicación 4.1. 43. Laravel Framework 5.3 . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.1.1. Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45. 4.1.2. Vistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.1.2.1. Layouts . . . . . . . . . . . . . . . . . . . . . . . . . 46. 4.1.2.2. Sub-views . . . . . . . . . . . . . . . . . . . . . . . . 46. 4.1.3. Controladores . . . . . . . . . . . . . . . . . . . . . . . . . . . 46. 4.1.4. Rutas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48. 4.1.5. Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49. 4.2. RequireJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50. 4.3. ¿Por qué Laravel y RequireJS? . . . . . . . . . . . . . . . . . . . . . . 52. 4.4. 4.3.1. ¿Por qué Laravel? . . . . . . . . . . . . . . . . . . . . . . . . . 52. 4.3.2. ¿Por qué RequireJS? . . . . . . . . . . . . . . . . . . . . . . . 53. Estructura del backend . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.4.1. Controladores . . . . . . . . . . . . . . . . . . . . . . . . . . . 54. 4.4.2. Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55. 4.4.3. Vistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.4.3.1. Para el website: . . . . . . . . . . . . . . . . . . . . . 56. 4.4.3.2. Para el CMS: . . . . . . . . . . . . . . . . . . . . . . 58. 4.4.4. Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58. 4.4.5. Rutas y middleware . . . . . . . . . . . . . . . . . . . . . . . . 59. 4.4.6. Estructura de clases . . . . . . . . . . . . . . . . . . . . . . . 60 vii.
(10) 4.5. 4.6. Estructura del frontend . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.5.1. Maquetación web y presentación de la información. 4.5.2. Interacción del usuario y dinamización Javascript . . . . . . . 63 4.5.2.1. Estructura de módulos Javascript-RequireJS del website . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64. 4.5.2.2. Estructura de módulos Javascript-RequireJS de la administración . . . . . . . . . . . . . . . . . . . . . 65. Implementación de los casos de uso . . . . . . . . . . . . . . . . . . . 65. 5 Optimización 5.1. 5.2. 67. Optimización de imágenes . . . . . . . . . . . . . . . . . . . . . . . . 68 5.1.1. Cropping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70. 5.1.2. Focusing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71. 5.1.3. Zooming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71. 5.1.4. Thumbnails . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72. 5.1.5. Compresión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73. 5.1.6. Proceso combinado de técnicas de optimización . . . . . . . . 73. 5.1.7. Implementación de las técnicas de optimización de imágenes . 76 5.1.7.1. Implementación de focusing . . . . . . . . . . . . . . 78. 5.1.7.2. Implementación de thumbnails . . . . . . . . . . . . 81. 5.1.7.3. Implementación de zooming . . . . . . . . . . . . . . 82. 5.1.7.4. Implementación del cropping . . . . . . . . . . . . . 83. 5.1.7.5. Implementación de compresión . . . . . . . . . . . . 85. Otras técnicas para optimizar rendimiento . . . . . . . . . . . . . . . 86 5.2.1. Minimización y ofuscación de recursos de código . . . . . . . . 86. 5.2.2. Compresión de recursos. . . . . . . . . . . . . . . . . . . . . . 87. 5.2.2.1. Compresión estática . . . . . . . . . . . . . . . . . . 87. 5.2.2.2. Compresión dinámica . . . . . . . . . . . . . . . . . 87. 5.2.3. Reducción de peticiones a servidor: Sprites y AJAX . . . . . . 88. 5.2.4. Cacheo de aplicación . . . . . . . . . . . . . . . . . . . . . . . 89. 5.2.5. Uso de CDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90. 6 Conclusiones 6.1. . . . . . . 61. 91. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 viii.
(11) A Arquitectura de servidores para la aplicación. 95. A.1 Alto rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 A.2 Alta disponibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 A.3 Configuración completa de la arquitectura . . . . . . . . . . . . . . . 97 Referencias. 99. ix.
(12)
(13) Índice de figuras 2.1. Modelo de artistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11. 2.2. Modelo de Art Buying . . . . . . . . . . . . . . . . . . . . . . . . . . 12. 2.3. Otros modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12. 2.4. Universo completo de la aplicación . . . . . . . . . . . . . . . . . . . 13. 2.5. Arquitectura Software Completa . . . . . . . . . . . . . . . . . . . . . 19. 3.1. Caso de uso 1: Acceder al website . . . . . . . . . . . . . . . . . . . . 24. 3.2. Caso de uso 2: Seleccionar idioma . . . . . . . . . . . . . . . . . . . . 25. 3.3. Caso de uso 3: Navegar el carrusel principal . . . . . . . . . . . . . . 25. 3.4. Caso de uso 4: Suscribirse a la newsletter . . . . . . . . . . . . . . . . 26. 3.5. Caso de uso 5: Navegar a las redes sociales . . . . . . . . . . . . . . . 27. 3.6. Caso de uso 6: Renderizar galerı́a de instagram. 3.7. Caso de uso 7: Navegar a secciones de artistas . . . . . . . . . . . . . 28. 3.8. Caso de uso 8: Seleccionar artista . . . . . . . . . . . . . . . . . . . . 29. 3.9. Caso de uso 9: Seleccionar imagen de artista . . . . . . . . . . . . . . 30. . . . . . . . . . . . . 28. 3.10 Caso de uso 10: Salir de pantalla de imagen única de artista . . . . . 30 3.11 Caso de uso 11:Seleccionar vı́deo de artista . . . . . . . . . . . . . . . 31 3.12 Caso de uso 12: Salir de pantalla de vı́deo único . . . . . . . . . . . . 32 3.13 Caso de uso 13: Navegar a sección de art buying . . . . . . . . . . . . 32 3.14 Caso de uso 14: Seleccionar campaña . . . . . . . . . . . . . . . . . . 33 3.15 Caso de uso 15: Seleccionar imagen de campaña . . . . . . . . . . . . 34 3.16 Caso de uso 16: Salir de pantalla de imagen única de campaña . . . . 34 3.17 Caso de uso 17: Navegar a la página de contacto . . . . . . . . . . . . 35 3.18 Caso de uso 18: Enviar mensaje de contacto . . . . . . . . . . . . . . 36 3.19 Diagrama de casos de uso de la aplicación . . . . . . . . . . . . . . . 37 3.20 Diagrama de navegación del Website . . . . . . . . . . . . . . . . . . 38 xi.
(14) 3.21 Diagrama de navegación del CMS . . . . . . . . . . . . . . . . . . . . 40 3.22 Diagrama E/R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.1. Comparativa de frameworks PHP en 2017 - Interés en el tiempo . . . 53. 4.2. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61. 4.3. Ejemplo de estructura HTML5 construida . . . . . . . . . . . . . . . 62. 4.4. Estructura de módulos javascript del website . . . . . . . . . . . . . . 64. 4.5. Estructura de módulos javascript de la administración . . . . . . . . . 65. 4.6. Diagrama de secuencia de caso de uso 8 . . . . . . . . . . . . . . . . . 65. 5.1. Proceso de gestión de imágenes en la aplicación CMS + web . . . . . 68. 5.2. Proceso de subida y optimización de imágenes . . . . . . . . . . . . . 69. 5.3. Ejemplo de proceso de subida y optimización de imágenes. 5.4. Ejemplo de cropping . . . . . . . . . . . . . . . . . . . . . . . . . . . 70. 5.5. Ejemplo de focusing. 5.6. Ejemplo de zooming . . . . . . . . . . . . . . . . . . . . . . . . . . . 72. 5.7. Ejemplo de thumbnails . . . . . . . . . . . . . . . . . . . . . . . . . . 72. 5.8. Ejemplo de compression . . . . . . . . . . . . . . . . . . . . . . . . . 73. 5.9. Ejemplo de uso aislado de compresión . . . . . . . . . . . . . . . . . . 74. . . . . . . 69. . . . . . . . . . . . . . . . . . . . . . . . . . . . 71. 5.10 Proceso erroneo de combinación de optimizaciones . . . . . . . . . . . 75 5.11 Proceso correcto de combinación de optimizaciones . . . . . . . . . . 75 5.12 Ejemplo de edición de imagen . . . . . . . . . . . . . . . . . . . . . . 76 5.13 Módulos de optimización en aplicación front . . . . . . . . . . . . . . 77 5.14 Diagrama de clases de optimización en aplicación back . . . . . . . . 78 5.15 Ejemplo de uso de foco . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.16 Transformaciones del foco . . . . . . . . . . . . . . . . . . . . . . . . 80 5.17 Pantallazo de thumbnails en administración . . . . . . . . . . . . . . 81 5.18 Pantallazo de control de zoom en administración . . . . . . . . . . . . 83 5.19 Ejemplo de minificación+ofuscación . . . . . . . . . . . . . . . . . . . 86 5.20 Ejemplo de combinación de imágenes en un sprite como imagen única 89 6.1. Proceso de optimización web . . . . . . . . . . . . . . . . . . . . . . . 91. 6.2. Proceso de optimización web aplicado a VF . . . . . . . . . . . . . . 92. A.1 Arquitectura propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . 97 xii.
(15) Índice de tablas 2.1. Universo de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . 10. 2.2. Caracterı́sticas de artistas representados . . . . . . . . . . . . . . . . 14. 2.3. Caracterı́sticas de artistas externos . . . . . . . . . . . . . . . . . . . 14. 2.4. Caracterı́sticas de campañas . . . . . . . . . . . . . . . . . . . . . . . 14. 2.5. Caracterı́sticas de fotógrafos . . . . . . . . . . . . . . . . . . . . . . . 15. 2.6. Caracterı́sticas de ilustradores . . . . . . . . . . . . . . . . . . . . . . 15. 2.7. Caracterı́sticas de directores de arte . . . . . . . . . . . . . . . . . . . 15. 2.8. Caracterı́sticas de imágenes . . . . . . . . . . . . . . . . . . . . . . . 16. 2.9. Caracterı́sticas de imágenes según el tipo de imagen . . . . . . . . . . 16. 2.10 Caracterı́sticas de videos . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.11 Caracterı́sticas de clientes/agencias . . . . . . . . . . . . . . . . . . . 17 2.12 Caracterı́sticas de newsletter . . . . . . . . . . . . . . . . . . . . . . . 17 2.13 Caracterı́sticas de usuarios . . . . . . . . . . . . . . . . . . . . . . . . 17 2.14 Caracterı́sticas de contactos . . . . . . . . . . . . . . . . . . . . . . . 18 2.15 Caracterı́sticas de mensajes de contacto . . . . . . . . . . . . . . . . . 18 3.1. Caso de uso 1: Acceder al website . . . . . . . . . . . . . . . . . . . . 24. 3.2. Caso de uso 2: Seleccionar idioma . . . . . . . . . . . . . . . . . . . . 25. 3.3. Caso de uso 3: Navegar el carrusel principal . . . . . . . . . . . . . . 26. 3.4. Caso de uso 4: Suscribirse a la newsletter . . . . . . . . . . . . . . . . 27. 3.5. Caso de uso 5: Navegar a las redes sociales . . . . . . . . . . . . . . . 27. 3.6. Caso de uso 6: Renderizar galerı́a de instagram. 3.7. Caso de uso 7: Navegar a secciones de artistas . . . . . . . . . . . . . 29. 3.8. Caso de uso 8: Seleccionar artista . . . . . . . . . . . . . . . . . . . . 29. 3.9. Caso de uso 9: Seleccionar imagen de artista . . . . . . . . . . . . . . 30. . . . . . . . . . . . . 28. 3.10 Caso de uso 10: Salir de pantalla de imagen única de artista . . . . . 31 xiii.
(16) 3.11 Caso de uso 11: Seleccionar vı́deo de artista . . . . . . . . . . . . . . 31 3.12 Caso de uso 12: Salir de pantalla de vı́deo único . . . . . . . . . . . . 32 3.13 Caso de uso 13: Navegar a sección de art buying . . . . . . . . . . . . 33 3.14 Caso de uso 14: Seleccionar campaña . . . . . . . . . . . . . . . . . . 33 3.15 Caso de uso 15: Seleccionar imagen de campaña . . . . . . . . . . . . 34 3.16 Caso de uso 16: Salir de pantalla de imagen única de campaña . . . . 35 3.17 Caso de uso 17: Navegar a la página de contacto . . . . . . . . . . . . 35 3.18 Caso de uso 18: Enviar mensaje de contacto . . . . . . . . . . . . . . 36. xiv.
(17) Resumen El texto aquı́ expuesto corresponde a la realización del trabajo fin de carrera (TFC) de la Facultad de Informática de la Universidad Politéctica de Madrid de Raúl Gómez Garcı́a. La aplicación del proyecto es real. Se ha realizado esta implementación con la intención de generar una aplicación web corporativa para una productora de publicidad gráfica de Madrid, con lo que todas las fases descritas se aplican a un cliente real y junto a un equipo real (equipo participante en las partes no técnicas, como pueden ser un traductor, editores de contenido y diseñadores gráficos). Se pretende explicar con este texto la capacidad del autor del proyecto de crearlo al completo participando y desarrollando todas las fases, demostrando ası́ la dedicación del mismo a este tipo de proyectos u otros similares en el entorno empresarial actual relacionado con el desarrollo de software en la red. Se ha desarrollado un proyecto web completo. Ésta es la base de este trabajo. Los pormenores especı́ficos de la aplicación web desarrollada se explican en este libro, pero todo se basa en un conjunto de fases completadas (en su parte técnica) al 100 % por mi: • Toma de requisitos y análisis del problema. • Análisis técnico y planteamiento de la solución. • Diseño técnico de la solución. • Decisión de tecnologı́as a utilizar. • Implementación de la aplicación web. • Documentación técnica • Puesta en marcha Lo que se intenta con este proyecto es exponer la forma de construir un proyecto web corporativo para llegar a conseguir un producto que, funcionalmente, sea lo más óptimo posible, siguiendo ciertas reglas de importacia de funcionamiento y rendimiento de la misma. Se tienen en cuenta aquı́ dos premisas fundamentales para conseguir nuestro objetivo: xv.
(18) • Premisa 1: Optimización del rendimiento de la web (en base a diferentes parámetros) • Premisa 2: Optimización del código para mejorar la mantenibilidad de la aplicación web. Estas dos premisas son fundamentales y son la base de este trabajo. Se mezclan y se tienen en cuenta en cada paso del proceso del proyecto. En el capı́tulo 1 , de introducción, se explica más detalladamente el razonamiento de esta conclusión. Ya después en el capı́tulo 2 se entrará directamente en materia, explicando el proceso seguido correspondiente a las fases previas a la implementación, también importantes para llevar a cabo un proyecto de calidad. En el capı́tulo 3 se explicará la estructura de la aplicación web. Se comentará aquı́ el diseño técnico y el porqué de las decisiones tomadas, tanto en cuanto a las tecnologı́as utilizadas como a la estructura y modularización de los ficheros y clases de la aplicación. Por tanto aquı́ se tendrá siempre en cuenta nuestra premisa de optimización número 1: Mantenibilidad de la aplicación. Tras la exposición de la implementación en el capı́tulo 4 de forma detallada, se pasará a especificar una de las caractarı́sticas más importantes de este proyecto ya en el capı́tulo 5, la optimización del rendimiento de la web, nuestra premisa número 2. Esta optimización se refiere a un conjunto de mejoras a través de ampliaciones y cambios en la implementación del código fuente o en la configuración del servidor, pero siempre con el fin último de conseguir nuestra premisa número 2. Éstas optimizaciones se basan sobre todo en la transformación de imágenes digitales para su optimización web: cropping + focusing + zooming + thumbnails + compression. Por último, las conclusiones y objetivos del proyecto, intentarán explicar lo conseguido en el mismo y el trabajo futuro.. xvi.
(19) Capı́tulo 1 Introducción Internet, una cantidad ingente de datos e información compartida; el mundo de la red o la nube está a la orden del dı́a y el mayor porcentaje de utilización de todos los recursos se practica a través de páginas y aplicaciones web. Cualquier persona que use mı́nimamente cualquier dispositivo tecnológico es usuario de aplicaciones web. Existen muchas formas diferentes de crear una aplicación web, pero no todas estas formas son del todo correctas. Uno de los problemas de las diferencias de calidad de las aplicaciones web es la demanda en el mercado; cualquier persona, empresa o entidad puede requerir de los servicios de un sistema web, ya sea para vender un producto o servicio o simplemente para exponer sus ideas. Existe tanta demanda que cada vez hay más desarrolladores dispuestos a trabajar generando este tipo de aplicaciones, aunque no todas ellas están óptimamente desarrolladas. Pero, ¿qué es una aplicación web óptima? ¿cómo debe construirse?. La idea principal que debemos seguir para la construcción óptima se basa en lo que queremos conseguir, no en cómo debemos construir la aplicación; aunque importante, ya veremos cómo construirla, una vez tengamos claros nuestros objetivos.. 1.1. Objetivos de una web corporativa. En el caso que nos ocupa. Los objetivos de una web corporativa no son fáciles de adivinar; se requiere de un proceso de análisis de nuestro público, de un estudio de mercado, etc... (no profundizaremos en el estudio de marketing digital. Pero sı́ que podemos asumir ciertos objetivos mı́nimos de cualquier web corporativa: • Objetivo de presentación: debe ser una tarjeta de visita eficaz. • Objetivo de posicionamiento: la web debe ayudar a posicionar a la empresa por delante de sus competidores. 1.
(20) 2. Introducción • Objetivo de ventas: la web debe aportar algún valor para ayudar a la empresa a mejorar sus ventas. • Objetivo de nuevos mercados: debe aportar valor para abrir nuevos mercados para la empresa.. Aunque realmente estos objetivos se basan en conocimientos de marketing diginal[7], que no es nuestro campo, hay que tenerlos muy claros desde el punto de vista técnico para poder llegar a construir el sitio de calidad que aporte estos valores a la empresa. Todos estos objetivos se consiguen gracias a muchos frentes diferentes, tales como un buen diseño gráfico que llame la atención o una buena estrategia de marketing que sepa qué tipo de contenidos deben estar incluı́dos en la web; pero uno de los puntos más importantes es que la web funcione. Esto lo conseguiremos gracias a nuestras técnicas de implementacion y optimización. Parece obvio decir que una web debe funcionar, pero cuando hablo del funcionamiento de una web corporativa me refiero a que la aplicación debe mantener al usuario; es muy fácil perder a un usuario visitante de nuestra página web; basta con que el sitio tarde más tiempo del que un usuario medio está dispuesto a esperar, y ese tiempo hoy en dı́a está bastante por debajo de unos pocos segundos. Aquı́ es donde está nuestro cometido: la aplicación debe funcionar y ser eficiente (alto rendimiento). Veamos qué tenemos que pensar sobre nuestra aplicación en cuanto a los objetivos descritos:. 1.1.1. Objetivo de presentación. Una web debe ser bonita, agradable y fácil de navegar. No es suficiente con que ponga lo que hace nuestra empresa, debe estar bien presentado, estructurado y debe ser usable. Estas caracterı́sticas tan básicas no son fáciles de llevar a cabo, pero en parte se consiguen gracias a un buen uso de las librerı́as y recursos gráficos (Javascript y CSS3 en nuestro caso). Si las animaciones, movimientos dentro de la web o incluso la estructura visual de la información no es agradable ni fácil de leer, el usuario no durará mucho dentro del sitio, se irá a buscar experiencias más gratificantes para la vista. Las causas más comunes de echar a perder este objetivo pueden ser: • Movimientos bruscos: si una web va a trompicones, puede ser desagradable de navegar. • Información disjunta y mal estructurada: el usuario quiere leer y conseguir la información rápidamente..
(21) 1.1 Objetivos de una web corporativa. 3. • Sonidos, imágenes o ventanas modales a destiempo: es muy incómodo tener popups o sonidos inesperados que dificultan la navegación y no aportan información adicional sobre lo que el usuario quiere y necesita. En definitiva, navegación lenta y desestructurada. Con lo que es importantı́sima la rapidez de navegación y recuperación de información del sitio web.. 1.1.2. Objetivo de posicionamiento. Normalmente cualquier empresa a medio o largo plazo desea posicionarse por encima del mayor número de competidores posibles en el mercado. Es un tema complejo, pero en el caso que nos ocupa, una buena parte de esta competición se consigue gracias al posicionamiento web (SEO). Hoy en dı́a las reglas de posicionamiento web las marcan los propios motores de búsqueda como Google o Bing. Hay muchas herramientas para medir este posicionamiento, y las más usadas son en gran parte creadas por las compañı́as dueñas de estos motores. Las técnicas de optimización SEO son muy variopintas y abarcan todos los campos que participan en la construcción de una web, desde la selección de palabras y contenidos correctos hasta, en nuestro caso, la correcta construcción de la aplicación: • Uso correcto de tags y atributos HTML5. • Uso correcto de las redirecciones del servidor. • Manejo o avolición de los errores de servidor. • Ayuda a los buscadores en forma de ficheros SEO: robots.txt o sitemap.xml • Carga rápida de la web. • Optimización multidispositivo.. 1.1.3. Objetivo de ventas. La web debe ayudar a la empresa a conseguir sus objetivos económicos. Para eso se construyó y es tan simple como que una empresa está creada para ganar dinero, con lo que el fin último de la web no será menos que éste. Quizás un website corporativo, que al final no es más que una presentación de la empresa, no podrá aportar de forma activa estas ganancias, pero sı́ debe estar pensada para no impedir esa formación natural de adeptos que aportarán esas ganancias a la empresa. La única forma de apoyar esta parte es construyendo una web.
(22) 4. Introducción • limpia y rápida, que agrade a estos clientes y los incite a seguir participando del objetivo de la empresa, • y permitiéndoles aportar sus valores e ideas al fin de la empresa. Es un gran valor permitir al usuario ofrecer un feedback a través de formularios o redes sociales; un camino de vuelta, no sólo tratarles como meros lectores de lo que queremos que oigan, vean o lean.. Por tanto es importante ofrecer formularios fáciles de usar y links, módulos o mashups usando redes sociales o aplicaciones externas que aporten este valor añadido.. 1.1.4. Objetivo de nuevos mercados. Abrirse a nuevos mercados es normalmente algo que todas las empresas desean a largo plazo, y esto debemos tenerlo en cuenta hoy mismo; no podemos pensar que la empresa se quede estancada y por tanto no podemos dejar nuestro sitio web estancado. La web debe evolucionar junto a la empresa, al mismo ritmo o más rápido aún, al ser nuestra carta de presentación al mundo. Por tanto, la web debe ser mantenible y fácilmente ampliable: • Debemos implementar un código legible y bien estructurado. Fácil de mantener. • Debemos generar una documentación técnica que explique correctamente los pormenores de la implementación. En el futuro no sabemos si seremos nosotros mismos los que mantengamos la aplicación, con lo que quien venga debe conseguir mantenerla de la misma forma que lo harı́amos nosotros.. 1.1.5. Conclusión sobre los objetivos. Podemos extraer de los apartados anteriores un conjunto de puntos que debemos tener en cuenta a la hora de crear nuestro sito web optimizado como web corporativa: 1. Web mantenible y estructurada. 2. Web visualmente agradable, usable y moderna. 3. Web rápida: optimización de rendimiento. 4. Web bien posicionada (SEO). 5. Web que ofrezca la posibilidad de colaborar al usuario. Estos puntos son en los que se ha centrado la optimización de la web en este proyecto..
(23) 1.2 Soluciones de optimización. 1.2. 5. Soluciones de optimización. A continuación se resumen las soluciones adoptadas para conseguir estas 5 conclusiones obligatorias para la optimización de la web corporativa.. 1.2.1. Web mantenible y estructurada. Éste parece un tema obvio, y realmente lo es; es obvio que necesitamos un código mantenible, bien estructurado y legible para que su mantenimiento y futuras ampliaciones sean lo más eficientes posible. En el caso de la web de una empresa es mucho más importante, ya que por definición, la empresa va a cambiar, va a evolucionar, y la web corporativa debe evolucionar con ella. Las soluciones que tenemos a nuestro alcance para generar un código mantenible son infinitas. La aplicación que nos ocupa, a la que llamaremos VF 1 , se basa en una arquitectura MVC 2 ampliada. No se usa esta arquitectura en toda la aplicación (se explicará después porqué), pero sı́ que existe una modularización del código que no está estructurado a través de MVC. Esto está conseguido: • en servidor: a través de un framework MVC-PHP llamado Laravel[5]. • en cliente: a través de una librerı́a de modularización Javascript llamada RequireJS[10]. Más adelante se explicarán estas tecnologı́as y cómo se ha usado para nuestro fin.. 1.2.2. Web visualmente agradable, usable y moderna. Éste es un tema muy subjetivo. Nadie puede decidir qué es más agradable o más moderlo, pero sı́ que existen un conjunto de estándares de usabilidad que ayudan en la construcción de sitios web. Lo primero que se aplicó durante la generación e las diferentes páginas web es el estándar de la W3C[11]. Este estándar nos ayuda a mejorar el sitio haciéndolo más accesible. Existen ciertos niveles estandarizados de accesibilidad web que se han intentado conseguir 1. VF no es más que un acrónimo del nombre de la aplicación/empresa del caso de estudio que nos ocupa. Se usará este acrónimo de ahora en adelante para agilizar la lectura 2 La arquitectura MVC es de las más usadas en web durante los últimos años. El uso de un modelo-vista-controlador es una de las claves para estructurar correctamente una aplicación y llegar al éxito de la mantenibilidad..
(24) 6. Introducción. Por otro lado se usaron un conjunto de reglas aprendidas de usabilidad[6, 1] aplicadas a la tecnologı́a web a través del lenguaje de marcado HTML5 junto con la estilización a través del uso de estilos CSS3 y dinamización Javascript.. 1.2.3. Web rápida: optimización de rendimiento. El rendimiento de un website es algo muy complejo, que no requiere de una única acción. Deben tomarse un conjunto muy amplio de medidas para que el rendimiento y velocidad de nuestra web sean lo más óptimos posibles. Ver [8] La particularidad de esta caracterı́stica es que no todas las aplicaciones web requieren del mismo tipo de medidas a tomar para mejorar el rendimiento. VF es una aplicación desarrollada para una empresa que produce publicidad gráfica. Aquı́ está el kid de las optimizaciones realizadas. Al ser una productora gráfica, el producto que se vende son básicamente imágenes. Las imágenes son la parte importante de esta empresa, ası́ está identificado y ahı́ es donde puede residir el principal problema de rendimiento de la web, ya que el volumen de imágenes será muy grande. Si el contenido de una web se va a basar sobre todo en visualizar imágenes, esta visualización tiene que ser exitosa en todo caso. El problema de las imágenes es que tienen sus propias caracterı́sticas internas y es más costoso de renderizar en un navegador web (obviamente más que un texto). Las imágenes tienen un formato, unas dimensiones y un peso en disco; éstas son las tres caracterı́sticas que pueden hacernos la vida imposible en cuanto al rendimiento de la web y son sobre las que se ha trabajado aquı́. Aunque se explicará en detalle más tarde (capı́tulo 5), las técnicas principales usadas para optimizar las imágenes de la aplicación son: • Cropping • Focusing • Thumbnails • Compresión Aunque parezcan técnicas disjuntas, realmente son parte de un todo: Recortaremos las imágenes de forma óptima, enfocándolas en un punto determinado y generando ası́ unos thumbnails comprimidos correctamente..
(25) 1.2 Soluciones de optimización. 1.2.4. 7. Web bien posicionada: SEO. Un buen posicionamiento SEO se construye progresivamente. Primero hay que seguir una serie de pautas recomendadas durante la construcción de la aplicación. Para esto fue bueno seguir de nuevo el estándar de W3C. Por otro lado, una vez la aplicación está construı́da son muy útiles ciertas herramientas de auditorı́a SEO para asegurarse de que todo está correcto e ir mejorando los puntos más débiles según los resultados de estas micro-auditorı́as autogeneradas. Más información sobre SEO en [12]. 1.2.5. Web colaborativa. Como se ha dicho, es importante que el usuario participe de los objetivos de la empresa. A través de la web las soluciones adoptadas son: • La inclusión de un formulario de contacto: un formulario abierto a través del cual el usuario puede expresar, proponer o preguntar sus dudas, inquietudes o propuestas. En este caso también es una vı́a directa de comunicación para aumentar el nivel de trabajo y por tanto de ganancias de la empresa. • El añadido de las redes sociales. Al ser una web orientada a la producción gráfica, a las imágenes, lo ideas es insertar algún aliciente de participación con redes sociales orientadas a imágenes: Instagram. Pero tampoco dejamos de lado el resto de redes sociales que pueden ayudar a presentar mejor a la empresa.. 1.2.6. Conclusión sobre soluciones adoptadas. Como se puede observar se han adoptado soluciones para todos los objetivos importantes a cubrir. Pero no es un trabajo sencillo y muchas veces combinar todas las soluciones de forma óptima es imposible, y hay que relajar el nivel de optimización de alguna de ellas para conseguir el de otras. Un claro ejemplo de esto puede ser el hecho de crear una aplicación one-page en la que todo el código fuente está en un sólo fichero; hay muchas posibilidades de que ese fichero sea ilegible, pero el código puede ser muy ligero y eficiente: no hay llamadas externas, no hay exceso de peticiones a disco o al server, el código podrı́a estar minimizado... Es un ejemplo que cubrirı́a perfectamente un sitio con un buen rendimiento, pero que tiene un código no muy mantenible y difı́cil de leer. En VF, se han intentado cubrir todas las soluciones, pero como se ha visto en el ejemplo siempre se podrı́a optimizar cada punto mucho más. Se ha intentado llegar a una solución intermedia para conseguir un mı́nimo en los 5 objetivos expuestos..
(26)
(27) Capı́tulo 2 Análisis y requisitos de la aplicación web La primera fase, el análisis de requisitos de la aplicación, para la construcción del sitio web corporativo para nuestra productora gráfica fue complétamente necesaria.. 2.1. Toma de requisitos. Se realizó una toma inicial de requisitos con el cliente. La intención final fue obtener una definición del sitio web, tanto funcional como de contenido. Ambas partes son necesarias para la construcción de nuestro sitio. En la reunión de toma de requisitos fue conveniente la participación de todas las partes que iban a participar en el proyecto: • Cliente. • Diseñadores gráficos. • Gestores de contenidos. • Desarrollador de la aplicación. No tiene demasiado sentido meterse en la toma de requisitos, pero sı́ es importante el resultado obtenido para entender bien la aplicación que se va a exponer más tarde en el capı́tulo sobre diseño e implementación de la misma. La definición obtenida fue un conjunto de palabras clave importantes para construir el universo de la aplicación. En estos conceptos se basa el desarrollo y las estructuras construidas: Se necesita una aplicación web para presentar la productora al público. 9.
(28) 10. Análisis y requisitos de la aplicación web Artistas Imágenes Fotógrafos Vı́deos Ilustradores Clientes Dirección de arte Agencias Art Buying Contacto Campañas Newsletter Tabla 2.1: Universo de la aplicación • La productora representa a un conjunto de artistas. Ahora mismo hay un conjunto cerrado, pero en el futuro se ampliará o incluso podrı́an cambiar los artistas actuales. • Hay 3 tipos de artistas en la producción gráfica: fotógrafos, ilustradores y directores de artes; estos últimos engloban también los gráficos y animaciones 3D. • La intención es que los clientes puedan acceder como usuarios y navegar por la web encontrando fácilmente: – Información clara de lo que hace la productora y de lo que es capaz de conseguir. – Información de los artistas a los que representa. Lo más importante de esta información es que vean el trabajo del equipo, es decir, imágenes y vı́deos con los trabajos tanto personales como comerciales realizados anteriormente por los artistas. • Habrá una división por tipos de artista; alguien podrı́a querer buscar únicamente ilustradores que encajen en su idea. • Existirá una sección para ver los trabajos anteriores de la productora, las campañas llevadas a cabo.Es importante saber de lo que es capaz y el resultado y calidad finales de los trabajos anteriores. Ésto será siempre visual: el resultado de los trabajos son las propias imágenes presentadas; es lo que se produce. A esto se le llama Art-Buying. • Se podrán ver todos los artistas de un tipo al mismo tiempo. • Se podrán ver todas las imágenes de cada uno de los artistas para ver el trabajo completo del mismo. Una especie de blog de presentación del artista. • Si el usuario/cliente necesitase ver las imágenes con más detalle, tendrı́a que poder fácilmente. • Habrá una sección de contacto con la que los usuarios podrán pedir más información o proponer futuros trabajos de producción o incluso pedir presupuestos..
(29) 2.2 Análisis del sistema. 11. • La web será multi-idioma: inglés por defecto y castellano. • Los usuarios se podrán suscribir a una newsletter a través de su email. • La aplicación debe ser multi-dispositivo. Muchos de los usuarios objetivo usarán portátiles, tablets o móviles para buscar información sobre la productora y quieren que esta búsqueda sea rápida y eficaz. En el mundo de la publicidad no hay demasiado tiempo que perder y el usuario se cansa rápido.. 2.2. Análisis del sistema. Una vez clarificados los requisitos de la aplicación a construir es hora de analizarlos y estructurarlos. A partir de la lista de requisitos y el universo de palabras clave anteriores obtenidos se crea un nuevo universo, pero esta vez, estructurado, para darle algún sentido y ver cómo se relacionan unos modelos con otros. Lo analizaremos modelos:. 2.2.1. Modelo de artistas. Los artistas son uno de los dos modelos fundamentales en que se basa la productora, con lo que analizaremos el sub-universo de los artistas como uno de los ejes centrales:. Figura 2.1: Modelo de artistas Los artistas crean las imágenes. Son los autores de las fotografı́as, ilustraciones o vı́deos creados tanto a nivel personal como a nivel comercial. Son sus trabajos, sus productos finales y, por tanto, la representación multimedia de estos trabajos se relaciona directamente con ellos. Además tenemos que tener en cuenta la distinción de los 3 tipos de artistas existentes:fotógrafos, ilustradores y directores de arte..
(30) 12. 2.2.2. Análisis y requisitos de la aplicación web. Modelo de art-buying. El segundo eje fundamental del universo de la productora son sus campañas, englobadas con el nombre de art-buying:. Figura 2.2: Modelo de Art Buying Las campañas publicitarias son el resultado del trabajo de la productora; al ser una productora gráfica el resultado final de cada campaña son estas imágenes y vı́deos con las que se relaciona cada campaña. Pero las campañas no se llevan a cabo solas, se relacionan con los clientes directamente, ya que sus ilustraciones o fotografı́as son el producto vendido a los mismos. El cliente final, en el 99 % de los casos contratará a una agencia de publicidad, que es la que realiza la parte creativa que traslada a la productora para que ejecute y consiga el resultado esperado a través de uno de los artistas representados, que es el que ilustrará o fotografiará esa propuesta creativa. Por tanto, las campañas son el centro de casi la totalidad de modelos participantes en el proyecto. Son el trabajo final de la productora que se ha de mostrar con toda esa información adicional sobre clientes, agencias y artistas.. 2.2.3. Otros modelos. Como se ha comentado en la fase de requisitos, hay alguna funcionalidad adicional requerida que aporta algo más a la aplicación, pero que no se relaciona directamente con el resto de modelos del universo.. Figura 2.3: Otros modelos.
(31) 2.2 Análisis del sistema. 13. Existirá una página de contacto en la que aparecen tanto el formulario de contacto como un conjunto de datos de contacto de las personas que conforman la empresa. Esto le da la suficiente entidad como para formar un modelo diferente. Igualmente ocurre con la newsletter. Tendrá que existir una funcionalidad especı́fica para manejar boletines en fechas determinadas y a la que se inscriban los diferentes usuarios.. 2.2.4. Análisis detallado. Con esta mı́nima especificación ya tendrı́amos el punto de inicio para poder comenzar a diseñar la aplicación como tal. Pero vamos a ir un paso más allá y a profundizar en cada una de los modelos anteriores, intentando generar un diagrama general del universo completo de la aplicación.. Figura 2.4: Universo completo de la aplicación Para simplificar el diagrama, no se añaden todas las caracterı́sticas de cada uno de los modelos del universo. Se exponen estas caracterı́sticas en detalle a continuación. No tiene sentido en este caso tratar como diferentes las imágenes de los artistas y de las campañas. El trato que se les va a dar es exáctamente el mismo, sólo que la una imagen se corresponderá con un artista y otra con una campaña, pero el manejo interno de la aplicación será similar. Con los artistas no ocurre exáctamente lo mismo. Una campaña podrı́a estar realizada con un artista externo a los representados, con lo que no tendrı́a las mismas.
(32) 14. Análisis y requisitos de la aplicación web. caracterı́sticas que un artista interno a efectos de la aplicación. Por lo tanto tenemos que usar dos entidades diferentes para artistas representados y artistas externos. 2.2.4.1. Caracterı́sticas identificadas: Artistas Representados. En cuanto a información sobre artistas representados por la productora será suficiente con el nombre y una biografı́a a nivel informativo y por supuesto un artista debe tener sus imágenes y vı́deos relacionados. Entidad Artista. Caracterı́sticas Nombre Biografı́a Imágenes Vı́deos. Tabla 2.2: Caracterı́sticas de artistas representados. 2.2.4.2. Caracterı́sticas identificadas: Artistas Externos. Los artistas externos en cambio no tienen datos internos en la aplicación. Solamente los relacionaremos a través de su nombre para identificarlo dentro de las campañas realizadas. Entidad Artista externo. Caracterı́sticas Nombre. Tabla 2.3: Caracterı́sticas de artistas externos. 2.2.4.3. Caracterı́sticas identificadas: Campañas. Las campañas son los modelos que más se relacionan con el resto de ellos. Como se ha dicho, son el eje central de la empresa y son los productos finales de la productora. Se requiere, a parte de sus caracterı́sticas especı́ficas, una relación con otros modelos como los artistas, imágenes que componen la campaña, agencias y clientes. Entidad. Campaña. Caracterı́sticas Nombre Artista Imágenes Agencia Cliente. Tabla 2.4: Caracterı́sticas de campañas.
(33) 2.2 Análisis del sistema. 2.2.4.4. 15. Caracterı́sticas identificadas: Fotógrafos. Los fotógrafos no son más que un tipo de artista, con lo que tendrá las mismas caracterı́sticas que estos: Entidad Fotógrafo. Caracterı́sticas Nombre Biografı́a Imágenes Vı́deos. Tabla 2.5: Caracterı́sticas de fotógrafos 2.2.4.5. Caracterı́sticas identificadas: Ilustradores. Lo mismo ocurre con los ilustradores. Ninguna caracterı́stica especial los diferencia a nivel de aplicación. Entidad Ilustrador. Caracterı́sticas Nombre Biografı́a Imágenes Vı́deos. Tabla 2.6: Caracterı́sticas de ilustradores 2.2.4.6. Caracterı́sticas identificadas: Directores de arte. Igualmente para los directores de arte. Entidad Director de arte. Caracterı́sticas Nombre Biografı́a Imágenes Vı́deos. Tabla 2.7: Caracterı́sticas de directores de arte 2.2.4.7. Caracterı́sticas identificadas: Imágenes. Las imágenes, base de nuestro proyecto de optimización, también tienen una serie de datos relacionados que las describe y que se mostrarán en la web: No todas las imágenes tendrán todas estas caracterı́sticas, pero al tratar todas las imágenes por igual las añadiremos para todas ellas. Las diferencias de información para cada tipo de imagen serı́an las de la tabla:.
(34) 16. Análisis y requisitos de la aplicación web Entidad. Images. Caracterı́sticas Nombre Artista Serie Campaña Agencia Cliente. Tabla 2.8: Caracterı́sticas de imágenes Tipo de imagen. Imagen de campaña. Imagen personal de artista. Imagen comercial de artista. Caracterı́sticas Nombre Artista Campaña Agencia Cliente Nombre Artista Serie Nombre Artista Agencia Cliente. Tabla 2.9: Caracterı́sticas de imágenes según el tipo de imagen 2.2.4.8. Caracterı́sticas identificadas: Vı́deos. Los vı́deos no se diferenciarı́an en nada de las imágenes en cuanto a sus caracterı́sticas. Los trataremos como un recurso multimedia de la misma forma: Entidad. Video. Caracterı́sticas Nombre Artista Serie Campaña Agencia Cliente. Tabla 2.10: Caracterı́sticas de videos. 2.2.4.9. Caracterı́sticas identificadas: Clientes y Agencias. Sólo necesitaremos el nombre de las agencias y clientes relacionados. El único uso será informativo..
(35) 2.2 Análisis del sistema. 17. Entidad Agencia/Cliente. Caracterı́sticas Nombre. Tabla 2.11: Caracterı́sticas de clientes/agencias 2.2.4.10. Caracterı́sticas identificadas: Newsletter. Los boletines serán entidades construidas para ser enviadas a través del correo electrónico. Para dar un buen servicio de newsletter en el que la productora no tenga que perder demasiado tiempo construyéndolas, se le proporcionará un conjunto de plantillas que podrá reutilizar con ciertos cambios mı́nimos para su envı́o a la lista de usuarios: Entidad. Newsletter. Caracterı́sticas Nombre Plantilla Fecha Tı́tulo Contenido Usuarios. Tabla 2.12: Caracterı́sticas de newsletter. 2.2.4.11. Caracterı́sticas identificadas: Usuarios. Los usuarios serán utilizados únicamente para su subscripción a la recepción de boletines, ası́ que, como se ha comentado, el único dato necesario serı́a la dirección de email de cada usuario. Entidad Usuario. Caracterı́sticas Email. Tabla 2.13: Caracterı́sticas de usuarios. 2.2.4.12. Caracterı́sticas identificadas: Contacto. Los datos de contacto podrı́an variar según el personal en cada momento dentro de la productora, con lo que se requieren almacenar ciertos datos de cada una de las personas de contacto implicadas: Pero además existen otras caracterı́sticas relacionadas con el contacto de la web. Al introducir un formulario de contacto, se enviarán mensajes a los administradores del sitio por email. Pero podrı́amos querer controlar también estos mensajes. Manejarlos históricamente y almacenarlos o realizar cualquier otra funcionalidad con.
(36) 18. Análisis y requisitos de la aplicación web Entidad Contacto. Caracterı́sticas Nombre Email Teléfono. Tabla 2.14: Caracterı́sticas de contactos ellos, con lo que existen un conjunto de caracterı́sticas relacionadas con los mensajes de contacto de la apliación: Entidad Mensajes de contacto. Caracterı́sticas Nombre de usuario Email Asunto del mensaje Texto del mensaje. Tabla 2.15: Caracterı́sticas de mensajes de contacto. 2.3. Arquitectura de aplicación. Antes de entrar en detalle en cada funcionalidad especı́fica de la aplicación tenemos que saber exáctamente cómo queremos que sea nuestra aplicación a un nivel de abstracción mayor; lo haremos a través de la arquitectura de la aplicación. No se explica aquı́ la arquitectura hardware que se usará, no es el objetivo de este trabajo, a parte de que la arquitectura hardware y de servidores podrá tener múltiples formas dependiendo de los objetivos de la propia apliación. Se puede leer el apéndice ?? para más información sobre la arquitectura de servidores propuesta para este tipo de aplicaciones web. Existirán varios roles de usuarios dentro de la aplicación: • Usuario • Administrador Sı́, administrador; no habı́amos hablado hasta el momento de administrar nada, pero esta parte es muy importante para nuestro cometido de optimización, como se verá en el capı́tulo 5, por lo que nuestro sistema se transforma en dos sub-aplicaciones diferentes: • Website: aplicación que verá el usuario público y utilizará el actor Usuario. Esta aplicación expone al público los datos y contenidos almacenados de forma visual, agradable y usable..
(37) 2.4 Resumen de casos de uso. 19. • CMS: aplicación/gestor de contenidos que usará el actor Administrador y que servirá para gestionar los contenidos que aparecerán después en el Website. Esta gestión se realiza a través de un entorno gráfico útil para el administrador para conseguir añadir y editar los datos de forma eficiente. Ambos entornos, como se podrá suponer, usan los mismos datos internos. El administrador introduce los contenidos desde el CMS y el usario los visualiza desde el website; por tanto existe una base de datos compartida. Además del uso compartido del disco fı́sico; esto será necesario para el almacenamiento y recuperación de imágenes y vı́deos.. Figura 2.5: Arquitectura Software Completa Como se observa en la imagen 2.5, el CMS usa los recursos (base de datos y disco) tanto en modo lectura como en modo escritura; es el que se encarga de almacenar los cambios en los datos. El webiste sólo se encarga de recuperar los datos (modo lectura) y mostrarlos como un sitio web. Además, el website se encarga de leer otros datos externos a través de apis REST, como pueden ser, redes sociales, mapas, etc...cualquier tipo de dato que no se almacena en el servidor propio pero sı́ en servidores externos.. 2.4. Resumen de casos de uso. Se listan ahora los casos de uso posibles dentro de la aplicación[3][4]. Será una descripción abierta y resumida del uso de los modelos descritos; más tarde en el.
(38) 20. Análisis y requisitos de la aplicación web. siguiente capı́tulo se detallarán estos casos de uso formalmente a través de diagramas para observar el comportamiento exacto de la aplicación. Vamos a dividir los casos de uso en dos conjuntos diferentes a partir de los diferentes actores que participarán en la aplicación: • Usuario : Website • Administrador: CMS. 2.4.1. Casos de uso: Website. El website está exclusivamente construido para la visualización pública a usuarios, con lo que éstos serán los actores de nuestros casos de uso. Los usuarios van a poder visualizar diferentes situaciones en la web: 1. Acceso al website 2. Seleccionar de idioma. 11. Seleccionar vı́deo de artista 12. Salir de pantalla de vı́deo único. 3. Navegar del carrusel principal 4. Suscribirse a la newsletter. 13. Navegar a sección de art buying. 5. Navegar a las redes sociales. 14. Seleccionar campaña. 6. Visualizar imágenes de Instagram. 15. Seleccionar imagen de campaña. 7. Navegar a secciones de artistas 8. Seleccionar artista 9. Seleccionar imagen de artista 10. Salir de pantalla de imagen única de artista. 2.4.2. 16. Salir de pantalla de imagen única de campaña 17. Navegar a la página de contacto 18. Enviar mensaje de contacto. Casos de uso: CMS. El CMS está construido para el uso exclusivo de los administradores/editores de contenidos de la aplicación. Los casos de uso para el CMS serı́an los siguientes: 1. Acceder al CMS. 4. Navegar a la lista de artistas. 2. Login al CMS. 5. Ordenar artistas. 3. Navegar por el Dashboard del CMS. 6. Eliminar artista.
(39) 2.4 Resumen de casos de uso. 21. 7. Publicar/Despublicar artista. 24. Publicar/Despublicar contacto. 8. Añadir nuevo artista. 25. Añadir nuevo contacto. 9. Editar datos de artista. 26. Editar contacto. 10. Eliminar imagen de artista. 27. Navegar a la lista de agencias. 11. Editar datos de imagen de artista. 28. Eliminar de agencia. 12. Editar thumbnails de imagen de artista. 29. Añadir de nueva agencia. 13. Navegar a la lista de campañas. 30. Editar de agencia. 14. Ordenar campañas. 31. Navegar a la lista de clientes. 15. Eliminar campaña. 32. Eliminar de cliente. 16. Publicar/Despublicar campaña. 33. Añadir de nueva cliente. 17. Añadir nueva campaña. 34. Editar de cliente. 18. Editar datos de campaña. 35. Editar de imágenes de carrusel de homepage. 19. Eliminar imagen de campaña 20. Editar thumbnails de imagen de campaña 21. Navegar a la lista de contactos 22. Ordenar contactos 23. Eliminar contacto. 36. Eliminar de imagen del carrusel de homepage 37. Editar de thumbnails de imagen de carrusel de homepage 38. Editar de imagen de sección de portada.
(40)
(41) Capı́tulo 3 Diseño abstracto del software Una vez analizados los requisitos principales del sistema que queremos contruir y una vez tenemos identificado y detallado el universo que vamos a usar para construirlo, podemos comenzar a generar el diseño técnico de la aplicación. En principio no tendrı́a porqué hacer falta conocer la tecnologı́a que se va a usar para generar un diseño correcto del software, pero vamos a usar un framework especı́fico. Este framework nos condiciona ya que nos va a proporcionar una estructura de directorios base y una arquitectura MVC ampliada con un conjunto de módulos predefinidos que nos facilitará el proceso de generación del proyecto. En cualquier caso, tenemos que realizar el diseño especı́fico para el universo obtenido; el framework nos va a ayudar en esta tarea, pero a un nivel mucho más especı́fico y cercano a la implementación. Con lo que vamos por pasos: 1. En este capı́tulo construiremos un diseño genérico a partir del universo abstracto generado. 2. Después en el capı́tulo 4 trasladaremos ese diseño a la arquitectura MVC ampliada de nuestro framework y podremos generar una estructura de clases real y especı́fica.. 3.1. Casos de uso. Se describen a continuación los casos de uso de la aplicación. Cada caso de uso se transforma en un diagrama del caso de uso y una tabla descriptiva para comprender bien el objetivo de cada caso de uso. Para no agobiar en exceso al lector se plantean solamente, a modo de idealización del trabajo realizado, los casos de uso del website. De forma similar serı́an los casos de uso de la administración con las operaciones de escritura de los datos de artistas, campañas, contacto, etc... 23.
(42) 24. 3.1.1. Diseño abstracto del software. Casos de uso: Website. Los casos de uso relacionados con el website con en los que participa directamente el actor Usuario. 3.1.1.1. Caso de uso 1: Acceder al website. Figura 3.1: Caso de uso 1: Acceder al website Nombre Propósito. Descripción. Pre-condiciones Post-condiciones. Acceso al website Visualizar la página inicial o homepage. La entrada en el website comienza con la escritura en la lı́nea de direcciones de un navegador web uno de los dominios asociados a la aplicación web. Esto desencadenará un acceso a la página inicial de la web. Por supuesto, se podrı́a escribir unaURL diferente a la URL base, pero aquı́ describimos el acceso inicial; el resto de accesos ocurrirána partir de acciones realizadas sobre la web, y por tanto serán otros casos de uso diferentes. El dominio escrito es correcto y dirige a la página inicial. Se visualizarán todos los componentes de la homepage: carrusel de imágenes, secciones, menú, presentación, header y footer con la información correcta extraı́da de BD y disco. Se visualizarán los textos en el idioma de la petición (dependiente del dominio escrito). Tabla 3.1: Caso de uso 1: Acceder al website. 3.1.1.2. Caso de uso 2: Seleccionar idioma. Diagrama y descripción para la selección de un idioma para la página..
(43) 3.1 Casos de uso. 25. Figura 3.2: Caso de uso 2: Seleccionar idioma. Nombre Propósito. Descripción. Pre-condiciones Post-condiciones. Seleccionar idioma Visualizar el sitio con los textos traducidos al idioma seleccionado Desde cualquier página del sitio web podremos seleccionar desde la cabecera el idioma que deseamos. Bastará con seleccionarlo y el propio sitio nos mostrará el sitio traducido. Otra opción es escribir el idioma en la URL con la regla que se decida; por ejemplo: misitio.com/es/ El sitio está en otro idioma diferente al que se desea seleccionar. Se redirigirá a la Home del sitio visualizando los textos de esta página inicial en el idioma seleccionado. Tabla 3.2: Caso de uso 2: Seleccionar idioma. 3.1.1.3. Caso de uso 3: Navegar el carrusel principal. Diagrama y descripción la navegación del carrusel de imágenes de la home.. Figura 3.3: Caso de uso 3: Navegar el carrusel principal.
(44) 26. Diseño abstracto del software. Nombre Propósito. Descripción. Pre-condiciones. Post-condiciones. Navegación del carrusel principal Visualización total o parcial de las imágenes del carrusel, automática o manualmente. Desde la homepage aparecerá el carrusel. En principio las imágenes dispuestas en el mismo irán avanzando automáticamente cada x milisegundos definidos. El usuario podrı́a saltar de una a otra imagen en cualquier momento sin seguir el orden establecido. Existen imágenes definidas por el administrador asignadas al carrusel de la home. Si el usuario no interactúa, el carrusel seguirá su curso y volverá al principio cuando termine la secuencia de imágenes. Si el usuario interactúa y elige una imagen para visualizar, el movimiento automático del carrusel finalizará para permitir al usuario manejar el carrusel a su antojo.. Tabla 3.3: Caso de uso 3: Navegar el carrusel principal. 3.1.1.4. Caso de uso 4: Suscribirse a la newsletter. Diagrama y descripción para la suscripción al boletı́n de noticias.. Figura 3.4: Caso de uso 4: Suscribirse a la newsletter.
(45) 3.1 Casos de uso Nombre Propósito. Descripción. Pre-condiciones Post-condiciones. 27 Suscribirse a la newsletter Añadir al usuario a una lista de suscripción interna que se usará en el futuro para enviar a ese usuario correos con noticias y actualizaciones sobre la productora. Se hará a través de su dirección de email únicamente. Desde la homepage el usuario podrá suscribirse añadiendo su dirección de correo a un formulario y presionando un botón de suscripción. Con esto aceptará ciertos términos para recibir estos boletines periódicos. El usuario no se ha suscrito aún con el email que introducirá en el formulario de suscripción. Se añadirá el email a la lista de suscriptores. Si el usuario ya está suscrito aparecerá un mensaje de error en la suscripción. No se puede suscribir dos veces.. Tabla 3.4: Caso de uso 4: Suscribirse a la newsletter. 3.1.1.5. Caso de uso 5: Navegar a las redes sociales. Diagrama y descripción sobre la navegación a redes sociales de la compañı́a.. Figura 3.5: Caso de uso 5: Navegar a las redes sociales. Nombre Propósito Descripción Pre-condiciones Post-condiciones. Navegar a las redes sociales Acceder a los contenidos en redes sociales relacionados con la productora. Desde cualquier página del sitio web se podrá acceder a los contenidos sociales a través de links y módulos incrustados en el footer. El usuario navegará al contenido de las redes sociales. La navegación permitirá mantener el sitio actual visible.. Tabla 3.5: Caso de uso 5: Navegar a las redes sociales.
(46) 28. Diseño abstracto del software. 3.1.1.6. Caso de uso 6: Renderizar galerı́a de instagram. Diagrama y descripción para la visualización del mashup de imágenes de instagram.. Figura 3.6: Caso de uso 6: Renderizar galerı́a de instagram Nombre Propósito. Descripción. Pre-condiciones Post-condiciones. Renderizar galerı́as de Instagram Visualizar un conjunto de imágenes de esta red social asociadas a la cuenta de Instagram de la productora. Realmente no es una acción que pida directamente el usuario, pero al cargar la página, internamente se hará la petición para cargar estas imágenes y se renderizarán en el footer de la aplicación. Existirá una cuenta de Instagram configurada en la aplicación. El usuario visualizará la galerı́a de instagram en el footer de la web.. Tabla 3.6: Caso de uso 6: Renderizar galerı́a de instagram 3.1.1.7. Caso de uso 7: Navegar a secciones de artistas. Diagrama y descripción para la navegación a páginas de artistas.. Figura 3.7: Caso de uso 7: Navegar a secciones de artistas.
(47) 3.1 Casos de uso. 29. Nombre Propósito Descripción. Pre-condiciones. Post-condiciones. Navegar a secciones de artistas Visualizar el conjunto de artistas de un tipo determinado Usando el menú principal presente en la cabecera de la aplicación, se podrá navegar a cualquiera de las secciones que muestran la lista de artistas de un tipo determinado. Los tipos: fotógrafos, ilustradores o directores de arte. Exiten artistas para el tipo seleccionado. El menú tendrá un link para acceder al conjunto de artistas de ese tipo. Visualizaremos una lista de artistas con su información básica: nombre e imagen o imágenes de presentación. Se filtrará por el tipo de artista sin mostrar dos artistas de tipos diferentes juntos.. Tabla 3.7: Caso de uso 7: Navegar a secciones de artistas 3.1.1.8. Caso de uso 8: Seleccionar artista. Diagrama y descripción para la selección de un artista.. Figura 3.8: Caso de uso 8: Seleccionar artista. Nombre Propósito Descripción Pre-condiciones Post-condiciones. Seleccionar artista Visualizar el detalle del artista: sus imágenes y biografı́a. En la lista de artistas de un tipo determinado se podrá seleccionar cualquiera de ellos para ver el detalle deseado de cada uno. El usuario ha navegado hasta una de las listas de artistas. Desaparecerá la lista de artistas y será sustituida por los datos del artista seleccionado. Las imagenes y vı́deos serán navegables.. Tabla 3.8: Caso de uso 8: Seleccionar artista 3.1.1.9. Caso de uso 9: Seleccionar imagen de artista. Diagrama y descripción para la selección de una imagen de un artista..
(48) 30. Diseño abstracto del software. Figura 3.9: Caso de uso 9: Seleccionar imagen de artista. Nombre Propósito Descripción. Pre-condiciones Post-condiciones. Seleccionar imagen de artista Visualizar la imagen completa seleccionada El usuario querrá poder visualizar una imagen en un tamaño mayor ocupando gran parte de la pantalla para poder analizarla más en detalle sin tener en cuenta el resto de imágenes del artista. El usuario ha navegado hasta la página individual de un artista. Desaparecerá la lista de imágenes del artista quedando visible únicamente la imagen seleccionada en un tamaño mayor.. Tabla 3.9: Caso de uso 9: Seleccionar imagen de artista. 3.1.1.10. Caso de uso 10: Salir de pantalla de imagen única de artista. Diagrama y descripción para conseguir cerrar la pantalla de detalle de imagen de un artista.. Figura 3.10: Caso de uso 10: Salir de pantalla de imagen única de artista.
(49) 3.1 Casos de uso Nombre Propósito Descripción Pre-condiciones Post-condiciones. 31 Salir de pantalla de imagen única de artista Visualizar de nuevo la lista de imágenes del artista. El usuario debe poder salir de la visualización de la imagen en tamaño grande mediante alguna acción de teclado o ratón. El usuario ha navegado hasta la pantalla de visualización de una única imagen en tamaño grande. Desaparecerá la imagen grande volviendo a la pantalla de la lista de imágenes del artista.. Tabla 3.10: Caso de uso 10: Salir de pantalla de imagen única de artista 3.1.1.11. Caso de uso 11: Seleccionar vı́deo de artista. Diagrama y descripción para seleccionar un vı́deo de un artista.. Figura 3.11: Caso de uso 11:Seleccionar vı́deo de artista Nombre Propósito Descripción. Pre-condiciones. Post-condiciones. Seleccionar vı́deo de artista Visualizar el vı́deo completo seleccionado El usuario querrá poder visualizar un vı́deo en un tamaño mayor ocupando gran parte de la pantalla para poder analizarlo más en detalle sin tener en cuenta el resto de recursos multimedia del artista. El usuario ha navegado hasta la página individual de un artista. Desaparecerá la lista de imágenes/vı́deos del artista quedando visible únicamente el vı́deo seleccionado en un tamaño mayor. El vı́deo se reproducirá automáticamente al abrirse esta nueva vista.. Tabla 3.11: Caso de uso 11: Seleccionar vı́deo de artista 3.1.1.12. Caso de uso 12: Salir de pantalla de vı́deo único. Diagrama y descripción para conseguir cerrar la pantalla de detalle de video de un artista..
(50) 32. Diseño abstracto del software. Figura 3.12: Caso de uso 12: Salir de pantalla de vı́deo único. Nombre Propósito Descripción Pre-condiciones Post-condiciones. Salir de pantalla de vı́deo único Visualizar de nuevo la lista de imágenes/vı́deos del artista. El usuario debe poder salir de la visualización del video en tamaño grande mediante alguna acción de teclado o ratón. El usuario ha navegado hasta la pantalla de visualización de un único vı́deo en tamaño grande. Desaparecerá el vı́deo grande volviendo a la pantalla de la lista de imágenes/videos del artista.. Tabla 3.12: Caso de uso 12: Salir de pantalla de vı́deo único. 3.1.1.13. Caso de uso 13: Navegar a sección de art buying. Diagrama y descripción para la navegación a la página de campañas.. Figura 3.13: Caso de uso 13: Navegar a sección de art buying.
(51) 3.1 Casos de uso Nombre Propósito Descripción Pre-condiciones Post-condiciones. 33 Navegar a sección de art-buying Visualizar el conjunto de campañas de la productora determinado Usando el menú principal presente en la cabecera de la aplicación, se podrá navegar a la sección que muestra la lista de campañas de la productora. Exiten campañas. El menú tendrá un link para acceder al conjunto de campañas. Visualizaremos una lista de campañas con su información básica: nombre e imagen o imágenes de presentación.. Tabla 3.13: Caso de uso 13: Navegar a sección de art buying. 3.1.1.14. Caso de uso 14: Seleccionar campaña. Diagrama y descripción para visualizar el detalle de una campaña.. Figura 3.14: Caso de uso 14: Seleccionar campaña. Nombre Propósito Descripción Pre-condiciones Post-condiciones. Seleccionar campaña Visualizar el detalle de la campaña: sus imágenes. En la lista de campañas se podrá seleccionar cualquiera de ellas para ver el detalle deseado de cada una. El usuario ha navegado hasta la lista de campañas. Desaparecerá la lista de campañas y será sustituida por los datos de la campaña seleccionada. Las imagenes serán navegables.. Tabla 3.14: Caso de uso 14: Seleccionar campaña. 3.1.1.15. Caso de uso 15: Seleccionar imagen de campaña. Diagrama y descripción para visualizar el detalle de una imagen de campaña..
(52) 34. Diseño abstracto del software. Figura 3.15: Caso de uso 15: Seleccionar imagen de campaña. Nombre Propósito Descripción. Pre-condiciones Post-condiciones. Seleccionar imagen de campaña Visualizar la imagen completa seleccionada El usuario querrá poder visualizar una imagen en un tamaño mayor ocupando gran parte de la pantalla para poder analizarla más en detalle sin tener en cuenta el resto de imágenes de la campaña. El usuario ha navegado hasta la página individual de una campaña. Desaparecerá la lista de imágenes de campaña quedando visible únicamente la imagen seleccionada en un tamaño mayor.. Tabla 3.15: Caso de uso 15: Seleccionar imagen de campaña. 3.1.1.16. Caso de uso 16: Salir de pantalla de imagen única de campaña. Diagrama y descripción para conseguir cerrar la pantalla de detalle de imagen de una campaña.. Figura 3.16: Caso de uso 16: Salir de pantalla de imagen única de campaña.
(53) 3.1 Casos de uso Nombre Propósito Descripción Pre-condiciones Post-condiciones. 35 Salir de pantalla de imagen única de campaña Visualizar de nuevo la lista de imágenes de la campaña. El usuario debe poder salir de la visualización de la imagen en tamaño grande mediante alguna acción de teclado o ratón. El usuario ha navegado hasta la pantalla de visualización de una única imagen en tamaño grande. Desaparecerá la imagen grande volviendo a la pantalla de la lista de imágenes de la campaña.. Tabla 3.16: Caso de uso 16: Salir de pantalla de imagen única de campaña. 3.1.1.17. Caso de uso 17: Navegar a la página de contacto. Diagrama y descripción para visualizar la página de contacto.. Figura 3.17: Caso de uso 17: Navegar a la página de contacto. Nombre Propósito. Descripción Pre-condiciones Post-condiciones. Navegar a la página de contacto Proporcionar los datos útiles para poder contactar con la productora de una forma u otra. A través del menú principal se podrá navegar a la página de contacto de la productora. En cualquier momento se podrá volver también al resto de secciones. Se podrá navegar a esta página desde cualquier punto de la aplicación. Aparecerá en pantalla tanto el formulario de contacto como los datos de contacto añadidos por el administrador.. Tabla 3.17: Caso de uso 17: Navegar a la página de contacto. 3.1.1.18. Caso de uso 18: Enviar mensaje de contacto. Diagrama y descripción para el envı́o de mensajes de contacto..
(54) 36. Diseño abstracto del software. Figura 3.18: Caso de uso 18: Enviar mensaje de contacto. Nombre Propósito. Descripción. Pre-condiciones Post-condiciones. Enviar mensaje de contacto Contactar con un mensaje directo con la productora para proponer, avisar o comentar algún tema relacionado con la empresa. A través del formulario de contacto se proporcionarán ciertos datos como: nombre, email, asunto y texto del mensaje, y ese mensaje se enviará por correo electrónico a la dirección de correo de la empresa. El usuario ha navegado a la página de contacto. El email de la empresa está previamente configurado para recibir los email de contacto. El email del administrador recibirá un correo con todos los datos introducidos en el formulario de contacto.. Tabla 3.18: Caso de uso 18: Enviar mensaje de contacto. 3.1.2. Resumen de casos de uso. Hemos visto de forma detallada todos los casos de uso de la parte de la aplicación. Veamos cómo queda la interacción entre los actores y todos estos casos de uso, para hacernos una idea general de la magnitud de la aplicación:.
(55) 3.2 Navegación. 37. Figura 3.19: Diagrama de casos de uso de la aplicación. 3.2. Navegación. Es importante saber cómo van a interactuar los actores dentro de nuestra aplicación, pero nuestro sistema es una aplicación web, sirve para navegar por la información que se expone, y es su cometido principal, con lo que es igual de importante saber cómo se puede navegar por la web: ¿qué vamos a poder hacer en cada página? ¿cómo vamos a poder llegar al resto de páginas del sitio?. 3.2.1. Navegación de Website. La posible navegación de nuestra aplicación website se resume en el diagrama de navegación 3.20:.
(56) 38. Diseño abstracto del software. Figura 3.20: Diagrama de navegación del Website La navegación del website comienza con la llamada a la URL base de la aplicación. En ese momento se redirige directamente a la Home o página inicial. Desde este sitio se redistribuyen los contenidos. Es una página de presentación de la productora, que permite incitar al usuario a navegar a otros sitios de la web. Se podrá desde la home, por tanto, acceder a cualquiera de las secciones de arte que se exponen: cualquier página de artistas y la página de art buying(campañas). Desde las páginas de artistas se podrá acceder a cada una de las páginas particulares de cada artista, y a su vez, desde la página de cada artista se podrá acceder a cada una de las imágenes o vı́deos de ese autor. Igual ocurre con las campañas. El proceso es el mismo: acceso a la página de cada campaña y desde allı́, acceso a cada imagen de la campaña por separado, si se desea. También se puede observar como se accede a la página de contacto que no tiene mayores niveles de navegación posteriormente. Se observa en la imagen 3.20 como hay un ente más AnyPage que es una forma virtual de representar a cualquiera de las otras páginas. Esto nos sirve para simplifica.
Documento similar
Debido al riesgo de producir malformaciones congénitas graves, en la Unión Europea se han establecido una serie de requisitos para su prescripción y dispensación con un Plan
Como medida de precaución, puesto que talidomida se encuentra en el semen, todos los pacientes varones deben usar preservativos durante el tratamiento, durante la interrupción
No había pasado un día desde mi solemne entrada cuando, para que el recuerdo me sirviera de advertencia, alguien se encargó de decirme que sobre aquellas losas habían rodado
Abstract: This paper reviews the dialogue and controversies between the paratexts of a corpus of collections of short novels –and romances– publi- shed from 1624 to 1637:
The 'On-boarding of users to Substance, Product, Organisation and Referentials (SPOR) data services' document must be considered the reference guidance, as this document includes the
In medicinal products containing more than one manufactured item (e.g., contraceptive having different strengths and fixed dose combination as part of the same medicinal
Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in
This section provides guidance with examples on encoding medicinal product packaging information, together with the relationship between Pack Size, Package Item (container)
