Card-based design and eg.InfiniteGrid 3.0

Before the spread of mobile websites, most of the web content had been presented in the form of lists, where a list of titles was displayed and the content of a title appears on click or tap. However, as of now you are more likely see card-based content rather than list-based one.

In this article, we will briefly review the characteristics of the card-based design and introduce eg.InfiniteGrid 3.0, a new version of the eg.InfiniteGrid library that allows the implementation of card-based design.

This article does not explain how to use eg.InfiniteGrid. For information about eg.InfiniteGrid, visit the website of eg.InfiniteGrid or the repository on GitHub.
- eg.InfiniteGrid website: https://naver.github.io/egjs-infinitegrid
- Repository on GitHub: https://github.com/naver/egjs-infinitegrid
Issue management and tracking: https://github.com/naver/egjs-infinitegrid/issues

Characteristics

Card-based design is an arrangement of rectangular or square forms containing content. The content of cards can be composed of several different elements such as an image only, text only, or combination of text and image. Card-based design is one of the most widely used methods for presenting content on the mobile version of a website as it is the most suitable way to overview various content in one place.

In several paragraphs below, we will explain the characteristics of card-based design in terms of aspects of design and content consumption. In addition, we will also describe technical problems resulting from these characteristics.

Design Aspect

Card-based design is an effective way to deliver web content to users because this organizes scattered elements in a grid to present content.

Grid layout web pages (source: http://www.usefulparadigm.com/2017/03/31/a-few-ways-to-make-a-grid-layout/)

Card-based design is especially appropriate for responsive layout because it allows the card size and position to make changes based on the screen size.

Responsive layout that make changes based on the screen size (source: Why Responsive Design and How can it help your Business?)

Moreover, you can implement a carousel layout as well as a list layout using card-based design.

The following figure shows an example of a list layout that has been implemented using card-based design.

List layout implementation using card-based design

The following figure shows an example of a carousel layout that has been implemented using card-based design.

Carousel layout implementation using card-based design

Card-based design can be used in various ways as you see above, so cards are all over the web design trends these days.

In order to make it easy to implement card-based design, technologies like Flexbox and CSS Grid Layout are constantly adopted as a web standard, and the number of available libraries has continually grown.

Content Consumption Aspect

Placing content in cards makes users consume content quickly. Unlike the form of lists where it requires action to see the detailed content, card-based design allows users to easily access the key content by placing digestible content on the card itself. In addition, cards act like a list.

Thus, users who browse the website having a card-based layout tend to consume content in a different way as they used to do. Most users do not take direct like clicking if content does not satisfy their needs; instead, they just scroll through a page. In this way, users can consume huge amounts of content much faster than ever before.

Technical Problems

As we stated earlier, users tend to consume a lot of content with card-based design. This means a large amount of resources is required to maintain the interface, resulting in performance deterioration that can negatively impact the user experience. The worst case scenario is that an application terminates unexpectedly due to excessive consumption of resources.

The reason why NAVER Shopping changed the library for implementing card-based design from Masonry to eg.InfiniteGrid is that there was a technical problem in resource consumption.

For information about the NAVER Shopping library for implementing the card-based design, see “Introducing eg.InfiniteGrid, a new library for implementing a card layout"

eg.InfiniteGrid 3.0

eg.InfiniteGrid 3.0 is a new version of the eg.InfiniteGrid library for implementing card-based design.

The main purpose of the eg.InfiniteGrid library was to solve the technical problem with the existing library. Consequently, the most important factor is optimizing the speed of web elements while content continues to appear.

Meanwhile, you (as a service developer) may need a solution to present your content in which users are interested in a proper way as well as to solve the technical problem. In other words, you’d like to have a method to present multiple layouts in different ways for each content type in order to deliver your messages effectively.

Architecture

eg.InfiniteGrid 3.0 not only is an improved version of the existing eg.InfiniteGrid 1.x, but also has been developed in order to represent multiple layouts in different ways.

The following figure shows a basic architecture diagram of how eg.InfiniteGrid 3.0 works.

Figure 5 Architecture diagram of how eg.InfiniteGrid 3.0 works

eg.InfiniteGrid 3.0 mainly consists of three modules: Infinite, ItemManager, and Layouts.

The Infinite module makes the content infinitely appears while keeping the number of DOM elements constant; the ItemManager module manages the information that each card has; the Layouts plugin module controls the placement of cards in order to make layouts applied in various ways.

Multiple Layout Representations

eg.InfiniteGrid 3.0 supports classes that let you represent five different layouts using the Layouts module.

eg.InfiniteGrid 3.0 allows you to implement a grid view that presents content continuously without suffering the performance problem while implementing multiple layouts having both horizontal and vertical. In addition, it helps you add the new type of layout you want to, besides those described earlier, once the interface is implemented.

GridLayout

GridLayout that can be implemented by the eg.InfiniteGrid.GridLayout class allows you to create a Masonry layout.

The definition of masonry is the work of building with bricks. The Masonry layout refers to the arrangement of cards, all of which have the same width like a stack of bricks.

It has been default until the eg.InfiniteGrid 2.x version. This new version, eg.InfiniteGrid 3.0, becomes more powerful in terms of design capabilities, by supporting horizontal scrolling. The way to add rows and columns determines what your interface design looks like either grid or list.

The following figure shows an example of aligning multiple cards horizontally (in a row), all of which have the same height, using GridLayout.

Horizontal layout (GridLayout)

GridLayout helps you easily create list view by vertically aligning multiple cards (n x n matrix), all of which have the same height and width as shown in the figure below.

List view (GridLayout)

It also supports a parallax scrolling effect.

Parallax effect using GridLayout
To see a list of all GridLayout examples, click the link below.
- GridLayout demo page:
https://naver.github.io/egjs-infinitegrid/#GridLayout

SquareLayout

SquareLayout that can be implemented by the eg.InfiniteGrid.SquareLayout class allows you to put all cards in the square grid.

SquareLayout helps you emphasize a particular card to make it n times bigger than others.

The following figure shows an example of emphasizing specific content using SquareLayout.

SquareLayout
To see a list of all SquareLayout examples, click the link below.
- SquareLayout demo page:
https://naver.github.io/egjs-infinitegrid/#SquareLayout

FrameLayout

FrameLayout can be implemented by the eg.InfiniteGrid.FrameLayout class.

FrameLayout allows you to create a custom grid template for cards so that you can arrange them on the custom template.

While SquareLayout is designed to emphasize a particular card, FrameLayout is designed to define the repeated cards to make a pattern.

The following figure shows an example of presenting metro UI using FrameLayout.

Metro UI using FrameLayout

The figure above shows a repeating pattern horizontally for the figure below.

Metro UI design pattern
To see a list of all FrameLayout examples, click the link below.
- FrameLayout demo page:
https://naver.github.io/egjs-infinitegrid/#FrameLayout

JustifiedLayout

JustifiedLayout can be implemented by the eg.InfiniteGrid.JustifiedLayout class.

The printing term “justification” refers to the text alignment to fill a given width from end to end. As the word “JustifiedLayout” is derived from this printing term, this layout refers to the image alignment to fill in a given width from end to end.

The following figure shows an example of justifying multiple card images with various sizes and aspect ratio.

JustifiedLayout
To see a list of all JustifiedLayout examples, click the link below.
- JustifiedLayout demo page:
https://naver.github.io/egjs-infinitegrid/#JustifiedLayout

PackingLayout

PackingLayout can be implemented by the eg.InfiniteGrid.PackingLayout class.

The concept of PackingLayout owes to the packing algorithm. PackingLayout allows you to enlarge a particular image while keeping the original aspect ratio. Instead of making all columns and rows the same height and width, this layout dynamically arranges cards with different heights and widths in a given space. If you want to make your static website look stylish, this choice would be the best, despite less expandability and flexibility relative to other layouts.

The following figure shows an example of presenting multiple card images while keeping the aspect ratio.

PackingLayout
To see a list of all PackingLayout examples, click the link below.
- PackingLayout demo page:
https://naver.github.io/egjs-infinitegrid/#PackingLayout

Improved Performance

The performance of eg.InfiniteGrid 3.0 has somewhat slightly improved compared to eg.InfiniteGrid 1.x.

For eg.InfiniteGrid 1.x, it is designed to find the size and position of a DOM element in order to keep the number of DOM elements constant. For eg.InfiniteGrid 3.0, it is designed to use data, instead of DOM elements, in order to find the size and position of a DOM element, which does not require extra resources. You will notice performance improvement with eg.InfiniteGrid 3.0 when cards are added.

The following graph shows the performance test results of Masonry and eg.InfiniteGrid by version, which are commonly used libraries for layouts.

The procedure is as follows: First, 30 cards combining text and images were appended before the test started. Then, a bunch of 30 cards were appended 100 times every 50 milliseconds. To sum up, the performance was measured while additional 3,000 cards were being appended in a situation where 30 cards were given in the first place.

Performance comparison between Masonry and eg.InfiniteGrid

In the graph above, eg.InfiniteGrid shows about two or three better performance than Masonry. The performance gap is even bigger when the test runs on the Android device. eg.InfiniteGrid also shows deterioration with the Android environment, but this performance gap is much smaller in comparison to other environments.

The following graph shows the performance test results of eg.InfiniteGrid by version.

Performance comparison among eg.InfiniteGrid versions

With eg.InfiniteGrid 1.5.0, it takes 5,451 milliseconds to complete the execution on the Android environment whereas 5,302 milliseconds with eg.InfiniteGrid 3.0. You will notice that eg.InfiniteGrid 3.0 performs better than other versions, even allowing for a small error.

Test page

Test Notes

  • The array for desktop devices has 6 rows and 5 columns (6 x 5).
  • The array for mobile devices (Android, iOS) has 2 rows and 3 columns (2 x 3).
  • For desktop devices, the performance gap among different versions is small because more cards are displayed at a time.

Conclusion

Not only are there many open source libraries for implementing layouts including Masonry and Justified.js, but also a lot of components that help keep the number of DOM elements constant in order to maintain performance at approximately a constant value. However, there are only a few components that can support layouts and handle technical problems together.

The main purpose of eg.InfiniteGrid was to solve a technical problem of the existing library. However, it has evolved into a component, eg.InfiniteGrid 3.0, which deals with implementing various representations including a technical problem.

If using a card-based design for your website comes with several advantages, it would be a good choice to integrate eg.InfiniteGrid 3.0 into your website.

Series of “Layout Libraries for Images”