Tag: pregunta

¿Cómo se puede detectar el “user agent” o agente de usuario en PHP?

La cadena  “user agent” o agente de usuario es una cadena que envía un navegador con cada petición HTTP al servidor web.

En PHP se puede acceder a este valor a través del array superglobal $_SERVER. En la documentación oficial se indica que se debe acceder a la posición HTTP_USER_AGENT:

Contenido de la cabecera User-Agent: de la petición actual, si existe. Consiste en una cadena que indica el agente de usuario empleado para acceder a la pagina. Un ejemplo típico es: Mozilla/4.5 [en] (X11; U; Linux 2.2.9 i586). Entre otras opciones, puede emplear dicho valor con get_browser() para personalizar el resultado de la salida de la página en función de las capacidades del agente de usuario empleado.

El siguiente fragmento de código visualiza el valor de la cadena del agente de usuario:

<?php echo $_SERVER['HTTP_USER_AGENT']; ?>

¿HTML 4.0, XHTML 1.0, HTML5?

¿Cuál usar? La respuesta está en el cómic Misunderstanding Markup: XHTML 2/HTML 5 Comic Strip que publicaron en el año 2009 en la revista Smashing Magazine.

Muy buenas las dos citas que aparecen en el cómic:

Drew McLellan:

Whenever this argument surfaces, there seems to be the assumption that loose syntax is easier for beginners. This baffles me. In my experience simple, strict rules are much easier to learn and code to than loose rules with multiple shorcuts. I like XHTML because attributes must always be quoted. Tags must always be closed. These are simple rules that require no thought, and result in uniform, predictable markup.

Bruce Lawson, HTML5 + XML = XHMTL 5:

I like the xhtml syntax. It’s how I learned. I’m used to lowercase code, quoted attributes and trailing slashes on elements like br and img. They make me feel nice and comfy, like a cup of Ovaltine and The Evil Dead on the telly.

¿Por qué los navegadores web muestran páginas web que están mal hechas?

Respuesta “no políticamente correcta” para que la entienda todo el mundo: porque hay mucho capullo suelto haciendo páginas web que no tiene ni puta idea de lo que hace (y lo grave no es eso, lo realmente grave es que se creen que saben). Si los navegadores web no visualizasen las páginas web que están mal hechas, no se podría navegar por el 99,99% de los sitios web.

Respuesta ingenieril: porque los navegadores aplican la llamada ley de Postel o principio de robustez: “Be conservative in what you do, be liberal in what you accept from others” (Sé conservador en lo que haces, se liberal en lo que aceptas de otros). Este principio o ley, que se puede aplicar en múltiples contextos (comunicación a través de una red, comunicación entre programas, comunicación entre funciones dentro de un mismo programa o incluso la comunicación entre las personas) quiere decir que cuando hagas algo, debes ajustarte completamente a la especificación, es decir, lo tienes que hacer perfectamente bien, pero cuando recibas algo, tienes que estar preparado para aceptarlo si tiene sentido y se entiende, aunque no se ajuste a la especificación.

Debido a ello, debido a que los navegadores tienen que estar preparados para aceptar casi cualquier cosa, se han convertido en programas muy complejos.

Más información: Why should I validate my HTML pages?

¿Por qué las páginas de inicio deben morir?

Eso me preguntó hace unos meses un seguidor en Twitter a raíz de la cita Las páginas de inicio deben morir de Jakob Nielsen:

La conversación fue:

SLM: Lás páginas de inicio deben morir. J.Nielsen

RGO: porque supuestamente deberían morir?

SLM: Afortunadamente ya casi no se usan, pero de 1998-2005 abundaron y no servían para nada, sólo para meter un Flash tonto

SLM: Pocas empresas necesitan una página de inicio, sólo las grandes que tienen sitios web locales y tienes que elegirlo

RGO: pero los páginas de inicio a que se refieren? A la de registro por ejemplo?

SLM: Página de inicio necesaria, asus.com aunque Canon y Nikon lo han resuelto mejor

SLM: Página de inicio que no sirve para nada, éstas son las malas entrar.com

Y una explicación más detallada:

asus.com muestra una página de inicio en la que el usuario debe seleccionar el sitio web local al que desea acceder. En una empresa como Asus este tipo de página de inicio tiene sentido porque en realidad Asus no es “una sola empresa”, sino que se puede considerar que son múltiples empresas en una, ya que en cada región geográfica puede ofrecer un catálogo de productos diferente, con diferentes precios, diferentes ofertas, etc.

En canon.com y nikon.com se ha resuelto mucho mejor la página de inicio, ya que, además de ofrecer la posibilidad de elegir la región geográfica, se ofrece información general que puede ser de interés para el visitante. En este caso, la página de inicio no se queda en la típica página de inicio para seleccionar algo como en el caso anterior.

 

Sin embargo, en entrar.com, la utilidad de la página de inicio es más bien escasa, y más que animar a “entrar” te anima a salir corriendo:

¿Por qué es malo Flash? Porque no es una página web

Ayer escribí la entrada ¿Por qué es malo Flash? y dejé pendiente mi respuesta.

Podría echar mano de lo que dicen otros, como por ejemplo:

  • Los seis motivos de Steve Jobs para rechazar Flash (aunque da risa que uno de los motivos sea que Apple defiende los estándares abiertos, jajaja, ¡qué chiste más bueno!)
  • No debes utilizar Flash para adornar una página. Si tu contenido es aburrido, reescríbelo y contrata a un fotógrafo profesional para hacer mejores fotos. No hagas que tus páginas se muevan. (Jakob Nielsen)

Pero mejor voy a contar una historia, para que sea más personal…

La primera vez que vi una página hecha con Flash, debió ser por el año 1998 o 1999 pensé “¿cómo diablos se hace esto? Yo no puedo hacer esto con lo que sé de HTML y JavaScript” (en 1998, CSS era un desconocido).

Sin embargo, al ver el código fuente de la página, mi sorpresa y admiración se transformó instantáneamente en una sensación de engaño. “¡Esto no es HTML! ¡Esto no es una página web” grité.

Hacer una página web con Flash es como hacer una página web con un applet de Java, o hacer una página web con VRML, o con cualquier otro plugin similar o hacer una página web que simplemente muestra un vídeo: ESO NO ES UNA PÁGINA WEB. Como dice la definición de applet en la Wikipedia:

Un applet es un componente de una aplicación que se ejecuta en el contexto de otro programa, por ejemplo en un navegador web. El applet debe ejecutarse en un contenedor, que le proporciona un programa anfitrión, mediante un plugin, o en aplicaciones como teléfonos móviles que soportan el modelo de programación por “applets”.

Ya está, no le des más vueltas: hacer una página web con Flash no es hacer una página web (la página web simplemente hace de contenedor), es simplemente, hacer algo con Flash, ponerlo dentro de una página web y punto.

En los últimos años, gracias al diseño adaptativo o adaptable (responsive design) mucha gente está empezando a darse cuenta de lo que realmente es la Web. Es triste, porque han hecho falta 20 años para que mucha gente se dé cuenta, pero por fin, parece que se ha logrado. La Web no es un folleto, no es una hoja de papel, no es una cartulina, no es una valla publicitaria, no es nada de esos medios en los que conoces el tamaño de la superficie en la que tienes que trabajar para hacer tu diseño. NO, UNA PÁGINA WEB NO TIENE UN TAMAÑO FIJO. Seguro que con Flash también se podría hacer un diseño adaptable, pero nunca lo he visto, porque Flash te hace creer que tu página tiene un tamaño fijo (repito, seguro que se podría hacer adaptable… pero nunca lo he visto).

Pero hay otras razones más importantes…

Una razón muy importante: FLASH NECESITA QUE EL USUARIO TENGA INSTALADO UN PLUGIN. Y no siempre han existido plugins de Flash para todos los navegadores y todos los sistemas operativos. Y los plugins dan muchos problemas y hay que estar actualizándolos constantemente.

Además, y quizás más importante: FLASH ES UN SOFTWARE PROPIETARIO. No es un estándar, no es abierto, no es libre, es un producto comercial.

Todas estas razones son totalmente contrarias al espíritu de la Web. Flash y otras cosas parecidas han sido y siguen siendo totalmente opuestas a lo que debe ser la Web.

Y si quieres más razones, tienes el ejemplo que mostraba ayer en la entrada ¿Por qué es malo Flash?, que tenía graves problemas de accesibilidad y posicionamiento, aunque respecto a esto quiero hacer una puntualización muy importante: también se puede y se hacen las cosas mal con sólo HTML, CSS y JavaScript; sin embargo, por su naturaleza, con Flash es mucho peor (por ejemplo, durante muchos años era imposible hacer algo accesible con Flash, y aunque ya se puede, sigue siendo difícil y pocos desarrolladores lo saben hacer).

¿Necesitas más razones?

Sin embargo… bien usado, Flash no es tan malo. Cuando se usa como un complemento, por ejemplo en una tienda online para que un usuario pueda interactuar con un producto y “sentir” cómo es ese producto, entonces sí que es una buena opción. Es decir: Flash es bueno cuando aporta algo más, pero si lo quitas no pasa nada porque sigue existiendo la página web y el usuario puede seguir navegando y recibiendo la información esencial.

Desgraciadamente, muchos desarrolladores no lo entienden así y hacen sitios web en los que elementos esenciales como la barra de navegación o el listado de productos están hecho en Flash, o mucho peor, todo el sitio web está hecho en Flash.

Malo, no, malísimo.

¿Hasta cuándo hay que dar soporte para los navegadores antiguos?

Our general advice is to wait five to six years after the launch of a new browser version before you stop caring about the previous one. For example, IE 5 was launched in 1999, so you could safely ignore version 4 in 2004. IE 6 was launched in 2001, so you can probably start ignoring IE 5 in 2007. IE 7 was introduced in 2006, so you probably will need to support IE until 2012. (The five-to-six years rule is useful for long-term planning: to actually make the decision to stop supporting a browser, check your server logs to see what percentage of your current customers employs that version.)

Traducción:

Nuestra recomendación general es que hay que esperar entre cinco y seis años a partir del lanzamiento de una nueva versión del navegador antes de dejar de preocuparse por la anterior. Por ejemplo, IE 5 fue lanzado en 1999, por lo que podías ignorar con seguridad la versión 4 en 2004. IE 6 fue lanzado en 2001, por lo que probablemente podrás empezar a ignorar IE 5 en 2007. IE 7 se introdujo en 2006, por lo que probablemente lo tendrás que soportar hasta 2012. (La regla de los cinco a seis años, es útil para la planificación a largo plazo: en realidad, para tomar la decisión de dejar de soportar un navegador, mejor comprueba los registros del servidor para ver qué porcentaje de tus clientes actuales emplea esa versión.)

Prioritizing Web Usability. Jakob Nielsen, Hoa Loranger. New Riders, 2006.

¿Qué es la usabilidad?

Usability is a quality attribute relating to how easy something is to use. More specifically, it refers to how quickly people can learn to use something, how efficient they are while using it, how memorable it is, how error-prone it is, and how much users like using it. If people can’t or won’t use a feature, it might as well not exist.

Traducción:

La usabilidad es un atributo de calidad relacionado con lo fácil que algo es de usar. Más específicamente, se refiere a la rapidez con que la gente puede aprender a usar algo, lo eficientes que son mientras que lo usa, lo fácil que es de recordar, cómo de propenso a errores es, y la cantidad de usuarios que le gusta usarlo. Si las personas no pueden o no quieren utilizar alguna característica, bien podría no existir.

Prioritizing Web Usability. Jakob Nielsen, Hoa Loranger. New Riders, 2006.

¿Cuál es la mejor forma de enlazar jQuery?

Esta es una duda que tenía desde hacía tiempo, porque había visto varias formas, pero ninguna explicación de cuál es la más adecuada. En el artículo Linking to jQuery: Always Reference a Specific Version me despejan las dudas y, supongo, las de mucha gente. La mejor forma es:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/jquery-1.7.2.min.js"><\/script>')</script>

¿Cómo? Sí, en el sistema en producción, lo más recomendable es enlazar con la versión más específica que se haya usado. Y en la segunda línea podemos ver un buen método para cargar una copia local de la librería si falla la conexión con el CDN que estemos utilizando. ¡Una maravilla!