Nahuel Sanchez

A place to write down what I discover and learn everyday at my workplace. Front-end may be the main topic, but who knows, probably I'll be publishing something else.

You're looking at all the posts published by Nahuel Sanchez.
← Go back to the front page

Do not forget about the emotions while selling something

I'm selling two iPhone X, Space Gray color, both with 256 GB of capacity. When I bought them I wasn't sure about getting the 64 GB version or the bigger one, but I made up my mind in favor of the 256 GB version and I'll tell you why it was a great decision.

Last year I went on a family trip with my mom and sister to a Brazilian beach where cellular signal wasn't available all the time, meaning LTE was a luxury, and also finding WiFi was a Tom Cruise's "Mission Impossible" remake possible plot.

In this scenario, the idea of today's about everything being in the cloud and not in the physical devices was a no go for me.

The trip was beyond great. I spent a lot of time in the water with my sister trying to record the best slow motion videos: sometimes trying with just the water, sometimes filming the sand to see if that improves the video, then letting my sister try some tricks in front of the iPhone camera over and over again until we get something good.

At the end of the day we ended up with many many GB of videos, and a job not done yet. Before dinner, all nights, and most of the times waiting for our mom to get ready, we selected the best shots in order to create a video, cinematic music included, to show to mom as if we were two Directors showing the final cut of a Hollywood movie to a film criticism.

The other phone, while exactly the same, it was just used for some work stuff. It's a great device for reading emails, writing emails, and taking notes.

The difference lies in the emotions

While both are the same technical speaking, they are not the same emotionally speaking. If I still need to prove my point I'll will continue telling you fake stories including a beach, a mom and a sister until your eyes get wet and you rip this phone out of my hand while letting me keep the one used for work... because that's the whole point.

I know it's very obvious I'm appealing to your emotions in the last story, but the true is that we're all victims of this trick in a regular basis.

Think about it. Think about the last time you bough something on Amazon, eBay or Mercado Libre, when you searched for a product you already knew, ended up with three or four browser tabs with similar publications of the same product, different price within a short range, and then you made a decision from where to buy based on not much logical data but confidence on the seller, the aspect of the website, the fact that one had a better description with a video of real people using the product, the fact that one had reviews from previous buyers.

Think in Coke showing a couple jumping of a cliff into a lake, McDonald's showing a single mom with his kid laughing while eating fries, a perfume showing a good looking guy with three Victoria's Secret angels.

I remember a local ad I often see on TV showing a divided screen where on the left you can see a cute lady getting ready to go out on a sunny day, and on the other side a big man wearing a hood and preparing his tools to break into the house of this lady the moment she step out. There you have the victim, the villain, the conflict... and the hero? A trustworthy armored door at an accessible price.

And Apple?, oh, boy, those guys really know everything about selling feelings instead of products. I remember during an Apple's Keynote somebody, probably Tim Cook, introduced "Live Photos" (you know, that feature that records a few seconds before and after an static photo) and said something like "This feature allows you to see a photo, gently press on the screen, and get a sneak peak of what was going on during the shot of that static image".

A time machine that shows you 3 seconds of video and audio around the static shot. Right in the feels.

What you're selling is a hero

Your product, service, software... whatever is the thing you're selling, it can be the hero of a story. A story where there's a problem your potential customer has.

The problem is the villain in the story you need to start telling. It can be pretty obvious like in the ad for the armored door, or very subtle like in the McDonald's ad where they tell that they know how hard it is to being a single mom but still you can come upon great moments with your son in their stores.

Spot the villain, disclose the problematic, then introduce the hero to your customer so they lived happily ever after.

A blank Ghost blog theme for development

This blogs runs on the Ghost platform built with Node.js, with a homemade theme that uses Handlebars, HTML, CSS and JavaScript, and if you are reading this article chances are that you're already a Ghost blog owner and that you're looking to develop your own theme.

The problem with the Ghost default theme named Casper, while it's extremely helpful to learn how to develop a custom Ghost theme, is that it is too complex or "it has too many things" you probably don't want for your blog.

For example, when creating the theme for this blog, I had to "deconstruct" Casper to start building on top of the ashes because I wanted a more simple theme, that has my own code wrote the way I wanted it.

Introducing the Pale Ghost blank theme

The Pale Ghost theme is a blank theme, developer ready, focused on the markup without styles, that already includes all the Ghost features for you to customize or remove in order to create your own theme.

I already searched for Ghost blank themes, and truth be told there are many out there, but none suits my desires. All the blank themes I encounter has too much JavaScript, or they are too much complex to the point they looses they purpose of being a blank theme.

This blank theme in particular is very simple, so you might be spending time in the styling part with CSS/SASS/LESS rather than working on the markup. And if you want to move stuff around, you'll find it's easy with the Pale Ghost theme as it is well deconstructed into different .hbs files for an easy development.

It also includes everything a Ghost theme can deliver, just as Casper, but with a simple implementation. The goal with this theme is to avoid the part where we as developers smack things down before actually building up.

For a more technical description of what this blank theme includes you can check the Pale Ghost theme's GitHub page.

Downloading...

You can download this blank Ghost theme from the Pale Ghost theme's GitHub page, where you'll find the "Releases" section.

Fun facts about the page speed of a website

Everybody, everywhere, all the time, is saying that page speed matters. We get it, we heard it a trillion times, and I'm not sure why we keep writing about it or discussing it.

Page speed matters as much as the sun is hot, period. If you are still in doubt then you're having a serious problem. Make your website faster, and do not argue this fact, as it will cost you money.

That disclaimer being made, you probably also read that Amazon run some test and found out that if their site become 1 second slower it could cost them 1.6 billions dollars a year. And that's 1.600.000.000 dollars.

How much is 1.600.000.000 dollars?

  • That's more than 133 millions dollars per month. An amount of money I probably never going to see in real life, at least not all together, whether you divide per months or even days (more than 4 millions a day).
  • In Argentina, that's 48 billions pesos considering the currency value by the time I'm writing this post.
  • That's 96 millions (just millions) kilograms of premium ice cream. That amount of ice cream means that you and your future generations can enjoy more than a kilo of ice cream per day starting today and for the following 200 thousands years.
  • If you buy an iPhone X, and iPad Pro, an Apple Watch Series 3... And then a MacBook Pro, an iMac Pro, an Apple TV... and finally an iPod Touch just because, you'll be spending around 20 thousands dollars meaning that for 200 years you can get yourself a brand new model of all this products everyday.
  • 320 millions Caramel Macchiato Venti from Starbucks.
  • A Magento Commerce licence could rise up to 125 thousands dollars per year based on expected annual gross sales revenue, meaning you can build 12800 new eCommerce websites using this platform.
  • The Apple Inc. v. Samsung Electronics Co. legal battle you probably read on the Internet doesn't event get near this number. Wikipedia talks about 539 millions in favor of Apple for the first US trial, and then 120 millions for the second US trial. It was pointless to check the legal battles in the other countries.
  • And my home banking doesn't let me enter 1.600.000.000 in any form's input.

It was hard to find the real source of this 1.6 billions dollars proclamation, so I'm not sure about the veracity of such statement but for the end of this post it is not 100% relevant.

What I did find is that Greg Linder, best known as the inventor of Amazon's recommendations, made a presentation in 2006 saying the following:

Every 100ms delay costs 1% of sales.
Greg Linder

Probably somebody took that statement, and calculated it to be 1.6 billions dollars a year.

How a VTEX developer looks like from a technical point of view

If you happen to be on a similar position as I am where one of my task is to conduct interviews and vote on someone getting hire or not, you also have to be able to establish if that person can work with a specific platform.

It is not the same working on a VTEX store, an ORO implementation, or in a Magento project. For each platform you have to have a specific set of skills, and again, depending on the platform, more experience on some specific skills are necessary and the seniority on a specific ability vary when you change the CMS you are messing with.

VTEX requires a front end developer with a signed certification from his mother saying that he's great with those "Find the n differences" puzzles you get on the Sunday's newspaper, because the primary task he'll face is to transform a given design into "code", as pixel perfect as it can be.

So, how it looks like now?

Translated to actual skills, for a start it means we're looking for someone very good at xHTML, CSS (and/or any CSS preprocessor like SASS or LESS), that can also handle simple JavaScript logic or jQuery for basic UX interactions.

Bear with me if you not agree on that "simple JavaScript logic" statement, because there's a reason why I said "for a start". With this specific developer you are kicking off the team you need for a VTEX implementation but you are not finish yet.

Based on my experience, someone with the ability to handle the layout will cover a high percentage of what the project needs. Seriously, even on highly custom VTEX projects always the largest amount of workload falls on the person who handles the implementation of the designs and that's why is very important to have someone who nails this task.

The next step is to choose between two options: we either look harder for a person with the mentioned skills that can also handle the logical part of a development, or we get another team member for this job only.

If we go for the first option, now finding the developer became a little bit more complicating.

I think that considering a lot of front end developers, on one end we have the "developer who handles the layout and leaves the logic to back end" and in the other side the "kind of full stack developer hungry for programming but with no love for the look and feel".

Our first option requires us to find someone in between, and that's hard (talking, again, from my work experience). Personally I'll go for this option, because, personally, I feel more comfortable with those "in between" developers. But that's just me.

The second option is more suitable when looking at this from a company level where you have multiple VTEX implementations.

Imagine an scenario where you have three VTEX projects ongoing, each with a person assigned full time implementing the layout only, and a fourth developer jumping from VTEX 1, to VTEX 2 and VTEX 3 working on the customizations only, while leaving the "make this as the designs indicate" to the full time assigned coworker.

The person in this second option needs to know JavaScript for real, because all VTEX front end custom stuff always falls on the need of use of JavaScript.

The developer, sort of acting as a back end developer in this platform (in a manner of speaking) will be dealing with the logical part of the implementation like struggling with the APIs and integrating with VTEX's Master Data.

But how it will look like in the future?

The platform is evolving constantly and it is on its peak on what updating the technology stack refers. This means that what I just said above still applies, but we need to consider what is coming.

In the not so distant future the idea of VTEX IO as the VTEX's web application development platform is that custom (and useful) customization that takes places on a specific VTEX store become an App, in a sort of plug and play plugin for that specific store and others.

For example, let's say you have to development something to get the users' email using a form in order to subscribe them to the newsletter configured using MailChimp. Do it once, make it an App, and reuse it on the future or sell it to other existing stores seeking for the same functionality.

In this new world, besides the fact that you need a little bit of npm and the use of a Terminal to set up your workspace, you'll definitely need to know React and GraphQL in order to build the application.

So don't get sleepy.

Understanding the product's name front end logic in VTEX

Is VTEX showing the name from the Product in the Admin? Or is it showing the name we entered in the SKU? Or is it showing both?... or why sometimes it seems like VTEX is using the Product name and in other occasions it is using the SKU name?

In other words, what's the name I'm going to see in the front end of my VTEX store when creating a new product?

I'm writing this down because I found there's always a confusion about what is VTEX showing as a name for a product when looking at it in the front end (like in a category or product's page) considering there's a tricky logic there that involves the Product entity and the SKU.

Product entity name and SKU name?

To avoid any misunderstanding, let's discuss first what I mean by "Product entity name" and what I'm talking about when referring to the "SKU name".

When I say "product's name" we all think about a product as a whole, the item itself and the name that item has. But a product in VTEX is divided into two thing: The Product (or the Product entity) and the SKUs included on that Product.

I know I might sound philosophical and delusional but just take a look at this screenshot so I explain myself better.

understanding-the-products-name-front-end-logic-in-vtex-01-1

Is our site showing the name from the first column or from the second one?

Which one is going to appear on the front end of the VTEX store?

It just depends on this simple logic you need to consider.

If the Product entity name is exactly the same as the SKU name, then VTEX will show only one. Take a look at the screenshot above where the names in both columns are identical, meaning the front end will only show "iPhone X 64GB Silver".

On the other hand, if the name in the Product is different from the name in the SKU, then VTEX will show the two names separated by a dash (-).

For example, if for the Product we have "iPhone X 64GB" and for the SKU we have just "Silver", then the result on the front end it is going to be "iPhone X 64GB - Silver". That simple.

understanding-the-products-name-front-end-logic-in-vtex-02

Knowing that, if you're facing the "problem" in VTEX with the front end showing the names "duplicated" or if you didn't understand from where that final name is coming... now you know.

Keeping both the Product and SKU with the exacly same text (not even a difference in the capital letters) will show only one name, no dash.