Meus melhores Tweets

Recentemente descobri que o Twitter permite embutir (Embed) um Tweet numa página. Gostei da funcionalidade e por isso resolvi colocar aqui os meus “melhores” Tweets segundo os Retweets que recebi.

Fazer o aplicativo primeiro para o iOS ou para Android?

Eu tenho a impressão que a maioria dos softwares mobile de sucesso saem primeiro no iPhone e, se derem certo, saem também para Android.

Ontem, o Flipboard, um dos melhores aplicativos para iPad fez sua estreia no iPhone e recebeu até elogio do VP de Marketing da Apple.

Recentemente o André Gil me mostrou o Path e fiquei de queixo caído. Hoje o Path tem versões para iPhone e Android, mas ele também é um caso que começou primeiro no iPhone:

Quando resolvemos fazer o Wesave tomamos esta decisão porque nós três (1, 2, 3) temos iPhone e não Android. Além disso, por algum motivo que penso entender melhor hoje, acreditávamos que no iPhone o aplicativo seria mais bonito e nós queríamos a melhor experiência que fossemos capazes de criar.

Em minha opinião entra dispositivo sai dispositivo e o iPhone continua oferecendo as melhores experiências de usuário por vários motivos:

1. É mais complicado fazer uma interface de usuário que se adapte bem aos diferentes dispositivos Android. Como você não sabe se o seu aplicativo vai pegar é melhor fazer para uma plataforma menos fragmentada para facilitar seus updates.

2. O Design da Apple é excelente e para piorar os fabricante e os usuários vivem customizando e destruindo o Android

3. Os usuários de iOS costumam ter sempre a ultima versão atualizada. Coisa que não acontece com os usuários de Android

4. As animações são muito mais fluídas no iOS

Você pode ver mais detalhadamente porque as animações no iOS são melhores neste excelente artigo de quem pode falar com propriedade. Resumindo, o fato é que a animação foi premissa central no desenvolvimento iOS e do Windows Phone. Como resultado as animações têm prioridade sobre todos os outros processos, mas isto não aconteceu no Android.

Posso até ouvir neste momento as pessoas mais técnicas falando: animação é frescura! Mas se já era importante no caso do Desktop é ainda mais no caso do Touch.

Numa tela Touch Screen a percepção do usuário conta muito. Como você está manipulando estes objetos virtuais (a tela e seus controles de interface) com suas mãos, eles devem responder de maneira natural, tal como é no mundo real. Quando você arrasta um papel sobre a mesa você não vê o papel pular e reaparecer mais adiante no sentido em que estava sendo arrastado. O movimento é suave e condizente com os nossos sentidos. Ter uma manipulação que trava no Touch Screen é como ter o mouse travando no Desktop.

Acredito que isto também explica porque muita gente costumava pensar que a questão era o aparelho em si. Alguns diziam que o Touch Screen do iPhone era imbatível e por isso a reposta era mais fluida. Mas esta claro agora que a questão é a arquitetura do sistema operacional, ou seja, se trata de software e não de hardware. Por isso não adianta contar vantagem do seu aparelho tem um processador mais poderoso.

Por estes motivos e por querer fazer produtos com as melhores experiências que sou capaz, é que acho que vou continuar com esta estratégia: primeiro farei o aplicativo para o iOS, se pegar faço uma versão para o Android.

Mesmo com muito mais dispositivos Android do que iOS o número de downloads de aplicativos da Apple Store é bem maior.

Tão perto e tão longe

Hoje estamos mais perto das pessoas que estão longe do que das que estão perto.

A questão não é só o Flash, mas o propósito da Adobe

Eu comecei a trabalhar com a Plataforma Flash porque naquela época ela me permitia criar melhores experiências, e não porque “era mais fácil”. Na época da Macromedia o propósito era claro: Experience Matters. Lembram? A o alvo da experiência na época da Macromedia era o usuário final.

Mas acho que com a Adobe isso mudou, principalmente agora que eles estão aos poucos desistindo do Flash Player. Não parece que propósito da Adobe é criar melhores as experiências para os usuários finais, mas sim para os desenvolvedores. A eterna promessa de fazer um único código e ter em vários devices (coisa que a Sun tentou no passado com o Java) é algo que chama muito a atenção do pessoal técnico (tornaria nossa vida bem mais fácil, não é mesmo?). Mas justamente por não ser nativo, eu particularmente não acredito que este tipo de aplicativo oferecerá a melhor experiência ao usuário (coisa que dependendo do caso nem sempre é preciso).

O que estou querendo dizer é que todo este debate (1, 2) não gira só em torno do Flash Player, mas sim em torno do propósito da Adobe. Quem acredita que finalmente o Write Once Run Everywhere será realidade continuará engajado no foco que a Adobe está dando para o Flex. Por outro lado, creio que os que buscam oferecer as melhores Experiências possíveis para o usuário final devem também aprender o Android Nativo, o iOS Nativo e o HTML5 puro (que é o verdadeiro Write Once Run Everywhere). E isto pode ou não ter relação com a questão “Para quê você faz Software?”.

Para quê você faz software?

A minha primeira paixão foi a máquina, o computador em si. Ver aquela caixa bege na minha frente já me deixava fascinado. Mas quando descobri o que dava vida aos computadores desenvolvi uma paixão maior ainda pela vontade de fazer meus próprios programas de computador.

No início eu não sabia metade do que eu sei hoje, mas lembro que na febre dos bichinhos virtuais (tamagotchis) eu fiz um em Visual Basic à base de inúmeros “ifs” e “fors”. Na verdade, fiz vários outros programas mesmo antes de entender bem muitos conceitos de desenvolvimento de Software.

Então veio o colegial Técnico em Processamento de Dados, a faculdade, os livros e eu descobri a Orientação a Objetos, as estruturas de dados, os algoritmos e todo o maravilhoso mundo da programação. Não deu outra: aqui estava minha nova paixão!

Suponho que muitos que estão lendo este texto também são apaixonados por seus códigos, seus algoritmos, suas implementações de MVC (verbo “to be” da programação), suas Best Practices e, principalmente, suas tecnologias favoritas. O problema é que quando eu estava apaixonado esqueci a minha “origem”, esqueci o que havia me motivado realmente a entrar neste mundo: fazer programas de computador. O código, limpo, inteligente e bonito era o que importava agora. Eu havia me tornado um “alienado tecnológico” e caído na armadilha do TI-Centrismo.

Não posso garantir que você passa ou passou pelo mesmo que eu, mas vou explicar como eu me sentia quando estava apaixonado. Se você se sente assim, tome cuidado, pois esta paixão deve lhe deixar cego de tal forma que talvez este seja o motivo pelo qual você não consegue mais fazer tanto quanto fazia antigamente.


O amor é cego

Quando eu estava apaixonado olhava meu código e achava ele lindo. Eu cuidava dele com carinho e ficava “p da vida” quando não me deixavam dar a atenção que meu código merecia. O código dos outros? Nossa como eram feios! E eu era o verdadeiro Ivo Pitanguy da programação, sempre capaz de fazer uma cirurgia plástica que ia deixar o código dos outros muito mais bonitos. Eu também passava horas discutindo com outras pessoas que insistiam em dizer que a tecnologia delas eram mais bonita que a minha. E era assim que eu gastava todo meu tempo: olhando para meu mundo, o mundo dos Design Patterns, das tecnologias e das metodologias. O todo não era importante desde que eu tivesse satisfeito com a minha parte (uma excelente maneira de se sentir confortável com o fracasso dos projetos). Eu havia desenvolvido o que chamo de egocentrismo funcional.

Certo dia eu levei um baque pois descobri que a minha paixão estava me traindo. Descobri que ela era a responsável por eu não conseguir mais fazer softwares como eu fazia antigamente. Ela me iludia. Eu achava que estava fazendo mas não estava fazendo nada pois o resultado era péssimo no final das contas. E a minha paixão me enganava de outra forma: a culpa nunca era minha.

Então eu resolvi partir pra outra e acabei reatando com a minha necessidade inicial de fazer acontecer. Fazer grandes projetos. Fazer grandes produtos. Se o meu código tem que ser bonito para isso: ok. Mas se para um bom resultado final eu tiver que fazer uma baita gambiarra foda-se, isto é um trade-off. Eu percebi que perdi muito tempo da minha vida preocupado com o meio e não com o fim. O código é o meio e não o fim. A tecnologia é o meio e não o fim. O produto é o fim. Eu era uma loja cujo o depósito era céu e a fachada o inferno. Meus clientes iam embora e eu enganava a mim mesmo criando desculpas para me sentir confortável com a situação. A culpa era do cliente e não minha. A culpa era do gerente e não minha.

E se mesmo assim você insistir em dizer que não tem culpa alguma, que tal parar de falar e fazer? O que importa é o seu código bonito nos seus produtos não tão bonitos assim? Vai lá e faz! Tem uma idéia? Está esperando o quê? Não conhece a tecnologia? Mas no começo você fazia mesmo sem conhecer, não era mesmo? Isso se chama Zona de Conforto. É seu cérebro achando que vai ser muito difícil e preferindo fazer as mesmas coisas de sempre.

Sim, é difícil, muito difícil vencer a luta contra nós mesmos. Mas comece assumindo que você é ser humano. Se não conseguiu fazer nada que gostaria é possível que você seja um dos responsáveis! Simples assim. A verdade nua e crua.

O que me motivou a escrever este texto é que ainda vejo muita, mas muita gente falando sobre suas paixões, discutindo detalhes técnicos mesmo antes de saber o propósito do produto, discutindo o que usar mesmo antes de saber quem vai usar. Mas de que adianta tanto conhecimento pra nada? Mas não é para nada – você diz. Então é para quê? Eis aqui o ponto chave!

Se eu lhe perguntar por que você faz software espero a resposta: porque eu gosto. Mas a pergunta certa não é “por que”. A pergunta certa é “para quê”. Para quê você faz Software?


Thumbnails powered by Thumbshots