Are you ready to work your way to Angular mastery? My guess is that you are, and with this book and your determination, you will. You purchased this book, and I not only thank you, but I want to make a promise to you right here, right now. Two promises, in fact. The first one is that if you diligently read the material, apply the knowledge you'll gain along the way, and build the example application with me throughout these pages, you will be well on your way to Angular mastery.

If you're anything like me, you have a library packed with literally hundreds of technical books and you have read most of them. Some books start off at an excruciatingly slow pace, entrenched in theory and historical minutia, while other books start off so quickly, they leave the readers scratching their heads wondering if they are too dumb to understand the material. The truth is, striking a balance while introducing readers to potentially brand new material—and not have them nod off as they read their newly acquired 400+ page technical book—is a tricky thing to pull off. So, my esteemed budding Angular guru, that is what my second promise is to you. I promise to do my utmost in finding that all-elusive happy medium between being technically heavy-handed, and being real-world practical while making this book as entertaining a read as I possibly can for you.

With the promises well stated, let's start our journey to Angular mastery together by taking a quick look at what we're going to cover in this brisk, but all important first chapter.

We'll set up your development environment in a jiffy, and we'll build our first Angular application in order to get some immediate feeling of accomplishment. We're going to skim over the details as we write it, but right after that, we'll cover a few critical Angular basics in more detail before concluding this chapter. These first few basics are the very first things you should get comfortable with because we'll use them over and over again throughout the book as we learn about the more advanced stuff.

After we cover these basics, we'll switch gears from Angular speak and we'll take a look at the fully fledged application that we'll be building together throughout the remainder of the book. As a bonus (and there are a few bonuses in this book that I hope will bring you a bunch of value), we're also going to touch on design principles, wireframing, and a little used design strategy called paper prototyping—whose focus is on usability testing. Paper prototyping has been around since approximately 1985 and has largely been replaced by Lean UX design since approximately 2008. Still, I'm always amazed at how many of my clients have never even heard of paper prototyping—but I'm also happy when they discover the value it brings to them when they try it out.

We'll cover paper prototyping at a high level at the end of this chapter, immediately following the wireframes section, which is the most logical place for discussing paper prototyping. We'll touch on a few UX design principles as well, but not on the Lean UX process itself since that would take us too far off course from our focus of this book. However, if you have an interest in the Lean UX design process, here is a good starting point: https://www.interaction-design.org/literature/article/a-simple-introduction-to-lean-ux.

OK, my esteemed budding Angular guru, are you primed and ready to get started? Good! Let's go!

The topics we will be covering in the chapter are:

• Angular's evolution
• Angular's building blocks
• Setting up your development environment
• Writing your first Angular application
• Angular basics
• Our sample project
• The process of paper prototyping

Angular is a frontend JavaScript-based web application framework that provides you with everything you need, including the kitchen sink, with which to build amazingly powerful Single Page Applications (SPAs). The application we'll be building together is an SPA, and we'll be discussing SPA strategies along the way.

While Angular wasn't the first JavaScript-based frontend web application framework, it was quite possibly the most powerful one of them. This is likely due to Angular's SPA-centric focus—since there's more to building an SPA application than there is to simply provide two-way data binding on your web pages.

The initial release of Angular was in late fall of 2010. Since then, dozens of competing libraries and frameworks have come on the scene, including some that also have large adoptions and large production implementations, such as Ember.js, Backbone.js, and React.js. Angular, despite having perhaps the highest learning curve (and we'll see why this is the case), remains the most powerful one of them all.

The Angular naming and versioning jungle can, at first glance, seem confusing. There are a few reasons for this, as follows:

• Angular's 1.x releases: Basically, any release prior to Angular 2 is commonly referred to as AngularJS. 
• AngularJS is no more actively in development mode. It has been put under long term support mode.
• Angular framework is being actively developed, and so developers need to be specific about which of the two Angular frameworks they are referring to when discussing them. Fortunately, there are two completely dedicated websites for them: https://angularjs.org/ and https://angular.io, respectively. The Angular team adopted semantic versioning, starting with the 2.0.0 release. You can read more about semantic versioning here: https://semver.org.
• Angular 2 was a complete rewrite of Angular 1.x (that is, AngularJS), and is thus not backward compatible with AngularJS. While Angular 4 was not a complete rewrite of Angular 2, it did have some changes in its core libraries that required the team to increment its major number from 2 to 4. Version 3 was skipped as a release number altogether.
• All releases from Angular 2 onward are commonly referred to as Angular 2+, or simply just as Angular.
• Due to having adopted semantic versioning, the Angular team never released Angular 3 and so went straight from Angular 2 to Angular 4. Specifically, there was a misalignment of the router package's version, which was already distributed as version 3.3.0. We'll cover routing in Angular in great detail in Chapter 4, Routing. Don't let this confuse you. Just know that there wasn't ever an Angular 3. No big deal. In the Windows OS world, there was never a Windows 9 either. These things happen.

After reading the preceding list, you can see why there tends to be some confusion around Angular. However, it's pretty straightforward if you keep these two things in mind:

• You should really only be using Angular, and not AngularJS (unless you have an exceptionally good reason for it)
• With the exception of there not being an Angular 3, there will be two major releases per year; they should be contiguous in numbering scheme (that is, 8, 9, and so on), and they are expected to be backward compatible—at least within the same major version number (as per the spirit of semantic versioning)

You can check out the official Angular release schedule here: https://github.com/angular/angular/blob/master/docs/RELEASE_SCHEDULE.md. Since Angular is a complete rewrite of the AngularJS platform, and this is worlds apart from AngularJS, we'll skip AngularJS altogether and start by taking a look at Components which are Angular's building blocks. Are you with me? Great, let's speedily move ahead.

Adding new features is the business of publishing new frameworks—but luckily, the fundamental underlying architecture does not change very often. When it does, it's not typically a complete overhaul. With the exception of Angular 2.0, which was completely divergent from its predecessor, all major releases so far contain largely the same architecture.

Let's now take a look at the core architectural pieces of the framework.

Components are like widgets that are in charge of displaying themselves along with the data they consume and/or manipulate on areas of your screen called views. An Angular application is like a tree of components, and Angular provides mechanisms for components to communicate with each other in a bidirectional manner—parent to child and child to parent.

Components rely on their templates for rendering their data. Templates are where you define what the component looks like and you can hook in styles to window-dress your component any way you like. A component can either contain its template (that is, the HTML) and its styling (that is, the CSS) either directly within itself or have references to template and style files outside of itself. At the end of the day, the world's fanciest frontend frameworks produce HTML, CSS, and JavaScript because these three things are the only things browsers understand.

Within the templates you create for your component, Angular enables you to alter the DOM with powerful constructs called directives. There are directives for controlling the way things are rendered on the screen (that is, the component view) such as repeating snippets of HTML, for displaying things based on conditional logic, for hiding or showing things, filtering arrays of data, and much more.

Angular is modular. That is to say that its functionality is wrapped up in modules, known as NgModules, and are themselves libraries. Modules are perfect for lumping code together in an organized way. For instance, there are modules for helping with forms, routing, and communicating with RESTful APIs. Many third-party libraries are packaged as NgModules so you can incorporate them into your Angular applications. Two examples of this are Material Design and AngularFire—we'll be taking a look at both of these libraries in later chapters.

Services are not really an Angular artifact per se, but rather a very general notion representing encompassed functionality, functions, and features that your application's components may need to consume. Things such as logging, data retrieval, or virtually any calculation or lookup service, can be written as services—these services can reside within your application, or live externally from it. You can think of a service as a highly specialized class that provides some service (such as looking up the distance between two zip codes) and does it well. Just as with components, not only are there tons of third-party services you can use in your Angular applications, but you can create your own custom services. We'll learn how to do this in Chapter 12, Integrating Backend Data Services.

Dependency injection(DI), or Inversion of Control (IoC), is a very useful and common software design pattern. This pattern is used to inject objects into the objects that depend on them. The object you're using that depends on other objects can just go ahead and use it without needing to worry where it is in order to load it, or how to instantiate it—you just use it as if it just sprung into existence at the time you needed it. Services are perfect for injecting into our application. We'll learn how to use DI in Angular, and how we can use the Angular command-line interface (CLI ) to generate injectable services of our own design.

Just before we move on to setting up our development environment, here are some interesting things about Angular:

• AngularJS was built using JavaScript, while Angular was built using TypeScript. While this adds a level of abstraction when writing Angular applications, using TypeScript provides a few important advantages when building larger apps with larger teams—we'll get to those shortly.
• AngularJS was based on controllers, whereas Angular is component based. You'll learn all you need to know about components in Chapter 6, Building Angular Components.
• SPAs are notorious for being difficult for implementing Search Engine Optimization (SEO ), but Angular is SEO friendly.
• It's possible to build native mobile applications with Angular.
• It's also possible to build cross-platform, desktop-installed applications with Angular.
• Angular can also run on the server, using Angular Universal.

You have to admit, this is a pretty impressive and exciting list. These things and more make learning Angular a worthwhile endeavor and the marketplace is asking for Angular know-how.

In order to get started with Angular, you're going to need to have the Angular CLI installed; to install that, you first need to have Node.js and npm (node package manager) installed. If you've already got Node.js and npm installed, great! If not, don't worry—they are easy to install and I will take you through the installation process in Appendix A, Toolchain for Web Development with Angular, near the back of the book. In Appendix A, I also take you through installing the Angular CLI and how to use it for building Angular applications. For brevity, I'll refer to the Angular CLI tool as just the CLI from this point forward.

If you are unsure whether you have NodeJS and npm installed, you can check really quickly by typing $ node -v and $ npm -v, respectively, on your command line. Similarly, you can type $ ng -v on the command line to see whether you have CLI installed. If you get a version number back, you have that particular tool installed (as shown in the following screenshot I took).

If any of these commands go unrecognized, jump on over to Appendix A real quick, install the tools, and jump right back here. I'll be waiting for you.

We'll also need a code editor. There are many code editors available today, including a number of free ones. Though any code editor will suffice, I would suggest you use Visual Studio Code for your Angular development—at least while working through this book. The reason for this is that Visual Studio Code is free, it's cross-platform, and is an excellent code editor. It's also the code editor that I've used while writing this book and so when I suggest the use of an extension, you can easily install the same one.

The preceding is all you need for this first chapter. When we start building the example project, which requires us to have a local database, you'll also need to install MongoDB. MongoDB, also known as Mongo, is a great NoSQL database that is also free and cross-platform. I take you through Mongo's installation process in Appendix B, MongoDB.

Additionally, there will be other software that you'll need to install, such as Chrome extensions, and I will let you know what they are and where to find them at the appropriate time. For now, let's get started with writing some Angular code.

When it comes to experimenting with Angular code, as you pick up this awesomely powerful framework, you generally have two choices of how to proceed. The first is to use an online code editor such as JSFiddle, Plunker, StackBlitz, or more. In Appendix C, Working with StackBlitz, you'll learn about the basics of using StackBlitz so you can use it from time to time to test some quick code without needing a test project in your development environment. You can visit the StackBlitz website here: https://stackblitz.com.

The second approach is to use your own local development environment—and since we've already set it up in the previous section, you can create a project whose sole purpose is to run some quick example code if you'd rather use that than an online code editor. My goal is to show you that you have options—there's not just one way to experiment with some code as you learn Angular.

When you use an online code editor, such as StackBlitz, the only software you need installed is a browser—no other tools whatsoever. While this makes things very easy, the trade-off is that you are extremely restricted in what you can do. That being said, I encourage you to experiment with an online code editor, but we'll only be using our development environments throughout this book. So, let's do that and create a small application together in just a few minutes time—we'll build a to-do list app.

From this point forward, we'll be using our terminals, the CLI, and the Visual Studio Code. Head on over to https://code.visualstudio.com, where you'll be able to download the Visual Studio Code installation package for your operating system of choice.

Components are the basic building blocks of Angular. In fact, you can think of an Angular web application as a tree of components. When you use the CLI to generate the shell for your Angular application, the CLI also autogenerates one component for you. The filename is app.component.ts and is in the src/app folder. The app component is how your Angular application is bootstrapped—meaning that it is the first component that is loaded, and all the other components are pulled into it. This also means that components can be nested. The previous screenshot shows our project directory structure, with the src/app folder expanded, and the app.component.ts open in the IDE's file editor window. The .ts file extension indicates that it is a TypeScript file. Interesting note—when you write Angular applications, you use TypeScript instead of JavaScript. In fact, the Angular team used TypeScript to write Angular!

After the following Components section, you'll find a complete code listing for our Angular application. There are six files that you'll have to edit. Three of them are already available in the application that you generated with the CLI. The other three will be available in your project once you use the CLI to generate the to-do component, which is the directory that you are presently missing when you compare your project structure to the previous screenshot. You'll find out how to do that in the following Components section, which is why the complete code listing was inserted afterward. Don't worry—follow along, keep the faith that Angular mastery is within your grasp, and you'll be just fine. If you don't believe me, just lie down on the floor and mumble these words, This too, shall pass, three times, slowly.

This section is a high-level fly-by on Angular components—just enough coverage of what an Angular component is. Chapter 6, Building Angular Components, is completely dedicated to Angular components and is where we're going to take a deep dive into them. Consider this section to be a little peek behind the component curtain, and when we get to discussing components, we're going to pull the curtains wide open and take a good look at the Component Wizard of Oz. Remember that in the Wizard of Oz story, Dorothy and the gang were petrified of the Wizard, but when he was finally revealed behind the curtains, they all soon stopped being scared. 

As previously mentioned, you can think of components as the basic building blocks or Angular, and of your Angular application as a tree of nested components. Buttons, progress bars, input fields, entire tables, advanced things such as carousels, and even custom video players—these are all components. The components on your web page can communicate with each other, and Angular has a couple of rules and protocols for how they can go about doing so. By the end of this book, you will become very comfortable with the ins and outs of components. You must, for it's simply the way of the Angular guru!

When you write a component file, as in the code that follows, there are three main sections to it. The first is the import section. The middle section is the component decorator, and it's where you indicate what the component's template file is (which defines what the component looks like), and what the components style file is (which is used to style the component).

import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})
export class AppComponent {
  title = 'app';
}

The CLI created the app component for us by default when it created our application for us, but how do we create our own components? The easiest way to generate a new component is to use the CLI and issue the following command: $ ng generate component name-of-component. So, to generate a new component named to-doitem, we would type $ ng generate component to-doitem on our command prompt. Remember to do this from within the src | app folder. The CLI will generate this component and insert it into its own folder, and the name of the newly created folder will be the same as the component.

Inside this folder, you will see four new files and their names all start with to-doitem.component because the name of our component is todoitem, and, well, it's a component. We'll discuss what the file ending in spec.ts is used for later, but you may already have a good guess as to what the other three files are for. Let's verify what you are probably already thinking; the component file itself is indeed the one named todoitem.component.ts. This file contains a reference to two of the others: todoitem.component.html, which is the template for the component (the HTML code, for defining its markup structure), and the todoitem.component.scss file, which will hold the styling for the component. Additionally, the CLI modified an existing file named app.module.ts. We'll discuss this file in more detail later on, but for now, all you need to know is that this file acts as a registry for your application's components.

You may be thinking, That's a lot of files. Are they all needed? The short answer to that is no. In  Chapter 5, Flex-Layout – Angular's Responsive Layout Engine, we'll look at how we can eliminate the .html file, and the .scss files, and just put all of our component stuff (the HTML and the styling) into our component file. However, there is a reason the Angular team provided the mechanism to have all these things be separate—so your application's code can be tidy and organized. You can thank them later.

A nice shortcut syntax when using the CLI to generate a component is to type $ ng g c name-of-component, where g is short for generating, and c is short for the component.

In addition to creating our own components from scratch, which we'll look at in depth in Chapter 5, Flex-Layout – Angular's Responsive Layout Engine. 

Interpolation is how you get a value from a variable within your component class to render in the component's template. If you recall, the logic for the component goes in the export section of the component class. That is the same place where variables are that you would like to use interpolation to have their values rendered in the template (that is, rendered on the web page). Let's assume that you have a variable called items and that its value is currently 4. To render the value in the template, you use a pair of double curly braces with the variable in between them. The variables and component logic are written inside the class.

Don't worry—we'll see lots of code snippets throughout the book that use interpolation, but for now, you can see this sample code that shows it in action. The code is meaningless and hardcoded for now, but it does demonstrate interpolation.

The first screenshot is of the component file (home.component.ts); the variable is declared on line 10:

This second screenshot is of the component's template file (home.component.html). Notice the pair of double curly braces on line 6:

This last screenshot shows the rendered value, 4 in this case. That's the basics of interpolation. We'll see much more advanced usage of it throughout the book as we work on our annotated photo album:

We've already mentioned something about templating and styling in the last few paragraphs of the Components section. Now that we have a small project available to us—the one that we created with the CLI—we can see what this looks like in code. Open your Angular project in the IDE, and open the app.component.ts file. Lines 5 and 6 in this app component file contain the references to its associated template (the .html file), and its style file (.scss), respectively. The following is a screenshot of the open project in my IDE, with the app.component.ts file open:

There are two types of data binding we can do in Angular, namely, one-way and two-way. Interpolation is very similar to one-way data binding. This is because, in both cases, data flows from the component class to the component template and not the other way around. Property binding is data binding in the sense that the data is being bound to a property.

It's also possible to have two-way property binding—meaning, not only can the value of a component property be bound to the template, but the template can alter the value of a component property. This is made possible in Angular by ngModel. Again, don't worry about this for now. We will take a look at two-way property binding later on. Just know that both one-way and two-way property binding is possible in Angular.

Implementing one-way property binding is very straightforward. All you need to do is to put square brackets around the HTML property (in the component's template) you want the data bound to, and assign the variable to it. To see a quick example of what one-way property binding looks like in code, take a look at the next three screenshots.

The first screenshot is of the component file (home.component.ts); the variable, txtPlaceholder, is declared on line 11:

This next screenshot is of the component's template file (home.component.html). In line 14, you can see the square brackets around the placeholder property of the input element:

This last screenshot is of the application running in the browser. You can see the text, Enter your todo item here, inserted as the placeholder text for the textbox via one-way property binding:

In Angular, event binding simply means that an event will be registered on an element within a component, and when that event happens, it will trigger a function to be called. In other words, an event will call a function. There are a ton of events that you can have Angular listen for—such as a button being clicked, a mouse hovering over an image, or when the user presses a key down when the cursor is in a textbox, and lots more. And, of course, you can write any function you can possibly think of to make other stuff happen, such as calling a web service, changing the color of the background page, calculating the value of Pi to 1,000 decimal places, or virtually anything else your heart desires. But how can we set up event binding in our Angular application to tie the event we're interested in, on the element we're interested in, to run the function we want? Well, thankfully, the Angular team made this super easy for us.

Suppose we'd like to have some user interaction via events such as click or mouseover—we can use event binding to map the functionality.

Now, that example is not very interesting, but we do have our to-do list application to look at the code we've already written. If you've typed in the code listings.

Learning a new programming language, or learning a new framework, is a matter of hands-on experimentation and repetition. Even Dr. Sheldon Cooper from The Big Bang Theory can't learn Angular just by reading a book on it. However, just following along with random code examples isn't much fun to do and, at the end of the day, you don't really have anything you can use. So, the approach we'll take on our journey to Angular mastery is to build a fully fledged web application that is fun to build and practical since you can deploy it and use it yourself.

The application that we'll be building together is based on one of the online services I've launched called Vizcaro. Vizcaro is a photo sharing service, but instead of sharing individual photos, you share albums (groups of photos). Also, the photos and albums will be annotated so you can add titles and captions to them. Our version won't have all the bells and whistles that my online service offers, but it will have just enough parts to make it a great web application to build in order to learn the material in this book.

There are generally two types of design: the way in which you design your user interface (the GUI), and the way in which you design the software components (API interfaces, services, components, and more). Throughout this book, we'll be covering quite a few design principles for the code. Angular is a spectacularly well-designed piece of software, and this is great for us because it provides a perfect opportunity to discuss software design as we learn Angular itself, in addition to when building our application. We'll also be covering user interface design principles in general as we build our application throughout the remainder of this book, but particularly when we build out our templates using our wireframes to help guide us.

In general, the term UX design is used when discussing user interface design. Borrowing a definition of UX design from Wikipedia: 

This is a good definition and applies to more than just software products.

Wireframes have been around since the early '80s. Their focus, at least initially, was on what the screen in the desktop application did (remember, web applications were not around yet), and for its general layout. They were not meant to be used as what the final design was to look like—including font selection, colors, and other properties of the controls on the screen. In essence, they were the prototype on paper. Paper prototyping, conversely, is a process that uses the wireframes. It's worth noting that the nouns wireframes and mockups are used interchangeably—they are the same thing. I'll briefly cover the paper prototyping process at the end of this chapter.

There are 10 wireframes that we'll be using for building our application—one for each screen it will have. The following is the listing of them, and a short description precedes each screenshot.

Every web application needs a starting page of some kind. It's known by many names, typically one of these: home page, landing page, index page, or splash page. Ours will be straightforward. No Flash animation or rainbow-colored backgrounds; it will be a simple page that lets the user know what the site does, and hopefully, it does that within five to seven seconds. If it doesn't, you may lose the visitor forever:

Most web applications don't have a dashboard page, but those that do typically provide a summary of things the user has, the last time they had logged in, and any notifications that the company would like to bring to the user's attention. If you use online banking, chances are that your bank's online banking web application has a dashboard page—and it probably is a list of accounts (checking, savings, credit cards, car loans, and more), and the balances on those accounts that you have with them.

We're going to build an application that users will implement to create photo albums, and so our dashboard will contain the number of photos we have uploaded, the number of photo albums, the last time we logged in, and more:

Since our application is supposed to enable our users to create photo albums, we'd better have a way for them to upload their photos! Yes—we are dedicating an entire web page to upload one photo at a time because we will use this same page to preview it after it has been uploaded—and to undo the upload. You'd be surprised to know that there is a well-known photo sharing site that does not show what you have just uploaded until you go to the listing of your photos! Having an immediate confirmation that the photo you intended to upload is, in fact, the one that was uploaded:

Uploading a photo is the first step in our annotated photo album application. We are devoting another web page to preparation the photo. This is where we will allow the user to resize the image and annotate it (give it a name and a caption). The photo's caption will be shown when viewing it in the photo album:

Before the user can add photos in their photo albums, they have to be able to create the albums. This is what the following web page will be used for:

You always need to think of usability and how to design the most intuitive user interface you possibly can. This page will show a listing of all the photos that the user has uploaded. Additionally, they can edit the name and caption for any of the photos right on this same page. The less jumping around from page to page that your users need to do, the happier they'll be:

This page does for photo albums what the previous page did for photos—provides a listing of all the albums the user created and has an intuitive way to edit their name and description (as opposed to the caption for photos) without going to another web page:

The workbench is the place where the user will be able to drag a photo onto a photo album. This will be our way of allowing the user to intuitively associate a specific photo to a specific album. By the way, not only will our drag and drop feature be intuitive and functional, it will add an element of fun for the user. Psychologically, users want to play on the site. Dragging and dropping—though not a mind-blowing experience—is more fun to do than it would be to select a photo from a photo dropdown, then select an album from an album dropdown, and, finally, click a connect or associate button. The former method would please the user, and the latter would make them send you a nastygram—then leave the site, never to return:

At the end of the day, the users want to see their photo albums in an engaging way. The drag and drop stuff was fun but they're not here for that. They're here to see photos from their son's birthday party, their daughter's high school graduation, or pictures of their dream home. This is an important page for them; it's where their work of using our site will pay off for them. Let's not disappoint them:

This concludes the introduction of our annotated photo album that we'll be building throughout the remainder of the book, the wireframing and this chapter's planned material that was to be covered. I did, however, want to quickly discuss paper prototyping, as a closing to the chapter, and to tie it back to the planning of our Angular application.

As mentioned near the beginning of this chapter, paper prototyping is a process. We had also mentioned that the core focus of paper prototyping was on usability testing. What we hadn't mentioned was that paper prototyping should be a part of the software development methodology that your development team uses—be it waterfall, or some form of agile. Specifically, paper prototyping should come immediately after the requirements documents are delivered to the project manager. That is the high-level view of what paper prototyping is and where it fits in.

Let's now take a look at the mechanics of the process at the lower level, meaning the interaction of the development team with the users of the application that is to be developed.

The mechanics, or process in which paper prototyping is done is to first create the wireframes and print them out (I know, more trees will be cut down and global warming becomes an even larger threat, but paper prototyping is important). Once the paper version is in front of you, your boss, your client, or a group of intended users (such as a focus group), you, or whomever else, will use the paper prototype just like they would by clicking their mouse onto the actual web application as if it were already finished and in production. You would ask them to pretend that it was the actual finished application. It sounds silly at first but human beings have an incredible imagination, and with little effort, they will be using it as they would the real thing! This is not hypnosis here but rather something quite magical starts to happen. Without your direction, except for at the very beginning when you explain what you're requesting of them and why, they will start to ramble on, talking out loud about the actions they are taking, or are thinking of taking, such as, Ok, so now I need to fill this out and submit the form, or Where is the button to undo what I just did. I made a mistake. The best information you're going to get from people going through this exercise is when they offer suggestions for how something may be improved, such as It'd be nice if I can easily navigate back to where I... . Can you imagine coding web pages and then realizing the changes being asked to have a far-reaching effect and would be a time-consuming change? It happens a lot.

Do you realize what you have by doing this? You have test users and you haven't written a single line of code! It is quite a powerful exercise! Try it, and email me your story.

So, when I explain this to a client—not to be the user, but how to present the paper prototyping process to their users and/or clients, I'm usually asked, But this is paper. How do we change the screen? I reply the best way I can—by showing them an example. I usually have a sample set of wireframes with me. Not only to demonstrate the paper prototyping process but also to just show a good example of wireframes. I lay down the login screen on the table we're seated at, and I ask them to log in using their finger as the mouse pointer, and then typing on their imaginary keyboard. After they chuckle and just play along with me by typing their username and password by fake typing on the table under the wireframe, they then hit the login button, and I become the computer—I pick up the login wireframe and put down the dashboard wireframe. They usually stop chuckling, look at the dashboard page, take a few seconds, and then look at me nodding and say, This is cool. I get it.

This chapter was packed with a wide array of topics, I know. It was inevitable because there is no one best starting point for all the readers. For instance, some readers know what wireframes are and have used them for years, while other readers may have only just heard of the term, or maybe not even that. This is the third edition of this book, but it is quite a bit different from the first two editions and even if it was largely the same, which it isn't, it doesn't mean that readers have already gone through the first two editions. You can think of this first chapter as a type of funnel—a wide enough funnel that brings readers of all levels of experience, and differing knowledge, into a common track for learning Angular, and the other symbiotic technologies that are covered in this book. Starting with Chapter 2, ECMAScript and TypeScript Crash Course, the funnel approach is over. The rest of the chapters will be a lot more focused on the subject matter at hand. So, thank you for hanging in there with me. Still, I hope that there were a few things that made wading through this first couple of dozen pages worthwhile, even if you're not completely new to Angular.

In review, we covered the evolution of Angular, including its semantic versioning and release schedule. Although the installation of NodeJS, npm, and the CLI are covered in Appendix A, this chapter is what guided that discussion, and we then used the CLI to build our first Angular app and a to-do list app together. We'll name the app to-do list because we're developers and not marketers (wink). We also covered how to use StackBlitz for building the same Angular application without having any reliance on our local development environment. We then covered the first very basic building blocks of Angular that you need to know well since they will be used again and again for any Angular apps you build. Namely, these were templating, property binding, event binding, and class binding. Lastly, we introduced the annotated photo album application that we'll be building together throughout this book and covered UX design principles, wireframing, and paper prototyping along the way. Whew! Mama mia!

In the next chapter, we will first understand the relationship between JavaScript and TypeScript. We will the as then, as the name suggests, do a crash course on TypeScript and it's advantages over JavaScript.