{"id":262,"date":"2015-06-03T11:12:44","date_gmt":"2015-06-03T10:12:44","guid":{"rendered":"http:\/\/tecnologiasweb.jsenso.es\/?p=262"},"modified":"2015-06-03T11:12:44","modified_gmt":"2015-06-03T10:12:44","slug":"mockup-arquitectura-web","status":"publish","type":"post","link":"https:\/\/blogs.ugr.es\/tecweb\/mockup-arquitectura-web\/","title":{"rendered":"Dise\u00f1o web: wireframes y mockups"},"content":{"rendered":"

Uno de los textos que suelo emplear en mi asignatura como b\u00e1sico es el que escribi\u00f3 mi buen amigo Mario P\u00e9rez Montoro<\/a> en 2010 para la editorial Trea<\/a> titulado \u201cArquitectura de la informaci\u00f3n en entornos web<\/a>\u201d. En \u00e9l se afirma que uno de los trabajos que implica la arquitectura de la informaci\u00f3n web est\u00e1 relacionado con el bosquejo de sitio web: el wireframing.<\/p>\n

En realidad cuando se dise\u00f1a un sitio web, en su primera aproximaci\u00f3n, hay dos elementos que son claves para el correcto desarrollo. Adem\u00e1s del bosquejo est\u00e1 el diagrama de contenidos. Este tipo de diagramas vienen muy bien para establecer la estructura del sitio y tener una visi\u00f3n global de d\u00f3nde se ubicar\u00e1 cada cosa en \u00e9l. En esta entrada me centrar\u00e9 en el bosquejo de sitios o, como dicen los modernos, la primera fase del dise\u00f1o web.<\/p>\n

 <\/p>\n

\n
<\/div>\n
View image<\/a> | gettyimages.com<\/a><\/div>\n<\/div>\n

 <\/p>\n

Personalmente he notado que ambos elementos (bosquejo y diagrama de contenidos) tienen dos dificultades en su desarrollo, hablando desde el punto de vista pedag\u00f3gico. El primero es que se ense\u00f1an poco. He estudiado los programas de las asignaturas de dise\u00f1o web dentro de las titulaciones universitarias espa\u00f1olas en las \u00e1reas de las ciencias sociales e inform\u00e1tica y he observado que apenas se mencionan en los temarios. No s\u00e9 si es por la poca cantidad de horas que se le puede dedicar a esto en un temario tan apretado (que es mi caso), o porque se considera una tarea \u201cmenor\u201d y se le deja al \u201cartista\u201d del equipo.<\/p>\n

Lo cierto es que sobre estos dos elementos se cimienta el \u00e9xito o el fracaso de un sitio web (entre otros, claro). Que est\u00e9 organizado, que sea atractivo, que sea f\u00e1cil de usar… Si se parte de un mal boceto, o se organizan mal las opciones de los men\u00fas, el usuario no durar\u00e1 mucho tiempo en el sitio. Realmente yo los contemplo como la formalizaci\u00f3n m\u00e1s evidente de la estructura de conocimiento que debemos plasmar en un sitio web<\/strong>. Cuanto m\u00e1s cercana sea esa estructura a lo que espera el usuario, m\u00e1s posibilidades existir\u00e1n de que este se encuentre a gusto en el sitio.<\/p>\n

La otra dificultad se centra en algo que parece muy evidente. Un gran porcentaje de sitios web se crean sobre CMS (WordPress<\/a>, Joomla<\/a>, Drupal<\/a>…) que permiten gestionar los aspectos visuales por medio de plantillas o temas ya precocinados. Si la p\u00e1gina principal y la estructura visual del resto de p\u00e1ginas (colores corporativos, elementos comunes, encabezamientos, pies de p\u00e1gina…) ya vienen dise\u00f1adas \u00bfpara qu\u00e9 molestarse en hacer un boceto?<\/p>\n

Yo sigo pensando que, a pesar de que existan muchos temas creados por terceros, siempre es importante tener un boceto del sitio (como m\u00ednimo la p\u00e1gina principal) y tener claros los elementos fundamentales. Una vez creado ese boceto deber\u00eda ser m\u00e1s f\u00e1cil decantarse por una plantilla u otra e, incluso, editar su CSS o su estructura para adaptarlo a lo que necesitamos y, adem\u00e1s, hacerla m\u00e1s personal, logrando que se identifique de manera \u00fanica con nuestro sitio. Es decir, que no sea el sitio n\u00famero 500 creado con esta plantilla.<\/p>\n

La creaci\u00f3n de bocetos tambi\u00e9n se conoce como wireframe o schematic y pretende organizar, de manera esquem\u00e1tica, la representaci\u00f3n de una p\u00e1gina web. En esa representaci\u00f3n no se suelen incluir im\u00e1genes, contenido ni comportamiento de las p\u00e1ginas, ya que lo que pretenden es dar una visi\u00f3n global de los elementos que tendr\u00e1 una p\u00e1gina y de c\u00f3mo se ubicar\u00e1n dentro de \u00e9sta. No deber\u00eda tener colores, ser lo m\u00e1s simple posible, suficientemente explicativo en cuanto a las \u00e1reas que se definan y no combinar diferentes tipograf\u00edas.<\/p>\n

\"Wireframe<\/a>
Wireframe de una p\u00e1gina principal. Fuente: ttp:\/\/www.comentum.com\/<\/figcaption><\/figure>\n

 <\/p>\n

Lo habitual es crear un wireframe para la p\u00e1gina principal y otro para las de contenido. Ambos bocetos deber\u00e1n tener en com\u00fan aquellos elementos que comparten (encabezado, pie, lugar del logo, men\u00fas, formulario de b\u00fasqueda…). En principio no deber\u00eda ser necesario realizar m\u00e1s, ya que las p\u00e1ginas interiores deber\u00edan ser repeticiones del boceto de contenido, pero con diferente texto (e im\u00e1genes, claro).<\/p>\n

Los principios que se declaran en el wireframe deben ser repetidos en el resto de p\u00e1ginas, de tal forma que, si existe un equipo trabajando en el desarrollo de la web, todos tengan claro lo que hacer. El objetivo fundamental es dise\u00f1ar contenidos, no el aspecto visual del sitio, por lo que en la creaci\u00f3n del wireframe nos debemos centrar en organizar la informaci\u00f3n a nivel de p\u00e1gina. La informaci\u00f3n que debe contener un wireframe (seg\u00fan StrangeSystems<\/a>) es:<\/p>\n