Foros del web, para los que viven de bits

Estoy haciendo un sitio basado en feeds RSS. Las noticias las estoy clasificando por sitios, colocándolas en cajas. Esas cajas tienen la característica de que son arrastrables (Ajax), a fin de que el usuario pueda darle un primer lugar a los sitios que más le interesan.

Éste es el problema: Mi sitio se conecta a varios servidores automáticamente, ésto también lo hace mediante una función Ajax. Cuando cada sitio carga va mostrando la noticia independientemente sin recargar la web. Hasta ahí todo bien, pero el asunto es que algunos servidores externos se ponen muy lentos y tardan mucho en devolver los resultados, por lo cual el tiempo de carga total se hace eterno.

La web luce estupenda con todas sus noticias desplegadas, pero está ese inconveniente del tiempo. Ésta como tal se carga rápidamente y muestra las cajas vacías. Inmediatamente todas cargan un gif animado tipo preload y se van llenando poco a poco. Pero demasiado "poco a poco"

No termino de decidir cómo sería más cómodo para el usuario: O esa modalidad, o que la web cargue sin noticias y que el mismo usuario haga clic en las cajas que le interesa cargar ¿Qué se les ocurre para solucionar esto, cómo sería más usable esa web?.

De verdad llevo como 2 semanas en su desarrollo y he volteado todo de las mil maneras, buscando una forma idónea de intuitividad y facilidad de uso. Nada de lo que he hecho me ha convencido lo suficiente como para terminar el trabajo por esa vía.

Pienso que quizás podrías pedir el 'feed' (¿qué palabra podemos usar en español en vez de feed?) cada cierto tiempo, y guardar una copia en el servidor. Entonces podrías mostrar una lista inicial de elementos y luego hacer que el programa AJAX compruebe la existencia de elementos nuevos.
Te agregaría quizás bastante tráfico, pero creo que es la única manera de mostrar algo de contenido mientras la actualización se carga.

Si lo pensás así, podrías hacer que se actualice cada 5 minutos la copia de tu servidor, y que el javascript solamente se conecte a tu servidor para obtener todos los elementos nuevos, cosa que, ventaja extra, podría hacerse con una petición sola

Por otra parte, quizás también quepa algo de optimización del código javascript, o en vez de hacer una descarga paralela de cada origen RSS, hacerla secuencial (para que no haya que estar repartiendo el ancho de banda entre muchos sitios) aunque esto último no sé qué tan ventajoso podría ser.

Sugerencias hay muchas, pero que sean implementables o prácticas es diferente

Si, a mi antes de leer lo del cuate alvlin también se me ocurria que es mejor cachearlo, y de pronto no se si genera tanto trafico o hasta menos ya que estas leyendo local, dependiendo de como lo manejes.

Queda fashion eso de actualizarse solo pero los servidores externos siempre nos matan :(

Sí, ese es el único problema. la lentitud. De momento estoy considerando la idea de diseñar unas cajas atractivas visualmente que inciten al usuario a hacer clic, las cuales contengan algunos links de info estática. Hasta quizás sea posible agregarlo como una característica más de personalización.

Naaah estoy perdido con esto.

Yo never daria clic :( sorry

Hola:

Opino lo mismo que alvlin y elquique, lo mejor sería guardar una copia de los elementos en el servidor (de la mejor manera que se te ocurra) e ir periódicamente comprobando si hay elementos nuevos para actualizar tu copia (tendrás que estudiar esos periodos, y si los realiza el cliente o el servidor).

Esa me parece una opción viable. La desventaja es que estarás poco sincronizado con tus feeds, nunca será a tiempo real aunque compruebes cada 5 minutos, pero espero que eso sea de poca importancia.



Saludos.

PD: Por cierto ahora que se me ocurre, ¿Qué pasa en tu sitio con javascript desactivado?

Los noscripts siempre los trabajo de último ;), aún no me ocupo pero los enlaces son todos html. Seguro sale algo bueno por esa parte.

"Avances" =P

Hola

Bueno, no es que esté yo muy puesto en el tema, más bien lo contrario, así que me disculpan si las ideas que propongo son un poco descabelladas o fuera de lugar.

Desde el punto de vista de la usabilidad, sería importante que le indiques al usuario que la página se refrescará con nuevo contenido cada cierto tiempo, 5, 10, 20 minutos, lo que haga falta. Pero más importante aun, es que le des la oportunidad de evitar que eso pase, a fin de cuentas, no sabemos cuanto tarda en leer lo que le has presentado.

Si tienes un sistema en el servidor que busque información periódicamente, por ejemplo usando cron y un php/perl/etc, puedes colocar una zona en la página avisando al usuario de la existencia de nuevo contenido, así, si lo decide, puede recargar la página o activar tu mecanismo de refresco de información.

Para hacer el chequeo de la nueva información, tiene varias alternativas, puedes asumir que cada 5 minutos habrá algo nuevo y no hacer chequeos, puedes usar el last-modified de la página (cabecera http), puedes usar el etag (cabecera http). Las ventajas de usar las cabeceras, es que es muy poco tráfico, el problema es que no se si puedes leerlas con lo que estás haciendo.

Luego podrías combinar mecánicas como el uso de PUT o curl para forzar el envío del archivo nuevo al cliente, pero serían un pelo más complicados ya que implican "falsear" el contenido del cache. Puede ser un poco complejo.

Así que como te indican, la opción de que el trabajo se realice en el servidor, es lo más eficiente, yo trataría de usar los métodos relacionados con las cabeceras para reducir el tráfico.

También grabaría la información nueva en archivos nuevos (nuevos nombres) y separados por áreas, de manera que cuando haya actualización de alguno, pueda usarse aunque otras áreas no tengan actualizaciones.

Se que puede sonar a perder dinamismo, pero es mejor perder 5 minutos de sincronización, que no usar el servicio porque es aburrido.

También creo que es importante la desincronización entre el script de cliente y el de servidor, al menos en 30 segundos, así te aseguras de que uno haya terminado de trabajar cuando el otro va a empezar.

Otra alternativa para el usuario es que coloques algún tipo de indicador visual que le permita saber que hay noticias nuevas, por ejemplo algo tipo semáforo, con códigos de color, así es fácil de entender y reaccionar, aparte que te ahorras tener que poner textos en cada caja (o cerca) diciendo que hay nuevas cosas.

Ahora mismo no se me ocurre mucho más.

Con suerte en otro momento puede que hasta algo útil se me ocurra.

;)

Felicidad

Éste es un proyecto al cual le he puesto mucho trabajo, tiempo y -ya en su culminación- me encuentro con este endemoniado obstáculo que no había previsto: el tiempo de carga.

La cosa es peor: el sitio está destinado a ser página de inicio de los usuarios. Si no resuelvo el problema de cómo hacerlo más intuitivo tendré que engavetarlo y olvidarme de él por un buen tiempo.

He pensado contratar un par de programadores (php y Js) para que optimicen lo mejor posible el código completo. Quizás con esa acción la cosa se haga un poco más ligera.

Pero eso no es todo, se pone aún peor : En realidad el asunto no es un RSS común. Mi sitio recupera literalmente y en tiempo real la información de otros servidores por medio de lenguaje dinámico. Para nada toco sus recursos RSS. Eso es lo que lo hace valioso a la apreciación de los usuarios.

El esquema que me he trazado es éste:

- Ya acepté que el tiempo de carga es largo. Eso no lo puedo solucionar porque se me escapa de las manos. La página en sí no es pesada. Al usuario sólo se le carga 30 y tantos Kb. El servidor tampoco es problema. No obstante, da igual si extraigo 1 o 20 artículos por sitio. La lentitud la ocasiona el escaneo que mi aplicación le da a toda la web. Luego identifica y aísla la sección de donde va a sacar la info, devolviéndola a los usuarios en forma limpia (texto puro con los estilos y presentación que les asigno).

- Si bien no es buen momento para desechar ideas, lamentablemente debo descartar la presencia de una caché, a menos que ésta tenga una utilidad secundaria que resulte provechosa. El "gancho" o atractivo del proyecto es precisamente la obtención de la información exactamente al mismo tiempo que los sitios externos la publican.

- Por lo tanto lo que debo desarrollar es una estrategia de usabilidad de tal nivel que -aún con ese problema- el usuario encuentre el sitio tan útil que se sienta animado a colocarlo como su página de inicio.

Por otra parte éstos son los recursos de usabilidad con los cuales cuento (los que están directamente relacionados con este asunto):

- La página como tal puede cargarse de inmediato y mostrar la información estática que desee en cada uno de las cajas.

- La información dinámica es independiente de una caja a otra. No es necesario que la página se recargue completa.

- Las cajas son arrastrables y su ubicación se guarda en una cookie para que el navegador recuerde cómo el usuario las configuró.

- Cada uno de los elementos gráficos son fácilmente identificables. Igualmente el concepto y diseñó de la interfaz global está sujeto a esta premisa.

Ése es el rompecabezas que tengo hasta el momento (o al menos gran parte). Una vez resuelto el problema viene el siguiente paso, que es añadirle un Drupal como aplicación central que gestionará todo lo que sea contenido interno.

Metacortex, primero te quiero felicitar, estás en una etapa de tu trabajo que yo espero alcanzar en un tiempo.

Y aunque no soy tan experto como muchos de mis amigos del foro se me ocurre poner de "gancho" esas aplicaciones pequeñas que hacen la vida del usuario mas facil, aunque muy obvias y aunque ya miles de sitios las ofrecen, pero se me ocurre una mezcla de calendario - agenda, donde puedan almacenar sus citas y demás, y aprovechando que implementas Ajax, algo así como unas "Notas adhesivas" para guardar apuntes diarios.

Por ese lado vería yo muy atractiva una página de inicio además del contenido que se actualiza.

Saludos y muchisima suerte, espero que algun dia puedas compartir las experiencias que tuviste al desarrollar ese trabajo, por lo menos algunas.

Edito: Imagino que este tipo de aplicaciones no aumentan significativamente la carga de la página ya que estarían en tu servidor y no en uno externo, es por eso que hago la recomendación.

Bueno no me des todo el crédito jeje. El motor de las funciones lo conforman unas clases PHP previamente fabricadas que puedes adaptar fácilmente a los proyectos web. Esas librerías se llaman Snoopy y puedes bajarlas libremente de aquí.

En cuanto a tu sugerencia, queda anotada con el conjunto.

Eso me gustó. Verde cuando ya ha cargado, amarillo cuando está en proceso y rojo por si hay alguna falla de servidor . Al no solucionar la lentitud tengo que meterle mano a buenas ideas como ésta.

Sin embargo, el objetivo es lograr que 1) el usuario se quede, 2) haga clic en las noticias y le agrade el proceso de carga, 3) que encuentre la ventaja de examinar en un solo sitio lo que le tomaría más tiempo en visitar cada uno de los otros.

Por cierto, todos los enlaces llevan directo a la fuente original. El sitio no almacena ninguna información externa, sólo expone lo más actual.

Ya te veré pegado al monitor


En serio, gracias a todos por sus ideas y su tiempo

Hola

Otra cosa que se me había pasado antes.

Los vínculos deberían abrirse en una nueva ventana para que no abandonen la tuya. Eso suena muy razonable desde varios puntos de vista, sin embargo, si lo haces, deberías advertir al usuario que eso pasará.

Personalmente suelo usar un sistema de detección de eventos a fin de no incluir onclicks ni nada similar en los vínculos, de esta manera, si js está activado, se abre una nueva ventana y si no, el vínculo carga en la misma ventana, pero supongo que en este caso, estando fuertemente basado en javascript, da igual la mecánica y bastará con que le adviertas en alguna parte, por ejemplo, una sección de "sobre nosotros", "ayuda" o algo similar en la que expliques como funcionan las cosas o que esperar.

Otra ventaja importante es que al no salir de tu página, si no abrirse una nueva ventana, no se ve afectado lo que ya había antes, evitando así empeorar cualquier lentitud que haya.

Felicidad

Sí, el target _blank es fijo . No puse los enlaces como onclick sino <a href="javascript:talcosa..." >, teniendo la libertad de añadirle las propiedades que se requieran.

De antemano te digo que veo muy cuesta arriba el asunto de la accesibilidad. Por ahora la cosa es una maraña informe presta a salir de una etapa crítica de confusión. No obstante el "cómo" está construido el sitio tiene sus puntos buenos para pensar en una opción accesible:

- La info extraida no depende del javascript. En realidad llega a archivos php independientes a los que se le puede hacer un include o enlazar.

- Aunque la carga de javascript es mucha, me ocupé especialmente la totalidad de su código (excepto lo que te mencioné de los enlaces) permaneciera dentro de las etiquetas <script>. La estructura html está limpia.

Aún no he tocado de lleno el tema de la accesibilidad, pero ahorita se me ocurre que quizás el <frameset> (que no es accesible ) pueda solucionar el problema de las cargas independientes con Js desactivado.

Si pones un frameset bombardeare tu sitio :P jaja

Lo que pasa es que si descarto el frameset tendré que enfrentar la tenebrosa realidad de la recarga completa de página (con cada caja). Por eso digo, ya me estoy haciendo la idea de que -de una forma u otra- no será un sitio ejemplarmente accesible. Y con el target=_blank queda rebajado automáticamente a transicional... Al menos no uso tablas

jaja imagino estas usando Frontpage no ??

Y para evitar la recarga completa que tal un AJAX?

Jejeje sin querer me diste una idea con ese comentario.

El Ajax está. Hablábamos de implementar el frameset en caso de javascript desactivado

El atributo TARGET vuelve con HTML 5, así que podés usarlo sin culpa ;)