Bitácora de Vuelo

Descripción general

La idea es ofrecer un "espacio de colaboración de corta vida". Algo así como un pastebin dinámico, pero que al mismo tiempo sea fácil de usar. En definitiva, algo útil.

Los kilinks van a poder ser editables, y cada nueva edición será hija del kilink editado (cada "submit" es un commit en un virtual versionado de código). Aclaración importante de terminología: el kilink es uno solo, que tiene distintas versiones; este kilink único tiene siempre la misma URL, el mismo "kilink id".

Habrá tener coloreado de código, como todos los pastebines, pero con dos grandes diferencias: detección y coloreado automático de tipo de texto, y edición coloreada.

La autenticación será lo más sencilla posible para que un visitante pueda decir "soy Fulano" en la menor cantidad de clicks posibles. La idea es ofrecer de esas autenticaciones que son tan automágicas ahora: openid, via twitter, o facebook, etc, o de última un "usuario/clave" por si la persona no tiene ninguno de los otros mecanismos fáciles.

No hay mecanismos de "compartición" de los kilinks: cualquiera puede acceder a cualquier kilink (en general por la URL que se comparte, pero también buscando, ver abajo).

La autoría del kilink y la responsabilidad sobre ese texto es del usuario que lo pegó ahí. Hay que declinar explícitamente responsabilidad. El texto incluido en el mismo es de "dominio público" y puede ser mostrado/usado indiscriminadamente.

¿Por qué usar kilink?

• Se puede usar anonimamente...

• ...pero recuerda quien sos

• Permite compartir un texto en pocos clicks

• Se da cuenta del lenguaje

• Es amigable a nivel de interfaz

• Copia el texto directamente a tu clipboard

• Se puede integrar el texto en donde quieras, por versión o siempre actualizado!

Facilidad de uso / primera impresión

El diseño tiene que ser simple y efectivo, orientado a bajar la barrera de entrada del visitante, el "costo" que el usuario tiene que pagar desde que llega a la página hasta que tiene el kilink en su portapapeles para pegarlo en otro lado. Esto se ve en varios detalles, por ejemplo:

• que el cursor por default esté en el textarea destino

• que el textarea, en lugar de estar 100% vacío, tenga adentro un "pegar acá" o algo similar en gris, suavecito, que desaparezca al pegarle algo.

• que entre el textarea y el botón de submit no haya nada que distraiga

• que el botón de submit se llame "crear kilink" o lo que corresponda

• que pueda llevar la url del kilink creado sin tener que seleccionar un texto

• que se pueda crear un kilink sin registrarse ni loguearse

• botones para copiar automaticamente al clipboard: URL y texto del kilink

• download as file

• botón de imprimir, y CSS especial para que quede linda la impresión

• etc

Visualmente, la página tiene que ser lo menos intrusiva posible, hay que minimizar la "polución visual", pero sin dejar de ofrecer la información necesaria (al hacer hover con el mouse, o en colores que no llamen demasiado la atención).

Otras características:

• una URL o kilink ID que casi funciona como URL corta, ej: kilink.com.ar/4g3jxd

• el contenido del kilink debería ser indexado por google y otros buscadores

Contribución anónima

Se va a poder crear o editar un kilink sin tener que registrarse ni loguearse, pero va a aparecer "Anonymous" como autor (o algo más divertido).

Dicho esto, al usuario le conviene autenticarse, ya que de esta manera puede tener distintas ventajas:

• Es autor de los tuits que cree (figura su nombre, digamos)

• Como es autor, puede borrar sus tuits

• Tiene en su perfil preferencias para adaptar mejor kilink a sus necesidades (habría que ver cuales :p )

Edición, versionado, diffs

Un gran detalle con respecto a la edición es que va a ser "in place". En otras palabras, en lugar de ofrecer un texto estático y un área nueva (como la mayoría de los pastebines), queremos mostrar el texto del kilink, y que el usuario lo pueda editar ahí mismo.

Obviamente, poder editar nos va a generar una estructura de árbol para las versiones. Este árbol será mostrado de forma explícita en la interfaz web, pudiendo el usuario hacer click en cualquiera de los nodos, viendo las distintas versiones del mismo kilink. Al mostrar las distintas versiones como nodos de un árbol se evita confundir al usuario con cosas como versiones "hermanas", "padres" o "hijas". El usuario ve la versión que tiene elegida, y si la edita aparecerá un nuevo nodo hijo del que estaba viendo.

También, se podrá elegir dos versiones, y pedir un "diff" entre las mismas.

Coloreado del texto y tipo del mismo

¿Qué es la autodetección? En lugar del funcionamiento "pastebin clásico" (de pegar un texto y elegir qué tipo de texto es), cuando el usuario pegue el texto se debe autodetectar qué tipo de texto y colorearlo en el momento según el tipo detectado. Obviamente, va a haber un combobox con todos los tipos, que cambia automáticamente al tipo autodetectado, pero que el usuario puede modificar para rectificar una autodetección errónea (obviamente, si el usuario cambia a mano el tipo de texto, el coloreado cambiará correspondientemente).

La "edición coloreada" es la habilidad de poder editar el kilink y que se vaya coloreando mientras se edita (recordemos que vamos a mostrar un sólo texto y el usuario podrá editar directamente allí).

Ambos comportamientos no son fáciles de lograr, pero facilitaría mucho la interacción del usuario, y quizás con herramientas como google-code-prettify no sea tan complicado.

Caducidad de los kilinks

Los kilinks serán permanentes, nunca vencen y siempre estarán online, a menos que el autor del mismo los borre explícitamente. Esta no-caducidad hay que comunicarla explícitamente, pero aclarando que no nos hacemos cargo si un kilink desaparece por problemas ajenos o propios, o por la baja del servicio.

Con respecto a que los usuarios puedan borrar kilinks, sólo será posible si el usuario es el autor del mismo.

Como esta es una acción poco probable (nadie borra un paste, a menos que se de cuenta que metió info muy sensible o demasiado privada), la idea es que sólo se pueda hacer desde la página de perfil del usuario, para no ensuciar la interfaz de uso "normal".

Herramientas

Hay que tener una colección de herramientas, entre ellas:

• plugin para editores (seleccioná el texto → kilink, salta a la pag web con el kilink ya creado)

• plugin para navegador (seleccioná el texto → kilink, idem)

• linea de comando (grep ERROR *.log | kilink y este escupe la url de un kilink nuevo)

• applet que permita meter una "ventanita para rápidamente crear kilinks" en cualquier lado

• applet que permita meter un "visualizador de un kilink particular" en cualquier lado

• applet que permita meter "mis últimos kilinks" en cualquier lado

Tags

Los kilinks tendrán tags asociados, los cuales se crearán de forma semimanual, y servirán como filtros.

Habrá un área cerca del texto donde haya una colección de tags. Al crear un kilink, al momento de pegar el texto, en esa zona aparecerán N tags sugeridos por el sistema (luego de analizar el texto), el usuario puede borrar alguno de esos tags, o agregar más.

Mecanismos para autosugerir tags:

• lenguaje de programación usado (if any)

• bibliotecas específicas usadas en el código

API

Se debe implementar una API HTTP sobre la cual se podrá hacer todo lo que se pueda hacer, al punto que la interfaz web usará esa misma API para trabajar contra el backend.

La API tendrá dos modos: autenticado y público. Para el modo público no se necesita nada en particular, pero no se puede hacer todo desde ahí (por ejemplo, borrar kilinks).

Idea: Debemos revisar las APIs de pastebin, snip y tinypaste, que son las más piolas que vimos, para diseñar de entrada algo que tenga sentido. También hay que ver cómo autenticar.

Idea: Ofrecer en el sitio bindings para distintos lenguajes de programación.