Lesson video

Hi, everyone.

My name is Mrs. Welsh.

And today, we'll be starting our app development project.

This is lesson one of two, so don't worry if this is all new to you.

I'll be here to guide you through each step.

So let's get started.

Welcome to today's lesson from the unit Mobile App Development.

This lesson is called App Development Project Part One.

By the end of today, you'll be able to plan and build an app that includes user interaction.

Before we begin, let's have a look at some of those keywords.

User requirements, what the target audience wants in relation to the product, wireframe, a plan that outlines the basic structure and layout of the user interface, prototype, first version of an app that shows the design and basic features, but might not be fully functional yet.

So during today's lesson, we are going to be planning an app using design tools, describe what a prototype is, and creating the app screens.

So we're going to be starting with planning the app.

The app project scenario, the teachers at Oak Primary School have asked you to create a simple quiz app for their year-six pupils.

The app will be used as part of a transition day to help them revise key stage 2 topics and get them used to the technology used in secondary schools.

To understand what the app needs to include, the app developer needs to know the user needs, and these are called user requirements.

User requirements are a list of features or functions that the user wants in the app.

For the quiz app project, the user requirements are the features or functions that the primary school teachers and the pupils would like.

User requirements help the app developers stay focused on what the app needs.

They make sure the app is useful to the people who will use it.

User requirements focus on what the app should do, not how it should be built.

They provide a checklist, so you can evaluate the app when it is finished.

The app you are gonna be creating for the primary school must include at least seven screens, including a welcome screen, question screens, and a score screen.

It needs to include at least five text input questions, track the user score, be visually engaging, with colours or images, include working buttons for the navigation, and provide feedback at the end based on the score.

Let's have a look at a question.

Which of the following is the best example of a user requirement, A, the app should have a red background, B, the app must be fun to use, C, the app must have a screen that shows the user's score after they finish the quiz, D, the app should be made using App Lab? If you need to pause the video to read back through the question and decide upon your answer, do so now.

So what do you think it is, A, B, C, or D? If you said "C," you'd be correct.

We could say that A, B, and C are user requirements, because if they've said, "What has a red background?" That could be a user requirement.

It should be fun to use.

Again, it could be a user requirement.

However, we are looking for the best example, and C is the best example of a user requirement, because it's telling us exactly what it wants.

It's telling us what screen we need to have and what it needs to do.

So if you selected C, well done, that is the best example of a user requirement.

Developers will use what is called a wireframe to help plan an app before starting to build it.

A wireframe is a sketch of your app, and it shows the layout of each screen, including where buttons, text, and images will go.

And we've got an example here of what a wireframe could look like for a game.

We can see there it is really basic, it is got a title, it is telling us where the buttons are going to be, and it is giving us a very, very simplistic idea of what each screen is going to look like.

Wireframes are used to help the app developer think about how the user will navigate through the app.

Creating a wireframe can save time, as the app developer has a plan to follow.

If the layout doesn't look right in the wireframe, it can be fixed quickly.

Think about it, as it's a drawing, it's very easy to change the drawing or draw it out again rather than designing it in App Lab, for example, and then having to delete things, rename things, move things around.

App development teams and real companies use wireframes to plan before they build, and they may also take the wireframes to the users and ask them whether they think the layout is correct.

So they'll use the wireframes for lots of different jobs.

Let's have a look at a question.

What is the purpose of a wireframe, A, to plan how each screen will be arranged, B, to add colour to your app, C, to test the score system? If you need to pause the video now to read back through the question and decide upon your answer, do so now.

So what do you reckon? Is it A, B, or C? If you said, "A," you would be correct.

A wireframe is to plan how each screen will be arranged.

Let's move on.

Task A, using the user requirements from the Oak Primary School app request, draw a set of wireframe screens for the quiz app.

The wireframes to be created are the welcome screen, question screen, and a score screen.

Make sure to label all buttons, text inputs, and images.

If you need to Pause the video now to read back through the task and then to complete the wireframes, do so now.

Let's take a look at some possible designs.

So for the welcome screen, we have got a label at top for the screen title, a space for an image, and then space for the start button, and also space for the view high score button.

For the question screen, we have got a label for the quiz question, space for the image, space for the text input, and then space for the submit answer button.

And then for the score screen, again, we've got a label for the screen title, a label for the score, a feedback label, and then the restart quiz button.

So your designs might be slightly different, but as long as you have taken into consideration what the layout is gonna be for each of the screens, excellent job.

And we'll be utilising these wireframe sketches later on.

So moving on to describing what a prototype is, when creating an app, app developers will build a prototype.

A prototype is a test version of the app, and it can include the basic layout of the screens, and it may also include some navigation between the screens.

At this point, it is not a completely working version of the app, it is to give a rough idea of what the app may look like.

So prototypes are used to check that the screen layout makes sense.

App developers will use prototypes to get feedback from the users.

And using a prototype helps app developers find out if anything is missing or confusing.

Just think about it, if you built the whole app, and then took it to your user to get feedback, and they said, "No, we don't like it," you're gonna have wasted a lot of time developing an app, when you could have taken a prototype, and they could have said, "We don't like how this screen looks." And you could have changed it straight away before developing the whole app.

So true or false, a prototype should include fully working code? If you need to pause the video now to read through the question and decide upon your answer, do so now.

So what do we think, true or false? If you said, "False," you would be correct.

A prototype is a basic version of the app that shows the layout and navigation, not the full functionality.

So did you get that right? Excellent.

And let's move on.

So to create a prototype, you're going to use the wireframe designs created for the screens, use App Lab to create the main screens, so that would be the welcome screen, the question screen, and the score screen.

So, remember, what you need to do is go into your App Lab, and you're going to create a new project, and you'll see following screen, and make sure you are clicked in the Design view, so then you can drag and drop the elements onto the screen.

Make sure you create the three main screens, giving each of them a unique name.

So as we see there, we have got our welcome_screen, our question_screen, and our score_screen.

Let's have a look at a question.

What is the main purpose of creating a prototype before building a full app, A, to write all the final code first, B, to plan the app's layout and navigation before coding, C, to check the spelling of all the questions, D, to choose colours and fonts for the final version? If you need to pause the video now to read back through the question and decide upon your answer, do so now.

What do we think? Is it A, B, C, or D? If you said, "B," you'd be correct.

It is to plan the app's layout and navigation before coding, so you can have a look to see what the screen's gonna look like, created as an app, before going any further, so you can make any changes to the screen designs at this point.

So looking at task B, what I want you to do is to complete the sentence, a prototype is, and complete that sentence for me.

If you need to pause the video, so you can go and complete this task, you could do so now.

So what do you think? What is a prototype? A prototype is a basic version of the app that shows layout and navigation.

If you've written something similar describing a prototype, and you've included things like, "It just shows the layout, and it won't be a fully functioning app," or, "It won't have coding," if you've included things like that in your description, excellent, because that is exactly what a prototype does and does not include.

So good job.

And let's move on.

Part two, what I want you to do is match the description and tell me whether it is wireframe or prototype.

The descriptions we've got are a paper sketch of the app layout, a clickable version with working navigation buttons, helps test look and flow before final design, and uses tools like pens, paper, or digital drawing tools.

So if you need to pause the video, so you can complete the task, do so now.

What did we get for each one? A paper sketch of the app layout, it's using those keywords, that's a layout, and it's on paper, so that means it's going to be a wireframe.

Clickable version with working navigation buttons is gonna be prototype.

Tests the look and flow for final coding, again, prototype.

And use as tools like pens, paper, et cetera, this will be a wireframe.

So did you get all of those correct? The descriptions did give you clues as to which one it was going to be.

If you've got them all correct, excellent job.

And let's move on.

Part three, you are going to open up the starter project, and you're going to use your wireframes as a guide to create the welcome screen, the question screen, and the score screen.

And you need to make sure you are following your wireframe design.

After completing all the screens, part four is to review your prototype and make any changes needed to ensure the screens are suitable for the primary school pupils.

So if you need to pause the video, so you can go and complete the task, do so now.

Let's have a look at some possible screen designs.

From our prototype, we have got our welcome screen.

So we have got our label at the top, which is giving an idea about what the quiz is about.

We have got the image included there.

So at the moment, it is a blank image, because we haven't decided what images we are going to include.

And we have got our start button and our view high score button.

Screen layout looks okay.

So we are gonna stick with our original design.

Our question screen, again, we have kept the same format as our wireframe, with the label at the top, followed by the image, the text input, and the submit answer button.

And finally, for our score, we have got our label at the top, label for the score, feedback label, and our restart quiz button.

Your screens may look slightly different because they'll be based on your wireframes.

You may also have changed it after you have put it into App Lab and decided that you didn't like some of the layout.

But what you need to make sure you've got are three screens created with the basic elements that are going to be in there.

And if you've got all of that, you may even have put some of the navigation in there, just so you could click through to see how it would work.

Brilliant.

We are on our way to creating our app.

So for the final part of this lesson, we are going to create the app screens.

So if you remember, a good app is easy to use with a simple layout.

It has clear navigation with labelled buttons.

It looks good and uses suitable colours, images, and fonts.

It's functional, with working interactivity, and it's built for the user.

Images can make an app more engaging to the user.

They should suit the content of the app and help to enhance it.

App Lab allows you to upload images, but you must remember that all images you use must follow copyright rules.

So you can't just go copy and pasting out of a web browser.

You need to find a website that will allow you to use the images.

So to add an image to App Lab, the first thing I'm going to do is drag and drop the image element onto the app screen.

And the next thing you're going to do, in the PROPERTIES panel, you are going to go down to where it says, "Image," and you are going to click Choose.

And this is where we're going to select the image that's going to be displayed.

The next thing we're going to do is then upload an image you have got saved.

Prior to deciding you are going to use an image, you do need to go and find them and save them.

What we're going to do is click Upload File.

You will then go and find where the you have saved the image on your computer, select it, and then it will upload the file.

So as we can see here on this screenshot, I have got a little maths icon, which I have uploaded.

We can see the App Lab is telling me that my image was successfully uploaded.

And I can then choose this image to be displayed by clicking the Choose button.

And when I do that, it will display the image on my app screen.

And we can see, when we look at the PROPERTIES, we can see the image has now got the image file name in it.

But what we can also do are change some of the PROPERTIES, so we can make the image fit within the container, which is what I've done here.

You could add a board to it if you wished.

You could also drag and drop the image around to change the position of it, but also change the width and the height of it if you decided that it was too small.

So looking at a question, images should only be added to an app if they help the user understand or enjoy the app more.

So is that true or false? If you need to pause the video to read back through the question and decide on your answer, do so now.

What do we think, true or false? If you said, "True," you would be correct.

Images should only be added if they are going to enhance the app.

As it says there, the images should have a purpose, they can make the app more appealing or easier to understand.

Random or distracting images can actually make it harder to use.

It could also just be cluttering the screen when it's not needed.

So moving on.

When building your app, use the wireframe designs as a guide for the screen layout.

The wireframe can be used to check the layout of the buttons, text, and images, and the order of the screen.

Add the final content and code to your prototype to create the final app.

What we're doing now is using our prototype as the base to create our final app.

So we're going to add the rest of the content needed to create the full app onto our prototype.

When creating the app, you must follow the user requirements.

And remember, for the quiz app, the user requirements are that it must have seven screens, and this includes a welcome screen, the question screens, and a score screen.

It needs to have at least five text input questions, track the user score, be visually engaging, with colours or images, include working buttons for the navigation, and provide feedback at the end based on the score.

So let's have a look at another question.

Why is it important to follow the user requirements, is it A, so your app looks like somebody else's, B, so you don't have to test anything, C, so you can skip using wireframes, or D, so your app meets the user needs? So, again, if you need to pause the video to read back through the question and select your answer, do so now.

So what do we think? Is it A, B, C, or D? If you said, "D," you would be correct.

It is important to follow the user requirements, so our app meets the user needs.

And if you got that correct, brilliant, you have definitely understood the importance of user requirements and how they help us design an app.

For task C, part one, you're going to use your wireframe and your prototype to create the app screens, including the images and the quiz content.

So, remember, we need a welcome screen, five question screens, a score screen.

And for part two, you're gonna add the following navigation.

The welcome screen is gonna go to the question one screen, and the score screen is going to go to the welcome screen, and the question five screen is going to go to the score screen.

Okay, so that's the navigation that we need to add.

So they're the key navigation points.

Welcome screen is gonna go to question one, the score screen is gonna have a restart button to take them back to the welcome screen, and question five, being the final question in the app, is going to take the user to the score screen, so they can see how many questions they've got correct.

If you need to pause the video, so you can read back through the task, do so now.

Okay, let's take a look at a possible solution.

So we've got our screens designed, we've got the buttons to navigate to the correct screen.

So on the first screen, which is the welcome screen, we can see we've got our label, we've got an image, we've got a big green start button, and we've got our view high score button.

So all clearly labelled.

And we've got a background colour as well, just so we're not always looking at a white screen.

On our question one screen, again, we have got the question in a big, bold text, we've got a suitable image, the text box where we're going to input the answer, and again, a big green submit button, so we can't sort of miss it.

And then our score screen, we've got a label, got an image, and we've got the feedback label underneath, and again, we've got a big button, so we can restart the quiz from the beginning.

The code for the navigation, first one, we've got our onEvent for our start_button, and when that button is clicked, it is gonna set the screen to question one.

So that was the first part of our navigation.

The start screen goes into question one.

We've then got our onEvent for our high_score_button, and when we click the high_score_button, it is going to take us to the score screen.

And then we've also got our restart_button.

And when we click the restart_button, it is gonna send us back to the welcome screen.

So those are the three pieces of navigation we had to add at this point.

Have we got all that done? Have we got our screens all nicely formatted with the text colour, the images, and the working navigation? If so, excellent job, and let's move on.

And looking at today's summary, a wireframe is a plan that shows the structure and layout of each screen in an app.

Prototype is a basic version of an app that includes screens and navigation, but is not fully functional.

And the final app should be built by following both the wireframe and the prototype.

Thank you for joining me today for part one of our project.

We currently have our screens that are almost fully functional, and we can definitely jump between them using the buttons.

I hope you'll join me for the part two of this project, where we'll add the full functionality and complete the development of our app.

So, hopefully, I will see you next time.