Alters

Diesño web: máxima compatibilidad - Diseñando el esqueleto a papel

Buenas!

Seguimos con el tema del diseño web...

Ahora que ya sabemos cómo hacer la web algo más estándar, es la hora de empezar con el diseño en sí.

Pero, para poder diseñar bien algo, primero es necesario hacer bocetos, para ver cómo quedaría todo.

Así, se coge un papel en blanco y se empiezan a plasmar ideas, y cuando tenemos una buena la desarrollamos. Recomiendo usar escala para ver mejor los resultados finales.

Cuando tengamos un diseño que nos agrada, podemos (si queremos) pasarlo a PC. Yo lo hago con Corel y mucha paciencia...

Os dejo el último diseño que hice (img):

img1
El tamaño original es 800x600, y lo hice a escala 3:100 (es decir, en el papel era un cuadro de 24x18, y 3 cm equivalen a 100px).

Como veis es un diseño sencillo: se distinguen tres partes principales (lateral - 5 secciones, central - cuadro grande, superior - barra con 2 secciones).

Al tener la escala, fue fácil llevarlo a tamaño real, y fue también fácil llevarlo a web con CSS.

Obviamente, este diseño va un poco en la línea del producto que promociona; es decir, cada tipo de página puede tener un diseño "más acorde" a ello, de manera que no pondría, por ejemplo, colores apagados (grises, negros) en un diseño de una juguetería infantil.

No solo los colores influyen, sino las formas. Formas redondeadas pueden dar un poco de dinamismo en un diseño, pero también son más difíciles de llevar a cabo.

Veamos un poco en profundidad qué cosas se pueden tener en cuenta a la hora de diseñar:
  • Público al que va dirigido
  • Tipo de producto (por ejemplo, las redes sociales tiran hacia el azul)
  • Contraste fondo/contenido
  • Efectos adicionales (sombras, bordes redondeados...)
  • Tamaño óptimo (para webs pequeñas, pienso que 800x600 es un buen tamaño)
  • Accesibilidad
Hasta aquí, tenemos ya todo preparado para llevar nuestra web de la cabeza a internet.

En la próxima entrada (será bastante corta...), veremos cómo analiza, a grosso modo, el estilo nuestro navegador.

Así que,

¡Hasta la próxima!

Diseño web: compatibilidad máxima - W3C

Buenas de nuevo!

Empezamos con el tema de diseño web, temporalmente.

En esta entrada hablaremos de W3C.

W3C significa "World Wide Web Consultorium", es decir, un consultorio de la WWW. Como tal, tiene herramientas específicas para validar nuestro HTML, CSS... e incluso tiene manuales de referncia de los mismos (incluyendo JS).

Pero, ¿Qué es "validar" un HTML?

Veréis, muchas veces codificamos de manera "no estándar" nuestras web. Esto no significa que estén mal, sino que no es un documento estándar, acorde con las directrices de W3C.

Hoy en día no pasa nada, ya que la mayoría de los navegadores incluyen funciones que "estandarizan" nuestro HTML; pero antaño, no seguir un estándar daba webs muy diferentes dependiendo del navegador.

Bien, ahora no penséis que los estándares son muy complicados... voy a dejar una lista de elementos generales a cumplir para el estándar de la W3C:

  • Cerrar los elementos que no tienen etiqueta de cierre:
    • Ejemplo:
      • <br> no es estándar
      • <br /> es estándar
      • <meta ...> no es estándar
      • <meta ... /> no es estándar
    • Si bien no es obligatorio, a mi me gusta dejar un espacio antes del cierre ("/").
  • Entrecomillar los atributos
    • Ejemplo:
      • <div class=clase1> no es estándar
      • <div class="clase1"> es estándar
      • <img src=./img/css/icon.png> no es estándar
      • <img src="./img/css/icon.png> tampoco es estándar (falta cerrar el elemento)
      • <img src="./img/css/icon.png" /> es estándar
  • Cumplir los requisitos básicos de las diferentes etiquetas:
    • <head>
      • Tiene que tener el tag "title" dentro
    • <img>
      • Tiene que tener los atributos "src" y "alt"
    • <a>
      • Tiene que tener el atributo "src"
    • <html>
      • Tiene que tener un "charset" definido
    • <form>
      • Tiene que tener los atributos "name", "action" y "method"
    • <input>
      • Tiene que tener el atributo "type" y "name"
    • <ul>, <ol>
      • Tiene que tener el atributo "type"

Creo que no me dejo ningún elemento en el tintero... como veis, no es demasiado complicado cumplir con el W3C (al menos con webs simples o muy poco complejas).

El "problema", por así decirlo, viene cuando programamos en PHP (por ejemplo). El uso de comillas se puede hacer algo caótico, sobretodo si hacemos JavaScript dinámico en el que llamamos a funciones con parámetros en forma de cadena (que va entrecomillada...)

Mi sugerencia: en PHP usad (siempre que podáis) las comillas simples, y los textos entrecomillados usando la doble comilla.

Vale, todo esto es muy bonito, pero, ¿Qué implica al diseño con la W3C? para responder haré una pequeña reflexión:

Continuamente salen nuevos aparatos tecnológicos que implementan, de alguna u otra manera, la tecnología de Internet.

Éstos nuevos dispositivos implementarán unas u otras reglas, y éstas pueden o no paliar una codificación "no estándar".

A continuación hago un ejemplo drástico, para que se vea la diferencia:

 - Si haces un documento así:

<body><table><td>HOLA

y lo probamos en chrome, éste lo estructura internamente así (inspeccionando el elemento):

<html><head></head><body><table><tbody><tr><td>HOLA</td></tr></tbody></table></body></html>

Ahora se ve el cambio... ha puesto de todo. Y esto se debe a que los navegadores no vuelcan el código fuente directamente, sino que lo tratan previamente.

Puede que un nuevo navegador no incluya todo esto, por el motivo que sea (menor consumo de recursos, por ejemplo), y entonces... ¿qué pasaría con nuestra web? estaría a merced de los algoritmos del navegador, y la veríamos de vete-tú-a-saber-qué manera.

Sin embargo, en una web estándar W3C, la conversión que hace el navegador es nula, por lo que nos "da igual" cómo trate el código fuente, siempre (en teoría) se verá igual la web.

Por este motivo siempre intento que las web cumplan el estándar.

Podéis pasar el test aquí:  http://validator.w3.org/

Si pasáis el test, os saldrá un enlace para "colgar una medalla" en vuestra web. Con ella los visitantes sabrán que cumplís el estándar (y podéis "fardar" con ella, jeje ;-) )

La próxima entrada la llenaremos con contenido de "maquetar esqueletos a papel".

¡Hasta la próxima!

Diseño web: compatibilidad máxima

Buenas de nuevo!

Empieza una nueva "serie de entradas", para dar tiempo a la serie de las M!nas...

Como dije, hablaremos de diseño web. Diseño compatible, sobretodo.

Antes de todo, comentar que para nada soy ningúno de esos "gurús del CSS" que son capaces de montar verdaderas obras de arte combinando CSS2 y CSS3, y cosas por el estilo... yo el CSS lo uso para diseñar cosas simples. Las cosas complejas las dejo para PHP, JS, y demás...

Os dejo un índice acerca de esta nueva serie:

  1. W3C
  2. Maquetar el esqueleto a papel
  3. Interpretar estilios como el navegador
    1. File
    2. Inline
    3. Direct
  4. Clases con CSS
    1. Ancho
    2. Alto
    3. Posición x e y
    4. Relative, absolute...
  5. Maquetar el esqueleto con CSS
  6. Tips & tricks
    1. Porcentajes
    2. Agrupar contenido en clases superiores
    3. Inherit, initial u omitir
    4. Contenido "centrado"
    5. Contenido que se "redimensiona"
      1. Fondo
      2. Contenido
    6. Jugar con la transparencia
    7. Efectos "misc"
      1. Scroll modificado
      2. Cajas con borde
      3. Modificar "select"
      4. Scroll "dependiente"
      5. Editar listas
    8. Div vs Span
    9. Compatibilizar con otros navegadores

En principio serán 6 entradas, aunque lo más posible es que la sexta esté en varias partes (ya que tiene mucho contenido).

Intentaré ilustrarlo todo con ejemplos, para que quede más claro.

Así, en la próxima entrada hablaremos de la W3C, o dicho de otra manera, cómo hacer webs "estándar". Para mí, este punto es fundamental, ya que una web que cumpla a rajatabla la W3C dice mucho.

Saludos, y

Hasta la próxima!

Varios - Misc

Buenas!

Hacía tiempo que no escribí nada en el blog... llevo severos retrasos con todos mis proyectos... así que, para no estar demasiado sin hacer una entrada "con chicha", vamos a ver varios temas rápidos.

AJAX Cross-Domain (ACD)

Muchas veces habréis oído aquello de "usar API's", si bien no las habéis usado alguna vez (google maps, google calendar...)

Para aquellos que no sepan qué es una API, decir que es una capa de abstracción creada por programadores para facilitar el uso de herramientas web.

Un ejemplo: quiero poner en un mapa dónde vivo (en mi web). Hace tiempo, yo lo hubiera hecho así:

 - Entro en google
 - Busco google maps
 - Busco mi calle
 - Hago un print de pantalla
 - Coloco la imagen en mi web

Sin embargo, las API permiten que mi web conecte con google, y le puedo especificar dónde vivo (en latitud y longitud) y él se encarga de todo (es decir, delegamos el funcionamiento a google). Yo solo me tengo que preocupar de poner una capa (div) para recibir el mapa y llamar al método correspondiente.

Pues bien, uno de los principales problemas que entraña el uso de una API es el ACD (AJAX Cross-Domain).

¿Qué es el ACD? es un impedimento (una medida de seguridad, más bien propia de IE) que impide que una web cargue datos de un servidor externo, tal como indica la imágen "img1" (en rojo marcada la comunicación interrumpida).

img1
Esto frustra todo amago de comunicación con servidores externos. Sin embargo, las API se usan. ¿Cómo?
Pues hay varios métodos:


  • Proxie transparente: esta medida se basa en modificar el archivo .htaccess, con una regla de reescritura, de manera que podemos convertir algo como "http://miweb.com/api" en "http://apiweb.com". Con esto conseguimos establecer un puente, mediante el cual nosotros llamaremos a "miweb.com/api", y mediante el archivo htaccess, estaremos realmente accediendo a "apiweb.com".
    • Ventajas: funciona bien, y de manera simple
    • Inconvenientes: cada cliente de la API tiene que configurar su htaccess (algunos hostings no dejan).
  • Página ACD: es una web (http://www.ajax-cross-domain.com/) en la que te puedes descargar un src (código fuente) de un programa cgi. Mediante htaccess hacemos que lo interprete como un js, y éste hace de puente para solventar el problema de ACD.
    • Ventajas: configurable, seguro
    • Inconvenientes: necesita aceso a ACD, y no todos los hostings permiten interpretar cgi como js.
  • Envoltura: es el método más usable de todos, ya que no necesita de nada por parte del cliente (eso sí, la API tiene que estar preparada para usar envoltura). El método de la envoltura consiste en incluir la llamada a la API dentro de un elemento <script> en nuestra web. De esta manera, nuestra web hará una llamada a la API, para incluír el contenido al script. El contenido que "se crea" es, ni más ni menos que el resultado de llamar a la API deseada.
    • Ventajas: siempre podremos usarla
    • Inconvenientes: el programador de la API tiene que prepararla, y (que yo sepa) solo se puede mandar datos vía GET.
Y, ¿porqué os comento el problema del ACD? pues porque estuve varias semanas luchando con este problema con una API que me tocó programar en mi trabajo, y finalmente lo conseguí solucionar usando el método de la envoltura (y la consecuente remodelación de la API...).

En la próxima entrada (a no ser que sea sobre M!nas), trataré de solucionar el tema del diseño web, para hacer lo máximo compatible con IE, Firefox, chrome, opera y safari.

Para poder seguir entregando material en abundancia, lo haré tipo "serie", como he estado haciendo estas entradas.



Varios

Buenas de nuevo!

Sigo trabajando en la entrada de las M!nas, aunque llevo algunos retrasos...

La semana pasada estuvo muy movida también... espero que esta semana vuelva todo a la normaildad...

Y bueno, este fin de semana estuve en el salón del manga. Como era de esperar nadie llevaba el mismo cosplay que yo :-p (Prince of persia: Warrior Within, con la Water Sword).

Allí conseguí ponerme en contacto con un novato (y con esto no quiero decir que sea malo) desarrollador de videojuegos, así que quizás en un tiempo me meto en ese mundillo. También cogí información de un centro que forma en 3D (y lo hace muy bien, al parecer); si bien los precios son elevado (9.900€ un máster de 9 meses, 19.800 una carrera de 2 cursos), incluye mucho material (incluyen hasta un ordenador), así como también prácticas en empresa.

También conseguí contactos con editoriales varias... resulta que tengo un relato corto escrito y registrado, pero no consigo que salga a la luz... a ver si con estos nuevos contactos consigo algo.

En cuanto al merch que compramos (mi novia, mi buen amigo James y yo) fue variado, aunque este año no hemos encontrado ninguna ganga (el año pasado conseguimos una figura de Bobobo por 20€ - en los otros stands las vendían por 80€).

En cuanto a últimas novedades, estoy metido en un concurso de InfoJobs, que consiste en desarrollar una App para la misma compañía, usando su API. El premio al ganador oscila entre los 10.000 y 12.000€ (así que si - ojalá - ganara sería una buena alegría). Pienso que mi idea es buena; y esto es un buen comienzo, ya que hace falta mucha motivación para hacer algo bueno y decente, y sin una buena autoestima es imposible!

Antes de cerrar esta entrada, decir que me guardo las fotos del Salón del Manga (así como las del anterior) para una posible futura entrada no relacionada con  la informática (como esta, jejeje).

Saludos y...

¡Hasta la próxima!