[gnome-hispano] Fw: Redefiniendo el paradigma de bÃsqueda y gestiÃn de informaciÃn en Nautilus

[Domingo Gonzalez <gonav ono com>]

Inicio del mensaje redirigido:

Fecha: Mon, 20 Jul 2009 20:50:15 +0200
Desde: Domingo Gonzalez <gonav ono com>
Para: Ismael Olea <ismael olea org>
Asunto: Re: [gnome-hispano] Redefiniendo el paradigma de bÃsqueda y gestiÃn de informaciÃn en Nautilus


El Mon, 20 Jul 2009 18:53:59 +0200
Ismael Olea <ismael olea org> escribiÃ:

> 2009/7/20 Domingo Gonzalez <gonav ono com>
>
>
> > Debajo de este nombre tan espectacular subyace una idea tonta que se me ha
> > ocurrido a raÃz de intentar reorganizar y actualizar toda la informaciÃn del
> > disco.
>
>
> No hay nada como trajinar gigabytes de porno para pensar en cÃmo hacer mÃs
> eficiente la gestiÃn de la info.

Es que a partir de cierta cantidad de ficheros es inviable trabajar asÃ. 
Y en el curro tampoco... ;)

> - SeparaciÃn entre la estructura organizativa de la informaciÃn y la
> > estructura fÃsica de ficheros.
>
> El concepto que descubres se llama Âarquitectura de informaciÃnÂ. Te sugiero
> encarecidamente que te hagas con el libro del oso blanco asap:
> http://www.amazon.com/Information-Architecture-World-Wide-Web/dp/1565922824
> BÃsicamente de lo que hablas es de separar la Âestructura de informaciÃnÂ
> del Âesquema de la informaciÃn (si no me traiciona la memoria pq tengo aÃn
> embalados todos mis libros).

SÃ, serÃa algo asà como un MVC (disculpen la herejÃa) para los ficheros fÃsicos.
Por eso comentaba la idea del wiki, pues permite reorganizarte tu informaciÃn (que al final son enlaces) como 
mÃs te interese.

> > - Manejo de la informaciÃn como objetos y no como ficheros (por ej. un
> > manual en html multi-pÃgina serÃa un solo objeto)
>
>
> No pienses tanto en el esquema de la informaciÃn. Dale un vistazo al
> concepto de Âactividades de Sugar que Gnome Shell hace suyo. Al final
> llegarÃs a conclusiones semejantes pero por un camino mÃs cercano al uso de
> las apps. En ese mismo sentido creo que a las apps gnome les falta gestionar
> la persistencia de los recursos (creo que es mejor que llamarlos objetos y
> aprovechar el uso de las  URI)

Le darà un vistazo.

> - Posibilidad de asignar y visualizar informaciÃn adicional fÃcilmente a un
> > determinado fichero (objeto), como metadatos.
>
>
> Esa asignaciÃn que dices solamente es solamente ÂanotaciÃnÂ. La anotaciÃn
> puede ser formal (ontologÃas) o informal (folksonomÃas). Ambas
> aproximaciones son vÃlidas y pueden/deben compaginarse. Tracker sirve
> precisamente para gestionar estas cosas.

He estado mirando Tracker y Beagle y van en ese sentido, pero echo a faltar un poco mÃs de integraciÃn y de 
posibilidades (por ejemplo aÃadir categorÃas o favoritos, clasificar o desclasificar un deteminado fichero, o 
tener un panel para bÃsquedas a travÃs de esas categorÃas). Vamos que si estuvieran integradas en Nautilus 
serÃa la caÃa.

> Por otro lado la anotaciÃn y catalogaciÃn puede ser algo automatizable
> extrayendo informaciÃn contextual con cosas como Zeiltgeist para que la
> recuperaciÃn de info sea mÃs sencilla.

Yo creo que extendiendo Nautilus se puede hacer mucho...

> - FÃcil ediciÃn para organizar la estructura de la informaciÃn, pudiendo
> > crear secciones, subsecciones y enlazar tanto con direcciones url de
> > internet como con del tipo file:// de una manera cÃmoda.
>
> olvÃdate de (sub)secciones, piensa mÃs bien en cÃmo flickr maneja las
> etiquetas, que es una gozada

ÂY no podrÃa tener Tracker una GUI tipo flickr, que permita cosas parecidas? 
Vamos, serÃa traer el concepto de web al escritorio.

> ademÃs con una modesta gestiÃn de tesauros puedes hacer mÃs fÃcil la
> gestiÃn; ejem: rojo=colorado=bermejo, etc
>
>
> > - Sistema de bÃsqueda por nombre real y por metadatos.
>
> tracker ;-)
>
>
> > Todo esto se podrÃa integrar en Nautilus de alguna forma. Algunas
> > implementaciones existentes que he estado mirando y que podrÃan aprovecharse
> > en mayor o menor medida son las siguientes:
>
> De alguna forma el nautilus actual deberÃa morir en este cambio. Lo bueno es
> que su cÃdigo serÃa refactorizado como dios manda.

Solamente hay que ver que usamos mÃs el google que el navegador de ficheros. Eso es una seÃal... :)

> - Una plataforma wiki como herramienta mÃs flexible y eficiente para editar
> > la organizaciÃn de la informaciÃn.
>
>
> Wiki es basura. Wiki es estructura en Ãrbol. Lo que debes destruir es el
> concepto de Ãrbol en la gestiÃn de la info personal, que debe ser una
> especie de caos perfectamente organizado en vistas: de nuevo estudiate la
> organizaciÃn de flickr y consulta el libro del oso.

Como formato wiki no me gusta nada, pero el sistema web permite organizar los datos dando mÃs informaciÃn que 
un tÃtulo de categorÃa. 
Por ejemplo puedes escribir una pÃgina con tus trabajos y enlazar a los ficheros y url relacionadas con el 
tema. Esto de momento ni tracker ni beagle lo pueden hacer, hasta que no tengan un interfaz mÃs potente.

> > Definiendo en moinmoin /home/Archivo como directorio de trabajo se podrÃa
> > acceder a todos los ficheros como locales al wiki, por dar una idea.
>
> fuck wiki!
>
> - El enfoque del entorno de trabajo de GnomeShell [3] y su nuevo paradigma
> > de gestiÃn de informaciÃn.
>
> En mi opiniÃn la gestiÃn de la informaciÃn de gnome shell es patÃticamente
> obsoleta.
>
> Lo que tiene de interesante es la nueva pila de software que estÃ
> estabilizando por ejemplo revisando el concepto del Âgestor de ventanasÂ:
> pasa de metacity canibalizando todo el cÃdigo que necesita.
>
> Conste que soy poco amigo de las soluciones no tradicionales,
>
>
> en UI la tradiciÃn es garantÃa de obsolescencia.
>
> Estudia el Sugar. No soy devoto, pero ya es un cambio. Y tal vez sea hora de
> volver a leer a Raskin.

Otro para probar. Ya te cuento.

Muchas gracias. ;)

> ( kill'em'all wikis)