Tech Guides - Web Development

Clearly, there’s lot of competition for web designer jobs, - with the salary rising each year - so it’s crucial you find a way to make your resume stand out. You need to balance creativity with professionalism, all while making sure your experience, personality, and skills shine through. Over the years, people have created numerous resumes for web designers and everybody knows what it takes to get that job. Follow this guide to write a creative and attention-grabbing web designer resume. Note: All images in this article are courtesy of zety.com resume templates page and the guide. Format is a window to your mind Because you’re applying for a design position, the look and format of your resume is very important. It gives prospective employers a sense of your design philosophies. Use white space, and clear, legible fonts to help a hiring manager easily find your information. To stand apart from the crowd, avoid using a word processor to create your resume. Instead use InDesign or Illustrator to design something creative and less cookie-cutter like. Submit your resume in PDF format to avoid formatting errors that will ruin the look of your document. Sometimes a job posting will specifically forbid submitting in PDF though, so watch out for that. Highlight your Experience The key to writing a good experience section for a web designer is keeping it brief and relevant, while highlighting your career achievements. Add no more than three to five bullet points with measurable achievements per past position. Don’t just list your past company and when you worked there. “Discuss what you did and include some tangible accomplishments. If you created a custom graphic set for clients, mention that, and also what percentage were satisfied (hopefully it’s very high.) Prove you have the necessary experience to do the job well,” advises Terrence Wood, resume proofreader at Paper Fellows. Education Your education is not nearly as important as your experience, but you still need to present it right. That means using this section to talk about your strong points. Include coursework and achievements that are relevant to the job description. Maybe you wrote a column about web design in your college’s newspaper, things like this help you stand out to a hiring manager, especially if you are just starting your career in web design. Also, include the GPA here. Showcase your skills Everyone is going to list their skills, if you want that interview you need to do something to make yourself seem exceptional. The first thing you’ll do is take a good look at the job description and note what skills and responsibilities they mention. Now you know what skills to include, but including them is not enough. You need to prove you have them by giving examples of times you used them at past jobs. Don’t just list that you are proficient in Adobe Creative Suite, prove it by describing how you used it to tackle web design for 90% of client projects. Up the ante even more and include samples of your past work. This is a good spot to include your portfolio, any certifications that you have or anything that can help you let them know just how good you are at your job and confirm your skills. If you've had a predominantly freelance career, list the companies or individuals that you've worked for and include examples of work for each of them. You can do the same thing if you had a '9 to 5' career – simply list your previous jobs and show examples of your best work. It's a good idea to let your potential employers know about any future skills you plan to acquire. Use infographics You can give your resume a really unique look by using infographics, while still keeping it professional. Divide your resume layout into a grid with two columns and four or five rows. Now place one category of data into each square of your grid. Next, transform each section into an infographic. Use icons to represent different skills or awards. You can use your design software’s shape tools to create charts and graphs. Programs like Adobe InDesign can be used to create your infographics. You can also use Canva or Visme. Keep it professional It’s a great idea to inject some creativity into you resume. You want to stand out, and after all, it is a design resume. But it’s also important to balance that creativity with professionalism. A hiring manager will make some judgements about your personality based on how your resume looks. Be subtle in your creativity. Use colors that are easy on the eyes, and keep fonts reasonable. There can be a lot of beauty in simplicity. Stick to the basics, place content in an order familiar to recruiters to avoid making them have to work for the information they need. Remember that your primary goal is to communicate your information clearly. Write a cover letter Some people say that it's not really necessary but it's your chance to stand out. Maybe there is something that isn't on your resume or you want to seem more appealing and human – cover letter is a good chance to do all of that. Cover letter is a great place to elaborate how you'll be able to meet their needs. It's a good opportunity to also show them that you have done your research and know their company. Writing resources for your resume ViaWriting and Writing Populist: These are grammar resources you can use to check over your resume for grammatical mistakes. Resume Service: This is a resume service you can use to improve the quality of your web designer resume. Boomessays and EssayRoo: These are online proofreading tools, suggested by Revieweal, you can use to make sure you resume is polished and free of errors. My Writing Way and Academadvisor: Check out these career writing blogs for tips and ideas on how to improve your resume. You’ll find posts here by people who have written web designer resumes before. OXEssays and UKWritings: These are editing tools, recommended by UKWritings review, you can use to go over your resume for typos and other errors. StateofWriting and SimpleGrad: Check out these writing guides for suggestions on how to improve your resume. Even experienced writers can benefit from some extra guidance now and then. ResumeLab: Learn what to include in a cover letter. The job market for web designers is competitive. Make sure you lead with your best qualities and skills, and be sure they fit the job description as closely as possible. Be creative, but ensure you keep your resume professional as well. Now go have fun using this guide to write a creative and attention-grabbing web design resume. Author bio Grace Carter is a resume proofreader at Assignment Writing Service and at Australian Help, where she helps with CV editing and cover letter proofreading. Also, Grace teaches business writing at Academized educational website.   Is your web design responsive? “Be objective, fight for the user, and test with real users on the go!” – Interview with design purist, Will Grant Tips and tricks to optimize your responsive web design  

JavaScript developers are keenly aware of the need to reduce the size of deployed assets, especially in today's world of single-page apps. This usually means running increasingly complex JavaScript codebases through build steps that produce a minified bundle for deployment. However, if you read a typical tutorial on setting up a build tool like Browserify or Webpack, you'll see numerous references to a variable called process.env.NODE_ENV. Tutorials always talk about how this needs to be set to a value like "production" in order to produce a properly optimized bundle, but most articles never really spell out why this value matters and how it relates to build optimization. Here's an explanation of why process.env.NODE_ENV is used and how it fits into the typical build process. Operating system environment variables are widely used as a method of configuring applications, especially as a way to activate behavior based on different deployment environments (such as development vs testing vs production). Node.js exposes the current process's environment variables to the script as an object called process.env. From there, the Express web server framework popularized using an environment variable called NODE_ENV as a flag to indicate whether the server should be running in "development" mode vs "production" mode. At runtime, the script looks up that value by checking process.env.NODE_ENV. Because it was used within the Node ecosystem, browser-focused libraries also started using it to determine what environment they were running in, and using it to control optimizations and debug mode behavior. For example, React uses it as the equivalent of a C preprocessor #ifdef to act as conditional checking for debug logging and perf tracking, roughly like this: function someInternalReactFunction() { // do actual work part 1 if(process.env.NODE_ENV === "development") { // do debug-only work, like recording perf stats } // do actual work part 2 } If process.env.NODE_ENV is set to "production", all those if clauses will evaluate to false, and the potentially expensive debug code won't run. In addition, in conjunction with a tool like UglifyJS that does minification and removal of dead code blocks, a clause that is surrounded with if(process.env.NODE_ENV === "development") will become dead code in a production build and be stripped out, thus reducing bundled code size and execution time. However, because the NODE_ENV environment variable and the corresponding process.env.NODE_ENV runtime field are normally server-only concepts, by default those values do not exist in client-side code. This is where build tools such as Webpack's DefinePlugin or the Browserify Envify transform come in, which perform search-and-replace operations on the original source code. Since these build tools are doing transformation of your code anyway, they can force the existence of global values such as process.env.NODE_ENV. (It's also important to note that because DefinePlugin in particular does a direct text replacement, the value given to DefinePlugin must include actual quotes inside of the string itself. Typically, this is done either with alternate quotes, such as '"production"', or by using JSON.stringify("production")). Here's the key: the build tool could set that value to anything, based on any condition that you want, as you're defining your build configuration. For example, I could have a webpack.production.config.js Webpack config file that always uses the DefinePlugin to set that value to "production" throughout the client-side bundle. It wouldn't have to be checking the actual current value of the "real" process.env.NODE_ENV variable while generating the Webpack config, because as the developer I would know that any time I'm doing a "production" build, I would want to set that value in the client code to "production'. This is where the "code I'm running as part of my build process" and "code I'm outputting from my build process" worlds come together. Because your build script is itself most likely to be JavaScript code running under Node, it's going to have process.env.NODE_ENV available to it as it runs. Because so many tools and libraries already share the convention of using that field's value to determine their dev-vs-production status, the common convention is to use the current value of that field inside the build script as it's running to also determine the value of that field as applied to the client code being transformed. Ultimately, it all comes down to a few key points: NODE_ENV is a system environment variable that Node exposes into running scripts. It's used by convention to determine dev-vs-prod behavior, by both server tools, build scripts, and client-side libraries. It's commonly used inside of build scripts (such as Webpack config generation) as both an input value and an output value, but the tie between the two is still just convention. Build tools generally do a transform step on the client-side code, replace any references to process.env.NODE_ENV with the desired value, and the resulting code will contain dead code blocks as debug-only code is now inside of an if(false)-type condition, ensuring that code doesn't execute at runtime. Minifier tools such as UglifyJS will strip out the dead code blocks, leaving the production bundle smaller. So, the next time you see process.env.NODE_ENV mentioned in a build script, hopefully you'll have a much better idea why it's there. About the author Mark Erikson is a software engineer living in southwest Ohio, USA, where he patiently awaits the annual heartbreak from the Reds and the Bengals. Mark is author of the Redux FAQ, maintains the React/Redux Links list and Redux Addons Catalog, and occasionally tweets at @acemarke. He can be usually found in the Reactiflux chat channels, answering questions about React and Redux. He is also slightly disturbed by the number of third-person references he has written in this bio!

In this post, you will learn how to write a Node.js MapReduce application and how to run it on Amazon EMR. You don’t need to be familiar with Hadoop or EMR API's. In order to run the examples, you will need a Github account, an Amazon AWS, some money to spend at AWS, and Bash or an equivalent installed on your computer. EMR, BigData, and MapReduce We define BigData as those data sets too large or too complex to be processed by traditional processing applications. BigData is also a relative term: A data set can be too big for your Raspberry PI, while being a piece of cake for your desktop. What is MapReduce? MapReduce is a programming model that allows data sets to be processed in a parallel and distributed fashion. How does it work? You create a cluster and feed it with the data set. Then, you define a mapper and a reducer. MapReduce involves the following three steps: Mapping step: This breaks down the input data into KeyValue pairs Shuffling step: KeyValue pairs are grouped by Key Reducing step: KeyValue pairs are processed by Key in parallel It’s guaranteed that all data belonging to a single key will be processed by a single reducer instance. Our processing job project directory setup Today, we will implement a very simple processing job: counting unique words from a set of text files. The code for this article is hosted at Here. Let's set up a new directory for our project: $ mkdir -p emr-node/bin $ cd emr-node $ npm init --yes $ git init We also need some input data. In our case, we will download some books from project Gutenberg as follows: $ mkdir data $ curl -Lo data/tmohah.txt http://www.gutenberg.org/ebooks/45315.txt.utf-8 $ curl -Lo data/mad.txt http://www.gutenberg.org/ebooks/5616.txt.utf-8 Mapper and Reducer As we stated before, the mapper will break down its input into KeyValue pairs. Since we use the streaming API, we will read the input form stdin. We will then split each line into words, and for each word, we are going to print "word1" to stdout. TAB character is the expected field separator. We will see later the reason for setting "1" as the value. In plain Javascript, our ./bin/mapper can be expressed as: #!/usr/bin/env node const readline = require('readline'); const rl = readline.createInterface({ input : process.stdin }); rl.on('line', function(line){ line.trim().split(' ').forEach(function(word){ console.log(`${word}t1`); }); }); As you can see, we have used the readline module (a Node built-in module) to parse stdin. Each line is broken down into words, and each word is printed to stdout as we stated before. Time to implement our reducer. The reducer expects a set of KeyValue pairs, sorted by key, as input, such as the following: First<TAB>1 First<TAB>1 Second<TAB>1 Second<TAB>1 Second<TAB>1 We then expect the reducer to output the following: First<TAB>2 Second<TAB>3 Reducer logic is very simple and can be expressed in pseudocode as: IF !previous_key previous_key = current_key counter = value IF previous_key equals current_key counter = counter + value ELSE print previous_key<TAB>counter previous_key = current_key; counter = value; The first statement is necessary to initialize the previous_key and counter variables. Let's see the real JavaScript implementation of ./bin/reducer: #!/usr/bin/env node var previousKey, counter; const readline = require('readline'); const rl = readline.createInterface({ input : process.stdin }); function print(){ console.log(`${previousKey}t${counter}`); } function countWord(line) { let [currentKey, value] = line.split('t'); value = +value; if(typeof previousKey === 'undefined'){ previousKey = currentKey; counter = value; return; } if(previousKey === currentKey){ counter = counter + value; return; } print(); previousKey = currentKey; counter = value; } process.stdin.on('end',function(){ print(); }); rl.on('line', countWord); Again, we use readline module to parse stdin line by line. The countWord function implements our reducer logic described before. The last thing we need to do is to set execution permissions to those files: chmod +x ./bin/mapper chmod +x ./bin/reducer How do I test it locally? You have two ways to test your code: Install Hadoop and run a job With a simple shell script The second one is my preferred one for its simplicity: ./bin/mapper <<EOF | sort | ./bin/reducer first second first first second first EOF It should print the following: first<TAB>4 second<TAB>2 We are now ready to run our job in EMR! Amazon environment setup Before we run any processing job, we need to perform some setup on the AWS side. If you do not have an S3 bucket, you should create one now. Under that bucket, create the following directory structure: <your bucket> ├── EMR │ └── logs ├── bootstrap ├── input └── output Upload our previously downloaded books from project Gutenberg to the input folder. We also need AWS cli installed on the computer. You can install it with the python package manager. If you do not have AWS cli installed on your computer, then run: $ sudo pip install awscli awscli requires some configuration, so run the following and provide the requested data: $ aws configure You can find this data in your Amazon AWS web console. Be aware that usability is not Amazon’s strongest point. If you do not have your IAM EMR roles yet, it is time to create them: aws emr create-default-roles Good. You are now ready to deploy your first cluster. Check out this (run-cluster.sh) script: #!/bin/bash MACHINE_TYPE='c1.medium' BUCKET='pngr-emr-demo' REGION='eu-west-1' KEY_NAME='pedro@triffid' aws emr create-cluster --release-label 'emr-4.0.0' --enable-debugging --visible-to-all-users --name PNGRDemo --instance-groups InstanceCount=1,InstanceGroupType=CORE,InstanceType=$MACHINE_TYPE InstanceCount=1,InstanceGroupType=MASTER,InstanceType=$MACHINE_TYPE --no-auto-terminate --enable-debugging --log-uri s3://$BUCKET/EMR/logs --bootstrap-actions Path=s3://$BUCKET/bootstrap/bootstrap.sh,Name=Install --ec2-attributes KeyName=$KEY_NAME,InstanceProfile=EMR_EC2_DefaultRole --service-role EMR_DefaultRole --region $REGION The previous script will create a 1 master, 1 core cluster, which is big enough for now. You will need to update this script with your bucket, region, and key name. Remember that your keys are listed at "AWS EC2 console/Key pairs". Running this script will print something like the following: { "ClusterId": "j-1HHM1B0U5DGUM" } That is your cluster ID and you will need it later. Please visit your Amazon AWS EMR console and switch to your region. Your cluster should be listed there. It is possible to add the processing steps with either the UI or aws cli. Let's use a shell script (add-step.sh): #!/bin/bash CLUSTER_ID=$1 BUCKET='pngr-emr-demo' OUTPUT='output/1' aws emr add-steps --cluster-id $CLUSTER_ID --steps Name=CountWords,Type=Streaming,Args=[-input,s3://$BUCKET/input,-output,s3://$BUCKET/$OUTPUT,-mapper,mapper,-reducer,reducer] It is important to point out that our "OUTPUT" directory does not exist at S3 yet. Otherwise, the job will fail. Call ./add-step.sh plus the cluster ID to add our CountWords step: ./add-step j-1HHM1B0U5DGUM Done! So go back to the Amazon UI, reload the cluster page, and check the steps. "CountWords" step should be listed there. You can track job progress from the UI (reload the page) or from the command line interface. Once the job is done, terminate the cluster. You will probably want to configure the cluster to terminate as soon as it finishes or when any step fails. Termination behavior can be specified with the "aws emr create-cluster". Sometimes the bootstrap process can be difficult. You can SSH into the machines, but before that, you will need to modify their security groups, which are listed at "EC2 web console/security groups". Where to go from here? You can (and should) break down your processing jobs into smaller steps because it will simplify your code and add more composability to your steps. You can compose more complex processing jobs by using the output of a step as the input for the next step. Imagine that you have run the "CountWords" processing job several times and now you want to sum the outputs. Well, for that particular case, you just add a new step with an "identity mapper" and your already built reducer, and feed it with all of the previous outputs. Now you can see why we output "WORD1" from the mapper. About the author Pedro Narciso García Revington is a Senior Full Stack Developer with 10+ years of experience in high scalability and availability, microservices, automated deployments, data processing, CI, (T,B,D)DD, and polyglot persistence.

Bill Gates is quoted as saying that we tend to overestimate the pace of change over a period of 2 years, but underestimate change over a decade. It’s an astute observation: much of what will matter in 2019 actually looks a lot like what we said will be important in development this year. But if you look back 10 years, the change in the types of applications and websites we build - as well as how we build them - is astonishing. The web as we understood it in 2008 is almost unrecognisable. Today, we are in the midst of the app and API economy. Notions of surfing the web sound almost as archaic as a dial up tone. Similarly, the JavaScript framework boom now feels old hat - building for browsers just sounds weird... So, as we move into 2019, progressive web apps, artificial intelligence, and native app development remain at the top of development agenda. But this doesn’t mean these changes are to be ignored as empty hype. If anything, as adoption increases and new tools emerge, we will begin to see more radical shifts in ways of working. The cutting edge will need to sharpen itself elsewhere. What will it mean to be a web developer in 2019? But these changes are enforcing wider changes in the industry. Arguably, it’s transforming what it means to be a web developer. As applications become increasingly lightweight (thanks to libraries and frameworks like React and Vue), and data becomes more intensive, thanks to the range of services upon which applications and websites depend, developers need to expand across the stack. You can see this in some of the latest Packt titles - in Modern JavaScript Web Development Cookbook, for example, you’ll learn microservices and native app development - topics that have typically fallen outside of the strict remit of web development. The simplification of many aspects of development has, ironically, forced developers to look more closely at how these aspects fit together. As you move further into layers of abstraction, the way things interact and work alongside each other become vital. For the most part, it’s no longer a case of writing the requisite code to make something run on the specific part of the application you’re working on, it’s rather about understanding how the various pieces - from the backend to the front end - fit together. This means, in 2019, you need to dive deeper and get to know your software systems inside out. Get comfortable with the backend. Dive into cloud. Start playing with microservices. Rethink and revisit languages you thought you knew. Get to know your infrastructure: tackling the challenges of API development It might sound strange, but as the stack shrinks and the responsibilities of developers - web and otherwise - shift, understanding the architectural components within the software their building is essential. You could blame some of this on DevOps - essentially, it has made developers responsible for how their code runs once it hits production. Because of this important change, the requisite skills and toolchain for the modern developer is also expanding. There are a range of routes into software architecture, but exploring API design is a good place to begin. Hands on RESTful API Design offers a practical way into the topic. While REST is the standard for API design, the diverse range of tools and approaches is making managing the client a potentially complex but interesting area. GraphQL, a query language developed by Facebook is said to have killed off REST (although we wouldn’t be so hasty), while Redux and Relay, two libraries for managing data in React applications, have seen a lot of interest over the last 12 months as two key tools for working with APIs. Want to get started with GraphQL? Try Beginning GraphQL. Learn Redux with Learning Redux.       Microservices: take responsibility for your infrastructure The reason that we’re seeing so many tools offering ways of managing APIs is that microservices are becoming the dominant architectural mode. This requires developer attention too. That’s not to say that you need to implement microservices now (in fact, there are probably many reasons not to), but if you want to be building software in 5 years time, getting to grips with the principles behind microservices and the tools that can help you use them. Perhaps one of the central technologies driving microservices are containers. You could run microservices in a virtual machine, but because they’re harder to scale than containers, you probably wouldn’t be seeing the benefits you’d be expecting from a microservices architecture. This means getting to grips with core container technologies is vital. Docker is the obvious place to start. There are varying degrees to which developers need to understand it, but even if you don’t think you’ll be using it immediately it does give you a nice real-world foundation in containers if you don’t already have one. Watch and learn how to put Docker to work with the Hands on Docker for Microservices video.  But beyond Docker, Kubernetes is the go to tool that allows you to scale and orchestrate containers. This gives you control over how you scale application services in a way that you probably couldn’t have imagined a decade ago. Get a grounding in Kubernetes with Getting Started with Kubernetes - Third Edition, or follow a 7 day learning plan with Kubernetes in 7 Days. If you want to learn how Docker and Kubernetes come together as part of a fully integrated approach to development, check out Hands on Microservices with Node.js. It's time for developers to embrace cloud It should come as no surprise that, if the general trend is towards full stack, where everything is everyone’s problem, that developers simply can’t afford to ignore cloud. And why would you want to - the levels of abstraction it offers, and the various services and integrations that come with the leading cloud services can make many elements of the development process much easier. Issues surrounding scale, hardware, setup and maintenance almost disappear when you use cloud. That’s not to say that cloud platforms don’t bring their own set of challenges, but they do allow you to focus on more interesting problems. But more importantly, they open up new opportunities. Serverless becomes a possibility - allowing you to scale incredibly quickly by running everything on your cloud provider, but there are other advantages too. Want to get started with serverless? Check out some of these titles… JavaScript Cloud Native Development Cookbook Hands-on Serverless Architecture with AWS Lambda [Video] Serverless Computing with Azure [Video] For example, when you use cloud you can bring advanced features like artificial intelligence into your applications. AWS has a whole suite of machine learning tools - AWS Lex can help you build conversational interfaces, while AWS Polly turns text into speech. Similarly, Azure Cognitive Services has a diverse range of features for vision, speech, language, and search. What cloud brings you, as a developer, is a way of increasing the complexity of applications and processes, while maintaining agility. Adding in features and optimizations previously might have felt sluggish - maybe even impossible. But by leveraging AWS and Azure (among others), you can do much more than you previously realised. Back to basics: New languages, and fresh approaches With all of this ostensible complexity in contemporary software development, you’d be forgiven for thinking that languages simply don’t matter. That’s obviously nonsense. There’s an argument that gaining a deeper understanding of how languages work, what they offer, and where they may be weak, can make you a much more accomplished developer. Be prepared is sage advice for a world where everything is unpredictable - both in the real world and inside our software systems too. So, you have two options - and both are smart. Either go back to a language you know and explore a new paradigm or learn a new language from scratch. Learn a new language: Kotlin Quick Start Guide Hands-On Go Programming Mastering Go Learning TypeScript 2.x - Second Edition     Explore a new programming paradigm: Functional Programming in Go [Video] Mastering Functional Programming Hands-On Functional Programming in RUST Hands-On Object-Oriented Programming with Kotlin     2019: the same, but different, basically... It's not what you should be saying if you work for a tech publisher, but I'll be honest: software development in 2019 will look a lot like it has in 2018.  But that doesn't mean you have time to be complacent. In just a matter of years, much of what feels new or ‘emerging’ today will be the norm. You don’t have to look hard to see the set of skills many full stack developer job postings are asking for - the demands are so diverse that adaptability is clearly immensely valuable both for your immediate projects and future career prospects. So, as 2019 begins, commit to developing yourself sharpening your skill set.

Before I begin, one thing that needs to be established, is we can’t for a second ignore the fact that we are going to compare two different JavaScript frameworks - React and Vue. Both frameworks are clearly different in terms of popularity and usage. While ReactJS is a JavaScript library, great for building huge web applications where data can be updated on a regular basis. Vue.js is a JavaScript framework, fit for creating highly adaptable user interfaces and sophisticated Single-page applications. On the other hand, we all have mostly come across is how React and Vue are similar in their fundamental approach. They both have a virtual DOM based approach; they both have component based structure and are Reactive in their architecture. They both tend to work around a root library with all the other tasks transferred to other libraries. Having said that, as per npm trends report, React stands well ahead in terms of monthly downloads at 2.4 million whereas Vue stands joint second with Angular at around 239k downloads. Now that we have established the popularity of front end web development frameworks, it’s time to talk about what works and what doesn’t in React and Vue.js. Comparing React.js and Vue.js Template vs JSX While everything in React is a JavaScript code written in JSX syntax, Vue depends majorly on its templates which are HTML5 and CSS3 based. Now if you are a front end developer how can this possibly affect you? Well it depends on your choice of working methodology. If you want to write code on your own and control every aspect of your application, then the React way will be much more suitable for you. But if you want to start working on a readymade template and then add features as you go then Vue should be your best choice. React is a better framework if you want to scale up Make no mistake about this. The size and scalability of your application plays a determining role on your choice of framework. The fact that React gives you more control over your application architecture is the single most reason why it is easier in React to scale up your application. But since Vue is so much dependent inherently on the templating structure, it becomes tough when to build an industrial grade application made with Vue as changing the template can be difficult. It's easier to update data with Vue than React Updating data on Vue is much simpler. The middle stage of transpiling is not needed in Vue as it directly renders into the browser and hence the process is faster. Whereas in React, the data is analyzed, then stored, then the Document Object Model (DOM) is invoked and thereafter the change takes place, which is a time consuming process. React has a bigger community than Vue React is backed by Facebook. There are many similar libraries like React such as Preact which render support to React making it a  larger community than Vue. And with larger communities developers can expect faster resolution of issues and regular community support with timely updates. Building for mobile with React and Vue The capabilities of all modern day frameworks are often judged in terms of how they allow developers build for mobile. React has a world class companion in this domain: React Native. React Native is very similar to React in terms of its component structure, and is a fairly short learning curve for anyone already using React. The introduction of Vue Native, which offers a way of writing mobile applications with NativeScript using Vue, has made it easier for mobile developers to use Vue mobile development. Chinese tech company Alibaba has also created a cross platform framework called Weex. Weex has support for Vue, and while it doesn't yet have the capabilities of React Native, it could be a mobile framework to watch. Which is better? React or Vue? To summarize, there are different aspects of Vue and React which are useful and developer friendly. However if you intend to judge them on your own, you are better off assessing what your development needs are first? How big an issue scalability is going to be? Would you be needing something for the mobile platform too? Once you have figured out these questions, the choice should be easy. Read Next: What is React.js and how does it work Is React Native really a Native framework Using React Router for Client Side Redirecting

It's been a year of change and innovation in web development. We've seen Angular shifting quickly, React rising to dominate, and the surprising success of Vue.js. We've discussed what 'things' will matter in web development in 2018 here, but let's get down to the key tools you might be using or learning. Read what 5 trends and issues we think will matter in 2018 in web development here. 1. Vue.js If you remember back to 2016, the JavaScript framework debate centred on React and Angular. Which one was better? You didn't have to look hard to find Quora and Reddit threads, or Medium posts comparing and contrasting the virtues of one or the other. But in 2017, Vue has started to pick up pace to enter the running as a real competitor to the two hyped tools. What's most notable about Vue.js is simply how much people enjoy using it. The State of Vue.js report reported that 96% of users would use it for their next project. While it's clearly pointless to say that one tool is 'better' than another, the developer experience offered by Vue says a lot about what's important to developers - it's only likely to become more popular in 2018. Explore Vue eBooks and videos. 2.Webpack Webpack is a tool that's been around for a number of years but has recently seen its popularity grow. Again, this is likely down to the increased emphasis on improving the development experience - making development easier and more enjoyable. Webpack, is, quite simply brings all the assets you need in front end development - like JavaScript, fonts, and images, in one place. This is particularly useful if you're developing complicated front ends. So, if you're looking for something that's going to make complexity more manageable in 2018, we certainly recommend spending some time with Webpack. Learn Webpack with Deploying Web Applications with Webpack. 3. React Okay, you were probably expecting to see React. But why not include it? It's gone from strength to strength throughout 2017 and is only going to continue to grow in popularity throughout 2018. It's important though that we don't get caught up in the hype - that, after all, is one of the primary reasons we've seen JavaScript fatigue dominate the conversation. Instead, React's success is dependent on how we integrate it within our wider tech stacks - tools like webpack, for example. Ultimately, if React continues to allow developers to build incredible UI in a way that's relatively stress-free it won't be disappearing any time soon. Discover React content here. 4. GraphQL GraphQL might seem a little left field, but this tool built by Facebook has quietly been infiltrating its way into development toolchains since it was made public back in 2015. It's seen by some as software that's going to transform the way we build APIs. This article explains everything you need to know about GraphQL incredibly well, but to put it simply, GraphQL "is about designing your APIs more effectively and getting very specific about how clients access your data". Being built by Facebook, it's a tool that integrates very well with React - if you're interested, this case study by the New York Times explains how GraphQL and React played a part in their website redesign in 2017. Learn GraphQL with React and Relay. Download or stream our video. 5. WebAssembly While we don't want to get sucked into the depths of the hype cycle, WebAssembly is one of the newest and most exciting things in web development. WebAssembly is, according to the project site, "a new portable size- and load-time-efficient format suitable for the web". The most important thing you need to know is that it's fast - faster than JavaScript. "Unlike other approaches that require plug-ins to achieve near-native performance in the browser, WebAssembly runs entirely within the Web Platform. This means that developers can integrate WebAssembly libraries for CPU-intensive calculations (e.g. compression, face detection, physics) into existing web apps that use JavaScript for less intensive work" explains Mozilla fellow David Bryant in this Medium post. We think 2018 will be the year WebAssembly finally breaks through and makes it big - and perhaps offering a way to move past conversations around JavaScript fatigue.

Google apparently wants all the web developers to adopt the AMP approach for their websites. The AMP project was announced by Google on October 7, 2015, and AMP pages first became available to web users in February 2016. Mobile search is more popular presently as compared to desktop search. It is important for web pages to appear in Google’s mobile search results, and this is why AMP is not optional for web publishers. Without AMP, a publisher’s articles will be extremely unlikely to appear in the Top Stories carousel on mobile search in Google. This means the developers will have two options for them, either to design the complete app in the AMP format, or have two formats ready, one as per their own design considerations, the other as per the Google AMP format. Does that really work for the developers? We will try to address that question here in this article. The trouble with Web content - Searchability and Indexing The searchability of your application is heavily dependent on the structure & format of your app. To be found on Google search is dependant on how easily Google can crawl and index your application. The main challenge for indexing is the vast nature of internet and the wide variety of applications that exist. The absence of a structure or a particular format makes the task of checking website content and categorizing them very difficult. This was the primary reason why Google had come up with the idea of Accelerated Mobile Pages. The purpose of adopting AMP is to make all web and mobile applications conform to a certain structure, so that they can be easily classified and categorized. Since the implementation of ‘mobile first’ approach - an approach that puts more emphasis on the mobile platform and UI considerations for mobile devices, the AMP way has been slowly becoming the most preferred way of app designing. But the real question here is are developers adopting this particular design thinking willingly or are they finding themselves running out of other options with Google forcing its hand on how they design their apps. The Ground Realities of the Web - Diversity vs Uniformity The truth is that the internet is a diverse playing ground. It’s a place for information sharing. As such, the general consensus is not exactly in line with Google’s vision of a uniform web. Google started off as a search engine whose main task was to be the gateway of information - to lead people to the specific web addresses. From there on, they have evolved to be one of the leading beneficiaries of the world wide web. The next step in Google’s evolution seems to be quite natural to take control over content and hosting. Google has also recently announced that they are going to lay down undersea internet cable from Japan to Guam, and from Guam to Australia. They are portraying this decision as an economic decision which will save them money eventually after the cables are laid. But some are seeing this as a step to remove external dependencies and as a step closer to total control over the internet. Google’s recent partnering deal with WordPress is a proof that Google is taking steps towards owning up the web hosting space. AMP specification means that Google will have the final say over design specifications. The diversity in design will suffer as you would not want to spend time to design a site that won’t be indexed by Google. Hence the developers will only have two options, use the pre-designed template provided by Google, or make two specific website designs, one as per their own design consideration and the other one as per AMP. But Google will keep showing you error signs if your AMP version doesn’t match the main design. Hence the choice finally narrows down to choosing AMP. The trouble with AMP Your content published using AMP is stored in a Google cache and hence repeated views are loaded from the cache. This also means that the user will actually spend more time in Google’s own page and will see Google’s ads and not the ones which the content creator had put up. This by extension means loss of revenue for the actual content creator. Using Analytics is far more difficult in AMP-based pages. The AMP pages are difficult to customize and hence difficult to design without looking similar. So the web might end up with similar looking apps with similar buttons and UIs all across. The AMP model takes its own decisions as per how it actually shows your content. So you don’t get to choose your metadata being displayed, but Google does. That means less control over your content. With Google controlling the extent to which your website data is displayed, all the pages are going to look similar with very little metadata info shown, fake stories will appear parallel to normal news thumbnails because there will be very little text displayed to enable to make a call, whether a story is true or false. All of these come with the caveat that AMPed up pages will rank higher on Google. If that’s the proverbial carrot used to lure web publishers to bring their content under Google’s umbrella, then we must say that it’s going to be a tricky choice for developers. No one wants a slow web with irregular indexing and erroneous search results. But how far are we prepared to let go of individuality and design thinking in this process, that’s a question to ponder about. Google wants web developers to embrace AMP. Great news for users, more work for developers. Like newspapers, Google algorithms are protected by the First Amendment Implementing Dependency Injection in Google Guice

Tomorrow, on Wednesday 12 September, the European Parliament will vote on amendments to the EU Copyright Bill, first proposed back in September 2016. This bill could have a huge impact on open source, software engineering, and even the future of the internet. Back in July, MEPs voted down a digital copyright bill that was incredibly restrictive. It asserted the rights of large media organizations to tightly control links to their stories, copyright filters on user generated content. https://twitter.com/EFF/status/1014815462155153408 The vote tomorrow is an opportunity to amend aspects of the directive - that means many of the elements that were rejected in July could still find their way through. What parts of the EU copyright directive are most important for software developers? There are some positive aspects of the directive. To a certain extent, it could be seen as evidence of the European Union continuing a broader project to protect citizens by updating digital legislation - a move that GDPR began back in May 2018. However, there are many unintended consequences of the legislation. It's unclear whether the negative impact is down to any level of malicious intent from law makers, or is simply reflective of a significant level of ignorance about how the web and software works. There are 3 articles within the directive that developers need to pay particular attention to. Article 13 of the EU copyright directive: copyright filters Article 13 of the directive has perhaps had the most attention. Essentially, it will require "information society service providers" - user-generated information and content platforms - to use "recognition technologies" to protect against copyright infringement. This could have a severe impact on sites like GitHub, and by extension, the very philosophy of open collaboration and sharing on which they're built. It's for this reason that GitHub has played a big part in educating Brussels law makers about the possible consequences of the legislation. Last week, the platform hosted an event to discuss what can be done about tomorrow's vote. In it, Marten Mickos, CEO of cybersecurity company Hacker One gave a keynote speech, saying that "Article 13 is just crap. It will benefit nobody but the richest, the wealthiest, the biggest - those that can spend tens of millions or hundreds of millions on building some amazing filters that will somehow know whether something is copyrighted or not." https://youtu.be/Sm_p3sf9kq4 A number MEPs in Brussels have, fortunately, proposed changes that would exclude software development platforms to instead focus the legislation on sites where users upload music and video. However, for those that believe strongly in an open internet, even these amendments could be a small compromise that not only places an unnecessary burden on small sites that simply couldn't build functional copyright filters, but also opens a door to censorship online. A better alternative could be to ditch copyright filters and instead opt for licensing agreements instead. This is something put forward by German politician Julia Reda - if you're interested in policy amendments you can read them in detail here. [caption id="attachment_22485" align="alignright" width="300"] Image via commons.wikimedia.org[/caption] Julia Reda is a member of the Pirate Party in Germany - she's a vocal advocate of internet freedoms and an important voice in the fight against many of the directive (she wants the directive to be dropped in its entirety). She's put together a complete list of amendments and alternatives here. Article 11 of the EU Copyright Directive: the "link tax" Article 11 follows the same spirit of article 13 of the bill. It gives large press organizations more control over how their content is shared and linked to online. It has been called the "link tax" - it could mean that you would need a license to link to content. According to news sites, this law would allow them to charge internet giants like Facebook and Google that link to their content. As Cory Doctorow points out in an article written for Motherboard in June, only smaller platforms would lose out - the likes of Facebook and Google could easily manage the cost. But there are other problems with article 11. It could, not only, as Doctorow also writes, "crush scholarly and encyclopedic projects like Wikipedia that only publish material that can be freely shared," but it could also "inhibit political discussions". This is because the 'link tax' will essentially allow large media organizations to fully control how and where their content is shared. "Links are facts" Doctorow argues, meaning that links are a vital component within public discourse, which allows the public to know who thinks what, and who said what. Article 3 of the EU Copyright Directive: restrictions on data mining Article 3 of the directive hasn't received as much attention as the two above, but it does nevertheless have important implications for the data mining and analytics landscape. Essentially, this proportion of the directive was originally aimed at posing restrictions on the data that can be mined for insights except in specific cases of scientific research. This was rejected by MEPs. However, it is still an area of fierce debate. Those that oppose it argue that restrictions on text and data mining could seriously hamper innovation and hold back many startups for whom data is central to the way they operate. However, given the relative success of GDPR in restoring some level of integrity to data (from a citizen's perspective), there are aspects of this article that might be worth building on as a basis for a compromise. With trust in a tech world at an all time low, this could be a stepping stone to a more transparent and harmonious digital domain. An open internet is worth fighting for - we all depend on it The difficulty unpicking the directive is that it's not immediately clear who its defending. On the one hand, EU legislators will see this as something that defends citizens from everything that they think is wrong with the digital world (and, let's be honest, there are things that are wrong with it). Equally, those organizations lobbying for the change will, as already mentioned, want to present this as a chance to knock back tech corporations that have had it easy for too long. Ultimately, though, the intention doesn't really matter. What really matters are the consequences of this legislation, which could well be catastrophic. The important thing is that the conversation isn't owned by well-intentioned law makers that don't really understand what's at stake, or media conglomerates with their own interests in protecting their content from the perceived 'excesses' of a digital world whose creativity is mistaken for hostility. If you're an EU citizen, get in touch with your MEP today. Visit saveyourinternet.eu to help the campaign. Read next German OpenStreetMap protest against “Article 13” EU copyright reform making their map unusable YouTube’s CBO speaks out against Article 13 of EU’s controversial copyright law

If you’re a backend developer, it’s easy to feel overwhelmed by the range of backend development tools available. It goes without saying that you should use what works for you but sometimes it’s not that easy to even work that out. With this in mind, this year’s Skill Up report offers a useful insight into some of the most popular backend tools being used today. Let’s take a look at what tools came out on top. That should help you make decisions about what you’re going to use or maybe even just learn. Read the Skill Up report in full. Sign up to our weekly newsletter and download the PDF for free. Node.js More than 50% respondents said, they prefer Node.js, the popular server-side Javascript coding framework. Node.js is a Javascript runtime that runs on the V8 JavaScript runtime engine. Node.js adds capabilities to Javascript (front-end language) to let it do more than just creating interactive websites. It uses an event-driven, non-blocking I/O model that makes it lightweight and efficient. The latest stable release of Node, Node 10, will be the next candidate in line for the Long Term Support (LTS) in October 2018. Node.js 10.0 comes with plenty of new features like OpenSSL 1.1.0 security toolkit, upgraded npm, N-API, and much more. Get started with learning Node.js with the following books: Learning Node.js Development Learn Node.js by Building 6 Projects RESTful Web API Design with Node.js 10 - Third Edition ASP.NET Core The next popular alternative was ASP. NET Core with over 25% developers approving it as their choice of backend framework. ASP.NET Core is the open-source cross-platform framework for building backends, web apps and services, and IoT apps. According to the skill-up survey, it was also one of the most popular framework used by developers. It provides a cloud-ready, environment-based configuration system. It seamlessly integrates with popular client-side frameworks and libraries, including Angular, React, and Bootstrap. Get started with ASP.NET Core by reading: Learning ASP.NET Core 2.0 Mastering ASP.NET Core 2.0 ASP.NET Core 2 High Performance - Second Edition Express.js Developers and tech pros also like to work with Express JS, and hence it ranked No. 3 on our list. Express JS is the pre-built Node JS framework that can help developers build faster and smarter websites and web apps. Express basically extends Node.js to build complete web apps. It is the perfect framework to learn for developers, who are fluent in Node.js, but want to transition to creating apps from just server-side technologies. Express is lightweight and comes with extra, built-in web application features and the Express API to support the already robust, feature-packed Node.js platform. Express is not just limited to NodeJS. It also works seamlessly with other modules and offers HTTP utilities and middleware for creating APIs. It can help developers master single-page and multiple-page websites, as well as some complex web apps. You can go through Projects in ExpressJS [Video], a complete course to learn professional web development using Express.js. Laravel Next, was Laravel, a prominent member of a new generation of web frameworks. It is one of the most popular PHP frameworks and is also free and and open source. It features: A simple, fast routing engine Powerful dependency injection container Multiple back-ends for session and cache storage Database agnostic schema migrations Robust background job processing Real-time event broadcasting The latest stable release, Laravel 5 is a substantial upgrade with a lot of new toys, at the same time retaining the features that made Laravel wildly successful. It comes with plenty of architectural as well as design-based changes. Start building with Laravel with these videos. Beginning Laravel [Video] Laravel Foundations: Basics to Every App [Video] Java EE The fifth most popular choice of backend tool is the Java EE. The Enterprise Java standard or Java EE is a collection of technologies and APIs for the Java platform designed to support Enterprise. By enterprise, we mean applications classified as large-scale, distributed, transactional and highly-available, designed to support mission-critical business requirements. Applications written to comply with the Java EE specification do not tie developers to a specific vendor; instead, they can be deployed to any Java EE compliant application server. The Java EE server application implements the Java EE platform APIs and provides the standard Java EE services. The latest stable release, Java EE 8 brings with it a load of features, mainly targeting newer architectures such as microservices, modernized security APIs, and cloud deployments. Our best picks for learning Java EE: Java EE 8 Application Development Architecting Modern Java EE Applications Java EE 8 High Performance The other backend tools which were among the top picks by developers included: Spring, a programming and configuration model for building modern Java-based enterprise applications, on any kind of deployment platform. Django, a powerful Python web framework for creating RESTful web services. It reduces the amount of trivial code, which simplifies the creation of web applications and results in faster development. Flask, a framework for building web servers in Python. It is a micro framework, meaning it’s not a full stack web application development framework. It just gives the developers very basics to get a web server running. Firebase, Google’s mobile platform to help developers run mobile backend code without managing servers and develop high-quality apps. Ruby on Rails, one of the oldest, backend technology. A certain percentage of people still prefer using ruby on rails for their backend code. Rails is a flexible and IDE friendly framework with easy functions and manipulations and the support of the powerful ruby language. The entire skill up survey report can be read on the Packt website, which details on what developers think about the changing tech landscape and the parameters that are driving that change. This survey report is launched at the start of the Skill Up campaign, where every eBook and video will be available for $10. Go grab your free content now!

On-demand apps almost came as a movement in the digital world and transformed the way we avail services and ready-to-use business deliverables. -E-commerce stores like Amazon and eBay were the first on-demand apps and over time the business model penetrated across other niches. Now, from booking a taxi ride online to booking food delivery to booking accommodation in a distant city, on-demand apps are making spaces for every different customer interaction. As these on-demand apps are gradually building the foundation for a fully-fledged on-demand economy, the future of e-commerce will depend on how new and cutting-edge features are introduced and how the user experience can be boosted with new UI and UX elements. But before taking a look into the future of on-demand e-commerce, it is essential to understand the evolution of the on-demand apps in recent years.   Let us have a brief look at various facets of this ongoing evolution.   Mobile-push for change: Already mobile search has surpassed desktop search in both volume and frequency. Moreover, mobile has become a lifestyle factor allowing instant access to services and contents. It is a mobile device’s round the clock connectivity and ease of keeping in constant touch that has made it a key to the thriving on-demand economy.   Overwhelming Social Media penetration: The penetration of social media across all spheres of life has helped people staying connected while communicating almost on anything and everything, giving businesses a never-before opportunity to cater to the customer demands. Addressing value as well as a convenience: With the proliferation of on-demand apps, we can see two gross categories of consumers- the value-oriented and the convenience-oriented consumers. Besides giving priority to more value at a lesser cost, the on-demand apps are now facilitating more convenient and timely delivery of products. Frictionless business process: Allowing easy and smooth purchase with least friction in the business process has become the subject of demand for most consumers. Frictionless and smooth customer experience and delivery are the two most important criteria that on-demand apps fulfill.   How to cater to customers with on-demand e-commerce apps? If as a business you want to cater to your customers with on-demand apps, there are several ways you can do that. When providing customers more value is your priority, you can only ensure this with easier, connected and smooth e-shopping experience. 4 specific ways you can cater to your customers with on-demand e-commerce apps. By trying and testing various services, you can easily get a first-hand feel of how these services work. Next, evaluate what the services do best and what they don’t. Now, think about how you can deliver a better service for your customers. To transform your existing business into an on-demand business, you can also partner with a service provider who can ensure same-day delivery of your products to the customers. You can partner with services like Google Express, Instacart, Amazon, PostMates, Google Express, Uber Rush, etc. You can also utilize the BOPUS (by online, pick up in store) model to cater to many customers who find this helpful. Always make sure to minimize the time and trouble for the customers to pick up products from your store. Providing on-site installation of the product can also boost customer experience. You can partner with a service provider to install the product and guide the customers about its usage. How on-Demand apps are transforming the face of business? The on-demand economy is experiencing a never-before boom and there are too many examples of how it has transformed businesses. The emergence of Uber and Airbnb is an excellent example of how on-demand apps deliver popular service for several daily needs. Just as Uber transformed the way we think of transport, Airbnb transformed the way we conceive booking accommodations and hotels in places of travel. Similarly, apps like Swiggy, Just Eat and Uber Eats are continuing to change the way we order foods from restaurants and food chains. The same business model is slowly penetrating across other niches and products. From the daily consumable goods to the groceries, now almost everything is being delivered through on-demand apps to our doorstep. Thanks to customer-centric UI and UX elements in mobile apps and an increasing number of businesses paving the way for unique and innovative shop fronts, personalization has become one of the biggest driving factors for on-demand mobile apps. Consumers also have got the taste of personalized shopping experience, and they are increasingly demanding products, services and shopping experience that suit their specific needs and preferences. This is one area where on-demand apps within the same niche are competitive in a bid to deliver better customer experience and win more business. The Future of On-demand eCommerce Apps The future of the on-demand e-commerce apps will mainly revolve around new concepts and breakthrough ideas of providing customers more ease and convenience. From gesture-based checkout and payment processing to product search through images to video chat, a lot of breakthrough features will shape the future of on-demand e-commerce apps. Conversational Marketing Unlike the conventional marketing channels that follow the one-way directive, in the new era of on-demand e-commerce apps, conversational marketing will play a bigger role. From intelligent Chatbots to real-time video chat communication, we have a lot of avenues to utilise conversational marketing methods. Image-Based Product Search By integrating image search technology with the e-commerce interfaces customers can be provided with an easy and effortless ways of searching for products online. They can take photos of nearby objects and can search for those items across e-commerce stores.   Real-time Shopping Apps What about getting access to products just when and where you need them? Well, such ease of shopping in real-time may not be a distant thing of the future, thanks to real-time shopping apps. Just when you need a particular product, you can shop it then and there and based upon availability, the order can be accepted and delivered from the nearest store in time. Gesture-Based Login Biometrics is already part and parcel of smart user experience. Gestures are also used in the latest mobile handsets for login and authentication. So, those days are not far when the gestures will be used for customer login and authentication in the e-commerce store. This will make the entire shopping experience easier, effortless and least time-consuming. Conclusion The future of on-demand e-commerce apps is bright. In the years to come, the on-demand apps are going to be more mainstream and commonplace to transform the business process and the way customers are served by retailers across the niches. Author Bio Atman Rathod is the Co-founder at CMARIX TechnoLabs Pvt. Ltd. with 13+ years of experience. He loves to write about technology, startups, entrepreneurship and business. His creative abilities, academic track record and leadership skills made him one of the key industry influencers as well. You can find him on Linkedin, Twitter, and Medium. Declarative UI programming faceoff: Apple’s SwiftUI vs Google’s Flutter What Elon Musk can teach us about Futurism & Technology Forecasting 12 Visual Studio Code extensions that Node.js developers will love [Sponsored by Microsoft]

The world is abuzz with automation. It is everywhere today and becoming an integral part of organizations and processes. Software testing, an intrinsic part of website/app/software development has also been taken over by test automation tools. However, as it happens in many software markets, a surplus of tools complicates the selection process. We have identified top 5 testing frameworks, used by most developers for automating the testing process. These automation testing frameworks cover a broad range of devices and support different scripting languages. Each framework has their own uniques pros, cons, and learning approaches. Selenium [box type="shadow" align="" class="" width=""]Creators: Jason Huggins Language: Java Current version: 3.11.0 Popularity: 11,031 stars on GitHub[/box] Selenium is probably the most popular test automation framework, primarily used for testing web apps.  However, selenium can also be used in cloud-based services, load-testing services and for monitoring, quality assurance, test architecture, regression testing, performance analysis, and mobile testing. It is open source; i.e., the source code can be altered and modified if you want to customize it for your testing purposes. It is flexible enough for you to write your own script and add functionality to test scripts and the framework. The Selenium suite consists of four different tools: Selenium IDE, Selenium Grid, Selenium RC, and Selenium WebDriver. It also supports a wide range of programming languages such as C#, Java, Python, PHP, Ruby, Groovy, and Perl. Selenium is portable, so it can be run anywhere, eliminating the need to configure it specifically for a particular machine. It becomes quite handy when you are working in varied environments and platforms supporting various system environments - Windows, Mac, Linux and browsers - Chrome, Firefox, IE, and Headless browsers. Most importantly, Selenium has a great community which implies more forums, more resources, examples, and solved problems. Appium [box type="shadow" align="" class="" width=""]Creators: Dan Cuellar Language: C# Current version: 1.8.1 Popularity: 7,432 stars on GitHub[/box] Appium is an open source test automation framework for testing native, hybrid, and mobile web applications. It allows you to run automated tests on actual devices, emulators (Android), and simulators (iOS). It provides cross-platform solutions for native and hybrid mobile apps, which means that the same test cases will work on multiple platforms (iOS, Android, Windows, Mac).  Appium also allows you to talk to other Android apps that are integrated with App Under Test (AUT). Appium has a client-server architecture. It extends the WebDriver client libraries, which are already written in most popular programming languages. So, you are free to use any programming language to write the automation test scripts. With Appium, you can also run your test scripts in the cloud using services such as Sauce Labs and Testdroid. Appium is available on GitHub with documentations and tutorial to learn all that is needed. The Appium team is alive, active, and highly responsive as far as solving an issue is concerned. Developers can expect a reply after no more than 36 hours, after an issue is opened. The community around Appium is also pretty large and growing every month. Katalon Studio [box type="shadow" align="" class="" width=""]Creators: Katalon LLC. Language: Groovy Current version: 5.4.2[/box] Katalon Studio is another test automation solution for web application, mobile, and web services. Katalon Studio uses Groovy, a language built on top of Java. It is built on top of the Selenium and Appium frameworks, taking advantage of these two for integrated web and mobile test automation. Unlike Appium, and Selenium, which are more suitable for testers who possess good programming skills, Katalon Studio can be used by testers with limited technical knowledge. Katalon Studio has a interactive UI with drag-drop features, select keywords and test objects to form test steps functionalities. It has a manual mode for technically strong users and a scripting mode that supports development facilities like syntax highlighting, code suggestion and debugging. On the down side, Katlon has to load many extra libraries for parsing test data, test objects, and for logging. Therefore, it may be a bit slower for long test cases as compared to other testing frameworks which use Java. Robot Framework [box type="shadow" align="" class="" width=""]Creators: Pekka Klärck, Janne Härkönen et al. Language: Python Current version: 3.0.4 Popularity: 2,393 stars on GitHub[/box] Robot Framework is a Python-based, keyword-driven, acceptance test automation framework. It is a general purpose test automation framework primarily  used for acceptance testing and streamlines it into mainstream development, thus giving rise to the concept of acceptance test driven development (ATDD). It was created by Pekka Klärck as part of his master's thesis and was developed within Nokia Siemens Networks in 2005. Its core framework is written in Python, but it also supports IronPython (.NET), Jython (JVM) and PyPy. The Keyword driven approach simplifies tests and makes them readable. There is also provision for creating reusable higher-level keywords from existing ones. Robot Framework stands out from other testing tools by working on easy-to-use tabular test files that provide different approaches towards test creation. It is the extensible nature of the tool that makes it so versatile. It can be adjusted into different scenarios and used with different software backend such as by using Python and Java libraries, and also via different API’s. Watir [box type="shadow" align="" class="" width=""]Creators: Bret Pettichord, Charley Baker, and more. Language: Ruby Current version: 6.7.2 Popularity: 1126 stars on GitHub[/box] Watir is powerful test automation tool based on a family of ruby libraries. It stands for Web Application Testing In Ruby. Watir can connect to databases, export XML, and structure code as reusable libraries, and read data files and spreadsheets all thanks to Ruby. It supports cross-browser and data-driven testing and the tests are easy to read and maintain. It also integrates with other BBD tools such as Cucumber, Test/Unit, BrowserStack or SauceLabs for cross-browser testing and Applitools for visual testing. Whilst Watir supports only Internet Explorer on Windows, Watir-WebDriver, the modern version of the Watir API based on Selenium,  supports Chrome, Firefox, Internet Explorer, Opera and also can run in headless mode (HTMLUnit). [dropcap]A[/dropcap]ll the frameworks that we discussed above offer unique benefits based on their target platforms and respective audiences. One should avoid selecting a framework based solely on technical requirements. Instead, it is important to identify what is suitable to developers, their team, and the project. For instance, even though general-purpose frameworks cover a broad range of devices, they often lack hardware support. And frameworks which are device-specific often lack support for different scripting languages and approaches. Work with what suits your project and your team requirements best. Selenium and data-driven testing: An interview with Carl Cocchiaro 3 best practices to develop effective test automation with Selenium Writing Your First Cucumber Appium Test

A UX practitioner's primary goal is to provide every user with the best possible experience of a product. The only way to do this is to connect repeatedly with users and make sure that the product is being designed according to their needs. At the beginning of a project, this research tends to be more exploratory. Towards the end of the project, it tends to be more about testing the product. In this article, we explore in detail one of the most common methods of testing a product with users--the usability test. We will describe the steps to plan and conduct usability tests. Usability tests provide insights into how to practically plan, conduct, and analyze any user research. This article is an excerpt from the book UX for the Web by Marli Ritter, and Cara Winterbottom. This book teaches you how UX and design thinking can make your site stand out from the rest of the sites on the internet. Tips to maximize the value of user testing Testing with users is not only about making their experience better; it is also about getting more people to use your product. People will not use a product that they do not find useful, and they will choose the product that is most enjoyable and usable if they have options. This is especially the case with the web. People leave websites if they can't find or do things they want. Unlike with other products, they will not take time to work it out. Research by organizations such as the Nielsen Norman group generally shows that a website has between 5 and 10 seconds to show value to a visitor. User testing is one of the main methods available to us to ensure that we make websites that are useful, enjoyable, and usable. However, to be effective it must be done properly. Jared Spool, a usability expert, identified seven typical mistakes that people make while testing with users, which lessen its value. The following list addresses how not to make those mistakes: Know why you're testing: What are the goals of your test? Make sure that you specify the test goals clearly and concretely so that you choose the right method. Are you observing people's behavior (usability test), finding out whether they like your design (focus group or sentiment analysis), or finding out how many do something on your website (web analytics)? Posing specific questions will help to formulate the goals clearly. For example, will the new content reduce calls to the service center? Or what percentage of users return to the website within a week? Design the right tasks: If your testing involves tasks, design scenarios that correspond to tasks users would actually perform. Consider what would motivate someone to spend time on your website, and use this to create tasks. Provide participants with the information they would have to complete the tasks in a real-life situation; no more and no less. For example, do not specify tasks using terms from your website interface; then participants will simply be following instructions when they complete the tasks, rather than using their own mental models to work out what to do. Recruit the right users: If you design and conduct a test perfectly, but test on people who are not like your users, then the results will not be valid. If they know too much or too little about the product, subject area, or technology, then they will not behave like your users would and will not experience the same problems. When recruiting participants, ask what qualities define your users, and what qualities make one person experience the website differently to another. Then recruit on these qualities. In addition, recruit the right number of users for your method. Ongoing research by the Nielsen Norman group and others indicate that usability tests typically require about five people per test, while A/B tests require about 40 people, and card sorting requires about 15 people. These numbers have been calculated to maximize the return on investment of testing. For example, five users in a usability test have been shown by the Nielsen Norman group (and confirmed repeatedly by other researchers) to find about 85% of the serious problems in an interface. Adding more users improves the percentage marginally, but increases the costs significantly. If you use the wrong numbers then your results will not be valid or the amount of data that you need to analyze will be unmanageable for the time and resources you have available. Get the team and stakeholders involved: If user testing is seen as an outside activity, most of the team will not pay attention as it is not part of their job and easy to ignore. When team members are involved, they gain insights into their own work and its effectiveness. Try to get team members to attend some of the testing if possible. Otherwise, make sure everyone is involved in preparing the goals and tasks (if appropriate) for the test. Share the results in a workshop afterward, so everyone can be involved in reflecting on the results and their implications. Facilitate the test well: Facilitating a test well is a difficult task. A good facilitator makes users feel comfortable so they act more naturally. At the same time, the facilitator must control the flow of the test so that everything is accomplished in the available time, and not give participants hints about what to do or say. Make sure that facilitators have a lot of practice and constructive feedback from the team to improve their skills. Plan how to share the results: It takes time and skill to create an effective user testing report that communicates the test and results well. Even if you have the time and skill, most team members will probably not read the report. Find other ways to share results to those who need them. For example, create a bug list for developers using project management software or a shared online document; have a workshop with the team and stakeholders and present the test and results to them. Have review sessions immediately after test days. Iterate: Most user testing is most effective if performed regularly and iteratively; for testing different aspects or parts of the design; for testing solutions based on previous tests; for finding new problems or ideas introduced by the new solutions; for tracking changes to results based on time, seasonality, maturity of product or user base; or for uncovering problems that were previously hidden by larger problems. Many organizations only make provision to test with users once at the end of design, if at all. It is better to split your budget into multiple tests if possible. As we explore usability testing, each of these guidelines will be addressed more concretely. Planning and conducting usability tests Before starting, let's look at what we mean by a usability test, and describe the different types. Usability testing involves watching a representative set of users attempt realistic tasks, and collecting data about what they do and say. Essentially, a usability test is about watching a user interact with a product. This is what makes it a core UX method: it persuades stakeholders about the importance of designing for and testing with their users. Team members who watch participants struggle to use their product are often shocked that they had not noticed the glaringly obvious design problems that are revealed. In later iterations, usability tests should reveal fewer or more minor problems, which provides proof of the success of a design before launch. Apart from glaring problems, how do we know what makes a design successful? The definition of usability by the International Organization for Standardization (ISO) is: Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. This definition shows us the kind of things that make a successful design. From this definition, usability comprises: Effectiveness: How completely and accurately the required tasks can be accomplished. Efficiency: How quickly tasks can be performed. Satisfaction: How pleasant and enjoyable the task is. This can become a delight if a design pleases us in unexpected ways. There are three additional points that arise from the preceding points: Discoverability: How easy it is to find out how to use the product the first time. Learnability: How easy it is to continue to improve using the product, and remember how to use it. Error proneness: How well the product prevents errors and helps users recover. This equates to the number and severity of errors that users experience while doing tasks. These six points provide us with guidance on the kinds of tasks we should be designing and the kind of observations we should be making when planning a usability test. There are three ways of gathering data in a usability test--using metrics to guide quantitative measurement, observing, and asking questions. The most important is observation. Metrics allow comparison, guide observation, and help us design tasks, but they are not as important as why things happen. We discover why by observing interactions and emotional responses during task performance. In addition, we must be very careful when assigning meaning to quantitative metrics because of the small numbers of users involved in usability tests. Typically, usability tests are conducted with about five participants. This number has been repeatedly shown to be most effective when considering testing costs against the number of problems uncovered. However, it is too small for statistical significance testing, so any numbers must be reported carefully. If we consider observation against asking questions, usability tests are about doing things, not discussing them. We may ask users to talk aloud while doing tasks to help us understand what they are thinking, but we need the context of what they are doing. "To design an easy-to-use interface, pay attention to what users do, not what they say. Self-reported claims are unreliable, as are user speculations about future behavior." - Jakob Nielsen This means that usability tests trump questionnaires and surveys. It also means that people are notoriously bad at remembering what they did or imagining what they will do. It does not mean that we never listen to what users say, as there is a lot of value to be gained from a well-formed question asked at the right time. We must just be careful about how we understand it. We need to interpret what people say within the context of how they say it, what they are doing when they say it, and what their biases might be. For example, users tend to tell researchers what they think we want to hear, so any value judgment will likely be more positive than it should. This is called experimenter bias. Despite the preceding cautions, all three methods are useful and increase the value of a test. While observation is core, the most effective usability tests include tasks carefully designed around metrics, and begin and end with a contextual interview with the user. The interviews help us to understand the user's previous and current experiences, and the context in which they might use the website in their own lives. Planning a usability test can seem like a daunting task. There are so many details to work out and organize, and they all need to come together on the day(s) of the test. The following diagram is a flowchart of the usability test process. Each of the boxes represents a different area that must be considered or organized: However, by using these areas to break the task down into logical steps and keeping a checklist, the task becomes manageable. Planning usability tests In designing and planning a usability test, you need to consider five broad questions: What: What are the objectives, scope, and focus of the test? What fidelity are you testing? How: How will you realize the objectives? Do you need permissions and sign off? What metrics, tasks, and questions are needed? What are the hardware and software requirements? Do you need a prototype? What other materials will you need? How will you conduct the test? Who: How many participants and who will they be? How will you recruit them? What are the roles needed? Will team members, clients, and stakeholders attend? Will there be a facilitator and/or a notetaker? Where: What venue will you use? Is the test conducted in an internal or external lab, on the streets/in coffee shops, or in users' homes/work? When: What is the date of the test? What will the schedule be? What is the timing of each part? Documenting these questions and their answers forms your test plan. The following figure illustrates the thinking around each of these broad questions: It is important to remember that no matter how carefully you plan usability testing, it can all go horribly wrong. Therefore, have backup plans wherever you can. For example, for participants who cancel late or do not arrive, have a couple of spares ready; for power cuts, be prepared with screenshots so you can at least simulate some tasks on paper; for testing live sites when the internet connection fails, have a portable wireless router or cache pages beforehand. Designing the test - formulating goals and structure The first thing to consider when planning a usability test is its goal. This will dictate the test scope, focus, and tasks and questions. For example, if your goal is a general usability test of the whole website, the tasks will be based on the business reasons for the site. These are the most important user interactions. You will ask questions about general impressions of the site. However, if your goal is to test the search and filtering options, your tasks will involve finding things on the website. You will ask questions about the difficulty of finding things. If you are not sure what the specific goal of the usability test might be, think about the following three points: Scope: Do you want to test part of the design, or the whole website? Focus: Which area of the website will you focus on? Even if you want to test the whole website, there will be areas that are more important. For example, checkout versus contact page. Behavioral questions: Are there questions about how users behave, or how different designs might impact user behavior, that are being asked within the organization? Thinking about these questions will help you refine your test goals. Once you have the goals, you can design the structure of the test and create a high-level test plan. When deciding on how many tests to conduct in a day and how long each test should be, remember moderator and user fatigue. A test environment is a stressful situation. Even if you are testing with users in their own home, you are asking them to perform unfamiliar tasks with an unfamiliar system. If users become too tired, this will affect test results negatively. Likewise, facilitating a test is tiring as the moderator must observe and question the user carefully, while monitoring things like the time, their own language, and the script. Here are details to consider when creating a schedule for test sessions: Test length: Typically, each test should be between 60 and 90 minutes long. Number of tests: You should not be facilitating more than 5-6 tests in one day. When counting the hours, leave at least half an hour cushioning space between each test. This gives you time to save the recording, make extra notes if necessary, communicate with any observers, and it provides flexibility if participants arrive later or tests run longer than they should. Number of tasks: This is roughly the number of tasks you hope to include in the test. In a 60-minute test, you will probably have about 40-45 minutes for tasks. The rest of the time will be taken with welcoming the participant, the initial interview, and closing questions at the end. In 45 minutes, you can fit about 5-8 tasks, depending on the nature of the tasks. It is important to remember that less is more in a test. You want to give participants time to explore the website and think about their options. You do not want to be rushing them on to the next task. The last thing to consider is moderating technique. This is how you interact with the participant and ask for their input. There are two aspects: thinking aloud and probing. Thinking aloud is asking participants to talk about what they are thinking and doing so you can understand what is in their heads. Probing is asking participants ad-hoc questions about interesting things that they do. You can do both concurrently or retrospectively: Concurrent thinking aloud and probing: Here, the participant talks while they do tasks and look at the interface. The facilitator asks questions as they come up, while the participant is doing tasks. Concurrent probing interferes with metrics such as time on task and accuracy, as you might distract users. However, it also takes less test time and can deliver more accurate insights, as participants do not have to remember their thoughts and feelings; these are shared as they happen. Retrospective thinking aloud and probing: This involves retracing the test or task after it is finished and asking participants to describe what they were thinking in retrospect. The facilitator may note down questions during tasks, and ask these later. While retrospective techniques simulate natural interaction more closely, they take longer because tasks are retraced. This means that the test must be longer or there will be fewer tasks and interview questions. Retrospective techniques also require participants to remember what they were thinking previously, which can be faulty. Concurrent moderating techniques are preferable because of the close alignment between users acting and talking about those actions. Retrospective techniques should only be used if timing metrics are very important. Even in these cases, concurrent thinking aloud can be used with retrospective probing. Thinking aloud concurrently generally interferes very little with task times and accuracy, as users are ideally just verbalizing ideas already in their heads. At each stage of test planning, share the ideas with the team and stakeholders and ask for feedback. You may need permission to go forward with test objectives and tasks. However, even if you do not need sign off, sharing details with the team gets everyone involved in the testing. This is a good way to share and promote design values. It also benefits the test, as team members will probably have good ideas about tasks to include or elements of the website to test that you have not considered. Designing tasks and metrics As we have stated previously, usability testing is about watching users interacting with a product. Tasks direct the interactions that you want to see. Therefore, they should cover the focus area of the test, or all important interactions if the whole website is tested. To make the test more natural, if possible create scenarios or user stories that link the tasks together so participants are performing a logical sequence of activities. If you have scenarios or task analyses from previous research, choose those that relate to your test goals and focus, and use them to guide your task design. If not, create brief scenarios that cover your goals. You can do this from a top-down or bottom-up perspective: Top down: What events or conditions in their world would motivate people to use this design? For example, if the website is a used goods marketplace, a potential user might have an item they want to get rid of easily, while making some money; or they might need an item and try to get it cheaply secondhand. Then, what tasks accomplish these goals? Bottom up: What are the common tasks that people do on the website? For example, in the marketplace example, common tasks are searching for specific items; browsing through categories of items; adding an item to the site to sell, which might include uploading photographs or videos, adding contact details and item descriptions. Then, create scenarios around these tasks to tie them together. Tasks can be exploratory and open-ended, or specific and directed. A test should have both. For example, you can begin with an open-ended task, such as examining the home page and exploring the links that are interesting. Then you can move onto more directed tasks, such as finding a particular color, size, and brand of shoe and adding it to the checkout cart. It is always good to begin with exploratory tasks, but these can be open-ended or directed. For example, to gather first impressions of a website, you could ask users to explore as they prefer from the home page and give their impressions as they work; or you could ask users to look at each page for five seconds, and then write down everything they remember seeing. The second option is much more controlled, which may be necessary if you want more direct comparison between participants, or are testing with a prototype where only parts of the website are available. Metrics are needed for task, observation, and interview analysis, so that we can evaluate the success of the design we are testing. They guide how we examine the results of a usability test. They are based on the definition of usability, and so relate to effectiveness, efficiency, satisfaction, discoverability, learnability, and error proneness. Metrics can be qualitative or quantitative. Qualitative metrics aim to encode the data so that we can detect patterns and trends in it, and compare the success of participants, tasks, or tests. For example, noting expressions of delight or frustration during a task. Quantitative metrics collect numbers that we can manipulate and compare against each other or benchmarks. For example, the number of errors each participant makes in a task. We must be careful how we use and assign meaning to quantitative metrics because of the small sample sizes. Here are some typical metrics: Task success or completion rates: This measures effectiveness and should always be captured as a base. It relates most closely to conversion, which is the primary business goal for a website, whether it is converting browsers to buyers, or visitors to registered users. You may just note success or failure, but it is more revealing to capture the degree of task success. For example, you can specify whether the task is completed easily, with some struggle, with help, or is not completed successfully. Time on task: A measure of efficiency. How long it takes to complete tasks. Errors per task: A measure of error-proneness. The number and severity of errors per task, especially noting critical errors where participants may not even realize they have made a mistake. Steps per task: A measure of efficiency. A number of steps or pages needed to complete each task, often against a known minimum. First click: A measure of discoverability. Noting the first click to accomplish each task, to report on findability of items on the web page. This can also be used in more exploratory tasks to judge what attracts the user's attention first. When you have designed tasks, consider them against the definition of usability to make sure that you have covered everything that you need or want to cover. The preceding diagram shows the metrics typically associated with each component of the usability definition. A valid criticism of usability testing is that it only tests first-time use of a product, as participants do not have time to become familiar with the system. There are ways around this problem. For example, certain types of task, such as search and browsing, can be repeated with different items. In later tasks, participants will be more familiar with the controls. The facilitator can use observation or metrics such as task time and accuracy to judge the effect of familiarity. A more complicated method is to conduct longitudinal tests, where participants are asked to return a few days or a week later and perform similar tasks. This is only reasonable to spend time and money on if learnability is an important metric. Planning questions and observation The interview questions that are asked at the beginning and end of a test provide valuable context for user actions and reactions, such as the user's background, their experiences with similar websites or the subject-area, and their relationship to technology. They also help the facilitator to establish rapport with the user. Other questions provide valuable qualitative information about the user's emotional reaction to the website and the tasks they are doing. A combination of observation and questions provides data on aspects such as ease of use, usefulness, satisfaction, delight, and frustration. For the initial interview, questions should be about: Welcome: These set the participant at ease, and can include questions about the participant's lifestyle, job, and family. These details help UX practitioners to present test participants as real people with normal lives when reporting on the test. Domain: These ask about the participant's experience with the domain of the website. For example, if the website is in the domain of financial services, questions might be around the participant's banking, investments, loans, and their experiences with other financial websites. As part of this, you might investigate their feelings about security and privacy. Tech: These questions ask about the participant's usage and experience with technology. For example, for testing a website on a computer, you might want to know how often the participant uses the internet or social media each day, what kinds of things they do on the internet, and whether they buy things online. If you are testing mobile usage, you might want to inquire about how often the participant uses the internet on their phone each day, and what kind of sites they visit on mobile versus desktop. Like tasks, questions can be open-ended or closed. An example of an open-ended question is: Tell me about how you use your phone throughout a normal workday, beginning with waking up in the morning and ending with going to sleep at night. The facilitator would then prompt the participant for further details suggested during the reply. A closed question might be: What is your job? These generate simple responses, but can be used as springboards into deeper answers. For example, if the answer is fireman, the facilitator might say, That's interesting. Tell me more about that. What do you do as a fireman? Questions asked at the end of the test or during the test are more about the specific experience of the website and the tasks. These are often made more quantifiable by using a rating scale to structure the answer. A typical example is a Likert scale, where participants specify their agreement or disagreement with a statement on a 5- to 7-point scale. For example, a statement might be: I can find what I want easily using this website. #1 is labeled Strongly Agree and #7 is labelled Strongly Disagree. Participants choose the number that corresponds to the strength of their agreement or disagreement. You can then compare responses between participants or across different tests. Examples of typical questions include: Ease of use (after every task): On a scale of 1-7, where 1 is really hard and 7 is really easy, how difficult or easy did you find this task? Ease of use (at the end): On a scale of 1-7, how easy or difficult did you find working on this website? Usefulness: On a scale of 1-7, how useful do you think this website would be for doing your job? Recommendation: On a scale of 1-7, how likely are you to recommend this website to a friend? It is important to always combine these kinds of questions with observation and task performance, and to ask why afterwards. People tend to self-report very positively, so often you will pay less attention to the number they give and more to how they talk about their answer afterwards. The final questions you ask provide closure for the test and end it gracefully. These can be more general and conversational. They might deliver useful data, but that is not the priority. For example, What did you think of the website? or Is there anything else you'd like to say about the website? Questions during the test often arise ad hoc because you do not understand why the participant does an action, or what they are thinking about if they stare at a page of the website for a while. You might also want to ask participants what they expect to find before they select a menu item or look at a page. In preparing for observation, it is helpful to make a list of the kinds of things you especially want to observe during the test. Typical options are: Reactions to each new page of the website First reactions when they open the Home page The variety of steps used to complete each task Expressions of delight or frustration Reactions to specific elements of the website First clicks for each task First click off the Home page Much of what you want to observe will be guided by the usability test objectives and the nature of the website. Preparing the script Once you have designed all the elements of the usability test, you can put them together in a script. This is a core document in usability testing, as it acts as the facilitator's guide during each test. There are different ideas about what to include in a script. Here, we describe a comprehensive script that describes the whole test procedure. This includes, in rough order: The information that must be told to the participant in the welcome speech. The welcome speech is very important, as it is the participant's first experience of the facilitator. It is where the rapport will first be established. The following information may need to be included: Introduction to the facilitator, client, and product. What will happen during the test, including the length. The idea that the website is being tested, not the participant, and that any problems are the fault of the product. This means the participant is valuable and helpful to the team developing a great website. Asking the participant to think aloud as much as possible, and to be honest and blunt about what they think. Asking them to imagine that they are at home in a natural situation, exploring the website. If there are observers, indication that people may be watching and that they should be ignored. Asking permission to record the session, and telling the participant why. Assuring them of their privacy and the limited usage of the recordings to analysis and internal reporting. A list of any documents that the participant must look at or sign first, for example, an NDA. Instructions on when to switch on and off any recording devices. The questions to ask in thematic sections, for example, welcome, domain, and technology. These can include potential follow - on questions, to delve for more information if necessary. A task section, that has several parts: An introduction to the prototype if necessary. If you are testing with a prototype, there will probably be unfinished areas that are not clickable. It is worth alerting participants so they know what to expect while doing tasks and talking aloud. Instructions on how to use the technology if necessary. Ideally your participants should be familiar with the technology, but if this is not the case, you want to be testing the website, not the technology. For example, if you are testing with a particular screen reader and the participant has not used it before, or if you are using eye tracking technology. An introduction to the tasks, including any scenarios provided to the participant. The description of each task. Be careful not to use words from the website interface when describing tasks, so you do not guide the participant too much. For example, instead of: How would you add this item to your cart?, say How would you buy this item? Questions to include after each task. For example, the ease of use question. Questions to prompt the participant if they are not thinking aloud when they should, especially for each new page of the website or prototype. For example: What do you see here? What can you do here? What do you think these options mean? Final questions to finish off the test, and give the participant a chance to emphasize any of their experiences. A list of any documents the participant must sign at the end, and instructions to give the incentive if appropriate. Once the script is created, timing is added to each task and section, to help the facilitator make sure that the tests do not run over time. This will be refined as the usability test is practiced. The script provides a structure to take notes in during the test, either on paper or digitally: Create a spreadsheet with rows for each question and task Use the first column for the script, from the welcome questions onwards Capture notes in subsequent columns for the user Use a separate spreadsheet for each participant during the test After all the tests, combine the results into one spreadsheet so you can easily analyze and compare The following is a diagram showing sections of the script for notetaking, with sample questions and tasks, for a radio station website: Securing a venue and inviting clients and team members If you are testing at an external venue, this is one of the first things you will need to organize for a usability test, as these venues typically need to be booked about one-two months in advance. Even if you are testing in your own offices, you will still need to book space for the testing. When considering a test venue, you should be looking for the following: A quiet, dedicated space where the facilitator, participant, and potentially a notetaker, can sit. This needs surfaces for all the equipment that will be used during the test, and comfortable space for the participant. Consider the lighting in the test room. This might cause glare if you are testing on mobile phones, so think about how best to handle the glare. For example, where the best place is for the participant to sit, and whether you can use indirect lighting of some kind. A reception room where participants can wait for their testing session. This should be comfortable. You may want to provide refreshments for participants here. Ideally, an observation room for people to watch the usability tests. Observers should never be in the same space as the testing, as this will distract participants, and probably make them uncomfortable. The observation room should be linked to the test room, either with cables or wirelessly, so observers can see what is happening on the participant's screen, and hear (and ideally see) the participant during the test. Some observation rooms have two-way mirrors into the test room, so observers can watch the facilitator and participant directly. Refreshments should be available for the observers. We have discussed various testing roles previously. Here, we describe them formally: Facilitator: This is the person who conducts the test with the participant. They sit with the participant, instruct them in the tasks and ask questions, and take notes. This is the most important role during the test. We will discuss it further in the Conducting usability tests section. Participant: This is the person who is doing the test. We will discuss recruiting test participants in the next section. Notetaker: This is an optional role. It can be worth having a separate notetaker, so the facilitator does not have to take notes during the test. This is especially the case if the facilitator is inexperienced. If there is a notetaker, they sit quietly in the test room and do not engage with the participant, except when introduced by the facilitator. Receptionist: Someone must act as receptionist for the participants who arrive. This cannot be the facilitator, as they will be in the sessions. Ask a team member or the office receptionist to take this role. Observers: Everyone else is an observer. These can be other team members and/or clients. Observers should be given guidelines for their behavior. For example, they should not interact with test participants or interrupt the test. They watch from a separate room, and should not be too noisy so that they can be heard in the test room (often these rooms are close to each other). The facilitator should discuss the tests with observers between sessions, to check if they have any questions they would like added to the test, and to discuss observations. It is worth organizing a debriefing for immediately after the tests, or the next day if possible, for the observers and facilitator to discuss the tests and observations. It is important that as many stakeholders as possible are persuaded to watch at least some of the usability testing. Watching people using your designs is always enlightening, and really helps to bring a team together. Remember to invite clients and team members early, and send reminders closer to the day. Recruiting participants When recruiting participants for usability tests, make sure that they are as close as possible to your target audience. If your website is live and you have a pool of existing users, then your job is much easier. However, if you do not have a user pool, or you want to test with people who have not used your site, then you need to create a specification for appropriate users that you can give to a recruiter or use yourself. To specify your target audience, consider what kinds of people use your website, and what attributes will cause them to behave differently to other users. If you have created personas during previous research, use these to help identify target user characteristics. If you are designing a website for a client, work with them to identify their target users. It is important to be specific, as it is difficult to look for people who fulfill abstract qualities. For example, instead of asking for tech savvy people, consider what kinds of technology such people are more likely to use, and what their activities are likely to be. Then ask for people who use the technology in the ways you have identified. Consider the behaviors that result from certain types of beliefs, attitudes, and lifestyle choices. The following are examples of general areas you should consider: Experience with technology: You may want users who are comfortable with technology or who have used specific technology, for example, the latest smartphones, or screen readers. Consider the properties that will identify these people. For example, you can specify that all participants must own a specific type or generation of mobile device, and must have owned it for at least two months. Online experience: You may want users with a certain level and frequency of internet usage. To elicit this, you can specify that you want people who have bought items online within the last few months, or who do online banking, or have never done these things. Social media presence: Often, you want people who have a certain amount of social media interaction, potentially on specific platforms. In this case you would specify that they must regularly post to or read social media such as Facebook, Twitter, Instagram, Snapchat, or more hobbyist versions such as Pinterest and/or Flickr. Experience with the domain: Participants should not know too much or too little about the domain. For example, if you are testing banking software, you may want to exclude bank employees, as they are familiar with how things work internally. Demographics: Unless your target audience is very skewed, you probably want to recruit a variety of people demographically. For example, a range of ages, gender ethnicity, economic, and education levels. There may be other characteristics you need in your usability test participants. The previous characteristics should give you an idea of how to specify such people. For example, you may want hobbyist photographers. In this case, you would recruit people who regularly take photographs and share them with friends in some way. Do not use people who you have previously used in testing, unless you specifically need people like this, as they will be familiar with your tests and procedures, which will interfere with results. Recruiting takes time and is difficult to do well. There are various ways of recruiting people for user testing, depending on your business. You may be able to use people or organizations associated with your business or target audience members to recruit people using the screening questions and incentives that you give them. You can set up social media lists of people who follow your business and are willing to participate. You can also use professional recruiters, who will get you exactly the kinds of people you need, but will charge you for it. For most tests, an incentive is usually given to thank participants for their time. This is often money, but it can also be a gift, such as stationery or gift certificates. A recruitment brief is the document that you give to recruiters. The following are the details you need to include: Day of the test, the test length, and the ideal schedule. This should state the times at which the first and last participants may be scheduled, how long each test will take, and the buffer period that should be between each session. The venue. This should include an address, maps, parking, and travel information. Contact details for the team members who will oversee the testing and recruitment. A description of the test that can be given to participants. The incentives that will be provided. The list of qualities you need in participants, or screening questions to check for these. This document can be modified to share with less formal recruitment associates. The benefit of recruiters is that they handle the whole recruitment process. If you and your team recruit participants yourselves, you will need to remind them a week before the test, and the day before the test, usually by messaging or emailing them. On the day of the test, phone participants to confirm that they will be arriving, and that they know how to get to the venue. Participants still often do not attend tests, even with all the reminders. This is the nature of testing with real people. Ideally you will be given some notice, so try to recruit an extra couple of possible participants who you can call in a pinch on the day. Setting up the hardware, software, and test materials Depending on the usability test, you will have to prepare different hardware, software, and test materials. These include screen recording software and hardware, notetaking hardware, the prototype to test, screen sharing options, and so on. The first thing to consider is the prototype, as this will have implications for hardware and software. Are you testing a live website, an electronic prototype, or a paper prototype? Live website: Set up any accounts or passwords that may be necessary. Make sure you have reliable access to the internet, or a way to cache the website on your machine if necessary. Electronic prototype: Make sure the prototype works the way it is supposed to, and that all the parts that are accessed during the tasks can be interacted with, if required. Try not to make it too obvious which parts work and which parts do not work, as this may guide participants to the correct actions during the test. Be prepared to talk participants through parts of the prototype that do not work, so they have context for the tasks. Have a safe copy of the prototype in case this copy becomes corrupted in some way. Paper prototype: Make sure that you have sketches or printouts of all the screens that you need to complete the tasks. With paper prototype testing, the facilitator takes the role of the computer, shows the results of the actions that the participant proposes, and talks participants through the screens. Make sure that you are prepared for this and know the order of the screens. Have multiple copies of the paper prototype in case parts get lost or destroyed. For any of the three, make sure the team goes through the test tasks to make sure that everything is working the way it should be. For hardware and other software, keep an equipment list, so you can check it to make sure you have all the necessary hardware with you. You may need to include: Hardware for participant to interact with the prototype or live site: This may be a desktop, laptop, or mobile device. If testing on a mobile device, you can ask participants to use their own familiar phones instead of an unfamiliar test mobile device. However, participants may have privacy issues with using their own phones, and you will not be able to test the prototype or live site on the phone beforehand. If you provide a laptop, include a separate mouse as people often have difficulty with unfamiliar mouse pads. Recording the screen and audio: This is usually screen capture software. There are many options for screen capturing software, such as Lookback, an inexpensive option for iOS and Android, and CamStudio, a free option for the PC. Specialist software that handles multiple camera inputs allows you to record face and screen at the same time. Examples are iSpy, free CCTV software, Silverback, an inexpensive option for the Mac, and Morae, an expensive but impressive option for the PC. Mobile recording alternative: You can also record mobile video with an external camera that captures the participant's fingers on screen. This means you do not have to install additional software on the phone, which might cause performance problems. In this case, you would use a document camera attached to the table, or a portable rig with a camera containing the phone and attached to a nearby PC. The video will include hesitations and hovering gestures, which are useful for understanding user behavior, but fingers might occlude the screen. In addition, rigs may interfere with natural usage of the mobile phone, as participants must hold the rig as well as the phone. Observer viewing screen: This is needed if there are observers. The venue might have screen sharing set up; if not, you will have to bring your own hardware and software. This could be an external monitor and extension cables to connect to a laptop in the interview room. It could also be screen sharing software, for example, join.me. Capturing notes: You will need a method to capture notes. Even if you are screen recording, notes will help you to review the recordings more efficiently, and remind you about parts of the recording you wanted to pay special attention to. One method is using a tablet or laptop and spreadsheet. Typing is fast and the electronic notes are easy to put together after the tests. An alternative is paper and pencil. The benefit of this is that it is least disruptive to the participant. However, these notes must be captured electronically. Camera for participant face: Capturing the participant's face is not crucial. However, it provides good insight into their feelings about tasks and questions. If you don't record face, you will only have tone of voice and the notes that were taken to remind you. Possible methods are using a webcam attached to the computer doing screen recording, or using inbuilt software such as Hangouts, Skype, or FaceTime for Apple devices. Microphone: Often sound quality is not great on screen capturing software, because of feedback from computer equipment. Using an external microphone improves the quality of sound. Wireless router: A portable wireless router in case of internet problems (if you are using the internet). Extra extension cables and chargers for all devices. You will also need to make sure that you have multiple copies of all documents needed for the testing. These might include: Consent form: When you are testing people, they typically need to give their permission to be tested. You also typically need proof that the incentive has been received by the participant. These are usually combined into a form that the participant signs to give their permission and acknowledge receipt of the incentive. Non-disclosure agreement (NDA): Many businesses require test participants to sign NDAs before viewing the prototype. This must be signed before the test begins. Test materials: Any documents that provide details to the participants for the test. Checklists: It is worth printing out your checklists for things to do and equipment, so that you can check them off as you complete actions, and be sure that you have done everything by the time it needs to be done. The following figure shows a basic sample checklist for planning a usability test. For a more detailed checklist, add in timing and break the tasks down further. These refinements will depend on the specific usability test. Where you are uncertain about how long something will take, overestimate. Remember that once you have fixed the day, everything must be ready by then. Checklist for usability test preparation Conducting usability tests On the day(s) of the usability test, if you have planned properly, all you should have to worry about are the tests themselves, and interacting with the participants. Here is a list of things to double-check on the day of each test: Before the first test: Set up and check equipment and rooms. Have a list of participants and their order. Make sure there are refreshments for participants and observers. Make sure you have a receptionist to welcome participants. Make sure that the prototype is installed or the website is accessible via the internet and working. Test all equipment, for example, recording software, screen sharing, and audio in observations room. Turn off anything on the test computer or device that might interfere with the test, for example, email, instant messaging, virus scans, and so on. Create bookmarks for any web pages you need to open. Before each test: Have the script ready to capture notes from a new participant. Have the screen recorder ready. Have the browser open in a neutral position, for example, Google search. Have sign sheets and incentive ready. Start screen sharing. Reload sample data if necessary, and clear the browser history from the last test. During each test: Follow the script, including when the participant must sign forms and receive the incentive. Press record on the screen recorder. Give the microphone to the participant if appropriate. After each test: Stop recording and save the video. Save the script. End screen sharing. Note extra details that you did not have time for during the session. Once you have all the details organized, the test session is in the hands of the facilitator. Best practices for facilitating usability sessions The facilitator should be welcoming and friendly, but relatively ordinary and not overly talkative. The participant and website should be the focus of the interview and test, not the facilitator. To create rapport with the participant, the facilitator should be an ally. A good way to do this is to make fun of the situation and reassure participants that their experiences in the test will be helpful. Another good technique is to ask more like an apprentice than an expert, so that the participant answers your questions, for example: Can you tell me more about how this works? and What happens next?. Since you want participants to feel as natural and comfortable as possible in their interactions, the facilitator should foster natural exploration and help satisfy participant curiosity as much as possible. However, they need to remain aware of the script and goals of the test, so that the participant covers what is needed. Participants often struggle to talk aloud. They forget to do so while doing tasks. Therefore, the facilitator often needs to nudge participants to talk aloud or for information. Here are some useful questions or comments: What are you thinking? What do you think about that? Describe the steps you're doing here. What's going on here? What do you think will happen next? Is that what you expected to happen? Can you show me how you would do that? When you are asking questions, you want to be sure that you help participants to be as honest and accurate as possible. We've previously stated that people are notoriously bad at projecting what they will do or remembering what they did. This does not mean that you cannot ask about what people do. You must just be careful about how you ask and always try to keep it concrete. The priorities in asking questions are: Now: Participants talking aloud about what they are doing and thinking now. Retrospective: Participants talking about what they have done or thought in the past. Never prospective: Never ask participants about what they would do in the future. Rather ask about what they have done in similar situations in the past. Here are some other techniques for ensuring you get the best out of the participants, and do not lead them too much yourself: Ask probing questions such as why and how to get to the real reasons for actions. Do not assume you know what participants are going to say. Check or paraphrase if you are not sure what they said or why they said it. For example, So are you saying the text on the left is hard to read? or You're not sure about what? or That picture is weird? How? Do not ask leading questions, as people will give positive answers to please you. For example, do not say Does that make sense?, Do you like that? or Was that easy? Rather say Can you explain how this works? What do you think of that? and How did you find doing that task? Do not tell participants what they are looking at. You are trying to find out what they think. For example, instead of Here is the product page, say Tell me what you see here, or Tell me what this page is about. Return the question to the participant if they ask what to do or what will happen: I can't tell you because we need to find out what you would do if you were alone at home. What would you normally do? or What do you think will happen? Ask one question at a time, and make time for silence. Don't overload the participants. Give them a chance to reply. People will often try to fill the silence, so you may get more responses if you don't rush to fill it yourself. Encourage action, but do not tell them what to do. For example, Give it a try. Use acknowledgment tokens to encourage action and talking aloud. For example, OK, uh huh, mm hmm. A good facilitator makes participants feel comfortable and guides them through the tasks without leading while observing carefully and asking questions where necessary. It takes practice to accomplish this well. The facilitator (and the notetaker if there is one) must also think about the analysis that will be done. Analysis is time-consuming; think about what can be done beforehand to make it easier. Here are some pointers: Taking notes on a common spreadsheet with a script is helpful because the results are ready to be combined easily. If you are gathering quantitative results, such as timing tasks or counting steps to accomplish activities, prepare spaces to note these on the spreadsheet before the test, so all the numbers are easily accessible afterward. If you are rating task completion, then note a preliminary rating as the task is completed. This can be as simple as selecting appropriate cell colors beforehand and coloring each cell as the task is completed. This may change during analysis, but you will have initial guidance. Listen for useful and illustrative quotes or video segment opportunities. Note down the quote or roughly note the timestamp, so you know where to look in the recording. In general, have a timer at hand, and note the timestamp of any important moments in each test. This will make reviewing the recordings easier and less time-consuming. We examined how to plan, organize, and conduct a usability test. As part of this, we have discussed how to design a test with goals, tasks, metrics, and questions using the definition of usability. If you liked this article, be sure to check out this book UX for the Web  to make a web app fully accessible from a development and design perspective. 3 best practices to develop effective test automation with Selenium Unit Testing in .NET Core with Visual Studio 2017 for better code quality Unit Testing and End-To-End Testing

Static sites are back and stronger than ever. A large number of businesses have realized the importance of sticking to trendy, beautiful, static websites which have less hassle of server maintenance and security exploits. For example, Nest and MailChimp, prominent design companies, are using static site generators for their primary websites. Vox Media has built an entire publishing system around Middleman static site generator. A static website contains Web pages coded in HTML, with fixed content, so they look same to every user. These websites are made using static site generators, which automate the process of creating websites, with minimal coding required from developers. If you’re looking to implement static sites in your next business project, we have compiled a list of the top 5 static site generators to help you design interactive and fast websites. Before we dive in, first let’s understand when choosing static sites makes sense. Why choose static sites? Static sites typically take the content stored in flat files as opposed to dynamic sites where databases serve as content stores. This content is applied against templates and is used to generate a structure of static HTML files. These static files function as the website for the users. Agreed, they lack real-time content and have limited functionalities. But these static sites come in real handy when you want to avoid the hassle of server maintenance while also keeping your pocket light. Not to mention, they are the best option available when your product doesn’t require timely upgrades. Another important factor which contributes to their popularity is the ability to be indexed easily by Google search engines. Since Google has indicated site speed to be one of the signals used to rank pages, static sites have truly shined through. With pure HTML static websites, you have total control over your SEO, and the HTML and CSS are fully understood by search engines. Unlike dynamic websites, you don’t need a special plugin to manage your SEO or need to optimize page load time. Static sites are fast loading, secure, and most importantly, well prepared for traffic surges. This is why their popularity is only surging with the growth of publishing content online. Now that I have ignited your interest to make your next website static, let’s look at some frameworks for building these sites. Static site generators have exploded in popularity in recent years, with a total of more than 100,000 stars for static website generator repositories. Hence, navigating the wide range of choices can be difficult. Here are my top five picks to get you started. Jekyll: The most mature player Jekyll is perhaps the most mature and popular static site generator (Quite obvious from the Github stars). It is built with Ruby and is typically used for transforming plain texts into static websites and blogs. It takes a directory filled with text files, renders that content with Markdown and Liquid templates, and generates a publish-ready static website. Jekyll comes with a big bonus of being natively supported by GitHub pages. So you can easily deploy your site using GitHub for absolutely free. It also has a huge community and wide array of plugins, making it easier for Wordpress and Drupal developers to import content. Hugo: The fastest player Blazingly fast, Hugo is a static HTML and CSS website generator built around Google’s Go programming language. It is optimized for speed, ease of use, and configurability. As with Jekyll, Hugo takes a directory of text files and templates, albeit written in Go, and generates them into a full HTML website. It is extremely fast with build times less than 1 ms per page It is cross-platform, with easy installation on macOS, Linux, Windows, and more. It renders changes on the fly with LiveReload as you develop. It provides full i18n support for multi-language sites. Hexo: The One-command player Hexo is a powerful framework built with Node.js. It offers super fast rendering even for extremely large sites. Hexo is highly extensible as it offers support for GitHub flavored Markdown and most Octopress plugins. It has a One-command deployment to GitHub Pages, Heroku, and other sites. Hexo also features a powerful plugin system. You can install more plugins for Jade, CoffeeScript plugins and many Jekyll plugins with minor adjustments. Gatsby: The multi-tasker Gatsby is a static site generator for React. It is optimized for speed as it loads only critical parts for fast loading. Once loaded, Gatsby prefetches resources for other pages so that clicking around the site feels incredibly fast. Gatsby.js can also be used to generate static Progressive Web apps. It does automatic routing based on the directory structure. The HTML code is generated server-side and additional code need not be included for configuring the router. Gatsby has a pre-configured Webpack-based build system and allows easy data integration from CMSs, SaaS services, APIs, databases, and file systems. VuePress: The new player VuePress, the new player in town, is a minimalistic static site generator powered by Vue.js. VuePress creates a single-page application with pre-rendered static HTML from a Markdown file. This markdown file is powered by Vue, VueRouter, and Webpack. It is composed of two parts: A theming system A default theme optimized for writing technical documentation. This default theme has a header-based search, customizable navbar and sidebar, optional homepage, auto-generated Github link and Page edit links. VuePress also comes with integrated Google Analytics and multi-language support. Here's a short table summarising all static site generators. Static Site Generator GitHub stars Languages Templates Features Jekyll 34k + Ruby Liquid - Most mature and popular - Supported by GitHub pages - A wide array of Plugins Hugo 25k + Go Go - Extremely fast - Cross-platform - Renders changes on the fly - Full i18n support for multi-language sites. Hexo 22k + Javascript EJS, Pug - Highly extensible - One-command deployment - Powerful plugin system Gatsby 21k + Javascript React - Optimized for speed - Generates static PWA - A pre-configured Webpack-based build system VuePress 7k + (growing fast) Javascript Vue - Theming system - Default theme - Google analytics support - Multi-Language support   Apart from these, you also have Next, GitBook, Nuxt, Pelican, among others as some of the other static site generators to choose from. Before going with your choice of static site generator, you need to first make an informed decision on whether or not a static site is right for your next project. Consider your website needs and the kind of business you’re running. If your website has too much going on, it may be killing your traffic. In such cases having a fast, secure and beautiful static site is much more beneficial than a massive, unwieldy dynamic website. Firefox 60 arrives with exciting updates for web developers: Quantum CSS engine, new Web APIs and more [news] Get ready for Bootstrap v4.1; Web developers to strap up their boots [news] How to create a generic reusable section for a single page based website [tutorial]

Last year Mikeal Rogers, the community organizer of Node.js foundation stated in an interview: “Node.js will take over Java within a year”. No doubt Java has been the most popular programming language for a very long time. But Node is catching up quickly thanks to its JavaScript connection; the most used programming language for the front end web development. JavaScript has gained significant popularity for server side web development too and that is where Node.js has a bigger role to play. JavaScript functionalities get compiled in the browser and are capable of creating sleek and beautiful websites with ease. Node.js extends JavaScript capabilities to the server side and allows JavaScript code to run on the server side. In this way, JavaScript is able to utilize the resources of the system and perform more complex tasks than just running on the browser. Today we look at the top 5 reasons why Node.js has become so popular with the potential to take over Java. Asynchronous programming Node.js brings asynchronous programming to the server side. The meaning of Asynchronous request handling is that while one request is being addressed, the newer requests will not have to wait in queue in order to be completed.The requests are taken up in parallel and are processed as and when they arrive. This saves a lot of time and also helps to maximize the processor’s power to the full extent. Event Driven Architecture Node.js is completely built upon the foundation of Event Driven Architecture. What do we mean by event driven architecture in Node.js? Every request, be it access to database or a simple redirect to a web address is considered as an event and is stored in a single thread. Once the thread is complete with requests, be it a single request or multiple requests, the events are completed in sequence and any new request is added as an event on top of the previous events. As the events are completed, the output is either printed or delivered. This event driven approach has paved way for the present event driven architecture based application and implementation of microservices. Vibrant Community The Node.js developer community is a large and an active community. This has propelled the creation of several other third party tools which have made server-side development easier. One such tool is Socket.io which enables push messaging between the server and the client. Tools like Socket.io, Express.js, Websockets etc, have enabled faster message transfer resulting in more efficient and better applications. Better for Scaling When you are trying to build a large scale industrial grade application, there are two techniques available - multithreading and event driven architecture. Although the choice depends on the exact requirement of the application, Node can solve a multitude of your problems because it doesn’t just scale up the number of processors, but it can scale up per processor. This simply means the number of processes per processor can also be scaled up in node.js in addition to the number of processors. Real Time Applications Are you developing real time applications like Google doc, or Trello where there is a need of small messages travelling to and from, from the server to the client? Node.js will be the best choice for you to build something similar. The reason being the feature we discussed in the second point - event driven architecture and also the presence of fast messaging tools. The smaller and more frequent your messaging needs, the better node.js works for you. Although we’ve looked at some of the features in favor of Node.js, no technology is above limitations. For example if you are building CRUD applications and there is no need for real time data flow, then node.js would not make your job any easier. If you are looking to build CPU heavy applications, then Node.js might disappoint you because it comprises of only one CPU thread. But keeping in mind that it brings the flexibility of JavaScript to the server side and is the inspiration behind groundbreaking technologies like Microservices, it’s imperative that Node.js is going to grow more in the near future. Server-Side Rendering Implementing 5 Common Design Patterns in JavaScript (ES8) Behavior Scripting in C# and Javascript for game developers

The vastness and the innovativeness of today’s e-commerce websites are converting visitors into potential buyers and come back as returning visitors. Every e-commerce website is designed with high-quality UX (user experience) and the absence of it can hurt the revenue and sales in various stages. If not made simplistic and innovative, a bad UX may have an adverse effect on the website’s rankings as all search engines emphasize on portals that are easy to navigate. This makes e-commerce mobile app development services necessary for website owners. Almost 68% of users utilize smartphone devices in the US and the amount goes up to 88% in the UK. So, if seen from the advertising standpoint, websites need to be mobile-friendly at any cost as 62% of users will never suggest a business that has a poorly designed mobile website. Now if we take a look at the global population that buys online, the percentage comes to around 22.9% and by 2021, the number will hike to 3.15 billion. Hence keeping an up-to-date UX design for mobile apps is an absolute must. Some UX tips to keep in mind These are some UX design tips that an e-commerce website must utilize for making the buying experience worthwhile for the consumers. Horizontal filtering Most websites employ interfaces that carry left-hand vertical sidebar filtering. However, currently, horizontal filtering has gained prominence. Its benefits include: Horizontal filtering is a tablet and smartphone friendly. So, filters can be viewed while scrolling and the full width of a page can also be utilized. Utilizing paragraphs, sliders and tablets along with checkboxes are easier as horizontal filtering is flexible. Page width utilization: With this UX design, bigger visuals with better and useful information can be put in a page. No overloading of websites with CTAs and product information Making product descriptions crisp and understandable is necessary as any user or customer won’t like to go through massive texts. Clear CTAs – Having a clear and compelling call to action is important. Knowing the audience well – The aspects that attract your customers or the ones causing inconvenience to them must be well addressed.   Easy to understand descriptions - Top e-commerce app developers will always offer you with clear descriptions containing a crisp heading, bullet points, and subheadings. Fabricating a user-centric search The search experience that you offer to your customers can break or make your online sales. Your e-commerce businesses must implement these points for fabricating a client-centric search: Image recognition – Pictures or images are extremely important when it comes to e-commerce. Users will always want to see the items before buying. TImage recognition must be implemented in every website so that users can rely on the item they are purchasing. Voice search – As per mobile app design guidelines, voice recognition must also be implemented as it helps online retailers to improve the user experience. This is about ease, convenience, and speed. It makes consumers more comfortable which results in elevated customer engagement. Making the correct choice amid scrolling, loading more buttons and pagination When you engage in e-commerce shopping app development services, you must choose how the products are loading on your website.: Load more buttons – Websites that contain load button option is more favorable as users can discover more products offering them a feeling of control. Pagination – This is a process by which a small amount of information is offered to the customer so that he can emphasize on specific parts of a page. With pagination, users can overview entire results that will tell them how long the search is going to take. Endless scrolling - This technique can lead to seamless experiences for users. By enabling endless scrolling,  content loads continuously as a customer scrolls the page downwards. This works best for websites that contain an even content structure. It is not suitable for websites that need to fulfill goal-oriented jobs. Simple checkouts and signups required Among the various mobile app design elements, this point holds quite an importance. Making the procedures of checkouts and signups simple is paramount as website users are quick to run out of patience. Single-column structure – A user’s eye will move naturally from top to the bottom along a solitary line. Making on-boarding simple – Asking too many questions at the very beginning is not recommended. Registration simply calls for the user’s email and name. Later, personal information like, address and phone number can be asked. Colors Color is an often overlooked part of UI design. It is, in fact, hugely important - and it's beginning to become more important to designers. When you think about it, it seems obvious. Color is not only important from a branding perspective, allowing you to create a unified and consistent user experience within a single product (or, indeed, set of products). Color can also have consequences for hardware too. A white interface, for example, will use less battery power as the device won't require the resources that would otherwise be needed to load color. Accessibility and color in design Another important dimension to this is accessibility. With around 4.5% of the population estimated to suffer from color blindness (most of them male), it could be worth considering how the decisions you make about colors could impact these users. In a nutshell While implementing the entire e-commerce application development process, you have to make sure as a merchant that you are delivering experiences and products that fulfill real requirements. A lot of emphasis needs to be put on visual appeal as it marks as a vital element in fulfilling customer needs and is also an establishment of credibility. A customer’s first impression must be good no matter what. When talking about mobile user experience, credibility must be taken into account that can be ensured when you capture the attention of your users by informing them about what you exactly have to offer. The about page must be clear containing information like physical address, email address, phone number, etc. Following these UX tips is adequate for your E-commerce business to take flight and do wonders. Get hold of a professional team today and get started. Author Bio   Manan Ghadawala is the founder of 21Twelve Interactive which is a mobile app development company in India and the USA. You may follow him on @twitter. Why Motion and Interaction matter in a UX design? [Video] What UX designers can teach Machine Learning Engineers? To start with: Model Interpretability Align your product experience strategy with business needs