Arquitetura da Informação sem Wireframe

Notas do Editor

• #2: \n
• #3: \n
• #4: \n
• #5: \n
• #6: 1. perguntar: quem já fez projeto sem wireframe?\n2. quem já fez projeto sem wireframe e se considerou fazendo AI?\n\nIsso é bom ou ruim?\nNós perguntamos “porque”?\n\n- quem nunca fez mas sabe o que é etnografia.\n- onde a etapa mais negligenciada é a de implementação/avaliação\nou seja. projetamos e não sabemos se ou como funciona\n\na entrega de documentos como o wireframe marca a finalização da participação de um arquiteto em um projeto?\n\npessoal, o que queremos discutir com vocês é o seguinte: \n- será que o wireframe não está atrapalhando a Arquitetura da Informacao?\n- impedindo que o arquiteto desenvolva outras habilidades?- tanto na própria opção de processo quanto na expetativa do outro\n- pq? pq a galera só ve o trabalho do arquiteto no wireframe\n- não TOCAm, nao VEEM o processo . e por isso não dão valor\n
• #7: esta é umaproblemática no nível do profissional\n\neste é um assunto discutido no próprio EBAI\n\n"maestro de uma orquestra, concebendo e movendo a equipe para frente" MORVILLE\nou \no operador de axure?\n\nao mesmo tempo que o wireframe é a atividade mais executada temos... (póximo slide)\n\n\n“a natureza holística do trabalho de arquitetura de \ninformação, certas pessoas claramente não se darão por satisfeitas até \nque tenham controle direto sobre todos os aspectos do trabalho que \npossam afetar a arquitetura. Esse modo de pensar é um sinal do pior \ntipo de arrogância e solapa todo esforço de convencer as empresas do \nvalor da disciplina” GARRET\n
• #8: este desejo de dominar todo o processo\n\nisso impacta onde?\n\nno ponto máximo onde o arquiteto de informação pode tocar\nno cheirinho de interface do usuário\n\nonde temos o reflexo?\nas consequencias aparecem no desejo, na fome... (próximo slide)\n
• #9: ... na ansiedade do wireframe\n\nTemos “ansiedade de wireframe”: de que a resolução dos problemas de arquitetura estão num documento e podem ser manipuladas, tocadas...\n
• #10: \n
• #11: \n
• #12: \n
• #13: \n
• #14: um documento\numa especificação: acordo entre profissionais sinalizando o caminho decidido para aquilo que deverá ser produzido\n- um setor de agências de publicidade ("manda pro wireframe")planta baixa de uma agência com "área dos post-its"\n- e as vezes até uma pessoa ("chama ai o… wireframe")pessoa com cara de wireframe\n\nestaria o destino do arquiteto ser tipo um “flasheiro” ou “htmler”?\n
• #15: \n
• #16: \n
• #17: SLIDE 3 FUNÇÕES DO WIREFRAME COMO DOCUMENTO:\n- comunicar ( espaço entre pessoas par amanifestar possibilidades mais definidas)\n- colaborar (especificar... e por isso, espaço de disputa) \n- documentar ( registrar E MATERIALIZAR)\n\n“O wireframe é uma maneira de manifestar\ndecisões realizadas em torno de um projeto,\ne pode ser utilizado com diferentes propósitos.”\n
• #18: o ponto mais importante da sua utilização é como colaboração.\n\nSegundo James Garrett, quando arquitetos \nde informação e designers são separados, a única maneira de se produzir wireframes de \nsucesso é por meio da colaboração.\n\ne quando isso fica na mão de um profissional, outros aspectos são deixados de lado... \n\nfalando de desenvolver conceitos, de acordar, de decidir, o arquiteto com o wireframe tem nas mãos este controle e passa a fazer parte da disputa \n\né nesta dinâmica que\n
• #19: e quando a colaboração não acontece nós percebemos o conflito, \n\no conflito é algo positivo, quando amenizada as relações de poder, quando existe diálogo e troca, e o wireframe não tem um “pai”, um dono\n\nO projeto de interfaces é um processo político (AGNER, 2006, p.140-144) onde se \nmanifestam conflitos de perspectivas e prioridades, em um jogo que envolve múltiplos \ninteresses de clientes, usuários, arquitetos, designers, desenvolvedores, entre outros. \n\no wireframe está no limiar entre a arquitetura de \ninformação e o design de interface. O modo mais comum de se fazer wireframes reforça uma \ndicotomia conteúdo e forma, onde o arquiteto trabalha em prol deste último e, desta maneira, \ninevitavelmente interferindo no trabalho de Design Visual.\n
• #20: \n
• #21: http://darmano.typepad.com/logic_emotion/2006/05/the_guided_wire.html\nhttp://boxesandarrows.com/view/the_guided_wire\n
• #22: \n
• #23: pensando no quanto interfere na arquitetura de infromação, na relação dos profissionais, o quanto não é positivo te-lo centralizado.\n\nenquanto o arquiteto se coloca como ”fazedor de wireframes”, ele também é percebido...\n
• #24: a pergunta é: quais são as implicações disso?\ncomo isso retorna ao profissional ou a disciplina?\n\né desta maneira...\n\nserá que era isso que o arquiteto de informação, ao adotar o wireframe, adotar de fato como sua obra, esperava?\n\n\n
• #25: aqui ele já projetou arquitetura de informação, achou que projetava experiências, e chegou ao wireframe thinking.\n
• #26: afinal, dá para fazer AI sem wireframe? \nlevantamos algumas 3 maneiras que \najudam a pensar no objetivo do \nwireframe: documentar, colaborar e \ncomunicar -- e modos de fazer sem ele\n
• #27: \n
• #28: \n
• #29: \n
• #30: \n
• #31: \n
• #32: falar do problema de começar a \nespecificar sem antes testar \npossibilidades com sketch, \ngogosketch, etc\n\nfalar que o fred criou o termo\n
• #33: Já o wireframe detalhado, assim como qualquer trabalho que exija tempo e \ndedicação, pode gerar um apego entre seu produtor e o resultado do trabalho e, assim, \nrestringir possibilidades de desenvolvimento em um estágio inicial\n
• #34: \n
• #35: o que fazer se o wireframe nem \nsempre é a melhor pedida?\n
• #36: explorarem nos seus \ntrabalhos as alternativas: dar uma \nchance para olhar a Arquitetura \nsem wireframe pode dar inights \nde novos métodos e práticas \n
• #37: \n
• #38: \n