Guia de Experiência de? Usuário A experiência do usuário iOS gira em torno da interação simplificada com o conteúdo que é importante as pessoas. As diretrizes deste capítulo aplicam-se aos aplicativos que são executados em todos os dispositivos iOS. Importante entender que a Apple é bem direta quando se trata de UX, ela trata os assuntos…
Recentemente tenho postado sobre a Guideline do iOS, é conhecido o fato de que a Apple se preocupa bastante com a parte psicológica da Experiência do Usuário. Interessante é ver que depois do grande sucesso conseguido pela mesma através do iOS (iPhone e iPad), muitos dos seus concorrentes começaram a dar mais importância ao…
Uma grande interface de? usuário? segue? os princípios? de design? de interface? humana que? se baseiam na? forma como as pessoas / usuários pensam e? trabalham, e não? sobre? as capacidades? do? dispositivo.? Uma? interface? de usuário que? é? desinteressante, complicada,? ou? ilógica? pode? até mesmo fazer? uma grande aplicação? parecer? um enorme fardo? de se usar.? Mas? uma? interface, bela, intuitiva e? atraente para o usuário aumenta a? funcionalidade? de um aplicativo e? inspira um? apego? emocional positivo nos usuários. Importante ressaltar na forma como a Apple tem pensado…
Não é uma tarefa fácil traduzir e comentar uma Guideline, mas o desafio está sendo interessante, vou apontar sempre que possível a minha visão sobre a Guideline, minha tradução não é 100% porque procuro humanizar algumas coisas que a Apple deixa, vamos dizer… repetitivo demais. Intencionalmente é claro, pois visão enraizar os conceitos na cabeça…
Um post r?pido para compartilhar algo que pode ser ?til a mais algu?m…
Recentemente fiz o upgrade do meu Macbook Pro do Mac OS X Snow Leopard para o Lion, depois de todas as atualiza??es de software, no uso do dia a dia notei que o Lion estava absurdamente lento, Google Chrome, Mozilla Firefox, o Eclipse (esse estava de chorar e desanimador de t?o lento que estava)
Lendo os blogs, achei 2 dicas que resolveram o problema:
1 – Verificar e reparar as permiss?es de acesso ao HD
Caminho: Finder > Applications > Utilities > Disk Utility
Selecionar o drive que representa o Mac, depois clicar no bot?o: Verify Disk Permissions, esperar finalizar e depois no bot?o: Repair DIsk Permissions
Link do post com as dicas: Speed up Mac OS X Lion
Desde post tamb?m revisei as configura??es do Spotlight.
2 – Limpar os caches
Abrir o Finder > Menu: Go > Go Folder | ou executar o atalho: Shift + Command + G
Digite: ~/Library/Caches
Apague o conte?do deste diret?rio
Caso n?o tenha total seguran?a se deve apagar todos os arquivos e diret?rios, fa?a um backup, copiando o conte?do da pasta para outro diret?rio. Obs.: esse passo n?o ? necess?rio, mas caso queria alguma garantia de o que fazer se algo der errado ter? as c?pias.
Aten??o: alguns diret?rios e arquivos n?o ser?o exclu?dos pois est?o em execu??o, por exemplo, cache referente ao Finder e a alguns outros aplicativos do Mac OS X.
Reinicie seu Mac.
Link do post com a dica: OSX Lion – Clear your caches!
Feito estes procedimentos, os aplicativos e o Mac OS X Lion passou a ter uma performance e resposta aceit?vel, assim como tinha no Mac OS X Snow Leopard.
Hoje existem diversas plataformas no mundo mobile e cada uma com uma linguagem específica, dessa forma, existe um custo elevado para portar uma mesma aplicação para todas as plataformas, esse custo elevado no desenvolvimento de projetos acaba criando uma barreira muito grande para que pequenas empresas possam usufruir desse ambiente que cresce exponencialmente a cada [...]
Eis que na semana passa foi uma loucura a quantidade de posts e pessoas falando da nova vers?o do Tweetdeck “nativa”, para Windows e Mac OS que substituiu a vers?o anterior em Adobe AIR. Os Appletards (man?acos, tarados pela Apple) foram ao del?rio, mas…
MacMagazine : Agora o Tweetdeck ? nativo
Tecnoblog: Twitter chuta Adobe AIR para escanteio
Os coment?rios dos tards comemorando o fato s?o hil?rios, perdemos funcionalidades e recursos e eles comemoram por agora a aplica??o ser “nativa”
A minha opini?o:
A perda de funcionalidades foi not?ria…
Perda de funcionalidades = retrocesso
Perdemos: encurtador de links, atualiza??o em real-time dos tuites, o upload de fotos n?o funcionou em nenhuma das minhas frustradas tentativas de uso, ao ficar um periodo sem conectividade a internet o novo aplicativo n?o consegue mais recuperar os tuites. Essas foram os problemas que encontrei nessa nova vers?o.
Vi muita gente elogiando pelo simples fato de (creio eu n?o gostarem d) o Adobe AIR n?o ser a base desde cliente…
Analisando tecnicamente e tecnologicamente o ocorrido:
Temos aqui nada mais que o cliente web: https://web.tweetdeck.com/ empacotada como uma webapp instal?vel no Mac.
Ao analisar o conte?do do pacote TweetDeck (a aplica??o) no Mac, temos /Content/Resources/htdocs todo o c?digo html+js+css da aplica??o a qual pelo que observei a web vem a ser a mesma.
Ainda n?o identifiquei qual solu??o de webapp foi utilizada para gerar o instal?vel, mas tenho a respectiva suspeita em ordem:
1 – Appcelerator Titanium
2 – Mozilla Prims
3 – o Twitter desenvolveu sua propria solu??o de empacotamente da webapp
Caso voc?, assim como eu instalou a nova vers?o e desinstalou a antiga, crendo que a nova manteria as funcionalidades da antiga e se arrependeu, ainda tem como voltar para a vers?o antiga e deixar de usar esse lixo da nova vers?o…
Encontrei:
- um post de outra pessoa que como eu n?o gostou da nova vers?o
Como todos devem ter percebido, nos últimos meses o CSS3 e o HTML5 tem ganho um grande destaque no desenvolvimento web. Grandes empresas como o Google, Microsoft, Adobe e Apple estão apoiando fortemente o desenvolvimento web utilizando WebStandards. Caso você já conheça algo sobre CSS, provavelmente deve saber como é complicado a organização desses documentos em um projeto de médio ou grande porte. Dado esses problemas conhecidos, foram surgindo os chamados pré-processadores de CSS, que viabilizam a criação de documentos de estilo, adicionando novas funcionalidades.
Hoje vamos conhecer o LESS, The Dynamic Stylesheet Language. O objetivo dessa biblioteca em javascript é prover uma série de funcionalidades para as, usualmente criadas a mão, folhas de estilos. Recursos tais como, variáveis, mixins (Multiple Inheritance, Traits), mixins parametrizáveis, funções, namespaces, importação, etc. Vamos aprender como utilizar os principais recursos dessa biblioteca em um projeto e como aproveitar o melhor dessa biblioteca para organizar corretamente nossas folhas de estilo.
As variáveis ajudam-nos a definir valores que podem ser utilizados em diversas regras do nosso CSS. Elas possuem escopo assim como em uma linguagem de programação orientada a objetos, trocando em miúdos:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
// Arquivo stylesheet.less
// Essa variável foi definida no escopo do arquivo, logo, todas as regras do arquivo podem acessar seu valor. @siteBackgroundColor: #FF3300; // Laranja h1 // Isto significa que, se criarmos uma outra regra chamada &.mainTitle h2 |
O que é interessante no uso de variáveis é a reutilização e organização. Imagine uma design guideline onde existem RGBs específicos a serem seguidos, essas cores poderiam ser definidas em um documento chamado color_variables.less e adicionados ao nosso arquivo principal utilizando a clausula @import.
Quando um arquivo LESS é importado, todas as suas variáveis e mixins são adicionados ao arquivo principal. Os escopos serão mantidos e a extensão .less é opcional.
@import “lib.less”
@import “lib”
É possível utilizar pastas nas clausulas de @import:
@import “where/is/my/stylesheet.less”
@import “where/is/my/stylesheet”
No LESS, mixis são como uma espécie de classe CSS que pode ser reutilizada em diversas outras regras. Quando utilizadas, todas as propriedades definidas no mixin são adicionadas a regra onde a mesma foi adicionada, caso um mixin mude, todas as regras que o referenciam serão também modificadas.
Imagine o conceito de mixin como classes CSS orientadas a objeto, o que é interessante do mixin é que temos aqui algo como uma herança múltipla, caso uma mesma instrução seja declarada em mixins diferentes, e esses mixins adicionados a uma regra, o mixin declarado por último terá vantagem na construção final do CSS da regra onde foi adicionado.
|
1
2 3 4 5 6 7 8 9 10 11 12 |
.bordered
border-top: dotted 1px black; border-bottom: solid 2px black; // Declaramos agora uma regra qualquer que fará uso do nosso mixin. |
Quando modificarmos o mixin .bordered, todos os elementos que o estão utilizando serão modificados. Reutilização!
Vamos para um exemplo mais usável para exemplificar como é um mixin parametrizável.
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
// Bordas arredondadas cross-browser.
// Observe que utilizamos algo parecido com uma função de javascript para declararmos nosso mixin. // A notação de variável deve ser adicionada (@radius), com isso, criamos uma variável chamada “radius” no escopo // do mixin que poderá ser utilizada apenas internamente pelo método. // Observe também que declaramos um valor padrão para o parâmetro, de 5px. .border-radius( @radius: 5px ) // Repare que utilizamos a mesma variável para todas as regras. border-radius: @radius; -moz-border-radius: @radius; -webkit-border-radius: @radius; // Para utilizarmos a regra, seguimos o mesmo padrão |
É importante destacar que um mixin pode conter diversos parâmetros. Isso pode ser feito da seguinte forma:
|
1
2 3 4 5 6 |
// Declaramos um novo mixin
.border-radius-and-color( @radius: 5px, @borderColor: #000000 ) .border-radius( @radius ); // Observe que aqui reutilizei o mixin previamente definido. Composição de mixins. border: 2px solid @borderColor; // Adicionamos agora a cor para a borda. |
Com o LESS você pode criar suas regras de CSS utilizando uma espécie de hierarquia. Vamos ver como isso funciona na prática.
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
// Dado o CSS abaixo
div#header #menu … rules div#header #menu li a div#header #topNav |
Com o LESS, o mesmo CSS acima poderia ser escrito da seguinte forma:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 |
// Como utilizar hierarquia com Less
div#header #menu ul li #topNav |
Depois de processado, o CSS será exatamente igual. Você não precisa utilizar esse esquema de hierarquia caso não queira, é importante lembrar que o LESS é apenas uma extensão do CSS, se for de desejo do desenvolvedor, podemos escrever um código LESS sem usar nenhum recurso especial, como se fosse um CSS tradicional.
Com o LESS o seu CSS sabe fazer contas. Qualquer número, cor ou variável pode ser utilizada em uma operação aritmética.
Ele sabe identificar quando estamos utilizando uma cor ou um número, por exemplo:
|
1
2 3 4 5 6 7 |
@base: 5%;
@filler: @base * 2; @other: @base + @filler; color: #888 / 4; |
Assim como no javascript, é possível também utilizar parênteses nas suas operações:
|
1
|
width: (@var + 5) * 2;
|
Na minha opinião um dos recursos mais úteis durante o desenvolvimento de uma aplicação. Podemos efetuar operações em cima de RGBs, por exemplo, imagine que o layout do seu website foi criado baseado-se em apenas uma cor, utilizando diversos tons dessa cor. Com o LESS é possível utilizar métodos pré-definidos como lighten, saturate, darken, fadein, fadeout e spin. Esses métodos retornam sempre um RGB que pode ser utilizado em seu LESS. Vejamos alguns exemplos:
|
1
2 3 4 5 6 7 8 9 |
@base: #f04615;
.class // Utilizo a cor base 25% mais clara |
É possível também extrair informações de uma determinada cor para ser utilizada em outra.
Isso é feito a partir dos métodos hue, saturation e lightness.
|
1
2 3 |
hue(@color); // retorna o valor do canal ‘hue’ da cor @color
saturation(@color); // retorna o valor do canal ‘saturation’ da cor @color lightness(@color); // retorna o valor do canal ‘lightness’ da cor @color |
Em dado momento necessitamos organizar uma série de mixins e variáveis. Para isto podemos utilizar um conceito presente no LESS chamado Namespaces. Assim como em linguagens de programação orientadas a objetos, que possuem o conceito de pacotes, os namespaces fornecem encapsulação para nossas folhas de estilo. Isso pode ser implementado facilmente utilizando a mesma notação de ID do CSS tradicional. Vejamos.
|
1
2 3 4 5 6 7 8 9 10 11 12 |
#bundle
.button () display: block; border: 1px solid black; background-color: grey; &:hover background-color: white } .tab … .citation … } |
Verifique que acima, criamos um mixin chamado button dentro do namespace bundle. Para o utilizarmos devemos fazer da seguinte forma:
|
1
2 3 4 |
#header a
color: orange; #bundle > .button; // Estamos acessando o namespace ‘bundle’ e fazendo uma chamada para o mixin ‘button’. |
Uma utilização muito comum dos namespaces é na criação de pequenas bibliotecas de utilidades. Imagine que sua empresa pode possuir uma série de arquivos LESS, e em um determinado projeto você necessita de acesso a esses mixins, variáveis, etc. Organizar seus documentos com namespaces fácilita a visualização e localização de uma determinada instrução no seu documento LESS, como por exemplo, um mixin customizado que pode ser facilmente encontrado a partir da sua indicação de namespace.
|
1
2 3 |
someRule
#dclick > .border-radius(10px); |
Como podemos ver, o LESS facilita uma série de tarefas que são praticamente impossíveis de serem efetuadas pelo CSS tradicional.
Aconselho a todos que tenham interesse em se aprofundar mais na biblioteca a conhecer o website (http://lesscss.org/). Lá você poderá encontrar a documentação com maior riqueza de informações também poderá ver alguns exemplos de código que não foram abordados nesse post.
Qualquer dúvida, sinta-se a vontade e envie-nos um comentário!
Abraço!
A algum tempo venho me aventurando no estudo de Design para apps, tanto Android quanto iOS. No entando, depois de vastas pesquisas e claro, da prática, nada melhor que ela para nos dar experiência sobre o assunto, resolvi corrigir meu último post sobre o tema.
Nele eu comento sobre a melhor técnica para criar a skin, indicando a resolução de 320 x 480px como a melhor forma. Recordemos:
“Portanto a melhor técnica é criar, obviamente tudo em vetor, na resolução de 320 x 480px, ver se está tudo harmonico, e então só depois redimensionar para o dobro, 640 x 960px. Confie, ficará muito melhor que desenhar diretamente para 640 x 960px, já tive algumas experiências ruins criando diretamente nessa resolução. Deixe para aplicar texturas caso queira faze-lo na resolução de 640, já as bases tem que ser vetorial.”
Acontece que apesar de ser uma técnica boa, utilizada muito lá fora, nada melhor que desenvolvermos o nosso próprio método, que melhor se adapta a nossa realidade.
Um dos grandes problemas que encontrei na criação de interfaces para iOS é a diferença de cores vista no meu Macbook em relação ao meu iPhone4. (o tal retina).
As cores realmente mudam, e o verde ou azul que eu estava vendo no meu Macbook e que achei que estava agradável, misteriosamente mudava de maneira drástica ao abrir a app no iPhone. Confesso que aquilo me irritava a tal ponto que ? a solução empregada por mim era senão exportar imagens de teste para então abri-las no meu iPhone a fim de comparar as cores.
Ok Eduardo, mas não estavamos tratando de resolução? Sim, mas foi procurando a solução de um problema que cheguei na solução de dois…
Pensei naqueles aplicativos para controlar o Mac remotando através do iPhone, mas que fosse por tela compartilhada, fato, iria resolver a questão das cores, mas nada a ver com a questão da resolução.
Porém depois de testar alguns aplicativos cheguei ao Live View, ele não só resolvia esse meu problema pois compartilha a tela, como sua função é exclusivamente ajudar Designers no desenvolvimento das apps, e nem acreditei quando vi que era FREE, e acreditem, pagaria facilmente 5 dólares por ele hoje devido a sua utilidade.
E porque ele resolveu meu problema de resolução? Porque me senti mais tranquilo em desenvolver já no tamanho do retina a fim de poder ver diretamente no iPhone as proporções dos elementos no meu stage.
Resultado, muito mais praticidade e com isso muito mais qualidade no visual da app…
Logo, inverti o processo para o desenvolvimento diretamente em Retina Display, e quando vou exportar no Photoshop eu simplesmente exporto para @2x com 100% de resolução e então exporto sem o @2x, ou seja, 1x, mas com o nome puro da imagem com 50% do seu tamanho.
Ah sim, e a app funciona também para iPad.
Você precisa instalar uma app no seu Mac, que irá liberar o acesso da app que está no seu iPhone ou iPad para ter a visualização no Mac.
http://www.zambetti.com/projects/liveview/
Antes de mais nada você precisa de uma rede wifi onde seu Mac e seu iPhone ou iPad estejam conectados, uma vez com a app baixada no iPhone e iPad, abra primeiro a app que está no seu Mac, do contrário vai aparecer essa imagem:
Agora que aprendeu, e abriu primeiro o Live View no seu Mac, irá aparecer a seguinte mensagem:
Basta selecionar o seu Mac e a imagem que está dentro do retângulo optado (iPhone ou iPad, portrait ou landscape) irá aparecer no iPhone ou iPad da forma como escolheu.
O Live View também permite você colocar uma senha de acesso por questões de segurança.
Ele possui várias configurações, mas são bem simples, você pode rotacionar a tela (portrait ou landscape), optar pelo Retina, inclusive escolher a performance dependendo da sua rede Wifi.
Essa app foi de grande valia para mim, espero que ajude também você que está desenvolvendo ou pensando em desenvolver para iOS.
Esta foi a 7a edição da Adobe Max que pude acompanhar pessoalmente. Posso dizer com propriedade que está foi a Max que menos vi novidades, mas talvez foi a mais importante que tive a oportunidade de participar. Antigamente ficava colocando novidades técnicas. Agora pretendo fazer você pensar.
No ano passado estava muito forte a velha estória de Flash vs Html 5 e, de certa maneira, isso ainda persiste na mente de muitas pessoas. Ficou muito claro que para a Adobe isso não é um problema. Não podemos esquecer que na essência, a Adobe é uma empresa que desenvolve ferramentas para facilitar a vida de Designer, Arquitetos de Informação, Developers etc. A Adobe nunca foi contra o Html 5, inclusive ela sempre fez parte do W3C participando da definição dos padrões do Html 5. Vi progressos de ferramentas como o Adobe Edge e integrações do Dreamweaver com JQuery e PhoneGap muito interessantes. Alias a Adobe comprou a PhoneGap como vocês já sabem.
Mas e o flash? Confesso que no meio da conferência coloquei no twitter: “Acho que pela primeira vez o flash vai morrer”. Disse isso vendo as maravilhas que a Adobe estava mostrando com CSS e Html 5 e algumas sugestões que eles estavam fazendo para o W3C. Depois analisei com mais calma e acho que me precipitei. O flash tem um longo caminho pela frente, mas acho que ele vai ocupar espaços específicos. Vejo o flash usado em totens, aplicações com consumo grande dados, que abusem de processamento (flash agora usa GPU), aplicações internas específicas, games, 3D etc. Veja esta experiência: http://www.nissan-stagejuk3d.com/. Isso ainda vai ser flash por um bom tempo.
Na conferência vimos os melhores games rodando em Flash. Esse é um caminho sem volta e quem sabe no futuro você não precise mais de seu PS3 ou Xbox e faça isso na sua próxima TV com flash ou no seu próprio micro. Também vimos a Adobe muito bem posicionada para o desenvolvimento de apps para dispositivos móveis. Um código fonte para iOS e Android, só a Adobe consegue isso hoje. Até conseguimos fazer apps com html 5 e CSS, mas os apps desenvolvidos com as ferramentas da Adobe nos dão uma performance melhor. Além de tudo, desenvolvimento para desktop com AIR também é imbatível e agora com Native Extensions, o céu é o limite.
Ficou claro que aplicações tradicionais com formulários e transações serão em Html 5. Eu já fui em vários clientes e pergunta era sempre a mesma: “Funciona no iPad?”. Sabemos que o certo seria fazer um app específico e que os tablets e dispositivos móveis requerem iterações específicas. Mas nossos clientes e usuários querem acessar suas aplicação do seu browser de qualquer lugar e de qualquer dispositivo.
Então é isso? E a compatibilidade do browser? E a facilidade do SDK do Flex? E a carga de testes vai aumentar? A resposta é que esse é um caminho sem volta. E o melhor de tudo é que isso é uma grande oportunidade para todos. Vamos sim enfrentar o velho problema de compatibilidade de browsers, fabricantes e desenvolvedores de browsers querendo cada um “impor” o seu padrão. Mas quando grandes como Microsoft, Apple, Google, Facebook e Adobe dizem que este é o caminho, é melhor refletirmos sobre isso. Até grandes desenvolvedores da comunidade Flex falam sobre isso. Vi uma palestra do Grant Skinner sobre um jogo que ele fez em html 5 usando canvas.
Na DClick nós sempre falamos que a tecnologia é meio. O mais importante é a solução e a experiência do usuário. Se para o usuário não acessar sua aplicação de um tablet ou um celular é um problema, isso é um problema de experiência. Somos muito conhecidos pelo uso do Flex e Flash e temos muito orgulho disso, mas Html 5, JQuery, CSS etc, também são realidade para nós. Novamente, tecnologia é meio.
Para mim, não existe tecnologia “matadora” para tudo. Cada problema tem a melhor solução. Cada tecnologia tem seus prós e contras. Não perca o seu tempo “pixando” uma ou outra tecnologia. Veja o que cada uma pode trazer de benefício para você, seus aplicativos e seus clientes. Estude. E o mais importante, Seja feliz!
