Uma proposta de atualização para o Safari do iPhone
Home › Tecnologia › Uma proposta de atualização para o Safari do iPhone
8 de março de 2013 @ 18:36
8 de março de 2013 @ 19:24
O Safari é tecnicamente uma plataforma própria, separada da App Store. Até o dia que o Gatekeeper chegar ao iOS, ele vai ser a forma mais aberta dos usuários acessarem informações nos dispositivos móveis da Apple. Mas apesar das abas do iCloud e Lista de Leitura, o Safari Mobile permanece praticamente sem mudanças desde que foi apresentado em 2007.
Eu queria conceitualizar o que o Safari poderia ser no iOS se passasse pelos mesmos desenvolvimentos que ocorreram com outros navegadores nos últimos anos, e ajustar a experiência de usuário para atingir às mudanças que ocorreram em outras partes da plataforma.
O browser do seu iPhone permanece praticamente do mesmo jeito há mais de cinco anos. A Apple modificou e refinou o navegador – que sempre foi sólido – mas às vezes ele parece velho. O designer Brent Caswell tem uma bela visão para o futuro do Safari.
Unificando as barras de endereço e busca
Hoje em dia, todos os navegadores modernos tem uma barra de endereços e busca unificadas (incluindo o Safari no Mac). O que a Apple chama de "Campo de Busca Inteligente" também foi expandido para além das buscas típicas e vai trás do seu histórico, buscas anteriores e às vezes o conteúdo das páginas que você visitou. Unificar os dois campos tem o potencial para melhorar a experiência de navegação; você pode acidentalmente apertar a barra errada. Eu lembro quando comecei a usar a barra unificada no Google Chrome, a experiência parecia infinitamente mais simples.
Um dos obstáculos para a unificação é o teclado que aparece quando o usuário toca em um dos dois campos. O teclado de busca é bem típico, enquanto o de endereços foi desenvolvido para digitar URLs. Eu tive que juntar as individualidades deles para unificá-los. Mas, no fim, acho que seria vantajoso para o usuário médio.
Você vai notar que a barra de baixo está na parte de cima do teclado, o que pode parecer estranho em um primeiro momento. O que ela faz, no entanto, é permitir ao usuário imediatamente começar a digitar em uma página nova com a mesma facilidade que ele tem para acessar os favoritos. Assim, ele evita toques desnecessários.
Adicionei ícones aos resultados para ajudar a entender cada uma das opções. Se você começar a rolar a lista, o teclado vai para baixo e sai do caminho, como acontece em quase todos os apps.
Atualmente, quando você clica no botão de favoritos, você encontra uma série de bookmarks, pastas e pseudopastas para Lista de Leitura, Abas do iCloud e Histórico. Por mais que faça sentido para a Lista de Leitura e Histórico aparecerem nesta parte do app, a Aba do iCloud deveria aparecer abaixo da hierarquia das Páginas. Pessoalmente, não acho que as pseudopastas fazem sentido, então eu criei abas na parte inferior da tela. Os designers da versão do iPad parecem concordar comigo.
Então nós vamos entrar em partes profundas de Interface de Usuário. No iPhone, há a necessidade de um botão "Pronto" já que os Favoritos preenchem a tela inteira; no iPad você precisa tocar em qualquer parte da tela para descartar um pop-up, e quando você está na parte de dentro de uma pasta e aperta "Editar", o botão de voltar é substituído por um "Nova Pasta" (o que eu acho que é menos elegante).
No final, o botão de voltar no topo da tela foi o que eu precisei eliminar completamente. Mas para conseguir fazer isso eu tive que mudar completamente a forma como as pastas parecem. Peguei algumas lições das pastas na home screen (que não possuem botão de voltar).
Na minha versão do Safari, as pastas estão atrás da lista. Quando a pasta na lista é tocada, a lista é quebrada na metade e desliza para revelar o conteúdo da pasta. Tocar no título da pasta por uma segunda vez faz ela fechar.
Como em outros apps, a busca fica escondida abaixo da barra de título, e você teria que puxar a lista para baixo para encontrá-la. Estou mostrando aqui porque isso não existe no app atualmente.
Edição de bookmarks pode ser feita com muito mais eficiência ao usar o sistema de edição que existe no app de Mail. Isso, combinado com opções de bookmars aparecendo quando o usuário desliza em um favorito (como no Twitter), cria uma experiência de edição muito mais robusta.
Após alguns meses usando o Compartilhamento de Fotos do iOS 6, eu achei decepcionante que a Apple não espalhe o amor do iCloud para outros apps. De verdade, todo app nativo do iOS devia ter melhor integração com o iCloud além de simples sincronização.Teríamos notas colaborativas, você poderia enviar lembretes, ou pastas de favoritos públicas assim como você tem álbuns de fotos públicos. Então mesmo que Compartilhamento de Favoritos não seja o melhor nome possível, acho que é uma ideia que poderia ser explorada.
Diferentemente das fotos, o Compartilhamento de Favoritos seria colaborativo; mais do que uma pessoa poderia contribuir com o conteúdo das pastas. O usuário poderia também escolher por simplesmente compartilhar o conteúdo dela. Para o sistema funcionar, os participantes precisam ser divididos em duas categorias: "colaboradores" e "assinantes".poderia enviar lembretes, ou pastas de favoritos públicas assim como você tem álbuns de fotos públicos. Então mesmo que Compartilhamento de Favoritos não seja o melhor nome possível, acho que é uma ideia que poderia ser explorada.
Colaboradores podem ver e editar o conteúdo, enquanto os assinantes só conseguem ver. Se não for público, o colaborador pode convidar pessoas para colaborar. Se for público, qualquer pessoa com o link poderia assinar, mas precisaria ser convidado para poder colaborar.
Como mais de uma pessoa colabora, os favoritos não podem ser deletados a não ser que todos os colaboradores abandonem-o. Se você quer ter uma ideia do que seria editar um negócio desses, clique aqui.
A Lista de Leitura não sofre muita mudança. Eu mexi na interface para economizar espaço, e adicionei a habilidade de editar em lotes. Quando estiver no modo de edição, um botão "+" aparece no lugar do "Pronto", o que permite que o usuário adicione um item à lista.
A visão das páginas mudou um pouco. Em vez de simplesmente mostrar uma página por vez, o usuário pode ver quatro. Como disse antes, as Abas do iCloud foram movidas da seção de bookmarks para a visão das páginas.
Conectando apps ao conteúdo da web
No iOS, um app pode dizer ao sistema operacional que ele tem a habilidade de abrir certos tipos de arquivos, e um app pode ter suporte para abrir esses arquivos em outros apps. Mas e o conteúdo da web no Safari? Acho que apps poderiam conseguir acessar conteúdo na web através da ficha de ação do Safari. Eis alguns tipos de conteúdo que apps poderiam abrir:
Links (seja um link em uma página ou uma página própria
Argitos (usando a habilidade do Safari de pegar artigos da web
Páginas (código da página da web)
Links de assinatura de Podcasts
Como no caso atual, a ficha de ação aparece ao pressionar o botão ação (para agir na página inteira) ou pressionar por alguns segundos o conteúdo que você quer tomar ação (par acionar algo na página). Acima um exemplo do que poderia acontecer quando uma imagem é pressionada por muito tempo.
Claro que a lista é limitada pelos tipos de apps que você pode instalar no seu dispositivo. Se você tem o Photoshop Touch instalado, então pode abrir arquivos .psd.
Mas apps deveriam poder fazer mais do que simplesmente abrir os arquivos, deveria existir a possibilidade dos apps realizarem diferentes ações para conteúdos. Então você poderia twittar um link ou enviar via DM através do Twitter. Duas ações, um app.
O usuário teria controle total das ações que apareceriam nessa ficha de ação, nas configurações do Safari. Elas poderiam ser redistribuídas segurando um dos ícones até ele se mexer, do mesmo jeito que é feito na homescreen.
Claro, esse tipo de ação seria ótimo de ter no sistema inteiro, mas como estou falando apenas do conceito para o Safari, vou deixar isso aqui.
Um dos novos desenvolvimentos na tecnologia da web são as notificações da web. Muitos browsers modernos têm suporte a elas, e eu acho que o Safari poderia ter também. Controlar quais sites poderiam mandar essas notificações apareceria nas configurações de notificações assim como acontece com e-mail. Então cada site poderia ter seu próprio alerta e som, e o usuário poderia escolher se receberia a notificação na lock screen ou no ícone do Safari.
Quando você receber uma notificação e abrir o Safari, um pequeno banner com o texto da notificação apareceria no topo do app. Você poderia descartá-lo ao clicar no "x" ou abrir a página ao pressioná-lo.
O Reader no Safari é basicamente uma versão simplificada do iBooks. Mas porque ele precisa ser simplificado? Acho que pessoas podem gastar meia hora lendo um longo artigo na em uma tarde chuvosa de domingo da mesma forma como podem ler um livro no iBook. O Reader no Safari deveria ter suporte para compartilhar citações, paginação, temas designados pelo usuário, fontes definidas pelo usuário, leitura sem distração e controle de brilho independente.
O Safari é apenas um dos muitos apps nativos da Apple que eu acho que precisam de uma atualização. E por mais que a atualização que eu estou sugerindo não seja perfeita, acho que ajudaria a manter o iOS na direção certa.
Alguns dos recursos que eu proponho poderiam estar em todas as versões do Safari. Eu quis me limitar à versão do iPhone para que o projeto não ficasse grande demais. Posso falar do iPad e do Mac em outro dia.
Brent Caswell é um designer e estudante de ciência política na Universidade do Alabama – Birmingham. Você pode ler mais sobre os pensamentos dele sobre design, UX e tecnologia em geral aqui.
AppledesigniosiPhoneSafari
Artigo anterior Atenção: pré-venda do dual chip Xperia E começa na sexta!
Próximo artigo Digitizer Desktop 3D, da MakerBot, é como um replicador de <i>Star Trek</i> na vida real