Nova usabilidade no noosfero

[Vinicius C. Brand]

Olá Terceiro e demais,

    Tivemos uma conversa aqui, eu, Bráulio, e Daniel Tygel, e achamos
interessante a sua proposta de fazer a nova interface via plugin. Só não
nos pareceu necessário interferir nos controllers.

Eu estou fazendo esta parte, a interface responsiva com bootstrap.

    Acreditamos que seria possível refazer a interface via plugin,
redefinindo helpers e views que precisem de ajustes de css ou html, e
realmente seria necessário retirar qualquer geração de html dos models (que
não nos parecem muitos os casos). E também, via plugin, definir os assets a
serem usados (Aliás, não sabemos como redefinir assets: é possível um
"ASSET_PATHS" ou algo do tipo?).

    Você acha que seria possível fazer esta nova interface via plugin sem
mexer os controllers? Tem algum exemplo que comprove isso?

    Já estamos fazendo as propostas de redefinição de helpers, caso a caso,
via monkey patches. Você tinha pensado outra maneira de sobrescrever os
módulos do helper?

    Estamos trabalhando já em rails3 (master).

          Abraços,

                  bráulio, daniel e vinícius


Em 14 de agosto de 2014 17:53, Antonio Terceiro <terceiro at colivre.coop.br>
escreveu:

> 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/
>
>
>
> _______________________________________________
> Noosfero-br mailing list
> Noosfero-br at listas.softwarelivre.org
> http://listas.softwarelivre.org/cgi-bin/mailman/listinfo/noosfero-br
>
>


-- 
Paz, amor e sucesso,
Vinicius

---
Vinicius Cubas Brand
+55 (41) 9920-6369

........__Ô
....._  \ >_
....(_) /  (_)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.softwarelivre.org/pipermail/noosfero-br/attachments/20140814/e570cd2a/attachment.html>