UNIVERSIDADE FEDERAL DA PARAÍBA CENTRO DE CIÊNCIAS HUMANAS, LETRAS E ARTES DEPARTAMENTO DE MÍDIAS DIGITAIS CURSO DE COMUNICAÇÃO EM MÍDIAS DIGITAIS

Transcrição

1 UNIVERSIDADE FEDERAL DA PARAÍBA CENTRO DE CIÊNCIAS HUMANAS, LETRAS E ARTES DEPARTAMENTO DE MÍDIAS DIGITAIS CURSO DE COMUNICAÇÃO EM MÍDIAS DIGITAIS TIAGO JOSÉ LIMA DE OLIVEIRA WORK ORDER TRACKING: PLUGIN DE ORDENS DE SERVIÇOS PARA WORDPRESS JOÃO PESSOA - PB 2014

2 TIAGO JOSÉ LIMA DE OLIVEIRA WORK ORDER TRACKING: PLUGIN DE ORDENS DE SERVIÇOS PARA WORDPRESS Relatório final, apresentado à Universidade Federal da Paraíba (UFPB), como parte das exigências do Programa do Curso de Comunicação em Mídias Digitais para obtenção do Título de Bacharel. Orientador: Prof. Me. Paulo Henrique Souto Maior Serrano JOÃO PESSOA - PB 2014

3 Catalogação da Publicação na Fonte. Universidade Federal da Paraíba. Biblioteca Setorial do Centro de Ciências Humanas, Letras e Artes (CCHLA). Oliveira, Tiago José Lima de. Work Order Tracking: plugin de Ordens de Serviços para Wordpress./ Tiago José Lima de Oliveira. - João Pessoa, f.:il. Relatório (Graduação em Comunicação em Mídias Digitais) Universidade Federal da Paraíba - Centro de Ciências Humanas, Letras e Artes. Orientador: Prof.º Me. Paulo Henrique Souto Maior Serrano 1. Software. 2. Plugin. 3. Wordpress. 4. Desenvolvimento Web. I. Título. BSE-CCHLA CDU 004.4

4 TIAGO JOSÉ LIMA DE OLIVEIRA WORK ORDER TRACKING: PLUGIN DE ORDENS DE SERVIÇOS PARA WORDPRESS Relatório final, apresentado à Universidade Federal da Paraíba (UFPB), como parte das exigências do Programa do Curso de Comunicação em Mídias Digitais para obtenção do Título de Bacharel. Orientador: Prof. Me. Paulo Henrique Souto Maior Serrano Aprovado em 12 de Agosto de 2014 BANCA EXAMINADORA Orientador Prof. Me. Paulo Henrique Serrano Depto. de Mídias Digitais / CCHLA / UFPB Campus I Prof. Me. Cléber Morais Depto. de Mídias Digitais / CCHLA / UFPB Campus I Prof. Dr. Guilherme Ataíde Depto. de Ciência da Informação / CCSA / UFPB Campus I

5 À minha mãe que sempre incentivou; Ao meu pai que sempre acreditou; À minha irmã que sempre foi a maior parceira.

6 AGRADECIMENTOS A Deus que sempre foi o maior conforto. A todos os meus familiares, pelo amor e por estarem em todos os momentos ao meu lado. Especialmente meus pais e irmã, que nunca deixaram faltar estímulo e sempre souberam ser um alívio nos momentos de ansiedade. Ao meu orientador, Prof. Me. Paulo Henrique Serrano pela oportunidade de realização deste trabalho, pelo incentivo no desenvolvimento. Ao curso de Comunicação em Mídias Digitais e professores, que permitiram identificar as áreas de atuação de maior afeição. Aos meus amigos que sempre foram compreensíveis e presentes nos momentos certos. Aos meus amigos da UFPB que tornaram o desenrolar do curso mais prazeroso e descontraído. A todos os outros que não foram citados, mas que, de alguma forma, contribuíram para o cumprimento de mais uma etapa.

7 RESUMO Este relatório descreve todas as etapas para a criação de um plugin de Ordens de Serviços para Wordpress. Visando uma descrição mais detalhada, a discussão é constituída através de textos, tabelas e gráficos dispostos em meio às várias fases da produção, incluindo desde o recolhimento dos dados, como o planejamento e arquitetura das informações até o resultado final de pleno funcionamento da ferramenta. O plugin tem como objetivo principal atender às diversificadas necessidades de assistências técnicas de serviços. Dessa forma, ser um aplicativo capaz de cadastrar, consultar e administrar Ordens de Serviço, tipo de documento utilizado diariamente por estas organizações. Além disso, o software deve: ser de fácil instalação, para que possa ser instalado por qualquer tipo de usuário; conter uma interface de assimilação rápida; e ainda disponibilizar a incorporação de widget e/ou shortcode no site do usuário. Essas aplicações exibem um breve formulário de busca através do qual os clientes das assistências podem acompanhar o status dos seus serviços. O relatório trata também das dificuldades, as resoluções e os resultados para cumprimento de cada requisito do plugin de acordo com a documentação do Wordpress. Palavras-chave: plugin; Wordpress; software; desenvolvimento web.

8 LISTA DE TABELAS Tabela 1: Demonstração das colunas da tabela de OS Tabela 2: Demonstração das colunas da tabela de orçamento... 22

9 LISTA DE ILUSTRAÇÕES Quadro 1: Quadro comparativo entre as quatro assistências Quadro 2: Quadro comparativo entre os modelos de Ordens de Serviços Quadro 3: Quadro comparativo entre as fichas de Orçamentos Quadro 4: Opções adicionadas na tabela wp_options Figura 1: Gráfico do dia 6 de agosto de 2014 referente ao uso dos CMS mundialmente Figura 2: Esboço da interface para cadastro de OS Figura 3: Esboço da versão de impressão das OS Figura 4: Comparação entre uma das linhas da tabela de dados do cliente Figura 5: Interface da página de cadastro de OS Figura 6: Exemplo de visualização de impressão da OS Figura 7: Quadros usados para as etapas de aprovação, execução e entrega Figura 8: Demonstração de adequação da página principal Figura 9: Caixa de diálogo exibida na página de impressão caso os dados da empresa não estejam preenchidos Figura 10: Representação do código PHP utilizado para exibir conteúdo através de cliques de botões Figura 11: Demonstração da paginação do plugin Figura 12: Representação da estrutura utilizada no formulário de busca Figura 13: Fluxograma de alteração dos status Figura 14: Exemplo do resultado de busca pelo widget na sidebar Figura 15: Exemplo do resultado de busca pelo shortcode em uma página... 40

10 SUMÁRIO 1 INTRODUÇÃO Justificativa Problema Hipótese Objetivos FUNDAMENTAÇÃO TEÓRICA Breve histórico de linguagens para web Web 2.0 e Content Management System (CMS) METODOLOGIA Briefing Levantamento de dados Arquitetura das informações Os status Wireframe Tabelas Desenvolvimento do plugin Front-end Experiência do usuário Controle de erros Back-end Informações básicas Criação de tabelas e SQL Paginação Formulário de busca Atualização de status Widget e Shortcode CONSIDERAÇÕES FINAIS REFERÊNCIAS GLOSSÁRIO APÊNDICES ANEXOS... 50

11 9 1 INTRODUÇÃO As tecnologias que compõem a internet e as páginas da web têm evoluído e se modernizado desde o seu surgimento. As possibilidades de desenvolvimento de sites são infinitas; novas fontes de códigos de linguagens são criadas, e outros adaptados, constantemente para que atendam a demanda de web designers e programadores. Esses fatores contribuem para a facilidade e agilidade na produção de sites e/ou sistemas de informações. Lição comprovada da história da tecnologia [é] que os usuários são os principais produtores da tecnologia, adaptando-a a seus usos e valores e acabando por transformá-la [...]. Novos usos da tecnologia, bem como as modificações reais nelas introduzidas, são transmitidos de volta ao mundo inteiro, em tempo real [...] e o resultado é que nos envolvemos num processo de aprendizagem através da produção, num feedback intenso entre a difusão e o aperfeiçoamento da tecnologia. Foi por isso que a Internet cresceu, e continua crescendo, numa velocidade sem precedentes, não só no número de redes, mas no âmbito de aplicações. (CASTELLS, 2001, p.26). 1.1 Justificativa A inclusão digital se tornou indispensável no mundo dos negócios. Os sites se apresentam como mais um meio de comunicação entre as organizações e seus clientes, com diversas vantagens. Além de terem seus serviços propagados a uma quantidade muito maior de pessoas, os negociantes podem ter seus trabalhos agilizados. Por exemplo, ao invés de o cliente precisar se dirigir fisicamente a eles, ou realizar ligações em busca de informações triviais, o site pode disponibilizar, com menos trabalho e muito mais comodidade, qualquer informação que ele precisar. Benefícios para os dois. A ampliação de conhecimentos se faz fundamental para o crescimento profissional bem sucedido. Sabendo disso, como motivação pessoal, uma das razões para o desenvolvimento do proposto trabalho, foi aumentar os conhecimentos adquiridos durante a graduação. No curso, foram estudadas algumas linguagens basais para desenvolvimento web; guiado pela curiosidade e pretensão de saber mais, e para o aprofundamento do que foi já estudado, o trabalho foi conduzido.

12 Problema No cenário atual a maioria das empresas utilizam os sistemas de informação como ferramenta imprescindível aos seus processos de negócio (SOUSA, 2009). No caso das assistências técnicas de serviços, estes processos de negócio estão ligados diretamente à utilização de Ordens de Serviços (OS). É através delas que a empresa tem controle dos serviços e dos produtos que são recebidos. Nelas estão inseridos todos os dados referentes ao produto, ao cliente e ao serviço. O problema é quando a quantidade de documentos é muito grande e dificulta este controle. Além disso, o acesso a esses dados precisa ser rápido, para passar informações aos clientes que desejam saber sobre o andamento dos seus serviços. Esse tipo de atendimento ao cliente, mesmo que rápido, algumas vezes acaba dificultando a execução de tarefas e serviços que requerem mais atenção e habilidade. Para uma melhor organização, algumas assistências recorrem a programadores para criação de softwares específicos que atendam as suas necessidades. Na maioria dos casos, a criação de um sistema próprio custa caro, e nem todas as empresas podem financiar este desenvolvimento. Para tornar mais prática a comunicação com o cliente, algumas destas empresas acabam recorrendo à opção de criação de sites pouco comunicativos e sem tanta usabilidade. Em experiência pessoal anterior, foi criado um site para uma assistência técnica de relógios, em que eram apresentadas algumas facilidades, tais como tabelas de preços, história da empresa e localização. Entretanto, para que o site cumprisse plenamente a sua função comunicativa, era preciso que oferecesse uma ferramenta de acompanhamento de serviços para os clientes. Devido à carência de aplicações que facilitassem o cumprimento desta função, e, até então, conhecimento insuficiente para confecção própria, este último quesito não foi disponibilizado. 1.3 Hipótese O ideal para empresas ou profissionais que utilizam ordens de serviços, seria a disponibilização de uma ferramenta gratuita ou de baixo custo, que permitisse aos clientes ter acesso ao andamento dos serviços através de seus sites. Para melhorar o desempenho dessa ferramenta e dos processos de trabalhos nas assistências, esse software deveria ser capaz de cadastrar e arquivar as ordens de serviços com os dados dos clientes, do produto e do(s)

13 11 serviço(s). Dessa forma, as consultas seriam facilitadas para a assistência e para os clientes, que podem ter acesso aos seus serviços em qualquer lugar. 1.4 Objetivos O objetivo geral desse trabalho foi desenvolver uma extensão de CMS (Content Management System) para cadastro, administração e consulta de ordens de serviços que atendesse a demanda de assistências técnicas, que não podem investir na produção de sistemas específicos, ou de qualquer outro usuário que careça de um aplicativo que cumpra tais finalidades. O CMS escolhido para ser trabalhado foi o Wordpress, por ser o mais utilizado em desenvolvimento web (BUILDWITH, 2014). Além disso, a facilidade e simplicidade desta plataforma a aproximavam ainda mais da necessidade das assistências técnicas de um sistema de fácil assimilação. As ferramentas de extensões de funcionalidade do Wordpress são denominadas de plugins. E para permitir o acompanhamento dos serviços pelos clientes, foram utilizadas as ferramentas widget e shortcode. Ambos permitem a instalação de algum bloco de conteúdo no website da assistência, a diferença entre eles é com relação às formas de instalação e onde o formulário deve ser exibido. No intuito de tornar o plugin ainda mais acessível a qualquer empresa ou pessoa, a ferramenta é gratuita e seus códigos foram estrategicamente organizados e comentados. Dessa forma, qualquer usuário que tenha conhecimento básico em desenvolvimento web, pode entendê-lo e modificá-lo quando necessário. O plugin também foi desenvolvido de acordo com os outros princípios básicos que o classificam como um software livre. Segundo o portal da Fundação do Software Livre América Latina - FSFLA são eles: possibilidade de rodar o programa quando quiser, estudar o código fonte e modificá-lo se preciso, copiar o programa, distribuir cópias livremente e publicar, e distribuir versões modificadas quando quiser (FSFLA, 2010). Para Garofalo e Alis (2010, p.2), a filosofia por trás dos softwares livres pressupõe o seu tratamento não como objeto de posse, não como produto, mas sim como ideia, algo que possa ser compartilhado sem que isso lhe desagregue valor.

14 12 2 FUNDAMENTAÇÃO TEÓRICA 2.1 Breve histórico de linguagens para web O HyperText Markup Language (HTML) surgiu em 1991 e é atualmente a principal linguagem para desenvolvimento de páginas web. HTML, segundo a entidade de padronização da WorldWideWeb W3C ( é uma linguagem que descreve a estruturação de páginas web através de elementos de marcação. Através dela, é possível a publicação de textos e diversos outros tipos de mídias, além de acessar, através de cliques no mouse, outras informações online por meio de links de hipertexto. Desde o seu surgimento, o HTML sofreu várias modificações. Segundo a documentação da W3C a primeira versão no HTML era bastante limitada. As possibilidades dessa linguagem eram basicamente cabeçalhos, parágrafos, imagens no modo in-line, links de hipertexto e listas. Com o passar do tempo essa tecnologia foi se aperfeiçoando, e nas versões 2 e 3 já foram incluídos formulários, tabelas, cores de fundo etc. Devido ao crescimento no número de sites, a concorrência também aumentou, por consequência, a dificuldade de ter seus sites destacados também (GOODMAN, 1999, p.3). A versão do HTML 4 foi lançada oficialmente em 1997 e trouxe inovações significativas. Além das melhorias nas ferramentas mais antigas e criação de outras, a nova versão possibilitou a incorporação de páginas de estilo e execução de scripts (W3C). Essas duas novidades resultaram na criação de novos tipos de linguagens agregadas ao HTML: de estilo e de script. Com o surgimento dessas tecnologias, recursos mais dinâmicos puderam ser desenvolvidos, possibilitando a execução de algoritmos mais complexos diretamente no navegador do usuário ou visitante do site. (SERRANO; NICOLAU, 2012). Surgiu então, um novo fenômeno no âmbito do desenvolvimento web, o Dynamic HTML (DHTML) traduzido livremente para HTML Dinâmico. O DHTML não se trata de uma linguagem especifica, e sim, a fusão de várias linguagens para criação de páginas dinâmicas e interativas (KYRNIN). Com esse novo método, é possível alterar o que está sendo visualizado na tela sem necessariamente trocar de página; é possível interagir com a mesma página escondendo e mostrando objetos, por exemplo (SHANNON). Em outras palavras, o DHTML possibilitou que cliques em botões façam com que qualquer coisa aconteça na mesma página.

15 Web 2.0 e Content Management System (CMS) O conceito de Web 2.0 foi sugerido por Tim O Reilly e começou a ser propagado a partir do ano de Para Carvalho (2008, p.7), com o surgimento da Web 2.0, a facilidade de publicação online e a facilidade de interação entre os internautas torna-se uma realidade. Há alguns anos, os sites estavam disponíveis como livros: as pessoas acessavam, liam e viam o que era de interesse e fechavam. No máximo, a comunicação com os desenvolvedores ou responsáveis pelo conteúdo era através de um . Atualmente, uma página que se limitar a isso está fadada ao esquecimento. (AMOROSO, 2008). As mudanças também foram no âmbito visual. Depois da euforia multicolor e sonora, passou-se a uma nova fase de maturidade em que se procura a sobriedade e a simplicidade (CARVALHO, 2008, p.7). Os elementos gráficos passaram a ser muito mais agradáveis, porém, o mérito para isso não foi só do surgimento desse novo conceito de web, mas também do surgimento e da popularização dos conteúdos dinâmicos (AMOROSO, 2008). Segundo Beners-Lee et. al (1994, p.76), a web foi desenvolvida para ser um repositório de conhecimento humano, que permitiria que colaboradores locais distintos partilhassem as suas ideias e todos os aspectos de um projeto comum.. E de acordo com a Folha de São Paulo (2006), a principal característica da Web 2.0 é a participação do usuário na produção de conteúdo. Esse fenômeno possibilitou o surgimento de diversas ferramentas e tecnologias que permitem a interação com o usuário, ligada essencialmente à produção de conteúdo. Alguns exemplos dessa nossa fase: AdSense, wikis e blogs. Além das já citadas tecnologias, a Web 2.0 também resultou na busca de novos métodos de publicações online. Os Content Management Systems (CMS), em português, Sistemas de Gerenciamento de Conteúdo (SGC), já existiam desde o final da década de 90, porém, só se tornou notório conforme a popularidade da Web 2.0 aumentou. Para Chagas, Carvalho e Silva (2008, p.1), os CMS são sistemas de trabalho colaborativo, com suporte para realização de tarefas e que facilitam a criação, gerenciamento, distribuição, publicação e informações corporativas. Qualquer colaborador de uma organização, detentor de informação, pode produzir conteúdo no website da organização com o uso de um SGC. Além disso, os SGC reduzem erros de publicação e facilitam o processo de validação. (CHAGAS; CARVALHO; SILVA, 2008, p.1).

16 14 Segundo o BuildWith, até 6 de agosto de 2014, o Wordpress é o CMS mais utilizado, com 47,38% de domínio sobre os outros nesta data (Figura 1). Isso faz com que a plataforma se torne muito mais confiável. O fato de muitas pessoas utilizarem o sistema facilita a correção de erros e a segurança nas informações. O Wordpress ainda permite a instalação de plugins, que segundo sua própria documentação, são ferramentas para estender as funcionalidades da plataforma. Enquanto o núcleo do Wordpress é desenvolvido para ser simples possível, os plugins se encarregam de oferecer funções e recursos que possibilite o usuário adaptá-lo para suas necessidades específicas. Figura 1: Gráfico do dia 6 de agosto de 2014 referente ao uso dos CMS mundialmente Fonte: BUILDWITH, 2014.

17 15 3 METODOLOGIA 3.1 Briefing Levantamento de dados Para o desenvolvimento de um produto, é extremamente necessário entender as necessidades do seu público alvo, e assim, atende-las ao máximo. Sabendo disso, a etapa de recolhimento de dados foi indispensável para o desenvolvimento do plugin. Foram estudados os perfis de quatro assistências (Quadro 1) e em seguida recolhidos os modelos de Ordens de Serviços (OS) e orçamento utilizadas diariamente por elas. Quadro 1: Quadro comparativo entre as quatro assistências Nome da empresa NJ Serviços Natal Watch Watch Center NJ Relógios Localização João Pessoa PB Natal RN Salvador BA João Pessoa PB Ficha OS Manual Manual Manual Eletrônica Ficha Orçamento Não possui Manual Manual Eletrônica Sistema Eletrônico Necessidade de Sistema Não Não Não Sim Custo baixo Ser de fácil compreensão Fonte: o autor Ser de fácil compreensão Ser fácil e permitir ao cliente acompanhar o andamento do serviço Em análise dos dados acima, é perceptível que as empresas NJ Serviços e NJ Relógios são as que possuem os perfis e necessidades mais diferenciados, enquanto que as demais, Natal Watch e Watch Center, possuem perfis e necessidades semelhantes. Por esse motivo, as empresas foram agrupadas de acordo com suas necessidades, resultando nos seguintes grupos: Empresa 1 NJ Serviços, Empresa 2 Natal Watch e Watch Center e Empresa 3 NJ Relógios, assim referidas daqui em diante. O objetivo do plugin precisava estar de acordo com todas estas necessidades. A Empresa 1 deseja implantar um sistema eletrônico que seja de baixo custo, já a Empresa 2 dá prioridade à praticidade do programa, a Empresa 3 também prioriza a praticidade e, por já ter mais experiência com sistemas eletrônicos, destaca ainda a necessidade de disponibilizar para seus clientes o acompanhamento dos serviços em andamento na assitência. Para atender a essas três necessidades, o plugin precisaria, portanto: Ter baixo ou nenhum custo; Possuir uma interface amigável e prática;

18 16 Permitir que os clientes acompanhem seus serviços Arquitetura das informações Após o levantamento de dados, foi possível começar a pôr em prática o planejamento do produto. O primeiro passo foi fazer comparações entre os documentos recolhidos. A finalidade era analisar e filtrar quais dados esses documentos possuíam em comum e estabelecer o que era ou não relevante para o modelo a ser empregado no plugin. Pelo fato de a Empresas 1 (NJ Serviços) e Empresa 2 (Natal Watch e Watch Center) utilizarem o mesmo modelo de OS, foram dispostas em uma coluna única no quadro de OS: Quadro 2: Quadro comparativo entre os modelos de Ordens de Serviços TOPO DADOS OS DADOS CLIENTE DADOS PRODUTO DADOS OS EMPRESAS 1 E 2 EMPRESA 3 Plugin (Anexos A e B) (Anexo C) Logotipo Logotipo Banner Marcas trabalhadas Marcas trabalhadas Endereço Endereço Endereço Telefone Telefone Telefones (dois) Site Número de OS Número de OS Número de OS Garantia Tipo de OS Tipo de OS Data de Entrada Data de OS Data de Entrada Recepcionista - Autor - CPF RG/CPF - RG Nome Nome Nome Telefone Telefone Telefone - Telefone de Contato - Celular Celular Celular - - Telefone Comercial - Produto Tipo Marca Marca Marca Modelo Modelo Modelo Referência Referência Referência - Número de Série - - Nota Fiscal - Caixa Mostrador Características do Relógio Descrição do Produto Pulseira Códigos dos Defeitos Externos Condições do Relógio Características Externas Defeitos Externos Defeito Segundo o Cliente Serviço a Executar - - Total - - Sinal - - Defeitos Segundo o Defeito(s) Segundo o Cliente Cliente

19 17 Desconto - - Total Geral - - Resta - - Data de Orçamento - - Data de Entrega - - Informações Importantes Informações Importantes Informações Importantes Assinatura do Cliente Assinatura do Cliente Assinatura do Cliente - Data da Assinatura - - Horário de Funcionamento - Fonte: o autor O mesmo foi feito para as fichas de orçamento (Quadro 3). Dessa vez, a comparação é apenas entre a Empresa 2 e Empresa 3, já que a Empresa 1 não as utiliza. Quadro 3: Quadro comparativo entre as fichas de Orçamentos TOPO DADOS OS / ORÇAMENTO DADOS CLIENTE DADOS PRODUTO DADOS OS / ORÇAMENTO TABELA ORÇAMENTO EMPRESA 2 EMPRESA 3 (Anexo D) (Anexo E) Plugin Logotipo Logotipo Marcas trabalhadas Marcas trabalhadas Banner Endereço Endereço Endereço Telefone Telefone Telefone Site Número de OS Número de OS Número de OS Número de Orçamento Tipo de OS Tipo de OS - Data de OS - Data do Orçamento - Data de Orçamento - Nome Telefone - - Telefone de Contato - - Celular - Marca Marca - - Modelo - Referência Referência - - Produto - - Número de Série - - Nota Fiscal - - Defeitos Segundo o Cliente - - Características do Relógio - Calibre Calibre do Relógio - Causa do Mau Funcionamento - - Status do Orçamento - - Quantidade Quantidade Quantidade Revisão Geral Tipo Conserto Parcial Descrição Referência Cód. Referência / Serviço

20 18 DADOS OS / ORÇAMENTO - Marca - Essencial Opcional Opcional/Essencial Essencial - Valor - - Desconto Peça (R$) - - Serviço (R$) Valor (Item) Total (Item) Valor (Item) Total Total (Orçamento) Valor Total Desconto - - Valor Total - - Data de Entrega Tempo de Serviço Tempo de Serviço (dias) - - Garantia (meses) Validade do Orçamento (dias) - - Observações - - Forma de Pagamento - - Data de Autorização - - Assinatura - - Técnico - - Informações Importantes - - Fonte: o autor Levando em consideração que os modelos de OS e orçamento recolhidos são específicos para relógios, alguns títulos foram adicionados, retirados ou renomeados para que o plugin fosse o mais universal possível, não restringindo a instalação e utilização apenas para assistências técnicas desse tipo de produto. A partir dos dados que deveriam estar presentes no modelo do plugin, foi possível estruturar quais eram os principais formulários e páginas a serem desenvolvidas. Em seguida, partir para a construção do wireframe. Pontos elementares: Formulários de cadastro das OS e dos orçamentos; Versão de impressão das OS e dos orçamentos; Possibilidade de consulta e edição de dados inseridos previamente; Formulário de configurações onde a empresa pudesse inserir seus dados para serem exibidos nas versões de impressão. A criação dessas páginas unicamente, não seria interessante para a Empresa 3, já que ela focou na necessidade de atualização e acompanhamento dos serviços pelos clientes. Ou seja, a disponibilidade de um status para cada OS. Da forma descrita acima, o status que poderia ser acompanhado por eles se resumiria apenas a Aguardando Orçamento, o que era

21 19 insuficiente para um acompanhamento funcional. Por isso, mais alguns pontos fundamentais precisaram ser levados em consideração: Desenvolver um método que especificasse melhor o andamento dos serviços; A assistência precisa ter um controle entre os produtos que estão em sua posse e os que já foram entregues tendo sido o serviço executado ou não; Criar um formulário com dados referentes ao pagamento para serem exibidos quando a OS for encerrada Os status Para entender como deveriam funcionar os status, foi preciso a percepção de dois fatores. O primeiro se refere ao conhecimento de todo o processo realizado pelos produtos dentro das assistências técnicas. Desde a entrada até o processo de finalização, quando o produto é entregue ao cliente e/ou é efetuado o pagamento. O segundo foi analisar quais são as respostas que, de acordo com o processo do serviço de cada OS, a assistência passava para um cliente que supostamente ligasse e quisesse saber o andamento do seu serviço. A partir disso as frases foram elaboradas, estabelecendo padrões dessas respostas, com a finalidade de estabelecer uma melhor comunicação entre a assistência, o plugin e o cliente. O status varia para cada Ordem de Serviço. A troca desse status deve ocorrer através do plugin e de acordo com uma comunicação prévia entre a assistência e o cliente. Padrões de status adotados: Aguardando Orçamento; Aguardando Autorização; Serviço em Execução; Orçamento Reprovado; Aguardando Retirada; Serviço Reprovado; Aguardando Faturamento; OS Finalizada Wireframe Nesse processo, foi importante ressaltar a necessidade da Empresa 2 e da Empresa 3 de que o sistema fosse prático e de fácil assimilação. Por isso, foram planejados formulários clean onde as informações são bem dispostas e com bom espaçamento entre elas. O software utilizado para o início deste processo foi o Mockflow, mas pelo limite imposto de

22 20 apenas quatro páginas por projeto, os esboços foram reaproveitados e redesenhados no Adobe Illustrator CS6. O mais conveniente no design do plugin, era que sua aparência estivesse de acordo com toda a interface do Wordpress. Dessa maneira, o wireframe foi todo elaborado de forma que a estrutura e o visual se assemelhassem ao máximo aos utilizados nas páginas da plataforma e pelos outros plugins. Os campos de informações foram desenhados com espaços amplos para que todos os dados inseridos tivessem uma boa visibilidade, não sendo escondidos, no caso de textos mais extensos (Figura 1). A disposição dos botões, as mensagens e o destaque, quando necessário, são bastante objetivos para não haver confusão na hora de inserir os dados. Figura 2: Esboço da interface para cadastro de OS Fonte: o autor

23 21 Para as versões de impressão, o número da OS foi destacado por uma cor de fundo diferente (Figura 2). Levou-se em consideração que este precisava ser de rápido acesso e localização, já que ele é o principal dado no acesso ao andamento do serviço. Figura 3: Esboço da versão de impressão das OS Fonte: o autor A continuação do wireframe está disponível como Apêndice A Tabelas Com o wireframe pronto, as estruturas das tabelas começaram as ser confeccionadas. De início, quatro tabelas haviam sido consideradas essenciais: uma para cada formulário da OS (cadastro, orçamento e pagamento) e outra para a página Configurações. Na prática, essa esquematização não funcionava e essa quantidade era desnecessária. Por isso, só duas tabelas precisaram essencialmente ser criadas: uma para as OS (Tabela 1) e outra para os itens dos orçamentos (Tabela 2). Os dados de pagamentos e os dados do formulário de orçamento que só precisam ser inseridos uma vez (datas, valores totais, etc.) foram inseridos na tabela de OS. A outra tabela ficou exclusivamente para os itens da ficha de orçamento.

24 22 Tabela 1: Demonstração das colunas da tabela de OS NOME DA COLUNA id_os tipo_os status_os data_entrada autor_os cpf_cliente_os rg_cliente_os nome_cliente_os _cliente_os ender_cliente_os tel_princ_cliente_os tel_cel_cliente_os tel_com_cliente_os tipo_prod_os marca_prod_os ref_prod_os mod_prod_os desc_prod_os carac_prod_os def_prod_os data_orcam valor_total dias_serv tempo_garantia descon_pag valor_final forma_pag desc_pag nome_pag cpf_pag receb_pag data_pag wp_wot_os TIPO int(10) int(2) int(2) datetime varchar(15) varchar(20) varchar(20) varchar(150) varchar(150) varchar(150) varchar(50) varchar(50) varchar(50) varchar(10) varchar(10) varchar(10) varchar(10) varchar(250) varchar(250) varchar(250) datetime double(10,2) int(5) int(5) double(10,2) double(10,2) varchar(50) varchar(50) varchar(150) varchar(20) varchar(15) datetime Fonte: o autor Tabela 2: Demonstração das colunas da tabela de orçamento NOME DA COLUNA id_orcamento num_os qtd_serv desc_serv wp_wot_orc TIPO int(20) int(10) int(5) varchar(150)

25 23 e_o_serv val_peca val_serv val_total int(5) double(10,2) double(10,2) double(10,2) Fonte: o autor A tabela de Configurações foi excluída do projeto por dois motivos: O Wordpress disponibiliza códigos para inserir dados na tabela wp_options, que é voltada especialmente para esse tipo aplicação. Era inviável criar uma tabela com apenas uma linha de informações que viriam a ser editadas esporadicamente; 3.2 Desenvolvimento do plugin Front-end A estrutura e o estilo das páginas do plugin foram possíveis através de duas linguagens web: HTML e CSS, respectivamente. Nessa etapa, o wireframe e seus requisitos foram amplamente explorados no intuito de respeitar ao máximo o projeto inicial. No geral, algumas poucas alterações foram feitas a fim de melhorar ainda mais a organização e visibilidade das informações dispostas nas páginas. No início, os blocos de informações estavam estruturados através de <div>. Essa organização resultou em códigos HTML visualmente poluídos (Figura 3) e de difícil leitura, já que era preciso muitas divs para que a estruturação e estilização fossem adequadas. Em quase todas as divs, era preciso definir uma nova id e/ou classe para que se comportassem de forma independente uma das outras. Para que os quadros tivessem a mesma aparência das tabelas do Wordpress, foi necessário copiar os códigos de estilos destinados aos elementos da tag <table> na folha de estilos da plataforma e inseri-las no arquivo CSS do plugin, aplicando-as em cada id e/ou classe definida previamente no HTML. Isso fez com que a página CSS ficasse extensa e, de certo modo, repetida. Além desse fator, a aparência do plugin só estaria de acordo com a aparência do Wordpress da versão que estava sendo utilizada, trazendo um novo requisito: Utilizar, sempre que possível, a folha de estilos padrão do Wordpress. Dessa forma, o plugin se adequará às diferentes versões do sistema.

26 24 Figura 4: Comparação entre uma das linhas da tabela de dados do cliente Fonte: o autor Para cumprimento deste ponto, era necessário que as divs fossem trocadas pelas tags <table>, <thead>, <tr>, <tbody>, <th>, <td>, e em alguns casos <tfoot>. Isso possibilitou a utilização das ids e classes padrões da folha de estilos da plataforma e o cumprimento de que a aparência do plugin sempre se adequasse à aparência do painel administrativo. Com isso, o arquivo CSS próprio do plugin ficou destinado apenas para especificações especiais, como largura das tabelas e colunas, delimitações de margens e paddings etc. Além das tabelas, as ids e classes aplicadas nos botões e títulos também são as do próprio Wordpress. As tags para formulários <form> e <input> foram fundamentais. O método de cada formulário varia de acordo com suas necessidades em questão. Quanto aos inputs, foram

27 25 utilizados de diversos tipos: text, radio, checkbox, submit, button etc. Para alguns textos maiores, a tag utilizada foi <textarea>. Cada tipo foi empregado de forma que estivesse de acordo com a informação a ser inserida em cada campo e correspondesse à proposta do wireframe (Figura 4). Figura 5: Interface da página de cadastro de OS Fonte: o autor Para as versões de impressão da OS e orçamento, foi criada uma página de estilos específica. Através desta, é possível manipular quais dados devem ser exibidos ou não, e a forma como os elementos devem estar dispostos do documento. Para esconder algumas informações, foi importante o emprego da propriedade display. Uma das principais alterações das versões online para as impressas é a exibição do topo com os dados da empresa inseridos na página Configurações. Levando em consideração que estes dados podem variar de acordo com cada assistência, foi preciso prever quer alguns campos poderiam ficar em branco ou não serem preenchidos da forma pretendida pelo plugin. Para a imagem do banner, que poderia ter a resolução diferente da recomendada, valores de

28 26 width e height foram empregados na tag <img>. O resultado para o caso destas imagens diferenciadas é uma imagem desproporcional, mas exibidas completamente. Diferente de se tivesse sido utilizada a propriedade background-image. Figura 6: Exemplo de visualização de impressão da OS Fonte: o autor A mudança mais destacável entre o wireframe e a versão final foi com relação às telas de aprovação, execução e entrega. A ideia no início era que elas fossem exibidas através de lightbox. Porém, percebeu-se que para Ordens de Serviços que receberiam essas atualizações na página de consulta, não seria o ideal. A melhor forma encontrada foi produzir tabelas que tivessem a pergunta referente a cada processo e seus respectivos botões de respostas. Como a mesma estrutura foi utilizada nas três tabelas, e para evitar futuras confusões com relação ao processo em que a OS se encontra, foram estabelecidas cores diferentes (Figura 6). Dessa maneira, ao passar do tempo o usuário associaria a cor à pergunta. A interface da página principal também teve algumas alterações importantes. A página foi toda reestrutura a fim de resultar um visual atrativo. Assim como as outras, também foi planejada para se adequar às diversas resoluções (Figura 7).

29 27 Figura 7: Quadros usados para as etapas de aprovação, execução e entrega Fonte: o autor Figura 8: Demonstração de adequação da página principal Fonte: o autor Experiência do usuário Para melhorar a usabilidade da ferramenta, algumas interações foram inseridas nas páginas. A página principal do plugin exibe um quadro de saudação, onde além de dar as

30 28 boas-vindas, o usuário também é lembrado da possibilidade de disponibilizar aos seus clientes o acompanhamento dos serviços através da instalação do widget ou do shortcode. No intuito de tornar o processo de preenchimento dos formulários mais rápido, alguns campos são preenchidos automaticamente. Em alguns casos, o preenchimento se dá por meio de informações disponibilizadas pelo Wordpress quando a página é carregada, nos itens que são necessários o nome do atendente, é inserido o nome do atual usuário, por exemplo. Além disso, nos campos de valores os cálculos são executados instantaneamente. Isso foi possível através da utilização de códigos JavaScript e da biblioteca JQuery, que já vem incorporada automaticamente no Wordpress. A fórmula utilizada no formulário de orçamento é: quantidade * (valor da peça + valor do serviço = valor total. Já para o de faturamento: valor total desconto = valor final. Para que o plugin estivesse disposto a receber valores com vírgula, como é o padrão nacional, a utilização do replace() foi fundamental. Neste caso, o código troca a, inserida pelo. no momento da equação. Essa troca é importante já que o JavaScript faz os cálculos de acordo com o padrão internacional, que utiliza o. para números decimais Controle de erros O código JavaScript replace() também foi fundamental para evitar que alguns dados fossem inseridos de forma errônea no banco de dados. Através dele o usuário fica impossibilitado de inserir letras e símbolos em campos de números como CPF, RG e valores. Para que alguma informação importante não deixasse de ser inserida, foi utilizada a propriedade required do HTML5 nos inputs. Dessa forma, a OS só é cadastrada no sistema se todos estes campos importantes estiverem preenchidos, resultando em descrições mais detalhadas de clientes e produtos. Para as informações da empresa, que devem estar presentes na versão impressa da OS, foi preciso encontrar uma forma de estimular e lembrar o usuário de preenchê-las. Na página principal, o subtítulo do botão para a página de configurações é variável, caso os dados estejam devidamente preenchidos a mensagem é: Maravilha! Os dados da empresa estão devidamente preenchidos, do contrário: Você precisa preencher alguns dados importantes da empresa. Ainda para o caso de não estarem preenchidas, no momento em que a página de impressão é carregada, é exibida uma caixa de diálogo. Clicando em OK (Figura 8), o usuário é encaminhado para a página de configurações, se for em Cancelar, o processo continua normalmente.

31 29 Figura 9: Caixa de diálogo exibida na página de impressão caso os dados da empresa não estejam preenchidos Fonte: o autor Back-end A parte mais importante e talvez mais complexa na produção de um sistema é a de programação. É preciso compreender alguns conceitos básicos, como funciona a conexão das informações com o banco de dados, como as páginas devem se comportar em meio aos cliques dos botões. O entendimento de como funcionam alguns elementos são importantes, alguns deles: string, function, array, if, elseif, else, isset, echo, include etc. O trabalho na programação de um plugin Wordpress, não é diferente. A plataforma disponibiliza alguns códigos para tornar o desenvolvimento mais prático, entretanto, ainda é necessário dois tipos de fatores: Saber e entender programação em PHP; Consultar, sempre que possível, a documentação do Wordpress e a usabilidade para cada código da plataforma. O segundo ponto é essencial porque algumas vezes um código PHP não é válido dentro do sistema e é preciso entender como substituí-lo. Além disso, também são disponibilizadas algumas boas práticas para o desenvolvimento adequado. Esses dois fatores são importantes para prevenir o sistema de futuros bugs e torná-la cada vez mais confiável Informações básicas Para produção de plugins para o Wordpress, um dos primeiros passos é criar o arquivo principal, adicionar o código com dados triviais: nome, autor, descrição etc. e as principais páginas que o irão compor. É possível adicionar as páginas em algum menu já existente ou criar um novo e inseri-las dentro, varia de acordo com a necessidade. Os códigos utilizados

32 30 para isso são: add_menu_page e add_submenu_page. Estes códigos se encarregam de fazer a instalação das páginas no painel administrativo. Ao implantar os códigos de submenu, o Wordpress exige que sejam definidos os caminhos de cada um. Existem duas opções: o endereço do arquivo dentro da pasta do plugin, ou executar uma função que inclua este arquivo. De início, foi optada a primeira opção, entretanto, a terminação.php era exibida na URL, o que normalmente não acontecia com outros plugins. Por isso, foi então escolhida a segunda opção. Para aplicação de folhas de estilos e scripts, por recomendação do Wordpress, foram utilizados os códigos wp_register_style, wp_enqueue_style, wp_register_script e wp_enqueue_script. Foi preciso cautela ao utilizar esses códigos, pois eles fazem a instalação em toda a plataforma: se houverem nomes de ids e classes iguais com estilizações diferentes, por exemplo, pode causar problemas nas estruturas das páginas. Como já mencionado, para as versões de impressão de OS e orçamento, foi preciso desenvolver uma folha de estilo exclusiva. Para ativá-la apenas no comando de impressão e através da documentação do Wordpress, viu-se que é possível determinar no wp_enqueue_style qual o tipo de mídia que deverá ser empregado. Entretanto, o arquivo era chamado em todas as páginas. Para que ficasse limitado somente às essas páginas, o uso do if e da variável Wordpress $plugin_page foram fundamentais Criação de tabelas e SQL Com as tabelas desenhadas previamente, os códigos para criá-las foram adicionados no arquivo principal do plugin com suas devidas colunas, citadas anteriormente. O Wordpress aconselha que os títulos das tabelas sejam antecedidos pelo seu prefixo, que por padrão é wp_. Levando em consideração que este pode ser alterado no momento da instalação da plataforma, é recomendável a utilização do código $wpdb->prefix. Como já foi mencionado, para as informações da página de configurações não foi necessária a criação de uma nova tabela. O Wordpress disponibiliza a tabela wp_options, que é voltada especialmente para essas necessidades. A adição de dados nessa tabela se dá através do código add_option. De início, as informações dos campos Nome, e Site eram exibidas e editadas nas opções utilizadas na página Configurações > Geral do próprio Wordpress. Entretanto, para uma maior segurança, foram criadas novas opções para estes campos também (Quadro 4).

33 31 Quadro 4: Opções adicionadas na tabela wp_options NOME DA OPÇÃO wot_banner_empresa wot_nome_empresa wot_ender_empresa wot_tel1_empresa wot_tel2_empresa wot_ _empresa wot_site_empresa wot_info_empresa Fonte: o autor Para trabalhar com qualquer ação dentro do banco de dados, é preciso a utilização de alguns códigos que façam a conexão entre as páginas desejadas e ele. No Wordpress essa conexão já é feita durante a instalação. Por esse motivo, é disponibilizada a variável $wpdb, que permite inserir, exibir, editar e deletar dados de tabelas previamente criadas. Os dados inseridos na tabela wp_option são exibidos por meio do código get_option e update_option para atualizá-los Paginação A intenção do sistema desde o principio era que quando a OS fosse cadastrada, o usuário fosse encaminhado para as etapas posteriores. No caso dos serviços que, por algum motivo entre as etapas, precisasse aguardar e não pudessem ser executados na hora do cadastro, deveria haver a possibilidade de edição e atualização através da página de consulta. O fato de ter mais experiência com HTML induziu o pensamento de que a paginação de plugins era tão simples quanto a de um site, por exemplo. Onde cada página recebe uma URL diferente e o acesso entre elas é feito através de hiperlinks. Seguindo essa ideia, foi criada uma nova página para cada etapa do processo de cadastro das Ordens de Serviço. Inicialmente, a intenção era que as páginas dos submenus acessassem essas outras inseridas somente no diretório do plugin através do código plugin_url. Na prática, os problemas começaram a surgir. O Wordpress só insere em seu painel administrativo as páginas adicionadas como submenu. Fazer o link entre as páginas do submenu e as do diretório, era disfuncional. Isso porque as que não estavam inseridas no menu eram exibidas sem estilização e sem o painel de administração. Além disso, o acesso ao banco de dados era impossibilitado, já que a plataforma não reconhecia o arquivo endereçado como parte do painel administrativo.

34 32 Algumas pesquisas foram realizadas, a fim de compreender como fazer com que o plugin tivesse acesso a outras páginas que não estivessem incluídas no menu. Sem sucesso, alguns tópicos foram postados em fóruns de discussão voltados a desenvolvedores. Em um deles, foi sugerido que essas páginas fossem inseridas como submenus de um menu nulo, ou seja, estariam dentro do painel administrativo mas não seriam exibidas como opções de menu nenhum. Duas falhas foram percebidas nessa metodologia: ao serem acessadas, nenhum menu ficava ativo porque estas páginas eram independentes. Para mascarar este problema, a sugestão era utilizar códigos JavaScript para adicionar a classe wp-has-current no menu do plugin quando elas fossem acessadas. Entretanto, isso fazia com que só a cor de fundo fosse alterada, as opções do submenu continuavam escondidas, já que o menu não estava verdadeiramente selecionado. Além disso, os títulos das páginas era como se estivessem em branco. Devido à possibilidade de que esses dois fatores talvez causassem estranheza por parte do usuário, pareceu, portanto, não ser a forma correta de cumprimento da proposta. Neste momento, a solução foi, então, inserir todas as páginas como submenus e escondê-los do painel através de elementos do CSS. Dessa forma, as páginas teriam suas próprias URL para serem endereçadas, estariam sendo inseridas com o painel administrativo e não seriam exibidas como opções do menu. Até então, o código de inserção das informações da OS no banco de dados, estava presente na página endereçada pelo action do formulário. O problema era que, caso o usuário utilizasse o botão de atualizar nesta página, os dados eram inseridos novamente no banco, gerando assim, um novo número de OS. Além de confundir o usuário do plugin e o cliente, resultaria em uma tabela com informações repetidas desnecessariamente. Notou-se então que se os dados fossem inseridos através do clique do botão e não da página seguinte, o problema talvez fosse resolvido e esta outra página poderia ser atualizada livremente. Para isso, foi criada uma função PHP com os códigos de inserção, que deveria ser executada através da propriedade JavaScript onclick. A hipótese estava correta, o método não. O navegador não entendia que a função deveria ser executada apenas com no comando onclick e realizava dois inserts no banco: um em branco, quando a página era acessada, e outro com os dados inseridos, quando o botão era clicado. Também era preciso encontrar uma forma de enviar o número da atual OS para a página seguinte. Para que, dessa forma, através do SELECT ela pudesse exibir as informações equivalentes ao valor do ID que é o mesmo número da OS. Até este ponto, sabia-se que para

35 33 ter acesso ao ID da última linha inserida o Wordpress sugere a utilização do código $wpdb- >insert_id. Ainda faltava o meio. O método $_POST fora tentando previamente, mas sem sucesso. Entre estudos para ver como deveria ser este envio, descobriu-se o método $_SESSION. Na pesquisa para entender como funcionava no Wordpress, um dos resultados sugeria a utilização de um código específico no arquivo principal. Esse código fazia com que o dado inserido na variável só estivesse armazenado até o momento em que o usuário fizesse logout. Quando fosse feito login novamente, a variável estaria limpa, mesmo que fosse pela mesma conta. Depois de certo tempo, alguns problemas foram percebidos quanto ao método de paginação que estava sendo utilizado. Se cada página tivesse um endereço individual, elas poderiam ser acessadas facilmente pelo usuário através de suas respectivas URL. Isto não deveria acontecer pelo mesmo motivo que as páginas não poderiam ser exibidas como opções do menu. A página de faturamento, por exemplo, só deveria poder ser acessada através de cliques na página da OS, quando esta já tivesse passado por todas as outras fases. Portanto, era imprescindível que o conteúdo da página fosse alterado por cliques dos botões, não pelas URL. O que era um problema, já que tentativas anteriores foram falhas. Desde sempre, o ideal para a página de configurações era que todas as atualizações dos dados do formulário acontecessem através da própria página, ou seja, o caminho de destino o action deveria ser ela mesma. Tentou-se aqui também a utilização do onclick. Dessa vez, o problema era que quando o botão era ativado, ele recarregava a página com os dados antigos. Para que o(s) dado(s) que acabara(m) de ser atualizado(s) fosse(m) exibido(s), era preciso atualizar a página. O problema foi diferente do anterior por que neste caso a linha da tabela só deveria ser editada, e não inserida, como anteriormente. Analisando outros plugins, percebeu-se que é possível variar o conteúdo da página com cliques através do próprio PHP. Para a página de configurações, era preciso exibir uma mensagem de confirmação da atualização. Foram necessários os códigos $_POST, if e echo. Figura 10: Representação do código PHP utilizado para exibir conteúdo através de cliques de botões Fonte: o autor

36 34 O botão precisou ser do tipo submit e ter um name declarado. Com essa percepção, foi possível entender como deveria ser feito o controle de disponibilidade dos formulários. A criação de uma página que exibisse o conteúdo de todos os processos da OS todos os formulários e os quadros de aprovação, execução e entrega foi fundamental. Estes conteúdos deveriam variar de acordo com o status da OS em questão. Foi importante perceber que essa mesma página deveria ser acessada tanto no momento em que a OS fosse cadastrada, como quando o usuário quisesse vê-la e/ou editá-la na página de consulta. Para que elas tivessem acesso a esta página da OS, neste momento, o arquivo ainda fora inserido como submenu e o <li> escondido no CSS. Nesse passo, na página de cadastro, a forma encontrada para evitar a inserção duplicada foi: ao clicar o botão de Salvar, a função de inserção é executada, e em seguida o usuário é redirecionado para a página da OS. O redirecionamento é feito através do código header(); e até então o método utilizado para enviar o número da OS cadastrada para a página seguinte era o $_SESSION. Para os resultados das OS na página de consulta, a solução tinha sido a criação de um formulário para cada linha de resultado. Dentro desse formulário havia um input do tipo hidden com o número da OS. O número era então acessado pela outra página pelo $_POST. Problema: se, por acaso, a página fosse recarregada através do Enter na URL do navegador, os dados exibidos eram os do número da OS que estava no $_SESSION. Isso acontecia por que ao recarregar nesse modo, o navegador perde as informações da pagina anterior que estavam armazenadas em $_POST. A solução para este problema foi enviar o número da OS através do método $_GET, que envia os dados através da URL. Isso fez com que a página pudesse ficar sendo atualizada sem exibir alertas, e segura de que os dados exibidos na página pertenciam à OS desejada, a que está no endereço do navegador. Dessa forma, foi desnecessária a utilização do $_SESSION, e o $_POST ficou sendo utilizado apenas para o envio dos outros dados que não sejam o número da OS. Para que a página da OS não tivesse o mesmo problema de ser acessada através da URL, o submenu da página da OS foi excluído e sua função declarada com o include, no arquivo principal se manteve. A diferença é que ela passou a ser executada dentro das páginas de cadastro e consulta através dos seus respectivos botões, não como submenu.

37 35 Figura 11: Demonstração da paginação do plugin Fonte: o autor

38 Formulário de busca Na página de consulta, o usuário deve poder escolher que tipo de busca o formulário realizará. Através do número da OS, do CPF ou do nome cliente. O conteúdo desta página varia de acordo com alguns comandos, através da utilização dos códigos if, elseif e else. De forma que, se a busca for ativada as linhas da tabela estejam de acordo com o resultado desta, se não, são exibidas as últimas Ordens de Serviços inseridas no sistema. Melhorando assim, a acessibilidade do usuário. Para evitar repetições de códigos, o SELECT da busca foi composto através de algumas variáveis. Ativando a busca, carrega-se dentro de duas variáveis os valores fornecidos no formulário. Para uma melhor compreensão, as variáveis serão nomeadas por $a e $b. A variável $a se destina ao armazenamento do valor do option selecionado, a variável $b, o(s) dado(s) inserido(s) no campo input. Por organização, os valores dos option foram definidos por números. Dessa forma, os valores de $a só serão números. Para fazer o SELECT, esses números precisariam ser convertidos em nomes de colunas para serem empregados no WHERE. Os códigos if e elseif foram utilizados de acordo com a quantidade de opções. Dentro de cada um foi adicionada uma mesma variável $c e como valor está o nome da coluna referente à opção de busca selecionada pelo usuário. O SELECT utiliza, portanto, as variáveis $c e $b para realizar a busca. Figura 12: Representação da estrutura utilizada no formulário de busca Fonte: o autor Para que os filtros funcionassem de maneira correta, foi fundamental o emprego de dois símbolos de = dentro dos if e elseif. De início só havia um, e, portanto, o filtro não funcionava de forma adequada. Por exemplo, se a opção de CPF fosse selecionada, e no input o valor fosse o número de uma OS, a busca funcionava do mesmo jeito. Outro problema enfrentado foi com relação à busca por nome do cliente. Essa opção só foi possível através da troca do = por LIKE no código do SELECT, e inserindo o valor de $b entre dois símbolos de %. Para

39 37 ordenar os resultados de acordo com a ordem de OS inseridas, da mais nova à mais antiga, foi adicionado o código ORDER BY id DESC Atualização de status Os status das Ordens de Serviços são fundamentais para o bom funcionamento do plugin. Como já foi visto, é através dele é que é possível controlar o conteúdo a ser exibido na página da OS de acordo com a individualidade de cada serviço. Por esse motivo, o entendimento de como funciona a alteração desses status é fundamental para compreender o funcionamento do plugin. A atualização desses dados também é feita através do clique de botões, localizados estrategicamente em cada estágio da OS. Acontece quando o usuário clica para salvar as informações que acabaram de ser adicionadas. Pelo fato das verificações dos status serem constantemente exploradas no plugin, a melhor forma de inseri-las no banco de dados foi no formato INT. Quando o status precisa ser exibido ao usuário ou ao cliente da assistência, esse número é substituído por sua respectiva frase, através do uso de códigos if, elseif e echo. No caso da busca através do widget ou shortcode, cada status exibe também uma breve mensagem explicativa. São elas: Seu serviço está em análise; Por favor, aguarde mais um pouco; Aguardamos sua autorização para dar procedimento ao serviço. Favor entrar em contato; Estamos executando seu serviço. Por favor, aguarde mais um pouco; O orçamento foi reprovado. Caso queira saber mais, favor entrar em contato; Esperamos sua visita para retirada do produto; O técnico encontrou problemas na execução deste serviço. Para saber mais, favor entrar em contato; O serviço já foi efetuado e o produto entregue. Aguardamos o faturamento do serviço; O produto já foi entregue. Contamos com você para o seu próximo serviço. Durante os testes do plugin percebeu-se que, se por acaso os dados de algum formulário relacionado a um status antecedente ao atual fossem atualizados, o status da OS voltava a ser o referente ao daquele estágio, retrocedendo. Para evitar que isso acontecesse, foi necessário utilizar if e else declarando que esta alteração só deveria acontecer se o número atual do status fosse inferior ao número do status proposto no formulário, sendo igual ou maior, a atualização só aconteceria para os outros dados.

40 38 Figura 13: Fluxograma de alteração dos status Fonte: o autor

41 Widget e Shortcode A possibilidade de utilização dessas duas ferramentas foi essencial para o cumprimento total dos objetivos propostos pelo plugin. Essas aplicações possuem cargos bastante parecidos, a diferença está relacionada à forma de instalação e onde os dados deverão ser exibidos. Os widgets são mais utilizados com mais frequência em sidebars, enquanto os shortcodes, em páginas do site. A opção de usabilidade de cada um varia de acordo com a necessidade do usuário. Foi através dessas aplicações que o acompanhamento dos serviços por parte do cliente foi possível. Os códigos utilizados para ambas são bastante parecidos: após a instalação, é exibido no local desejado um formulário com dois campos: um para o código da OS e outro para CPF do cliente. Por segurança, ambos são obrigatórios. Após o clique do botão, é feita a checagem através do SELECT, e se a OS for localizada, é exibido o status e a mensagem explicativa; se não, uma mensagem de erro. Para adição dessas aplicações, o Wordpress disponibiliza alguns códigos. Os principais são: register_sidebar_widget e register_widget_control para os widgets e add_shortcode para os shortcodes. Após instaladas, o usuário pode estilizá-las de acordo com o tema utilizado através da id wot_busca. Figura 14: Exemplo do resultado de busca pelo widget na sidebar Fonte: o autor

42 40 Figura 15: Exemplo do resultado de busca pelo shortcode em uma página Fonte: o autor

43 41 4 CONSIDERAÇÕES FINAIS O plugin surge, em meio a outras opções de sistemas voltados para Ordens de Serviço, como uma solução para os diversificados tipos de necessidades de assistências técnicas. A compreensão dessas necessidades possibilitou a criação de uma ferramenta completa e com grandes vantagens sobre as concorrentes, sendo o primeiro plugin de Ordens de Serviços para Wordpress. Os benefícios no desenvolvimento deste trabalho se deram de diversas formas. Primeiro às assistências, que possuem agora uma nova configuração de sistema, que é fácil, de interface objetiva e permite o acompanhamento dos serviços pelos clientes, o que também é uma vantagem para eles. A ferramenta pode ser utilizada por qualquer desenvolvedor web, a facilidade de instalação e o fato de ter sido produzida a partir do Wordpress o CMS mais utilizado por eles possibilita o uso independente do nível de conhecimento na área. A produção desta ferramenta conseguiu atender os objetivos e justificativas iniciais. Através deste produto, foi possível dar os primeiros passos na aprendizagem de programação de sistemas. Muitas dúvidas foram respondidas e algumas novas curiosidades surgiram, impulsionando cada vez mais o crescimento profissional pessoal. A ferramenta foi publicada no GitHub para que qualquer pessoa tenha acesso e possa modificá-lo como preferir. A pretensão é que também seja disponibilizada no repositório de plugins do Wordpress na versão em inglês, e trabalhar em futuras versões do sistema, melhorando-a cada vez mais. Como já foi visto, o desenvolvimento se deu através de várias tentativas, principalmente no processo de programação. A falta de experiência com este tipo linguagem fez com que para cada necessidade do plugin fossem realizadas várias pesquisas e tentativas, entre erros e acertos, até chegar ao objetivo desejado. Alguns códigos mais específicos do PHP e do Wordpress necessitaram de um nível de conhecimento mais elevado, e por isso o aprofundamento da pesquisa precisou ser equitativamente maior. Acima de tudo, o plugin precisava ser seguro principalmente em relação ao acesso ao banco de dados. Por esse motivo, além de compreendidos, os códigos e a páginas precisavam ser constantemente testados. Tentava-se prever como o usuário captaria as informações da página e as possibilidades de acesso que poderiam ser executadas. O que nem sempre era rápido, já que os usuários possuem suas próprias formas de assimilações. Grande parte dos meios de estudo para este tipo de trabalho é em outros idiomas, desse modo, a compreensão

44 42 de alguns termos técnicos nem sempre era tão simples. Tudo foi estudado e encaminhado para que, no final, os objetivos propostos pelo projeto fossem cumpridos. Desse modo, a produção deste trabalho também contribui para guiar desenvolvedores que possuam pouca experiência na área de programação ou que tenham o mesmo tipo de dificuldade. Para cada erro deparado, foi preciso encontrar novas formas de resolvê-lo. No decorrer da produção, alguns elementos foram alterados no intuito de trazer melhorias à ferramenta, ou simplesmente porque a proposta inicial não funcionava. Isso foi importante para a percepção da importância de estar sempre disposto a seguir novas diretrizes no planejamento e desenvolvimento de qualquer produto.

45 43 REFERÊNCIAS CASTELLS, Manuel. A Galáxia Internet: reflexões sobre Internet, negócios e a sociedade. Rio de Janeiro: Jorge Zahar Ed., SOUSA, Daniela Justiniano. Web Services na integração de sistemas Disponível em < Acesso em 18 mar BUILDWITH. CMS Usage Statistics: Statistics for websites using CMS technologies Disponível em < Acesso em 6 ago FSF (América Latina). Fundação Software Livre América Latina. Liberdades essenciais do Software Livre Disponível em: < Acesso em 18 mar GAROFALO, Simone; ALIS, Gleidston. Cerceamento ou Acessibilidade: uma discussão sobre a documentação de software livre. Revista Texto Livre: Linguagem e Tecnologia. v.3, nº 2, Disponível em: < Acesso em 18 mar W3C. Consórcio World Wide Web. HTML. Disponível em: < Acesso em 19 mar GOODMAN, Danny. Dynamic HTML: The Definitive Reference. Sebastopol: O Reilley & Associates, Inc., SERRANO, Paulo Henrique; NICOLAU, Marcos. Interfaces Livres: Autonomia e Inclusão no Ciberespaço KYRNIN, Jennifer. DHTML or Dynamic HTML. Disponível em: < Acesso em 20 mar SHANNON, Ross. DHTML Explained Disponível em: < Acesso em 20 mar CARVALHO, Ana. Manual de Ferramentas da Web 2.0 para Professores. Lisboa: Direcção- Geral de Inovação e de Desenvolvimento Curricular do Ministério da Educação Disponível em: < Acesso em 20 mar AMOROSO, Danilo. O que é Web 2.0? Disponivel em: < Acesso em 20 mar

46 44 BENERS-LEE, Tim; CAILLIAU, Robert; LUOTONEN, Ari; NIELSEN, Henrik; SECRET, Arthur. The World Wide Web. Communications of the ACM. vol. 37. nº Disponível em: < Acesso em 20 mar Folha de S.Paulo. Entenda o que é a Web Disponível em: < Acesso em 20 mar CHAGAS, Fernando; CARVALHO, Cedric; SILVA, João. Um estudo sobre os sistemas de gerenciamento de conteúdo de código aberto Disponível em < Acesso em 20 mar HEDENGREN, Thord. Smashing WordPress: Beyond The Blog. Chichester: John Wiley & Sons Ltda., Wordpress. Plugin Resources. Disponível em: < Acesso em 20 mar BONDARI, Brian; GRIFFITHS, Everett. WordPress 3 Plugin Development Essentials: create your own powerful, interactive plugins to extend and add features to your WordPress site. Olton: Packt Publishing Ltd., MEMÓRIA, Felipe. Design para a Internet: projetando a experiência perfeita. Rio de Janeiro: Elsevier, GIL, Antonio Carlos. Métodos e técnicas de pesquisa social. 6. Ed. São Paulo: Atlas, 2011.

47 45 GLOSSÁRIO Briefing: termo utilizado constantemente por profissionais de publicidade e outros ramos relacionados. Trata-se da denominação para o tipo de pesquisa relacionada ao conhecimento mais aprofundado de uma empresa e de suas áreas de atuações, no intuito de desenvolver um produto final. Wireframe: esboço de telas que prevê espaçamentos e tamanhos para a confecção de algum projeto futuro. Algumas vezes o wireframe também esquemativa a relação entre as páginas. Termo utilizado com mais frequência por web designers e desenvolvedores de sistemas. Essa é a primeiro passo no processo de criação de produtos, a etapa seguinte é a de design.

48 46 APÊNDICES APÊNDICE A Wireframe do plugin Work Order Tracking Modelo da página principal

49 Modelo de formulário para cadastro de orçamento 47

50 48 Modelo de versão de orçamento impresso Modelo de formulário de faturamento

51 Modelo de página para localização de Ordens de Serviço 49