How to Deploy With Deployer

Automated workflow for deployment is a great tool that every software development team must have. The release process, when it is fast, secure and fault tolerant, can save time for developing more great things. And the good news that there are many great tools for creating an automated release cycle.

In this article, I’m going to introduce you a deployment tool called Deployer. I like to use it because it is written in PHP, is easy to set up, and has many handy features to integrate the deployment process into your team’s workflow.

The Deployment Process With Deployer

First of all, let’s see the structure of the deployment process with Deployer. It consists of three main parts: a deploy server to init deployment, a production or staging server to host your application, and a git repository to store the code of your application.

When you init a deploy process, you run a deployment script on the deploy server. After this, the deploy server connects to the production server with SSH and does the maintenance things from the production server like cloning the code from a git repository, updating Composer’s dependencies, and other stuff you need in order to have a successful release. 

Deployer Deployment Process

For everyone to be trusted in this chain, we will create and install SSH certificates to the servers and repository.

Install SSH Certificates

We need to create an SSH authentication key on a production server and share it to a git repository. If you don’t have any SSH authentication keys on your deploy server, run ssh-keygen and follow the instructions. Keygen will create a public key in a file ~/.ssh/

Now you can install it to the account of your repository. If you don’t know how to do it, look at the example of GitHub from the related links at the bottom of the article, or ask your repository hosting service for help.

Also, it is better to create an SSH key on your deploy server to get trusted on the production machine. Use these commands to make a passwordless SSH connection between the deploy and production servers.

With all certificates installed, we are ready to install Deployer.

Install Deployer

The installation of Deployer is as easy as the installation of Composer. You need to download PHP Archive and make it a global command:

Let’s check the version of Deployer to see if everything is installed correctly:

Everything looks great, and we are ready to create our first deployment script.

Make the First Deployment Script

To initialize Deployer for your project, run dep init. This will execute a utility to generate a deployment script, which will ask you for a project type and repository link and will create the deploy.php file in the current directory. Let’s have a look at this file and the main functions that are used in a recipe. 

The functions set and get work with the configuration values, and a shortcut of a getter can be used with a run command:

Each configuration value can be overridden for each host. We can set up a deploy path and SSH user for our application in our deploy script:

To define your own tasks, use the task function and run to run a command on the production server:

And then run it with dep and the function name as a param:

Now you can look through the deploy file and change all the needed params to the configuration of your application.

Deploy to Production

We have already installed Deployer, installed SSL certificates to the deploy and production servers, and made the deployment script, so finally it is time to pull it all together and make the first deployment to production.

To deploy your application, just call dep deploy:

Deploy to Production

If something has gone wrong, you can roll back to the previously deployed version in just one step:

Looks easy, doesn’t it?

Now let’s check what was created on our production server. Thanks to Deployer, we can do this easily with shortcut commands. Try dep ssh to connect to a server directly using the configuration from the deployment script, or remotely execute a command via SSH tunnel with dep run. Also, this command supports variables that we have set in the script.

So let’s have a look at the deploy path:

The main thing is the releases directory, where Deployer stores the last versions of our application. After each successful deploy or rollback, it links current to the enabled release. Finally, we have a shared directory, which stores files and folders from the shared_dirs and shared_files that we have set in the script file.

On the first deployment, Deployer will copy those files to a shared dir and create a link from the releases dir to the shared dir. The next time, it will just add a link from the release files to the files and folders in the shared directory. Also, you can change any file in a shared directory and Deployer will keep it without changes on each deploy—for example, this is useful for configuration files.

In addition, if you have a composer.json file in the root of your repository, Deployer will call Composer to create a vendor directory and update all needed dependencies. If you don’t store the Composer file in the root directory, you can create a custom task to update it.

And now it is time to integrate the application deploy to our processes.

Add a Custom Task

Every team has its own deploy configurations and process to automate, so Deployer has easy tools to extend the standard configuration and add custom tasks. For example, your hosting may have the rule to store applications and webroot in different places, with no rights to change the configuration of Apache or Nginx. 

But there is a way to get over this rule—use symbolic links. So we will add a task for this:

And then add it to the main deploy task as part of a release cycle:

Now run the deploy script again and check if everything is correct with dep ssh.

Third-Party Recipes

Deployer has many recipes to integrate with third parties that can extend the basic functionality. We can use Composer to install them:

I like to use the Slack notification recipe. To enable it, we should go to the Slack recipe page, click the Add to Slack button, and select the channel to send notifications. Then we will get the Slack webhook and add this code to deployment.

After these changes, Deployer will send a message like this to the deploy channel:

Viewing Deployer in Slack

Now you can add your team to the channel so everyone who’s involved can be notified.


In this tutorial we have installed Deployer and created a deploy script that can be used to deploy our application from a git repository to a production or staging server in just one click.

Also, it can be integrated into team processes—for example, an application can be deployed automatically after changes in the master branch and notification can be made on a Slack channel about successful deployment.

If you have any questions, don’t hesitate to ask questions in the comments to the article. 

Further Reading and Related Links

Source: Nettuts Web Development

TypeScript for Beginners, Part 4: Classes

We have come a long way in learning TypeScript since starting this series. The first tutorial gave you a brief introduction of TypeScript and suggested some IDEs that you can use for writing TypeScript. The second tutorial focused on data types, and the third tutorial discussed the basics of interfaces in TypeScript.

As you might already know, JavaScript has only recently added native support for classes and object-oriented programming. However, TypeScript has allowed developers to use classes in their code for a long time. This code is then compiled to JavaScript that will work across all major browsers. In this tutorial, you will learn about classes in TypeScript. They are similar to their ES6 counterparts but are stricter.

Creating Your First Class

Let’s start with the basics. Classes are a fundamental part of object-oriented programming. You use classes to represent any entity which has some properties and functions that may act on given properties. TypeScript gives you full control over the properties and functions that are accessible inside and outside their own containing class. Here is a very basic example of creating a Person class.

The above code creates a very simple class called Person. This class has a property called name and a function called introduceSelf. The class also has a constructor, which is also basically a function. However, constructors are special because they are called every time we create a new instance of our class. 

You can also pass parameters to constructors in order to initialize different properties. In our case, we are using the constructor to initialize the name of the person that we are creating using the Person class. The introduceSelf function is a method of the Person class, and we are using it here to print the name of the person to the console. All these properties, methods, and the constructor of a class are collectively called class members.

You should keep in mind that the Person class does not automatically create a person by itself. It acts more like a blueprint with all the information about the attributes a person should have once created. With that in mind, we created a new person and named her Sally. Calling the method introduceSelf on this person will print the line “Hi, I am Sally!” to the console.

Private and Public Modifiers

In the previous section, we created a person named Sally. Right now, it is possible to change the name of the person from Sally to Mindy anywhere in our code, as shown in the following example.

You might have noticed that we were able to use both the name property and the introduceSelf method outside the containing class. This is because all the members of a class in TypeScript are public by default. You can also explicitly specify that a property or method is public by adding the keyword public before it.

Sometimes, you don’t want a property or method to be accessible outside its containing class. This can be achieved by making those members private using the private keyword. In the above code, we could make the name property private and prevent it from being changed outside the containing class. After this change, TypeScript will show you an error saying that the name property is private and you can only access it inside the Person class. The screenshot below shows the error in Visual Studio Code.

A private property not accessible outside its class

Inheritance in TypeScript

Inheritance allows you to create more complex classes starting from a base class. For example, we can use the Person class from the previous section as a base to create a Friend class that will have all the members of the Person and add some members of its own. Similarly, you could also add a Family or Teacher class. 

They will all inherit the methods and properties of the Person while adding some methods and properties of their own to set them apart. The following example should make it clearer. I have also added the code for the Person class here so that you can easily compare the code of both the base class and the derived class.

As you can see, you have to use the extend keyword for the Friend class to inherit all the members of the Person class. It is important to remember that the constructor of a derived class must always invoke the constructor of the base class with a call to super().

You might have noticed that the constructor of Friend did not need to have the same number of parameters as the base class. However, the first name parameter was passed to super() in order to invoke the constructor of the parent, which also accepted one parameter. We did not have to redefine the introduceSelf function inside the Friend class because it was inherited from the Person class.

Using the Protected Modifier

Up to this point, we have only made the members of a class either private or public. While making them public allows us to access them from anywhere, making the members private limits them to their own containing class. Sometimes you might want the members of a base class to be accessible inside all the derived classes. 

You can use the protected modifier in such cases to limit the access of a member only to derived classes. You can also use the protected keyword with the constructor of a base class. This will prevent anyone from creating an instance of that class. However, you will still be able to extend classes based on this base class.

In the above code, you can see that we made the age property protected. This prevents the use of age outside any classes derived from Person. We have also used the protected keyword for the constructor of the Person class. Declaring the constructor as protected means that we will no longer be able to directly instantiate the Person class. The following screenshot shows an error that pops up while trying to instantiate a class with the protected constructor.

TypeScript protected constructor

Final Thoughts

In this tutorial, I have tried to cover the basics of classes in TypeScript. We began the tutorial by creating a very basic Person class that printed the name of the person to the console. After that, you learned about the private keyword, which can be used to prevent the members of a class from being accessed at any arbitrary point in the program. 

Finally, you learned how to extend different classes in your code using a base class with inheritance. There is a lot more that you can learn about classes in the official documentation.

If you have any questions related to this tutorial, let me know in the comments.

Source: Nettuts Web Development

A Swift Transition From iOS To macOS Development



Today started just like any other day. You sat down at your desk, took a sip of coffee and opened up Xcode to start a new project. But wait! The similarities stop there. Today, we will try to build for a different platform! Don’t be afraid. I know you are comfortable there on your iOS island, knocking out iOS applications, but today begins a brand new adventure. Today is the day we head on over to macOS development, a dark and scary place that you know nothing about.

To create a new macOS project in Xcode, open New Project, hit the macOS icon at the top, the select Cocoa App, and press Next

The good news is that developing for macOS using Swift has a lot more in common with iOS development than you realize. To prove this, I will walk you through building a simple screen-annotation application. Once we complete it, you will realize how easy it is to build applications for macOS.

The post A Swift Transition From iOS To macOS Development appeared first on Smashing Magazine.

Source: Smashing Magazine

Understanding the Core Concepts of User Research

The following is a short extract from our new book, Researching UX: User Research, written by James Lang and Emma Howell. It’s the ultimate guide to user research, a key part of effective UX design. SitePoint Premium members get access with their membership, or you can buy a copy in stores worldwide.

This next section is going to get a bit theoretical. Don’t worry: we’ll show you how to apply it later in the chapter. For now, though, you need the basic building blocks of research design.

In this section, we’re going to run through 10 concepts. Some may already be familiar to you, others less so. They are:

  • What is data?
  • Qualitative vs. quantitative
  • Discovery vs. validation
  • Insight vs. evidence vs. ideas
  • Validity and representativeness
  • Scaling your investment
  • Multi-method approaches
  • In-the-moment research
  • Ethics
  • Research as a team sport.

What is Data?

The research process involves collecting, organising and making sense of data, so it’s a good idea to be clear what we mean by the word ‘data’. Actually, data is just another word for observations, and observations come in many forms, such as:

  • Seeing someone behave in a certain way
  • Or do something we’re interested in (such as click on a particular button)
  • Hearing someone make a particular comment about your product
  • Noting that 3,186 people have visited your Contact Us page today

But how do you know what’s useful data, and what’s just irrelevant detail? That’s what we’ll be covering in the first few chapters, where we’ll talk about how to engage the right people, and how to ask the right questions in the right way.

And how do you know what to do with data when you’ve got it? We’ll be covering that in the final two chapters about analysis and sharing your findings. In particular, we’ll be showing you how to transform raw data into usable insight, evidence and ideas.

Qualitative vs. Quantitative

When it comes to data analysis, the approaches we use can be classified as qualitative or quantitative.

Qualitative questions are concerned with impressions, explanations and feelings, and they tend to begin with why, how or what. Such as:

  • “Why don’t teenagers use the new skate park?”
  • “How do novice cooks bake a cake?”
  • “What’s the first thing visitors do when they arrive on the homepage?”

Quantitative questions are concerned with numbers. For example:

  • “How many people visited the skate park today?”
  • “How long has the cake been in the oven for?
  • “How often do you visit the website?”

Because they answer different questions, and use data in different ways, we also think of research methods as being qualitative or quantitative. Surveys and analytics are in the quantitative camp, while interviews of all sorts are qualitative. In general, you’ll be leaning on qualitative research methods more, so that will be the focus of this book.

Discovery vs. Validation

The kind of research will depend on where you are in your product or project lifecycle.

If you’re right at the beginning (in the ‘discovery’ phase), you’ll be needing to answer fundamental questions, such as:

  • Who are our potential users?
  • Do they have a problem we could be addressing?
  • How are they currently solving that problem?
  • How can we improve the way they do things?

If you’re at the validation stage, you have a solution in mind and you need to test it. This might involve:

  • Choosing between several competing options
  • Checking the implementation of your solution matches the design
  • Checking with users that your solution actually solves the problem it’s supposed to.

What this all means is that your research methods will differ, depending on whether you’re at the discovery stage or the validation stage. If it’s the former, you’ll be wanting to conduct more in-depth, multi-method research with a larger sample, using a mix of both qualitative and quantitative methodologies. If it’s the latter, you’ll be using multiple quick rounds of research with a small sample each time.

At the risk of confusing matters, it’s worth mentioning that discovery continues to happen during validation – you’re always learning about your users and how they solve their problems, so it’s important to remain open to this, and adapt earlier learnings to accommodate new knowledge.

Insight, Evidence and Ideas

Research is pointless unless it’s actually used. In some cases, the purpose of research is purely to provide direction to your team; the output of this kind of project is insight. Perhaps you want to understand users’ needs in the discovery phase of your project. If so, you need insight into their current behaviour and preferences, which you’ll refer to as you design a solution.

Often, though, you need research to persuade other people, not just enlighten your immediate team. This can be where you need to make a business case, where your approach faces opposition from skeptical stakeholders, or where you need to provide justification for the choices you’ve made. When you need to persuade other people, what you need is evidence.

And sometimes, your main objective is to generate new ideas. Where that’s the case, rigorous research is still the best foundation, but you’ll want to adjust things slightly to maximise the creativity of your outputs.

Research is great at producing insight, evidence and ideas. But… methodologies that prioritise one are often weaker on the others, and vice versa. It’s much easier if you plan in advance what you’ll need to collect, and how, rather than leaving it till the end of the project. The takeout: you should think about the balance of insight, evidence and ideas you’ll need from your project, and plan accordingly.

When it comes to planning your approach, bear in mind your analysis process later on. If you give it thought at this stage, you’ll ensure you’re collecting the right data in the right way. We talk about this more in Chapter 8.


Validity is another way of saying, “Could I make trustworthy decisions based on these results?” If your research isn’t valid, you might as well not bother. And at the same time, validity is relative. What this means is that every research project is a tradeoff between being as valid as possible, and being realistic about what’s achievable within your timeframe and budget. Designing a research project often comes down to a judgement call between these two considerations.

Let’s look at an example. You want to understand how Wall Street traders use technology to inform their decision-making. If you were prioritising validity, you might aspire to recruit a sample of several hundred, and use a mix of interviewing and observation to follow their behaviour week by week over several months. That would be extremely valid, but it would also be totally unrealistic:

  • Wall Street traders will be rich and busy. They’re unlikely to want to take part in your research.
  • A sample of several hundred is huge. You’re unlikely to be able to manage it and process the mountain of data it would generate.
  • A duration of several months is ambitious. You would struggle to keep your participants engaged over such a long period.
  • Even if the above weren’t issues, the effort and cost involved would be huge.

Undaunted, you might choose to balance validity and achievability in a different way, by using a smaller number of interviews, over a shorter duration, and appealing to traders’ sense of curiosity rather than offering money as an incentive for taking part. It’s more achievable, but you’ve sacrificed some validity in the process.

Validity can take several forms. When you design a research project, ask yourself whether your approach is:

  • Representative: Is your sample a cross-section of the group you’re interested in? Watch out for the way you recruit and incentivize participants as a source of bias.
  • Realistic: If you’re asking people to complete a task, is it a fair reflection of what they’d do normally? For example, if you’re getting them to assess a smartphone prototype, don’t ask them to try it on a laptop.
  • Knowable: Sometimes people don’t know why they do things. If that’s the case, it’s not valid to ask them! For example, users may not know why they tend to prefer puzzle games to racing games, but they will probably still take a guess.
  • Memorable: Small details are hard to remember. If you’re asking your participants to recall something, like how many times they’ve looked at their email in the past month, they’ll be unlikely to remember, and therefore your question isn’t valid: you need a different approach, such as one based on analytics. If you were to ask them how many times they’ve been to a funeral in the past month, you can put more trust in their answer.
  • In the moment: If your question isn’t knowable or memorable, it’s still possible to tackle it ‘in the moment’. We’ll say more about this below.

Takeout: You want your research approach to be as valid as possible (ie, representative and realistic, as well as focused on questions that are knowable and memorable) within the constraints of achievability. Normally, achievability is a matter of time and budget, which leads us to…

Scaling Your Investment

Imagine you were considering changing a paragraph of text on your website. In theory, you could conduct a six-month contextual research project at vast expense, but it probably wouldn’t be worth it. The scale of investment wouldn’t be justified by the value of the change.

Continue reading %Understanding the Core Concepts of User Research%

Source: Sitepoint

How to Make Paper Prototypes

The following is a short extract from our book, Designing UX: Prototyping, written by Dan Goodwin and Ben Coleman. It’s the ultimate guide to prototyping. SitePoint Premium members get access with their membership, or you can buy a copy in stores worldwide.

There are no rules for making paper prototypes––that is what’s great about it. You need materials that are commonly found in any home or office, but if you have to buy them, they are relatively inexpensive.

What You’ll Need

At the very least you’ll require paper and a pen––this low barrier to entry is one of the best aspects about this approach. For more complex and interactive prototypes, though, you’ll need a bigger arsenal, and if you’re running workshops or doing a lot of prototyping, assembling a toolkit of the following items is a good idea.

We’d suggest the following items when undertaking a prototyping session:

  • paper with a grid or dot grid (preferred)
  • sticky notes (never leave home without them!)
  • pencils
  • eraser
  • pens (Sharpies in different colors and thicknesses are ideal)
  • scissors or craft knife
  • glue (preferably restickable)

Items that are nice to have include:

  • index cards
  • mounting putty
  • adhesive tape (preferably removable to move items around)
  • highlighter pens
  • double-ended marker pens with fine and normal nibs
  • transparent sheets and markers
  • a box for filing or transporting your prototype

We’ll look at the possibilities involved in using different materials later in the chapter.

Your Approach

Strictly speaking, you could just dive in and start making; however, a process we’ve found helpful at fffunction is to think outward-in, focusing on increasingly smaller pieces as you go, such as:

  1. devices
  2. screens
  3. elements
  4. interactivity or state changes


What size viewport or device are we designing for in this instance? Any available user research may inform this. Analytics data will indicate what an existing audience may prefer to use. A goal of the design work could be to prototype an improved experience on small-screen devices.

Desktop or Laptop

An A4- or US letter-sized piece of paper is suitable here, where you could use different orientations to mimic the device, such as landscape for a desktop or laptop. If you want a more realistic source, you could print out a browser frame graphic.


A5- or US half-letter-sized paper should suffice, although if you’re designing for a large tablet such as the Apple iPad Pro (12.9 inches), you might want to stick with the A4/Letter size. Again, you can choose an orientation depending on what you expect the user to have. If you want to make this more realistic, creating a dummy device is an option. The most lo-fi approach would be to draw it on a piece of card and cut out a hole where the screen would be, as depicted below.

Laser-cut and 3D-printed devices have been created specifically to help use paper prototypes in a more natural way, allowing the prototype to be part of a device.


As with the previous examples, you can sketch directly onto paper: A5- or US half-letter-sized, index cards, or sticky notes, and use different orientations. There are more options available for mobile devices, though, than any other form.

You could make a cellphone border with a cutout window for the screen, or use cards laid on top of the device to act as different screens.

As mentioned, there are also laser-cut and 3D-printed device models available. The figure below shows a laser-cut plywood phone model that we use in our work.

Plastic or card model devices with a channel to insert pieces of paper to simulate scrolling are also available. You could even place all the screens on a long piece of paper and slide it around to simulate navigation.

Another option is to use a small spiral-bound notebook to flick between screens, with tabs or colored dots forming navigation elements, as seen below. This is a nice approach as it mimics how people use their cellphone: held in one hand while the other taps it to interact.


Now we’ll define what screens are required to communicate the design. It’s helpful to consider what steps in the journey the user will take. We can develop a list from existing work such as user journeys, task models, sitemaps, information architecture, or a functional specification. Some of this was covered in the Gather Resources section of Chapter 2, to which you can refer back if you need a refresher. Once you’ve developed a list, you can start to think about what elements will be required for each screen.

If you don’t know the screen size, or have an incomplete picture of what you are designing, sketching the steps out on cards can be useful for working a product at a high level before going into more detail. We’d recommend beginning
with smaller A5 or index cards to help you focus on the individual interactions on each screen; aiming for one purpose per screen is a good way to start. You can then arrange them on a table to experiment with different flows through a process.


When looking at the elements that make up your screen, consider how users will interact with them during the prototype process. What needs to happen when they touch that element?

In some cases, you may have a consistent interface with only one window changing based on interactions around it. A simple example would be a menu in a left-hand column that changes the content of the right-hand column. This could be represented with the same card on the left, and separate cards for each piece of interchangeable content on the right, as shown below.


All the elements you’ve established will each be interactive at various points. There’s a challenge here in how to replicate that functionality with paper. Again, there’s likely to be no “right first time” solution to this so it’s worth experimenting with different materials and approaches.

Continue reading %How to Make Paper Prototypes%

Source: Sitepoint

Quickly Create Simple yet Powerful Angular Forms

Forms are an essential part of many web applications, being the most common way to enter and edit text-based data. Front-end JavaScript frameworks such as Angular, often have their own idiomatic ways of creating and validating forms that you need to get to grips with to be productive.

Angular allows you to streamline this common task by providing two types of forms that you can create:

  • Template-driven forms – simple forms that can be made rather quickly.
  • Reactive forms – more complex forms that give you greater control over the elements in the form.

In this article, we’ll make a simple example form with each method to see how it’s done.


You do not need to know all the details of how to create an Angular application to understand the framework’s usefulness when it comes to forms. However, if you want to get a better grasp of Angular, you can take a look at this SitePoint article series on building a CRUD app with Angular.


We will use Bootstrap in this tutorial. It is not an integral part of an Angular application, but it will help us streamline our efforts even further by providing ready-made styles.

This is how you can add it to your application:

  1. Open the command prompt and navigate to the folder of your project

  2. Type npm install bootstrap@next. This will add the latest version of bootstrap to the project

  3. Edit the .angular-cli.json file and add a link to the Bootstrap CSS file

    "apps": [
    "styles": [

    We will not use the Bootstrap JavaScript file in this application.

  4. Both template-driven Forms and Reactive Forms require the FormsModule. It should be added to the application in app.module:

    import { FormsModule } from '@angular/forms';
    imports: [

With that out of the way, we can proceed with the forms themselves.

Template-Driven Forms

Let us assume you want to create a simple form as quickly as possible. For example, you need a company registration form. How can you create the form?

The first step is to create the <form> tag in your view.

<form #companyForm="ngForm">

We need to modify this tag in two ways in order to submit the form and use the information from the input fields in our component:

  • We will declare a template variable using the ngForm directive.
  • We will bind the ngSubmit event to a method we will create in our component
<form #companyForm="ngForm" (ngSubmit)="submitCompany(companyForm.form);">

We will create the submitCompany method in the component a bit later. It will be called when the form is submitted and we will pass it the data from the form via companyForm.form.

We also need a submit button, regardless of the content of the form. We will use a few Bootstrap classes to style the button. It is good practice to disable the button before all the data validation requirements are met. We can use the template variable we created for the form to achieve this. We will bind the disabled property to the valid property of the companyForm object. This way the button will be disabled if the form is not valid.

<button class="btn btn-primary" [disabled]="!companyForm.valid">Submit</button>

Let us assume our simple form will have two fields – an input field for the name of the company and a drop-down field for the company’s industry.

Creating form inputs

First, we create an input field for the name:

<input type="text" 

Right now we have a standard input with the type, name and class attributes. What do we need to do to use the Angular approach on our input?

We need to apply the ngModel directive to it. Angular will create a control object and associate it with the field. Essentially, Angular does some of the work for you behind the scenes.

This is a good time to mention that ngModel requires the input field to have a name or the form control must be defined as standalone in ngModelOptions. This is not a problem because our form already has a name. Angular will use the name attribute to distinguish between the control objects.

In addition, we should specify a template variable for the input: #nameField in this case. Angular will set nameField to the ngModel directive that is applied to the input field. We will use this later for the input field’s validation. This variable will also allow us to perform an action based on the value of the field while we are typing in it.

Now our input looks like this:

<input type="text" 

It is almost the same, but with a few key changes.


Let us assume we want the company name field to be required and to have a minimum length of 3 characters. This means we have to add the required and minlength attributes to our input:

<input type="text" 

Sounds simple enough, right? We will also need to display an error message if any of these two requirements are not met. Angular allows us to check the input’s value and display the appropriate error message before the form is submitted.

We can perform such a check while the user is typing in the form. First of all, it is a good idea to display an error only after the user has started to interact with the form. There is no use in displaying an error message right after we load the page. This is why we will insert all the error messages for this input inside the following div:

<div *ngIf="nameField.touched && nameField.errors"></div>

The ngIf directive allows us to show the div only when a specific condition is true. We will use the nameField template variable again here because it is associated with the input. In our case, the div will be visible only, if the input has been touched and there is a problem with it. Alright, what about the error messages themselves?

We will place another div inside the aforementioned one for each error message we want. We will create a new div for the error message and use the nameField template variable again:

<div class="alert alert-danger" 
     The company name is required

We are using the “alert alert-danger” bootstrap classes to style the text field. The nameField variable has the property errors, which contains an object with key-value pairs for all the current errors. The ngIf directive allows us to show this error message only when the ‘required’ condition is not met. We will use the same approach for the error message about the minimum length.

Continue reading %Quickly Create Simple yet Powerful Angular Forms%

Source: Sitepoint

How to Prototype Interactions with Adobe XD

The following is a short extract from our book, Jump Start Adobe XD, written by Daniel Schwarz, a highly practical tutorial on this fantastic prototyping tool. SitePoint Premium members get access with their membership, or you can buy a copy in stores worldwide.

Prototyping Interactions

Let’s start by linking the welcome screen to the location filter screen, effectively demonstrating a user flow where the user searches for a type of cuisine, and is then asked to specify where they’d like to eat in the location filter screen. Click on the right arrow icon (inside the input field on the welcome screen), where a blue arrow-tab will appear alongside it.

Creating a user flow

Drag and drop this blue tab into the location filter screen. A user flow will have been created, and a small modal will appear where you can specify transition settings for this user flow – that is, how the screen will transition into the next one (the type of animation effect, the duration of that animation, etc).

Flow and transition settings

Later on (when we learn how to preview/test our prototypes), we’ll be able to literally click on this icon and be taken to the next screen, as if we were using a real app — this is how we (and our developers, and maybe even our clients) use the prototype workspace to test our concept before committing to it.

Next, we’ll specify the transition settings for this user flow.

Designing Transitions

Animation comes with its own set of UX challenges. A slow transition can make the user feel like your app is taking too long, whereas a transition that’s too fast can leave the user wondering what even happened. And then there’s the style of the transition itself. You don’t need to do a fade-flip-slide combo to wow the user, a subtle motion is enough to illustrate the result of the user interaction. Let’s explore some of the transitions and transition settings that we can use in Adobe XD.

  • Target (what the screen transitions into):
    • None: Essentially removes the flow
    • Previous Artboard: Returns to previous screen
    • [Artboard Name]: Links to another screen
  • Transition (the visual effect):
    • None: No transition
    • Dissolve: Simple fade transition
    • Slide Left: Slides over from the left
    • Slide Right: Slides over from the right
    • Slide Up: Slides over from the top
    • Slide Down: Slides over from the bottom
    • Push ←/→/↑/↓: Same as slide transition, except the screen sliding in pushes the current screen out
  • Easing (the speed of each interval of the transition):
    • Ease-Out: Transition will start at full speed/finish slowly
    • Ease-In: Transition will start slowly/finish at full speed
    • Ease-In-Out: Start slow, full-speed at middle, finish slow
    • None: The transition will not accelerate/decelerate (linear)
  • Duration: Overall time it takes for the transition to complete

For further reading on easings (notably, the different types of easings and their effect on user experience), check out my article on micro-interactions and easings on SitePoint.

Because we linked the welcome screen to the set location screen, the Target setting has already been defined. Slide Left is a suitable option for the Transition setting because it creates motion (the destination screen slides in from the right, implying that it was the next screen in a series of screens — this is the default setting on iOS and some areas of Android).

Ease-out is a suitable easing for this user flow because it forces the animation to be faster at the beginning, creating a seemingly swift transition that doesn’t delay the user too much, then gracefully slows down so the user has a little extra time to understand what’s happened. In most cases, the default Duration setting of 0.4 seconds is more than optimal.

Let’s roll with these settings.

First scren settings

From the Set Location screen, create a user flow back to the Welcome Screen. Select Previous Artboard as the Target, which will automatically reverse the transition last used. For example, if you used Slide Left to enter the screen, Slide Right will be used as you return to the previous screen.

Continue reading %How to Prototype Interactions with Adobe XD%

Source: Sitepoint

UX: What Can We Prototype? What Can’t We Prototype?

The following is a short extract from our book, Designing UX: Prototyping, written by Dan Goodwin and Ben Coleman. It’s the ultimate guide to prototyping. SitePoint Premium members get access with their membership, or you can buy a copy in stores worldwide.

What can we prototype?

In simple terms, what we might consider creating a prototype for are the kinds of things that we might we otherwise use sketches and wireframes to explore and design.

We’ll now review some of the items for which prototypes are particularly helpful in the design of a website.

Information Architecture and Structural Elements

Presenting a site’s structure as a sitemap diagram to the project team and stakeholders is often ineffective. It’s even harder to user-test structural elements with such a diagram. At a more granular level, we have the same problem testing and presenting other aspects of information architecture including structure, behavior and labelling in navigation, or taxonomies (such as the categories users can employ to segment and query products in an online shop).

It’s possible to build an interactive prototype and populate it with real structural elements (for example, primary and secondary page navigation, product categories). Then we can test these structures: the page hierarchy, the behavior of the navigation, and the labels that we’re proposing with real users given real tasks to perform. We can present our information architecture to stakeholders in an exciting, tangible way that they can visualize and explore.

This lends itself particularly well to the loading of real content for prototyping then being used for production. We can start at a low level of fidelity by loading the structure of a website into a content management system (CMS) database for a prototype. Then we can increase fidelity by adding placeholder content, then further still by adding in real content. This content can then potentially be used in a production implementation. We’ll talk about this in detail in Chapter 7.

Layout and Visual Hierarchy

We can use a prototype to design, test, and communicate the overall layout and hierarchy of elements that make up a page. This is the kind of design where we’d traditionally use wireframes.

Take the example of a site presenting a range of vacuum cleaners. We might have a list of all cleaners grouped or categorized in a certain way; for example, a page for each individual cleaner showing specifications, options, and user reviews. We have to decide what content to present in the listing and what to display on a single cleaner page, as well as how to lay them out.

We can use insights from user research to help us, such as the tasks different types of users are trying to achieve, what information is needed to solve those tasks, and what’s considered important / less important. From there we can come up with a proposed layout for the listing and for the single page. Then we can implement that proposal in a prototype, ideally using some real content.

A prototype enables us to present the proposal to stakeholders and to test it with real users. Over the lifetime of our prototype, we can add, remove, and change content, as well as alter the layouts we’re proposing. We can test small changes or radical alternatives to the layout. If our prototype’s implementation has a good separation of content and presentation, the process of changing the layout while maintaining the same base content is easy. That means we can test more layouts, more quickly and more easily.

Interactive Elements

All websites have at least some interactive elements (such as a link), but many have interactive elements that are more involved and complex. This requires significant amounts of user interface design.

Consider the example of an ecommerce site selling clothes and accessories. Users tend to have varying requirements in narrowing their clothing searches, whether it’s by size, color, season, garment type, fabric, brand, and so on. This often leads designers of an ecommerce store to consider a faceted navigation pattern, where users can narrow their search across several sets of criteria––for example, medium size, yellow color, and cotton fabric––and see the results promptly.

While it sounds straightforward enough, this is a remarkably complicated feature to design. The ability of a prototype to help us try out ideas for laying out categories, their method of interaction, and which categories to narrow results by will significantly improve our chances of doing it justice. We can use a decent set of representative content to quickly implement a range of ideas for presenting and interacting with that content. We can communicate our ideas with stakeholders and test them out with real users––iterating, changing, and experimenting as we go.

Without a prototype, this kind of rapid iteration could only happen once the online store had been (at least) partially implemented. Prototyping allows us to do it earlier, quicker, and cheaper.

What can’t we do with a prototype?

By now, I’m hoping you have plenty of ideas for a prototype and what can be achieved by creating one. That said, it’s worth addressing what we’re unlikely to achieve with a prototype.

Use Quantitative Research to Make Decisions

If you’re looking to try out some design ideas with a view to employing metrics to assess which is “better” (for example, more sign-ups, more conversions, highest task completion rate), a prototype is unlikely to help. For these kinds of tests, you need a large sample size––typically in the thousands or tens of thousands; however, utilizing quantitative research to make decisions such as these is beyond the scope of this book.

It’s worth pointing out, though, that prototypes generally will help you test your designs with a large number of users more successfully than alternatives such as sketches or wireframes. This is because of the ease of implementing, sharing, publishing and running tests with prototypes, and iterating these tests over and above the other methods.

Testing for Completion/Conversion Funnel Progress

It’s generally a bad idea to try to measure the success of a task completion/conversion funnel (for example, how far users of an ecommerce site progress along a sales funnel) with user tests, whether it be a prototype or with a production siteQuantitative measurement of progress in goal funnels is covered in the SitePoint book Researching UX: Analytics:

This is because in an observed user-testing scenario, users are motivated to complete the tasks they’re presented with purely by the nature of being a participant in a user test. We might expect to hear comments along the lines of “I’d have given up by now,” which to a degree are useful. But since what users say they do and what they actually do can be two completely different things, such comments only help up to a point. When using a site in a natural context, user behavior in reality may be very different and tolerance for poor design much lower.

Testing Accessibility

Most prototyping techniques fail to match the final production implementation and, as a result, can’t be used to test the accessibility of a design; for example, measuring the ability for users of assistive technologies to access content and features.

Typically, HTML prototyping is done in a very rough-and-ready way, so coding standards and accessibility barely get a look-in.

Continue reading %UX: What Can We Prototype? What Can’t We Prototype?%

Source: Sitepoint

Building With Vue.js 2 and Firebase


Firebase is Google’s mobile platform that helps you develop high-quality apps and grow your business. In this tutorial, you will make good use of one of Firebase’s awesome features: the Realtime Database. 

You will build a single page application to create books. This book will be saved to your Firebase database, and you will be able to retrieve and delete books you have created.

Let’s get started.

Set Up Firebase

Go to Google’s Firebase page to create a new account. When done with that, log in to your console. Click on the option to add a project. Enter your project details and click on the button CREATE PROJECT.

This will lead you to your console. The Firebase console helps you manage your Firebase configuration settings.

For this tutorial, you’ll need to make access to your database public. From the panel on the left, select Database. Select Realtime Database from the options that show next by clicking GET STARTED. Making your database public involves editing the rules. So click RULES on the page that loads next.

Make your rules look like this.

Click the option to PUBLISH when done.

With this rule, authentication is not required to perform read and write actions on your database. This is needful for the application you will be building in this tutorial.

Set Up a Project Using Vue CLI

Vue CLI allows you to scaffold Vue.js projects. If you do not have it on your machine, you can get it by running:

This will install it globally on your machine. Here is how Vue-CLI is used.

To learn more about Vue-CLI, check the GitHub page.

For this project you will use webpack templates, so run the command below from your terminal.

These are the installation options I used.

Navigate to your project folder. The files and folders generated by Vue-CLI have a tree like this.

Now run the command to install your dependencies.

When done, you can start your dev server by running:

Add Firebase to the Project

To bind Firebase data to Vue.js data properties, we will make use of the VueFire library. You can check more about it on GitHub.

Run the command below:

Open up main.js to add VueFire. Make your main.js file look like what I have below.

Set Up the Firebase Connection

Go to your Firebase console, and click on the Overview link on the left panel. Select the option to add Firebase to your web app. Copy the snippet that pops up in the window to a text file. The snippet contains your apiKey, authDomain, databaseURL, projectId, storageBucket, and messagingSenderId. You need these details to be able to access your Firebase database.

You start by importing Firebase from the core Firebase library. A Firebase instance is created using the initializeApp method. The snippet you copied has to be passed to this method as an object. This has to be done in the script section of your App.vue, like this.

After creating the Firebase instance, the database reference is obtained by using app.database().

Book Listing

Since VueFire makes it easy to bind Vue.js data properties to Firebase, implementing the books listing feature requires you to add this.

You add that below:

Now you have access to the book items from your database. The template will look like this.

The v-for directive is used to iterate through the available books. Each book will be outputted in a new table row.

Adding a New Book

To put in place the addition of new books, you need to first define the data model that will be used.

Next, set up the template to look like this.

The v-model directive is used to bind the newBook properties to the corresponding input.

The v-on directive will lead us to create an event handler method that gets called whenever a new book is to be created. Here is what the event handler should look like.

The addBook method helps insert new book objects into the Firebase database. The data is also synced across all clients. 

Deleting Books

Let’s add the ability to delete books. Add another column to the book listing.

Let’s put in place a method that gets called each time the button is clicked. The method is passed the book you intend to delete, which is actually the key to the book, as you will see soon. The remove() is called on the returned book to delete it from the database.

Here is what the method looks like.

With that, you are done with App.vue. Putting everything together, here is how your App.vue file should look.

In the template, I added some Bootstrap classes. For these to work, open your index.html file and make it look like this.


JavaScript has become extremely popular and is now capable of building mature applications (as we’ve seen above). If you’re looking for additional resources to study or to use in your work, check out what we have available in the Envato Market.

In this tutorial, you learned about Firebase. You were able to connect Vue.js and Firebase using VueFire. Your application can make read and write requests to your Firebase database.

You can go further by adding more features like categories and description.

Source: Nettuts Web Development

Quick Wins For Improving Performance And Security Of Your Website



When it comes to building and maintaining a website, one has to take a ton of things into consideration. However, in an era when people want to see results fast, while at the same time knowing that their information online is secure, all webmasters should strive for a) improving the performance of their website, and b) increasing their website’s security.

Quick Wins For Improving Performance And Security Of Your Website

Both of these goals are vital in order to run a successful website. So, we’ve put together a list of five technologies you should consider implementing to improve both the performance and security of your website.

The post Quick Wins For Improving Performance And Security Of Your Website appeared first on Smashing Magazine.

Source: Smashing Magazine