Ideas for mobile, tablet, desktop or web for app that in a first step consists of lots of data entry?

Question

With a friend I am making an app that basically consists of one big calendar in which data can be entered. The app will be a sowing calendar which can be used to enter the months in which you are planting specific crops and will calculate when you can harvest, or vice versa. The idea is that once the data is entered the app shows you when to take next steps and the interactive information can be easily updated.

First we thought of developing a mobile app. The problem is that in the first step ("the initial data entry flow") the user needs to plough through and enter a lot of data about seeds and crops. We thought that this first step might not be mobile friendly since the screen is so small.

One idea we had is to use a web app for data entry, and then bring that data into a mobile app where it can be manipulated. Another idea is to just make a downloadable computer program or target tablets since the screens are larger. The thing we would like best is to make a mobile app.

Considering the fact that a lot of data needs to be entered initially, is it feasible to make a mobile app (e.g., by using a specific GUI-design)? And if not, what other platform would you recommend and why?

Answer 1

Web or Mobile?

This sounds like a really useful native mobile application as I'm guessing it will be notification-centric that will alert the user when action is required. Things to consider before diving into native mobile development:

• Will this be OS-agnostic (i.e. will it run on iOS, Android, and possibly even Windows devices)

• Will it be a universal binary (i.e. will it be built for both mobile and tablet, or only one or the other)

• Cost of development - iOS or Android developers can be expensive if you aren't doing this yourself. HTML/CSS can be cheaper as there's a bigger pool to draw from. Backend development will vary.

• Audience - who is this for? Is this for big farms, small farms, home farmers? What devices do they use and how will this be incorporated into their existing workflow?

• Extensions/integrations/3rd party tools - Since you are dealing with a huge library of data (I assume, given the plethora of plant types and growing systems) and have other natural data-integrations that I'm guessing would be useful (some kind of weather API for example), taking into account what integrations you will be using and which systems they work best with may ultimately decide the best system to develop for.

• Leveraging hardware - Will you be using any kind of hardware integrations (using a phone's camera or NFC capabilities, or the iPhone's M7 motion chip or new barometer for altitude measurements)? If yes, you may be pigeon-holed into whatever devices have the hardware you are utilizing and effectively eliminating a desktop application.

Naturally these are just a couple things to consider when deciding between web or native app and desktop or mobile/tablet. A lot of these are development concerns.

IA/UX

On the UX side of things, it sounds like you have a good grasp on what data the user will be required to enter. It would be very beneficial to draw this out in a user flow first to figure out what steps the user will take to achieve the end goal (and what that end goal really is). This should help inform the form elements the user will need to use for data entry.

Also, what types of data-entry can you automate or speed up? For example, if I have a bag of seeds, I could use my phone's camera to scan the barcode and have that run through an API to a seed database that could have suggested growing times, when to plant, specific notes to that seed and brand, lighting considerations, etc. Not sure if this exists, but if it does it may eliminate a lot of the form fields the user has to enter. Applying this to things like GPS could also speed up the data-entry process.

You may find you can auto-fill (or at least provide default values) for many fields in your data-entry that could have a significant impact on the user's experience.

Other Tidbits

It sounds like you are thinking about making this primarily a calendar view application. Have you considered making it more of a news feed or task management type of system? Just a thought, but if this is really dedicated to creating actionable tasks for future dates, framing this on a system like GTD may be a more practical approach then a strict calendar application. There could certainly be a read-only calendar view, but the default view would be more list view sorted by date.

Incorporating notifications for the user also seems like a very important step and requires notification and account settings, but that's a whole 'nother beast ;)

Good luck!

UPDATED BASED ON COMMENT

You may be able to get around having the users create an account if you only want them to be able to use it on one dedicated device and store and data locally to that device. That's pretty limiting though especially in this day and age where everyone expects their applications to run across devices and platforms.

For notifications, you'll have to think about when you want to notify users of actions. For example, it would be really nice to get a notification like "Your tomatoes are almost ready to harvest!" but do you want that to come a day before harvest day, a week before harvest day, or the day of? Do you want to have multiple notifications (one a week before and one on the day of)? What happens when you have 20 different crops? Do you really want your user to get multiple notifications everyday during harvest time? Also, do you want to control how often these are blasted out to the user, or do you want them to have control? Do you want to set defaults and then let them adjust as needed?

Notifications are tricky to get right, but are extremely useful if done properly. Try to put yourself in your users shoes and make your best guess. Then make a prototype and get it in the hands of someone in your target demographic and get feedback from them. Improve on your original prototype given that information.

Maybe the best advice is really figure out what the core application is and just get it out to users. Don't get caught in the weeds with all the additional functionality. Even if it's just a calculator app to begin with that focuses on growth times, that's better than a huge multifunctional calendar-project management alerting notifying crazy app that's forever under development.

Answer 2

Design for people not device.

You might prototype a few scenarios that involve mobile + desktop pairing. Wearable UXD is a good example of this paradigm.

Generally desktops are better for data entry. While mobile has the benefit of being always on the user.

Take something like Fitbit for example. The device is optimized for collecting data in an unobtrusive way and presenting concise 'nudge' messaging to bolster engagement and use. On the other side of the coin is the web based site where data is presented, entered and managed. This also makes things like account management, security, roles and other activities better suited for a desktop environment.

The point is to design for the human, not for the device. Do some research to see what devices are used, when and by whom. You might discover that creating the ability to delegate data-entry to an assistant is the key to success.

A little user research will go a long way.

Answer 3

I have also participated in a project involving large amount of data input on multiple types of devices. And our solution is using Responsive Web Design, so users can choose to input data on mobile, tablet or desktop, through accessing the same URL.

Also one thing we found is that although mobile devices are relatively small, users under certain circumstances, still choose to use mobile to input.

Hope it is helpful.