Aplicações iOS param quando as pessoas pressionam o botão Home para abrir um aplicativo diferente ou usam um recurso do dispositivo, como o telefone. Em particular, as pessoas não tocam em um botão para fechar a aplicação ou selecionam Sair em um menu. Para proporcionar uma boa experiência de parada, um aplicativo do iOS deve:
Nunca termine uma aplicação de iOS programadamente, porque as pessoas tendem a interpretar isso como uma falha (crash). No entanto, se as circunstâncias externas impedem que o aplicativo funcione como previsto, você precisa informar seus usuários sobre a situação e explicar o que eles podem fazer sobre isso. Dependendo o quão grave o mau funcionamento das aplicações é, você tem duas escolhas.
Essa parte é óbvia como quase toda a Guideline do iOS, mas eu vejo a Guideline como um checklist que você deve seguir, porque podemos esquecer dos detalhes, e uma boa experiência é feita pelos detalhes.
Dessa forma é importante ressaltar que a comunicação com o usuário deve ser feita a todo momento, quer seja no momento em que ele usa a aplicação ou mesmo quando não está utilizando. As diversas formas de comunicação são o push, notificações que o usuário recebe quando a aplicação aparentemente está fechada. A notificação durante o uso da aplicação, e porque não, a notificação sobre a instabilidade da aplicação. É muito mais importante e significativo avisar o usuário que a aplicação está sofrendo instabilidades do que esperar que ela dê crash e o usuário sinta esse problema perdendo assim confiança na sua app.
Avisar o usuário é fundamental, quer seja o fato de que sua aplicação não irá rodar muito bem uma determinada versão do iOS, o que é comum, ou que está sobrecarregada e poderá fechar a qualquer o momento. Certa vez eu utilizei o Foursquare e apareceu para mim a informação de que a aplicação estava instável, indicando que eu deveria reiniciar a aplicação pois ela poderia fechar a qualquer momento, e claro, como qualquer usuário eu fui até o limite da aplicação até ela fechar na minha frente. A diferença é que como era um crash previsto não me causou uma experiência ruim, pois parece indicar que a aplicação tem o controle da situação, e que não vou um mero crash por erro no desenvolvimento.
Esse tipo de informação pode definir entre a sua aplicação permanecer ou não no device do usuário, pois alguns dos usuários preferem deletar uma app logo no primeiro crash, por achar que a app não é confiável.
Se você fornecer um contrato de licença ao usuário final (EULA ou) com a aplicação do iOS, a App Store o apresenta para que as pessoas possam lê-lo antes de chegar a sua aplicação.
Se possível, evite que os usuários precisem indicar que concordam com o seu EULA quando iniciam o seu pedido. Sem um termo de acordo exibido, os usuários podem desfrutar da sua aplicação sem demora alguma. No entanto, mesmo que esta seja a experiência preferivel do usuário, talvez não seja viável em todos os casos. Se você precisa mostrar um contrato de licença dentro de seu aplicativo, faça isso de uma forma que se harmonize com a interface do usuário e faça o menos inconveniente possível.
Se possível, fornecer um aviso na sua descrição do aplicativo ou EULA. Os usuários podem então ver o aviso na App Store, e você pode equilibrar os requisitos de negócios com necessidades de experiência do usuário.
Para o iPad: aumente a interatividade (Não apenas adicione funcionalidades ‘features’ )
As melhores aplicações iPad dão as pessoas formas inovadoras de interagir com o conteúdo enquanto eles realizarm uma tarefa claramente definida e finita.
Resista à tentação de adicionar funcionalidades que não estão diretamente relacionadas com a tarefa principal. Em vez disso, explore formas que permitam que as pessoas vejam mais e interajam mais. Em particular, você não deve ver a tela grande do iPad como um convite para trazer de volta todas as funcionalidades que você poderia ter podado de seu aplicativo para o iPhone.
Para fazer que seu aplicativo iPad destaque-se, concentre-se nas formas de ampliar a experiência do usuário, sem diluir a principal tarefa com características estranhas.Por exemplo:
Associe estreitamente as transições visuais com o conteúdo que está mudando. Em vez de trocar com uma tela totalmente nova quando algumas informações incorporadas mudam, tente atualizar apenas as áreas de interface do usuário que necessitem dela. Como regra geral, a transição da visão individual e objetos, e não na tela. Na maioria dos casos, lançar a tela inteira não é recomendado.
Quando você executa menos transições de tela cheia, sua aplicação Ipad tem maior estabilidade visual, o que ajuda as pessoas a manter o controle de onde elas estão na sua tarefa. Você pode utilizar elementos da interface do usuário, tais como exibição de divisão e pop-over para diminuir a necessidade de transições em tela cheia (também transições totais da tela).
Acredito que o melhor exemplo do uso de transições coerentes, features inteligentes, seja sem dúvida o Flipboard, aplicação que revolucionou o conceito de navegação no iPad, sendo referencia para diversas outras apps atuais.
Inclusive sempre que quero mostrar as capacidades do iPad a algum usuário curioso eu acabo mostrando a app Flipboard, devido aos recursos que ela utiliza de forma eficaz e muito, muito agradável.
O Flipboard utiliza o recurso de flip de páginas de uma que a Guideline não previa, alias, não previa mas não impedia. Isso é o que deve ser observado, a Guide tem por objetivo auxiliar para que as aplicações mantenham uma coerência de usabilidade. Porém aplicações que superam as expectativas com o Flipboard, viram referência para as demais aplicações que vão surgindo. A idéia é tirar o melhor dos recursos oferecidos pelo iOS.