Em nossa última postagem no blog, discutimos como gerar sites completos, com conteúdos totalmente preenchidos a partir de dados produzidos pelo uso diário do seu SaaS. Agora que cobrimos a criação inicial de sites, vamos voltar nossa atenção para a experiência de seus usuários enquanto navegam entre o construtor de sites Duda e a interface do seu App.
A primeira etapa na criação de uma experiência perfeita para seus clientes já é deixar White Label a UI (interface do usuário) e a URL do construtor de sites Duda, como também as URLs provisórias no subdomínio que você constrói.
Antes de discutirmos o processo real de autenticação de seus usuários no construtor de sites Duda, vamos dar uma olhada em como podemos apresentar uma interface de usuário (UI) original enquanto eles editam seus sites. Duda é o construtor de sites que você pode chamar de seu, e um dos grandes motivos para isso são nossos extensos recursos white label. Com as opções de personalização disponíveis, você pode reformular o branding do editor como uma extensão do seu próprio produto. Para começar, faça login em sua conta e selecione “White Label” no menu superior e clique em “Marca personalizada” no menu suspenso.
Ao realizar uma integração entre a Duda e sua plataforma SaaS, os recursos de White Label mais importantes a serem configurados são aqueles que controlam a aparência do editor do site. Embora as opções estejam disponíveis para mudar a marca de outros componentes da Duda, como a tela de login e o painel, é mais provável que esses aspectos sejam totalmente controlados pelo SaaS de origem, em vez da Duda. Abordaremos como podemos pular a tela de login e, em vez disso, pré-autenticar o usuário um pouco mais tarde.
Para personalizar a marca do editor do site, acesse a opção "Editor" na página de White Label. A partir daqui, você poderá fazer upload do seu próprio logotipo e personalizar as cores do texto e dos botões. Para trabalhos avançados de branding, você também pode incluir seu próprio CSS e HTML personalizados.
Uma vez que você tenha a marca da interface rodando, há uma etapa adicional importante: o nome do domínio que seus usuários verão no navegador. Por padrão, a URL do editor do site Duda será algum derivado de um domínio Duda genérico, como por exemplo “x.responsivewebsite.com”. É possível atualizar isso para algo mais atrativo, como “editor.mydomain.com” ou “my.domaineditor.com”, navegando até “White Label” → “Domínio Personalizado” e selecionando a opção “Domínio do Editor”. Lembre-se de que você precisará adicionar uma entrada CNAME no DNS de qualquer domínio que escolher. A informação para esta entrada é fornecida na página de Domínio Personalizado.
Depois que a experiência de edição do site foi adaptada à sua marca, precisamos pensar sobre a experiência de publicação. Colocar um site no ar é o “calcanhar de aquiles” para muitas agências e empresas de SaaS. Nomes de domínio e DNS podem ser um assunto complexo para pessoas não-técnicas. Muitos usuários podem não ter um domínio ou site existente, que já está usando seu domínio. Eles podem até ter registrado um domínio, ou ter sido registrado por um terceiro, mas o site em si nunca foi configurado.
Independentemente do contexto, pode ser um longo processo fazer com que esses usuários atualizem seu DNS, apontando para o site recém-criado. A fim de tornar o processo de publicação o mais simples possível, a Duda permite que qualquer site da sua conta seja publicado instantaneamente em um subdomínio de um domínio de sua escolha. Por exemplo, o cliente “1” pode terminar com uma URL como “client1.sites.mydomain.com” ou “client1.mydomainsites.com”. Configurar o domínio do site fornece uma maneira simples de colocá-lo no ar, sem ter que amarrar o usuário às complexidades da gestão de DNS e domínios.
Quando o site estiver no ar, é o momento perfeito para fornecer algum suporte rápido para ajudar o usuário na transferência, ou registro, de um domínio. A Duda fornece
artigos de suporte 100% white label para ajudar seus usuários durante esse processo. Além disso, os endpoints de API de
criação e
atualização de site permitem que você atualize o domínio, ou subdomínio, de um site diretamente da sua plataforma, orientando seus usuários a partir de sua própria UI (Interface do Usuário).
Com todas essas opções disponíveis, você garantirá aos seus usuários um tempo recorde desde a criação até a publicação de um site.
Com o branding todo configurado, estamos prontos para transferir usuários da sua plataforma SaaS para o editor de sites Duda. Para tornar esse processo simples, precisamos adicionar algumas chamadas adicionais de API ao processo que iniciamos na parte 1 desta série de artigos. Neste post, explicamos como fazer uma chamada para criação do site, e outra para enviar dados da sua plataforma SaaS à biblioteca de conteúdo na Duda. Assim que essas chamadas forem concluídas com sucesso, faremos chamadas adicionais para criar uma conta de usuário Duda e, em seguida, permitir que esse usuário acesse o site.
A chamada API de criação de usuário permite que você passe o identificador de usuário para a Duda, ou seja, que você pode usar o mesmo ID de usuário que usa em seu próprio App. Ao combinar os IDs, ele simplifica chamadas de API futuras que exigem identificação do usuário, como o endpoint SSO (Single sign-on), ou conceder acesso a um site para um usuário. Além disso, você deve especificar o “account_type” de “CUSTOMER” no corpo da solicitação, para distinguir este usuário das contas do seu time. O corpo também pode conter metadata do usuário, como por exemplo os campos “nome” e “e-mail”.
Observação: as chamadas de API requerem Nome de Usuário e Senha para autenticação.
Como você está escolhendo o identificador de usuário na chamada, não o retornaremos após o sucesso. Em vez disso, você receberá um código de status 204 sem dados no corpo da resposta. Também é importante ressaltar que você não especifica ou recebe nenhum tipo de senha para esses usuários. Como veremos mais tarde neste post, esperamos que qualquer usuário criado por meio da API se autentique diretamente do seu aplicativo por meio do endpoint SSO (Single sign-on) da Duda, em vez de navegar para uma página de login.
Neste ponto do processo, já criamos com sucesso um usuário na Duda, mas ele ainda não recebeu nossa permissão para editar um site. A chamada "Grant Site Access” resolverá esse tema. Com ela, podemos especificar não apenas um site ao qual esse usuário deve ter acesso, mas também uma lista de permissões para esse site. Usando estas permissões, podemos adequar uma experiência de edição extremamente simples ou mais avançada, de acordo com a estratégia adotada, nunca deixando de lado a flexibilidade do usuário.
Neste exemplo, estamos dando ao usuário acesso a um site específico usando o “user ID” que escolhemos na etapa anterior e o “nome_do_site” que recebemos de nossa chamada de API de criação de site. Ao passar as permissões para LIMITED_EDITING, PUBLISH e REPUBLISH, o usuário verá um editor muito simples que só permite a alteração do conteúdo existente. Eles não poderão adicionar ou excluir widgets e conteúdos, ou adicionar ou remover páginas adicionais. Uma lista completa de permissões pode ser recuperada do endpoint da API de todas as permissões possíveis. Usando permissões, é possível conceder aos diferentes usuários graus variados de acesso ao mesmo site.
Com as chamadas de API adicionais temos todas as peças de que precisamos para permitir que um usuário edite seu site. A última etapa é utilizar o SSO API endpoint para mover o usuário do seu aplicativo SaaS para o editor White Label.
Na UI (Interface do Usuário) do seu App, precisaremos de um botão 'Editar site' que aparece após a criação de um site, direcionado ao usuário ou organização em questão. Este botão, quando clicado, emitirá a chamada para o endpoint SSO, utilizando o mesmo identificador de usuário que você escolheu na etapa de criação de usuário. A resposta da API incluirá um URL do editor para o qual você pode redirecionar imediatamente o navegador.
É importante que essa chamada seja feita no momento do intento - você não vai querer fazer a chamada para o endpoint SSO no carregamento do aplicativo e armazenar em cache a URL de retorno por um longo período. Os URLs são válidos por no máximo dois minutos por motivos de segurança. É melhor fazer a chamada quando o usuário realmente clicar no botão.
Além do nome do site e ID do usuário, você precisará fornecer um parâmetro de consulta de destino. Isso permite que você crie um link direto para o White Label da Duda em áreas como: templates, página de estatísticas ou o próprio Dashboard. No modelo SaaS, quase sempre você vai desejar enviar o usuário diretamente para o editor do site, portanto, disponibilizamos o valor "EDITOR".
Abaixo, um exemplo de resposta API:
Até o momento, nesta série de posts, vimos como criar sites de forma programática e preenchê-los com conteúdo de uma plataforma SaaS. Também aprendemos como criar usuários com acesso a esses sites recém-criados. Com os recursos White Label da Duda, esses usuários experimentarão o branding do SaaS em questão, sem saber que deixaram o aplicativo de origem.
No post final da série, falaremos sobre a integração de estruturas de dados mais complexas e a criação/remoção automática de páginas inteiras de conteúdo de um site quando um usuário altera os dados na sua plataforma SaaS. Sugerimos que você tente criar alguns usuários por API, ou dentro da plataforma Duda. Altere suas configurações de permissão para restringir o tipo de experiência que funcionaria melhor para seus usuários para consolidar o aprendizado.
Leia também: Integrando a Duda a uma Plataforma SaaS (1 de 3)
