Re: [Spip-es] Interfaz Wysiwyg

From : dani@... , the 2nd September 2003 18:57

Hola German,  hola a tod@s, 
 Ante todo me parece que el hecho que produzcan código HTML  y no "seudocódigo" SPIP es más una ventaja que una   desventaja. 
Entiendo que ese argumento pueda parecer un contra-argumento . Por lo tanto me explico un poco: SPIP hace bien ciertas cosas y no otras.  Y si bien es flexible para pedirle que haga unas cuantas cosas mas que lo que hace bien, hay que hacerlo con cautela, y no es tan facil generalizarlo. Su uso tipico es un eperiodico en linea, o un webzine. Un articulo es ante todo un texto que viene a insertarse en una paginacion del periodico, no es una pagina we con un formato super complejo (tablas, frames, etc.) En este sentido, los atajos tipograficos, más que como 'negrita', 'italica' deberian considerarse conceptualmente:  {citacion}, {{resaltar}}, etc.  Y de hecho, cada uno es el atajo de un estilo, mas que a un tag html (cf. http://spip.net/es_article105.html)  Si bien existe el 'atajo'  ...  que permite ingresar cualquier codigo html, para mantener la coherencia editorial, el uso de este método debe ser la exception y no la regla.  Imaginense que quieran cambiar toda la presesentacion de un sitio, como un periodico ccambia de maquetaje: si en los articulos spip se ingreso codigo html 'a fuego', tipo  ...  es claro que el asunto no pasa la migracion...  Otros ejemplos: si quieren hacer una version del sitio en WAP, iMode u off-line en un PDA, accesible desde cualquier otro tipo de terminal que un navegador habitual, o una version leida para ciegos,...  La referencia a una hoja de estilo .css, simple y limitada, sera una gran ventaja para adaptar rapidamente la conversion.  Despues: que la eleccion de los atajos : {{ }}, {}, [  -> ], etc. no sea estandar y que sea o no la buena eleccion... se discute, por cierto. La experiencia (de usuarios reales y no informaticos) demuestra que los atajos spip se aprenden facilmente, e incluso bastante 'naturalmente'.  Por ultimo, cabe recalcar que no se trata en realidad de una alternativa entre atajos spip 'no estandar' por un lado y html u otro 'estandar' por otro: imaginen construir una nota de pie de pagina en html. bastante más complicado, ¿no? ¿Y qué 'estandar' existe para eso?? Por todo eso es que, si bien no es un estandar sino un sintaxis propio a SPIP, me parece que en un campo de una base SPIP, es mejor ingresar  'seudocodigo' spip (la terminologia no es muy apropiada...) que codigo html.  Y cuando es necesario pasar al html, lo mas sensato hoy en dia me parece crear una pagina interna con un editor estilo Dreamweaver u otro, y luego hacer un copiar/pegar en un campo spip, revisando eventualmente a mano el html para sacar los tags inutiles o perjuiciosos. 
 El problema de los desarrolladores de esqueletos será   saber hacer buenas hojas de estilo.
Eso si: ahi esta la clave de un sitio spip logrado.  fijense spip.net : como Montse lo puteaba con los viejos esqueletos que no estaban adaptados, y como ahora que cambio de esqueletos le parecio mucho mas claro.  Sin embargo, el contenido es el mismo...  Se entiende? 
   Y de ahí se puede entrar en la idea del código sucio. Si   se  hace una interfase sencilla que solo use las pocas   cosas: negrillas, itálicas, tablas, listas y esas cosas...  en otras  palabras sin colores, fuentes y esas cositas...    es decir el  código sucio... 
Bueno, hay editores que hacen codigo {{aun mas sucio}} que eso ;-) Pero, si esa puede ser la idea: un herramienta mas wysiwig, pero que conlleve los elementos de paginacion del sitio.
   Con eso llegamos al tercer problema, la incompatibilidad   con todos los visualizadores, que -me parece- es el   argumento más firme 
Si claramente: si hubiera una manera liviana y universal de hacer tal herramienta, no hay de dudar que Spip la consideraria. 
 no aprobar poner una herramienta de estas en una   distribucón libre de SPIP. 
una reflexion fuera del tema (y que sin duda es una interpretacion abusiva de tu frase, German): {{todas}} las distribuciones de spip son y {{deben ser}} libres. read the f* {GPL}, please ;-) Cada quien hace lo que se le antoja con spip, lo unico que esta prohibido es retirar {{la libertad}} o los autores. (cf. el sitio de los barbudos: http://www.fsf.org/home.es.html y una traduccion al espanhol: http://www.garaitia.com/new/gpl-spanish.php) 
   No creo que sea buena idea que sea que ese tipo de   herramienta pase a ser un componente por omisión del SPIP,   por esa razón. Pero podría ser un componente opcional.
Por un problema de mantenimiento, en SPIP se intentan evitar las opciones (al menos a ese nivel).  En el pasado, esto ha frustrado unas cuantas propuestas (y en particular esta misma). Lo que se hizo al final fue crear el sitio http://rezo.net/spip-contrib/  donde se pueden proponer esqueletos, hacks, etc.  SI quieren podemos armar un sitio de contribuciones en espanhol. o directmanete multilingue.  Bueno, hasta pronto. saludos, daniel