HOW WE BUILT IT
Unlike most development companies, we love to share how we’ve built applications and fancy features, so we’ve decided to write a post about how our home page banner came to be. It was a quick and fun project that involved a similar process (on a much smaller scale) than the applications we build. We follow the same process for many of the things that we do here at Brand Enamel.
The goal of the web banner was to stand out, offer some interactivity, show some behind the scenes capabilities, and be quick to load. While these are all very important, the most important part is standing out. We know we only have a few seconds to leave an impression on the visitors on brandenamel.com. So, we’re appreciative that you stuck around to learn more about us and our coding practices.
We used a combination of HTML, CSS, and JavaScript.
The components:
HTML 27kb
The HTML is inherently very small in size. After all, HTML is nothing more than a text file that brings everything together. Our website is built in PHP, but HTML is inserted into the page using PHP. To start developing the HTML file, we created a file called index.html, which when clicked, will open a browser on any computer (regardless of whether the computer is online. At just 27kb, this HTML file is ready to display whatever JavaScript and CSS we tell it to display.
CSS 84kb
CSS is a stylesheet used to help style the text and elements with colors, pictures, and some flashy functionality. Think of a CSS file as the flavoring of a soup. Sometimes the soup base (in this case the HTML) has flavoring, coloring, and maybe some veggies or meat. With just one CSS file (or many if desired), we can change the color of the soup from red to yellow. If there are carrots in the soup then one line of code can change all carrots from yellow to orange. Using stylesheets is much better than putting the CSS code into the HTML file for a few reasons, which we’ll get into in another post soon.
JavaScript or JS 68kb
Now comes the fun part. Javascript’s role in all of this is to work with HTML and CSS. Think of JavaScript as the spoon in the soup. We can scoop the contents out of the soup bowl, pour it back in, stir the soup, and manipulate the soup in just about any way. JavaScript is a widely used scripting language that allows developers to make the page come alive. In the most basic example, a button on a website could have some JavaScript added to it. The button may change colors when hovered, which could be executed through either CSS OR JavaScript, but a hover box above the button would be primarily done through JavaScript. We can tell the hover box to wait a few seconds before showing, fade in or out when hovered, or show a modal when the button is clicked. There is an unlimited possibility of what JavaScript can do.
When we add all of these components together, we get a combined file size of 179kb - not bad considering that’s the size of a medium-sized image. We can’t forget that the red image also needs to be displayed, which is done by calling sliderimage.jpg through the HTML file. The image itself is optimized to show clearly but also compressed enough so it doesn’t take too much time to load on the page. It is 126kb in size.
In the “old days” (the mid-2000s) we used to use Flash, which is a product by Adobe. Flash was a brief love affair that has been fizzling since the late 2000s, and will likely abruptly end in the next couple of years. Apple and Google have both declared that they will be dropping support for Flash in the next year or so. The reason we mention Flash is that Flash is very good at combining HTML-, CSS-, and JavaScript-like features into one package. Coding in “ActionScript” (Flash’s native language) was relatively easy and straightforward, and probably helped boost its popularity in the last couple of decades. The main complaints about Flash were its ability to load scripts and actions without complete transparency. Once the ActionScript was coded it is very difficult to see what the code looks like as well as what possible scripts the Flash file could load. This combined with its almost nonexistent SEO capabilities made its popularity quite short. We still see some Flash banners on sites here and there, but for the most part, they are being built now using programs like Photoshop and other advanced editors.
Anyway, back to the banner. I had mentioned that our process for building banners was similar to building an enterprise application but on a much smaller scale. We start with a concept and set intentions for the work we’ll do.
Intentions
We ask ourselves questions such as, what is the purpose of the banner, besides taking up room at the top of the page? And why is the banner at the top of the page. They are basic questions that lead to thought provoking answers. A list of intentions helps guide the build from beginning to end. If we ever get off track, say for example by convincing ourselves that the banner should be on the side of the page, then we can see the reasons behind why we’re doing what we’re doing. This must come before the design phase, which is an extremely enticing step. My mind always tries to trick me into skipping right to the design phase.
Message
We asked ourselves what message we wanted to send to our customers. What came to mind is that we can build ideas for our clients, and show them how things are built, as well as the advantages. We also wanted a clear message without too much clutter. That’s why we decided to go with bullet points with hidden messages behind each bullet point.
Design
Finally, the fun part. What is the functional design of this banner and how do we put our intentions and Message into a digestible banner? We can utilize images taken by other people (which we did, thanks to Adobe Stock Images), some JavaScript libraries which are open source (Check out these open source applications!), and modify all of the above to fit our exact needs. Once the design was finalized the rest fell into place very quickly.
Spec
Next up is explaining every piece of the banner, such as fonts, font size, animations, and functionality. This is important whether I am coding this banner or if one of our other developers is taking on the work. Many times I’ll catch myself straying from the spec if I don’t write it down. We should go back to the Design phase at this stage unless there are functional issues that need to be considered, and we missed in the first phases of the project. Writing out every detail very clearly, such as assigning color values (like HEX numbers such as #FFFFFF (white)), font sizes, line-spacing (very important; I will cover this topic in another post), and how the user interacts with the banner are all detailed as thoroughly as possible as if someone else is going to code the banner.
Code
Again, a fun part (for some). With the Spec laid out and the resources such as images, open-source code, and supplemental files available, we can begin coding. This is where it all comes to life. In this example, we used 3 open-source JS files and modified them to our needs. Check out Twenty Twenty comparison slider, Typewriter-bundle.js, and Event.move.js. All free to use and we can combine and modify as needed.
Test & Revise
This is an iterative step that needs to be repeated until there are no errors or mistakes. We take a look at the Specs and very carefully test each part of the banner. Do the JavaScript circles blink in the timing and order we want? What happens when the circles are hovered? We usually find 2 or 3 things that need to be revised, but they are usually small modifications and take very little time. Quite often is the responsiveness, which means that the desktop layout is as functional as the mobile layout. Bootstrap is a huge help with this and we use it in quite a few projects.
Final Delivery
Now that the banner is ready we can install it on the site. There is some final testing once deployed to the production site, but in most cases, we are good to go.
To many people this process may seem long and unnecessary, however, to us it is critical to follow the correct steps. We usually discuss these steps with a client and keep them posted throughout the process unless the client only wants to see the finished product (which is perfectly fine). In the end, we can only be happy if the client is satisfied with the work.
If you’re considering building an application of any kind we’d love to talk to you. We don’t require any commitment to discuss ideas, and we’re happy signing NDAs if you or your investors require one. Please contact us here so we may start the journey to figuring out your new product or service. We look forward to hearing from you!
