BO2 – Backoffice para todos

João Dias says:

Boa sorte para o vosso projecto.

Tenho, no entanto, que fornecer alguns reparos e conselhos:
1- “Something are wrong”, é uma frase incorrecta. O erro de login deveria ser “Something IS wrong”.

2- Não deveriam mostrar erros pouco descritivos como “Something is wrong”. Invistam um pouco na User Experience e tratem os erros como pontos-chave no sucesso ou insucesso das operações dos vossos utilizadores. Eles não vão saber o que fazer com “Erro. Algo está errado”. Eles vão pensar “Boa, e eu nem fiz nada! E agora, o que faço?”. Nunca deixem o utilizador sem saber o que fazer.

Se é um erro de login, orientem-no. “Erro ao realizar login. Escreveu bem o seu login e password?”. “Desculpe, parece que esses dados estão incorrectos. Por favor, tente de novo”. Algo menos brusco.

3- Nem faz sentido ter notificações a dizer “Your session has been iniciated”. Se eu fiz login numa página, quero ser levado logo para o conteúdo. Quanto muito podem mostrar na própria página de login uma notificação de sucesso. Menos passos para chegar ao que interessa, mais clientes satisfeitos, certo?

4- Aliás, considerem seriamente rever o vosso Inglês nas páginas. Está cheio de erros. Eu sei que se calhar estou a ser picuinhas, mas sendo um projecto open-source, toda a gente pode ter acesso a ele, incluindo pessoas de outros países.

Em termos técnicos:

CSS:
1- Não usem CSS Imports. São muito pouco eficientes e podem causar um atraso de muitos segundos no carregamento de uma página. É péssimo, sobretudo para colocar os estilos como cache no browser. Ah e minifiquem esse CSS, que ele não precisa de estar descomprimido.

2- Não usem ID’s nas vossas folhas de estilo e, sobretudo, ID’s como selectores sobre-qualificados. Não há razão nenhuma para terem coisas como “#login #container #fields div”. Um selector com ID já é mau, com trÊs é pior. A especificidade é demasiada. Considerem optar uma estratégia de CSS modular, como o BEM CSS.

Lembre-se disto: “#login header span” não significa “Id login, com um elemento-filho header e um sub-elemento-filho span”. Significa “todos os elementos span – uma consulta – que pertençam a todos os elementos header – segunda consulta – e que sejam limitados pelo ID login. Se usam três ID’s está o caos instalado para o browser.

3- Considerem seriamente utilizar uma linguagem de pré-processamento, como o SASS ou o LESS. Poupam em erros de desenvolvimento e o código exportado já sai minimizado, se desejarem. E torna-se muito mais fácil manter código em projectos open-source.

4- Malta, estamos em 2014, não há razão para não se ter um formulário de login responsivo. Falta aqui algum cuidado com a estrutura base do Back-Office. Não se esqueçam que mais de metade dos acessos online hoje em dia já são dispositivos móveis. Optimizem a vossa framework para ser responsiva, modular e adaptada a qualquer resolução.

HTML
1- Deixem as div’s de lado e usem elementos semânticos do HTML5. A vossa compatibilidade entre browsers é, neste momento, baixa. Não estão a assegurar que todos os elementos aparecem iguais em todos os browsers (vejam projectos como o CSS Reset ou o Normalize.css) e isso deve ser uma dor de cabeça que devem evitar já.

2- O vosso site não está preparado para ser visualizado em dispositivos móveis. Comecem aqui: http://css-tricks.com/favicon-quiz/

3- Não utilizem inline events de javascript. Não estão a fazer a correcta separação entre forma (HTML), estilo (CSS) e funcionalidade (Javascript). Toda essa componente de interacção deve estar relegada para os vossos scripts. Torna o código MUITO mais limpo e eficiente.

Javascript:
1- Coloquem todo o Javascript no fundo da página e o CSS no head. Apenas o javascript crítico – e raramente há razões para ter tal – deve estar no head da página. Vão poupar em tempo de carregamento.

2- Testem o vosso javascript com o JS Hint e vão ver alguns erros a aparecer e que necessitam de correcção. Ah, e documentem o vosso código. Presumo eu que, uma vez que não é código minificado (e deve estar), é a source. E, como source de um projecto de código aberto, tudo deve estar o mais possível comentado.

3- Concatenem todos os ficheiros de javascript que carregam do vosso servidor. (Dica: o jQuery pode ser carregado de uma CDN, como o CDNJS e aí já poupam mais uns milissegundos no arranque das páginas)

Finalmente, uma dica de usabilidade. Na edição de campos, considerem o inline-editing. Não é muito fácil perceber que tenho que seleccionar, por exemplo, uma página, e depois vir cá abaixo escolher o botão de editar. Essas opções devem estar disponíveis em cada uma das entradas da vossa tabela.

Ferramentas essenciais para usarem:

CSS Lint
Js Hint e JS Lint
Page Speed Insights
GTMetrix
WebPage Test
Modern.ie

Espero que não levem a mal os meus comentários, são com a melhor das intenções 🙂

Carlos says:

Tenho uma questão: estou a desenvolver em Joomla um website e queria colocar uma autenticação inicial (como está demonstrado no vosso vídeo) para posteriormente poderem aceder a esse website.
Quando inicio o website vai logo para a página do index.php e eu queria que esta só fosse acedida depois da autenticação feita. Essa autenticação seria utilizando os utilizadores registados na tabela users do próprio Joomla. Podem dar ideias? É acessível de se fazer?

Obrigado