Novo Layout Do Registro.br

[Andre Juliano]

Direto do tunel do tempo:

 

Ano 2000

 

https://web.archive.org/web/20000301124159/http://registro.br/

 

Ano 2001

 

https://web.archive.org/web/20020721130747/http://www.registro.br/

 

Ano 2005

 

https://web.archive.org/web/20050701014048/http://www.registro.br/

 

Ano 2011

 

https://web.archive.org/web/20110713161244/http://registro.br/

 

 

Tambem so lembro do de 2005. :)

[timonense]

Bem, particularmente, eu preferia a de 2011, mas assumimos que da mesma forma que a tecnologia, o registro.br deve evoluir, e não poderia permanecer por muito tempo com o mesmo layout. Mas, a questão da usabilidade peca um pouco principalmente pela retirada do link Whois que, deliberadamente, foi tomado a parte pelo todo, e quando é necessário fazer uma consulta é necessário buscar em Tecnologia -> Ferramentas -> Serviço de diretório whois -> digitar o endereço procurado. Só ai são 3 cliques antes de efetuar a busca, soma-se a isso o fato de ter efetuado a busca de um dominio anteriormente e não ter encontrado o link Whois (até os captchas que não funcionavam pelo menos de vez em quando permitiam; agora nem isso). Não sei qual seria o problema em efetuar buscas Whois, se a busca não é spam e é uma busca legítima, qual seria o problema em um usuário por simples curiosidade buscar as informações do site? não é público? acredita-se que a infraestrutura por trás do sistema seja adequada para suportar demandas do tipo (vale lembrar que estamos falando da instituição que controla os registros de domínios de um país inteiro).

Outro exemplo: os submenus do menu principal, possuem tamanho da fonte maior que os tópicos do menu principal, não ficou bom, chega a incomodar a quem está olhando, tudo bem que um site deve possuir dispositivos de acessibilidade, mas ampliar o tamanho de uma fonte deve ser tarefa opcional ao usuário que está utilizando o sistema, e só o fato dos tamanhos serem diferentes já dão a impressão que o sistema possui algum problema de apresentação. Os manus até ficaram bons, mas a diferença de tamanho deixou com aspecto de haver algum problema, e seguindo essa mesma tendência, após fazer uma pesquisa de domínio, a frase "disponível para registro" ou "não está disponível para registro" além do registro pesquisado possuem fontes descomunalmente desproporcionais. Estão muito grande, parece que o sistema está gritando para o usuário, por estas e outras, preferia o sitio antigo. era mais visualmente proporcional, mas, se fosse melhorado a proporcionalidade dos elementos visuais, ficaria muito bom.

[rubensk]

Sobre o WHOIS, ele não é um caso de uso que justifique otimização cruzada com a pesquisa de domínios para novos registros. Quem quer consultar diretamente o WHOIS basta favoritar a página. A busca da página inicial é para os usuários buscando disponibilidade ou não do domínio.

Sobre a parte visual, parte do motivo dos seus questionamentos é que há uma busca constante por tornar as opções do contexto aberto mais visíveis que as outras... isso é feito com uma combinação de cores, tamanhos e negrito. Eu vou discutir seus pontos com a especialista de UX que orientou a criação do site para ver se a dose passou do ponto de "falar alto" para "gritar", mas falar alto é o que queríamos mesmo.

[Renato Frota]

Que bom saber que tem alguém da registro.br participando ativamente por aqui. Eu acompanho o portaldohost desde sempre (não lembro se já tive usuário, acabei criando este ontem) e, dias atrás, quando vi o layout novo registro.br "reclamei muito no twitter" (na verdade foi no facebook). kkkk

Olha, eu concordo com a observação que fizeram sobre o tamanho das fontes. Inclusive, não é só no retorno de consultas, não. Mesmo na home, sem clicar em nada, sem executar nenhuma ação, já acho que o layout tem umas proporções não muito amigáveis. Tem muito paddings nas boxes, as fontes são muito diferentes em cada seção...

 

Eu recomendaria:

1- em vez de tanto padding e um texto quebrado em duas linhas no box "Pesquise e registre o domínio desejado", ele poderia estar numa linha só (reduzindo o height dessa box)

2- o input onde se digita o nome do domínio poderia ser menor (até mesmo para caber melhor o texto do item 1)

3- o placeholder "Digite o nome do site" está errado (não tem outra palavra, desculpe, está errado, mesmo). O campo é para pesquisar domínios, e não sites pelo nome.

4- nas áreas Eventos, Segurança e Conexão Internet, a fonte dos textos que vem logo a seguir, são bem ruins de ler (classe .strong, com font-weight 600). Eu deixaria os mesmos 300 dos blocos de cima, e aumentaria o font-size para algo entre 16 e 20px.

5- no topo, Criar Conta e Acessar Conta não sequem um padrão. Um é um link com text-decoration underline, o outro é um botão com ícone+texto...

6- o menu superior, como já foi observado, possui subitens maiore que o próprio menu. se a intenção é prover maior acessibilidade, eles deveriam ter maior espaçamento vertical então, ficou muito junto para uma fonte desse tamanho. melhor ainda se tivessem uma separação visual (uma borda ou qualquer divisão entre os itens).

7- pensando na usabilidade (nem tanto por mim, eu já acostumei, estou pensando justamente nos leigos que vão registrar direto na registro.br, por economia em relação a registrar com os provedores ou pela sensação de segurança de poder alterar o domínio sem vínculo os provedores), creio que o link "informar servidores DNS" deveria estar mais destacado (melhor ainda, se o campo de DNS já viesse aberto).

 

Agora perguntas sobre as mudanças de política:

 

1- Por que limitar a troca de nameserver enquanto o domínio ainda não está pago? O que a registro.br ganhou com isso?

2- Se quando eu defino um nameserver externo, eu posso alterar os registros livremente, por que as entradas de DNS não podem ser alteradas quando opto pelos servidores de DNS gratuitos da registro.br? Já que é pra limitar, eu até acho que possa existir uma razão óbvia (apesar de eu não estar enxergando) para impedir a troca de nameserver, mas travar o domínio nos DNS da registro.br e não permitir a configuração da zona já me parece restritivo demais.

 

São meus 2 centavos.

No mais, parabéns ao registro.br pelo envolvimento com a comunidade, por estarem abertos a ouvir nossas opiniões (e também pelo módulo WHMCS, que parece ter iniciativa da entidade - ou de um funcionário dela - e não de um programador independente).

[rubensk]

 

7- pensando na usabilidade (nem tanto por mim, eu já acostumei, estou pensando justamente nos leigos que vão registrar direto na registro.br, por economia em relação a registrar com os provedores ou pela sensação de segurança de poder alterar o domínio sem vínculo os provedores), creio que o link "informar servidores DNS" deveria estar mais destacado (melhor ainda, se o campo de DNS já viesse aberto).

 

Agora perguntas sobre as mudanças de política:

 

1- Por que limitar a troca de nameserver enquanto o domínio ainda não está pago? O que a registro.br ganhou com isso?

2- Se quando eu defino um nameserver externo, eu posso alterar os registros livremente, por que as entradas de DNS não podem ser alteradas quando opto pelos servidores de DNS gratuitos da registro.br? Já que é pra limitar, eu até acho que possa existir uma razão óbvia (apesar de eu não estar enxergando) para impedir a troca de nameserver, mas travar o domínio nos DNS da registro.br e não permitir a configuração da zona já me parece restritivo demais.

 

São meus 2 centavos.

No mais, parabéns ao registro.br pelo envolvimento com a comunidade, por estarem abertos a ouvir nossas opiniões (e também pelo módulo WHMCS, que parece ter iniciativa da entidade - ou de um funcionário dela - e não de um programador independente).

 

UX 1-6 - Juntei com o comentário anterior para conversar com nossa especialista de UX. 

UX 7 - Informar os servidores DNS na contratação era um ponto de atrito do processo. Acontecia de alguém tentar registrar um domínio, especificar servidores DNS de um host e depois acabar não fechando com esse host. Aí o ticket fica morto por 15 dias até expirar, então o usuário precisa se candidatar nesse tempo ainda como concorrente dele mesmo, e só depois disso ele consegue o domínio. Assim, quem sabe o que está fazendo tem a opção de informar DNS, mas o default é o caminho que dará maior certeza da obtenção do domínio. 

Pol 1 e 2 - Há dois motivos para isso: um, que foi inclusive comentado aqui nesta thread, é o de gente que sentava em cima do domínio(incluindo phishing); o outro é que alguns clientes, de boa fé, não percebiam que ainda precisavam pagar, pois já estava funcionando. Quando depois de 15 dias o domínio era congelado, o cliente armava um barraco. Com essas mudanças de política, e algumas mudanças na interface e nos e-mails de registro, fica bem claro de que o serviço será prestado tendo um pagamento como contra-partida, e evita-se que algo que esteja em produção seja tirado do ar.

 

Você comentou ser restritivo demais, mas eu gostaria de saber que prestadores nesse mercado prestam serviços antes de pagamento, caso não sejam serviços gratuitos... 

 

O módulo WHMCS foi iniciativa da organização mesmo. Ele acabou sendo implementado por mim e por outro funcionário porque não conseguimos achar alguém para fazer o módulo, o que era o plano original. O que está faltando é gente contribuir com o código, que é aberto... 

[Renato Frota]

UX 1-6 - Juntei com o comentário anterior para conversar com nossa especialista de UX. 

UX 7 - Informar os servidores DNS na contratação era um ponto de atrito do processo. Acontecia de alguém tentar registrar um domínio, especificar servidores DNS de um host e depois acabar não fechando com esse host. Aí o ticket fica morto por 15 dias até expirar, então o usuário precisa se candidatar nesse tempo ainda como concorrente dele mesmo, e só depois disso ele consegue o domínio. Assim, quem sabe o que está fazendo tem a opção de informar DNS, mas o default é o caminho que dará maior certeza da obtenção do domínio. 

Pol 1 e 2 - Há dois motivos para isso: um, que foi inclusive comentado aqui nesta thread, é o de gente que sentava em cima do domínio(incluindo phishing); o outro é que alguns clientes, de boa fé, não percebiam que ainda precisavam pagar, pois já estava funcionando. Quando depois de 15 dias o domínio era congelado, o cliente armava um barraco. Com essas mudanças de política, e algumas mudanças na interface e nos e-mails de registro, fica bem claro de que o serviço será prestado tendo um pagamento como contra-partida, e evita-se que algo que esteja em produção seja tirado do ar.

 

Você comentou ser restritivo demais, mas eu gostaria de saber que prestadores nesse mercado prestam serviços antes de pagamento, caso não sejam serviços gratuitos... 

 

O módulo WHMCS foi iniciativa da organização mesmo. Ele acabou sendo implementado por mim e por outro funcionário porque não conseguimos achar alguém para fazer o módulo, o que era o plano original. O que está faltando é gente contribuir com o código, que é aberto... 

 

UX 7 - Acho que o ideal seria o meio termo: não deixar os campos de nameserver diretamente expostos, mas apenas aquele bloco cinza (Avançado), só para evitar que passe batido na hora do registro, já que, deixando sem nameserver, a pessoa não pode voltar e trocar até que o pagamento esteja confirmado. Não lembro exatamente o que está escrito naquele bloco, mas uma explicação curta a respeito da necessidade da conta de hospedagem já estar ativa para que o domínio funcione (e o problema da espera de 15 dias que será gerado caso ele informe nameservers incorretos) tal qual você explicou, acho que seria o ideal.

 

E agora, me surgiu uma dúvida: o registro.br não exige que os nameservers respondam autoritativamente pelo domínio antes de permitir o registro (converter o ticket em registro)? Por que não antecipam esta exigência para a criação do próprio ticket? Assim não vai ter esse problema de ticket pendurado.

 

A resposta para as perguntas 1 e 2 não me convenceram. Quem é mal intencionado continua podendo registrar o domínio e utilizá-lo antes do pagamento, do mesmo jeito? Quem vai sofrer a "punição" da mudança de política é justamente o usuário final, leigo, que não está acostumado com o processo e, pior ainda, que se estiver lendo algum do tutoriais disponíveis pela internet afora a respeito do registro do domínio, se verá "preso" na troca do nameserver sem querer (nem todo mundo vai ler aquela mensagem ali, as reclamações continuarão).

 

E não vi nada a respeito da minha sugestão de ter os servidores da registro.br como slaves, com clonagem da zona master gratuitamente (que gera menos custos para a registro.br e mais flexibilidade para quem trabalha com servidores de IP único).

[rubensk]

UX 7 - Acho que o ideal seria o meio termo: não deixar os campos de nameserver diretamente expostos, mas apenas aquele bloco cinza (Avançado), só para evitar que passe batido na hora do registro, já que, deixando sem nameserver, a pessoa não pode voltar e trocar até que o pagamento esteja confirmado. Não lembro exatamente o que está escrito naquele bloco, mas uma explicação curta a respeito da necessidade da conta de hospedagem já estar ativa para que o domínio funcione (e o problema da espera de 15 dias que será gerado caso ele informe nameservers incorretos) tal qual você explicou, acho que seria o ideal.

 

E agora, me surgiu uma dúvida: o registro.br não exige que os nameservers respondam autoritativamente pelo domínio antes de permitir o registro (converter o ticket em registro)? Por que não antecipam esta exigência para a criação do próprio ticket? Assim não vai ter esse problema de ticket pendurado.

 

A resposta para as perguntas 1 e 2 não me convenceram. Quem é mal intencionado continua podendo registrar o domínio e utilizá-lo antes do pagamento, do mesmo jeito? Quem vai sofrer a "punição" da mudança de política é justamente o usuário final, leigo, que não está acostumado com o processo e, pior ainda, que se estiver lendo algum do tutoriais disponíveis pela internet afora a respeito do registro do domínio, se verá "preso" na troca do nameserver sem querer (nem todo mundo vai ler aquela mensagem ali, as reclamações continuarão).

 

E não vi nada a respeito da minha sugestão de ter os servidores da registro.br como slaves, com clonagem da zona master gratuitamente (que gera menos custos para a registro.br e mais flexibilidade para quem trabalha com servidores de IP único).

 

Como você mesmo citou, temos uma mensagem avisando de que só será possível mudar DNS após o pagamento... sobre os tutoriais disponíveis na Internet, quem os fez precisará atualizar o conteúdo se quiser que ele continue relevante. Nós também, por sinal... estamos trabalhando nisso, inclusive. Nós não temos como deixar de implementar mudanças só porque há conteúdos desatualizados disponíveis na rede. 

 

Exigir DNS que não o do Registro.br já respondendo previamente seria obrigar o cliente a já contratar um plano de hospedagem antes de registrar o domínio. Fora o atrito maior no processo, isso gera alguns problemas: 

- E se mais de um cliente estiver interessado no mesmo domínio usando o mesmo host, como o host vai saber se quem efetivamente contratou os serviços é quem registrou ? Exemplo: fulano 1 solta um comentário em rede social dizendo que domínio "xxx.com.br" seria legal. Em seguido, fulano 2 vê isso e contrata um host... fulano 1 testa os DNS dos hosts conhecidos e quando um responde, ele vai lá e registra o domínio usando a configuração de DNS que fulano 2 pediu. 

 

Sobre as políticas, note que quem as fez acompanha o dia-a-dia de registros e de casos de suporte... se não te convenceu, talvez você possa considerar a possibilidade de que as coisas sejam diferentes de como você as imagina. 

 

A questão de DNS foi em outro tópico, está respondida lá. 

[Renato Frota]

Como você mesmo citou, temos uma mensagem avisando de que só será possível mudar DNS após o pagamento... sobre os tutoriais disponíveis na Internet, quem os fez precisará atualizar o conteúdo se quiser que ele continue relevante. Nós também, por sinal... estamos trabalhando nisso, inclusive. Nós não temos como deixar de implementar mudanças só porque há conteúdos desatualizados disponíveis na rede. 

 

Exigir DNS que não o do Registro.br já respondendo previamente seria obrigar o cliente a já contratar um plano de hospedagem antes de registrar o domínio. Fora o atrito maior no processo, isso gera alguns problemas: 

- E se mais de um cliente estiver interessado no mesmo domínio usando o mesmo host, como o host vai saber se quem efetivamente contratou os serviços é quem registrou ? Exemplo: fulano 1 solta um comentário em rede social dizendo que domínio "xxx.com.br" seria legal. Em seguido, fulano 2 vê isso e contrata um host... fulano 1 testa os DNS dos hosts conhecidos e quando um responde, ele vai lá e registra o domínio usando a configuração de DNS que fulano 2 pediu. 

 

Sobre as políticas, note que quem as fez acompanha o dia-a-dia de registros e de casos de suporte... se não te convenceu, talvez você possa considerar a possibilidade de que as coisas sejam diferentes de como você as imagina. 

 

A questão de DNS foi em outro tópico, está respondida lá. 

 

Aí é culpa de quem comprou o host e não comprou o domínio, oras. O registro.br não poderia ser responsabilizado por uma situação como essa. Hospedagem é hospedagem, registro é registro.

 

E se condicionar a existência da conta de hospedagem para criar o ticket seria um "problema", por que não é um problema condicionar a existência da conta para o registro efetivo?

Quanto à questão de DNS, desculpe e equívoco, vou lá ler :)

[rubensk]

Aí é culpa de quem comprou o host e não comprou o domínio, oras. O registro.br não poderia ser responsabilizado por uma situação como essa. Hospedagem é hospedagem, registro é registro.

 

E se condicionar a existência da conta de hospedagem para criar o ticket seria um "problema", por que não é um problema condicionar a existência da conta para o registro efetivo?

 

 

 

Responsabilidade no ponto de vista jurídico de fato não tem, mas o usuário leigo vai fazer barulho igual. 

 

A partir do momento que é criado um ticket, aquele cliente tem prioridade no registro do domínio durante o prazo de expiração da pendência de DNS. Assim, ele já garantiu o nome, desde que satisfaça as pendências a tempo. Um segundo ticket concorrendo pelo domínio pode ser criado, mas mesmo que esse segundo esteja sem pendências, ele aguarda o primeiro e só vai ganhar o primeiro expirar. 

[Renato Frota]

Beleza, compreendo o posicionamento da registro.br. Sei que ninguém trabalha de graça.

 

Acho uma pena que seja assim, pois ter o domínio funcionando dentro do prazo de 15 dias para pagamento e a liberdade de poder configurá-lo enquanto o pagamento é confirmado era um recurso muito bom e, 1 domínio a mais ou 1 a menos com edições liberadas na plataforma, não fazia a menor diferença (no bolso da registro.br). Mas se a proposta é barrar phishing, acho que deveria ter cortado em definitivo (só funcionar o domínio depois de confirmado o pagamento). Do jeito que está, virou uma barreira que só existe no caminho dos bem intencionados: os mau intencionados, vão continuar registrando, com a conta previamente registrada e terão o domínio funcionando por 15 dias (e mais um período, após solicitar a extensão de pagamento)...