iScheda Publicidade Digital M2M

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/284492819 iScheda Publicidade Digital M2M Publicação de campanhas remotamente Conference Paper · June 2014 CITATIONS 0 READS 114 2 authors: Paulo Saramago Universidade NOVA de Lisboa 1 PUBLICATION0 CITATIONS SEE PROFILE Vitor Santos Universidade NOVA de Lisboa 203 PUBLICATIONS1,083 CITATIONS SEE PROFILE All content following this page was uploaded by Vitor Santos on 24 November 2015. The user has requested enhancement of the downloaded file. iScheda Publicidade Digital M2M Publicação de campanhas remotamente Paulo Saramago Development Onepointsale Lisbon, Portugal [email protected] Vítor Santos ISEGI Universidade Nova de Lisboa Lisbon, Portugal [email protected] Resumo— Existe uma necessidade de gerir melhor os meios de comunicação publicitária divulgada tradicionalmente em placares de rua. O facto da informação a disponibilizar em cada placar ser comumente colocada de forma individual torna a esta atividade morosa e dificulta a sua gestão. Uma forma de ultrapassar este problema passa pela centralização da gestão da informação e pela possibilidade de atualização remota em tempo real. No presente trabalho endereçamos este problema, conceptualizando uma solução e efetuando o desenvolvimento de um protótipo. A solução, designada por iScheda, tem vindo a evoluir passo a passo, integrando pareceres de negócio e técnicos com o objetivo de responder melhor à necessidade de publicar conteúdo digital, de uma forma prática e segura. Keywords: Digital Advertising; Remote Campaigns; M2M; Outdoors I. INTRODUÇÃO A maioria dos placares de publicidade são impressos em papel. Estando estes a ser convertidos em formato digital, os custos de comunicação e de atualização dos dispositivos são significativos, assim como a logística necessária torna-se num processo complexo e carece de medidas de segurança. Este artigo tem como objetivo descrever a conceção e o projeto de implementação de uma solução de placares de publicidade centralizada, doravante denominada iScheda. O âmbito do projeto foi definido através da descrição rigorosa dos requisitos da solução, quer a nível de produtos, como de serviços, ambos resultados da investigação. Quer a investigação como o desenvolvimento do protótipo foram conduzidas na Onepointsale, onde foram realizados as definições dos processos, nomeadamente da gestão do âmbito, da comunicação, dos recursos humanos, do procurement, financeira e do risco. Foi também estudada a identificação dos principais constrangimentos, requisitos e cronograma macro para o projeto. II. ANÁLISE DE NEGÓCIO A ideia principal de negócio foi criar um produto, o iScheda, que tem como objetivo a dinamização de uma área, incorporando uma solução em suporte de imagem digital, aliada a uma comunicação Wireless em rede centralizada, com gestão dinâmica e multicliente de campanhas de marketing e publicidade. O público-alvo do iScheda será sobretudo organizações que necessitem de atualizações permanentes de campanhas publicitárias e produtos. Essas organizações a alcançar serão sobretudo do sector financeiro, imobiliário, grandes superfícies comerciais, serviços postais, distribuição e retalho alimentar. O público a atingir terá assim em comum, a expectativa de capacitar a sua organização de meios, para que atualizem as suas campanhas de marketing, de forma centralizada, minimizando custos e disponibilizando a informação de forma apelativa, uniforme e rápida. Uma das grandes vantagens que se esperava obter é a capacidade de gestão geográfica e a atualização em tempo real da informação de forma remota. O projeto tecnológico integra comunicação Wireless GSM/M2M, de uma forma encriptada, garantindo a confidencialidade dos dados das empresas que operam na solução. A fim de dar uma melhor resposta ao desafio de publicar conteúdo digital, efetuou-se uma análise que compreendia os aspetos internos e externos ao projeto, e qual o seu valor acrescentado na cadeia de valor a nível de mercado. Realizou-se também uma gestão de riscos, que visou trabalhar desde início potenciais problemas e oportunidades, adotando medidas que facilitassem a concretização do projeto. A. Análise e Matriz SWOT Dinâmica Face à constante mudança, dos tempos assume-se como sendo importante a implementação de novas tecnologias que permitam a atualização rápida de informação e que paralelamente respondam aos desafios de redução de custos. Muito relevante face ao período económico atual. É também importante realçar que, apesar do potencial de novas soluções técnicas para a publicidade, estas não são ainda suficientemente rápidas e não permitem uma gestão centralizada. De acordo com a Análise SWOT Dinâmica (Ansoff, 1987) que apresentamos no tabela 1, as principais elações a considerar são as seguintes: 1) Para que a empresa se possa expandir a nível nacional e internacional é fundamental a criação de parcerias que, futuramente, se possam traduzir em novas áreas de negócio; 2) Os conhecimentos avançados e especializados ao nível da Gestão e das Ciências Sociais serão um elemento chave no combate às dificuldades a nível económico-social; 3) A importância de um plano de negócio consistente, bem como a partilha de know-how com os parceiros, possibilitarão a minimização de dificuldades financeiras e a falta de notoriedade no mercado. Tabela 1 ANÁLISE SWOT Oportunidades Ameaças Expansão Nacional; Parcerias; Vasta área de negócio; Mudança de hábitos nas empresas; Crise Económica Mundial; Saturação do Mercado Concorrencial; Imagem da concorrência. Forças Ideia inovadora. Criação de parcerias Futuramente expansão para áreas “secundárias” de acordo com um estudo de mercado; Conhecimentos avançados em áreas económicofinanceiras, marketing, estratégia e gestão empresarial; Recursos humanos especializados em diversas áreas; Fraquezas Fracos meios financeiros para investir; Falta de imagem no mercado. Partilha de knowhow com parceiros; Consistência do plano de negócio trará alguma facilidade na concessão de crédito; Partilha de experiência com parceiros de negócio; Aplicação criteriosa dos custos/investimentos; Contato direto com o cliente. a. Análise SWOT Dinâmica. B. Principais Riscos e Potenciais Problemas Por forma a analisar os potenciais riscos com este projeto, efetuou-se uma análise detalhada, da qual resultou a seguinte lista: 1. Avarias de equipamentos; 2. Prazos de entrega de novos equipamentos de hardware; 3. Incompatibilidade entre o iScheda e os ecrãs dos clientes; 4. Falhas recorrentes de comunicação entre a plataforma central e os equipamentos nos clientes; 5. Plágio por parte dos concorrentes; 6. Competências técnicas. Os técnicos não corresponderem ao pretendido; 7. Falta de apoio técnico em caso de avaria após o término do horário laboral; 8. Possibilidade de hackers manipularem as contas dos utilizadores; 9. Incapacidade de resposta da Plataforma em caso de grande afluência num curto espaço temporal. Após análise, em nosso entender foi lícito concluir que o plágio da solução e uma potencial falha nas comunicações dos equipamentos remotos, são os riscos, para os quais que teríamos de ter mais atenção no plano de mitigação, dado que estes, provavelmente, teriam mais impacto negativo no projeto. III. PLANEAMENTO A. Identificação de Requisitos Após a análise de negócio efetuou-se o levantamento de requisitos detalhados da solução iScheda. Estas necessidades e restrições originaram a definição dos requisitos. O critério de classificação de cada requisito (Crítico, Muito Importante, Importante) foi estabelecido por forma a ser mais fácil atribuir prioridades no plano de desenvolvimento de cada funcionalidade. Sendo a classificação Crítico, com características essenciais. Ou seja, uma falha na sua implementação significa não satisfazer o utilizador e têm de ser implementadas. Por sua vez a Muito Importante significa que esta característica deverá ser implementada. No entanto, a entrega do produto final não será atrasada pela falta de uma característica muito importante. E a classificação Importante indica que são úteis em aplicações pouco típicas, ou de uso pouco frequente. Não se espera um impacto muito grande na satisfação pela sua implementação. B. Arquitetura da Solução A infraestrutura do iScheda foi dividida em quatro camadas autónomas que refletem níveis de segurança assegurando a confidencialidade da informação dos Clientes e possibilitando uma melhor gestão na manutenção da solução. A infraestrutura foi dividida nas seguintes camadas:  Nível 0 – uma zona desmilitarizada, na qual se validam todos os utilizadores que nela se encontram, antes de passarem ao nível subjacente. É composto por um serviço de gateway para a web seguro que protege os utilizadores de ameaças da Internet, o acesso é baseado em identidade, interligando com a Active Directory interna, em que a gestão de permissões funciona a nível aplicacional, com gestão de identidades, credenciais e políticas de segurança;  Nível 1 – disponibiliza a farm do Portal, que funciona em modo de redundância e balanceamento de carga. Por sua vez, com a devida autenticação, validação de identidade do nível 0, pode aceder com credenciais no Portal na componente privada;  Nível 2 – nesta zona encontram-se os serviços aplicacionais do iScheda, na farm aplicacional, a base de dados de autenticação da Active Directory, com todos os serviços de DNS e GC (Global Catalog) associados, permitindo um uso dos recursos mais facilitado, e encontra-se também o serviço de gestão de conteúdos Sharepoint, o qual contém a base de dados de conhecimento. Paralelamente este serviço disponibiliza os Dashboards do comportamento da solução, para a equipa de gestão;  Nível 3 – na zona mais afastada da Internet, a qual faz parte da estrutura interna da solução iScheda, encontrase a zona que contém os dados, as cópias em caso de desastre e toda a informação analítica, onde infere os relatórios de Business Intelligence. Para além da base de dados relacional, encontra-se uma base de dados específica (BLOB - Binary large object) para armazenamento de grandes ficheiros, sejam estes imagens ou vídeos. A arquitetura foi dimensionada para 10.000 utilizadores, sendo que a solução foi desenhada para garantir o máximo de segurança e o máximo de validações possíveis à entrada, evitando assim potenciais ataques na camada aplicacional. Numa “Era Digital”, em que estamos mais integrados nas redes sociais, torna-se fundamental ter uma presença empresarial, dado que é um dos locais onde residem os potenciais clientes das organizações. Com esta perspetiva considerou-se na arquitetura, a possibilidade de ligação às redes sociais. C. Processo de desenvolvimento O processo de desenvolvimento de software adotado foi o Evolutivo Incremental, em que o desenvolvimento foi feito através de incrementos sucessivos face ao âmbito da solução. Ou seja, o sistema vai sendo desenvolvido progressivamente com sucessivas melhorias. O principal motivo para a adoção desta abordagem foi o facto de se tratar de um problema muito complexo, em particular na componente de comunicação e acesso remoto. D. Ferramentas De acordo com a arquitetura proposta, foram utilizadas as seguintes ferramentas de desenvolvimento e suporte da solução: 1) Microsoft Windows Server 2012 – Sistema operativo base, com os respetivos serviços de Active Directory, DNS, GC, Internet Information Services e File & Print; 2) Microsoft SQL Server 2012 – Base de dados relacional e log shipping para a infraestrutura de replicação; 3) Microsoft System Center 2012 – Monitorização, configuração e gestão de serviço; 4) Microsoft Sharepoint – Gestão de conteúdos e publicação de Dashboards; 5) Microsoft Forefront – Firewall, gestão de regras de segurança e gestão de identidades; 6) Microsoft Visual Studio 2012 – Diagramas UML, desenvolvimento e teste aplicacional; 7) Microsoft Azure – Integração da solução em arquitetura Cloud, PaaS para desenvolvimento e testes, e IaaS como infraestrutura base da solução; 8) X-Loader e kernel Linux – sistema operativo dos dispositivos remotos; 9) Hewlett-Packard Storage tool – preparação dos dispositivos de armazenamento; 10) Windows 8 ARM – sistema operativo alternativo dos dispositivos remotos. E. Análise e Desenho Funcional Os requisitos funcionais foram detalhados num mapa de navegação do Portal referindo-se sempre à necessidade de existência de um conjunto de serviços que permitissem alimentar o Portal do Cliente do iScheda, de modo a ser possível disponibilizar aos Clientes um conjunto de funcionalidades, tais como:  Adesão ao serviço;  Autenticação no Portal;  Realização de pedidos e manutenção de informação sobre os estabelecimentos;  Consulta de conteúdos. F. Desenho da Aplicação Informática Utilizando a linguagem UML (Unified Modeling Language), foram construídos diagramas que representassem as atividades previstas na solução iScheda, nomeadamente:  UML que apresenta todos os Pedidos de Cliente;  Diagrama Use Case que representa as atividades do Cliente face aos pedidos de serviço que poderá efetuar no Portal;  Diagrama UML Sequência Criação e Publicação, que continha um diagrama de sequência, em que podemos ver as várias etapas na criação e publicação por um Cliente. Foram criados mais dois modelos: o Modelo de Classes com a representação das classes da aplicação e respetivos métodos, e um Modelo Relacional - ERD (Entity–relationship model) Lógico, que espelha o Modelo de Dados da solução iScheda, assim como a explicação detalhada da sua implementação e das suas funcionalidades. O Modelo de Classes e o Modelo Relacional permitiram uma maior objetividade e rapidez durante a fase de programação da solução. G. Deliverables No âmbito do projeto e de acordo com o planeamento do mesmo foram identificados e incluídos os principais marcos a atingir: 1) Definição do projeto; 2) Estudo preliminar que apresente as soluções encontradas para o problema; 3) Requisitos funcionais e respetiva implementação UML; 4) Requisitos técnicos e respetiva implementação UML; 5) Desenho Aplicacional; 6) Software Verification and Validation Plan (SVVP); 7) Agente de software, que funcione no componente de comunicação e/ou computador; 8) Integração do componente de comunicação wireless com a solução; 9) Software central que inclua os requisitos aprovados; 10) Código fonte desenvolvido para solução (somente para os módulos identificados); 11) Integração, Protótipo e instalação experimental (somente para os módulos identificados); 12) Manual de exploração da componente aplicacional. H. Limites da solução A solução alcançada não permite a transmissão wireless de ficheiros com capacidade superior a 25 Megabytes. O motivo da limitação prende-se pelo tempo de resposta do equipamento remoto, que necessita de efetuar o carregamento das campanhas digitais. Para além desta limitação, antecipamos que outras possam emergir, fruto da natural evolução das tecnologias envolvidas. Tal levou, como habitual em projetos semelhantes, a uma especial atenção no acompanhamento futuro e a uma melhoria contínua da solução. IV. DESENVOLVIMENTO Nesta secção descrevemos o processo de desenvolvimento e implementação da solução iScheda, com o objetivo de concretização do seu primeiro protótipo. A. Infraestrutura De forma a garantir fiabilidade e robustez na solução, foi implementada uma infraestrutura que visa suportar a aplicação, garantindo a segurança e desempenho. A solução foi implementada em modo de virtualização Microsoft Hyper-V, possibilitando a migração da mesma para o modelo Cloud. B. Protótipo Sendo o protótipo baseado em tecnologia M2M (machine-tomachine) recorreu-se a uma base de desenvolvimento da Sierra (http://www.sierra.com), utilizando um Sierra Wireless AirLink FXT009 com Q2687-based quad-band gateway industrial e antenna quad-band. Paralelamente, e na expetativa de minimizar os custos do equipamento, recorreu-se a uma implementação que visa tirar partido de equipamentos GSM (Global System for Mobile Communications) de mercado, no qual se utiliza o seguinte equipamento. • Ficha de ligação USB (Universal Serial Bus); • Uma breadboard; • Um circuito para alimentar a breadboard; • Fios de ligação; • Transformador de 9v. Figura 1Esquema para a fonte de alimentação para a Breadboard Existe um forte investimento dos fabricantes no intuito de estimular os programadores a utilizar as tecnologias já comercializadas, no entanto face à especificidade de determinadas aplicações tornou-se fundamental o uso de reengenharia, por forma a adaptar nova tecnologia a novas soluções. A construção do protótipo passou por várias fases, dado que os problemas encontrados foram variados e, na expectativa de os resolver, foram sendo testados os diversos componentes até se atingir o resultado desejado. A primeira preocupação foi obter o nível de corrente elétrica correta na breadboard, dado que os equipamentos com recurso a redes GSM necessitam de maior carga (Mbed.org, 2012). Para tal, foi implementado o circuito de corrente da (Figura 1), que permitiu a alimentação do controlador, mas também do equipamento de comunicação. Para os testes de armazenamento e leitura, foram utilizados diferentes cartões de memória, nomeadamente do Kingston 8GB de Classe 4, do Samsung 4GB de Classe 4 e do ScanDisk 8GB este de classe 10 com 30MB/s de leitura. O quadro seguinte da SD Association indica as diferentes classes de cartões de memória, nomeadamente relativo às suas velocidades de leitura e escrita (SD Association, 2013). Figura 2 Quadro referência da SD Association Os testes iniciais decorreram com problemas de lentidão, duplicação e inversão das imagens e vídeos. Foram muitos os testes a nível da programação do componente de VGA na compreensão dos erros apresentados, sendo que a resolução dos mesmos foi devida à utilização do compilador 4DGL, para a publicação de vídeos, a formatação dos dispositivos de armazenamento em modo raw, a criação de ciclos de repetição, dado que em cada carregamento do vídeo este aparenta ser lento, mas nas seguintes passagens têm uma velocidade aceitável. A nível de desempenho a publicação é rápida para os modelos testados, sendo somente necessário dois minutos, para a inicialização, ligação, download das campanhas e publicação das mesmas. C. Software de Gestão Para garantir uma gestão otimizada da estrutura da solução iScheda, promovendo em simultâneo a melhoria contínua do serviço, foi desenvolvido e integrado neste projeto um software de gestão centralizado, cuja flexibilidade permitiu alcançar as seguintes funcionalidades: 1) Inventariação dos dispositivos remotos e gestão do seu ciclo de vida (Asset Management); 2) Gestão de Operações, nomeadamente Incidentes, Problemas, Pedidos e Eventos; 3) Gestão de Alterações, Configurações, Versões e Base de Conhecimento; 4) Gestão de Níveis de Serviço a nível de Infraestrutura e dos dispositivos remotos, Planos de Disponibilidade e Continuidade. 5) Gestão de Orçamentos, Ordens de Encomenda e Imputação de Custos aos Clientes; 6) Portal Self-Service para os pedidos tipificados; 7) Relatórios e Alertas. V. CONSIDERAÇÕES FINAIS A. Conclusões Acreditamos que o principal fator de sucesso para o iScheda é o tipo de serviço que apresenta que, colmata uma necessidade de mercado com um dispositivo de comunicação simples, que facilita a interligação de vários placares de publicidade, permitindo a sua atualização de forma rápida, eficiente e com um baixo custo. O Cliente do iScheda não só poderá ter a possibilidade de divulgar a sua própria publicidade, mas também de rentabilizar o seu “espaço” de publicidade para outros anunciantes. O Cliente poderá pertencer a uma rede de meios de exposição que proporcionará vantagens para difundir a sua publicidade através do iScheda de outros Clientes. Esta solução é uma alternativa/complemento aos meios atuais (TV, cartazes, outdoors, entre outros) para difusão de publicidade de Clientes, habitualmente anunciantes, com vantagens qualitativas e quantitativas, nomeadamente a atualização de placares de publicidade, de forma apelativa, uniforme, rápida, sem custos de logística acrescidos e difusões flexíveis territorialmente. Com a conclusão do protótipo confirmou-se a resposta técnica face a uma oportunidade no meio da publicidade, dado o forte crescimento dos meios de comunicação são cada vez mais e a necessidade de informar os clientes de uma forma rápida, é um fator de competitividade e cria valor ao cliente final. A utilidade de um mecanismo de comunicação remoto possibilita a publicação em meios de comunicação, já existentes, sendo que à data da realização deste trabalho, muitos não têm qualquer ligação, tal como os televisores dos estabelecimentos comerciais ou placares digitais nas estradas. Por outro lado, o protótipo iScheda desenvolvido revelou-se de utilização simples, dado que a configuração e conteúdo do equipamento são eliminados sempre que necessário, sendo esta implementada remotamente, evitando a deslocação ao local para nova implementação. Outro aspeto que consideramos importante é o facto do protótipo iScheda ter as funcionalidades base num ecrã táctil, facilitando ao utilizador no local, a possibilidade de efetuar um reset manual ou até mesmo ativar uma chamada de Call-torepair, para a equipa de suporte que, a nível da plataforma de software, poderá acompanhar o caso com base no incidente criado na ferramenta de gestão. A solução iScheda desenvolvida até à data no contexto deste projeto tem limitações, que estão relacionadas com o tempo disponível para o desenvolvimento do protótipo e respetiva solução mas, no geral, em nosso entender apresenta já uma resposta positiva face à hipótese colocada, tendo sido confirmada com algumas restrições identificadas no capítulo sete, limitações e futuros estudos. B. Trabalho Futuro Este estudo foi iniciado tendo como base uma ideia de produto. Apesar de ter sido feita uma análise detalhada, os componentes foram apenas testados para demonstrar a viabilidade da solução. A utilização de vários componentes redundantes como dois tipos de controladores a nível de processamento, ou a nível de vídeo, demonstrou que a solução de Hardware pode ser um sistema Standard, um sistema aberto e incluir várias abordagens e modelos de equipamentos, consoante a que for mais viável e competitiva. O primeiro protótipo criado tem uma limitação a nível de pixels e quando utilizado em écrans de grande dimensão, por exemplo num outdoor de doze metros quadrados, as imagens são adulteradas. Sendo necessária a utilização de campanhas publicitárias criadas num sistema de imagem vetorial SVG (System Vectorial Graphics), garantindo que a campanha não fica distorcida, mas sim nítida porque foi criada com base em vetores. Como estudo futuro, seria interessante a conversão do sinal de vídeo síncrono de um controlador gráfico do protótipo iScheda para RS232, cabo de rede de categoria tipo cinco, ou cabo de fibra ótica. Sendo esta conversão um ponto crucial no uso de écrans de dimensão elevada, ou seja, em módulos Led interligados em cascata. A plataforma de Software também desenvolvida somente para o uso do protótipo, revelou-se um fator chave para a utilização da solução, sendo que existem várias funcionalidades que podem ser alvo de estudo e desenvolvimento futuro, criando maior maturidade e complexidade no projeto. REFERÊNCIAS [1] Alberto Silva, Carlos Videira. UML Metodologias e Ferramentas Case, Volume 1. Lisboa: Centro Atlântico, 2005. [2] —. UML Metodologias e Ferramentas Case, Volume 2. Lisboa: Centro Atlântico, 2008. [3] Ansoff, Igor. Corporate Strategy. USA: Penguin Books, 1987. [4] Brian W. Kernighan, Dennis M. Ritchie. The C Programming Language. EUA: Prentice Hall Software Series, 1988. [5] Carvalho, Adelaide. Práticas de C#, Programação Orientada por objectos. Lisboa: FCA, 2011. [6] Cherim, Mike. A comparative accessibility and usability. Maio 29, 2013. http://accessites.org/site/2007/09/a-comparative-accessibility-andusability. [7] Christian Nagel, Bill Evjen, Jay Glynn, Karli Watson, Morgan Skinner. Professional C# 4 and .NET 4. EUA: Wiley Publishing, 2010. [8] Hillar, Gastón C. Professional Parallel Programming with C#, Master Parallel Extensions with .NET 4. EUA: Wiley Publishing, 2011. [9] INE - Instituto Nacional de Estatística. Localização geográfica. Junho 27, 2013. http://www.ine.pt/xportal/xmain?xpid=INE&xpgid=ine_indicadores&in dOcorrCod=0000554&contexto=bd&selTab=tab2. [10] Institute, Project Management. PMBok. 2007. [11] Jim Webber, Savas Parastatidis, Ian Robinson. REST in Practice, hypermedia and Systems Architecture. EUA: O'Reilly, 2010. [12] M2M.com. M2M, Machine-to-machine. Novembro 2, 2012. http://www.m2m.com. [13] Microsoft. Entity states and SaveChanges. Janeiro 29, 2013. http://msdn.microsoft.com/en-US/data/jj592676. [14] —. Get Started with Entity Framework (EF). Janeiro 15, 2013. http://msdn.microsoft.com/en-us/data/ee712907. [15] —. Visual C#. n.d. http://msdn.microsoft.com/ptbr/vstudio/hh388566.aspx. [16] Ramos, Pedro Nogueira. Desenhar Bases de Dados com UML. Lisboa: Edições Sílabo, 2007. [17] Santos, Maribel Yasmina. Business Intelligence, Tecnologias da Informação na Gestão de Conhecimento. Lisboa: FCA, 2009. [18] Standardization, International Organization for. ISO 9000. 2005. [19] Troelsen, Andrew. Pro C# 5.0 and the .Net 4.5 Framework. New York: Apress, 2012. [20] W3C. HTML5: Edition for Web Authors. Maio 30, 2013. http://www.w3.org/TR/html5-author. [21] —. Web Content Accessibility Guidelines (WCAG) 2.0. Maio 28, 2013. http://www.w3.org/TR/WCAG20/. [22] Wendy A. Rogers, Arthur D. Fisk. "Ergonomics in Design: The Quarterly of Human Factors Applications." SAGE, 1997: 7. View publication stats