Entre las características del administrador nos encontramos con administración de usuarios, objetos, ficheros y del sitio, gráficas con relaciones de los usuarios, múltiples sitios por instalación, internacionalización, sistema de etiquetas, ACL, vistas, eventos, plugins y API para widgets.

Además permite RSS, FOAF, XFN, OpenId, OpenSocial, OAuth, JSON, Ajax con jQuery, sistema de caché que permite memcached.

Lógicamente, el usuario final dispondrá de su perfil, panel, feeds de su actividad, preferencias, blog, aplicaicones OpenSocial, repositorio de ficheros, foros y mucho más.

Elgg necesita PHP 5.2+, Apache, GD, MySQL 5+ y mod_rewrite. A parte OpenSocial necesita Mcrypt y la librería PHP SOAP.

Elgg

Vía / WebAppers

Kenai provee a los proyectos de SVN y Mercurial, foros, listas de correo, wikis, sistemas de bugs y personalización de tu página.

Porject Kenai

• Evita usar imágenes complejas o grandes: cuanto más ligeras sean antes cargarán.
• Optimiza las imágenes: existe diferentes formatos, y cada cual es conveniente en un caso. Los más usados son GIF, PNG y JPEG. JPEG y PNG tienen un valor de calidad de la imagen, reducirlo puede hacernos ganar algunos Kb y no perder en calidad.
• Indica el tamaño de las imágenes en el HTML: así el navegador sabrá como repartir el espacio para la imagen antes de que cargue por lo que el render de la página será más rápido.
• Precarga imágenes: aquí el autor dice un consejo un tanto peculiar, no sé si bueno o malo, pero sí interesante. Se trata de cargar imágenes grandes en páginas anteriores y asignarle el tamaño 1x1 para que no se vean y así esté cargada anteriormente. Eso sí, forzaría a que tire de caché para que no te la cargue dos veces.
• Animaciones flash: si tienes que usar una animación no uses GIFs animados (sí, algunos te encuentras aún), usa flash, pero tampoco te pases.

Top 5 tips to decrease the load time of your websites via images

Vía / Begin Rescue

• Menos es más, no uses mas código del necesario
• No uses CSS o Javascript dentro del HTML, ya sea en las etiquetas como en el head.
• Usa código semántico, las cabeceras mediante etiquetas h1, h2, ..., resaltar mediante strong, ...
• No uses meta etiquetas redundantes
• Usa microformatos para hacer tu sitio legible
• Usa tablas solo para mostrar tablas
• Usa rel="external" para enlaces externos, no uses target="_blank", hazo mediante Javascript
• No uses Javascript mediante enlaces
• No muestres contenido importante mediante Flash o Ajax, siempre mediante HTML plano

10 Coding Guidelines for Perfect Findability and Web Standards

Las características que nos ofrece son:

• Grabación y reproducción de casos de test
• Selección inteligente de campos mediante sus ids, nombres o XPath
• Autocompletado para todos los comandos de Selenium
• Paso a paso
• Debug y puntos de parada
• Guardar los test como HTML, scripts de Ruby, ...

Disponemos de un gran tutorial de uso aquí

Selenium IDE

Gracias Taufpate por el aviso.

Tutoriales, consejos y referencias

• Cómo hacer una nube de tags en PHP, MySQL y CSS
• Nubes de etiquetas con ColdFusion
• Nubes de etiquetas en ASP.NET
• Nube de etiquetas en PHP
• Consejos para diseñar tu tag cloud
• Mejor método para programar las nubes de etiquetas
• Sub tag cloud mediante hover y jquery

Inspiración

• Galería de tag clouds: ejemplos y buenas prácticas

Generadores

• TagCloud generator
• Tag Cloud Generator (otro)

Everything Tag Clouds

• How to create a Facebook application for your youth group news or blog
• Facebook's Simple Tutorials
• NewsCloud
• Running a Cron Job With Your Infinite Session Key
• Automatically Update all your User’s Facebook Profile
• PledgeBank Facebook integration
• Sample FBML code and description of application architecture
• How To Set Up A Facebook RSS Feed Reader Application For Your Blog (muy completo)
• 10 Things that would have been nice to know when starting my facebook application
• 5 Facebook Application Gotchas
• From inside facebook - 10 tips on promoting your app

Vía / Got Ads?

Para aquellos que se encuentren en esas circunstancias, espero que los consejos que os voy a comentar, sacados de mi propia experiencia en el desarrollo web, os sean de utilidad.

Echa un vistazo preliminar

Aún no sabes cómo es el código, si es bueno o es malo, pero un vistazo preliminar a la estructura de directorios y a los nombres de los ficheros suele darte una idea aproximada de la funcionalidad que pueden tener.

Por muy malo que sea un programador, éste tiene su propia lógica para la nomenclatura, échale un rato a intentar adivinarla y así podrás localizar ficheros de forma más sencilla en futuras modificaciones.

No esperes un diseño MVC claro, quizás ni exista y esté todo mezclado. Tú tienes tu forma de programar, pero aunque para ti sea perfecta, ni quizás lo sea, ni todo el mundo la comparte.

No intentes entenderlo todo de golpe

Lo más seguro es que no debas cambiar toda la aplicación de golpe, por lo que de poco te va a servir empezar a estudiarla completamente y entender todo su significado. Ve por partes, si tienes que hacer un cambio en una parte céntrate en esa parte del código y olvídate del resto.

Cuando te hayas pegado con una parte del código no se te olvidará fácilmente, por lo que si en otra ocasión tienes que volver a tocar esa parte te será más sencillo.

Empieza por el final para llegar al origen

Afortunadamente el resultado del desarrollo web es visible para todos, tan solo debes ver el código HTML para ver qué se ha generado con la aplicación.

Normalmente, las modificaciones que se suelen realizar son del tipo "en tal página falla tal cosa". Mira el HTML de esa página y encuentra algo que pueda ser exclusivo de ella.

Busca nombres de clases de etiquetas, las cabeceras de las páginas (<h1>..<h6>), textos explicativos. Una vez creas que tienes un texto más o menos exclusivo de esa página busca entre todo el código, por ejemplo en Windows puedes usar GlobalFind.

Debes tener cuidado porque a veces el código no aparece exactamente como lo buscas. Por ejemplo un texto largo puede estar dividido en varias líneas:

$texto = 'Texto largo que el desarrollador ';
$texto .= 'a cortado en líneas para verlo más claro, ';
$texto .= 'aunque sea menos eficiente por tener que ';
$texto .= 'concatenar strings.';

O también puede darse la circunstancia de que el texto se forme por la unión de un texto y una variable:

$clase = array('empleados', 'facturas', 'resumen');
// Algo de código por aquí
echo '<div class="'.$clase[$tipo].'">...</div>';
// Más código

Quizás te encuentres con ficheros de idiomas, y verás que el texto que buscas está asociado a un código, céntrate en ese código y búscalo.

Usa trazas

La lógica del código es de todo menos lógica. Te vas a encontrar con partes de código que no vas a entender por mucho que lo estudies. No es bueno perder el tiempo intentando entender el código al 100%, ya tendrás tiempo para ello.

Cuando te encuentres con un trozo de código que no entiendas, métele trazas a todos los bloques para saber por dónde pasa:

echo 'Empezamos';
if ($condicion1 && $condicion7) {
  echo 'Paso por aquí 1';
  // código
  if ($condicion3 || !$condicion4) {
    echo 'Paso por aquí 2';
    // código
  } else {
    echo 'Paso por aquí 3';
    // codigo
    if ($condicion5) {
      echo 'Paso por aquí 4';
    }
  }
} else {
  echo 'Paso por aquí 5';
  // código
}
echo 'FIN';

Fijándote en las trazas que devuelva verás que código se ejecuta y así podrás encontrar mejor el error.

Ten en cuenta la base de datos

La BD es muy importante a la hora de localizar información. Mucha gente usa la BD para almacenar los mensajes de error o de información, que serán fundamentales para comprender el funcionamiento de la aplicación.

Localiza dónde se ejecutan las consultas, si hay suerte estarán separadas del resto de código (normalmente a las clases que tratan con la BD se le llama modelos). Si tienes que modificar los datos que devuelve una consulta, aunque no sepas cómo se obtienen esos datos (la sentencia SQL exacta), si que puedes hacerte una idea de las tablas a las que accede. Busca entre los modelos el nombre de esas tablas y filtra por los campos que muestra en la página. Claro que el select * from puede ser nuestro mayor enemigo.

Examina los datos de la tabla para ver si coincide con los datos que se muestran. Un ejemplo sencillo es insertar un registro mediante la aplicación y ver qué se ha guardado en la BD, así entenderás más facilmente qué se guarda en cada campo.

No olvides los ficheros de configuración

En ellos está mucha de la lógica de la aplicación, estudiarlos durante un rato puede aclararnos muchas cosas, como por ejemplo rutas de ficheros, conexiones a la BD, sistema de trazas, clases auto-ejecutables...

Cuidado con las aplicaciones externas

Si programas en Java es posible que no encuentres el por qué de un problema porque quizás la ejecución dependa de un JAR externo. Localízalos y tenlos siempre presentes. Si trabajas con Linux o Unix puede que haya llamadas a la shell. Pasará algo parecido a los JAR, deberás saber dónde están y qué hacen.

Empieza por los cambios sencillos

No intentes poner la aplicación del revés o cambiarla radicalmente nada más empezar con ella. Ve poco a poco, con cambios sencillos, que te hagan enfrentarte con el código y empezar a conocerlo.

Los cambios que puedas realizar en una parte no sabes donde van a poder afectar, por eso debes ir con cuidado y empezando con cosas sencillas, que tendrán menos posibilidades de estropear otras cosas.

Un cambio en varios lugares

Reutilizar código no siempre es una norma para los desarrolladores. Aunque creas que has localizado el lugar dónde debes cambiar el código, no pienses que es el único lugar. Sigue buscando a ver si hay más lugares donde se deba cambiar.

Testea constantemente

No conoces la aplicación y no sabes que puedes estropear cuando tocas algo. Un cambio sin importancia puede hacer que todo falle, ten cuidado si arreglas algo de no estropear otra cosa.

• Fondos de pantalla grandes: los fondos de pantalla grande pueden hacer que el diseño resalte, a parte de que son fáciles de añadir.
• Layout original: no es la primera vez que veo diseños con secciones de tamaños que superan el ancho y alto del navegador y que para acceder a cada sección hay que hacer un scroll progresivo (mediante javascript). Son originales y en algunos casos muy acertados. En el ejemplo que os pongo, cada color es una sección y el tamaño original tiene un ancho de 6000px.
• Navigación creativa: la navegación puede dar mucho juego para mejorar el diseño, ya sea mediante rollovers u otras cosas. Eso sí, ante todo que prime la usabilidad. En el ejemplo que os paso los menús van a juego con los colores de la calle.
• Minimalismo: aunque por ahora se ha tratado de consejos con un gran diseño, eso no implica que un gran diseño tenga que ser aparatoso, puede ser perfectamente minimalista, lo cual hace que llame mucho la atención.
• Logo: está claro que un buen logo hace que te represente y además te diferencie.
• Layout horizontal: aunque la gente está acostumbrada al scroll vertical, este tipo de diseño puede llegar a ser muy atractivo, aunque haya gente que lo odie.

6 Methods to Make Your Website Standout

• Olvidarse del tableless: si, aunque sea duro, es mejor volver a las tablas y olvidarse del posicionamiento y la maquetación vía CSS.
• Usar los estilos dentro de las etiquetas: la mayoría de los lectores de correo online ignoran lo que hay entre la cabecera del HTML, por eso es conveniente usar los estilos dentro de las etiquetas.
• No uses imágenes de fondo: aunque para un buen diseño puede ser esencial, hay algunos lectores que no mostrarán los background, por lo que es mejor no usarlos para asegurarnos de que todo el mundo vea correctamente el correo.
• Considera las imágenes bloqueadas por defecto: por seguridad los clientes de correo bloquean las imágenes por defecto, por lo que no es conveniente usarlas para indicar el contenido del mensaje.
• Usa el atributo alt en las imágenes: como estarán bloqueadas por defecto, es necesario indicar la mayor información posible en ese atributo.
• Usa paths absolutos: ya que el mail se leerá en otro servidor es necesario indicar la ruta completa para que los contenidos se vean correctamente.
• Ten cuidado con el tamaño de los archivos: a parte de que el usuario no debe esperar para poder leer el correo, algunas veces los correos con archivos pesados son considerados spam.
• Evita flash y similares: evita el uso de flash u otros contenidos multimedia que puede que no se vean en el cliente.
• Diseña para espacios pequeños: aunque se trate de un HTML no siempre el espacio donde se ve es amplio, piensa en dimensiones pequeñas a la hora de diseñar.

9 best practices for email design

Vía / CSS Globe

• Controles no estándares: los enlaces, botones, radio buttons y demás controles tienen una utilidad específica y estándar. Cambiar el comportamiento no es lo correcto y no hace más que confundir al usuario.
• Inconsistencia: diferentes cosas para una misma utilidad, usa lo mismo en el mismo lugar para la misma acción.
• Acciones no perceptibles: se debe saber qué acción realiza un control a simple vista. Si hay que investigar para qué sirve algo no cumple su cometido.
• Controles sin reacción: cada control debe indicar 3 cosas: mostrar a los usuarios el estado actual, cómo se interpretan los comandos y qué está pasando.
• Malos mensajes de error: no basta con decir que hay un error, sino que es lo que ha pasado y que se puede hacer para solucionarlo.
• Preguntar por lo mismo dos veces
• No hay valores por defecto: os valores por defecto sirven para que haya más rapidez en las respuestas, para enseñar mediante el ejemplo y para dirigir a usuarios novatos.
• No explicar cómo funciona la aplicación: en aplicaciones estándar eso no es muy problemático, pero en otras aplicaciones hay que explicar qué se puede conseguir y cómo y no únicamente acceder a la aplicación.
• No indicar qué se hace con la información
• Mostrar características internas: al usuario no le importa y no llegará a entender cosas internas de la aplicación, por lo que no es necesario que el usuario lea.

Top-10 Application-Design Mistakes

Vía / dzone

El post que os pasamos a continuación explican muy bien los pasos que hay que dar para poder permitir que el usuario personalice la web a su gusto:

Existen varios tipos de personalización:

• Recolocar contenido en la página
• Añadir elementos (widgets)
• Modificar preferencias
• Personalizar los estilos (skins)

Eso sí, hay que tener en cuenta algunos aspectos a la hora de permitir personalizar la web:

• Es necesario un botón de reset para volver a la configuración inicial.
• Permitir bloquear la configuración para que el usuario borre o elimine algo accidentalmente.
• Facilidad para desplazar los módulos.

Pero lógicamente existen pros y contras:

Pros

• Personalizar hace que el usuario sienta que un pedazo de web le pertenece.
• Hace la web más interesante, ya que el usuario la dispone a su gusto y quita cosas que le sobren.
• Le da frescura ya que las modificaciones permiten hacer sentir que los contenidos se actualizan con mayor frecuencia.

Contras

• No a todo el mundo le gusta la personalización, a parte requiere tiempo para realizarlo y eso puede hacer que no se haga.
• Lo simple a veces es mejor, aunque claro, el diseño por defecto debe ser suficientemente bueno para que la personalización sea una opción, no una necesidad.
• Requiere complejidad, que no suele ir muy bien con la usabilidad.
• Un usuario puede querer añadir mucha información, perjudicando el rendimiento general.

Customisable websites - the definitive guide

Vía / Digg

Se trata de hacer login en una aplicación mediante una cookie que estará almacenada en el navegador. Esto es lo que se suele hacer cuando queremos recordar al usuario y así que no tenga que logarse cada vez que entra o se pierde la sesión del navegador. Como se trata de una cookie le podemos poner la fecha de caducidad que queramos por lo que el usuario permanecerá logado durante ese tiempo.

Los datos en la cookie no pueden ir en claro, ya que cualquiera podría obtener esos datos si accedieran a nuestro navegador, por lo que hay que encriptarlos.

Supongamos que tenemos una tabla de usuarios que tiene como mínimo 3 datos: alias, contraseña y código. El alias y la contraseña están claro para que se usan y el código lo veremos más adelante. Contraseña y código serán ambos datos encriptados con MD5.

El proceso de login normal (mediante formulario) sería el siguiente: recibimos usuario y contraseña mediante POST y hacemos consulta a la BD para obtener los datos del usuario mediante el alias. Una vez obtenidos los datos del usuario, comprobamos si la contraseña de la BD y la contraseña recibida y encriptada con MD5 son la misma (nunca hay que recuperar los datos igualando el usuario y la contraseña, ya que si no se hace correctamente puede haber problemas de seguridad, por lo que es mejor obtener primero los datos y luego mediante código comparar los datos). Si las contraseñas coinciden daremos acceso a la aplicación, pero antes almacenaremos en el campo código un valor aleatorio y encriptado con MD5 que usaremos después.

Para realizar el login mediante cookies tendremos que guardar en la cookie el alias y la contraseña. Lo único que encriptaremos será la contraseña, el usuario también se podría encriptar, pero obtener los datos del usuario usando el alias encriptado es menos eficiente, tendría que realizar un MD5 por cada registro de la tabla de usuarios. También se podría almacenar en otro campo el alias encriptado, pero serían datos redundantes y tampoco es muy correcto.

La contraseña no se guardaría únicamente encriptada, ya que el MD5 se puede romper mediante fuerza bruta, por lo que lo que almacenaremos será una unión encriptada de una función simple entre la contraseña y el código. El ejemplo más sencillo para la función es la concatenación, por lo que la contraseña almacenada en la cookie quedaría algo así:

md5(contraseña+codigo)

que para ver un ejemplo más claro, si nuestra contraseña fuera 'password', quedaría algo así:

md5( md5('password') + md5( rand() ) )

ya que la contrasñena en la BD se guarda encriptada y el código es un valor aleatorio encriptado.

Supongo que con mucha paciencia también se puede romper este código, pero realmente, si te preocupa que alguien pueda romper un MD5 de una cadena de 64 caracteres (32+32), mejor no hagas el recordar password y usa SSL.

Una vez obtenida la contraseña de la cookie, realizamos la operación con la contraseña obtenida en el consulta a la BD y si coinciden pues damos acceso a la aplicación.

Cada vez que se haga login se renueva el código y actualiza la cookie, y cada vez que se haga logout o se equivoque en el login se actualiza el código y se borra la cookie.

Esta es la forma en que lo haría yo, pero si alguien tiene dudas sobre la eficacia del método, por favor que lo comente.

Mediante un plugin de Aptana y iUi un framework de Javascript y unos estilos CSS que emulan el iPhone, podemos desarrollar aplicaciones, incluso tener simulaciones preliminares en un visor que gira como en iPhone.

Dispondremos un visor para Safari, otro para Firefox y otro para iPhone. Pero hay que tener en cuenta que Apple distingue entre aplicaciones web compatibles con Safari en iPhone, optimizadas para Safari en iPhone y aplicaciones web para iPhone.

El tutorial realizado por la gente de IBM nos lleva paso a paso a desarrollar un ejemplo que luego podremos ver en nuestro iPhone / Ipod Touch.

Develop iPhone Web applications with Eclipse

Vía / AjaxLine