Need some insight from Mobile Applications FBGs (1 Viewer)

[Tiger Fan]

Turning to the FFA for some help here b/c I’m not exactly sure of the terminology on what to search for.

I’ve got an idea for an application that I believe could be a viable product. I’ve bounced this across a few potential customers/end users and that are in agreement with me. So, I’m doing all of my due diligence to put a cost model together and I need some steer from here.

Features (to the customer)

· Crisp, clear front end to end users, who would enter data that would feed into a back end database.

· The # of variables that would make up the entry needs to be dynamic…certain customers would only use some, where others could end up using a lot.

· Data Entry needs to be able to happen from ios, Android and web

· Clean, simple, easy to read reports – on demand, emailed on a recurring basis, etc.

Features (to the owner)

· Need to be able to create multiple customer accounts and customize the front end form (logo, fields, etc) to meet customers need

· Within each customer account, ability to create multiple users – potentially with different needs, access, etc.

· The reporting feature needs to be very robust – canned reports, customized reports, trends, benchmarks against industry, etc. And needs to be available on demand to me and customers

Out of the box vs. Customization?

· To a guy with some limited IT knowledge, I would assume that there are some out of the box applications available, but I could be wrong

I’m being intentionally vague on the specifics, but at it’s core, this is what I’m looking to do. Happy to answer questions and take suggestions/criticism. I greatly respect the power and knowledge of the FFA!

 

[Sarnoff]

Came up with an app idea the other night, simple idea, no clue how to implement it.

 

[Maelstrom]

The fact that you want it to be multi-platform means you likely want to investigate some of the mobile development platforms that can be used to develop for multiple platforms at once. Specifically, I'm thinking of the Cordova platform (recently known as PhoneGap), which allows a developer to use standard web technologies to build the app and then deploy it across multiple platforms. Lately a platform on top of Cordova called Ionic has been making some waves, allows for a nice UI that is very responsive to input and much quicker than the standard method of making web apps directly with Cordova.

This doesn't mean you don't need a mobile developer, while it uses web technologies, it is still something that you need knowledge of the mobile environment and how apps work in order to build the app. A developer you are looking for should also have knowledge of submitting to iTunes and Google Play, as well as deployment to the web if you want a standard web app as well.

I would consider hiring a designer to do the design, and a separate developer for development, it is often too much to ask to find a person who can do both well, and you'll make compromises in both areas with a single person a lot of times. There are rare people that can handle both, but it's relatively rare.

Ok, enough about the person/app, lets talk about process. Before you hire anyone, you should know the Information Architecture and have that documented. That means every step a user might take. For instance, a login screen. You have the login screen, but you'll also need a forgot password screen, a confirmation for the forgot password, and forgot password "no matching user found" error screen.

You can map this out with sketches or post-its. Post-its are good because you can work out each "screen" of your app on a wall, with each post-it representing a screen. If you can't see a way to get from one screen to another, then you need another screen. They are also good because being small it contrains what you can have on each screen as well, just like in a mobile screen.

So, here are the steps to implement an app, from a business person's point of view:

1. idea (yay, you have this)
2. test the idea by talking to some people about it, figure out if it's viable, etc
3. architect the workflow You can do it like I described above, you may at some point want to hire someone who specializes in IA to review it and make suggestions, better to do that BEFORE you start building rather than after, as it's much easier to do when you don't have to redo work in the app itself
4. This workflow will determine whether your app is "easy" or "hard" to use, confusing, etc. Once you have it "done", test it by making up some sample tasks and having people show how they might do those tasks, while talking out loud about what they are thinking about. You'll find points where you're missing steps or adding steps that don't matter by simple tests like this. You only need maybe 5 people to get a decent idea if you are on the right path, but you might repeat this a few times before you move on to the next step.
5. Very important to get this right.

[*]find a designer to design the screens you laid out, brand the app, your business, etc.

1. If you find a mobile developer, they may be able to suggest interface changes to your workflow that can be combined into a single screen, don't forget to retest if significant changes are made to the interface during design
2. design for an app isn't the same as design for the web, even a web interface. It may be better to develop the two interfaces seperately

[*]find a developer or more likely, 2 - one for the server/database/api and one to implement the design

1. You may want a developer that can setup an API and your database structure, these skills are going to be quite a bit different than a person to implement the design.
2. You definitely want an API that each of the apps and the web can access, rather than tying each directly to the database. Don't accept otherwise for this kind of multi-platform development.
3. You will want to make sure to include in the requirements an administration console for you to mange your app data, access non-public reports about it, manage users, etc.
4. implement the design and access the API via the apps. Again, a good developer may have ideas to simplify the workflow, and will also likely find areas where there are steps missing. Test again if significant changes are made.
5. Demand on a quality assurance/user acceptance testing phase, with the understanding that part of development includes fixing any bugs found during this phase.

[*]submit to the stores (make sure to leave 1-3 weeks for Apple to approve the app for iTunes, Google Play is usually available in less than 24 hours)
[*]Advertise the app (just being in the store is NOT enough, you need PR, advertising, or direct sales to get the word out)
Hope that helps, kind of a stream of consciousness - I may clean this up a bit more and post it to my blog and if so, I'll post the link here for the cleaned up version.

 

[Tiger Fan]

Wow, awesome info there. More than I could've hoped for.

Going to digest everything over the next few days and post some thoughts.

Thanks again!

 

[Maelstrom]

Wow, awesome info there. More than I could've hoped for.

Going to digest everything over the next few days and post some thoughts.

Thanks again!

No problem, it's what I do. Granted, I'm the "developer" in that scenario, but if you are in my industry (work at a digital agency) and pay attention a little, you know the process.

Feel free to PM questions and I'll answer as I'm able.

 

[Paulymaggs]

Surprised there isn't a off the shelf solution for this sort of thing by now.

 

[Maelstrom]

Surprised there isn't a off the shelf solution for this sort of thing by now.

Why? This stuff is a lot harder than anyone wants to give credit for. Many apps take months of planning and development.

The average cost to develop a mobile app is anywhere from $5k to $150k - cheapest equals outsourced, then freelance, then agency/dev shop - http://www.quora.com/How-much-does-it-cost-to-build-an-iPhone-app

 

[Tiger Fan]

Wow, awesome info there. More than I could've hoped for.

Going to digest everything over the next few days and post some thoughts.

Thanks again!

No problem, it's what I do. Granted, I'm the "developer" in that scenario, but if you are in my industry (work at a digital agency) and pay attention a little, you know the process.

Feel free to PM questions and I'll answer as I'm able.

Here's what I've got so far:

The fact that you want it to be multi-platform means you likely want to investigate some of the mobile development platforms that can be used to develop for multiple platforms at once. Specifically, I'm thinking of the Cordova platform (recently known as PhoneGap), which allows a developer to use standard web technologies to build the app and then deploy it across multiple platforms. Lately a platform on top of Cordova called Ionic has been making some waves, allows for a nice UI that is very responsive to input and much quicker than the standard method of making web apps directly with Cordova.

• What the ideal development platform choice be any different if I wanted to roll it out first on iOS/web and then later to android? Or better to just develop it all upfront with the expectation that there would be subsequent rollout?
• What’s the cost premium (% basis) I could expect by doing both mobile platforms at once vs. one at a time (ios first and upon proven concept android) – just my gut feel here

A developer you are looking for should also have knowledge of submitting to iTunes and Google Play, as well as deployment to the web if you want a standard web app as well.

• With respect to submitting to iTunes and Google Play Is this only important if you’re looking for a vast # of people to purchase the app? I probably wasn’t clear in my initial post, but the app would be B2B and would require me selling the service in person. The app would be part included in part of the service….I wouldn’t just expect Joe Blow off the street to search for this and buy it.
• Does that change anything with the way it gets submitted and/or purchased?

I would consider hiring a designer to do the design, and a separate developer for development, it is often too much to ask to find a person who can do both well, and you'll make compromises in both areas with a single person a lot of times. There are rare people that can handle both, but it's relatively rare.

• Just to be clear, when you “hire a designer to do the design”, do you mean the actual graphic design and UI?

[SIZE=11pt]Ok, enough about the person/app, lets talk about process. Before you hire anyone, you should know the Information Architecture and have that documented. That means every step a user might take. For instance, a login screen. You have the login screen, but you'll also need a forgot password screen, a confirmation for the forgot password, and forgot password "no matching user found" error screen. [/SIZE]

[SIZE=11pt]You can map this out with sketches or post-its. Post-its are good because you can work out each "screen" of your app on a wall, with each post-it representing a screen. If you can't see a way to get from one screen to another, then you need another screen. They are also good because being small it constrains what you can have on each screen as well, just like in a mobile screen. [/SIZE]

• I’ve basically done this already at a high level. But not to the detail you mentioned. Dumb question, but is there any literature that you’re aware of that can walk you through this (at least at surface level)?

Still digesting the 2nd part of your post, but if you had to look at it cradle to grave, what's the single biggest cost driver in your mind? Layout, architecture, actual development, etc?

 

[[icon]]

Blackdot for feedback here. I've done multiple app designs and am in the process of building/launching one in medical field right now.

 

[DA RAIDERS]

.

 

[Maelstrom]

• What the ideal development platform choice be any different if I wanted to roll it out first on iOS/web and then later to android? Or better to just develop it all upfront with the expectation that there would be subsequent rollout?
• What’s the cost premium (% basis) I could expect by doing both mobile platforms at once vs. one at a time (ios first and upon proven concept android) – just my gut feel here

My personal feeling, particularly for B2B apps, is that a web based platform like what I described above is more than suitable, and will be much more affordable to have developed. It is also my personal feeling that web and mobile will tend to converge. A Cordova based app is not (yet) suitable for apps with a lot of animation or games, stuff like that. So with that, my personal recommendation is still along the same lines.

Cost for a standard Cordova web based mobile app (for a single platform) is likely to be, IMO, close to half that of a native app. The Ionic platform I mentioned adds a bit of complexity, in exchange for a significantly enhanced mobile experience, but likely only an additional 10%-20% because it also gains a significant amount of efficiency. Building with Cordova, there isn't a significant cost difference of developing the 2nd app immediately vs. at a later date, either way if programmed correctly there is almost nothing to do except build the app for the other platforms. Realistically, there are sometimes some bugs to work out on the various platforms, and working on multiple platforms at once can find and squash those bugs earlier rather than having it work on one platform perfectly and having to fix a bunch of bugs for the other one when you decide to add it (potentially breaking things on the first platform in the process that then need to be addressed). Overall though, I'd say you can develop for both platforms in this way cheaper than you could develop the same app for a single native platform.

With native, you are looking at maybe 175% of the cost of a single app to develop both, mainly because design assets can be reused. Of note: unlike iOS, Android assets need to be designed for a variety of phone sizes. There isn't really a lot of additional cost savings developing native apps at the same time except that if you hire a team to build them, they can potentially work out issues in the logic and such together and once, and then just apply it to each device. But in some ways the programming paradigm for each platform is different enough to make some of those discussions irrelevant. It can be easier to have an app done for one platform and then just say, here, copy this. And easier can potentially translate into cheaper.

• With respect to submitting to iTunes and Google Play Is this only important if you’re looking for a vast # of people to purchase the app? I probably wasn’t clear in my initial post, but the app would be B2B and would require me selling the service in person. The app would be part included in part of the service….I wouldn’t just expect Joe Blow off the street to search for this and buy it.
• Does that change anything with the way it gets submitted and/or purchased?

Yes, it does. You will still need to register with Apple to get a developer license, and they do have a program for B2B apps so you can still use iTunes to manage your app distribution. (https://developer.apple.com/programs/volume/b2b/) Only caveat is the same caveat of every developer of iOS apps in the store, if you charge for the app, I'm pretty sure you still give Apple 30%, even in the B2B program. But you could put the app as free and work out the payment separate from iTunes (check Apples TOS with your lawyer, of course, I am not a lawyer). But you control who has access to the apps, they don't have to be publicly available in the App Store. The businesses have some advantages also, in that they can manage on their end who can use the app as well. The other option with Apple is to develop the app as an ad-hoc app, but I'm pretty sure you only get 100 installs that way, and you have to manage installation and so on.

For Android, you can pretty easily skip the Play Store, and just provide the app to your business customers. Google does have a business portal where a business can upload apps for their employees, etc, but you'd have to work with each business because it is domain specific. And you'd have to make a custom build of your app for each business, which likely is not ideal. I'd recommend for Android you put it in the Play Store (as free) and just tell Google not to promote it, and then provide the link to your B2B clients while locking the app down via a login or verified user check in the app or something similar. Users, particularly businesses, may be a bit leary of having to sideload an app and turn off security settings on their phones in order to do so.

• Just to be clear, when you “hire a designer to do the design”, do you mean the actual graphic design and UI?

Yes, graphic design for the interface, not like design in the sense of design the user flow, app functionality, etc.

• Dumb question, but is there any literature that you’re aware of that can walk you through this (at least at surface level)?

Go pick up Don't Make Me Think by Steve Krug. It's more about web usability, I'm hoping he is working on a mobile version. But still, the principle apply. I have an older version, so can't specifically speak to this edition, but it was very good. I still think low tech is probably the easiest place to start, but there are tools like https://cacoo.com/ for when you need to make a workflow that can be sent to various team members, or if you just work better in a digital environment. Here is a book I found on Amazon that looks like a good primer in this subject of app interface - http://amzn.to/T6a5Ml, but I haven't read it so I can't specifically vouch for this one.

Biggest cost driveris probably actual development. I'd break it down like this (in percentages of your budget)

• IA/Planning - 10% - I don't want to sell information architecture short, they can give you some amazing insights and can challenge you and your ideas in ways you probably haven't thought of. But you can hammer out the basics if you can think logically about everything that is needed, and then have someone review what you've done.
• Design - 25% - Design is important, but your app working is even more important. Yes, I'm biased as a developer, but this number is also based on the number of hours in projects I've worked on that is allocated to design as compared to development.
• Development - 45% - Biggest cost driver, it takes time to build a solid app
• Testing - 15% - Don't skimp on testing, but you can also likely get friends/family to do some testing. If you do that though, make sure they are getting something out of it and that you have very specific test plans for them to follow or they will spend 5 minutes playing with app and say it's good. Provide tasks to accomplish to your testers and have them document any problems along the way. Having a good bug tracking system is very important (encourage your developer to use it during development as well for "todo's" and "known issues"
• Deployment - 5% - Make sure to alot some time for getting the apps ready to install.

 

[Tiger Fan]

Awesome info again Few clarifications on my end:

[SIZE=11pt]1. W[/SIZE][SIZE=11pt]hen you say "native" app, you mean mobile app for a single platform (ios or android), and not web based?[/SIZE]

[SIZE=11pt]2. [/SIZE][SIZE=11pt]Some of the key users will be "out in the field" so there needs to be some sort of input using a mobile device. They could be connected some of the time, but need to be able to have offline input, and then automatic sync/upload when a connection existed.[/SIZE] – still web over native with this info?

 

[Maelstrom]

Awesome info again Few clarifications on my end:

[SIZE=11pt]1. W[/SIZE][SIZE=11pt]hen you say "native" app, you mean mobile app for a single platform (ios or android), and not web based?[/SIZE]

[SIZE=11pt]2. [/SIZE][SIZE=11pt]Some of the key users will be "out in the field" so there needs to be some sort of input using a mobile device. They could be connected some of the time, but need to be able to have offline input, and then automatic sync/upload when a connection existed.[/SIZE] – still web over native with this info?

Yup, by native I mean built using Java (Android) or ObjectiveC/Swift (Apple), not using web technologies.

There is no reason an app built using web technologies won't work offline, but you should definitely make sure that is one of your specific requirements for your developer. They probably will need to use some form of "local storage" to store data, and build in a function that checks for connection and handles the syncing logic.

 

[Quez]

This has to be a very difficult business to make money in. It seems like there are so many apps that even if you have a good one someone will just rip it off.

 

[Maelstrom]

This has to be a very difficult business to make money in. It seems like there are so many apps that even if you have a good one someone will just rip it off.

Depends on what kind of app you make. The one Tiger Fan appears to be making would be tough to "rip off" because it won't likely be public in the store (or if it is, not marketed heavily outside of his vertical). From his description, I assume the businesses pay him for the right to use the app in some manner. Can build a really nice business that way.

But ya, if you make the next Candy Crush, you better make your money quickly because the flood of copy-cats will be right behind you. Not to say you can't make money with a commondity app, but it is a tough business to maintain, and you have to continue to be one step ahead of the copy cats.

 

[Tiger Fan]

Awesome info again Few clarifications on my end:

1. When you say "native" app, you mean mobile app for a single platform (ios or android), and not web based?

2. Some of the key users will be "out in the field" so there needs to be some sort of input using a mobile device. They could be connected some of the time, but need to be able to have offline input, and then automatic sync/upload when a connection existed. – still web over native with this info?

Yup, by native I mean built using Java (Android) or ObjectiveC/Swift (Apple), not using web technologies.

There is no reason an app built using web technologies won't work offline, but you should definitely make sure that is one of your specific requirements for your developer. They probably will need to use some form of "local storage" to store data, and build in a function that checks for connection and handles the syncing logic.

Thx

 

[Paulymaggs]

The fact that you want it to be multi-platform means you likely want to investigate some of the mobile development platforms that can be used to develop for multiple platforms at once. Specifically, I'm thinking of the Cordova platform (recently known as PhoneGap), which allows a developer to use standard web technologies to build the app and then deploy it across multiple platforms. Lately a platform on top of Cordova called Ionic has been making some waves, allows for a nice UI that is very responsive to input and much quicker than the standard method of making web apps directly with Cordova.

This doesn't mean you don't need a mobile developer, while it uses web technologies, it is still something that you need knowledge of the mobile environment and how apps work in order to build the app. A developer you are looking for should also have knowledge of submitting to iTunes and Google Play, as well as deployment to the web if you want a standard web app as well.

I would consider hiring a designer to do the design, and a separate developer for development, it is often too much to ask to find a person who can do both well, and you'll make compromises in both areas with a single person a lot of times. There are rare people that can handle both, but it's relatively rare.

Ok, enough about the person/app, lets talk about process. Before you hire anyone, you should know the Information Architecture and have that documented. That means every step a user might take. For instance, a login screen. You have the login screen, but you'll also need a forgot password screen, a confirmation for the forgot password, and forgot password "no matching user found" error screen.

You can map this out with sketches or post-its. Post-its are good because you can work out each "screen" of your app on a wall, with each post-it representing a screen. If you can't see a way to get from one screen to another, then you need another screen. They are also good because being small it contrains what you can have on each screen as well, just like in a mobile screen.

So, here are the steps to implement an app, from a business person's point of view:

1. idea (yay, you have this)
2. test the idea by talking to some people about it, figure out if it's viable, etc
3. architect the workflow You can do it like I described above, you may at some point want to hire someone who specializes in IA to review it and make suggestions, better to do that BEFORE you start building rather than after, as it's much easier to do when you don't have to redo work in the app itself
4. This workflow will determine whether your app is "easy" or "hard" to use, confusing, etc. Once you have it "done", test it by making up some sample tasks and having people show how they might do those tasks, while talking out loud about what they are thinking about. You'll find points where you're missing steps or adding steps that don't matter by simple tests like this. You only need maybe 5 people to get a decent idea if you are on the right path, but you might repeat this a few times before you move on to the next step.
5. Very important to get this right.

[*]find a designer to design the screens you laid out, brand the app, your business, etc.

1. If you find a mobile developer, they may be able to suggest interface changes to your workflow that can be combined into a single screen, don't forget to retest if significant changes are made to the interface during design
2. design for an app isn't the same as design for the web, even a web interface. It may be better to develop the two interfaces seperately

[*]find a developer or more likely, 2 - one for the server/database/api and one to implement the design

1. You may want a developer that can setup an API and your database structure, these skills are going to be quite a bit different than a person to implement the design.
2. You definitely want an API that each of the apps and the web can access, rather than tying each directly to the database. Don't accept otherwise for this kind of multi-platform development.
3. You will want to make sure to include in the requirements an administration console for you to mange your app data, access non-public reports about it, manage users, etc.
4. implement the design and access the API via the apps. Again, a good developer may have ideas to simplify the workflow, and will also likely find areas where there are steps missing. Test again if significant changes are made.
5. Demand on a quality assurance/user acceptance testing phase, with the understanding that part of development includes fixing any bugs found during this phase.

[*]submit to the stores (make sure to leave 1-3 weeks for Apple to approve the app for iTunes, Google Play is usually available in less than 24 hours)
[*]Advertise the app (just being in the store is NOT enough, you need PR, advertising, or direct sales to get the word out)
Hope that helps, kind of a stream of consciousness - I may clean this up a bit more and post it to my blog and if so, I'll post the link here for the cleaned up version.

A terrific post that needs the recognition that it deserves!

 

[Paulymaggs]

So what is this phonegap exactly?

Have read their faq but not totally getting what they mean when they continuously mention that they can only do "....HTML, CSS, and JS...."

Does this mean they can basically 'port' any website that doesn't have php directly to a app format via phonegap?

 

[Quez]

Google showed something off a few weeks ago that made making android apps very easy. It was all drag and drop, and very user friendly. I messed around with it for a second, and it was very easy.

 

[Paulymaggs]

"Mobile Version" of your website VS. App of your website ?

Is there any tangible benefits to doing the app of your website if a Mobile Version is perfectly adequate?

 

[[icon]]

"Mobile Version" of your website VS. App of your website ?

Is there any tangible benefits to doing the app of your website if a Mobile Version is perfectly adequate?

Very basic breakdown:

App Benefits:

• Pinpoint control of layout/design down to the pixel level

• Offline functionality when user isn't in service (depending on type of app)

• Near instant responsiveness / content loading

• Increased options with regards to client-side functionality

App Drawbacks:

• More expensive to develop (generally speaking)

• Often pricy to adapt to other platforms

---

Mobile/Repsonsive Website Benefits:

• Cheaper to develop

• Cross Platform

Website drawbacks

• Requires data connection

• Slower load times and responsiveness

• Subject to rendering dictated by browser, screen size, etc (may not look same/good on all devices/browsers).

• More reliant on server side for complex functionality

 

[Paulymaggs]

"Mobile Version" of your website VS. App of your website ?

Is there any tangible benefits to doing the app of your website if a Mobile Version is perfectly adequate?

Very basic breakdown:

App Benefits:

• Pinpoint control of layout/design down to the pixel level

• Offline functionality when user isn't in service (depending on type of app)

• Near instant responsiveness / content loading

• Increased options with regards to client-side functionality

App Drawbacks:

• More expensive to develop (generally speaking)

• Often pricy to adapt to other platforms

---

Mobile/Repsonsive Website Benefits:

• Cheaper to develop

• Cross Platform

Website drawbacks

• Requires data connection

• Slower load times and responsiveness

• Subject to rendering dictated by browser, screen size, etc (may not look same/good on all devices/browsers).

• More reliant on server side for complex functionality

Nice take.

 

[Maelstrom]

"Mobile Version" of your website VS. App of your website ?

Is there any tangible benefits to doing the app of your website if a Mobile Version is perfectly adequate?

Very basic breakdown:

App Benefits:

• Pinpoint control of layout/design down to the pixel level

• Offline functionality when user isn't in service (depending on type of app)

• Near instant responsiveness / content loading

• Increased options with regards to client-side functionality

App Drawbacks:

• More expensive to develop (generally speaking)

• Often pricy to adapt to other platforms

---

Mobile/Repsonsive Website Benefits:

• Cheaper to develop

• Cross Platform

Website drawbacks

• Requires data connection

• Slower load times and responsiveness

• Subject to rendering dictated by browser, screen size, etc (may not look same/good on all devices/browsers).

• More reliant on server side for complex functionality

That is pretty spot on, but I might argue that websites DO have the option for pinpoint control of layout and are getting closer to the same sort of responsiveness as apps with the advent of single page apps using things like Angular.

Also, there is the middle ground, Phonegap/Cordova allows for some of the advantages of an app, like allowing for offiline access and access to the phone hardware, but the easier development path of a website. It's a nice, quick way to get something up and running, to validate an idea. There are definitely reasons for building native apps, but it is going to be more expensive and probably take longer.

 

[Paulymaggs]

Oh, of course, if you DO have an actual App, you get to take advantage of the app eco system on both platforms.

We all know how rankings of apps snowballs on itself and there is almost no better marketing tool.

 

[Maelstrom]

Oh, of course, if you DO have an actual App, you get to take advantage of the app eco system on both platforms.

We all know how rankings of apps snowballs on itself and there is almost no better marketing tool.

Yup. One of the reasons that if it is a toss-up between mobile website and a hybrid app, you should seriously consider a hybrid app.

Of course, the website and app may serve vastly different markets, but if you are talking browser based app then yes, you should definitely consider what the app ecosystem can bring you.