Desarrollando para mobile

En las últimas semanas estuve desarrollando un sitio web mobile. Desde mi punto de vista, lo mejor que tiene el desarrollar/maquetar para mobile es que se pueden usar (y de hecho se fomenta) las ventajas de HTML5.

Con lo que me encontré a la hora de hacer esta webapp, es con pequeños yeites, que paso a poner a disposición de todos.

Un CSS para todos

Hace unos meses Jakob Nielsen, en contra de cualquier práctica realista, propuso que en lo que a desarrollo web mobile se refiere, lo mejor es olvidar las mediaqueries al hacer un único sitio que se adapta a todos los dispositivos, y en su lugar hacer sitios mobiles por separado del sitio full, tantos como hagan falta, e inclusive, crear tantos generadores de contenido como sean necesarios para permitir, justamente, esta proliferación de sitios.

Ridículo.

Yo uso mediaqueries por todos los motivos que se pueden encontrar googleando, y porque mis clientes y los de la agencia para la que trabajo no tienen presupuestos tan grandes para lograr lo que Nielsen propone. Entonces, un CSS con mediaqueries para todos.

Y la mejor manera que por el momento encontré para apuntar a las distintas pantallas, es la siguiente:


/* generales */
@media only screen and (min-width: 420px) and (max-width: 767px) {
}
/* iPad */
@media only screen and (min-device-width: 768px) and (max-device-width: 1024px) {
}
/* iPhone */
@media only screen and (max-device-width: 480px) {
}

Cabe notar que el de iPhone se superpone con el de dispositivos mobiles en general, por lo que esta diferenciación pocas veces hará falta, pero no está de más el saberla.

iPhone/iPad reescala al rotar

Este es un curioso problema, cuya solución, si bien la entiendo, no me gusta al 100%. El problema es que al cargar una página en un iPad, y luego cambiar la rotación, la escala «cambia» y nos vemos forzados a hacer el ajuste, que si bien el gesto con los dedos lo hace facilísimo, no deja de ser molesto. El problema se origina en código que se suele encontrar incompleto, como el siguiente:

<meta name ="viewport" content="initial-scale=1.0, width=device-width">

En la ardua tarea de copypastear código hasta que funciona, pocas veces nos detenemos a pensar para qué realmente sirve cada parámetro. El meta «viewport» nos permite indicarle al browser cómo se debe comportar nuestro contenido respecto del dispositivo. Podríamos entonces setear content=»width=200px», que lo que hará será forzar el ancho del contenido a un máximo de 200px. No se me ocurre un ejemplo práctico en donde querramos setear un ancho de esta manera, pero lo que si sabemos es que si podemos setear ese ancho de forma proporcional, entonces podemos poner nuestra web al ancho de cualquier dispositivo. Y eso es lo que hace width=device-width.

También se puede setear la escala a la que se debe ver el contenido con initial-scale=1.0. Pero lo que en verdad necesitamos para corregir las rotaciones de iPhones/iPods/iPads es lo siguiente:

<meta name ="viewport" content="user-scalable=no, initial-scale=1.0, maximum-scale=1.0, width=device-width">
<meta name="apple-mobile-web-app-capable" content="yes"/>

De este modo seteamos la escala incial, la escala máxima, y le quitamos la posibilidad al usuario de reescalar, al mismo tiempo que seteamos nuestro ancho de página a todo el dispositivo. Y con la instrucción que sigue le indicamos al dispositivo que nuestra aplicación corre en full screen.

Lo que veo de negativo de esto es que se le quita la posibilidad al usuario de escalar, y eso no me gusta. Pero se trata de equilibrio, si como usuario voy a estar cambiando la escala, entonces no puedo pretender que la rotación de mi dispositivo me recalcule todos los tamaños a como me es a gusto. O quizás debiera? en fin… será problema de los ingenieros.

Por nuestra parte, nos queda saber diseñar/maquetar para que los usuarios roten y puedan tener la mejor experiencia posible.

Les dejo un link a stackoverflow, de donde pude empezar a ilustrarme sobre el tema, y otro a la documentación oficial de Safari, de donde pueden leer sobre «apple-mobile-web-app-capable».

Favicons

El tema con los favicons en mobile se reduce a crear un archivo .png por cada tipo de pantalla que puede guardar la webapp como favorito. No me voy a extender demasiado en esto, porque simplemente seguí el paso a paso que encontré en esta página. El único tip que sí voy a dar es que los .png no pueden tener transparencia en IOS (android si los lee), confirmado esta vez en la documentación para desarrolladores de Apple.

Debugging

Por último, un plugin que no conocía, y permite cambiar el user agent en el Firefox o Chrome. Es algo que parece tonto, hasta que te das cuenta que todos los sitios usan el user agent para detectar si es o no un dispositivo móvil el que se conecta.

Altura 100% de un DIV

Setear un div al 100% de altura, o bien que siempre se estire según el contenido del div de al lado, es algo que sólo se puede cumplir en CSS mediante trucos. El viejo template de WordPress (creo que el que estaba en el 2.0), usaba una imagen para simular el alto 100%, seteando a la misma como fondo del div contenedor de los otros dos. El color de ambos divs estaba creado entonces por una imagen.

El truco que uso cuando me piden este tipo de funcionalidades, es el siguiente:


.contenedor{
 overflow:hidden;
 width:680px;
 margin:0 auto;
 }
 .left{
 float:left;
 width:100px;
 padding:20px;
 padding-bottom:9999em;
 margin-bottom:-9999em;
 background:#555555;
 }
 .main{
 float:left;
 width:500px;
 padding:20px;
 background:#bbbbbb;
 }

Mi .contenedor, sin height seteado, con overflow:hidden. Esto es importante porque en el .left seteamos un padding-bottom monstruoso, extremadamente grande, junto con un margin-bottom negativo igual de grande, que lo único que harán será estirar el contenido de ese div hasta el final de .contenedor, pero como el mismo tiene la instrucción de «ocultar» todo lo que sobresalga de él, nunca vemos el excedente.

Mejor es ver el html, no?

Imagen en el submit de un form

Adlatina es un portal de comunicación. Tiene unos cuantos años online, si trabajan en publicidad lo conocen por obligación (si trabajan y no lo conocen, que esperan?). Algo que me molesta, y mucho, es que en su formulario de login no funciona el «enter». O sea, pongo mi email, mi password, toco enter……… y muevo el mouse hasta el boton «Ingresar» para hacer click y loguearme. Horrible…

El otro día me puse a pensar en esto, porque simplemente no puede ser que suceda. Pensé un poco más, y la conclusión es que si está hecho de esa forma (y hace años), es porque no saben hacerlo bien. Alguno dirá «pero es un botón de submit, cómo no van a saber hacerlo?». Corrección, es un botón de submit con una imagen, es otra cosa.

Veamos el código que usaron para este botón sin usabilidad:

<div class="box">
	<div class="content2">
		<a tabindex="7" class="boton" title="ingresar" onclick="document.formulario.submit();" href="#"><span>ingresar</span></a>
		<div class="clear"> </div>
	</div>
</div>

Como se puede ver, no hay ningún elemento de formulario que haga el submit. En vez de un <input type=»submit»>, hay un <a><span>, donde el atributo onclick del <a> es un javascript que hace el submit de un form. Espantoso.

Según mi teoría, el que hizo este formulario no supo cómo resolver el poner una imagen en el submit del formulario. El problema con los input, es que cuando se trata del <input type=»submit» /> el css empieza a comportarse extraño con todos los navegadores. Mientras en Firefox funciona, Explorer falla siempre. Entonces, en su lugar hay que usar un elemento que no lo usa nadie, el <button>.

El código quedaría así:

<div class="box">
	<div class="content2">
		<button tabindex="7" type="submit" class="boton_usable"><div><span>ingresar<span></div></button>
		<div class="clear"> </div>
	</div>
</div>

A la etiqueta button se le puede poner como contenido un <div> o un <span>, si son maquetadores y no conocían <button>, se acaban de dar cuenta que es su nuevo mejor amigo.

Les dejo el link con el formulario tal cuál como está hoy, y mi propuesta. Chusmeen el CSS.

SEO y SEM

En los últimos meses me preguntaron en distintas ocaciones sobre SEO y SEM. No es precisamente algo en lo que me especializo, o sobre lo que esté leyendo constantemente. Lo que sí me interesa en relación a SEO es la web semántica, escribir bien para que se guarde un sitio correctamente.

Luego de esta introducción, les cuento brevemente de qué se tratan. Entonces, qué es SEO y SEM?
Seguir leyendo

Guía de maquetación HTML para e-mails marketing

En el tiempo en que llevo trabajando en Interactive, aprendí que algo a lo que hay que prestarle un poco más de atención en la etapa de test es a los e-mail. Debido a la ausencia de estándares, y que corporativamente se utilizan clientes de email como Lotus u Outlook, pero el público en general utiliza webmails, uno se ve obligado a reducir las piezas html a una serie de reglas para performar correctamente en todos los medios.

Como no suelo encontrar guías en la web sobre este tema, comparto la que uso diariamente. Agreguen o corrijan lo que crean necesario:
Seguir leyendo