DEV Community: itsharshag

UI vs UX

itsharshag — Sun, 10 Apr 2022 14:25:48 +0000

If you have been curious about the difference between UI and UX, this article will help you in understanding the difference.

User Interface (UI)

UI designers deal with the visual aspect of a product.

They are responsible for the look and feel of a website. They deal with things like typography, white space, and colors to make a website look good They focus on having a contrast between text and other elements on a page to ensure readability and accessibility. They think about the layout of the website like which is the best area to place a piece of text or an image or a button. They make designs for multiple screen sizes like laptops and mobiles. They integrate the brand's identity into the whole design by using brand colors and brand-specific graphics. They ensure that the design of the different pages is consistent.

User Experience

UX designers are responsible for designing and optimizing the user experience of a product.

UX designers think about how to enhance a product and make it more user-friendly. They analyze whether interacting with the product is straightforward or not. Is the experience smooth or clunky? They map out and optimize the user journey which is all the possible ways a user can interact with a product. They take care of things like how many steps is it taking to do a particular task. They try to reduce complexity. They talk to users, see the analytics data, and critically think about ways to improve the experience of a product.

Now, let's go over a few examples

Example 1

Suppose you have a quotes website where you have curated the quotes from the best authors and celebrities in the world.

The UX designer discovers that what people often do is that they copy a quote by selecting the desired text manually and then send it to their friends. The UX designer proposes the addition of a copy button to allow users to copy the text with a button click. The UX designer came up with a solution to improve the user experience.

The UI designer will now think about where to place the copy button, what icon to use for it, and what should be the color for it.

Example 2

You have a gaming news website

The UX designer discovers that people are coming to the signup page but only a small percentage of people finish signup. The designer investigates and finds that the signup form is long. It's asking for Full Name, Email, Password, Gender, Address, and Preferences. Users don't like this and don't signup. The designer proposes that we only ask for the full name, email, and password and after a user logs in, we can get the other details eventually.

Now, the UI designer makes the desired changes to the form and ensures that the design still looks good.

In this example also, the UX designer identified the area of improvement and proposed a solution for it. The UI designer made the necessary visual changes and ensured that the new design is consistent with the rest of the design.

So, that’s it in a nutshell. I hope you got an idea of the difference between UI and UX.

Horizontal and Vertical Scaling

itsharshag — Sat, 19 Mar 2022 09:01:27 +0000

Imagine you have built a website that solves mathematical equations. You receive an equation as input and calculate the solutions on your server and return them back. And your server runs on a machine that has 1GB RAM and a 2-cores CPU. And you get 100 requests per hour which your server is able to respond to within an acceptable time.

But suddenly your website gets popular in the academic circles and starts receiving 1000s of requests per hour. You notice a heavy slowdown of responses on your website and even some failed requests.

To fix this situation, you will need to scale your servers. There are two approaches to scaling your servers: Horizontal and Vertical

Vertical Scaling (or scaling up) means switching to a better machine or upgrading your current machine. That means you switch to a machine that has more resources like more RAM, more CPU Cores, more storage, and better networking hardware. So, upgrading your existing set of machines refers to vertical scaling.

But you can’t infinitely vertical scale your servers. With much more bulky machines, the chance of them getting shut down is more and there is also a physical limit on how large a single machine can be. Also, if this machine goes down, people will not be able to visit your website until the machine and your server boot up.

To fix this, we have the horizontal scaling (or scaling out) approach. We create a pool of machines with the same configuration and then distribute incoming requests to them. Even if one of the machines goes down, the load can be distributed over to the remaining machines. This takes care of the single point of failure issue.

In practice, we use both horizontal and vertical scaling. Tools like Kubernetes, AWS ASG, and AWS LB allow us to manage horizontal and vertical scaling with ease.

Lessons I learned from my failed side project

itsharshag — Sat, 19 Mar 2022 09:00:03 +0000

I worked on a side project for six months. Even though I failed with it, I learned a lot of valuable lessons from it. In this blog, I will share those with you. Hopefully, they will be useful in your journey too.

You can have all the fun you want with your side project. Go ahead and use those experimental technologies and do wild things in your project. But in case you do want it to grow into a business, it will be best to avoid these mistakes:

Don't write your code in a new technology for fun or performance

Coming from React, I was attracted to Svelte's simplicity and hence decided to use it to build my side project. If I would have used React, I could have reused a lot of code that I had written in the past.

I migrated my express server to Go in between to get "performance" to remain future-proof and handle more requests with fewer resources. Hardly 10 users landed daily on my website and here I was concerned about "performance".

All this time I spent learning svelte and code migrations could have utlized in sales and marketing.

Use a new technology only when it solves a pressing need.

Don't reinvent the wheel

I rewrote my side project in SvelteKit because I was looking for server-side-rendering. SvelteKit was in beta at that stage, I faced compatibility issues, and doing simple stuff involved a lot of reading and exploration.

Instead of SvelteKit, I could have chosen a mature technology like Next.js.

I also designed components like Cards and Tabs myself to have the most "optimized" JS bundle.

Build the product and users will come

Nope, they won't. You will have to build distribution channels.

Build a large waitlist
Reach out to friends and family
Post content regularly on social media
Engage with people online
Build a community on Discord
Invest in a blog and SEO

After spending six months on the product, I had <200 registered users. A good Product Hunt launch brings 200+ users in just a few days.

Introduction to Content Delivery Networks

itsharshag — Sat, 19 Mar 2022 08:57:58 +0000

Unless you are Warren Buffet, you will most likely need a fancy website with images, videos, and unique styles to capture the attention of your audience. But usually all of this can sum up to a lot of data. Images and videos are heavy. CSS and JS code combined for even a regular website can be a significant amount.

To reduce the load of all of these things that you can put in public and ensure fast delivery to the people who are viewing your website, you can use a CDN (Content Delivery Network). A CDN is designed to deliver all static assets of a website like images and videos to end users at a fast speed.

CDNs are a globally distributed set of servers that cache your static assets whenever any user visits your website for the first time. All the subsequent requests from that user and other users will be a lot faster because they will be receiving a cached copy of the asset. CDNs are geographically located in a higher number of locations, and that ensures that your user will receive the cached as quickly as possible. The load times for images, videos, and styles will be reduced, and your users will have a better experience.

Unless you are deploying your applications on the edge, most application servers are present in only one or just a couple of locations. Even if you're deploying on the edge, using a CDN to serve static assets is a better choice as it reduces the number of requests on your servers and reduces the load on your application servers.

A couple of widely used CDNs are Cloudflare, Amazon CloudFront, and Akamai CDN.

I like to use Cloudflare because it's free and has a great onboarding experience. I use it for a number of my projects. I connect Cloudflare to a public bucket on BackBlaze and then when once the cache gets built, Cloudflare serves assets at fast speeds.

This is a great article on how to connect a BackBlaze bucket to Cloudflare to cache assets for your website: https://help.backblaze.com/hc/en-us/articles/217666928-Using-Backblaze-B2-with-the-Cloudflare-CDN