Responsive HTML generation using SuperSQL

Abstract

Purpose

With the rapid spread of smartphones and tablets, it is becoming necessary for web developers to create responsive web pages which are visually appealing on devices of various sizes. However, building responsive UIs is a very challenging task, requiring deep knowledge of HTML and CSS. This paper aims to propose an approach to generate responsive web pages using SuperSQL, which is an extension of SQL that can format data retrieved from a database into various kinds of structured documents.

Design/methodology/approach

By incorporating the methodology of bootstrap, a grid-based framework for front-end development, the authors have made it possible to create responsive web pages from simple SuperSQL queries. In addition, by utilizing SuperSQL’s unique feature that can describe the structure of the output web page, the authors have proposed and implemented a mechanism to automatically optimize the web content’s size and position.

Findings

In the evaluation, the authors created some actual web applications with and without the use of SuperSQL and compared the code amount (number of lines). As a result, when using the proposed system, the amount of code was reduced to about 1/5. The authors also compared the layout generated by the proposed automatic layout generation mechanism with the responsive layout that was generated manually. As a result, the automatic layout generation mechanism created the same layout as the manually created layout 74.8 per cent of the time, and the user satisfaction level turned out to be 85.8 per cent.

Originality/value

The way to generate a responsive HTML by using a single SuperSQL query, and the mechanism for automatic responsive layout generation.

1. Introduction

The current trend of the rapid spread of smartphones and tablet devices has made it necessary for web developers to create web pages with UIs viewable on multiple devices. The approach to solving this problem is to create responsive designs that adapt to various environments based on information such as screen size and window size. This method eliminates the need for developing different websites for every device on the market. However, creating responsive layouts that accommodate to different device size requires deep expertise in HTML and CSS.

Usual implementation techniques include using flexible grids and images, where the sizing of elements is done using relative units instead of absolute ones and CSS3 media queries where different styles can be applied for various device sizes. Numerous libraries and frameworks, such as Bootstrap[1] and Foundation[2], exist for supporting developers build responsive designs. The frameworks provide CSS rules for an initial set of standard and reusable layouts, typography, forms, buttons, navigation and other user interface components.

For many years, SuperSQL[3] (Toyama, 1998) has been developed as an extension of SQL. SuperSQL can be used to generate various kinds of structured documents such as HTML, XML, PDF, etc. based on the contents of a relational database. HTML generation using SuperSQL is designed so that it can reduce the workload and the amount of code needed to develop web pages that use data from databases. Especially, the mobile web application generation feature (Goto and Toyama, 2016) enables developers to easily create web applications fit for small-screen devices, while drastically reducing the code amount compared to using languages and methods such as PHP and Ruby on Rails. However, this feature is focused on creating web applications fit for devices with small screens and is not made for creating application fit for multiple device sizes.

This paper introduces a feature for generating responsive web pages that we added to the conventional SuperSQL system. In addition, we propose the mechanism for an automatic responsive layout generation by using the features of SuperSQL syntax rules, which can describe an intention of a layout structure directly. These features bring the methodology of the Bootstrap framework to the SuperSQL and enable the creation of responsive web pages with much less effort compared to the methods using existing popular technologies. Evaluation results show that the proposed feature was able to achieve about 80 per cent reduction of code amount (number of lines) compared to PHP and HTML/CSS. The automatic layout generation mechanism created the same layout as the manually created layout 74.8 per cent of the time, and the user satisfaction level turned out to be 85.8 per cent.

In this paper, Section 2 explains about related technologies and related works on the responsive web application development. Section 3 explains about SuperSQL. In Section 4, we explain about the responsive HTML generation features for SuperSQL that we propose in this paper. Section 5 focuses on the evaluation of the proposed system. The conclusions and the future work are shown in Section 6.

2. Related technologies and related works

2.1 Related technologies

2.1.1 Web application development.

A web application is mainly developed by script languages such as PHP[4], Ruby[5] and Perl[6] and are widely used to create websites such as blogs, social networking services and online shopping. Web application development requires the knowledge of programming language, front-end web development using HTML, CSS and JavaScript, and operation of a database. To support web development, web application frameworks have been provided.

2.1.2 Web application frameworks.

Web application frameworks are designed for development of web services, and web applications. The purpose of the framework is to make the development of websites faster and easier for developers. The functionality varies from framework to framework, but most frameworks adopt some kinds of templates or libraries.

Currently, there are many kinds of web application frameworks for various programming languages. For example, for PHP, CakePHP[7], Lavarel[8], Biscuit[9] and Symfony[10] are widely used. Play Framework[11], Tapestry[12], Velocity[13] are usable for Java, Ark[14] and Catalyst[15]; Mojolicious[16] is for Perl, and Django[17], TurboGears[18]; and Flask[19] is for Python. Almost all frameworks adopt object-relational mapping to access to a database. In object-relational mapping, the developer is required to code the procedural logic that outputs an HTML file with contents from the set of objects mapped to the underlying relational databases. However, in SuperSQL, HTML files are automatically generated in accordance with the layout structure that is expressed non-procedurally inside the TFE of the query.

2.1.3 Frameworks and technologies for frontend web development.

The functionality of the full-stack frameworks mentioned in the previous section is more or less focused on the backend functions. Frontend frameworks for simplifying the web design process have also been developed and are growing in popularity. Bootstrap[1] is the most popular of them and is almost turning into a web development standard. ZURB’s Foundation[2] is another framework with similar functionalities. Google’s Material Design Lite[20] is a framework by Google for building material design[21] web apps. All of the frameworks have some sort of support for building a responsive design.

Development in CSS preprocessors is also continuing. Less[22] and Sass[23] are the two most popular at the moment, with mostly comparable feature sets. Also, there is the newer approach, PostCSS[24], which introduces a new syntax to CSS and transforms CSS with JavaScript. It is gaining mind share, but not widely used as much as Less and Sass yet.

Other recent approaches include content management systems (CMS) that do not require the developer to write HTML and CSS files directly (Souer et al., 2007, 2008). WordPress[25], Joomla[26] and Drupal[27] are among the most widely used CMS. These software systems make the creation and the management of website content in a relatively user-friendly user interface (UI) and provide a wide variety of design templates for developers to start-off. However, tweaking specific details of the design template suddenly becomes a challenging task for novice developers, requiring the knowledge of HTML, CSS, PHP and often used CSS frameworks such as Bootstrap. SuperSQL’s modifier feature supports more detailed design specifications compared to the overall architecture of widely used CMS, making it possible for developers to tweak specific design details of specific elements easily.

2.2 Related works

Tools for assisting developers to create multi-platform websites have been proposed over the years. One approach is to adapt the page content of existing PC websites to mobile devices with small screens. The m.Site (Koehl and Wang, 2012) framework offers a visual tool to reshape the contents and a proxy server that dynamically generates the redesigned pages. m.Site reduces the cost of redesigning websites for mobile devices, but it is not aimed at creating a single responsive page that can adapt to multiple device sizes.

Another approach is to create a fluid and elastic design that can adapt to various display sizes. To support the labor-intensive and time-consuming process of creating responsive designs, Sinha and Karim (2013) devised a mockup-based design tool that creates fluid web layouts from a rough visual depiction of the desired design. In other words, this tool systematically encodes mockups drawn in a WYSIWYG editor into flexible layouts. This framework consists of an algorithm that derives the hierarchical layouts from mockup designs based on combinatorial search and puts it together with a systematic modular architecture for encoding the layouts into HTML and CSS. This tool may reduce the learning curve for novice developers, but the design generated by the tool is not fully responsive, and it does not make use of the CSS media queries to switch UI elements among various device sizes.

Sinha and Karim (2015) also proposes DECOR, which is a recommender tool for creating multi-device responsive UIs. Given an initial UI design, user-specified constraints on elements and a list of device form-factors (or device sizes), DECOR provides ranked, device-specific recommendations to the designer for approval. The tool requires user-specified constraints, based on a concept that a design that satisfies the constraints and requirements provided by the user is “well adapted” to various device form-factors. DECOR is implemented as a plugin to Maqetta[?], an open-source WYSIWYG editor, which allows creating designs by drag-and-drop. DECOR is aimed at supporting the workflow of web designers, while SuperSQL is aimed at supporting the workflow of web programmers. This is evident from the fact that DECOR does not have the functionalities and capabilities of connecting and interacting with the database, which is one of the vital factors for creating web applications.

3. SuperSQL

3.1 An overview of SuperSQL and TFE

SuperSQL extends SQL using the idea of the target form expression (TFE) (Seto et al., 1997) to generate various kinds of structured documents such as HTML, XML, PDF, etc. TFE is an extension of the target list of SQL. Unlike an ordinary target list, which is a comma-separated list of attributes, new operators such as connectors and repeaters are implemented to the TFE to specify the structure of the document inside the query. Each connector and repeater is associated with a dimension: the first two dimensions are associated with the columns and rows of the document structure, and the third dimension is associated with hyperlinks when generating a web document.

In addition to the TFE, we have also introduced the GENERATE <medium> <TFE> clause to the SQL syntax to make a distinction with the SELECT <targetlist> clause. The available target medium designations are not limited to the mediums mentioned above, but also include XML, PDF, X3D, etc.

3.2 Connectors and repeaters

3.2.1 Connectors.

SuperSQL uses binary operators represented by a comma (,), an exclamation point (!) and a per cent (%) to connect the attributes horizontally, vertically and in the depth direction, respectively. Generally, operations of these connectors are performed from left to right, but the order can be altered using curly braces ({}).

3.2.2 Repeaters.

A pair of square brackets ([ ]) followed by any of the connectors is a repeater for each dimension. Repeaters will connect multiple instances in their associated dimension repeatedly. For instance:

 GENERATE HTML [e.team, e.name]! FROM employee e

The query above will connect the team and the name of each employee horizontally and output the team-name pairs in the vertical direction repeatedly until no tuple remains in the query result. Table I shows the role of operators. Each x_i represents a TFE expressions whose simplest form is an attribute name or a string constant. Figure 1 shows simple examples of a table created from queries using connectors and repeaters.

Repeaters may also be nested to create a grouping of attributes based on their relationships. One or more attribute in a nested repeater groups the elements of the nested repeaters by the elements of the outer repeater. For instance:

 GENERATE HTML [e.team, [e.name]! ]! FROM employee e

This query will nest members’ name information for each team. Figure 2 shows examples of a table created from queries, including nested repeaters.

3.2.3 Multi-directional repeaters.

Repeaters can be combined to output and repeat elements into multiple directions. We call these multi-directional repeaters, and they are described as follow:

     [< TFE >] < connector >< number >< connector >

The < number > specifies the maximum number of times in which the elements are repeated in the direction denoted by the first < connector >. If the number of elements exceeds this upper limit of repetition, the following elements are connected in the direction specified by the second < connector >. For example, the following expression connects three elements horizontally and then connects the sets of elements vertically.

3.3 Modifiers

Users can change the look of the output result by using modifiers, represented by an at mark (@). Modifiers can be specified after one or more attributes to be decorated. Decorative specifications are specified inside a pair of braces ({}), separated by a comma and follow the semantic “attribute = value”:

   < TFE > ^@{attribute₁ = value₁, attribute₂ = value₂, […], attribute_n= value_n}

For instance, the following query specifies that the attribute e.name should be displayed with a 50 px width and a red font color:

   e.name@{width = “50”, font-color = “red”}

3.4 Functions

Functions in SuperSQL perform specific processes to character strings resulting from search results from the database. They are described as follows:

    func name([arg₁[,arg₂[ […] [,arg_n] […] ]]])

The available set of prepared functions depends on the media specified at the top of the query. Commonly used functions for web page generations are image function to include images and anchor function to create simple hyperlinks. For instance, the Image() function inserts images into the output HTML using <img> tags. It is described as follows:

 Image(< imagefile >,< directorypath >)

“image file” can be either a character string representing the path of the image to display or an attribute name in the database corresponding to a list of paths. In the second case, if a repeater is used, images are displayed repeatedly until no tuple remains in the list of paths. For instance, a sample query described as below generates a layout structure as shown in Figure 3:

 GENERATE HTML

 [image(d.pict, ″./image″)! d.name],3! FROM dog d

3.5 Features of SuperSQL

In this section, we explain about the features of SuperSQL to explain about our proposed system in Section 4. SuperSQL allows us to generate web contents by fewer lines of code. For instance, when a web developer creates a simple table like Figure 4, around 20 lines of code by using PHP, SQL, and HTML is needed generally. In this case, the web developer needs to know about the knowledge of PHP, SQL, HTML, and so on. The example PHP code for creating a simple table is shown in Source Code 1.

On the other hand, with SuperSQL, the table can be generated by the following four lines of code (Example Query 1).

In addition, if a web developer needs to change the layout from Figures 4 to 5, the code amounts will be about 35 lines (Source Code 2). In comparison with the previous code, code amounts become about 1.75 times. It is necessary to modify the entire code and describe a nested code using the for statement and so on. However, by using SuperSQL, the web developer can generate it by the following four lines of code (Example Query 2).

GENERATE HTML  [{image(image, ‘image’), {m.title! g.name! c.name}}! m.description],3!  FROM movie m, genre g, company c  WHERE m.genre = g.id AND m.company = c.id;

As you can see in the above query, the amounts of modified code and part of modified code are remarkably fewer.

In this way, the features of SuperSQL are not only generating web contents with few lines of code, but also modifying layouts with less changing code.

4. Responsive HTML generation using SuperSQL

In this paper, we propose a new approach to generating responsive HTMLs using SuperSQL.

4.1 Architecture

The compiler of the SuperSQL consists of three main parts: the parser, the data constructor and the code generator.

The queries are first parsed, and two parts are extracted, the schema (from the TFE clause), and components, i.e. the table names, predicates and so on. The components are sent to the SQL query maker that generates a SQL query aimed at retrieving the data. The extracted data from the database are then sent to the data constructor that organizes the data accordingly to the schema. After that, the code generator creates the resulting output, according to the target media specified in the GENERATE clause explained in Section 3.1. Figure 6 shows the architecture of SuperSQL compiler.

In the code generator, each output media format (HTML, XML, PDF, etc.) has its own mechanism for generating files. In our approach, we add the new “responsive web page” generation mechanism to the code generator.

4.2 Layout mechanism

To create responsive web pages from SuperSQL queries, we propose a new layout mechanism that incorporates the methodology of the Bootstrap framework. We chose Bootstrap because it is, by far, the most popular design framework used in the Web according to BuiltWith[28], and it is also widely used in many design themes for CMS such as Wordpress, Joomla, Drupal[29].

4.2.1 Bootstrap grid system.

Bootstrap layouts are based on a responsive, fluid grid system that scales up to 12 columns (by default) as the device or viewport size increases. This grid system is used for creating page layouts through a series of rows and columns to place the contents. Rows can be created by using the predefined grid class .row to a block-level element. There is no limit on the number of rows that can be created. Columns can be created using the appropriate predefined. col-<prefix>-<size> classes. <prefix> represents the four different class prefixes that correspond to different device sizes. The grid behavior for each size prefix is explained in Table II. The <size> is an integer number that represents the number of columns which the element takes up.

The following is a basic example of an HTML code that creates a Bootstrap grid as shown in Figure 7. Here, a row (<div class=″row″>) is created, and inside the row, two columns with widths spanning four columns and eight columns, respectively, are created. The columns both have a col-sm prefix to them, meaning that, if the width of the browser is greater than or equal to 768px, the columns will align horizontally, and if the width is smaller than 768px, the columns will collapse and align vertically.

Example: Simple bootstrap grid

The Bootstrap grid that we have discussed so far makes use of the predefined classes of the grid system which are available for quickly making grid layouts. However, there are many limitations to creating grids through predefined classes, such as the number of maximum columns, which is fixed to 12. Bootstrap is provided in a form of precompiled CSS and JavaScript files, but also in a form of source code that utilizes the two most popular CSS preprocessors, Less[22] and Sass[23]. Less and Sass are CSS preprocessors that extend the CSS language, adding features that allow variables, mixins and many other techniques that allow developers to make CSS more themeable and extendable. Especially, mixins let you make groups of CSS declarations reusable and easily accessible. The core functionalities of the grid system in Bootstrap are provided as mixins, allowing us to generate more flexible and semantic layouts as opposed to using predefined classes. Therefore, in our approach, we use Bootstrap written in Sass and generate CSS with customized semantic grids in accordance with the query content. This research could have been done using Less, but we prefer Sass because its abilities for nesting selectors and inheriting mixins make the codes more succinct and intelligible when compared to Less.

4.2.2 Adopting the Bootstrap grid system to the SuperSQL code generator.

To introduce the methodology of the Bootstrap grid System to SuperSQL, we reconstructed the layout mechanism of the SuperSQL code generator. We have associated the fluid grids and the concept of rows and columns to the SuperSQL layout expressions that use connectors and repeaters.

As mentioned in Section 3.2, connectors represented by a comma (,) and an exclamation point (!) connect the attributes in the horizontal and vertical direction, respectively. The repeaters will connect multiple instances in their associated dimension repeatedly. In the previous SuperSQL implementation, the layout structure was mainly built using an HTML <table> tag, and rows and columns were created using <tr> and <td> tags, respectively. To enable the creation of responsive web pages, we have substituted these elements with <div> elements to allow more flexibility in designs and output a Sass file that compiles into CSS to make the contents align to the responsive grid. Here is an example of a query that can create a responsive web page using the proposed system.

This query shows the image, name, breed and gender of each cat from a database table called cat. The page generated by this query is shown in Figure 8. A portion of the HTML output and Sass output of this query are shown below. In this query, an image of a cat is horizontally connected to the name, breed and gender of the cat which themselves are connected vertically. The whole TFE is inside a vertical repeater, which connects the instances repeatedly. The modifier @{sm} used here is part of the four modifiers introduced in this system, which are @{xs}, @{sm}, @{md}, @{lg}. They are basically modifiers for specifying size and grid behavior, and they follow the rules of predefined breakpoints for Bootstrap shown in Table II. The size can be specified using fractions (e.g. “2/5”) or percents (e.g. “40 per cent”). Thus, in this example, the image will take up two columns of the five column grid, and the information will take up three columns of the five column grid. The modifier used here is @{sm}, so the two elements become collapsed and align vertically when the window width of the browser becomes smaller than 768px.

Notice that, in the HTML output, each element and groups of elements are represented by a <div> element, with a sequentially numbered class name given to each of them. The CSS that is compiled from the Sass output is what makes the contents fluid and responsive. This system utilizes the Bootstrap Sass mixins to flexibly create responsive fluid grids that satisfy the specifications in the query. In this example, the two horizontally connected elements are given the modifiers @{sm=“2/5”} and @{sm=“3/5”}. The number of columns in the grid that is needed in this case is five. So, in the Sass output, a row is created using the mixin make-row and then, the total number of columns (grid-columns) is specified to five. Finally, inside the row, two sm columns with size 2 and 3 are created using the mixin make-sm-column.

4.3 UI components

The responsive web page generation system that we propose not only simplifies the development of responsive layouts, but also provide easily accessible design templates for commonly used UI components for web elements such as navigation and pagination.

4.3.1 Navigation.

Navigation headers can be created by using the navbar function. For instance, refer to the following query:

GENERATE ResponsiveHTML

  navbar(

   ″Cat Cafe: ′../home’″,

   ″News: ′../news’″,

   ″Menu: ′../menu’″,

   ″Recruit: ′../recruit’″, ″Access: ′../access’″,    ″dropdown(″About″,

    ″About Us: ′../aboutus’″,

    ″Contact: ′../contact’″

   )

  )

 FROM …

This query creates a navigation bar with menus that have links to Home, News, Menu, Recruit, Access, About Us and Contact pages. The resulting page for the query is shown in the top of Figure 9. The first argument in the navbar function creates a header menu for the page, linking to the Home page of the website. The arguments that follow are either a regular menu link, or a drop-down menu. Drop-down menus can be added using the dropdown function inside the navbar function. The first argument in the dropdown function is the text that will be shown on the toggle button of the drop-down menu. The arguments that follow are menu links inside the drop-down menu. The navigation bars are responsive-ready by default; so, when the window size of the browser gets smaller than the average tablet size (768 px), they are collapsed and become toggleable using the button on the top right (see the bottom of Figure 9).

4.3.2 Pagination.

In the proposed system, the developer can limit the number of contents that are shown in one page and split up a long content into shorter, easier-to-understand blocks:

 [< TFE >]! < number > per cent

By putting a number and a per cent (%) sign after a vertical repeater, the number of rows of data shown on one page is limited to the specified number. The data are split over multiple pages, and the pages can be switched using navigation buttons.

4.3.3 Modal window.

A modal window, which is a dialog box or a pop-up window that is displayed on top of the current page, can be created using the popup function defined as follows. The first argument defines a button or a clickable image, and the second argument defines the content inside the popup window: popup(“<text or image path>”, “<text or image path>”)

For example, the query shown below will create a button and a pop-up window as shown in Figure 10. If an image path is specified for the first argument of the function, a clickable image will be shown instead of a button:

GENERATE ResponsiveHTML popup(″Popup example″, ″This is a popup!″) FROM …

4.3.4 Togglable tabs.

Dynamic tab functionality can be added using the @{tab} modifier. It is defined as follows:

 {

   <TFE>@{tab=“<tab name>”}!

  <TFE>@{tab=“<tab name>”}!

  […]

 }@{tab-group}

If @{tab} modifier is specified to a TFE, the content of the TFE will be put inside a tab, which is labeled with the ¡tab name¿ . Transitions through panes can be done by clicking on an unfocused tab. An example of a simple tab structure is shown in Figure 11.

4.3.5 Image slider.

A slideshow UI component for cycling through images can be used using the @{slide} modifier. It is defined as follows:

 [ image(<image file>, <directory path>) ],@{slide}

  Or

 { image1(),image2() […] }@{slide}

Here, the image function is used in this feature. <image file> can be either a character string representing the path of the image or an attribute name in the database corresponding to a list of paths. If a @{slide} modifier is specified to a group of image functions, a slideshow that cycles through those images is generated. An example of an image slider is shown in Figure 12.

4.4 Mechanism for automatic responsive layout generation

In this chapter, we propose the mechanism for an automatic responsive layout generation by using the features of SuperSQL syntax rules, which can describe an intention of a layout structure directly. We show the layout optimization criteria assuming various viewing devices and the optimization methods in our system.

4.4.1 Layout optimization criteria.

Precedents to generate a responsive layout automatically are few. There are also no established methods. The points we should take into consideration when adapting web contents for various viewing devices are following. (These are parts of the whole and do not cover the whole).

• Invariant of appearance of each element.

  • size(width, height) setting;

  • order and arrangement setting; and

  • margin setting.

• menu configuration appropriate for screen size.

  • in smartphone size, collapse menu; and

  • in samrtphone size, simplify menu.

• Show/Hide elements.

  • Below a certain size, hide elements (sidebar etc.).

• Operate method integration.

  • Considering the impossible of mouse hover.

In this way, the contents layout criteria are various, and it is tough to evaluate appearance for people quantitatively. However, if we consider an optimization of content size and arrangement, we can broadly divide the principal method used on the Web as the way of optimization into the following two:

• rearrangement of horizontal contents (Figure 13); and

• rearrangement of repeated ordered contents (Figure 14).

There is a semantic difference between these two rearrangements. In the modern web development, HTML (structure) and CSS (design) are separated; therefore, it is hard to distinguish semantically, for instance, whether each element is lined up vertically or horizontally, and whether horizontal elements are same property. However, in SuperSQL, which can describe structure by using a repeater and connector, we can specify “rearrangement of horizontal contents” as the horizontal connect and “rearrangement of repeated ordered contents” as the horizontal repeat. Thus, we can easily distinguish them.

From the above, in various viewing devices, if we can automatically change the layout according to proportion and arrangement occupied by each element by using horizontal repeater and connector, not to change each element size in SuperSQL query, it can be said that it is a solution to the problem of optimizing and arrangement of contents in the challenge of content optimization to device size.

Then, in this system (GENERATE ResponsiveHTML), the layout with a width of 1,200 px (the maximum breakpoint in our system) is set as a standard layout. During decreasing a screen size of a device, the system optimizes the displaying layout to keep the state closest to the standard layout. Two break points (992 px, 768 px) lower than the 1,200 px as a separation of the optimization and one breakpoint (400 px) which is the number of pixels of the width of general smartphones or the minimum set width size of web browsers for PC are defined.

4.4.2 Optimization for horizontal connection.

In the optimization for a horizontal connection, when a web browser width decreases from 1,200 px to 992 px, 768 px, and 400 px step-by-step, our system decides the size and the arrangement of each element to keep the size of each horizontally connected element closest to the size of each element in the standard layout (screen width: 1,200 px). Concretely saying, when screen width decreases, the system compares the cases that “the horizontally connected elements are kept in as it is” and “some or all elements are aligned vertically”. And the system chooses the layout which the amount of difference in change in the width of each element is minimized.

From here, we explain with concrete examples. In the case of the upper part of Figure 15 that four elements(A, B, C, D) are horizontally aligned, there are eight arrangement patterns as candidate layouts (see the bottom of Figure 15). In this optimization, our system gets each element width when applying the candidate pattern. The system chooses the layout in which the difference between “the width of each element” and “the width of each element in the standard layout” is the smallest. In other words, in the case of Figure 15, the system calculates the following equation 1 in all candidate layouts at first. Then, it adopts the layout with the smallest value: $$(WidthA)-(WidthA\prime )|+|(WidthB)-(WidthB\prime )|+|(WidthC)-(widthC\prime )|+|\left(WidthD\right)-(WidthD\prime )|$$

Also, in our system, as a basic way of thinking, we aim to generate the layout which keeps arrangements of contents and size specifications specified by a web developer in creating the standard layout. Thus, in case that the order of horizontally connected elements is not changed and elements’ size has been specified, the candidate layouts are made with ratio maintained. We explain it with an example. If each size of four horizontally connected elements is specified in the order of 1/2, 1/6, 1/6, 1/6, our system generates the candidate layouts which align horizontally two-by-two, each of two elements’ ratio which aligns upper is 3/4 and 1/4 and lower is 1/2 and 1/2. The algorithm of the optimization for a horizontal connection is shown in Algorithm 1.

4.4.3 Optimization for horizontal repetition.

In the optimization for an horizontal repetition, similar to the case of horizontal connection, in each of three screen widths (992 px, 768 px, 400 px), our system decides the size and the arrangement of each element to keep the size of each horizontally repeated element closest to the size of each element in the standard layout (screen width: 1,200 px). In case that horizontal repetitions are used in GENERATE ResponsiveHTML, the sizes of repetitive contented contents are determined according to the specified size if there are size specifications or the number of output data. In either case, the same size elements are repeatedly displayed as an output result. Thus, in this optimization, the processing of the proposed system is not similar to the horizontal connection based on the arrangement pattern. The system creates the candidate layouts based on the sizes of each element (occupied ratio/proportion). Concretely saying, when screen width decreases, the system compares the cases that “the occupied proportion of each horizontally repeated element is kept in as it is” and “the proportion increased and the number of elements arranged in each column is decreased”:

Algorithm 1: Optimization for horizontal connection

 1: for all breakpoints do

 2:  for all candidate arrangement patterns do

 3:   for all each element of horizontal connections do

 4:    original_width ⇐ width of an element in the standard layout

 5:    candidate_width ⇐ width of an element in the candidate layout

 6:    width_difference ⇐ Difference between original width and

 7:   end for

 8:  end for

 9:  best_arrangement ⇐ Arrangement to be the smallest sum of

 10: Apply CSS (to change the width of each target element) to the browser using the value of best _arrangement

 11: end for

 12: return best _arrangement in each breakpoint

The system chooses the layout which the amount of difference in change in the width of each element is minimized.

From here, we explain with a concrete example. If there is a standard layout like the upper of Figure 16, you can create candidate patterns which are described in lower of Figure 16. In our system, the system obtains the width of each element when applying the arrangement like shown in the candidate layout group. The system chooses the layout which the difference between “the width of each element” and “the width of each element in the standard layout” is the smallest. The algorithm of the optimization for a horizontal repetition is shown in Algorithm 2.

4.4.4 Processing order of layout optimization.

In this system, the following two methods were implemented as a method for automatically generating responsive layouts. The system executes each processing for the layout optimization in the following order:

• Topdown: Method for optimizing each horizontal connection and horizontal repetition in order from the upper layer of the standard layout HTML.

• Bottomup: Method for optimizing each horizontal connection and horizontal repetition in order from the lower hierarchy of the standard layout HTML.

Algorithm 2: Optimization for horizontal repetition

 1: original_division ⇐ number of divisions of horizontal repetition in the standard layout

 2: original_width ⇐ width of each element in the standard layout

 3: for all breakpoints do

 4:  element_width ⇐ width of each element in a screen width of a breakpoint

 5: for i = 0 to original division do

 6:  candidate division original division i Number of divisions of horizontal repetition in the candidate layout}

 7:  candidate_width ⇐ (element_width * original_division)/(candidate_division){candidate width ⇐ Width of each element in the candidate layout}

 8:  width_difference ⇐ Difference between original_width and

candidate_width

 9:  end for

 10: best division ⇐ arrangement to be the smallest sum of width difference

 11: Apply CSS (to change the width of each target element) to the browser using the value of best division

 12: end for

 13: return best division in each breakpoint

4.4.5 Usage of feature for automatic responsive layout generation.

The feature for the automatic responsive layout generation was implemented as a part of GENERATE ResponsiveHTML. To use this feature, a web developer needs to write a SuperSQL query that generates a standard layout. On the specification of our system, the layout assuming desktop environment and the nonresponsive layout whise arrangement does not change depending on screen width are desirable as the standard layout. Thus, it is necessary for the developer to create the standard layout by only using the xs modifier. To generate a responsive layout based on the standard layout, the developer needs to enclose all <TFE> in braces and specify the responsive modifier like ’{ All <TFE> }@{responsive}’. By doing this, the system executes the feature for the automatic responsive layout generation, and the responsive HTML which is optimized for the screen size of each device is generated. From the above, the workflow for the developer is summarized as follows:

• Write a SuperSQL query that generates a standard layout assuming desktop PC environment (width: 1,200 px) by ONLY using the xs modifier.

• Specify the responsive modifier (@{responsive}) to all <TFE> of the query.

• Execute SuperSQL (the proposed system) and generate a responsive layout HTML.

In this way, by using our system, the web developers using SuperSQL can generate a responsive layout HTML by ONLY creating a layout for a desktop environment.

5. Evaluation

5.1 Evaluation items

To evaluate our approach, we conducted the following two evaluation experiments:

• Evaluation of the responsive layout generation features.

  • Comparison of coding costs.

• Evaluation of the mechanism for an automatic responsive layout generation.

  • Comparison with manual creation.

5.2 Evaluation environment

The evaluation environment of the proposed system is as follows:

• OS: Mac OS X El Capitan.

• CPU: 2.6 GHz Intel Core i5.

• RAM: 8 GB.

• Database: PostgreSQL 9.4.

• Web Browser: FireFox 50.1.0.

5.3 Evaluation of responsive layout generation features

In the evaluation of the responsive layout generation features, we evaluate the layout generation mechanism using the Bootstrap grid, which is newly implemented in the code generator. In this evaluation experiment, the automatic layout generation mechanism was not used. Participants manually generated a responsive layout HTML by the modifiers (xs, sm, md, lg modifiers).

5.3.1 Comparison of coding costs.

In the comparison of the coding costs, to show the usefulness of our system, we created multiple websites and compared the code amount with the conventional web application development method using HTML, CSS, JavaScript, PHP. The websites created in the evaluation are as follows. All these are “responsive” layouts that optimize a display according to the screen width of a viewing device or a browser.

Table III shows the list of functions implemented in each website. Site 1 and site 2 are web pages dedicated to browsing. Site 3 and Site 4 have various functions as web applications.

Table IV shows the comparison result of coding costs (line(s)). For every website, the amount of code can be drastically reduced when creating a website using SuperSQL. Specifically, the code amounts of web page generations at site 1 and site 2 is 21 to 27 per cent compared to PHP, and the code amounts of web page generations at site 3 and site 4 is 10 to 14 per cent compared to PHP. In this way, the more the structure of a website is complicated and the function as a web application increases, the more the difference of code amounts increases. In SuperSQL, it is possible to describe the functions such as page splitting of contents that needs to write dozens of code amounts using JavaScript, or the form creation and processing that need to write dozens of code amounts using PHP, etc. in several lines (approximately 1 to 10 lines). Because of this, the amount of code tends to differ more as the creation of web applications with many such functions.

5.4 Evaluation of mechanism for automatic responsive layout generation

To evaluate the automatic responsive layout generation mechanism, we conducted an experiment comparing two cases. In the first case, we asked participants to manually transform SuperSQL-generated layouts into responsive layouts, and in the second case, to generate a responsive layout automatically with our mechanism. We asked three participants to generate 38 layout patterns with SuperSQL and compared two layouts below.

• Responsive layouts automatically converted standard layouts generated by using only the xs modifier for layout decoration specification.

• Responsive layouts manually generated by participants by using all modifiers, which are xs, sm, md and lg.

We evaluated two points below about decoration specifications of each horizontal connection or horizontal repetition in queries:

• Coincidence: Percentage that decoration designation matches.

• Satisfaction: The degree of satisfaction of the participant for the behavior of the automatically generated layout.

  • Satisfied: Prefer layouts generated automatically.

  • Equal: Two layouts generated automatically and manually are equal or similar.

  • Dissatisfied: Prefer layouts generated manually.

Also, we compared two methods of the automatic responsive layout generation below:

• Topdown: Method for optimizing each horizontal connection and horizontal repetition in order from the upper layer of the standard layout HTML

• Bottomup: Method for optimizing each horizontal connection and horizontal repetition in order from the lower hierarchy of the standard layout HTML

The results are shown in Table V. As a whole, the average degree of coincidence is about 74.8 per cent, and the percentage of satisfaction with equal or higher is about 85.8 per cent. In many cases, participants were able to generate a satisfactory layout automatically.

Regarding the horizontal connection, the bottomup method is higher than the topdown method in both coincidence and satisfaction. This is because, in the topdown method, the changes added to the upper layer affect the lower layer, and layouts without waste are generated as a whole. On the other hand, layouts may be a cramped appearance like stuffing up the contents, which is considered to be a result of dissatisfaction.

Regarding the horizontal repetition, the average degree of coincidence is lower and the percentage of satisfaction is higher than that of horizontal connection. With large screen widths, changes in the size of each element that is horizontally repeated are often difficult to appear in appearance, and there are many cases that web developers do not specify fine size when creating a responsive layout manually. On the other hand, as the automatic layout generation mechanism is going through a detailed optimization that will be overlooked in the case of manual works, we got the result that the layouts of the automatic generation and the manual generation do not “match”, but rather, the automatically generated layout is preferred. Moreover, when comparing the topdown method and the bottomup method, in the bottomup method that does not consider the change in the upper layer, allocation of the element width when a screen width decreased may be too large, so both the degrees of coincidence and the percentage of satisfaction are lower.

6. Conclusions and future work

6.1 Conclusions

In this paper, we proposed a new approach to generating responsive HTMLs by using a single SuperSQL query and the automatic responsive layout generation mechanism. We proposed changes to the code generator of SuperSQL. Our approach aims to establish a simple method of developing responsive web pages that do not require expertise in frontend web development.

In the evaluation, we created four actual web applications with and without the use of SuperSQL and compared the coding costs (number of lines). As a result, when using the proposed system, the amount of code was reduced to about 1/5 compared to using HTML + JavaScript + PHP. We also compared the layout generated by the proposed automatic layout generation mechanism with the responsive layout that was generated manually. As a result, the automatic layout generation mechanism created the same layout as the manually created layout 74.8 per cent of the time, and the user satisfaction level turned out to be 85.8 per cent. We showed that it is a useful system that can reduce the burden on developers in creating responsive layouts.

6.2 Future work

In the proposed system, a hierarchical structure by braces in a SuperSQL query is significantly affected by rows and columns of the grid structure of the output web application. The use of braces is more complicated than the conventional system. For this reason, as a future task, we need to explore how to write a SuperSQL query that makes it easier to grasp the structure even if the code becomes long and to define indentation rules for writing a SuperSQL query.

Besides, in the automatic responsive layout generation mechanism, a responsive web page (HTML, CSS, PHP, JavaScript) is directly generated from a SuperSQL query for creating a standard layout. This design is not problematic if the automatically generated responsive layout satisfies a web developer’s requests. However, if the developer wants to change a part of the automatically generated responsive layout, the developer needs to modify the generated HTML or CSS, or rewrite the SuperSQL query manually to create a satisfied layout. Therefore, instead of directly outputting the web page by the proposed mechanism, to create a layout optimized by the system, it is necessary to create a proposal type system that shows to the developer which part of a query for the standard layout needs to be modified, and then the developer can sort it out.

This paper is an extension of work originally reported in Proceedings of the 18th Inter-national Conference on Information Integration and Web-based Applications and Services.

Notes

1.

“Bootstrap the world’s most popular mobile-first and responsive front-end framework”, available at: http://getbootstrap.com/

2.

“Foundation – The most advanced responsive front-end framework in the world”, http://foundation.zurb.com/

3.

“SuperSQL”, http://ssql.db.ics.keio.ac.jp

4.

“PHP.net”, http://php.net/

5.

“Ruby: a programmer’s best friend”, www.ruby-lang.org/

6.

“The Perl programming language”, www.perl.org/

7.

“CakePHP: The rapid development php framework”, http://cakephp. org/

8.

“Laravel – The PHP Framework For Web Artisans”, https://laravel. com/

9.

“rainner/biscuit-php”, https://packagist.org/packages/rainner/ biscuit-php

10.

“Symfony, High Performance PHP Framework for Web Development”, https://symfony.com/

11.

“Play Framework – Build Modern and Scalable Web Apps with Java and Scala”, www.playframework.com/

12.

“Apache Tapestry Home Page”, http://tapestry.apache.org/

13.

“The Apache Velocity Project”, http://velocity.apache.org/

14.

“Ark”, https://metacpan.org/release/Ark

15.

“Catalyst – Perl MVC web application framework”, www. catalystframework.org/

16.

“Mojolicious – perl real-time web framework”, http://mojolicious.org/

17.

“Django: the web framework for perfectionists with deadlines”, www.djangoproject.com/

18

“TurboGears”, http://turbogears.org/

19.

“Flask (A Python Microframework)”, http://flask.pocoo.org/

20.

“Material Design Lite”, https://getmdl.io/

21.

“Introduction – Material design – Google design guidelines”, https:// material.google.com

22.

“Getting started – Less.js”, http://lesscss.org/

23.

“Sass: Syntactically Awesome Style Sheets”, http://sass-lang.com/

24.

“PostCSS – a tool for transforming CSS with JavaScript”, http:// postcss.org/

25.

“Blog Tool, Publishing Platform, and CMS – WordPress”, https:// wordpress.org/

26.

“Joomla! The CMS Trusted By Millions for their Websites”, www.joomla.org/

27.

“Drupal – Open Source CMS – Drupal.org”, www.drupal.org/

28.

“Design Framework technologies Web Usage Statistics”, https://trends. builtwith.com/docinfo/design-framework

29.

“Love it or hate it, bootstrap is winning the Web”, www. ostraining.com/blog/coding/bootstrap-winning/

Figure 1.

Sample queries and output results in SuperSQL

[Figure omitted. See PDF]

Figure 2.

The created grouping table from the nested query

[Figure omitted. See PDF]

Figure 3.

The layout structure generated using the image function

[Figure omitted. See PDF]

Figure 4.

Generated table by Example Query 1

[Figure omitted. See PDF]

Figure 5.

Generated table by Example Query 2

[Figure omitted. See PDF]

Figure 6.

Architecture of SuperSQL compiler

[Figure omitted. See PDF]

Figure 7.

Bootstrap example

[Figure omitted. See PDF]

Figure 8.

Web page generated by cat.ssql instances repeatedly. The modifier @{sm} used here is part of the four modifiers introduced in this system, which are @{xs}, @{sm}, @{md}, @{lg}. They are basically modifiers for specifying size and grid behavior, and they follow the rules of predefined breakpoints for Bootstrap shown in Table II. The size can be specified using fractions (e.g. “2/5”) or percents (e.g. “40 per cent”). Thus, in this example, the image will take up two columns of the five-column grid, and the information will take up three columns of the five-column grid. The modifier used here is @{sm}, so the two elements become collapsed and align vertically when the window width of the browser becomes smaller than 768px

[Figure omitted. See PDF]

Figure 9.

Example of a navigation bar

[Figure omitted. See PDF]

Figure 10.

Example of a modal window

[Figure omitted. See PDF]

Figure 11.

Example of tabs

[Figure omitted. See PDF]

Figure 12.

Example of image slider

[Figure omitted. See PDF]

Figure 13.

Example rearrangement of horizontal contents

[Figure omitted. See PDF]

Figure 14.

Example rearrangement of repeated ordered contents the system compares the cases that “the horizontally connected elements are kept in as it is” and “some or all elements are aligned vertically”. And, the system chooses the layout in which the amount of difference in change in the width of each element is minimized

[Figure omitted. See PDF]

Figure 15.

Example candidate layouts on optimization for horizontal connection

[Figure omitted. See PDF]

Figure 16.

Example candidate layouts on optimization for horizontal repetition

[Figure omitted. See PDF]

Figure 17.

Website 1

[Figure omitted. See PDF]

Figure 18.

Website 2, Query 1 generates the Website 1 (the single-page website), and the Query 2-1 and 2-2 generate the Website 2 (the movie database website)

[Figure omitted. See PDF]

Table I.

Connector and repeater

Connector	Meaning of operator	Example
,	Connect horizontally	x1 , x2
!	Connect vertically	x1 ! x2
%	Connect with hyperlink	x1 per cent x2
Repeater	Meaning of operator	Example
[ ],	Repeat horizontally	[ x],
[ ]!	Repeat vertically	[ x ]!
[ ]%	Repeat with hyperlinks	[ x]%

Table II.

Bootstrap grid behavior over multiple devices

	Extra small devices	Small devices	Medium devices	Large devices
Breakpoints	<768 px	≥768 px	≥992 px	≥1,200 px
Assumed device	Phones	Tablets	Small PCs (laptops)	Large PCs (desktops)
Grid behavior	Horizontal at all times	Collapsed to start, horizontal above breakpoints
Class prefix	.col-xs-	.col-sm-	.col-md-	.col-lg-

Table III.

Function list of website for evaluation

	1	2	3	4
Display data	✓	✓	✓	✓
Response design	✓	✓	✓	✓
Plural pages structure		✓	✓	✓
Content page splitting			✓	✓
Entering data using a form			✓	✓
Dynamic data display			✓	✓
Login function				✓

Notes: Website 1: Single-page website imitating a company’s website (Figure 17); Website 2: Multiple-page website that you can view movie information (Figure 18); Website 3: Web application reproducing the movie DB (www.themoviedb.org/); Website 4: Web application reproducing Newsweek (http://europe.newsweek.com/)

Table IV.

Comparison result of coding costs (line(s))

	Website 1	Website 2	Website 3	Website 4
HTML, CSS, JavaScript, PHP	137	139	955	930
SuperSQL	30	37	136	85

Table V.

Evaluation results of mechanism for automatic responsive layout generation

		Coincidence	Satisfaction (%)
			Dissatisfied	Equal	Satisfied
Horizontal connection	Topdown	72.0	25.4	74.5	0.0
	Bottomup	85.2	9.1	90.9	0.0
Horizontal repetition	Topdown	73.6	0	77.9	21.0
	Bottomup	68.4	21.0	68.4	10.5