Nova usabilidade no noosfero

Antonio Terceiro terceiro at colivre.coop.br
Thu Aug 14 17:53:04 BRT 2014


On Thu, Aug 14, 2014 at 04:44:04PM -0300, Bráulio Bhavamitra wrote:
> Oi Aurium,
> 
> Estamos nessa linha! A idéia é migrar para o bootstrap mas não perder de
> vista que no futuro podem surgir interfaces baseadas em outros frameworks.
> Alguns pontos de implementação que pensamos e Vinão (em cópia)
> implementando:
> 
>    - Um tema base-bootstrap que é o equivalente bootstrap do base
>    - Um layout (se necessário) para o bootstrap
>    - Um helper JQueryUiHelper com os atuais métodos que usam o jqueryui e
>    um novo BootstrapHelper com os equivalentes em bootstrap
>    - Ambos os helpers acima implementariam um conjunto de métodos (talvez
>    definidos num UiBaseHelper) para criar "hotspots" de interface. Exemplo de
>    um método: box_classes, define quais as classes usadas num box. No caso do
>    bootstrap, retorna 'col-lg-3 col-md-4', que é a modulação de colunas para
>    cada tamanho de tela. O core chama esses métodos sem saber qual o backend
>    por trás!
> 
> Que acha? Vinão deve evoluir esses conceitos a medida que implementa.

Eu acho que essa estratégia não vai funcionar; simplesmente criar um
novo layout e um novo tema não vai resolver, porque o HTML gerado em
várias partes do "backend" não vai ser adequado para o novo layout, de
forma que vai ser _muito difícil_ evoluir isso sem quebrar os temas
atuais.

Um outro aspecto a levar em consideração é que os controllers também
estão bastante intrincados à concepção (ruim) da interface atual, de
forma que muitas mudanças neles também seriam necessárias, e de novo o
esforço pra não quebrar compatibilidade com o passado vai ser imenso.

Por outro lado, a nossa camada de models, apesar de não ser perfeita, na
minha opinião é muito boa, e manter compatibilidade nessa camada é muito
mais fácil do que nas camadas "acima", Pra isso a gente vai precisar
remover a geração de HTML dessa camada, o que de qualquer forma é uma
coisa que a gente deveria ter feito desde o início.

Na minha opinião a melhor forma de fazer isso seria um plugin que tem o
seu próprio layout, os seus próprios controllers, views, helpers e
assets; dessa forma a gente poderia projetar uma interface completamente
nova e descolada do passado. Usando bootstrap, principalmente, que na
minha opinião ganhou a corrida dos frameworks de interface assim como
git ganhou a do controle de versão. A gente também poderia usar tudo de
com que tem no rails 3/4, como asset pipeline, turbolinks e tudo mais.

Enquanto essa nova interface não estiver boa o suficiente, e enquanto
todas as organizações envolvidas no noosfero se adaptam à nova
interface, basta não habilitar o plugin que o Noosfero vai usar a
interface antiga, que apesar de ruim, vai continuar funcionando e não
vai quebrar os vários temas que estão na rua.

Eu já vinha experimentando com um branch pra viabilizar isso
tecnicamente, que é dar a possibilidade de plugins redefinirem rotas
arbitrárias:

https://gitlab.com/terceiro/noosfero/commits/plugin-improvements
em especial:
https://gitlab.com/terceiro/noosfero/commit/5d1c05dd30001134013ef7024771218e365a47ab

Quando acharmos que a nova UI está pronta, a gente pode simplesmente
transformar esse plugin num plugin "base" (i.e. um plugin que está
habilitado por padrão), e novas instalações vão usar a nova UI por
default. A gente dá um tempo com a interface antiga como obsoleta, e
depois de um tempo decreta o fim do suporte a ela e remove ela do core.

A partir daí, a gente teria 2 opções: mover o código do plugin da nova
interface para o core, ou manter o conceito de que interfaces são
plugins, de forma que você pode ter várias UI's alternativas como
cidadãs de primeira classe. Isso seria útil pra ter interfaces
alternaticas muito enxutas para dispositivos móveis e/ou com baixíssima
largura de banda por exemplo.

-- 
Antonio Terceiro <terceiro at colivre.coop.br>
Colivre - Cooperativa de Tecnologias Livres
http://www.colivre.coop.br/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listas.softwarelivre.org/pipermail/noosfero-br/attachments/20140814/29dfafb9/attachment.pgp>


More information about the Noosfero-br mailing list