Designing part 3 (Visual)

Let's look at our defined Must requirements first:

1. Scan for ingredients using the camera (Must)
2. Look up ingredients by searching (Must)
3. Have a valid datasource which I'm not the responsible for. (Must)
4. Support iOS 7 and above (Must)
5. Have multiple categories (profiles) to choose from. (Must)

Because the scanning functionality is the biggest and main function in this app I had this idea to give it a prominent place like in the Instagram app:

This would mean the app should have an UITabBar at the bottom with 5 UITab's. Which UITab's? Well, the following:

1. Profile

2. Search

3. Scan

4. History

5. More

As you can see I added the History functionality even though it was a Should in our requirements.

I had to if I wanted 5 UITab's and, with that, the center button the Scan tab.

Cool. Let's go designing!

As I'm actually done designing since I'm writing this after release I'll try to explain some design choices I made.

The profile screen is pretty straightforward. Which is actually the case with the whole app. I wanted to make the app as simple as possible. Solely for the reason that everyone could use the app without figuring out how to. And by everyone I mean literally everyone.

You choose a profile and on top it shows your selected profile. As you can see with the shadow underneath it, it is a button. When you press it you can customise that profile to your own needs.
Simple, clear, effective, done.

The search screen. Not much to design here really. Apart from one thing; the more info button.

Initially the idea was to have a banner on top of the screen that showed more info on the ingredient that you had to select in the list. But this couldn't be accomplished with a search function that should be already on top. Well, maybe it could, but not for the junior developer I am. Because when you type in the search field it shows a new UITableView on top of the current view, hence removing the banner we created.

So the solution was an info button on the right. When an user presses it a popup comes in screen with more info on the ingredient. It works the same for the search UITableView. Perfect.

The main function. I changed this layout more than I can remember.
The scanning consists of three steps. Take the photo, crop the photo and scan the photo. I could make a 'next' button on the top right, but in the end the way I did above seemed the most easy to comprehend as a new user to me.

Only one button is orange and active at each step with the simple internationally familiar numbers 1, 2 and 3. The title above tells in what step you are. No questions, right? Next.

The history screen. A few ways we could design this screen. Make it a list like in the search screen, a large banner as with the profile screen or photo's as in the photo's app that people are already familiar with.

A list was a no-go. As this is a history screen people should come here to look up old scannend ingredient lists. What would be the text we showed users to distinguish between other ingredientlists? The result? One ingredient of the many dozens? The date? No, no and no. You would had to intensively search before you found the ingredientlist you wanted.

The banners as in the profile screens would be to big and before you were at a few days old ingredientlist you would be scrolling until you lost your fingerprint. Nope that wouldn't do.

A screen like in the photo's app? Hmm, let's see:

- Users are already familiar with it

- You could fit 12 ingredientlists on first glance

- A thumbnail could show directly what it is

- A footer in the thumbnail could show the date for even better distinguishment.

Yep, that was the way to go.

The more screen is a simple UITableView with two items; Feedback and Disclosure.

But what about the matte greenish-orange theme? Well that's something that came later into play.

When I designed the app I did it in black and white. Colours were something I would think of later.
While programming I found this usefull library for buttons: https://github.com/herinkc/HTPressableButton

It had a library for colours in it and it looked really nice to my eyes. I tried the mint-colour for the headers and footers and was surprisingly pleased with the result, so I kept it. The orange (called bittersweet in the library) was a trial and error result. I tried different colours but that one was the most pleasing.

The font used is Helvetica Neue, simply because it gives eyegasmes when I look at it. So clear, and elegant. How could I not use it?

I also have a tutorial screen with custom backgrounds. Those backgrounds are provided by a good friend and professional photographer. However, she hasn't taken photo's she is proud of yet so they would come in an update.

Programming timeeee!

Designing part 2 (Requirements)

I'm gonna hold off to visual designing for a little longer. And the reason for that is that we haven't defined all the functionality yet in a more organised fashion.

How do we do that? Simple. By making a requirements list.

Note, that this is only common when a project is using the waterfall model for developing. Basically, in a waterfall model you finish each aspect of a project and move on to the next step only if you finished the previous one completely. In an agile project you do each step repeatedly for every few weeks (a sprint).

A requirements list is simply a list that defines all functionality the app requires. I prefer to sort it by using MoSCoW.

Now, let's make the list.

1. Scan for ingredients using the camera (Must)
2. Look up ingredients by searching (Must)
3. Have a valid datasource which I'm not the responsible for. (Must)
4. Support iOS 7 and above (Must)
5. Have multiple categories (profiles) to choose from. (Must)
6. Fast scanning (Should)
7. History (Should)
8. Supermarket searcher (Could)
9. Online portal to subscribe to custom categories users made. (Could)

The requirements list should be SMART. SMART stands for :

• Specific – target a specific area for improvement.
• Measurable – quantify or at least suggest an indicator of progress.
• Achievable – specify goals that are reachable.
• Realistic – state what results can realistically be achieved, given available resources.
• Time-related

A good rule of thumb to have in mind when making requirements SMART is that someone unrelated to the project should know what each requirement means and could interpreted it exactly as you mean it by just reading the requirement.

You can see that the supermarket searcher we had in our initial brainstorm session on paper has a Could specification. This is because I think it isn't that important while it would take a lot of time to integrate it.

Another thing to note is the valid datasource I don't want te be responsible for. This is because giving people advice on how to eat is a huge responsibility. Given the wrong advice, users could be in harm. That is not something I want to have on my back. Nor do I have the knowledge to give good advice. So the answer would be to look up the diets for each category/profile on the internet by known sources.

The reason to support iOS 7 and above was an easy decision. 

As you can see iOS 7 and above are on 97% of the phones. Adding support for only 3% would be a waste of developing resources as well as another important fact: the camera.

As you know by now the camera is an important factor in this app. Supporting < iOS 7 would mean supporting the iPhone 4 camera.

One of the bigger improvements in the iPhone 4S over its predecessor is the all-new camera. This is because besides an 8MP sensor, it also comes with a few other enhancements like an optical system with five-element lens (as opposed to four in the iPhone 4), wider f/2.4 aperture, improved back-side illumination and color accuracy, and last, but not least – faster operation

I'm not one for the megapixels when it comes to camera's as the quality of the photo has little to do with it, but in this case, where I have to examine each pixel on a photo up close to recognise text, it is most important. Supporting the iPhone 4 camera would mean less sharp photo's which on it's turn would mean worse recognition. Users would get angry for bad functionality and a bad app overall.
And that for only 3%? No thank you.

So now that we have the requirements, what comes next?

Visual design! (and no, I won't postpone it any more)

  

Designing part 1 (Initial start)

Before we start coding it is important to make it clear to our selfs what we are gonna build. A common mistake a lot of programmers make is that they jump right into the code without even knowing exactly what they want to build. They know the basic functionality of their idea, but they haven't given a thought about the rest of the app. What if you come across something later on? What if, while you're coding, you realise you could've done it in a different way and add more functionality.

Building an app requires attention to detail, thorough thought and strict rules. You need to think ahead so that when something goes wrong, you can anticipate in time.

If you jump into the sea without knowing how to swim, you'll drown. - Madeup Fromemythumb

So let's think about how to swim -or in this case, how to design our app-. And by designing i'm not talking about visual designing. I'm talking about functionality design; making it clear what we want and how we want it. Think of it like blueprints.

First let me tell you about my idea.

I'm Muslim myself (elhamdülillah) and something I encounter a lot in my near presence, is that when Muslims go shopping they need to check the ingredients-list on the back of the product for ingredients they are not allowed to consume. Most of the time it's pretty obvious, like pork meat. But there are these things called E-numbers. These numbers are predefined and show a generic way of an ingredient. For example, E300 stands for Ascorbice acid (Vitamine C). Not everyone knows what these E-numbers stand for and as there are a lot of E-numbers forbidden for Muslims, some aid would be helpfull. That's where my app comes in.

There are a lot of ways to help people with their shopping. One decision that was import for me to make was that the app should be easy to use. I want a large audience and this would mean that even old nanny's should be able to use the app.

And what's easier than taking a picture and telling you directly if you can eat it or not? Just take a picture of the ingredients list and by OCR the app is able to tell you if an ingrendient is blacklisted or not.

Now, the Muslims are a large enough public to aim for, but why not take it bigger? The functionality is there, so why not define several profiles besides Muslims? Exactly, why not.

So the app should have profiles like Muslims, Vegetarians, Lactose-intorelant, Sugar disease patients, etc.

And why stop there. Heck, let people customise their own profiles. Add ingredients (keywords) to your profile.

But what more can we add? Like I said, we need to think of all the functionality so we don't have to add it later and recode everything.

A list with all the ingredients so you can look it up? Check.

A local supermarket searcher? Why not. Check.

I think that's enough for an app. Let's get to the visual designing!

Welcome!

Hi people of the internet I'm currently developing an app for school and while it's not my first, I still find it a lot harder than I expected. I come across a lot of third party libraries, new API's, new best-practice models and better code in general in contrast to my previous experience with iOS. So I thought; Why not share this with others? A lot of problems I encounter are applicable to most developers and if I could help others that would help raise the quality of apps for everyone :D So in this blog I will share everything I come up against in my wild adventure of creating a diet-aid app (not gonna explain my app any further, you'll find out for yourself when you follow the blog :)). Without further ado, enjoy my blog!