I’m a college student graduating in IT at Faculdade De Pará de Minas. Every semester, we make a final project to apply all the knowledge taught to us during the few past months. This time, my team choose to create a page for an event who happens annually at the college: the Encontro Gamer de Pará de Minas (Pará De Minas’ Gamer Meeting , in a rough translation).
What started with a static page, turns out to be a Vue application who consumes data from an API, with data inserted from a custom CMS. In this post, I’ll tell you about our experience and what we learn in the meantime.
A live demo is available here: http://egpm.netlify.app/
Starting the project
We’re three in my team: me, Lucas and Eduardo. We’re all developers. Lucas and I work together, developing web applications. Eduardo works creating Delphi systems (and has a lot of experience with network, hosting and infrastructure in general).
Our main goal was to develop a static landing page, showing the main details for the event. We had little time to do the project and the idea was to keep the scope small as possible.
Before start with the coding, we decided to remake the event’s visual identity. We created a concept based on the colors of the european Super Nintendo controller. With the new logo and the colors defined, it was the time to find inspirations.
Getting inspired and Prototyping
As a starting point, we analyzed a lot of landing pages for similar events, keeping notes of what we thought that works and what won’t. The focus what to get inspiration for the items and information disposition on the page.
Based on that, we created small prototypes (think about functional wireframes) to test the viability of every layout without effectively choose the technologies and started the development.
Choosing the technologies
Other than create a page with a great user experience, the priority was to use the project as a playground for experimentation and learning. And picking different libs and frameworks was one of the best ways to achieve this.
We chose...
Vue.JS as a JS framework + Webpack as a module bundler
I really like how Vue’s syntax is user friendly. All the docs are pretty well written, and the community is getting bigger and bigger. We used a pre-configured template, enabling the creating of single file components (.vue). This template came with lots of conveniences: commands to generate the dist folder with all the files ready to production, CSS pre-processors support, modern JS transpiller, local server with hot-reload and a lot more.
Bootstrap 4
Easy pick. We choose Bootstrap 4 for the great grid system and components.
SASS (SCSS)
CSS pre-processor. SASS enable us to write CSS in a more intelligent and legible way. Also, it’s great to automate repetitive CSS tasks. We choose the SCSS syntax for all the similarities with the classic CSS syntax.
Git + Github
Version control systems are a requirement to develop in a collaborative way. Using git as a VCS, we choose Github as the host for our source code repository. We use Bitbucket in our daily job, and using Github was a great way to learn the differences and equivalences between the services.
Doing it
Working asynchronously and in a collaborative way
We created a Github repository and used issues and pull requests to manage the project. We are used to Bitbucket, and the learning curve was easy. As I write this post, our repository has 491 commits and 24 closed issues.
A lot of commits!
Our workflow is basically:
- Defining a new feature / hotfix;
- Open an issue for the subject and assign to one of us;
- Create a new branch based on master;
- Develop the feature / hotfix;
- Create a pull request pointing to master, assign the other as the reviewer;
- Wait for the review;
- After the approval, merge the PR and delete the old branch.
It worked very well, and we had almost no problems or code conflicts. We organized ourselves very well, even coding in completely different hours on the weekends.
Vue, vue, vue
With the webpack template configured and the repository online, we started the development. We learn the basics of the framework and in more than a week we had the basic structure for the application.
One of our first challenges was to learn the basics of modern Javascript, since all the imports and exports was based on the modularity concepts of the more recent versions of ECMAScript (6+).
The Vue syntax is pretty easy to learn, specially If you already worked with a framework like Angular before. The docs are excellent and very detailed. And if English is not your first language, maybe it has a translation. I’m Brazilian, my native language is Portuguese, and we have a great translation for the docs.
One of my favorite Vue features are the single-component-files (.vue). They contains all the HTML, CSS and JS for the component. To use a component named Banner, for example, you just need to use <Banner></Banner>. This makes the code way simpler and more legible for the developers.
The CMS
With the site taking form, it was clear to us that we need to create a CMS for content creation. We need one who allows us to register all the games that was going to be present at the event, tournament details, localization, a shortcut to buy tickets, FAQ and testimonials.
Lucas created all the CMS, using a custom PHP framework that he uses in personal projects. The CMS’ front end has the same basic structure as the website, using all the componentization concepts. The CMS consists in a panel with distinct sections to addition, removal or edition of all the various contents. All the data are returned in JSON via and API that the website consumes.
Today, all the CMS code are contained in two different repositories: one for the front-end, one for the back-end.
Components, SASS and how easy it was to experiment with the layout
The usage of Vue single file components allowed us to do a series of experiments with no sweat. To experiment with an item disposition, color or font, we just needed to change the component file. All the component’s instances updates automatically.
Using SASS was another great decision. As I said in another topic, it allowed us to create variables and code snippets to automate processes that uses CSS and enables a syntax that I found particularly more legible than the vanilla CSS one.
Keep in mind that after all, SASS converts everything in CSS. I choose the SCSS syntax, who keeps the semicolons and braces to delimit the end of lines and selectors.
Responsiveness and images
Even if you’re a beginner, you probably heard that it’s primordial that your site or system needs to be responsive. In a world that most of the web traffic are made with mobile devices, it’s important that your site feels great in any screen – from smartphones to desktops and everything in between.
Offering a great experience for our users, especially for the ones who’s going to access it from the smartphone was one of our main goals. And that’s not only about legible and well positioned items. The data consumption also needs to be small as possible – keep in mind that most of the smartphone users uses slow networks with data caps. In brazil, this is a reality.
Our site is extremely dependent on images, who are the responsible for most of the data consumption. With this in mind, we implemented a solution on the CMS to resize and compress images on image upload. We generate a series of variants with different resolutions and sizes. The average size for the smallest version of an image is close to 25kb ~ 30kb.
Using the <picture> and <options> tags, we verify the display size to fetch the most adequate image. On smartphones, you’ll always almost get the smallest version of the image, for example. This reduces considerably the data consumption and reflects in speed.
Iterating, testing and polishing
We iterate many times until we get to the final layout. Since none of our teachers imposed any kind of restrictions, we had the liberty to experiment. All the default fonts, font sizes and spacing between items, for example, was chosen close to the project’s deadline.
During the iterations, we choose a “less is more” approach. In the first ones, we had a lot of CSS animations. We choose to reduce them to a minimal level, since keeping them used to make the user lost focus.
Other than our internal tests, we created a pre-release environment and shared with our closest friends and classmates. We got a lot of valuable feedback in this phase, and we could make lots of improvements based on them.
The reception
We made our first release on the projects fair last month. The reception was overwhelmingly positive. Besides the small amount of content on the page, who went to our stand liked what they saw on both the laptop that we bring to show the CMS and the page on desktop, and on their own smartphones.
The greatest part was our colleagues super interested on the technologies and the processes behind the scenes. I believe that we encouraged a lot of people to play with projects like these (and we’re supper happy about it).
What can we improve?
Even after we made the project into production, we continue to iterate over it. We already made a lot of changes and improvements, fixing bugs and adding new features on the CMS. Lots of these features are going to be used on the next semester for our teachers and the people who make the event happen.
We know that there’s a lot to improve. Some of our next updates includes:
- Better implementation of accessibility standards;
- Implement a animated skeleton page (just like Facebook’s), keeping the page to “jump” after some of the content is loaded.
- Improve the overall infrastructure: cache, https, etc;
- Improve the initial non-cached load of the page;
- Implement lazy loading on the images that are not visible on the screen;
- Implement tools for automated tests.
Concluding…
We learned a lot developing this project. Changing a little our daily job workflow and play with different tools it’s a great way to learn new concepts and ways to build systems and pages. I already applied some of my new skills at my daily job and it felt so good!
