Now, before we write a single line of code,
we first need to plan this project,
because this one is a little bit more complex
than the other projects that we have been building.
So until now we have always simply started to code,
but without much thought about the features,
or the architecture before writing
the implementation itself.
I mean, we actually did use a flowchart a couple of times,
but I always simply provided that flow chart,
and we never did it together.
So we never planned an application together.
So in the real world, it's very important
that you always start with a planning phase
before building any project,
because otherwise you're setting yourself up
to a lot of confusion and problems down the road.
So to avoid all that, we will now do the planning
of the Mapty project together.
And so then you will get a feeling of how it works.
Now, there are many different ways of planning a project,
but I'm gonna show you my favorite process here,
which works great for many small and medium sized projects.
So I always like to start out
with a concept called User Stories.
And many companies, and teams use this idea
of user stories.
So you will see this everywhere when you start working
on a real developer job.
So a user story is basically a description
of the application's functionality
from the user's perspective.
And then all the user stories put together
will clearly describe the functionality
of the entire application.
So user stories are basically a high level overview
of the whole application, which will allow us developers
to determine the exact features that we need to implement
in order to make the user stories actually work as intended.
Then to visualize the different actions
that a user can take,
and how the program react to these actions,
we usually put all these features into a nice flow chart.
And again, we actually already used flow charts
in some other applications that we built before, right?
Now, once we know exactly what we're gonna build,
it's time to think about how we're gonna build it.
And this brings us to the project's architecture.
And in this context, architecture simply means
how we will organize our code, and what JavaScript features
we will use.
So the project's architecture is essentially what holds
all the code together.
It gives us a structure in which we can then develop
the application's functionality.
Now, my goal here is of course not to turn you
into a software architect.
The goal of this step is simply to stop and think about
how we will implement all this functionality.
So all these features before we actually do it.
Because we could implement any project
in a 1000 different ways.
So we could have one big file with no organization at all,
or we could divide everything into functions,
or we could use classes, or use multiple files,
or a mix of everything.
The possibilities are really endless.
So we have a lot of choice and all that choice
can sometimes be a problem.
And so if we don't think about the architecture
before writing the main part of our application,
then we will probably end up with a mess
of unmanageable spaghetti code.
And so that's not what we want.
But anyway, once we thought about
the project's architecture,
we are finally done with the planning step,
and are then ready to finally move on
to the development step.
And of course, this is where we're gonna implement
the plan that we created using JavaScript code.
So let's not plan the application that we're gonna build
in this section,
and so basically go through these four steps
of the planning step.
And we start with the user stories.
And remember a user story
is essentially a description
of the application's functionality
from the user's perspective.
And all user stories put together,
provide a clear picture
of the application's whole functionality.
Now there are multiple formats
in which we can write user stories,
but the most common one is to write sentences
with this format.
So as a certain type of user,
I want to perform a certain action so that I can get
a certain benefit.
And so this format of the user story answers the question,
who, what, and why.
Great, and so now applying this to our own Mapty project,
the first user story could go something like this.
So as a user, I want to log my running workouts
with location, distance, time, pace, and steps per minute,
so that I can keep a log of all my running.
So if we analyze the sentence,
then this clearly tells us who wants to perform
which action and why.
And then based on this, we will be able to plan
the application's necessary features in a next step.
So that as user story can basically be satisfied.
Next up, we can also say that as a user,
I want to log my cycling workouts with location, distance,
time, speed, and elevation gain,
so I can keep a log of all my cycling.
So this is similar to the first one,
but this one is regarding cycling
rather than running.
Next up as a user, I want to see all my workouts at a glance
so I can easily track my progress over time.
Then as a user, I also want to see all my workouts
on a map so I can easily check where I work out the most.
And finally, the last user story, which makes sense
for this application is that as a user,
I want to see all my workouts when I leave the app,
and come back later,
so that I can keep using the app over time.
Now, of course, we could have written these stories
in a different way, and certainly different people
will come up with different user stories
for the same application.
But what matters is that we can use user stories
to describe exactly what the application will do.
And I think that these user stories
do a pretty good job on that.
Now in this project, I actually already showed you
the working application in the last video, right?
But of course in the real world, you will be building
the application from scratch on your own.
And so therefore you will really have to think
as if you were the user and put yourself
in the user's feet so that you can come up
with these user stories,
and then build your features from there.
So let's not actually think about the features.
So here on the left side, we have a more boiled down version
of the user stories so that we can now work
on the features that the application should have,
and again, that is based on the user stories.
And based on this first user story,
we can already imagine a couple of features
that our application is gonna need.
So first we're gonna need a map where the user
can click in order to add a new workout.
That's because the user wants to log the workout
with the location.
And so therefore the best way
to get the location coordinates is gonna be
just clicking on a map.
Next, since we are working with maps, we should probably use
geolocation in order to display the map
at the current location of the user,
because this is a lot more user friendly than having
the user scroll to their current position, right?
So this is a perfect use case for geolocation,
and since all browsers on mobile and desktop
now support geolocation this will be a great addition
to our application.
Then of course, we're also gonna need a form
to input the rest of the data.
So the distance, the time, pace, and the steps per minute,
which is also called cadence.
So from the first user story alone
we could already know that we need these three features.
I mean, we don't really need them,
but they are nice to have because they allow us
to satisfy the user story.
And so let's now take a look at the second user story.
And so for this one, we're gonna need a form
that is very similar to the first one,
but this one has to ask for the elevation gain
instead of the steps per minute.
Then the user wants to see all the workouts at a glance,
and so therefore we're basically just gonna have a list
with all these workouts.
Then the user also wants to see them on a map,
and so therefore we will have a feature
basically displaying all the workouts on the map as well.
And lastly, the last user story basically says
that the workouts should of course persist over time.
And so there are multiple ways of doing that.
And so usually in a real world application,
you will have accounts where people's data then get stored.
But in this case here, since we are just building
a very simple application, all we're gonna do
is to store the workout data right in the browser.
And for that, we're gonna use a browser API
called local storage.
Then whenever the user comes back to the page,
we will read the data that was saved in a local storage,
and then display it both on the map,
and also on the list, okay?
And so these are the features
that we will have to implement,
and so let's now put them in our flow chart.
Now the flow chart should of course
contain these different features
that we're gonna implement,
but it's also gonna contain how the different parts
of the app interact with each other,
which event makes sense to implement,
and also how data flows across the application.
So let's now see the first couple of features
that we need to implement,
and that is geolocation to display the map
at the user's location,
and then to also display a map where the user can click
to add new workouts.
And this is how we could put them on the flow chart,
but let's actually think together about why
we put them like this on the flow chart.
So whenever we start to build a flow chart like this,
it's a good idea to start with events.
And so here in this case, I'm starting with the event
of the page loading, basically.
And so that's always a good event to start
the flow charts because of course that's always
the first event that basically occurs on any page.
I mean, it's not an event that we're gonna handle,
but as you know, all the code that is in the top level
will essentially be executed when the page loads.
And so we can count the page load as an event here as well.
So when the page does load, we want to start
by getting the user's location coordinates
using the geolocation API.
So just like we decided on in the last slide, right?
Then after that data arrives,
we want to then render the map basically centered
on the current location of the user.
Then we also already saw in the last slide that we need
a form to input the data for cycling and for running.
So we're gonna need to display a form,
and basically we will display that form,
or render that form whenever the user clicks
on a certain position on a map.
So here in this flow chart, as you see the yellow parts
are the actions, and the green parts is basically
when we render something on the user interface,
and in red I have marked operations
that happen asynchronously.
And what that means we will see in the next video.
Now, if the way that I'm building this flow chart here
is still confusing to you, then don't worry.
So in the future with more and more practice,
you will, of course be able to come up
with a flow chart like this on your own.
So just like everything in coding and programming,
this really is a matter of practice.
Now, just know that in the real world,
we usually don't always come up with all the steps
in the flow chart right in the planning phase.
So it's perfectly okay to just create a rough sketch
in the beginning here and then come up
with the exact detail during the implementation.
So definitely don't get hang up on building
the perfect flow chart, all right?
That's just not really necessary
in the beginning,
and so you should not waste too much time on this.
As you become better with practice, this will become easier,
and then you might be able to add more and more details
to your flow charts, right at the beginning.
But when you're just starting out and working
on your first applications, then don't stress
too much on this.
All right, but anyway, let's continue
with our features here.
So next up we want to display workouts in a list
and on the map.
And so therefore this is what our flow chart
is gonna look like.
So basically we rendered the form in step three and four,
and then we're going to have an event listener
on that form.
And so then whenever the user submits in your workout,
it is gonna be rendered on the map and on the list,
in steps five and six.
Then remember we want to store this workout data
in the browser and then read that data
whenever the page reloads.
And so what's gonna happen here
is that also whenever a user creates a new workout,
it will store all the workouts in local storage.
So we're using that local storage API in the browser
that I just mentioned in the last slide.
Then whenever the page loads,
as we see here on the left side of the flow chart,
then we get all of the workouts from local storage,
and render them on the map and on the list.
And of course that can only happen
after the current location has been fetched,
and a map has been displayed.
And so that's essentially what async means.
So that red box up there means that it is an operation
that takes some time, and only after it's completed,
then the rest of the operations that depend on it
can be executed.
And finally, there is another feature
that I didn't mention in the last slide,
but with just a nice addition
to the way the application works.
And so that is to simply move the map
to the workout location,
whenever we click on one on the workouts in the list.
And so here in the flowchart,
that is also pretty easy to represent.
And so basically all we need is an event handler
on the list.
And then whenever the user clicks on a workout in the list,
it will move to that workout's location, all right?
And so this is essentially how our application
is gonna work.
And so the features that we need to implement
using this flow and this sequence basically.
Now keep in mind that this flow chart itself
actually has nothing to do yet,
with the implementation itself.
So this is just how the program is gonna work.
And we might very well implemented in some other language,
so it wouldn't even have to be JavaScript.
So essentially this is only what our program should do,
but not how it does it.
So that's more specific and that's actually
for the architecture.
And so that brings us to the last part
of this planning step, which is, in fact, architecture.
Now just like the flow chart, we don't always need to have
the perfect final architecture
figured out before implementation.
So we can first do some experiments,
play around with the code, and only then,
think about the architecture for the final project in case.
Of course we can do it right in the beginning,
but it's not always necessary.
And so to start this project,
we will actually simply start coding,
and starting to implement the features
according to the flow chart that we just developed.
Then as we start to need more organization,
and ways to manage our data,
we will come back to thinking about the architecture.
Now, right, and so actually let's now go do that.