Sentido Web » Desarrollo web http://sentidoweb.com Desarrollo web, HTML, CSS, Javascript, PHP, MySQL Mon, 16 Jan 2012 10:16:20 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Impresiones sobre el desarrollo web en España http://sentidoweb.com/2009/04/30/impresiones-sobre-el-desarrollo-web-en-espana.php http://sentidoweb.com/2009/04/30/impresiones-sobre-el-desarrollo-web-en-espana.php#comments Thu, 30 Apr 2009 19:00:00 +0000 displaynone http://sentidoweb.com/2009/04/30/impresiones-sobre-el-desarrollo-web-en-espana.php Mientras que algunos de los que nos dedicamos al desarrollo web estamos cansados de oír hablar de la web2.0, otros que pertenecen al mismo mundo laboral ni saben qué es, ni les importa. El desarrollo web en España es como un iceberg, lo que se ve es nada comparado con lo que está debajo del agua.

Leyendo blogs sobre desarrollo web, parece que todo el mundo sabe, usa u opina sobre jQuery, frameworks, Ajax, JSON, RIA, estándares, usabilidad o el reciente cloud computing. Pero realmente somos una minoría los que estamos interesados en estos temas. Cada día aparecen proyectos web2.0 de los que se habla durante meses, evangelizadores de lo-que-sea 2.0 nos cansan los oídos sobre qué es lo que se hace o lo que se debe hacer y cuál es el futuro inminente. Pero realmente estos proyectos son un pequeño porcentaje y el adoctrinamiento 2.0 no cala hondo en la realidad laboral española.

Entonces, ¿qué es lo que pasa? Pues sinceramente, no tengo ni idea, ni creo estar capacitado para exponer la realidad de lo que ocurre. Tan solo tengo algunas ideas, pensamientos o suposiciones sobre cuales pueden ser algunos de los motivos que pueden causar la apatía 2.0.

Es un trabajo

Lo que para algunos es un entretenimiento, una pasión o un vicio, para la gran mayoría es sólo un trabajo. Muchos de lo que se dedican a este trabajo lo hacen porque “no había de lo suyo”: muchos químicos, matemáticos, biólogos… trabajan en una profesión que no les gusta, pero que desgraciadamente es de lo único que había trabajo cuando salieron de la universidad. Además hay que sumar el hecho de que los españoles tenemos una actitud negativa ante el trabajo: el que sea una obligación, se pague mal o se explote a la gente, son motivos suficientes para que muchos hagan lo justo en su jornada laboral, y eso implica no esforzarse un poco más en aprender.

Más de lo mismo

Me acuerdo que hace años, cuando cambié de proyecto, los antiguos compañeros me preguntaron qué tal el proyecto nuevo, y mi respuesta fue: “más de lo mismo, navegador → JSP → bean → BD → HTML”.

Si nos ponemos a pensar, casi todos los proyectos web que se realizan son muy parecidos: hacer consulta a la BD y mostrar datos. Esto provoca que la creación de páginas web sea algo muy monótono y mecanizado, donde la novedad suele escasear, por lo que la necesidad de aprender algo nuevo no abunda, ya que con los conocimientos básicos que se tienen, se puede hacer cualquier aplicación.

El copy/paste mató a la 2.0 star

Si al hecho de que la gente no está motivada o a lo de que es más de lo mismo, le añadimos el uso discriminado de copy/paste, nos encontramos con la situación de que la gente lo único que hace la mayor parte de su tiempo es copiar un html/script/css anterior, modificarlo para que te funcione y pasar al siguiente tema, y en muchos casos sin saber exactamente qué es lo que está cambiando.

En Java es muy típico encontrarte a personas que llevan años usándolo y que no se saben de memoria el public static void main(String args[]). ¿Para que sabérselo de memoria si siempre usan un script anterior para crear uno nuevo?. Yo personalmente no me sé de memoria el <!DOCTYPE html PUBLIC … > y no creo que me lo vaya a aprender en la vida (ni ganas que tengo).

Jefes de proyecto o analistas “mayores”

Seamos sinceros, normalmente la gente con más interés por aprender es la gente más joven, pero lógicamente, estas personas suelen ser las que más abajo del escalafón están y sólo se dedican a hacer lo que les mandan. Si quien decide qué se debe hacer, no tiene el conocimiento sobre las novedades que hay en el desarrollo web, ¿cómo se va a propagar el uso de la web2.0?.

Cuando empecé a aprender Ajax, me fue imposible ponerlo en práctica en el proyecto en estaba, los que estaban por encima mía ni sabían qué era, ni se les podía dejar por tontos. Después de mucha lucha conseguí que al menos se hiciera usando iframes ocultos, para ellos era un adelanto, para mí un atraso.

Clientes y otros politiqueos

El cliente tiene la razón, aunque te den ganas de abrirle la cabeza con un libro de O’Reilly. Esto suele llevar a la situación de peticiones imposibles y desarrollos chapuceros.

Una aplicación web no es una aplicación de escritorio, por mucho que le pese al cliente, el cual suele pedir cosas como:

  • que toda la aplicación se vea en la pantalla, que no haya scroll vertical o que haya varias capas (normalmente frames argggg) y cada capa con su propio scroll vertical (e incluso horizontal)
  • que se pretenda que se hagan uploads automáticos de ficheros, sin que el usuario haga nada en el navegador (da igual las veces que les expliques que los navegadores no lo permiten)
  • usar flash o applets porque el navegador no permite hacer algo y el cliente se empeña
  • que sea compatible con los navegadores más antiguos del mundo (alguien lo debe tener instalado y no le apetece actualizarse). Y no me refiero al IE6, sino a versiones como IE5 o Netscape 4.7 (sufrido en mis propias carnes hace no mucho)

Sobre el politiqueo, poco que decir que no conozcamos todos. Decisiones en altas esferas nos obligan a usar productos o programas que poco favor hacen al desarrollo web, y menos aún a los desarrolladores. Estas ordenes suelen estar dadas normalmente por comerciales, que de humo y motos saben mucho, pero que de desarrollo no saben nada. Resumiendo, aquellos que no saben de desarrollo web, obligan a que se haga de tal forma, imposibilitando el camino hacia la web.20.

Negocio, negocio, negocio

Al final todo es negocio y lo que realmente importa es ganar dinero, y cuanto más dinero mejor. Esto suele conllevar varias situaciones:

  • recurrir a menos gente de la necesaria
  • reducir tiempos de entrega
  • contratar gente menos cualificada y más barata, la cual suele necesitar mucha ayuda o revisión
  • reutilizar desarrollos anteriores, aunque tengan poco que ver

Debido a esto, los desarrolladores se encuentran con que tienen poco tiempo para mucho trabajo, y las prisas no son amigas de las florituras, algo de lo que la web2.0 está llena.

Conclusiones

Está claro que todo lo dicho anteriomente no es algo generalizado, existen empresas que realizan desarrollos impresionantes, jefes amantes de la web2.0 y programadores interesados en aprender más cada día. De todas formas, al final lo que importa es que seguimos haciendo las cosas mal, bueno, mal no, pero si deprecated. Y ahora con el tema de la crisis, cuando nuestra mayor ventaja puede ser la calidad de lo que ofrecemos, nos encontramos que hacemos lo mismo que el resto de los países y en algunos casos más caro, por ejemplo la India es mucho más barata y mil veces más eficiente que nosotros.

Que nadie se sienta ofendido, porque no va dirigido a nadie este post. Y si se siente ofendido, que se ponga las pilas.

]]> http://sentidoweb.com/2009/04/30/impresiones-sobre-el-desarrollo-web-en-espana.php/feed 0 Consejos para trabajar con el código de otros http://sentidoweb.com/2008/03/31/consejos-para-trabajar-con-el-codigo-de-otros.php http://sentidoweb.com/2008/03/31/consejos-para-trabajar-con-el-codigo-de-otros.php#comments Mon, 31 Mar 2008 17:30:00 +0000 displaynone http://sentidoweb.com/2008/03/31/consejos-para-trabajar-con-el-codigo-de-otros.php Cuando se trabaja en una empresa de desarrollo de software es muy común que entres en un proyecto que ya está empezado, por lo que deberás tratar con un código que no es el tuyo, y que da igual que sea bueno o malo, deberás adaptarte a él, algo que siempre puede dar algún problema. Más problemático es cuando sustituyes al único encargado del código y el traspaso de conocimientos se realiza en un par de horas (algo muy frecuente en las grandes empresas de consultoría).

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 '&lt;div class="'.$clase[$tipo].'"&gt;...&lt;/div&gt;';
// 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.

]]> http://sentidoweb.com/2008/03/31/consejos-para-trabajar-con-el-codigo-de-otros.php/feed 0 10 errores en el diseño de aplicaciones http://sentidoweb.com/2008/02/20/10-errores-en-el-diseno-de-aplicaciones.php http://sentidoweb.com/2008/02/20/10-errores-en-el-diseno-de-aplicaciones.php#comments Thu, 21 Feb 2008 02:00:00 +0000 displaynone http://sentidoweb.com/2008/02/20/10-errores-en-el-diseno-de-aplicaciones.php Un gran post en el que se nos explica diez errores que se cometen cuando se diseña una aplicación, un resumen sería el siguiente:

  • 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

]]> http://sentidoweb.com/2008/02/20/10-errores-en-el-diseno-de-aplicaciones.php/feed 0 Guía para que el usuario pueda personalizar una web http://sentidoweb.com/2008/02/15/guia-para-que-el-usuario-pueda-personalizar-una-web.php http://sentidoweb.com/2008/02/15/guia-para-que-el-usuario-pueda-personalizar-una-web.php#comments Fri, 15 Feb 2008 23:45:00 +0000 displaynone http://sentidoweb.com/2008/02/15/guia-para-que-el-usuario-pueda-personalizar-una-web.php Para las aplicaciones web es importante darle al usuario la posibilidad de personalizarla a su gusto.

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

]]> http://sentidoweb.com/2008/02/15/guia-para-que-el-usuario-pueda-personalizar-una-web.php/feed 0 Appcelerator: otra forma de realizar aplicaciones web http://sentidoweb.com/2008/01/15/appcelerator-otra-forma-de-realizar-aplicaciones-web.php http://sentidoweb.com/2008/01/15/appcelerator-otra-forma-de-realizar-aplicaciones-web.php#comments Tue, 15 Jan 2008 17:00:00 +0000 displaynone http://sentidoweb.com/2008/01/15/appcelerator-otra-forma-de-realizar-aplicaciones-web.php Appcelerator es una plataforma open source que cambia la forma de realizar aplicaciones web. Está basado en una arquitectura basada en mensajes, lo que quiere decir que toda la plataforma está manejada por mensajes, los cuales son tamaña pequeño. Los elementos HTML pueden enviar o recibir mensajes para cambiar su aspecto o para solicitar datos al Appcelerator Service, el cual es el responsable de gestionar todos los mensajes de la aplicación a/hasta los clientes. appcelerator.png Las aplicaciones usan Ajax y DHTML estándar para realizar las RIA, aunque dicen que sin Javascript, algo que no llego a comprenderles muy bien, porque lógicamente si usa Javascript, quizás se refiera a que el desarrollador no necesita usar Javascript porque se implementa directamente. Appcelerator ofrece una separación clara entre la parte lógica y la de presentación, usando servicios SOA para ello, por lo que es posible crear clientes para Java, PHP, .NET, Ruby y Python. Appcelerator Gracias diarioTHC por el aviso ]]> http://sentidoweb.com/2008/01/15/appcelerator-otra-forma-de-realizar-aplicaciones-web.php/feed 0 Utilidad online para medir la carga de una página http://sentidoweb.com/2008/01/02/utilidad-online-para-medir-la-carga-de-una-pagina.php http://sentidoweb.com/2008/01/02/utilidad-online-para-medir-la-carga-de-una-pagina.php#comments Wed, 02 Jan 2008 19:30:00 +0000 displaynone http://sentidoweb.com/2008/01/02/utilidad-online-para-medir-la-carga-de-una-pagina.php jmeter con las que podemos hacer tests de estrés para saber los tiempos de carga de las páginas, pero en algunas ocasiones algo sencillo es lo mejor y lo más cómodo. El Full Page Test de Pingdom nos ofrece el tiempo de carga del HTML, imágenes, CSS, JavaScripts, RSS, Flash y frames/iframes. A parte nos muestra el momento de inicio de petición, el tiempo hasta el primer bit (TTFB) y el tiempo hasta el último bit (TTLB. Todo esto en una gráfica muy sencilla y aclaratoria. fulltest.png Full page test Vía / OpenSourceCommunity.org ]]> http://sentidoweb.com/2008/01/02/utilidad-online-para-medir-la-carga-de-una-pagina.php/feed 0 Consejos para evitar crear malas aplicaciones web http://sentidoweb.com/2007/03/22/consejos-para-evitar-crear-malas-aplicaciones-web.php http://sentidoweb.com/2007/03/22/consejos-para-evitar-crear-malas-aplicaciones-web.php#comments Thu, 22 Mar 2007 22:30:00 +0000 displaynone http://sentidoweb.com/2007/03/22/consejos-para-evitar-crear-malas-aplicaciones-web.php Una lista con consejos para evitar realizar aplicaciones web que no tengan una buena calidad. Lo malo de las listas es que normalmente se basan en la experiencia del autor, por lo que a veces no se está de acuerdo totalmente con ellas. En este caso yo estoy bastante de acuerdo con la mayoría.

  • Pon los estilos y los javascript en ficheros independientes: complica la lectura, el debug y dificulta que varios desarrolladores modifiquen el mismo archivo.
  • Comprime: comprime la salida para ahorrar ancho de banda. Con esto no estoy del todo de acuerdo, ya lo hemos comentado antes en Sentido Web, hay que pensar que el comprimir la salida en el servidor requiere tiempo de ejecución en la máquina, no me imagino a Technorati, que a veces tarda un poco en darte la respuesta, despilfarrando tiempo de ejecución.
  • Valida: valida según el DOCTYPE que hayas especificado.
  • Cuidado con los mensajes de error: los mensajes de error deben estar enfocados en el usuario, no en el desarrollador para luego saber qué ha fallado. Además, mostrar mensajes de error de la aplicación específicos para los desarrolladores puede proporcionar información sensible a terceras personas.
  • No uses tablas: a parte de ser más fácil de mantener, y más claro de leer, ahorras ancho de banda al escribir menos código debido a la ausencia de TDs y TRs. Luego está, lógicamente, todas las otras razones que todos conocemos para no usar tablas.
  • Desarrolla para todos los navegadores modernos: no te centres solo en IE, existen otros, y aunque se usen menos, cada vez se usan más. Imagínate que una tienda por internet solo funciona para IE, ya que solo el 15% de los usuarios usa Firefox (por ejemplo), es bastante posible que la mayoría de ese 15% no entre en esa tienda online y busque una alternativa. Ese 15% de usuarios de Firefox quizás pueda representar un 15% de ventas.
  • Comprueba los requerimientos: si tu página necesita Javascript, cookies, flash o un plugin, comprueba que el navegador del usuario lo admite, si no es así hazlo saber.
  • Prueba la usabilidad con usuarios reales: a veces algunos sitios son difíciles de usar debido a que quienes lo usan no son quienes lo diseñan.
  • Usa una base de datos real: no uses Access u otro tipo de base de datos de ese estilo, si no puedes pagar Oracle usa MySQL.
  • Que sea multiplataforma: no uses ActiveX o cosas que sean específicas de una plataforma.
  • Piensa en el ancho de banda: no todo el mundo debe tener una línea con un ancho de banda grande, si la página tarda en cargarse es posible que el usuario huya de ella.
  • Ten en cuenta la internacionalización: si desarrollas algo para todo el mundo y solo lo realizas en inglés, es posible que no logres lo que buscas.
  • Testea: esto es lo de siempre, los test es lo más aburrido pero lo más necesario. Que los desarrolladores hagan sus pruebas primarias, pero que los verdaderos tests los hagan personas ajenas al desarrollo.

Ways to Avoid Building Web Applications That Suck

Vía / dzone

]]> http://sentidoweb.com/2007/03/22/consejos-para-evitar-crear-malas-aplicaciones-web.php/feed 0 Consejos para desarrollar Rich Internet Applications http://sentidoweb.com/2007/02/09/consejos-para-desarrollar-rich-internet-applications.php http://sentidoweb.com/2007/02/09/consejos-para-desarrollar-rich-internet-applications.php#comments Fri, 09 Feb 2007 17:30:00 +0000 displaynone http://sentidoweb.com/2007/02/09/consejos-para-desarrollar-rich-internet-applications.php Buenos consejos a tener en cuenta cuando quieras desarrollar un aplicación de internet (Rich Internet Applications):

  • Hazlo interactivo: en vez de ir página a página, hazlo que sea interactivo, edita contenidos, usa drag & drop.
  • Invita a usarlo: pequeños efectos con hover puede conseguir que el usuario se atreva a interactuar.
  • Usa popups ligeros: no se trata de ventanas popups, sino capas que de despliegan. Intenta usarlos cuando puedas para no tener que ir de página en página.
  • Piensa en la interacción como si fuera un storyboard: situa los frames como un storyboard para hacerte una mejor idea de cómo se deben producir las acciones.
  • Indica que acciones se realizan: avisa cuando se haya producido una acción, sin necesidad de dejar la página.
  • Piensa en objetos: en vez de pensar en contenidos y páginas.

Puedes leer más en:

Nine Tips for Designing Rich Internet Applications

Vía / backdraft

]]> http://sentidoweb.com/2007/02/09/consejos-para-desarrollar-rich-internet-applications.php/feed 0 DHTMLSite: aprendiendo mediante ejemplos http://sentidoweb.com/2006/12/13/dhtmlsite-aprendiendo-mediante-ejemplos.php http://sentidoweb.com/2006/12/13/dhtmlsite-aprendiendo-mediante-ejemplos.php#comments Wed, 13 Dec 2006 21:40:00 +0000 displaynone http://sentidoweb.com/2006/12/13/dhtmlsite-aprendiendo-mediante-ejemplos.php Ya son varios los sitios que te muestran artículos sobre desarrollo web, con formato Digg, los cuales son una buena fuente de información para aprender. Si en Sentido Web suelen aparecer entradas que hacen referencia a dzone o a Pixel Groovy, ahora tendremos que estar atentos a DHTMLSite para encontrar el tipo de artículos que nos gusta tanto en Sentido Web. El único fallo que tiene es que aún no ofrecen RSS, pero parece que si lo van a lanzar. DHTMLSite Vía / Webnova ]]> http://sentidoweb.com/2006/12/13/dhtmlsite-aprendiendo-mediante-ejemplos.php/feed 0 24 ways: buenos trucos para tu web http://sentidoweb.com/2006/12/07/24-ways-buenos-trucos-para-tu-web.php http://sentidoweb.com/2006/12/07/24-ways-buenos-trucos-para-tu-web.php#comments Thu, 07 Dec 2006 16:15:00 +0000 displaynone http://sentidoweb.com/2006/12/07/24-ways-buenos-trucos-para-tu-web.php 24ways.png24 ways es un sitio a tener en cuenta a la hora de encontrar trucos y efectos para tu web desarrollados por gurus del desarrollo web.

En especial me han gustado cinco de ellos:

Vía / QuirksBlog

]]> http://sentidoweb.com/2006/12/07/24-ways-buenos-trucos-para-tu-web.php/feed 0