It’s sorta sad by funny that that big Zoom vulnerability thing was ultimately related to web technology and not really the app itself.
There is this idea of custom protocols or “URL schemes.” So, like gittower:// or dropbox:// or whatever. A native app can register them, then URLs that hit them get passed to the native app. iOS has “universal links” which are coming to the web apparently. (Atishay Jain has an excellent write-up on them.) But links like that don’t leave much choice — they will open in the app. If your app has both web and native components, you might want to offer the user a choice. So, you use a regular URL instead.
In order for that web page to open up a native app, apparently, the tactic used by many is to have it communicate with a server running on localhost on your own computer which uses a URL scheme to open the native app. Clever, but I’ve heard sentiment from folks like:
I had no idea this software was running a localhost server on my machine
It feels weird that websites out on the wild internet can communicate with my localhost server
That’s the way it is though. But there are some protections in place. Namely: CORS (Cross-Origin Resource Sharing). Ugh. I feel like I deal with some kind of CORS problem every week of my life. But it’s important. It prevents XHR requests from websites that aren’t specifically allowed. Imagine if you visit my website, and I have your browser shoot requests over to Facebook, hoping you are logged in so I can do things on your behalf. Bad. CORS doesn’t prevent that, the same-origin policy of browsers prevents that. CORS is the mechanism to control that.
If my website tries to communicate with your website, and your website’s response doesn’t have an Access-Control-Allow-Origin header with my domain or *, it will fail. But not everything is subject to CORS restrictions. Images, for example, are not. We can link up images from any domain and they will return data.
Chris Foster thinks CORS and a lack of understanding of CORS was at the heart of the Zoom bug.
Zoom may have needed to get this feature out and did not understand CORS. They couldn’t make the AJAX requests without the browser disallowing the attempt. Instead, they built this image hack to work around CORS. By doing this, they opened Zoom up to a big vulnerability because n/ot only can the Zoom website trigger operations in the native client and access the response, but every other website on the internet can too.
This is often a source of confusion for newcomers because it’s not immediately apparent what CORS is supposed to achieve. Firstly CORS is not a security measure in itself, it’s actually the opposite: CORS is a way to circumvent the “Same Origin Policy” which is the security measure preventing you from making [AJAX] requests to a different domain.
Today’s users are quick to bounce away from a website if they can’t connect with a page’s content within 3 seconds. If your business features online appointment bookings, registrations, or making payments for events, you want the process to be super-simple.
Amelia is a WordPress appointment and event booking plugin that web designers love because it is easy to work with. Your clients and their customers will love it for the same reason since it provides a scheduling solution that is close to perfection.
We have created this article to show how Amelia keeps customers happy and can help a business to grow.
Events Functions in Amelia 2.0
It’s common knowledge that Amelia was already at the top of the class for appointment bookings plugins. A new set of events functions in Amelia 2.0 has made it even better. Amelia already has made spreadsheets items of historical interest only.
With 2.0 it can be used for even more events and occasions; whether they be single-day events to multi-day travel tours, classes, conferences, or seminars. Whatever the event, you can easily manage day-by-day detail bookings, recurring events, costs, etc.
Payments for Appointment and Event Scheduling
Managing prices and attendance for multiple day events is something you would not want to have to track manually. So, don’t!
Amelia’s integrations with WooCommerce, PayPal, and Stripe allow you to schedule a mix of event types while automatically streamlining the payments process – a “must have” feature in any all-encompassing booking solution. Currencies won’t present a problem either and you’ll receive SMS notifications as the payments roll in.
Events Calendar
Once you’ve entered your events, the Events Calendar becomes a central powerhouse for boosting registrations and payments. As we mentioned in the beginning, it’s super simple for users to view the panorama of events you’re offering – just a click away.
And, when a potential attendee selects an event from the calendar, he or she is guided through a step-by-step booking process. The calendar will automatically update an event’s availability and make a note when its maximum capacity is reached.
A truly neat feature is the UI for the event booker, payment processor, and events calendar. It’s the same UI for the you and for event attendees; and since data can move freely between these functions, registering for and managing events is as simple, satisfying, and mistake-free as possible.
There are additional Events Calendar options in Amelia 2.0 such as the ability to personalize what events will display based on status or your selections, the ability to create “invitation-only” events, and more. Click to read more about events and the Events Calendar.
Classes Booking
One of the things that makes the new Events Calendar such a powerful and useful feature is that the 2.0 version was built as a direct result of user feedback, a large part of which focused on the need for a specific solution. That need was for a solution that could streamline booking classes and payments in much the same way as appointments booking.
This was special. A variety of scheduling solutions and WP plugins for events already exist. But a practical solution of ongoing classes or group training, including payments, did not – until now.
Amelia 2.0 fully automates workshops, classes, and group training scheduling and payments. It doesn’t matter if they are single, multi-day, or recurring events. The scheduling and payments processes are streamlined, quick, and intuitive.
Spreadsheets are but a memory of times past.
Appointment and Event Scheduling You Can Really Use
Amelia has already been praised for its UI and UX. Did the Amelia 2.0 release make this plugin any better?
The short answer is – quite a bit.
New additions include the Gutenberg block and a pair of new languages – French and Dutch. As for the others; let’s take a look at what 4 of the most popular features look like now.
Admin Dashboard
Amelia gives its users an interactive dashboard summary of the business’s key performance indicators. KPI data is displayed in widgets, charts, and tables since KPIs are only of value when their actions are clear. It takes less than 5 seconds viewing Amelia’s dashboard to know where you stand.
Booking Wizard
The front-end view step-by-step booking wizard that takes Amelia users effortlessly through their booking or purchasing process is one of the more popular of this plugin’s features.
Visitors are naturally inclined to prefer a smooth UX that allows them to easily choose the services, locations, dates, and payment details they want, and even make changes without leaving the page.
Search Booking Widget
Choosing among highlighted events isn’t always enough. There will be times when users will have a need to search for an event they want to book.
The search widget makes searching easy and once an event is located, it presents all the options and preferences available including preferred time, place, service, employee, etc.
Multiple Front-End Views and Customizable Design
By inserting any of the following WordPress shortcodes into a page or post, users can unlock the following Amelia front-end views:
Booking Search
Step-by-Step Booking
Services Catalogue, or the
Events Booking view
No matter which view is chosen, the viewer is presented with a minimalist, non-intrusive UI. Where colors are used, they can be adjusted to match your brand or website theme.
Conclusion
Amelia is a booking and payments plugin featuring front-end design flexibility and UX together with the back-end management tools and automation your business requires. Amelia goes about its business 24/7 in background mode so you can devote your time to other pressing business tasks and issues.
There’s no longer any reason to have to work with multiple plugins or install a scheduler on your site that’s not quite up to the task. Amelia 2.0 does it all.
Shopping today is easier than before with the rise of e-commerce. You can make a purchase with just a few clicks and you don’t even have to leave the house!
E-commerce continues to grow and brick and mortar stores are beginning to adapt. They now have organized websites which are easy to navigate around and feature their products as prominently as possible.
The H&M E-Commerce Shop
The stores now have the task of making the product look appealing in-store and on their online store. However, displaying products for an online store is different compared to a physical store.
Many online shops face a major challenge because the customer can’t touch the item they want to purchase. When online shops establish their stores they need to create ideal photos to appeal to the browsing customer.
Keeping the customer’s attention does not require expensive studio lights or the fanciest equipment. You can make your products look more presentable on a budget with items you might already have with you:
1- Use a Smartphone Camera to Take Your Photos
There is a popular misconception that you always need a fancy, expensive camera to take photos of your products for e-commerce. This is not true. Your photos can be taken with a smartphone and you can still end up with an excellent quality product photo.
When you are on a budget you can use your smartphone to take photos of your products. Many smartphones today create high-quality photos without the need for an expensive DSLR camera. Popular smartphone brands such as Apple, Huawei, and Samsung invest in the cameras of their phones so you don’t have to rely on cameras to create great photos for your e-commerce products.
2- Use a DIY Lightbox to Light Up Your Products
Good lighting is the key to making your products look good. Having bad lighting can make your products look bad because shadows would display your products in a bad light.
One easy solution to your lighting problems is to have a lightbox. You can choose from a variety of premade lightboxes but, they can become costly.
In order to save money, you can make your own lightbox. A DIY lightbox will save you a lot of money because most of its parts can be found at home.
The base of the box can be made from any cardboard or plastic box you can find at home. You can use desk lamps to light up the box. There’s no need to spend a fortune on a box that only has one purpose.
There are online videos that instruct you on how to create your own lightbox. Making your box from scratch will save you a lot of money compared to purchasing a pre-made lightbox.
When you’re looking for lighting in your box you’re not limited to the desk lamp you are using. Natural light is a good alternative to the artificial light provided by desk lamps.
Using natural lights involves placing your product near a window with the sun shining through. This means you won’t have to use a lightbox to create your image.
An alternative to your lightbox can be a plain white sheet of paper, a platform to place the product and paper and a few clips to keep the paper in place.
Position the white sheet of paper near a source of sunlight such as your window at home.
Attach and clip the sheet to a platform that will hold it steady such as a chair.
Place your product on the white sheet of paper with the paper acting as the background.
3- Make Your Product Stand Out with the Help of a White Background
Photo from the Paper Boat Creative
Go to Amazon or any other online retailer and you’ll see that there’s a pattern to a lot of their product pages. Almost every online shop uses a white background to display their products.
Here are three reasons why you should use a white background for your online-only store:
Using a white background will save you a lot of space. Colored backgrounds take more time to load because the website has to load the colors of the product and the background. Users would have to wait for a while before they actually get what they came for which is the product.
White backgrounds are affordable. You don’t have to spend a lot of money on a white background to display your products. Even a small piece of white paper can act as your background. If you’re selling small items such as mugs or pencils, a small piece of white paper will be sufficient enough to display your merchandise. You don’t always have to use a large set up with expensive studio lights and backdrops.
Online buyers visit your store to browse your products and, hopefully, make a purchase. Don’t distract your buyers with dizzying colored backgrounds. A plain, white background will help the buyer’s eyes concentrate on the product instead of the background.
The kind of picture you want to display will be up to you as a photographer. There is another aspect that is even more important to make your products look good.
4- Retouch Your Photos to Make Them Stand Out
No matter how you shoot a photo of your product, there will always be some flaws that you can miss. This is where photo retouching comes in.
Photo retouching is an activity that involves cleaning up your photos by removing flaws so you can display your products in their best form.
Spotted a smudge on your product? You can use photo retouching to fix that? Want to add more copies of your product in one photo? Retouching can do that.
You can find an array of photo retouching tools online but the most popular retouching tool is still Adobe Photoshop. There are a lot of techniques you can use to improve your photos but, there are three techniques that stand out above the rest:
Use a Healing Brush to Remove Imperfections
If you’re featuring a model with your product, you might spot a blemish or a scar that the makeup could not cover. Using a healing brush will alleviate your problems. Choose a flawless patch of skin on the model and use that as a basis to remove the flaws on the rest of their skin.
Darken or Brighten your Product with Dodge and Burn
There’s a tool called Dodge and Burn that lets you darken or brighten parts of your image. Dodge and Burn help with adjusting your photo’s exposure. The exposure of an image determines how bright or how dark your image will look like.
Use the RAW File Format
One way to make your photo retouching easier is by using a RAW file format. Unlike a JPEG file format, the RAW file format gives you the freedom to adjust the settings of your picture without compromising the quality of the photo.
Using a JPEG file requires you to make a new copy of the picture every time because once you edit the picture, the quality of the photo becomes worse.
The RAW file format gives photo editors more freedom to play around with the settings of the photo because they don’t have to worry about a misplaced edit in one section. Using a RAW file means you can reset the settings of the photo back to how it was when you shot the image.
For more detailed instructions on dodge and burn and other features, you can visit the Adobe website. Their website explains all of the photo retouching features you can use on their software such as Photoshop.
Photoshop is just one of the many photo editing programs you can use to make your products look their best. There are other alternatives such as GIMP, Paint.Net and many others. The important thing is to make the image look good to the customer at first glance.
A study by Shopify mentioned that a buyer’s first impression is generated within 50 milliseconds before they leave a page. In order to capture the audience’s attention, you should look for instructional guides by companies that conduct e-commerce photo editing services such as the Paper Boat Creative.
Their website features guides on photo retouching and they even have a section dedicated to product photography so you can have a better understanding of how you can make your products look their best and keep the customer’s attention and, hopefully, make a purchase.
For a Better-Looking E-Commerce Photo
Creating the ideal e-commerce photo does not have to be expensive. Sometimes, the items you need will come from a small sheet of paper or a box you already have at home. Learning how to retouch your own photos will help you understand how to make your photos look excellent enough that customers can stay long enough on your page and make a purchase.
E-commerce photos can be created without spending a lot of money. All it takes is a few items you have at home and learning how to clean up your photos by yourself.
How does a web application actually work? I don’t mean from the end-user point of view. I mean in the technical sense. How does a web application actually run? What kicks things off? Without any boilerplate code, what’s the right way to structure an application? Particularly a client-side application where all the logic runs on the end-users device. How does data get managed and manipulated? How do you make the interface react to changes in the data?
These are the kind of questions that are simple to side-step or ignore entirely with a framework. Developers reach for something like React, Vue, Ember or Angular, follow the documentation to get up and running and away they go. Those problems are handled by the framework’s box of tricks.
That may be exactly how you want things. Arguably, it’s the smart thing to do if you want to build something to a professional standard. However, with the magic abstracted away, you never get to learn how the tricks are actually performed.
Don’t you want to know how the tricks are done?
I did. So, I decided to try building a basic client-side application, sans-framework, to understand these problems for myself.
But, I’m getting a little ahead of myself; a little background first.
Before starting this journey I considered myself highly proficient at HTML and CSS but not JavaScript. As I felt I’d solved the biggest questions I had of CSS to my satisfaction, the next challenge I set myself was understanding a programming language.
The fact was, I was relatively beginner-level with JavaScript. And, aside from hacking the PHP of WordPress around, I had no exposure or training in any other programming language either.
Let me qualify that ‘beginner-level’ assertion. Sure, I could get interactivity working on a page. Toggle classes, create DOM nodes, append and move them around, etc. But when it came to organizing the code for anything beyond that I was pretty clueless. I wasn’t confident building anything approaching an application. I had no idea how to define a set of data in JavaScipt, let alone manipulate it with functions.
I had no understanding of JavaScript ‘design patterns’ — established approaches for solving oft-encountered code problems. I certainly didn’t have a feel for how to approach fundamental application-design decisions.
Have you ever played ‘Top Trumps’? Well, in the web developer edition, my card would look something like this (marks out of 100):
CSS: 95
Copy and paste: 90
Hairline: 4
HTML: 90
JavaSript: 13
In addition to wanting to challenge myself on a technical level, I was also lacking in design chops.
With almost exclusively coding other peoples designs for the past decade, my visual design skills hadn’t had any real challenges since the late noughties. Reflecting on that fact and my puny JavaScript skills, cultivated a growing sense of professional inadequacy. It was time to address my shortcomings.
A personal challenge took form in my mind: to design and build a client-side JavaScript web application.
On Learning
There has never been more great resources to learn computing languages. Particularly JavaScript. However, it took me a while to find resources that explained things in a way that clicked. For me, Kyle Simpson’s ‘You Don’t Know JS’ and ‘Eloquent JavaScript’ by Marijn Haverbeke were a big help.
If you are beginning learning JavaScript, you will surely need to find your own gurus; people whose method of explaining works for you.
The first key thing I learned was that it’s pointless trying to learn from a teacher/resource that doesn’t explain things in a way you understand. Some people look at function examples with foo and bar in and instantly grok the meaning. I’m not one of those people. If you aren’t either, don’t assume programming languages aren’t for you. Just try a different resource and keep trying to apply the skills you are learning.
It’s also not a given that you will enjoy any kind of eureka moment where everything suddenly ‘clicks’; like the coding equivalent of love at first sight. It’s more likely it will take a lot of perseverance and considerable application of your learnings to feel confident.
As soon as you feel even a little competent, trying to apply your learning will teach you even more.
Here are some resources I found helpful along the way:
Right, that’s pretty much all you need to know about why I arrived at this point. The elephant now in the room is, why not use a framework?
Why Not React, Ember, Angular, Vue Et Al
Whilst the answer was alluded to at the beginning, I think the subject of why a framework wasn’t used needs expanding upon.
There are an abundance of high quality, well supported, JavaScript frameworks. Each specifically designed for the building of client-side web applications. Exactly the sort of thing I was looking to build. I forgive you for wondering the obvious: like, err, why not use one?
Here’s my stance on that. When you learn to use an abstraction, that’s primarily what you are learning — the abstraction. I wanted to learn the thing, not the abstraction of the thing.
I remember learning some jQuery back in the day. Whilst the lovely API let me make DOM manipulations easier than ever before I became powerless without it. I couldn’t even toggle classes on an element without needing jQuery. Task me with some basic interactivity on a page without jQuery to lean on and I stumbled about in my editor like a shorn Samson.
More recently, as I attempted to improve my understanding of JavaScript, I’d tried to wrap my head around Vue and React a little. But ultimately, I was never sure where standard JavaScript ended and React or Vue began. My opinion is that these abstractions are far more worthwhile when you understand what they are doing for you.
Therefore, if I was going to learn something I wanted to understand the core parts of the language. That way, I had some transferable skills. I wanted to retain something when the current flavor of the month framework had been cast aside for the next ‘hot new thing’.
Okay. Now, we’re caught up on why this app was getting made, and also, like it or not, how it would be made.
Let’s move on to what this thing was going to be.
An Application Idea
I needed an app idea. Nothing too ambitious; I didn’t have any delusions of creating a business start-up or appearing on Dragon’s Den — learning JavaScript and application basics was my primary goal.
The application needed to be something I had a fighting chance of pulling off technically and making a half-decent design job off to boot.
Tangent time.
Away from work, I organize and play indoor football whenever I can. As the organizer, it’s a pain to mentally note who has sent me a message to say they are playing and who hasn’t. 10 people are needed for a game typically, 8 at a push. There’s a roster of about 20 people who may or may not be able to play each game.
The app idea I settled on was something that enabled picking players from a roster, giving me a count of how many players had confirmed they could play.
As I thought about it more I felt I could broaden the scope a little more so that it could be used to organize any simple team-based activity.
Admittedly, I’d hardly dreamt up Google Earth. It did, however, have all the essential challenges: design, data management, interactivity, data storage, code organization.
Design-wise, I wouldn’t concern myself with anything other than a version that could run and work well on a phone viewport. I’d limit the design challenges to solving the problems on small screens only.
The core idea certainly leaned itself to ‘to-do’ style applications, of which there were heaps of existing examples to look at for inspiration whilst also having just enough difference to provide some unique design and coding challenges.
Intended Features
An initial bullet-point list of features I intended to design and code looked like this:
An input box to add people to the roster;
The ability to set each person to ‘in’ or ‘out’;
A tool that splits the people into teams, defaulting to 2 teams;
The ability to delete a person from the roster;
Some interface for ‘tools’. Besides splitting, available tools should include the ability to download the entered data as a file, upload previously saved data and delete-all players in one go;
The app should show a current count of how many people are ‘In’;
If there are no people selected for a game, it should hide the team splitter;
Pay mode. A toggle in settings that allows ‘in’ users to have an additional toggle to show whether they have paid or not.
At the outset, this is what I considered the features for a minimum viable product.
Design
Designs started on scraps of paper. It was illuminating (read: crushing) to find out just how many ideas which were incredible in my head turned out to be ludicrous when subjected to even the meagre scrutiny afforded by a pencil drawing.
Many ideas were therefore quickly ruled out, but the flip side was that by sketching some ideas out, it invariably led to other ideas I would never have otherwise considered.
Now, designers reading this will likely be like, “Duh, of course” but this was a real revelation to me. Developers are used to seeing later stage designs, rarely seeing all the abandoned steps along the way prior to that point.
Once happy with something as a pencil drawing, I’d try and re-create it in the design package, Sketch. Just as ideas fell away at the paper and pencil stage, an equal number failed to make it through the next fidelity stage of Sketch. The ones that seemed to hold up as artboards in Sketch were then chosen as the candidates to code out.
I’d find in turn that when those candidates were built-in code, a percentage also failed to work for varying reasons. Each fidelity step exposed new challenges for the design to either pass or fail. And a failure would lead me literally and figuratively back to the drawing board.
As such, ultimately, the design I ended up with is quite a bit different than the one I originally had in Sketch. Here are the first Sketch mockups:
Initial design of Who’s In application (Large preview)
Initial menu for Who’s In application (Large preview)
Even then, I was under no delusions; it was a basic design. However, at this point I had something I was relatively confident could work and I was chomping at the bit to try and build it.
Technical Requirements
With some initial feature requirements and a basic visual direction, it was time to consider what should be achieved with the code.
Although received wisdom dictates that the way to make applications for iOS or Android devices is with native code, we have already established that my intention was to build the application with JavaScript.
I was also keen to ensure that the application ticked all the boxes necessary to qualify as a Progressive Web Application, or PWA as they are more commonly known.
On the off chance you are unaware what a Progressive Web Application is, here is the ‘elevator pitch’. Conceptually, just imagine a standard web application but one that meets some particular criteria. The adherence to this set of particular requirements means that a supporting device (think mobile phone) grants the web app special privileges, making the web application greater than the sum of its parts.
On Android, in particular, it can be near impossible to distinguish a PWA, built with just HTML, CSS and JavaScript, from an application built with native code.
Here is the Google checklist of requirements for an application to be considered a Progressive Web Application:
Site is served over HTTPS;
Pages are responsive on tablets & mobile devices;
All app URLs load while offline;
Metadata provided for Add to Home screen;
First load fast even on 3G;
Site works cross-browser;
Page transitions don’t feel like they block on the network;
Each page has a URL.
Now in addition, if you really want to be the teacher’s pet and have your application considered as an ‘Exemplary Progressive Web App’, then it should also meet the following requirements:
Site’s content is indexed by Google;
Schema.org metadata is provided where appropriate;
Social metadata is provided where appropriate;
Canonical URLs are provided when necessary;
Pages use the History API;
Content doesn’t jump as the page loads;
Pressing back from a detail page retains scroll position on the previous list page;
When tapped, inputs aren’t obscured by the on-screen keyboard;
Content is easily shareable from standalone or full-screen mode;
Site is responsive across phone, tablet and desktop screen sizes;
Any app install prompts are not used excessively;
The Add to Home Screen prompt is intercepted;
First load very fast even on 3G;
Site uses cache-first networking;
Site appropriately informs the user when they’re offline;
Provide context to the user about how notifications will be used;
UI encouraging users to turn on Push Notifications must not be overly aggressive;
Site dims the screen when the permission request is showing;
Push notifications must be timely, precise and relevant;
Provides controls to enable and disable notifications;
User is logged in across devices via Credential Management API;
User can pay easily via native UI from Payment Request API.
Crikey! I don’t know about you but that second bunch of stuff seems like a whole lot of work for a basic application! As it happens there are plenty of items there that aren’t relevant to what I had planned anyway. Despite that, I’m not ashamed to say I lowered my sights to only pass the initial tests.
For a whole section of application types, I believe a PWA is a more applicable solution than a native application. Where games and SaaS arguably make more sense in an app store, smaller utilities can live quite happily and more successfully on the web as Progressive Web Applications.
Whilst on the subject of me shirking hard work, another choice made early on was to try and store all data for the application on the users own device. That way it wouldn’t be necessary to hook up with data services and servers and deal with log-ins and authentications. For where my skills were at, figuring out authentication and storing user data seemed like it would almost certainly be biting off more than I could chew and overkill for the remit of the application!
Technology Choices
With a fairly clear idea on what the goal was, attention turned to the tools that could be employed to build it.
I decided early on to use TypeScript, which is described on its website as “… a typed superset of JavaScript that compiles to plain JavaScript.” What I’d seen and read of the language I liked, especially the fact it learned itself so well to static analysis.
Static analysis simply means a program can look at your code before running it (e.g. when it is static) and highlight problems. It can’t necessarily point out logical issues but it can point to non-conforming code against a set of rules.
Anything that could point out my (sure to be many) errors as I went along had to be a good thing, right?
If you are unfamiliar with TypeScript consider the following code in vanilla JavaScript:
console.log(`${count} players`);
let count = 0;
Run this code and you will get an error something like:
I’m getting some feedback on my idiocy before I even run the code! That’s the beauty of static analysis. This feedback was often like having a more experienced developer sat with me catching errors as I went.
TypeScript primarily, as the name implies, let’s you specify the ‘type’ expected for each thing in the code. This prevents you inadvertently ‘coercing’ one type to another. Or attempting to run a method on a piece of data that isn’t applicable — an array method on an object for example. This isn’t the sort of thing that necessarily results in an error when the code runs, but it can certainly introduce hard to track bugs. Thanks to TypeScript you get feedback in the editor before even attempting to run the code.
TypeScript was certainly not essential in this journey of discovery and I would never encourage anyone to jump on tools of this nature unless there was a clear benefit. Setting tools up and configuring tools in the first place can be a time sink so definitely consider their applicability before diving in.
There are other benefits afforded by TypeScript we will come to in the next article in this series but the static analysis capabilities were enough alone for me to want to adopt TypeScript.
There were knock-on considerations of the choices I was making. Opting to build the application as a Progressive Web Application meant I would need to understand Service Workers to some degree. Using TypeScript would mean introducing build tools of some sort. How would I manage those tools? Historically, I’d used NPM as a package manager but what about Yarn? Was it worth using Yarn instead? Being performance-focused would mean considering some minification or bundling tools; tools like webpack were becoming more and more popular and would need evaluating.
Summary
I’d recognized a need to embark on this quest. My JavaScript powers were weak and nothing girds the loins as much as attempting to put theory into practice. Deciding to build a web application with vanilla JavaScript was to be my baptism of fire.
I’d spent some time researching and considering the options for making the application and decided that making the application a Progressive Web App made the most sense for my skill-set and the relative simplicity of the idea.
I’d need build tools, a package manager, and subsequently, a whole lot of patience.
Ultimately, at this point the fundamental question remained: was this something I could actually manage? Or would I be humbled by my own ineptitude?
I hope you join me in part two when you can read about build tools, JavaScript design patterns and how to make something more ‘app-like’.
In September 2018, I was just a few months into my journey of learning web development. As I’m sure is the case with many new developers, it was a big task for me to learn not only the basic skills required, but also keeping current with the fast-moving industry. Just as I was getting to the level where it felt as though I could build a simple website, I started to realize that it was only the first step.
Opening up a few HTML pages stored locally on my laptop felt like a million miles away from being able to say to someone, “Hey, check out my website, live on the actual internet!”
But I did it! And the best part is that it wasn’t as scary, difficult or expensive as it first felt like it’d be.
It all started with me sending Chris an email, which he used to write an awesome article explaining everything in plain English.
At this point, I didn’t have a fully coded website — just an idea for a basic site that I was using to teach myself as I went along. I used the ongoing progress of my site as a push to learn how to get a live website quicker. But I’m sure you could do the whole thing with an HTML document that just says “Hello, world!”
I built my site using Gatsby, a static site generator powered by React. Building a website with these tools in a modular way felt really natural to me. The concept of reusable parts is something I’m familiar with in my career as a physical product designer and mechanical design engineer. It means that you can build in stages, like Lego, brick-by-brick, until you eventually have a life-sized castle you can invite your friends to visit!
This isn’t a guide. It’s my personal experience in the process of getting a website from my laptop to being live on the internet. Hopefully it’ll give you some hope that it’s possible and achievable, even by someone who has no formal training in web development and who has only been doing it for 12 months!
Domain registrars
Before I ever bought a domain, it seemed like a pretty serious thing to do. Owning a domain means being responsible for it. People will go to that address and eventually see content that you’ve put there.
I don’t know if everyone has the same experience, but I spent weeks deciding on a domain name before going for it. It almost became an obsession of mine for a while, searching online for acronym generators to try and be clever, spending hours on dictionary.com trying to find synonyms that were cool. In the end, I settled for my name and what I do: joshlong.design. I still smile a little when I see my name in the address bar.
Since reading Chris’ article, I’ve actually bought two domains from two different providers: a .com and a .design. I realize that I went against Chris’ advice of consolidating domain names at a single registrar, but I needed to shop around a bit to get a good deal on my .design domain. I only own two domain names — and one of them I don’t actually have any plans for just yet — so keeping on top of where I bought them isn’t a task. In fact, I don’t remember the last time I needed to login and manage the domain I use on a daily basis!
Buying a domain name was as simple as any other online shopping transaction. Nothing really huge or scary about it. I bought my .com through Namecheap, and my .design through Google Domains, and the process was pretty similar for both. All they needed was my name, address and payment details. Pretty standard stuff!
I don’t remember Google trying to sell me a load of extra packages. They seemed happy with me just buying a domain, though they did offer me free WHOIS protection which I snapped up because I didn’t want my contact details freely available for anyone who’s feeling nosey. However, as Chris warned might happen, the other registrar I went through tried really hard to sell me some extras like hosting, email, a VPN (whatever that is!) and SSL certificates.
Google Domains checkout is happy just to sell the domain name.Namecheap tries to sell you all the additional services they offer before getting to the checkout.
I didn’t go for any of those extras. I already had a hosting plan, and you can use an alias through Gmail to “fake” having a me@mycoolsite.com email address. I honestly have no idea why I’d need a VPN, and the hosting I was going to go for gave me a free SSL certificate through Let’s Encrypt. So just the domain name, please!
Hosting
As Chris suggested it would be, choosing a host was a tad trickier than choosing and buying a domain name. But in the end, the web technology I used to build my site kind of guided me in a particular direction.
My site is built with Gatsby, which means it outputs straight-up static assets, basically as HTML and JavaScript files. That means that I didn’t need a host that offered a server (in my most super smart authoritative voice), especially for WordPress with a MySQL database and Apache server, 6 cores @ 3.6 Ghz, 4GB RAM, 5TB bandwidth, 5 IP Addresses and 500GB SSD Storage, etc.
All that jargon goes straight over my head. All I wanted to do was upload my files to the internet and go to my domain to see them all compiled and shiny. Should be easy, right?
Well it turns out that it actually was that easy. As there’s been so much hype around it recently, I thought I’d take a look at Netlify.
Netlify is recommended by Gatsby. They have really good documentation, and for my uses I felt as though I could comfortably stay within the free tier that they offer. In fact, at the moment I’m using 0.08% a month of the total bandwidth the free tier offers. Winning! Although maybe that means I’m not doing enough to get people to my site…
A quick aside about GitHub: I’m no expert at it and I don’t really know any of the etiquette it entails. All I did was sign up, create a new repository and follow the instructions that they give you. After that, every time I made a change to my site, I used the buttons in my code editor (VS Code) to commit and push my changes. It works, but I have no idea if it’s the correct or best practice way of doing it! I’m starting now, though, to understand how to use Git through the command line. I had no idea at all how to do it when I started, but I still muddled through it — and you can too!
Back to Netlify.
I signed up for an account (no credit card details required) and added a new site to Netlify by telling it about the GitHub repository where it was stored. When you’ve connected your repository, you can watch Netlify doing its thing deploying your site.
Part of the Netlify’s deploy process is that it shows your website going live in real time. That’s useful for debugging if something goes wrong, or just to watch and get excited like an impatient puppy waiting for a biscuit.You also get a deploy summary to quickly see what files were uploaded during deployment.
After my site was deployed to the randomly generated URL Netlify gives you, I followed their instructions for adding a domain I had registered elsewhere. They make it so easy!
I assume the instructions will be different for different hosts, but basically, Netlify gave me some server addresses which I then had to go back to my domain registrar to enter them in. These addresses are referred to as nameservers, so look out for that word!
Netlify gives you your nameserver addresses and super easy to understand documentation to set them up with your domain registrar
Once I entered my Netlify nameservers into Google Domains, Google knew where to look to send people who type my domain name into their browser’s address bar. All I had to do after that was wait for some internet magics to happen in the background. That took around three hours for me but can take anywhere from 10 minutes to 24 hours from what I hear.
After that was done, I could type my shiny new domain name into the address bar and — just like that — I’m looking at my own site, hosted live on the internet!
Content Management Systems
The world of Content Management Systems (CMS) is vast, and confusing, but it can also be completely irrelevant to you if you want it to be. I felt so liberated when I realized you don’t have to worry about it. It was one less thing in my list of things to do.
My Gatsby site posts and pages (my content) was just a directory of markdown files and my CMS was my text editor. Chris and Dave talked about the idea of this in a recent episode of ShopTalk Show.
My website content is managed right in my text editor, VS Code.
Because I wanted to have a standard structure for different types of posts and pages, I eventually started using NetlifyCMS which is an open-source CMS which can be included in your site real fast. (Chris also did a video recently about NetlifyCMS for his confer-reference site… see what I did there?!) Now I can create blog posts and drafts from anywhere in the world, straight from my website, as long as I have an internet connection!
The same content managed through NetlifyCMS, which offers a great UI and GitHub integration
Asset Hosting (CDNs)
A Content Delivery Network (CDN), as Chris explained in his article, is basically somewhere on the internet where you store the files you need for your website to run, HTML, CSS, images, etc. When your website needs them, it goes to the CDN and grabs the files for your site to use.
From what I’ve read, it’s good practice to use a CDN, and because of the hosting decision I made, it’s not something I have to worry about – it’s included by Netlify as standard, for free!
Netlify has it’s own CDN where all of the files for your website are stored. When someone goes to your website, Netlify goes to its CDN and grabs the files. It’s amazingly quick, and makes your site feel so much smoother to navigate.
It’s a long journey, but you can do it!
There was a point, before I set off on the journey of getting my website live, where I tried to convince myself that it’s fine to just have local websites, as my career isn’t in web development. The reason for that was because the path felt like it would be difficult, long and expensive.
In fact, it was none of those things! You could get a website live on the internet for £0.99 (~$1.25 for you Americans) or less if you find a deal on a domain name. The domain name was my only expense because for the path I took for hosting, asset management and content management.
At a super basic level, the path looks like this..
If you happen to use the same vendor to buy your domain name and your hosting, you can skip the nameserver step. (Netlify sells domains too!)
It’s definitely possible for anyone to get their website live on the internet. There’s a process that you need to follow, but if you take your time, it can be relatively straightforward. It’s a really wonderful feeling, getting a thing you built in front of people, and it’s honestly something that I thought I’d never be able to do. But it’s certainly within everyone’s reach!
Something I’ve come to really admire over this process (and thousands of Google searches) is the willingness of everyone in the web community to collaborate and help, accepting me and my questions as I tried to learn what I was doing. It’s something that I wish was more common in my own industry.
I’d love to hear other people’s experiences getting their first website live. What were your pitfalls and triumphs? Was it as scary as it first seemed?
There are an awful lot of libraries that want to help you animate things on the web. These aren’t really libraries that help you with the syntax or the technology of animations, but rather are grab-and-use as-is libraries. Want to apply a class like “animate-flip-up” and watch an element, uhhh, flip up? These are the kind of libraries to look at.
I wholeheartedly think you should both 1) learn how to animate things in CSS by learning the syntax yourself and 2) customize animations to tailor the feel to your site. Still, poking around libraries like this helps foster ideas, gets you started with code examples, and might form a foundation for your own projects.
Let’s take a look at the landscape of them. Some libraries have different approaches: only take what you need classes, Sass mixins, light JavaScript libraries for adding/removing classes, etc. But they are all essentially “CSS animation libraries.” (Some of them are kinda funny having “CSS3” in the title, which kinda dates them. People just don’t say that anymore.)
While animations can both be fun and create useful interactions, it’s worth remembering that not all users want them when browsing the web. See Eric Bailey’s “Revisiting prefers-reduced-motion, the reduced motion media query” for information on how to accommodate users who prefer little or no motion.
You pick an animation you like and it gives you a class name you can use that calls a keyframe animation (you copy and paste both). The point is you just take what you need.
Tachyons itself is an atomic CSS library with a ton of utility classes for essentially designing anything by adding classes to what you need. tachyons-animate extends those by adding “Single purpose classes to help you orchestrate CSS animations.” It can be used alone, but even the docs suggest it can be used in combination with other animation libraries since helper classes are generically useful.
A collection of CSS3 powered hover effects to be applied to links, buttons, logos, SVG, featured images and so on. Easily apply to your own elements, modify or just use for inspiration. Available in CSS, Sass, and LESS.
The BigInt data type aims to enable JavaScript programmers to represent integer values larger than the range supported by the Number data type. The ability to represent integers with arbitrary precision is particularly important when performing mathematical operations on large integers. With BigInt, integer overflow will no longer be an issue.
Additionally, you can safely work with high-resolution timestamps, large integer IDs, and more without having to use a workaround. BigInt is currently a stage 3 proposal. Once added to the specification, it will become the second numeric data type in JavaScript, which will bring the total number of supported data types to eight:
Boolean
Null
Undefined
Number
BigInt
String
Symbol
Object
In this article, we will take a good look at BigInt and see how it can help overcome the limitations of the Number type in JavaScript.
The Problem
The lack of an explicit integer type in JavaScript is often baffling to programmers coming from other languages. Many programming languages support multiple numeric types such as float, double, integer, and bignum, but that’s not the case with JavaScript. In JavaScript, all numbers are represented in double-precision 64-bit floating-point format as defined by the IEEE 754-2008 standard.
Under this standard, very large integers that cannot be exactly represented are automatically rounded. To be precise, the Number type in JavaScript can only safely represent integers between -9007199254740991 (-(253-1)) and 9007199254740991 (253-1). Any integer value that falls out of this range may lose precision.
This can be easily examined by executing the following code:
This integer is larger than the largest number JavaScript can reliably represent with the Number primitive. Therefore, it’s rounded. Unexpected rounding can compromise a program’s reliability and security. Here’s another example:
// notice the last digits
9007199254740992 === 9007199254740993; // → true
JavaScript provides the Number.MAX_SAFE_INTEGER constant that allows you to quickly obtain the maximum safe integer in JavaScript. Similarly, you can obtain the minimum safe integer by using the Number.MIN_SAFE_INTEGER constant:
const minInt = Number.MIN_SAFE_INTEGER;
console.log(minInt); // → -9007199254740991
console.log(minInt - 5); // → -9007199254740996
// notice how this outputs the same value as above
console.log(minInt - 4); // → -9007199254740996
The Solution
As a workaround to these limitations, some JavaScript developers represent large integers using the String type. The Twitter API, for example, adds a string version of IDs to objects when responding with JSON. Additionally, a number of libraries such as bignumber.js have been developed to make working with large integers easier.
With BigInt, applications no longer need a workaround or library to safely represent integers beyond Number.MAX_SAFE_INTEGER and Number.Min_SAFE_INTEGER. Arithmetic operations on large integers can now be performed in standard JavaScript without risking loss of precision. The added benefit of using a native data type over a third-party library is better run-time performance.
To create a BigInt, simply append n to the end of an integer. Compare:
The reason that the unary plus (+) operator is not supported is that some programs may rely on the invariant that + always produces a Number, or throws an exception. Changing the behavior of + would also break asm.js code.
Naturally, when used with BigInt operands, arithmetic operators are expected to return a BigInt value. Therefore, the result of the division (/) operator is automatically rounded down to the nearest integer. For example:
25 / 10; // → 2.5
25n / 10n; // → 2n
Implicit Type Conversion
Because implicit type conversion could lose information, mixed operations between BigInts and Numbers are not allowed. When mixing large integers and floating-point numbers, the resulting value may not be accurately representable by BigInt or Number. Consider the following example:
(9007199254740992n + 1n) + 0.5
The result of this expression is outside of the domain of both BigInt and Number. A Number with a fractional part cannot be accurately converted to a BigInt. And a BigInt larger than 253 cannot be accurately converted to a Number.
As a result of this restriction, it’s not possible to perform arithmetic operations with a mix of Number and BigInt operands. You also cannot pass a BigInt to Web APIs and built-in JavaScript functions that expect a Number. Attempting to do so will cause a TypeError:
Note that relational operators do not follow this rule, as shown in this example:
10n > 5; // → true
If you want to perform arithmetic computations with BigInt and Number, you first need to determine the domain in which the operation should be done. To do that, simply convert either of the operands by calling Number() or BigInt():
When encountered in a Boolean context, BigInt is treated similar to Number. In other words, a BigInt is considered a truthy value as long as it’s not 0n:
if (5n) {
// this code block will be executed
}
if (0n) {
// but this code block won't
}
No implicit type conversion occurs when sorting an array of BigInts and Numbers:
Bitwise operators such as |, &, <<, >>, and ^ operate on BigInts in a similar way to Numbers. Negative numbers are interpreted as infinite-length two’s complement. Mixed operands are not allowed. Here are some examples:
As with other primitive types, a BigInt can be created using a constructor function. The argument passed to BigInt() is automatically converted to a BigInt, if possible:
You can directly perform arithmetic operations on a BigInt created using a constructor:
BigInt(10) * 10n; // → 100n
When used as operands of the strict equality operator, BigInts created using a constructor are treated similar to regular ones:
BigInt(true) === 1n; // → true
Library Functions
JavaScript provides two library functions for representing BigInt values as signed or unsigned integers:
BigInt.asUintN(width, BigInt): wraps a BigInt between 0 and 2width-1
BigInt.asIntN(width, BigInt): wraps a BigInt between -2width-1 and 2width-1-1
These functions are particularly useful when performing 64-bit arithmetic operations. This way you can stay within the intended range.
Browser Support And Transpiling
At the time of this writing, Chrome +67 and Opera +54 fully support the BigInt data type. Unfortunately, Edge and Safari haven’t implemented it yet. Firefox doesn’t support BigInt by default, but it can be enabled by setting javascript.options.bigint to true in about:config. An up-to-date list of supported browsers is available on Can I use….
Unluckily, transpiling BigInt is an extremely complicated process, which incurs hefty run-time performance penalty. It’s also impossible to directly polyfill BigInt because the proposal changes the behavior of several existing operators. For now, a better alternative is to use the JSBI library, which is a pure-JavaScript implementation of the BigInt proposal.
This library provides an API that behaves exactly the same as the native BigInt. Here’s how you can use JSBI:
An advantage of using JSBI is that once browser support improves, you won’t need to rewrite your code. Instead, you can automatically compile your JSBI code into native BigInt code by using a babel plugin. Furthermore, the performance of JSBI is on par with native BigInt implementations. You can expect wider browser support for BigInt soon.
Conclusion
BigInt is a new data type intended for use when integer values are larger than the range supported by the Number data type. This data type allows us to safely perform arithmetic operations on large integers, represent high-resolution timestamps, use large integer IDs, and more without the need to use a library.
It’s important to keep in mind that you cannot perform arithmetic operations with a mix of Number and BigInt operands. You’ll need to determine the domain in which the operation should be done by explicitly converting either of the operands. Moreover, for compatibility reasons, you are not allowed to use the unary plus (+) operator on a BigInt.
What do you think? Do you find BigInt useful? Let us know in the comments!
Let’s start with a common example: You’ve just finished a website design for someone. It looks and functions exactly like the wireframe. Everyone on the design team has praised the project. The client hates it, but they can’t explain why.
The culprit might be color. Different colors can evoke such strong emotions that people have sharp reactions to them. It’s part personal preference, part psychological, and even part social norms. Understanding these tendencies and user preferences can greatly impact user experience.
Here’s what you need to know.
User Expectations and Preferences
User experience starts with the type of user your website or app is designed for. Basic demographics such as gender or region where a user lives can impact their perception of your design based on color. (You can read more about color and cultural considerations here.)
One of the most interesting impacts from color on UX is linked to gender. Studies have shown that men and women tend to like and dislike certain types of color.
Men tend to interact more with websites that have darker design schemes and more saturated colors, such as the design for VLNC Studio, above.
Women tend to prefer to interact with websites that have lighter design schemes and more muted color palettes, such as Tally, below.
Some men have a sharp reaction to websites using distinctly feminine colors such as pastel pinks, purples, and yellows.
More women tend to be put off by websites with harsh color schemes such as dark background with fully saturated red accents.
Mid-tone palettes are the most generally appealing to everyone.
Color Associations and Meanings
While it’s not an exact science, colors have fairly distinct emotional associations. Note that some colors can fall into categories of extremes. These associations tend to work with other design elements to create an overall vibe.
When a user sees a certain color or combination of colors, it creates an immediate response in the brain.
You expect design elements for Coca-Cola to be red. The color is so synonymous with the brand that it’s referred to as “Coke red.” Change the color and the brand is confusing. You don’t recognize it right away. The user is jarred and doesn’t quite react in the expected fashion. The drink might even seem to taste different.
All of those feelings come from changing the color. You might have felt yourself say “what?” when you saw the first image with green Coca-Cola branding.
It impacted the user experience you would have with the brand moving forward.
Color is an important element in branding because it creates that distinct connected between a user and a design. Color tells users what the brand is about. It tells users about the thing they are about to engage with.
Change that color, or use something off brand, and the user experience suffers because website visitors are suddenly confused or uncertain about the brand they thought they knew.
User Patterns Connect to Color
Have you noticed how many websites use red or orange buttons?
There’s a reason for that.
Bright colored buttons that contrast with the background of a website – red and orange often stand out from either light or dark backgrounds. Can help users find, understand, and want to engage with click- or tappable elements because they visually, and immediately, know what their expectation of that element is.
A key part of user experience is providing easy opportunities for users to interact that they enjoy and understand.
Cruise uses a ghost-style button with red text and a red hover state. It’s a different spin on traditional solid-color buttons, but there’s little question as to how to interact with it. Color draws users to the button.
Net Bluez uses a bright orange button for the most important element in the navigation menu. Notice how that element tends to jump off the screen begging to be clicked.
Increasing Conversion Rates
Challenge yourself in the design process to A/B Test button color. You’ll likely find that one color has a distinctly higher conversion rate than the other. (And it might not be the color you expect.)
Conversion rates tend to increase when the color of buttons or links is in stark contrast to the rest of the design. So, while you want to use a brand palette, picking a contrast color is key to generating conversions that contribute to overall user experience.
Look at the website below for a minute. Which color button is most likely to make you click? (The original color is blue.)
Providing Accessibility to All Users
Finally, color impacts UX in a way that’s not emotional or rooted in psychology. It’s much more practical than that.
Color impacts user experience because it can make a design accessible or not.
In order for everyone to understand a design fully, and engage with content, they must be able to see and read it with ease. Using color palettes and contrast ratios that fall in line with Web Content Accessibility Guidelines (WCAG 2.1) can ensure that every user can understand your color choices.
Use a color-blind filter, such as those in the comparisons below, to help simulate what other users might see when they look at your website. How could that impact usability?
Conclusion
Think of color as a tool to help users better interact and experience the content on your website. It impacts user experience on an emotional and usability level.
The key to figuring out if color is impacting UX in the right way is through user testing. A/B color tests can be a valuable tool.
How do you stand out from the crowd and convince you’re customers that you’re worthy of doing business with? Your website can be a strong indication of your trustworthiness. In this article, we’ll share five tools and practices you can implement to stand out as a trustworthy online business.
Why is it important that customers trust you?
People don’t want to spend money with businesses they don’t trust. This isn’t a crazy idea – if you’ve ever bought a car, you’ve considered the trustworthiness of the person selling it to you. Can you believe what they say? When you give them your money, will you get what you expect in return? Trust is a big factor in our decision-making process.
For online businesses, this is even more important. In-person you can touch the product you’re buying. You can speak directly with the person you’re buying from. When you purchase something online, you have to trust that it will be in good condition when it arrives. Trust is an important consideration for shoppers across industries; 90 percent of shoppers would only purchase financial services products from a known, trusted brand. The same idea holds true for medical expenses (91 percent), consumer electronics (83 percent), and even lower-priced items, like shoes (66 percent).
Trust isn’t just important for gaining new customers – it also helps businesses retain the customers they already have. Salesforce found that 95% of customers are more likely to be loyal to a company they trust. Furthermore, 92% are more likely to purchase additional products and services from trusted businesses.
5 Tools and Practices to Build Trust with Customers
Fortunately for online businesses, there are best practices that can help you build trust with your customers. The way you design your website can help reassure customers that you’re a legitimate business with their best interests in mind. Read below for five strategies you can employ to build trust with customers.
Make it easy to contact you
When customers have questions, it’s important that they are able to get in touch with a real human who can help. It doesn’t have to be a phone number. Something as easy as making an email address or live chat available can make customers feel more at ease with purchasing. That way, not only can they get their questions answered upfront, they also know you’re there if something goes wrong (such as a lost delivery).
Offering live chat is one of the most effective customer service contact channels because it provides immediate, personal, conversational help. Customers feel like they are connecting with a real human, and that makes them feel a connection with your brand.
Customers trust online reviews almost as much as they trust personal recommendations from friends and family. If you’re looking to build trust, displaying authentic customer reviews is a great way to do so. BrightLocal did an experiment where they created two versions of the same business website: one with customer reviews and one that only included the business’ reassurance that they were trustworthy. Respondents rated the website that included customer reviews substantially more trustworthy than the website without.
If you’d like to display customer reviews on your website, start by either providing a place on your site for reviews to be submitted or ask customers to provide a review after they’ve received the product. Make sure that you have the customer’s permission to showcase any review that you display on your website.
Display terms of service and privacy policy
Not only does having terms of service and a clear privacy policy present on your website reassure customers that you’re a legitimate business, but it’s also required by law if you want to do business in Europe. The General Data Protection Regulation (GDPR) requires all businesses to display an easy to read privacy policy on their website that lists the personal information the business will collect and how the business aims to keep that data safe (along with other information.
Secondly, including terms of service and your privacy policy on the website improves your TrustRank according to Google. What is TrustRank? It’s a link analysis technique used by search engines to separate spam from legitimate content. Having a higher TrustRank can help you rank higher on search engines and also prevent Google from flagging you as suspicious content.
Pay attention to your content
Which website are you more likely to trust? One that is riddled with typos and grammatical errors or one that looks professional? Your content says more than you think it does.
To gain the trust of your readers, spend time proofreading or hire a professional copyeditor to look over your site. If English isn’t your primary language, this is still important – your visitors could be coming from all over the world. Having a well-written website makes you look more authoritative.
It’s also important to provide references for any stats you use and cite any quotations that you’ve found on other sites. Secondly, linking to trustworthy sites (for example, well-respected news outlets) can help boost your TrustRank score as well. When readers know that they can believe what you’re saying, they will trust your sales claims too!
Consider using a Trust Badge
A surprising 70% of shoppers cancel their orders or abandon their online purchase just because they don’t trust the website. Trust seals or trust badges can help reduce this issue by signifying that your website is committed to the security and privacy protection.
A trust badge is purchased from a third-party company to indicate a certain level of security. Trust seals need to be earned and verified before they are displayed – you can’t just copy and paste an image from a Google search.
“A trust seal verifies to visitors that a website is legitimate. Data is collected by the third-party trust seal company that confirms that the business is authentic.” – Marie from CrazyEgg
While all of these tools will help you build a closer, more trusting relationship with your customers, nothing can compensate for shady behavior. Ultimately, your actions will speak louder than your words. Ensure you’re acting with integrity, doing what you say you will and delivering a consistently excellent customer experience.
While your website design can help build trust, one misstep will result in losing it all. Work tirelessly to deserve the trust your customers put in you, and enjoy a lifetime of success.
