Sergio Gago

Cada vez que ponemos un link, o que usamos un tag, que comentamos o que hacemos una referencia o relación, estamos enseñando a las máquinas a ordenar todos los datos que hay perdidos por la Web.

“La Web 2.0 es enlazar a gente que comparte, intercambia y colabora” (Traducción literal del video)

Hasta ahora la mejor descripción que he visto de la Web 2.0, con su impresionante video.

Visto en Grancomo.

Compartelo

Este es un tema en el que llevo pensando cierto tiempo, en parte gracias a Josep M., compañero de trabajo, con el que estoy haciendo ahora una muy productiva labor de arquitectura de la información y usabilidad en un proyecto.

¿Cómo ofrecer al usuario la posibilidad de elegir SU provincia con la máxima usabilidad? (Atención que hablo de su provincia)

Pues bien, a priori tenemos dos modelos básicos: La lista desplegable y el mapa, teniendo cada uno muchas variantes diferentes, y sus propios problemas y más. Estudiemos qué hacen algunos de los portales líderes en España (que se basan en la selección de provincia):

Idealista.com
Portal dedicado a la inmobiliaria. La navegación está basada en desplegables de 6 alturas, de forma que en los dos primeros solo tenemos que seleccionar el elemento buscado, y en el tercero, la provincia propiamente dicha, será donde tendremos que bajar hasta encontra el elemento buscado.

paginasamarillas.es
No hay mucho que decir. La provincia es un desplegable estándar de un solo nivel (más de 50 opciones), y una localida de campo libre.

fotocasa.es
Otro portal inmobiliario. Precisamente estos son los que más hincapié deben hacer en la localización geográfica. Optan por un modelo similar a idealista para las opciones (alquiler, compra…), pero se basan en un modelo de mapas para la localización de provincia. El resto de pantallas están basadas totalmente en mapas también, por localidad y zona (incluso barrio en ciudades grandes). La navegación del mapa es sensible y nos va indicando el nº de inmuebles encontrados).
loquo.com
Quizá uno de los portales de anuncios clasificados con más visitas. Utiliza (si no me equivoco) localización ip para redirigir al usuario a la ciudad adecuada, ya que en este caso son los anuncios los que están localizados geográficamente.
Aun así, como barra lateral nos ofrece todas las provincias donde existe loquo, por si algo ha fallado o simplemente quermos buscar en otro sitio.

infojobs.net
Portal líder de empleo en España. Aquí, lógicamente, la función de seleccionar la provincia donde quieres trabajar, es imprescindible. En este caso tenemos un desplegable de un solo nivel. (Luego veremos que también hay que valorar el espacio disponible).

atrea.com
Otro portal inmobiliario, del grupo BBVA, quizá menos conocido que idealista o fotocasa, pero que alexa no le trata nad mal. En este caso ofrecen las dos posibilidades: Tres listas desplegables de un solo nivel, que se autorrellenan con el anterior: País, provincia, y localidad. Y mapa que añade detalle en función de lo que vayamos seleccionando

enalquiler.com
En este portal ya asumimos que solo vamos a alquilar, de forma que los tres desplegables de 7 niveles son para el tipo de vivienda, la provincia y el precio. Eso si, los primeros elementos que muestran son los que más viviendas tienen. Tratando de simplificar el uso al mayor porcentaje de usuarios.

laboris.net
Otro portal de empleo que usa dos desplegables de un nivel tanto para provincia como para categoría.

niumba.com
Niumba es un portal de alquiler de viviendas para vacaciones, por lo que las zonas con las que trabajan están muy localizadas. De hecho, permiten buscar por provincia o por zona (costas sobre todo), pero al igual que atrea, permiten una búsqueda por desplegables de un nivel, o una selección por mapa, que contextualmente nos dice dónde estamos y qué oferta hay en ese punto.

segundamano.es
Portal de anuncios de intercambio propietaria del grupo anuntis. En la home no nos ofrecen ningún buscador, sino una lista enorme de categorías y subcategorías, y ya dentro de una de ellas podemos seleccionar la provincia en un desplegable de un nivel.
compraventa.com
Otro portal de anuncios de compra venta, en cuya home en lugar de pedirnos la categoría nos piden la localización, con mapa o con listado de todas las provincias. Está claro que se centran mucho más en el lugar que en la categoría de anuncio.

Estos son solo algunos ejemplos de portales que comen todos los días cantidaes ingentes de tráfico, pero sin duda hay muchos otros (que si queréis podéis dejar en los comentarios).
El primer problema que nos encontramos está en cómo clasificar este elemento. Si estuviéramos hablando de nuestro menú propiamente dicho, se puede concluir que las listas desplegables están hechas para formularios, y que se deben buscar otros elementos.

Pero tampoco estamos hablando de un elemento de formulario propiamente dicho (al estilo tradicional, se entiende). Estamos viendo un elemento que se nos muestra desde la home de nuestra página, y que de su utilización depende el resto de la navegación en el sitio, vamos, con una criticidad demasiado alta para ser obviada, sobre todo cuando hablamos de portales que venden ítems centrados geográficamente.

Entonces, tenemos que tener en cuenta los siguientes factores:

• Espacio disponible y criterios:
  ¿Con cuánto espacio contamos? ¿Cuántos elementos más tenemos en la página? ¿Será el único modo de navegación o el usuario puede elegir otros criterios de búsqueda? Si nuestra búsqueda es impepinablemente por localización, quizá necesite más peso.
  Es importante también el dónde lo vamos a colocar, y los criterios anteriores que le hemos hecho seleccionar. Por ejemplo, si tenemos que elegir un tipo de vivienda, una provincia, luego un precio y luego introducir un término para buscar, probablemente pocos usuarios introduzcan ningún término, porque después de seleccionar tres ítems, es más fácil darle a un botón que pensar en un término:La búsqueda más crítica, deberá tener el máximo espacio y estar situada en un “hotspot” de nuestra página. El usuario debe captar la criticidad del elemento. Si hay varios elementos de búsqueda, dividámoslos, fuera frustración!

• Usuarios target
  ¿Quién es nuestro público? ¿Gente que quiere vender en su barrio? ¿Gente que busca un piso en cualquier provincia de España? ¿El público conoce bien su geografía? ¿Qué nivel tienen de internet? En general, la gente es lenta tecleando y buscando, por lo que tenemos que simplificar y adelantarnos a sus pensamientos.Si tu público conoce bien el mapa, puedes ponérselo, será más fácil que encuentren algo en un elemento conocido donde ven todos los ítems a la vez, que estar buscando en una lista. recuerda: hay pocos usuarios que sepan que en una lista desplegable, si das a la “v” te irá directamente a “Valencia”.

• Accesibilidad: ¿Cómo se verá sin JS o sin imágenes?
  ¿Qué va a ocurrir a nivel de accesibilidad? ¿Cómo se quedará tu página si la desnudas y la dejas sin JS? ¿Y sin CSS? ¿Tus mapas son en flash?Si usas tecnologías no estándar, ofrece alternativas a la navegación (aunque menos visuales). Si usas mucho javascript, o ajax, también. Haz pruebas de navegación desactivando todo esto a ver cómo aparece. Acuérdate de los lectores de pantalla y de las versiones HTML plano.

• Dispersión de los datos
  ¿Estás en todos los sitios, pero mucho más en unos que en otros? Si el 90% de tus usuarios entran en tu portal para buscar jamones, pónselo en portada.Si Madrid y Barcelona ocupan el 95% de tus ofertas de trabajo, pónles un atajo. Es cierto que supone “menospreciar” a los usuarios de lugares con menos oferta, pero se trata de llegar a un acuerdo.

• Profundidad de los datos
  ¿Cuál es el nivel de selección? ¿Comunidad autónoma? ¿Provincia? ¿Localidad? ¿Otras? ¿Variadas? Este es un problema típico en las inmobiliarias. Si busco Valladolid, podríamos englobar, capital, y provincia, como mucho algunos pueblos grandes de alrededor. Sin embargo en Barcelona tiene sentido ver por separado la capital, del Vallès, Sitges, etc… ¿Hasta donde profundizaremos en nuestro mapa?En primera instancia, el usuario debe ser “universal”. No tiene sentido que un usuario que aún no nos ha dicho si es de Madrid o de Barcelona, pueda escoger Alcobendas. Según bajamos en la navegación podemos ir dándole más opciones, siempre con la opción de “todas las localidades”. Esto también depende de la dispersión de los datos. ¿Tenemos 500 inmuebles en Barcelona y 2 en Terrasa?

Para finalizar y concluir, me sigo quedando con los mapas, siempre, teniendo en cuenta los factores de arriba. Además, existe otro factor que he comentado y que también es muy importante: Nuestra Web debe ser homogénea. Las búsquedas de provincia deberán ser todas iguales.

¿Experiencias? ¿Opiniones?

Compartelo

Hoy navegando, he llegado por casualidad a la Web de una empresa de diseño Web, inicialmente muy parecida a las otras miles que hay por España. Pero cuando ha empezado a salir una sonrisa de mi boca ha sido cuando he llegado a su política de precios:

• 5 Pantallas destinadas a las diferentes necesidades de tu actividad o negocio, por ejemplo: Quienes Somos, Nuestros Servicios, Dónde Estamos, Solicita tu Presupuesto, etc.
  Con 5 basta, ni una más ni una menos.
• 1 Pantalla con un Formulario para que puedas recibir datos en tu E-mail (pedidos, información…).
  A sabe cómo está hecho el formulario… probablemente un “mailto:” en el action.
• 1 Pantalla para confirmación de envío del Formulario (siempre que tu servidor lo permita).
  Guau.. .tecnología punta
• 12 Fotografías que puedes distribuir en las 5 pantallas principales (facilitadas por ti).
  Ni una más ni una menos, no sea que tengamos que retocar más de lo debido en photoshop.
• Logotipo de tu empresa en cada pantalla (facilitado por ti).
  Por supuesto!
• 1 Diseño de pantalla estándar que puedes elegir entre los diferentes modelos que tenemos actualmente disponibles.

Y cuando dicen página estándar, dicen una colección de plantillazos sacados de variantes de template monster y derivados que aplican a varios clientes. Es más, peores derivados de template monster, porque ni siquiera cumplen estándares.

Precio: 250€, sin Iva, ni registro de dominio ni hosting.

Analizando un poco las webs generadas (estas cosas me fastidian más de lo debido, y le suelo dedicar algo de tiempo), vemos que:

• Están desarrolladas íntegramente con dreamweaver (vale, esto no es tan malo).
• El < ! DOCTYPE > brilla por su ausencia, así como el tipo de codificación utilizada.
• La mayoría de las etiquetas están en mayúsculas.
• Maquetan absolutamente todo con tablas (volvámos a los 90!)
• Por supuesto, no valida, se usan parámetros de estilo en el html no siempre válidos, y los alt de las imágenes no existen (y mira que el dreamweaver te lo pide!).

Eso si, puedes pedirles un presupuesto personalizado:

• Cada pantalla HTML con texto (tamaño a4): 35€
• Cada imágen: 2€
• Formulario: 38€
• Inserción de logotipo: 2€
• Pantalla HTML emergente (toma ya!): 10€
• 3 Banners rotativos: 6€
• Imágen de fondo por pantalla: 2€
• Midis por pantalla: 2€
• Contador de visitas: 9€
• Tablón de anuncios con CGI: 60€
• Lista de correo: 60€
• Diseño de interface con elementos de navegación: 60€
• Barra de navegación personalizada: 180€
• Mantenimiento y modificaciones. 9€
• Alta en 150 buscadores: 80€
• Ser un Webmaster de finales de los 90 en pleno fenómeno “2.0″ no tiene precio.

Y lo más divertido viene cuando en su página principal, “denuncian” a otras Webs por plagiar su plantilla… me pregunto qué pensarán sus clientes cuando vean que su web es exactamente igual que otra…

No se cuánto facturarán (ni me importa demasiado), pero al final tendrán fecha de caducidad…

Nota: No he puesto su Web a propósito, pero si alguien la quiere, me la puede pedir personalmente.

Compartelo

Esta entrada tiene dos motivos, por un lado presentar enseñaros una presentación de Bob Martin, y por otro, presentar InfoQ, una web para desarrolladores repleta de buenas presentaciones, como ésta de Los principios del diseño ágil orientado a objetos. Hay una buena colección de presentaciones, algunas acompañadas con sus transparencias que van cambiando conforme avanza el tema. Peeeeero, en inglés.
Y la otra parte es la presentación vinculada: La gestión de la dependencia, mal utilizada, es frágil, inelástica, no reutilizable, y muy rígida. En esta presentación, Bob Martin nos presenta sus principios del desarrollo ágil, en una presentación bastante divertida para los que sepáis suficiente inglés. Como decía Bertrand Meyer: “Los módulos deben ser abiertos a la extensión pero cerrados a la modificación”, a lo que amplía Bob, la clave está en la abstracción.

Compartelo

Desde que conocí la metodología de programación extrema hace unos años, me di cuenta de que estaba hecha para la Web. Aunque inicialmente estuviera pensada para cualquier tipo de desarrollo (sobre todo Java), realmente encaja a la perfección con un proceso de desarrollo Web normal.

La XP es uno de los muchos procesos ágiles que hay ahora mismo disponibles, y que se basa fundamentalmente en olvidarse de que no podemos adelantarnos a los cambios de requisitos, y a que los clientes siempre serán aleatorios y caóticos. De modo que nos propone varias pautas a seguir a la hora de gestionar nuestro proyecto. Copio los epígrafes del artículo en la wikipedia, adaptándolos a un desarrollo web medio - grande.

• Desarrollo iterativo e incremental: El desarrollo en espiral evolucionado. No podemos presentar directamente la imágen a un cliente, o a unos usuarios. Aquí entra la labor de bocetado, prototipado, pruebas de usabilidad, etc. Poco a poco vamos aumentando fidelidad a los prototipos hasta que desarrollamos la lógica de negocio completamente (donde el cliente ya pinta poco). Y como decía hace unos días: Da igual que tu algoritmo sea el mejor y más eficiente… si es feo, al cliente no le va a gustar!
  Y respecto a incremental, el hecho de ir añadiendo módulos, o funcinoalidades hace que el desarrollo sea menos caótico, algo nada nuevo dentro del desarrollo Web.

• Pruebas unitarias continuas. Hoy en día con Firebug, esto es más fácil que nunca. A la hora de desarrollar la GUI, trabajar con los efectos JS y el CSS (sobre todo con librerías), cada vez que vamos al navegador y pulsamos F5 para comprobar los efectos del último hack incluido no estamos haciendo más que pruerbas unitarias. Esto inicialmente estaba pensado para JUnit, y para la preparación de los casos de prueba de las clases antes de la programación de las mismas. Esto también lo podemos hacer en la lógica de negocio de nuestras clases. De hecho una técnica para fidelizar al 100% los prototipos es desarrollar toda la lógica de presentación apuntando a clases de prueba, que en lugar de sacar los datos de una capa de acceso a datos, tiene un contenido dummy (arrays escritos a pelo en una clase PHP). De esta forma, la interfaz da la impresión de estar terminada, pero realmente no hay nada por debajo.

• Programación por parejas: Esta es la parte que más me gusta, y que aunque parezca mentira realmente funciona. Mientras uno codifica, el otro va diseñando y realizando pruebas, preparando la codificación y comprobando lo que va haciendo el otro. Cuando hay un error que se nos atasca no hay nada mejor que pedir a alguein que lo eche un vistazo, y la programación por parejas va un poco por ahi. En el mundo del desarrollo Web es común hacer esto en parejas de diseñador gráfico - maquetador, o programador - analista, pero la idea es que haya cuatro ojos mirando el mismo monitor.

• Frecuente interacción del equipo de programación con el cliente. De hecho, el método propone que haya un miembro de la empresa cliente en el equipo de desarrollo. Esto es bastante inviable en el 99% de los casos, pero lo que si se puede hacer es un constante trabajo de pruebas y mejoras continuas. De nuevo, volvemos al prototipado y las pruebas con el cliente. Desde diagramas de casos de uso que sean entendibles, hasta documentación (no técnica), pasando, claro, por reuniones de seguimiento y de pruebas, documentadas y en acta.

• Corrección de todos los errores. Lo ideal es que cada “entrega” o “hito” no dure más de una semana. Cuanto más cortos mucho mejor, pues se genera menos ruido o caos en el código general. Y una filosofía que pocos apliacan. No se añaden funcionalidades hasta que se han solventado todos los errores de las existentes. En Web esto es muy importante. No nos sirve de nada implementar un mashup de google maps en nuestra aplicación, si la página no se ve bien en firefox!

• Refactorización del código. Aunque depende mucho del sistema que usemos (Java con struts y JSP, PHP, Ruby on Rails….), es importante refactorizar el código para aumentar la escalabilidad y el mantenimiento. En prácticamente todos los desarrollos informáticos acabas utilizando más librerías o implementando más funciones de las que necesitas. Muchas veces haces código duplicado, y otras podrías haber usado algún patrón de diseño para mejorar el código y hacerlo más claro. Lo idea es que cada iteración de la aplicación sufra una refactorización total, por supuesto sin modificar las funcionalidades. ¿Qué implica esto en el D. Web? Separar los CSS por tipo de presentación y módulo, juntar los JS de funciones similares, o separar los que no tengan nada que ver, buscar herencias y polimorfismos en el código e implementarlos, etc… Aquí la diferencia se nos dará en clarificación de código, y tiempo de carga (pasar de cargar código javascript de 80kb a cargar 30kb).

• Propiedad del código compartida: Todo el código es de todos y cualqueira puede modificar cualquier parte. Aquí estoy de acuerdo sólo si usas un buen control de versiones. Pero en los desarrollos Web es más común que un pequeño cambio afecte a toda la aplicación, de forma que se hace necesario que todos los desarrolladores conozcan todo el código y estén capacitados para modificarlo.

• Simplicidad en el código. Esto está claro, pero ampliarlo a simplicidad en la interfaz, en el diseño (no solo gráfico, sino de la aplicación), y por supuesto, cumplir con estándares y validaciones.

En general es útil cuando los equipos no son muy grandes (no más de 8 personas), y cuando son ágiles. La consultora tradicional tendrá muchos problemas para adaptarse. Sin embargo el equipo de jóvenes desarrolladores de una start-up, lo tendrán como el modelo ideal. Ergo concluyo: La programación extrema puede ser el mejor paradigma de programación para la creación de start-ups.

Más info en la web de difusión del extreme programming.

Compartelo

Llevo tiempo pegándome con las aplicaciones Ajax para conseguir hacerlas más accesibles.

Por una parte, el hecho de ser más dinámicas nos permite una interacción mejor, y si ésta está más cuidada, podemos hacerla mucho más compatible con muchos timpos de deficiencias, sobre todo visuales (a nivel cromático, por ejemplo). De hecho, no resulta dificil en una aplicación ofrecer un cambio cromático accesible, o un aumento del tamaño del texto.

El problema estaba en los lectores de pantalla, que hasta ahora parseaban la página al entrar (casi como un robot web), y cualquier actualización posterior no conllevaba a la lectura. Es decir, que al entrar en una Web, JAWS nos leería el primer contenido que nos encontraba, pero si cambiabamos cualquier cosa con innerHTML, el lector no se enteraría de nada, salvo que hiciéramos unos hacks poco recomendables.

Pues bien, leo en Sentido Web, que la gente de Juicy Studio ha estado trabajando en ello y ahora es posible dar más accesibilidad a nuestras Webs que usen Ajax. ¿How-to?

Primero estaría bien dar una pasada rápida a cómo funcionan los lectores de pantalla. En este artículo lo explican bastante bien, denotando los problemas con Ajax, y los modos de lectura.

JAWS utiliza un buffer virtual, que de forma normal, se actualiza de forma síncrona en función de las acciones del usuario. Pero al igual que Ajax lo que hace es “asincronizar” nuestra aplicación, también debemos “asincronizar” dicho buffer virtual, haciendo que nuestras llamadas al servidor también actualicen a JAWS (hablando rápido y mal).

Si vais a la página del artículo podéis ver el pseudocódigo que haría esto, bastante claro y sencillo. Al final, se trata de un hack o engaño al programa, pero que nos puede servir para cumplir nuestros objetivos de accesibilidad, y quizá una alternativa al formato “texto plano”.

Compartelo

Pero no el posicionamiento en google, sino el de negocio, un posicionamiento que en muchos casos, se olvida.

Todo esto viene a través del artículo ¿Cuánto vale una web profesional? en Tecnotertulia, que me ha parecido muy interesante y me ha recordado a las charlas que tenía con mis socios hace tiempo (aunque no he podido dejar un comentario).

Y hoy publican “La Respuesta“, que en parte, contesta a lo que escribo en este artículo.

Divide los presupuestos de Webs en Gratuitos - De 500 a 2000€ - de 2000 a 9000€ - de 9000 a 22.000€ y de 22000 a 500000€. Clasificación que me parece bien, pero que yo diviría en función del personal y tiempo involucrado en el proyecto. De modo que respondan a estas preguntas:

• ¿El proyecto tiena la suficiente extensión para requerir un jefe de proyecto dedicado a planificación y seguimiento?
• El proyecto lo va a llevar a cabo una sola persona o harán falta distintos roles? Diseñador gráfico, analista, maquetador, programador, experto SEO, DBA…
• ¿Las herramientas de desarrollo requieren licencias? ¿Será de creación propia o se usarán módulos de otras aplicaciones (código libre)?
• ¿El proyecto requiere mantenimiento? ¿Se garantiza posicionamiento? ¿Hay que preparar documentación? ¿Formación? ¿Presentar memoria?
• etc…

Al final todo esto “cala” mucho en la empresa que desarrolla (y aquí quería llegar). Información sobre “cuánto cobrar” por un desarrollo hay mucha y muy variada, y cada uno te dirá una cosa, pero al final lo que importa es que cada uno encuentre su nicho de mercado (que no siempre tiene que ser el de los precios más bajos).

Si tus clientes son grandes empresas con grandes expectativas, no aceptarán presupuestos de 1000€, y si vas a vender una web a una pescadería que no va a entender la diferencia entre usar estándares o plantar su texto en una plantilla, probablemente 300€ será mucho. Cuando nosotros vendiamos webs por 600€, nuestro trabajo era medio, con bajones de vez en cuando, pero cuando cambiamos la filosofía a “desarrolladora cara” incluso para pymes no bajando de 2000 o 3000€ por proyecto, de repente empezaron a llover trabajos, encontramos nuestro nicho. Y si alguien decía que eramos muy caros, le decíamos que eso era porque lo hacíamos mejor.

Compartelo

AlphaWork services es una especie de google labs de IBM, donde desarrollar aplicaciones (sobre todo) Web punteras, e intentan innovar en la forma de mostrar la información que tenemos actualmente.

Uno de los últimos trabajos que he visto es el Many Eyes, una aplicación social para la visualización y preparación de información colaborativa. Es decir, que grupos de usuarios puedan representar de forma social la información que deseen usando varios tipos de gráficos, entre ellos evoluciones de tag clouds.

Recomiendo echar un vistazo al tour de la aplicación, donde podemos ver el potencial que tiene la herramienta.

Cosas similares se hicieron con Quintura, por ejemplo. También recomiendo la lectura del artículo de Yusef Hassan-Montero y Victor Herrero-Solana: Improving tag clouds as visual information retrieval interfaces, que ya se puso en un comentario de este blog.

¿Hasta donde pueden llegar las nubes de tags para las categorías? ¿Cuál es la utilidad real a nivel de usabilidad?

Compartelo

Según Salvador Aragón, en el convergence Weblog del instituto de empresa, la Web 2.0 y las redes sociales están aumentando la brecha generacional en cuanto a los usos que dan de la red los jóvenes y los más mayores.

Todo esto viene de una de las sesiones del World Economic Forum, basado en un documento muy interesante de revisar.

Me gusta la forma que tiene Antonio de concluir el artículo, diciendo que las nuevas generaciones, desarrollamos una formas de comunicación y aprendizaje nuevas, que en muchos casos son de difícil comprensión para los más mayores y sus empresas.

Esto me ha dado y un Deja Vu, y me ha recordado cuando hace años intentaba vender webs a los directores de grandes bodegas de la Ribera del Duero (cuando ahora no hay ninguna que no tenga).

Estoy de acuerdo con Antonio en que existen modelos de comunicación gestados por nuevas generaciones y que dificilmente serán usados por los más mayores (myspaces por ejemplo), pero creo que el problema no está en las redes sociales como tal, sino en la segmentación que se da del propio mercado. El cánon puede ser el mismo, la forma de implementarlo diferente.

Compartelo

He leido en Sentido Web esta entrada que habla de PHP Maker , una herramienta que no conocía, y que me de haberlo hecho me habría ahorrado unas cuantas horas de trabajo.

A la hora de desarrollar aplicaciones web, en la parte de acceso a datos suelo implementar dos modelos diferentes, uno basado en consultas, y otro basado en “maestros”. Aunque no es nada nuevo, trataré de explicarlo un poco.

• Servicio de consultas:
  Sería una parte de la capa de acceso a datos que gestiona todas las consultas necesarias para ofrecer información a la lógica de negocio. Búsquedas concretas, ordenaciones, extracción de información de tablas diferentes en función de variables determinadas, etc… Id est: “Quiero ver los últimos 10 posts del usuario X en la categoría K”. Esa consulta implica varias tablas, y parámetros que nos ha pedido el usuario de antemano.
• Servicio de maestros:
  En ocasiones es necesario obtener toda la tupla de información de un registro, para cualquiera de las modificaciones básicas (CRUD - Create, Retrieve, Update, Delete, es decir: Crear, Obtener, Actualizar, Modificar registros). En esas ocasiones con un identificador nos puede valer para obtener toda esa tupla.
  Pues bien, este servicio hace unas labores tan concretas y tan optimizables, que tiene sentido separarlas en un servicio aparte, y que sea la lógica de negocio y el acceso a datos el que decida qué usar en cada momento.

Entonces, este PHP Maker, nos sirve para generar automaticamente scripts de acceso a datos a partir de una base de datos, y por lo tanto nos ahorra mucho trabajo.
Para ser sinceros, no lo he probado en mis propias carnes, pero tiene muy buena pinta. Y en la misma página ofrecen XMLMaker, o ASPMaker, que prometen soluciones del estilo. Merece la pena probarlo!

Compartelo