Y si no hay AJAX?

4
Nov/096

Recientemente escribí un comentario en el blog de Alfredo Artiles1, Bitácora de Webmaster, en un artículo relacionado con la nueva propuesta de los señores de google para hacer indexable un site en Ajax. En su artículo Alfredo resumía que aunque vayan por el buen camino al intentarlo, el uso de las técnicas que proponía Google para conseguirlo no le parecía muy adecuado. Yo voy un paso más allá y diría que sería todo un error implementar las opciones que comenta Google, pero esto daría para otro artículo2.

La cuestión es que su post viene a cuento porque hace tiempo que os quería comentar como, creo, que debería hacerse una web con contenido en AJAX y creo que este sería el mejor momento para ello.

Lo primero, comentaros que el problema de AJAX no solo está con los buscadores, sino principalmente con la usabilidad y accesibilidad. Ese pequeño porcentaje de usuarios que llega al site desde navegadores especiales para discapacitados, o desde navegadores solo texto, o incluso en un porcentaje mayor, aquellos que acceden desde su móvil, ellos son el principal objetivo a solventar cuando se desarrolla en AJAX, no los buscadores que en este caso creo que son secundarios (aunque también salgan muy beneficiados).

Bueno, entonces la panacea al respecto, cual sería? Simple, no desarrollar en AJAX!

Esto que parece una perogrullada es realmente la mejor solución para corregir el problema, desarrollar sin AJAX y añadir la capa de AJAX a posteriori. Con esto conseguimos crear una navegación lo más sólida posible fuera de todo JavaScript, y una vez creada añadimos mediante JS la capa AJAX, a base de modificar los enlaces internos por llamadas asíncronas al servidor y un par más de detalles en el código. Así, si un navegador sin JS o un Bot llegan a tu site con ganas de recorrerlo entero no tendrán ningún problema y podrán navegar por todo el site de forma perfecta.

También están los beneficios añadidos, como poder abrir enlaces en pestañas/ventanas nuevas, crear otra capa de independencia entre la Vista y los Scripts (digamos MVSC), o uno más importante aun el de poder enlazar directamente una página interna desde cualquier lado sabiendo que va a llegar a dicho enlace.

Nota: A partir de aquí el asunto se pone muy denso, así que si lo tuyo no es la programación front o bakend o la maquetación o si no comprendes algo de AJAX, mejor quédate con la idea vista hasta ahora y mira ejemplos en, por ejemplo, la web de Coleccionismo Baral

Lo primero que haremos será dar por sentado unos conceptos de la programación del site:

  • Se programa OOP (aunque en este caso no sea necesario, pero así vamos inculcando las nociones básicas mínimas)
  • Usamos el patrón de diseño de software MVC, separando la Vista y el Control sobretodo.
  • Usamos también el patrón Façade para tener así un único punto de entrada al código.
  • Usamos URLs SEO friendly del tipo http://host/casa/coche que luego pasarán a ser http://host#casa/coche

Bueno, una vez está claro esto, empezamos con la programación del site, creamos la navegación básica, la lógica interna del site, los modelos,… En fin todo el desarrollo pero sin incluir nada de AJAX por ahora. Una vez realizada la navegación y teniendo en cuenta que usamos los patrónes Façade y MVC incluimos un pequeño script3 al código del site similar al siguiente:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129

//Script File
 
// variable general que nos servirá para chequear si hay que cambiar contenidos por AJAX
var navAjaxCheck = false;
 
// Función goto, encargada de hacer la llamada asíncrona
// La variable jsonValue incorpora toda la información necesaria
var goto = function (jsonValue)
{
	// Posibles excepciones a la navegación por AJAX
	if (location.hash.test("signup"))
  		return false;
 
	//waiter es para añadir el típico efecto de sombreado en el site mientras se cambia el contenido.
	jsonValue.waiter = jsonValue.waiter === false ? false : true;
 
	//update es el id del contenedor a remplazar
	// (false en caso de no quere actualizar nada y "contenedor general" en caso de "null")
	jsonValue.update = jsonValue.update ? jsonValue.update :
		(jsonValue.update === false ? false : 'contenedor_general');
 
	// El nuevo valor del href
	jsonValue.href = jsonValue.href.test("#") ? " " : jsonValue.href;
 
	new Request.HTML({
	// Aquí está el punto importante, mandamos toda la info a /ajax/
		url: '/ajax/'+JSON.encode(jsonValue),
/*	Se desactiva por fallos con el IE.
		update: $(jsonValue.update),
		useWaiter: jsonValue.waiter,
		waiterOptions: {
		    baseHref: '/',
		    img: {
		        src: 'img/loader.gif',
		        styles: {
		            width: '220',
		            height: '20'
		        }
		    },
		    layer: {
		        background: '#fff',
		        opacity: 0.9
		    }
		},
		waiterTarget: jsonValue.update, */
	// Una vez completado guardamos el href y la información donde corresponde
		onComplete: function(responseTree, responseElements, responseHTML, responseJavaScript){
			$(jsonValue.update).set('html',responseHTML);
			//reseteamos el init() ya que hay contenido nuevo en el site.
			init();
			if (jsonValue.href && jsonValue.replace)
			 	location.hash = "#"+ jsonValue.href.replace(jsonValue.replace,"");
			//reseteamos la variable navAjaxCheck para contener la información del site actual
			navAjaxCheck = location.hash;
		}
	}).send();
};
 
//Función recursiva encargada de hacer de watchdog para la navegación asíncrona (dotando de la opción de retroceder/avanzar)
var navAjax = function()
{
	// Posibles excepciones a la navegación por AJAX
	if (location.href.test("signup"))
		return false;
 
	// Esto se da en el caso de que estemos en una URL normal tipo /casa/coche, que rápidamente la formateamos a
	// #casa/coche para que siga la lógica de navegación asíncrona.
	if (location.pathname != '/')
	{
		var href = location.href;
		var value = 'http://'+WEBHOST+'/'; // WEBHOST es una variable definida anteriormente
	 	location.href = href.replace(value,value+"#"); // por compatibilidad con IE
 
	// Comprobamos con el check generado si ha cambiado el hash de la URL,
	// en cuyo caso llamamos a goto con el nuevo hash
	}else if (location.hash != navAjaxCheck)
	{
		var href = location.hash;
		var value = '#';
		goto({ href: href.replace(value,''),  waiter:false, replace:"" });
	}
};
 
//Función principal encargada de cambiar todos los enlaces internos por llamadas asíncronas.
var addAjax = function ()
{
	// Usamos una frase de testeo simple, el dominio del site (también podría ser algo más complicado mediante exp. regulares)
	var replace = 'http://'+WEBHOST+'/';
 
	// Buscamos todos los enlaces del site
	$$('a').each(function(el)
	{
		var href = el.href;
		// Buscamos los que enlazan dentro del site y evitamos los marcados como "noAjax"
		// a los encontrados así les quitamos la opción por defecto y añadimos la opción de Ajax
		if (href.test(replace) && el.className != "noAjax")
			el.addEvent('click', function(event)
			{
				event.preventDefault();
				goto({href: href, replace: replace});
			});
 
	});
 
// función con las llamadas necesarias al cargar el site (incluir el navAjax, chequear variables...)
var init = function()
{
 
	// Añadimos el ajax
 
	addAjax();
 
	// ....
}
 
// Añadimos los eventos justo cuando el DOM ya se haya cargado.
window.addEvent('domready', function() {
 
	// Lanzamos el control de AJAX con un periodical para que se ejecute continuamente
	// el tiempo aproximado depende de la carga de JS del site y al gusto de cada uno (entre 1 y 5 segundos)
	navAjax.periodical(1000);
 
	// Cargamos el init con la información necesaria.
	init();
 
	// Cargamos el resto de funcionalidades que solo son necesarias una vez.
}
 
};

Como podréis ver, este JS está bastante mal codificado, lo suyo sería crear una clase completa que se encargue de toda la parte de navegación AJAX y hacerle mucho refactoring para conseguir algo decente, pero la idea es explicar los principios de acción, no daros un código 100% válido y correcto.

Ahora, solo tendremos que añadir al controller de la aplicación un método para cuando llegue por “/ajax/” que:

  • Defina la constante AJAX = TRUE4.
  • Coja la información pasada por la variable json del segundo parámetro y cambie la REQUEST_URI por la url del mismo. 
    1
2
3
4
5

    //Algo similar a esto debería valer
$json = /* variable con la información */
$ajax = json_decode(stripslashes($json), TRUE);
$url = $ajax["href"] ? $ajax["href"] : $_SERVER["HTTP_REFERER"];
$_SERVER['REQUEST_URI'] = str_replace("http://".$_SERVER['SERVER_NAME'], '', $url);
  • Continue de forma normal con el controller

Ahora la navegación para el resto del código es normal, hasta que llegamos a la parte de vista, donde utilizando la contante definida AJAX para saber si el usuario está utilizando AJAX o no y en caso afirmativo mostrar solo la información referente al AJAX que queremos, evitando mostrar por ejemplo la sección de “header” o las secciones fijas del template como el footer… Eso a gusto.

Como veis no es tan difícil añadir después la capa de AJAX y así se consigue una navegación con y sin JS casi-perfecta que facilitará y mucho la vida a navegadores y buscadores.

TODO: como observaréis el código JS está muy sucio y habría que hacer un refactoring completo de él. También habría que añadirle la posibilidad de controlar las anclas que ya existieran en el código (por ejemplo quitándolas y añadiendo un efecto de movimiento en la página al clicar sobre el enlace).

La parte del Controller y la de Vista las he dejado muy abiertas, esto es porque aquí cada maestrillo tiene su librillo, así que no he querido meterme mucho en como lo hago yo para no complicar más las cosas.

Y por último decir que en mi caso empecé usando una constante para definir el AJAX, pero rápidamente deseché esta opción ya que es posible que sobre una página se realicen llamadas sobre distintas secciones por ejemplo y al definir solo una constante esto no se cumple. Aquí lo que suelo hacer5 es pasar la información a través de la variable json(“update”) los campos a modificar, e incluir un código similar a este en el método que controla el AJAX para pasarlo a la parte de vista.

if ($ajax["update"])
{
	$zonas = explode ("::",$ajax["update"]);
	foreach ($zonas as $key => $value)
		$ajax[$value] = true;
}
  1. aka @aartiles ↩
  2. Solo diré que con lo fácil de modificar que dicen que es, por qué los señores de Google no han realizado ya los cambios en su código? ↩
  3. Ojo, que estamos trabajando con Mootools y ClientCide y con un código bastante sucio y obsoleto, por cierto ↩
  4. Esto es ligeramente más complicado, pero para simplificar dejemoslo así por ahora ↩
  5. Aunque también habría que refactorizar ya que no me llega a convencer ↩
By alquesada
Etiquetado como: , , , , , ,
6 Comentarios

Usabilidad, semántica web y SEO Orgánico

22
Oct/096

Vamos a intentar explicar, e interrelacionar entre si, estos tres conceptos  que a priori son tan distintos que incluso los skils de los profesionales relacionados a cada uno pueden ser completamente diferentes entre si, y sin embargo la interrelación entre ellos es sumamente fuerte.

El concepto de usabilidad en España es algo muy “novedoso“1 por desgracia, y realmente no se encuentran muchas empresas que realmente aporten este valor a sus proyectos. Dependiendo la mayoría de lo “usable” que sea el diseño que un artista plasma en su boceto. Lo peor de todo, es que posiblemente sea el punto más importante para que un desarrollo llegue a buen término. A más fácil de usar, más gente lo usará2

Según la Wikipedia 3 usabilidad se define como:

La facilidad con que las personas pueden utilizar una herramienta particular o cualquier otro objeto fabricado por humanos con el fin de alcanzar un objetivo concreto. La usabilidad también puede referirse al estudio de los principios que hay tras la eficacia percibida de un objeto.

Sobre la definición de “Semántica Web” o “web semánticamente correcta” se podría hablar largo y tendido ya que para un único concepto, IMHO entiendo que hay varias definiciones que vienen a ser todas las misma pero en distinto grado de complejidad. El concepto más básico y libre4, para web semánticamente correcta podría ser:

La correcta estructuración del código XHTML de un site de forma que se distinga correctamente el contenido del diseño y los scripts, las distintas secciones de la página y su relación en el proyecto, además del correcto uso de los ‘tags’ del XHTML con respecto a sus definiciones y significados.

Un concepto más amplio y complejo lo encontramos en la Wikipedia:

Se basa en la idea de añadir metadatos semánticos y ontológicos a la World Wide Web. Esas informaciones adicionales —que describen el contenido, el significado y la relación de los datos— se deben proporcionar de manera formal, para que así sea posible evaluarlas automáticamente por máquinas de procesamiento. El objetivo es mejorar Internet ampliando la interoperabilidad entre los sistemas informáticos usando “agentes inteligentes”. Agentes inteligentes son programas en las computadoras que buscan informacion sin operadores humanos.

O la más utópica y generalista que da la W3C en su guía breve de web semántica.

El principal problema que nos encontramos aquí es que al igual que la usabilidad, la semantica web pasa totalmente desapercibida en el 90% de los proyectos webs. Poca gente, por no decir ninguna, se dedica a mirar todo el código generado por el programador para una determinada página HTML. Mientras que la web se asemeje a lo que ha realizado el diseñador es más que suficiente.

Esto es normal en prácticamente todo lo que nos rodea, no nos molestamos en mirar como han arreglado nuestro coche, solo sabemos que funciona, por ejemplo. Por lo que aquí es el propio programador o maquetador la persona responsable de realizar un código de calidad que nunca o casi nunca será recompensado como se merece, pero que sin duda, como veremos después, tiene mucha importancia.

Sobre el SEO5 poco podemos decir que no se sepa ya. Según la Wikipedia:

El posicionamiento en buscadores o posicionamiento web es el resultado de la recuperación de información en la base de datos de los grandes Motores de Búsqueda de Internet por el uso de algoritmos de búsqueda en el software.

Este termino es por todos conocidos, desde el jefe hasta el becario y es una cosa que todo el mundo querría vender y hacer bien. Y es aquí donde una buena interrelación de los tres conceptos puede dar su mayor potencial, ya que hacer webs que sean óptimas para el SEO sin ser semánticamente correctas es bastante más complicado, y claro, una buena usabilidad del proyecto ayudará a crear más fácilmente una semántica más correcta.

Bueno, y según hemos visto, como se deben interrelacionar entre si para ayudarse? Veámoslo:

  • La Usabilidad es el primer estado de un proyecto, su objetivo es simplificar el uso de un producto o proyecto. Se podría decir que estructurarlo de forma cómoda para el usuario. Pues ahí está la primera ventaja, al estructurarlo para el usuario, ayudas enormemente a la estructuración semánticamente correcta del site. Al definir tanto el proyecto ayudas al programador/maquetador a distinguir entre las diferentes zonas del proyecto, que cambios tendrán y como se deberían estructurar, creando así una semántica web más solida y completa.
  • Como hemos dicho antes, una semántica web correcta, en su caso más básico, es una válida estructuración del código indicando las distintas secciones del proyecto. Pero esto más que para los usuarios es para los buscadores, que son realmente quienes ven el código y no el diseño. Luego es fácil pensar que si separamos bien contenido de información, cabecera y navegación del cuerpo y demás secciones, los buscadores entenderán perfectamente las distintas secciones, pondrán el peso correcto a cada sección y entenederán lo “puntos fuertes” del contenido, facilitando así el SEO Orgánico del site y su rápida indexación.
  • En el sentido contrario, tenemos que a la hora de crear una semántica web correcta, el tener buenas nociones de SEO puede ayudarnos y mucho, ya que la interrelación de Tips de SEO y secciones de la web no son pocas, fortaleciendo así la interrelación entre ambas6
  • Y en la otra parte, también tenemos que a la hora de crear la Usabilidad del site, tener nociones de semántica web, maquetación y diseño online, ayudarán y mucho a saber como crear estructuras, que secciones son factibles a la hora de pasarlo a la web, cuales no son recomendables por la complejidad que atañen o como poner las secciones para entregar el peso adecuado a cada una según el SEO Orgánico del proyecto.

Conclusión: Uno no puede ser experto en todos los ámbitos, pero si es necesario conocerlos lo suficiente para poder interrelacionar su trabajo con todo lo que hay alrededor del mismo. En este caso nos encontramos con tres sectores muy distintos, a los que llegan expertos de distintas ramas como informática, marketing, humanidades,… pero que deberían tener nociones básicas sobre los demás sectores para poder hacer un trabajo mucho más optimo en general.

que es cabecera, que es contenido, separando
  1. Véase que no le hemos hecho ni pizca de caso antes ↩
  2. Simple, verdad ↩
  3. Que recordemos no es la RAE, pero si un buen punto de partida ↩
  4. Ojo, que la definición es mia, no la toméis por axioma ↩
  5. En este caso nos centraremos solo sobre el SEO Orgánico ↩
  6. Por ejemplo, puede ayudar a la hora de poner la sección de navegación, el saber que un buscador no entiende varios divs seguidos como una correlación, sino que para esto es necesario un “UL” ↩
By alquesada
Etiquetado como: , , , ,
6 Comentarios

Cuando las cosas se hacen bien, salen bien.

23
Jun/090

Bueno, como hablar de algo sin demostrarlo, es como no hablar de nada, vamos a centrarnos un poco en enseñar como entendemos y programamos un proyecto web desde la nuezAzul. Principalmente porque esta es mi área.

También es cierto que toco un poco algunas de las demás partes de un proyecto; maquetación, accesibilidad y usabilidad (de esto poquito), SEO y SEM, branding online,…. Pero de estas prefiero ir dejando pequeños apuntes técnicos sueltos y centrarme en lo que realmente es mi fuerte, la Programación Web Avanzada. Y si, se puede decir esto y sumarle PHP sin restar el más mínimo poder a la frase.

Y para ello, lo primero es desmitificar a los que piensan que PHP es inseguro y poco profesional; el inseguro y poco profesional es el programador, no el lengjuaje.

El primer problema que encontramos con PHP es su mayor virtud. La anarquía del lenguaje. Este lenguaje se creó principalmente con una máxima; la mayor libertad posible. No es necesario definir variables, no tiene una estructura de programación definida, puede mezclarse dentro de código html o html dentro de código php…

Esto ha hecho que desde un principio, PHP fuese muy suculento para todo el mundo. Tanto programadores profesionales, como amateurs e incluso completos “novatos” de la programación pueden hacer en PHP sus pinitos y programar cualquier cosa.

Claro, esto ha dado muchas lineas de código a PHP, de las cuales la mayoría se podría decir que son basura “no reutilizable” y sobretodo muy inseguras y difíciles de auditar/ampliar. Pero claro, no todo es culpa del código, no se le puede pedir a un newbie que entienda de “Sql Injection” o de calidad de código.

Y como se podría solucionar este problema? Bueno, lo primero aquí es saber que se quiere y distinguir los casos.

  • Si eres un newbie, que solo quiere hacer sus pinitos, adelante, este es tu lenguaje y esto es todo lo que deberías leer de este blog.
  • Si realmente quieres realizar código de calidad y reutilizable, empieza por lo básico. Se lo más estricto posible, estructura el código, declara las varibles al principio de cada método, usa patrones de programación y nunca olvides la flexibilidad de PHP, pero no supedites la calidad a la flexibilidad, hazlo al revés, supedita la flexibilidad a  la calidad

El segundo problema es la rápida evolución del lenguaje frente a la lenta o inexistente evolución del programador. Tanto PHP como Apache y las bases de datos han tenido una evolución estos últimos años bastante fuerte, pasando de, por ejemplo, la programación funcional hasta la implementación de la OOP por parte de PHP, el famoso mod_rewriter de Apache o la potencia de las bases de datos relacionales. Todo esto implica un continuo esfuerzo por parte del programador para estar al día con todo lo que le rodea. Cosa que muchas veces no pasa, encontrandonos con que, por ejemplo, PHP4 no llega a desaparecer ya que implicaría restructurar mucho código o que no existan todavía casi ninguna aplicación que sea 100% OOP sino hibridos entre funcional y OOP.

Solucionar este problema es algo más complicado, cada día vemos actualizaciones de PHP, nuevas funcionalidades y otras decrépitas. Estar al día en esto podría ser algo fácil, pero si además hay que sumar el estar al día en las aplicaciones que usas, en Apache, en la base de datos con la que trabajas, revisando tu código para actualizarlo, … La cosa se complica un poco. Lo malo, esta es la única forma de solucionar el problema, es decir, si quieres realmente hacer buen código cada día, debes emplear cada día en formarte un poco más, y para esto no hay ayudas externas. Cada uno debe tener intención de leer y aprender cada día, sino, en poco más de un año, tu también estarás “decrepit“.

Otro de los defectos es la falta de estructura a la hora de programar, la falta de profesionalidad y de “seguridad de código” en lo que uno hace.  Conozco muchos casos en los que un programador, que entiende y usa la OOP, deja esto de lado porque un “proyecto es pequeño” o porque “no es necesario“. Creando archivos faraónicos, sin estructura alguna en la programación, sin revisar los posibles bugs de la aplicación, … Esto siempre es un error, pero es más error cuando esto pasa de ser para “proyectos pequeños” (Aunque nunca llegue a entender que es eso de proyectos pequeños) y se utiliza en todos los proyectos que uno hace.

El mayor problema que esto acarrea es la imposibilidad del posterior mantenimiento del site, los problemas y el tiempo perdido a la hora de implementar nuevas funcionalidades, o simples cambios en el diseño. Como siempre, el mayor problema aquí es la desfatachez del programador al pensar en el hoy y no el mañana. El mañana serán problemas para el cliente, no para el programador.

Y por último, otro de los grandes errores con PHP, es la suma de todo lo anterior, es encontrarnos proyectos “cajón de sastre” en los cuales, los programadores con buenas ideas y sin tiempo para pensarlas bien, crean proyectos, donde se mezcla funcional con OOP, viendo funciones sueltas entre clases, donde no hay una estructura definida correctamente, donde no se tratan los objetos por paquetes como cualquier otro lenguaje de programación orientado a objetos. Donde se ven funciones obsoletas o donde se ven mezclados, entre grandes ideas, código y html. Dando así grandes “cajones de sastre” de los que no se puede reutilizar gran cosa…

Como se podría solucionar? Lo primero es obviar la programación para todas las versiones y centrarse en PHP5 o superior. Versión a partir de la cual se puede hablar realmente de OOP. Y después de esto, aprender de los demás lenguajes de programación, aprender realmente lo que es el paradigma MVC (o cualquier otro que sea válido) y ponerlo en práctica, no pensar que existe un proyecto pequeño, todos son igual de importantes, pues son tu carta de presentación, usar PHP igual que usarías Java o C++ y sobretodo

TENER RESPETO, MUCHO RESPETO, TANTO A TU TRABAJO, COMO A QUIEN PAGA POR ÉL.

By alquesada
Etiquetado como: , , , , , , , , , , , , , , ,
Sin comentarios

Calendario

Más info

Donde Encontrarme

Etiquetas

Próximos eventos

  • No hay eventos.

Últimos comentarios

Archivos

Meta

Estadísticas

23 personas me han vistiado hoy.
Tu IP es: 38.107.191.81.
Tu Sistema Operativo: Search Bot.
Y estás visitandome con: .
Positions by Seo-Watcher