Planejando seu aplicativo

Introdução

Se você tem uma ideia para uma aplicação Web, você deve cuidadosamente planejá-lo antes de fazer qualquer código ou design. Isto irá parecer incrivelmente óbvio para a maioria das pessoas, mas é um ponto que não pode ser exagerado, se você está criando um aplicativo completamente novo ou adaptando um aplicativo existente. Este artigo trata dos principais conceitos para se manter em mente, como você planeja uma aplicação e como se preparar para a implementação.

Note que isto é algo de propósito simples, um fluxo de trabalho de proposta geral, desenhada para ajudar pessoas que estão começando; se você é um desenvolvedor experiente entao você provavelmente tem um fluxo de trabalho e práticas próprias para aplicar no desenvolvimento de aplicações Web, o que é bom.

Definindo objetivos

Para começar você deve descrever a funcionalidade que o aplicativo deve possuir e definir o público alvo da forma mais concisa possível, e você deve pensar sobre qual contexto/situação em que o seu público alvo poderia usar seu aplicativo. Para o meu simples aplicativo Location Finder, eu escrevi duas listas:

Funcionalidade

• Obter a localização do dispositivo com maior precisão possível
• Mostrar qual a localização em um Google map

Grupo de usuários

• Desenvolvedores que desejam aprender sobre aplicativos Web abertos e desenvolvimento para Firefox OS, provavelmente em um escritório ou no trem.
• Qualquer pessoa que deseja se descobrir onde estão, principalemente ao ar livre/longe de casa

Você deve fazer o aplicativo o mais simples possível; focando em conseguir fazer uma coisa—ou algumas coisas relacionadas—bem feita. Se você tem vários diferentes casos de uso que você deseja alcançar, você pode querer dividi-los em diferentes aplicativos. Seu aplicativo pode necessitar de uma experiência diferente em diferentes plataformas, então você pode precisar separar listas para um desktop e mobile (ou até mesmo tablet, TV, etc.)

Logo após, tente escrever um resumo amigável para o usuário sobre o seu aplicativo, que irá convencer as pessoas a baixá-lo e testá-lo. Se você pode resumi-lo em uma unica frase, então sua ideia é provavelmente é boa o suficiente para um aplicativo! Para o Location Finder, eu escrevi:

Location Finder usa a geolocalização para descobrir onde você está, e mapea o seu entorno usando a API do Google Maps.

OK, para um aplicativo puramente destinado a usuários finais, eu normalmente não deveria incluir os nomes das tecnologias; deverias ser algo como isto:

Location Finder descobre onde você está e mapea o seu entorno.

Mas já que o aplicativo é largamente destinado a ensinar desenvolvedores, eu decidi que estas informações poderiam ser úteis.

Esboçando o seu aplicativo

Já que você decidiu qual o objetivo e o público alvo do seu aplicativo,é sempre uma boa ideia começar com esboços em papel—tente desenhar diferentes telas para mostrar como o aplicativo deverá se parecer, e qual o fluxo de trabalho ele adotará quando o usuário utilizar seu aplicativo. Você provavelmente vai querer fazer diferentes esboços para desktop, mobile, tablet, TV, etc, se sua lista de funcionalidades requerer.

Em todo caso, inclua notas sobre os recursos gráficos, funções, etc. são necessárias para cada estágio, pois isso irá informar suas escolhar quando você iniciar os estágios de design e o desenvolvimento, e garante que você fique menos propenso a se esquecer de algo. Para o Location Finder, a funcionalidade é bem simples, então eu decidi que necessito apenas de um esboço:

Para um aplicativo mais complicado, você pode incluir multiplos esbolços de tela para mostrar a visualização principal, e então diferentes views representand diferentes fluxos que o usuário toma ao utilizar o aplicativo.

Can any program (be converted to) work as an open Web app?

Just about any page, program or site can work as an open Web app, as long as you keep in mind the advice we've already given above; keep it simple above all else. If an app is particularly complicated (such as a word processor or a large e-commerce platform), then it will not work as an app in all contexts, therefore you need to think about creating a different experience for say, mobile or tablet devices. For example, eBay's desktop site has advertisements, different search mechanisms, and a whole host of other features. The mobile version of the site, in comparison, hides most of the features and adverts, presenting just the most popular functions at the top of the interface, and minimizing the amount of keyboard interaction needed.

Google Docs is another interesting example to consider. The desktop site is a fully-functional word processor with lots of controls available, but this would be a nightmare to use on a mobile site, therefore the mobile version simply lets you read your documents, with a simple interface.

At this stage, have a think about how you will present the different versions. In most situations you will be able to use media queries to optimize the layout and functionality of your project for different browsers. However, if you have been given the task of creating a mobile app version of a heavy, legacy, enterprise desktop web site—or if the desktop and mobile experiences prove too radically different—bear in mind that you might be better off creating a separate mobile/tablet site or app.

Think about the technologies you need

Some people will fold this stage into the "Statement of Intent" stage above, but arguably it's often better to consider your functionality/layout completely separately from your technology. You should think about your functionality purely in terms of what's best for your users in the first instance, rather than trying to shoehorn a technology into a project because it's the latest, coolest, shiniest toy. Usually the simplest approach is the best.

We discuss such considerations in much more detail in our Developing Web Apps section, but in general you should think about the main functionality/requirements your app has, and the technologies that are likely to be best for implementing them. Examples of questions you should ask include:

• Do you need offline storage? If your application needs to persist data, you'd normally use a server-side language and database. If you want to continue using it when offline/installed on a device, you may well have to store data in a client-side storage mechanism, such as IndexedDB or localStorage.
• Do you want to play or manipulate media? You will probably need HTML5 features such as <canvas>, <video>, or <audio>.
• Do you want to obtain information from the device and its surroundings? You'll need to use one of the many available device APIs, such as the Battery Status API, Proximity API, or Device Orientation API.

Plano de teste

Outra coisa que é usualmente considerada óbvia mas que ás vezes não é levada é conta é teste. Você deve testar o mais cedo e frequentemente possível, erros fundamentais descobertos cedo podem salvar muito tempo e dinheiro do projeto futuramente quando muitas funcionalidades já foram desenvolvidas. Um plano geral de testes é parecido com este:

• Uma vez que você tenha escrito as declarações de funcionalidades e público alvo, compartilhe com colegas, amigos e família. Parece uma boa ideia inicialmente, ou parece ridiculo? Será que ela precisa de adaptações ou mudança de escopo?
• Compartilhe seus esboços para obter um feedback também. Algo óbvio está faltando? Algo deveria ser adicionado para dar significado à experiência?
• Depois, é quase sempre uma boa ideia criar um protótipo funcional que permita um teste de funcionalidades e interações. Selecione usuários reais fora do time de desenvolvimento para testar estas interações e veja o qual bem eles se saem. Se você não dispõe de um profissional em testes de usuário, não tem problemas—uma seleção de amigos e família é bom o suficiente, desde que você proponha os testes e questões corretas.
• Como você trabalha no desenvolvimento do aplicativo, repita o teste de usuário quantas vezes for necessário. Agora você está trabalhando com o aplicativo real, teste em diferentes navegadores e dispositivos que você puder, começando com o suporte à alvos primarios. Considere que é uma experiencia aceitável em cada navegador e dispositivo, e não apenas um teste normal de uso—veja a performance do aplicativo em situações de stress, em casos extremos como na entrada de dados maliciosos e em navegadores realmente velhos.
• Perto do fim do projeto, crie rigorosos testes de controle de qualidade de forma a eliminar todos os erros de ultima hora; erros que mordem o seu pescoço quando você menos espera.

Conclusion: points to consider

Hopefully this article will have given you most of what you need to consider before creating a successful open Web app. The list below provides a summary.

What is the purpose of your app?

Create a list of tasks, an idea for your app and the type of user you are targeting, and then write a goal statement: Define your app's purpose and the most important user in one sentence if possible. Example: A wish list creation tool for people who never do impulse shopping.

Focus on one main use case

It's possible that you cannot include all the tasks on your list in your goal statement. That is OK, because awesome apps — especially those for mobile — do one thing well. If your app is trying to do too many things, then think about splitting up the functionality over multiple apps. Although, if your application needs a lot of features to deliver its value, remember that you could consider delivering a Web app to desktop PCs only.

How will people use your app?

By now, you've identified your main use case, target users, and key features. Your main scenario should also consider the user environment in which your app is used. For example, a young mom with her baby at daycare might use your app to note a nice stroller (potential multi-tasking, pausing and continuing the task later). A different user might plan her next laptop purchase at home, in an armchair, without interruptions.

Concentrate on a few key features

Look at your task list again. Filter your list through the goal statement. If the tasks do not align with your goal statement, exclude them from your app. Describe each core task as a feature and then ask yourself, is this feature essential? Or is it nice-to-have but not required by the target user to complete the defined task? Be honest with yourself. If you end up with a short list of features, you are on the right track. Remember, the best apps usually do one thing well. Apps often fail not because they have too few features, but too many.

However, if you simply have to deliver a large feature set to reach your goal, consider making a desktop Web app your primary app and then offer a complementary mobile app with just the features and functions a user may need while away from their desk.

Sketch out your app

Once you have a few key interactions in mind, you can translate those steps into screens. You can sketch out the user flow, that is, what do your users go from one screen to another to complete a task. Think about the functionality of your app, and put the user interface elements that correspond to the most important interactions in the most prominent places. Think about how the screens will look on desktop versus tablet/mobile.

Required technologies

Look at your list of functionality, and make some notes about what technologies you will likely use to build those requirements.

Testing plan

Build a reasonable testing plan into your project plan, to reduce the chance of being hit by expensive unexpected surprises later on in the implementation stages.

See also

• Open Web apps
• Developing your Web app