Scoping a hybrid app - Agilis

Scoping a hybrid app

I’ve had cause recently to look into developing a hybrid app. I’ve got a few technical requirements – especially connecting to social network APIs and use GPS, both not uncommon to many apps that might be developed these days. It’s been interesting to look into what’s required, and how I can source a good team to design and develop what I need. I also need to estimate how much this thing is going to cost to make.

 

Scoping the project

The users

My first step when I scope a tech project is to think about what my users need to do. You do not need to be a technical wizard to do this, but you need to be able to visualise how a user might carry out an operation, and what kind of functions might be involved in achieving that task. Here’s a good list of some primary considerations for scoping any mobile orientated project:

  • What do my users need to do?
  • What do I need to communicate to my users?
  • How can I host any files that need accessing, uploading or downloading and what’s involved in that?
  • Are there any payment issues, if so, what’s involved?
  • How many users do I think I might have online concurrently (at the same time)?
  • Are most of my users on Android, or iPhone, or is it a mix? If so, this can mean either building two native apps, or one hybrid. Which is best?
  • How do my users access wifi, and how likely are they to spend their data allowance on using my app?
  • Do I need to connect to social networks, if so, what do my users need to do with those connections?
  • Do I need to consider data privacy, terms and conditions, security or other legal issues like copyright?

 

There are many other more detailed considerations, as you drill down into what your app is supposed to achieve, but this will get you thinking along the right lines.

The system

Once you’ve thought about the user issues, you can draw diagrams or flowcharts to picture more clearly how things fit together, for the front end, which they will see, and for the back end, which provides them with the functions and content they need. Again, here’s a couple of lists to get you started on this:

Front end

User tasks and functions
  • user personas – fun to draw your users!
  • register and log in
  • user profile area
  • primary user tasks – for example
    • browse other users
    • private message other users and receive messages
    • browse content, select and view specific content
    • upload files/download files
    • pay for downloads
    • share to social
    • get notifications, when, why
    • click on notifications to go to specific pages (interfaces)
    • make purchases, perhaps using a choice of methods

Back end

Database requirements and relationships
  • user details
  • consumption content storage and relationships
  • upload file storage and relationships
  • download file availability, data security
  • user payment details security and privacy
  • payment order details archiving and security
  • overall security checks and procedures
Analytics & Back up provision
  • analytics tracking
  • user behaviour tracking if required
  • regular back ups of all data
These lists are just a beginning, to map areas of consideration. Taking each area, depending on complexity, we then map it in more detail. Diagrams and flowcharts achieve this the best way, offering the most versatility for change and adaption, and by visualising what is actually going on, we see things that need to adapt, connect or change more quickly. If everyone sees this work, input from tech to design and vice versa can save a ton of problems or achieve greater simplicity and efficiency than if the teams work separately.

 

Cost

The advantages of an experienced company or freelancer cannot be underestimated, but cost might be potentially prohibitive for your purposes or budget. So what do I do, if I can’t afford to get ‘the real thing’ to develop my app? This choice can affect many aspects of the timeline for scoping, not just building the app. Experience can be the key here, but don’t exclude the young buck who is really enthusiastic and brimming with new ideas. For me (and my budget), an ideal small team is to have an experienced consultant on hand, for initial eyes on general approach and choice of platform(s) etc, plus in case the need arises for expert advice, should technical brick walls be encountered. Utilising the young bucks to design and build might create a few issues along the way but may also bring fresh design and simpler technical build to the project. It also brings the loyalty of young team members, which if you build apps or websites now and again, is really useful.

Summary

Hopefully this article might throw a bit of light and make things more straightforward when beginning a tech dev and design process. I wish you luck. It will never be a perfect process, but the planning is a vital part of the overall strategy. It’s the first step.

 

Helpful links

  1. http://cordova.apache.org/
  2. http://www.sitepoint.com/native-vs-hybrid-app-development/

 

Agilis is planning a course in Apache and Cordova for hybrid apps. If you’re interested, drop us a line.

 


Author: Pen Lister

Pen Lister is Academic Lead at Agilis, and has fifteen plus years in tech and new media, the last ten years spent lecturing at a London University. She’s now living in Malta, doing a PhD in augmented reality learning.
Copyright: This content is published courtesy of the kind permission of our guest bloggers in a non-exclusive rights arrangement, and articles may appear on our blog teams own websites in original or abridged form. All copyright is protected by author ownership.
Top