Define responsive design for
web-forms using layout editor
JIMMY HYTÖNEN & ROBIN ANDERSSON
web-forms using layout
editor
Jimmy Hytönen & Robin Andersson
June 23, 2015
Bachelor’s thesis
Supervisor: Fadil Galjic
Examiner: Anders Sjögren
access the web. These devices have significantly smaller screen sizes than the more common desktop. This results in that the approach to designing web content has to be changed. The approach to design web content that adapts its visual layout to different screen sizes, is referred to as Responsive Web Design.
Ida Infront is a company that develops systems and solutions for information-intensive businesses. They are currently examining how to design a layout editor that can be used to define responsive design for web-forms. The pur-pose of this project is to design and implement a prototype of such a layout editor, which will then be evaluated by Ida Infront.
The project is divided into two phases, starting out with the research pro-cess, followed by the prototype design process. In the research propro-cess, the following is examined: structure of the XML file describing web-forms, Re-sponsive Web Design techniques and technologies appropriate for the layout editor. In the prototype design process, a layout editor prototype allowing responsive design for web-form components, is designed and implemented. The responsive design configuration is added to the web-form XML file.
We found that Bootstrap is a suitable technology to define responsive design of web-forms, since placement of web-form components can be trans-lated into a Bootstrap grid system. The resulting layout editor prototype allows responsive configuration in Bootstrap. This is done by utilising the grid system as the underlying structure for placement of web-form compo-nents. The prototype also allows configuration for each of the four Bootstrap device classifications, named xs, sm, md and lg. Position and size of web-form components are stored for each Bootstrap device classification. The resulting responsive configuration is added into the existing XML file for the web-form.
åt webben med. Dessa enheter har betydligt mindre skärmar än de mer vanliga stationära enheterna. Det har resulterat i att sättet man designar webbinnehåll måste ändras. Metoden att designa webbinnehåll så det an-passar sin grafiska utformning efter olika skärmstorlekar kallas för responsiv webb design.
Ida Infront är ett företag som utvecklar system och lösningar för infor-mationsintensiva verksamheter. De undersöker just nu hur man designar en layout editor som kan användas för att definiera responsiv design för webb-formulär. Syftet med detta projekt är att designa och implementera en prototyp av en sådan layout editor, som sedan kommer utvärderas av Ida Infront.
Examensarbetet är uppdelat i två faser, det inleds med forskningsfasen och efterföljs av prototypfasen. I forskningsfasen undersöks följande: struk-turen i XML filen som beskriver webb-formulär, olika tekniker för responsiv webb design och lämpliga teknologier att använda i en layout editor. I pro-totypfasen, designas och implementeras en prototyp som gör det möjligt att definera responsiv konfiguration för webb-formulär. Konfiguration för re-sponsiv design läggs till i den befintliga XML filen.
Vi kom fram till att Bootstrap är en lämplig teknologi för att definera responsiv design för webb-formulär. Eftersom placeringen av komponenter i webb-formulär kan översättas till Bootstraps rutnät. Den resulterande lay-out editorn gör det möjligt att definera responsiv design i Bootstrap. Detta genom att använda Bootstraps rutnät som underliggande struktur för placer-ing av webb-formulärets komponenter. Prototypen gör det också möjligt att konfiguera för var och en av de fyra Bootstrap enhets klasserna, namngivna som xs, sm, md och lg. Position och storlek för webb-formulärets kompo-nenter lagras för varje Bootstrap enhets klass. Den resulterande responsiva konfigurationen läggs till i den befintliga XML filen för webb-formuläret.
Nyckelord: Formulär, Responsiv Webb Design, XML, Javascript,
First we would like to give our sincerest thanks to our supervisors from the ICT-school at KTH for being supportive and helpful during the process of working on this thesis.
Additionally, we would like to express our gratitude towards Ida Infront for making this thesis possible. Specifically, Magnus Grimsell for coming up with the idea for this thesis and entrusting us to carry out the investigation. Frida Vestman for giving us continuous feedback on the product. Johnny Hensegård for his technical expertise in the development environment at Ida Infront.
abbreviations
Abbreviation Description
HTML HyperText Markup Language W3C World Wide Web Consortium CSS Cascading Style Sheets RWD Responsive Web Design XML Extensible Markup Language MVC Model View Controller MVVM Model View ViewModel
CRUD Create, Read, Update and Delete GUI Graphical User Interface
WYSIWYG What You See Is What You Get SAD Software Architecture Document
Acknowledgements i List of acronyms and abbreviations ii
1 Introduction 1
1.1 General introduction to responsive design . . . 2
1.2 Introduction to Ida Infront . . . 2
1.3 Problem definition . . . 3 1.4 Research questions . . . 3 1.5 Purpose . . . 4 1.6 Delimitations . . . 4 2 Theoretical Background 6 2.1 Web-form . . . 6
2.1.1 What are web-forms? . . . 6
2.1.2 Designing a web-form . . . 7
2.1.3 Web-form grid structure . . . 8
2.2 Static Web Design . . . 8
2.2.1 What is Static Web Design? . . . 8
2.2.2 Supporting multiple devices in Static Web Design . . 9
2.3 Responsive Web Design . . . 9
2.3.1 Media Queries . . . 10
2.3.2 Fluid Grid Design . . . 12
2.3.3 Flexible Grid Design . . . 14
2.3.4 Mobile First Approach . . . 15
2.4 Design with Bootstrap . . . 15
2.4.1 What is Bootstrap? . . . 15
2.4.2 Grid system for different devices . . . 16
2.4.3 Mobile First . . . 18
3 Methodology 19 3.1 Research process . . . 19
3.2 Identifying problem areas . . . 21
4 Empirical basis 25
4.1 XML structure of forms . . . 25
4.2 HTML components in web prototype . . . 29
5 Analysis 33 5.1 Specialised research questions and answers . . . 33
5.1.1 Responsive behaviour of web-form component . . . 33
5.1.2 Components in XML file . . . 36
5.1.3 Technologies . . . 37
5.2 Main research questions and answers . . . 38
5.2.1 Dynamic layout editing . . . 39
5.2.2 Layout editor and Bootstrap . . . 41
5.2.3 Persist configuration into XML . . . 44
6 Discussion 48 6.1 Limitations . . . 48
6.2 Conclusion . . . 48
6.3 Sustainability & ethics . . . 50
6.4 Future work . . . 51
6.4.1 Generate web-form with responsive configuration . . . 51
6.4.2 XML configuration file . . . 51
6.4.3 Configuration for 1 view instead of 4 . . . 52
6.4.4 Alternatives to Angular Gridster . . . 53
Introduction
Responsive Web Design (RWD) or Responsive Design is an approach to define layout configuration for web pages.[1] RWD makes use of different techniques, such as fluid grids, flexible grids and media queries, to adapt web content to different screen sizes.[2][3] The need to design web applica-tions to be responsive is important to provide optimal user experience.[4]
The conventional way is to let developers configure the responsive de-sign. This means that if a user wants to configure RWD behaviour, they need to communicate their configuration to a developer. This in turn can lead to problems like misunderstandings about the design and additional costs. What if users could configure responsive behaviour without going through developers, but instead use a GUI (Graphical User Interface)?
Our task is to implement a prototype, which can be used to configure the graphical layout of a web-form using responsive design in a drag-and-drop client. The prototype should allow users to configure the responsive design without doing any programming, but rather using the prototype interface.
The company Ida Infront, which initially gave us the task to develop the prototype, will then see how the prototype can help their clients to define the responsive design of their web-forms.
1.1
General introduction to responsive design
Responsive Web Design consists of several techniques which attempts to adapt web content so that it is displayed correctly on different screen sizes. The common denominator is that they need to rely on CSS to change the layout.[5]
The need for Responsive Web Design emerged as soon as the first mobile device with browsing capabilities hit the market.[1] This is due to the reason that websites were adapted to desktop devices that use screens many times larger than mobile devices. This meant that the old static design which had been in use needed to be extended in order to support these new devices.
In the field of web design and development, we are quickly getting to the point of being unable to keep up with the endless new resolutions and devices.[6] For many websites, creating a different version for each resolution and new device would be impossible, or at least impractical. Should we just suffer the consequences of losing visitors from one device, for the benefit of gaining visitors from another? Or is there another option? Responsive Web Design is the approach that suggests that design and development should respond to the users behaviour and environment based on screen size, plat-form and orientation. The practice consists of a mix of flexible grids, fluid grids and an intelligent use of CSS media queries. As the user switches from their laptop to iPad, the website should automatically switch to accommo-date for resolution. In other words, the website should have the technology to automatically respond to the users preferences. This would eliminate the need for a different design for each new gadget on the market.
1.2
Introduction to Ida Infront
Ida Infront develops systems and solutions for complex and information-intensive businesses. The company have their own range of products un-der the name of iipax, such as document and form handling through
iipax-permission.[7] Ida Infront has discovered a need to make some of these
appli-cations. One such web application is under development and in it they want the functionality for defining Responsive Web Design for forms using the application.
1.3
Problem definition
The problem was defined by discussing with our supervisors at Ida Infront. Ida Infront had already outlined the problem and we discussed what we be-lieved seemed reasonable to do for them, given our time period.
We agreed upon with the supervisors that we would examine techniques which can be used with a web application for specifying responsive design behaviour. This will result in a layout editor prototype, intended for a web-form and providing several configuration options that would specify the behaviour for different screen sizes. The user group of the layout edi-tor is anyone, there are no requirements on programming knowledge. The prototype must realise a RWD technique for the overall form layout and provide the possibility to rearrange and resize form components. Form re-arrangements should be done via drag-and-drop technology. The input for this prototype will be a XML file describing the web-form components. The output should be a XML file describing the responsive design configuration specified.
Appendix A gives a more in-depth description of the functionality of the layout editor. Section 1.3 in appendix A lists the requirements with their corresponding priorities. Section 2.2 in appendix A defines the Use-Cases which the layout editor should realise.
1.4
Research questions
The problem for this thesis can be described by the following questions:
How to specify responsive behaviour of a web-form?
How to design a layout editor that can be used to specify the responsive behaviour of web-forms?
1.5
Purpose
The purpose of this thesis project is to examine the possibilities and prob-lems in designing and implementing layout editor prototype. The prototype will serve as an evaluation for how to implement a fully functional layout editor for Responsive Web Design of web-forms.
A product of Ida Infront, iipax permission, is a process oriented, policy-driven tool for case and document management.[7] Plans to make this appli-cation available online as a web appliappli-cation has taken its form. A prototype for it is under development.
If our thesis work proves to have a positive outcome, then the layout editor could be a part of the web application. It would also mean that Ida Infront could benefit from important findings and further develop the proto-type. It would make it possible for the customers of Ida Infront to define the arrangement of web-form components and their responsive behaviour. This would mean less room for misunderstandings and that Ida Infront could save time, since customers could modify the form without communicating with developers. The possibility to alter the web-form would also allow customers to experiment with different design ideas on their own.
1.6
Delimitations
The prototype is going to be used to evaluate the possibility to create a fully functional layout editor. This means that choices during the course of the project took into account the design of the web application Ida Infront is developing, by looking at aspects such as technologies used and graphical design.
The output of this project will be a prototype with focus on how to spec-ify responsive web-form design. All other non-functional requirements have not been taken into account, in order to increase our chances of finishing a prototype with high quality in time. The non-functional requirements that are not in our scope are such as security, concurrency, availability, reliability, scalability, usability and configurability.
The interface of the layout editor prototype is not designed to be respon-sive. It is only designed to be used on 1920x1080 resolution.
Theoretical Background
Responsive Web Design (RWD) is introduced in section 1.1, where a general view of the concept is given. RWD is of great importance when designing web pages, which takes into account the screen size and adapts its layout accordingly. This is mainly due to the fact that user experience, which is an important factor when designing graphical interfaces, is influenced by the way web content is displayed. In order to achieve the optimal viewing experience, it requires that you understand how menus, forms and other markup should be designed for different screen sizes.
2.1
Web-form
2.1.1 What are web-forms?
One typical web page contains many different visual components, described by corresponding HTML-element. One of the most common component is web-form, which corresponds to the <form> element. A web-form typically consists of several components, which defines what the purpose of the form is. Figure 2.1 shows an example of how a form can be structured. A web-form contains a combination of so called input controls. These are visual components like text fields, check boxes and many more which are often accompanied by a label describing the their purpose.[8]
Figure 2.1: An example of how a web-form can be structured
2.1.2 Designing a web-form
The way a web-form should be designed depends largely on its purpose. The input controls and labels determines the way the form is designed. There are however recommendations in which order input controls should be pre-sented and in which position relative to an input control a label should be placed.
A recommended approach[9] in placing the components is to keep an intuitive order of the input controls, e.g. firstly ask for name, then the date of birth. This gives a logical sequence to the form components and reduces the time it takes to complete the form.
When placing the labels to the input controls, there are two recom-mended approaches.[10] The first approach is to place the label on the top of the component, as illustrated in figure 2.1. This placement results in that it is faster to read both the label and the input controls, which means a user can more quickly submit the asked information. Placing a label to the left means that the user have to look at two different positions in the form, which takes more time. Left-aligned labels are therefore recommended
when the user submits unfamiliar information or when the form should not be rushed through, but may require some thought.
2.1.3 Web-form grid structure
A web-form can be structured as a grid.[11] Figure 2.2 illustrates how the web-form in figure 2.1 can be represented as a grid. This means that there is a structure that defines the way how form components are positioned. The grid cells are not necessarily symmetrical in width and height.
Figure 2.2: An illustration of the underlying grid structure in a webform
2.2
Static Web Design
2.2.1 What is Static Web Design?
The way which web content was designed before the emergence of the new handheld devices was that each web page had a fixed size. This means that the site layout remained the same on different screen sizes. This is referred to as Static Web Design.[12] Static Web Design causes problems for devices with screen sizes significantly smaller than that of a desktop. If the page
would be too large for a screen, then you would need to scroll horizontally or vertically to see all the content. From a technical point of view, Static Web Design means that in the CSS configuration, a fixed pixel width for all HTML markup is used.
2.2.2 Supporting multiple devices in Static Web Design
The way to provide some support for mobile devices is to create a separate website.[13] In the mobile version you effectively copy the contents of the desktop version and adapt the design to display on a mobile device. This means that in order to show two different versions of the same site, we need to duplicate the source code. When someone visits the site, there would have to be a check on which device the visitor is using, and then redirect to the mobile or desktop version. The drawbacks with this solution is that there would be a need to maintain two different versions, which is not desirable, as it costs money and time.
2.3
Responsive Web Design
In 2008, W3C created the specification for CSS3 media queries.[14] This provided the opportunity to create different layouts for different screen sizes without using multiple web sites. The release of the specification came as a response to the need to adapt web pages to different screen sizes.[15] In 2010, the term Responsive Web Design was minted by Ethan Marcotte.[16][17] The purpose of Responsive Web Design is to remove the constraints of Static Web Design by adapting web content to the screen size on which it is displayed. The reason for the popularity of Responsive Web Design is that it provides the possibility to improve the user experience.[18] This makes user
experi-encethe main driver for Responsive Web Design. Figure 2.3 depicts common
Figure 2.3: Same web page displayed on different devices
RWD utilises a set of techniques used to define how web content layout should be rearranged. The most common techniques are flexible grids, fluid grids and media queries, all of which are expressed in CSS. There are sev-eral front-end web frameworks, which can be used to define Responsive Web Design.[19] These are often more simple to use than manually configuring the CSS.[20]
2.3.1 Media Queries
Media queries is the big enabler of Responsive Web Design.[21] Media queries has a property screen, which is used to detect the pixel or screen size of the device being used for browsing. This allows media queries to target different pixel or screen size configurations and define different layout for specific de-vices. This means that we can target specific screen dimensions by defining appropriate intervals and optimise the viewing experience. Figure 2.4 shows an example of the visual representation of a CSS configuration that uses media queries to modify the background color of the body element. The
example will change the color depending on what the current pixel width of the device is.
Figure 2.4: Color changes for different intervals
Listing 2.1 corresponds to the CSS configuration used in figure 2.4. The listing shows the media queries and their intervals. The min-width property means that when the width is at least that number of pixels, only then will the layout apply. The max-width property means that only up to that number of pixels will the layout apply.
Listing 2.1: A CSS configuration for media queries
b o d y { b a c k g r o u n d - c o l o r : w h i t e ; } @ m e d i a s c r e e n and ( min - w i d t h : 300 px ) { b o d y { b a c k g r o u n d - c o l o r : l i g h t b l u e ; } }
@ m e d i a s c r e e n and ( min - w i d t h : 450 px ) { b o d y { b a c k g r o u n d - c o l o r : l i g h t g r e e n ; } } @ m e d i a s c r e e n and ( min - w i d t h : 600 px ) { b o d y { b a c k g r o u n d - c o l o r : y e l l o w ; } }
2.3.2 Fluid Grid Design
Fluid Grid Design is a Responsive Web Design technique that uses an un-derlying grid. The grid consists of columns and rows, which will reshape and adapt according to the screen size. The grid system uses media queries to reshape the grid. A grid will typically increase in the number of columns for bigger screens and therefore show more grid cells on each row. The re-verse effect will occur for smaller screens, where the number of columns will be reduced.[22] Figure 2.5 illustrates a layout with Fluid Grid Design. The underlying markup is a table, in which each input control and corresponding label is embedded in a <tr> <td> sequence.
Figure 2.5: Different layouts of a fluid grid
Listing 2.2 corresponds to the CSS configuration used in figure 2.5. The listing shows the different media queries and their intervals. For small screens below 480 pixels the form components will expand 100 percent on each row. For larger screens, between 480 and 720 pixels, the components will take up around half the width and result in two columns and two rows. Above 720 pixels, the form components are placed on the same row, each taking up 20 percent width.
Listing 2.2: Fluid grid example
i n p u t [ t y p e = t e x t ] { w i d t h : 1 0 0 % ; } tr { f l o a t : l e f t ; margin - l e f t : 5 px ; } @ m e d i a s c r e e n and ( min - w i d t h : 480 px ) {
tr { w i d t h : 4 5 % ; } } @ m e d i a s c r e e n and ( min - w i d t h : 720 px ) { tr { w i d t h : 2 0 % ; } } @ m e d i a s c r e e n and ( max - w i d t h : 479 px ) { tr { w i d t h : 1 0 0 % ; } }
2.3.3 Flexible Grid Design
Flexible Grid is a Responsive Web Design technique that uses an underlying grid structure.[23] The grid consists of a fixed structure of cells. The struc-ture will expand for larger screens and contract for smaller screens. The grid will however never reshape the structure to adjust the content as with a fluid grid. This behaviour is achieved by setting a percent value of the screen as the width and/or height of cells. The width and height will then dynamically increase and decrease depending on the medium it is displayed. Figure 2.6 depicts how a flexible grid will change with regards to the screen size.
Figure 2.6: Different layouts of a flexible grid
Listing 2.3 corresponds to the CSS configuration used in figure 2.6. The listing contains the three different grid cells indicated by a class with their color.
Listing 2.3: Flexible grid example . g r e e n { w i d t h : 1 0 0 % ; h e i g h t : 100 px ; b a c k g r o u n d - c o l o r : l i g h t g r e e n ; f l o a t : l e f t ; } . b l u e { w i d t h : 7 0 % ; h e i g h t : 100 px ; b a c k g r o u n d - c o l o r : l i g h t b l u e ; f l o a t : l e f t ; } . y e l l o w { w i d t h : 3 0 % ; h e i g h t : 100 px ; f l o a t : l e f t ; b a c k g r o u n d - c o l o r : y e l l o w ; }
2.3.4 Mobile First Approach
Mobile first is a design strategy in Responsive Web Design.[24] The strategy suggest that you start designing the website for the smallest device you want to support. Then you incrementally design for larger and larger devices, until you reach the final device to support. The benefits of this strategy is that if you constrain yourself to start designing for small devices, you will be forced to make decisions about what content is important.[25] The reasoning is also that it is easier to translate a mobile design to a desktop design than the contrary.
2.4
Design with Bootstrap
2.4.1 What is Bootstrap?
Bootstrap is a front-end web framework used for creating responsive websites that adapts according to the screen it is displayed on, whether it be a small
phone or a large desktop.[26] It was originally developed by Twitter under the name of Twitter Bootstrap. Bootstrap is considered the most popular framework for Responsive Web Design and continues to grow, making it an appealing choice when designing websites.[27]
2.4.2 Grid system for different devices
Bootstrap uses an underlying grid system, which adapts according to the device which it is displayed on.[28] A row in the grid system is always 12 columns wide. There are no restrictions to the number of rows in the grid. Figure 2.7 illustrates how a Bootstrap grid can be structured.
Figure 2.7: Bootstrap grid system with 12 columns
The framework classifies four different types of devices. These are smart-phones, tablets, laptops and desktops. See figure 2.3 for a picture of the devices. Bootstrap uses media queries to identify the pixel-width of the device and applies the device-specific styling. To achieve this the frame-work provides classes that are used to define the grid cells. Each of these classes indicates which device the layout should apply to, and the number of columns the cell should take up. See figure 2.8 for a table of the classes.
Figure 2.8: A table of the 4 different Bootstrap device classes
In order to adapt figure 2.7 to fully utilise Bootstrap design, one would need to define specific grid cells for a used device. Figure 2.9 shows an example of how the grid could be defined when a laptop sized device (md) is used. Each cell defines the col-md-x format, where x is the width of the cell.
Figure 2.9: A Bootstrap grid with md configuration
Each cell in a bootstrap grid can contain multiple device classes and are not restricted to the use of just one device class.
It is possible to hide components in Bootstrap when a certain device class is being displayed. For example you can hide fields which are not to be displayed on a phone or tablet. In order to hide a grid cell on a xs device, one would have to specify .hidden-xs on the cell. The same applies to the remaining device classes.
2.4.3 Mobile First
Bootstrap uses a Mobile First strategy.[28] This means that the Bootstrap device configuration is applied according to the Mobile First mindset. For example, if there is only a md configuration for the grid, then it would apply to md and all configurations above md such as lg. However if there is both md and lg configuration for the cells, then the lg configuration would override the md configuration when the lg device is used. If a device below
mdis being used, such as sm or xs and they are not configured, then the grid
cells would expand and each of them take up 100 percent of the width(12 columns in the grid system) of the screen.
Methodology
The thesis work consists of two processes, research process and prototype
design process. The research process consists of collecting and analysing
information which is then used in the prototype design process to construct the layout editor prototype. This chapter will give an account for both processes and how they are structured.
3.1
Research process
The aim of this thesis is to give answers to the following questions: How
to specify responsive behaviour of a web-form? and How to design a layout
editor that can be used to specify the responsive behaviour of web-forms?
With the main questions identified we felt the need to decompose them to be more narrow and specialised. The resulting research questions are presented in section 3.3. Figure 3.1 illustrates the research process model used to find answers to these new specialised questions. The process model is a modified version of a proposed research process structure given by the book Thesis Projects.[29] The process model has been adapted to better fit our project, which is more focused on collecting and analysing data rather than making a hypothesis.
Figure 3.1: The Research Process
Identify problem area
The first phase identifies the problem area in which there is need to gather information. The information that needs to be collected is relevant to an-swer the specialised research question. See section 3.2 for more detailed information.
Identify research question
This phase looks at the problem area and the information that is needed. Based on the problem area and type of information needed, a specified research question that defines what to examine, is derived. See section 3.3 for more detailed information.
Collecting information
This phase consists of gathering relevant information which can be used to answer the question. See section 3.4 for more detailed information.
Analysing information
This phase consists of analysing the information that has been found. This is done by taking notes on important findings such as how components are defined in the XML file. See section 5.1 for more detailed information.
Interpreting results
This phase consists of compiling the results and sorting what findings are relevant for the research question. This selection is not presented in the
report since it is not relevant when answering the research question.
Stating conclusions
In this phase we give an answer to the research question by concluding what we have found. See section 5.1 for more detailed information.
3.2
Identifying problem areas
In order to find an answer to the main research questions, it was broken up into several problem areas to narrow it down. Following problem areas were identified.
• Study the structure of the current XML file used by Ida Infront to represent the web-forms. This knowledge will provide insight in how to translate the XML file to HTML markup and modify the structure of the web-forms.
• Gather information and learn more about RWD in order to better un-derstand the concept and what techniques exists. Based on important findings select appropriate RWD techniques to apply for web-forms. • Find technologies that can be used in the layout editor prototype. A
front-end technology is selected with regards to how well drag-and-drop can be implemented and how well it supports the chosen RWD techniques. A back-end technology that allows generation of web-forms is selected.
3.3
Identifying specialised research questions
We needed knowledge about the problem areas to be able to select and apply technologies and techniques best suited for the prototype. The fundamental problem in each of the areas can be uttered by appropriate questions. These questions are:
• What distinguishes different components in the XML-file that Ida
In-front uses?
• How can the components in a web-form behave when the screen size
• What technologies are suitable for the prototype taking into account
the future web application?.
3.4
Collecting information
To be able to answer the research questions corresponding to the problem areas, we had to gather more information. Here we describe the methods used to answer the questions.
What distinguishes different components in the XML-file that Ida Infront uses?
In order to answer this question we needed to analyse some test samples of existing XML file which was provided by Ida Infront. Any questions that appeared during our analysis was discussed with our supervisors at Ida Infront.
How can the components in a web-form behave when the screen size changes?
Our method for collecting appropriate information was by literature studies about responsive design techniques. The most important resources mainly came from books and articles found through web-search. Most notable is Ethan Marcotte’s[30] and Luke Wroblewski’s[31] work. Marcotte’s article
A List Apart[16] coined the term Responsive Web Design. Shortly
after-wards he also wrote a book on the subject, with the name Responsive Web
Design.[32] Wroblewski created the design approach Mobile First and wrote
a book on the subject, named Mobile First.[33] More articles, books and blogs followed afterwards by many different authors. Google scholar[34] provided a good portal for finding scientific articles about the subject.
What technologies are suitable for the prototype taking into ac-count the future web application?
We concluded that Ida Infront would benefit the most if our prototype was implemented with the same technologies they are using for their web appli-cation. First we made observations about technologies they were using for both the front- and back-end, which was recorded by taking notes. When
these were discovered, we needed to make sure that the prototype can be implemented with use of the same technologies. If not, other technologies had to be found.
For finding new technologies, a search engine such as Google was used to find various results. Among the results we had to pick the one most suit-able for the desired functionality. For example, the web site CodeGeekz[35] listed many useful drag-and-drop utilities. However, it was up to us to de-cide which ones were applicable to our prototype.
Complexity was also a factor during the selection of technologies due to the limited time-frame and reluctance to add unnecessary complexities to the prototype.
3.5
Prototype design process
After collecting the required information we began designing the prototype. Consultations with our supervisors from Ida Infront, resulted in the following goals which the prototype must implement:
• The prototype reads the XML file containing a web-form configuration and generates the corresponding HTML components of the form. • The prototype provides possibility to change the placement and size
of form components.
• The prototype utilises drag-and-drop technology for modifications of the form components.
• The prototype realises the selected techniques for RWD and allows configuration for responsive design.
• The prototype generates an XML file that describes the responsive configuration for a web-form.
In order to document the architecture and functionality of the proto-type, a SAD (appendix A) that focuses on these aspects is produced. We decided to use Kruchten’s 4+1 model[36] and adapted it to only document two views, one to describe the Use-Cases and the other how the layout editor
realises them.
We decided to use the Prototyping Model[37] as the design process for the prototype, see figure 3.2. Each goal completes at least one cycle in the prototype design model. The Prototyping Model is suitable for projects where technical solutions are unclear and requires investigation. This is just the situation when creating the layout editor. The reason for this being that there is no predefined design for the prototype or, to our knowledge, existing approaches to design a similar layout editor for web-forms.
Figure 3.2: The Prototyping Model
Communication
In this phase we verbally discussed ideas, mainly regarding the functionality and GUI design with our supervisors at Ida Infront. For each idea we had to analyse what was feasible, given our time-frame and how much value it would bring to our end result.
Planning and design
In this phase we created mockups, took notes and verbally discussed design and functionality choices. We would then decide what approach seemed best to design a solution to a given problem.
Construction of prototype
In this phase we implemented the design and functionality decided in the previous phase.
Deployment, Delivery and Feedback
In this phase we presented functionality and progress in front- and back-end. This may trigger discussions leading on to the Communication phase.
Empirical basis
This chapter will bring up the XML structure for the web-forms. It will also list the appearance and HTML representation of components used in a web-form, as they are defined in Ida Infront’s web application prototype.
4.1
XML structure of forms
A customer of Ida Infront usually has very large, complex systems and mul-tiple forms for different cases. The configuration of each form is defined with XML with the following structure.
Each case is an objectType and its properties are defined inside an
exter-nalPropertiesnode. A component in a web-form is called attributeType, but
inside the scope of an objectType they are represented by an
objectAttribute-Type and exists as children to objectType. Listing 4.1 shows an example of
skeleton structure of an objectType.
Listing 4.1: XML skeleton for an objectType
<o b j e c t T y p e id =" s t d _ g e n e r a l _ c a s e " c l a s s =" c o n t a i n e r "> <! - - P r o p e r t i e s for the s t d _ g e n e r a l _ c a s e - -> <e x t e r n a l P r o p e r t i e s> <p r o p e r t y> <v a l u e> < /v a l u e> < /p r o p e r t y> < /e x t e r n a l P r o p e r t i e s>
<! - - Z e r o to m a n y n o d e s of o b j e c t A t t r i b u t e T y p e for s t d _ g e n e r a l _ c a s e - -> <o b j e c t A t t r i b u t e T y p e/ > <o b j e c t A t t r i b u t e T y p e/ > <o b j e c t A t t r i b u t e T y p e> <! - - If you w a n t to o v e r r i d e p r e d e f i n e d v a l u e s and p r o p e r t y
for an o b j e c t A t t r i b u t e T y p e you can do so h e r e - -> <d e f a u l t V a l u e s/ > <e x t e r n a l P r o p e r t i e s/ > <p o s s i b l e V a l u e s/ > < /o b j e c t A t t r i b u t e T y p e> < /o b j e c t T y p e>
Properties of an objectAttributeType are usually already defined in an
attributeType node, but if one would want to change its default settings for
a specific case, one could do so by overriding the properties inside the
ob-jectAttributeTypenode.
Configurations of an attributeType can be set as attributes inside the tag or inside the externalProperties, possibleValues or defaultValues node. Listing 4.2 shows a common example where a component is described both by attributes and properties inside an externalProperties node.
Listing 4.2: attributeType example <a t t r i b u t e T y p e id =" s t d _ r e g i s t r a t i o n _ d a t e " m u l t i V a l u e d =" f a l s e " r e a d O n l y=" t r u e " r e q u i r e d =" t r u e " t y p e =" d a t e " c o n t e n t S e a r c h a b l e =" t r u e "> <e x t e r n a l P r o p e r t i e s> <p r o p e r t y n a m e =" d i s p l a y N a m e . sv "> <v a l u e> R e g i s t r e r i n g s d a t u m < /v a l u e> < /p r o p e r t y> <p r o p e r t y n a m e =" d i s p l a y N a m e . en "> <v a l u e> R e g i s t r a t i o n d a t e < /v a l u e> < /p r o p e r t y>
<p r o p e r t y n a m e =" a t t r i b u t e T a b "> <v a l u e> &3. S t a t u s & b e s l u t < /v a l u e> < /p r o p e r t y> < /e x t e r n a l P r o p e r t i e s> <p o s s i b l e V a l u e s/ > <d e f a u l t V a l u e s/ > < /a t t r i b u t e T y p e>
The property with name attributeTab defines what group or tab the component belongs to. Regardless of which objectType uses the component it will always be part of that group.
Placement of components
With Ida Infronts existing Java client, the placement of the components defined in the XML is done sequentially, i.e. they are placed in the order they appear in the XML file. To define that a component will be placed in the same row as another, there is a property named keepWithPrevious. If it has a value set to true, the Java client will try to place it on the same row as previous component. Some components, such as text area will fill the whole row by itself.
Example of web-form
Figure 4.1 shows an example of a web-form in a Java client, and listing 4.3 and 4.4 show corresponding XML definition.
Listing 4.3: XML for std_general_case <o b j e c t T y p e id =" s t d _ g e n e r a l _ c a s e " c l a s s =" c o n t a i n e r "> <d e f a u l t V a l u e s> <v a l u e> G e n e r e l l t ä r e n d e < /v a l u e> < /d e f a u l t V a l u e s> <! - - G r o u p : A l l m ä n t - -> <o b j e c t A t t r i b u t e T y p e a t t r i b u t e T y p e I d =" d i s p l a y _ n a m e " r e a d O n l y =" f a l s e " r e q u i r e d =" t r u e " log =" t r u e " c o n t e n t S e a r c h a b l e =" t r u e "> <e x t e r n a l P r o p e r t i e s> <p r o p e r t y n a m e =" d i s p l a y N a m e . sv "> <v a l u e> Ä r e n d e n u m m e r < /v a l u e> < /p r o p e r t y> <p r o p e r t y n a m e =" r e a d O n l y "> <v a l u e> t r u e < /v a l u e> < /p r o p e r t y> <p r o p e r t y n a m e =" f i e l d L e n g t h "> <v a l u e> 7 < /v a l u e> < /p r o p e r t y> <p r o p e r t y n a m e =" a t t r i b u t e T a b "> <v a l u e> & amp ;1. A l l m ä n t < /v a l u e> < /p r o p e r t y> < /e x t e r n a l P r o p e r t i e s> < /o b j e c t A t t r i b u t e T y p e> <o b j e c t A t t r i b u t e T y p e a t t r i b u t e T y p e I d =" s t d _ d i a r y _ n o " log =" f a l s e "/ > <o b j e c t A t t r i b u t e T y p e a t t r i b u t e T y p e I d =" s t d _ y e a r " log =" t r u e "/ > <o b j e c t A t t r i b u t e T y p e a t t r i b u t e T y p e I d =" s t d _ d i r e c t i o n " log =" t r u e "/ > <o b j e c t A t t r i b u t e T y p e a t t r i b u t e T y p e I d =" s e n t e n c e " log =" t r u e "/ > <o b j e c t A t t r i b u t e T y p e a t t r i b u t e T y p e I d =" s t d _ d e s c r i p t i o n " log =" t r u e "/ >
< /o b j e c t T y p e>
Listing 4.4: XML for std_direction specification
< a t t r i b u t e T y p e id =" s t d _ d i r e c t i o n " m u l t i V a l u e d =" f a l s e " r e a d O n l y =" f a l s e " r e q u i r e d =" f a l s e " t y p e =" s t r i n g " c o n t e n t S e a r c h a b l e =" t r u e "> <e x t e r n a l P r o p e r t i e s> <p r o p e r t y n a m e =" d i s p l a y N a m e . sv "> <v a l u e> R i k t n i n g < /v a l u e> < /p r o p e r t y> <p r o p e r t y n a m e =" a t t r i b u t e T a b "> <v a l u e> & amp ;1. A l l m ä nt < /v a l u e> < /p r o p e r t y> <p r o p e r t y n a m e =" t o o l T i p . sv "> <v a l u e> R i k t n i n g < /v a l u e> < /p r o p e r t y> <p r o p e r t y n a m e =" k e e p W i t h P r e v i o u s "> <v a l u e> t r u e < /v a l u e> < /p r o p e r t y> < /e x t e r n a l P r o p e r t i e s> <p o s s i b l e V a l u e s> <v a l u e> I n k o m m a n d e < /v a l u e> <v a l u e> U p p r ä t t a t < /v a l u e> <v a l u e> Utg å e n d e < /v a l u e> < /p o s s i b l e V a l u e s> <d e f a u l t V a l u e s/ > < /a t t r i b u t e T y p e>
4.2
HTML components in web prototype
The web application prototype which is under development has defined the HTML for the components used in the web-forms. This section will list them and show corresponding HTML markup and visual representation. Most of the class names corresponds to classes defined in Bootstrap.
Text field
< i n p u t t y p e = " t e x t " c l a s s = " form - c o n t r o l " / >
Text area
< t e x t a r e a c l a s s = " form - c o n t r o l a u t o g r o w " r o w s = " 4 " > < / t e x t a r e a >
Text area with toolbar
< t e x t a r e a c l a s s = " form - c o n t r o l t e x t a r e a b o o t s t r a p - e d i t o r " r o w s = " 4 " > < / t e x t a r e a >
< s e l e c t c l a s s = " form - c o n t r o l s e l e c t select - p r i m a r y " data - t o g g l e = " s e l e c t " >
< o p t i o n v a l u e = " 1 " > A l t e r n a t i v e 1 < / o p t i o n > ...
< / s e l e c t >
Multi-valued field with specified values
< div c l a s s = " input - g r o u p " >
< div c l a s s = " input - group - a d d o n " > < i c l a s s = " i i c o n s iicon - l i s t " > < / i > < / div > < s e l e c t m u l t i p l e c l a s s = " form - c o n t r o l m u l t i s e l e c t m u l t i s e l e c t - d e f a u l t " data - t o g g l e = " s e l e c t " > < o p t i o n v a l u e = " 1 " > A l t e r n a t i v e 1 < / o p t i o n > < o p t i o n v a l u e = " 2 " > A l t e r n a t i v e 2 < / o p t i o n > ... < / s e l e c t > < / div >
Multi-valued field with non-specified values
< div c l a s s = " input - g r o u p " >
< div c l a s s = " input - group - a d d o n " > < i c l a s s = " i i c o n s iicon - l i s t " > < / i > < / div >
< i n p u t c l a s s = " t a g s i n p u t " / > < / div >
Multi-valued field with both specified and non-specified values
< div c l a s s = " input - g r o u p " >
< div c l a s s = " input - group - a d d o n " > < i c l a s s = " i i c o n s iicon - l i s t " > < / i > < / div > < i n p u t data - t o g g l e = " t a g s " data - s e l e c t o p t i o n s = " A l t e r n a t i v e 1 , A l t e r n a t i v e 2 , ... " / > < / div > Date picker < div c l a s s = " input - g r o u p " >
< div c l a s s = " input - group - a d d o n " > < i c l a s s = " i i c o n s iicon - g r i d " > < / i > < / div >
< i n p u t t y p e = " t e x t " c l a s s = " form - c o n t r o l d a t e p i c k e r " / > < / div >
Analysis
5.1
Specialised research questions and answers
In section 3.3 we broke down our research questions into smaller, more nar-row questions in different domains, which could help us provide an answer to the main research questions. This chapter will give an answer to each of them.
This chapter does not bring up the technical details of how layout editor is implemented. Appendix A is a SAD that describes the functionality and design of the layout editor more in-depth.
5.1.1 Responsive behaviour of web-form component
The question in the domain of responsive design is How can the components
in a web-form behave when the screen size changes?
We found that there are several possible ways that form components can be rearranged, as the screen size changes.
Merging columns
In order to accommodate smaller screen sizes, some layouts rely on a grid system. Since forms can be represented as a grid, we can reshape the form to a new grid structure, one that contains the same components but less columns. Look at figure 5.1 and 5.2 for an illustration. By reducing the number of columns and increasing the number of rows we would end up
with a form that is better fit for a smaller device. Figure 5.1 shows an example of a form that is 4 columns wide. This is a rather wide form and therefore, at its current layout, too wide for a smaller screen.
Figure 5.1: A form suitable for larger screen sizes
How could we adapt this layout to a smaller screen size? Since the form is structured as a grid with evenly sized cells, we could simply reshape the grid layout. Reducing the number of columns would be an appropriate choice to accommodate smaller screens. We could then end up with a 2 column wide grid system, as in figure 5.2.
Figure 5.2: A form suitable for smaller screen sizes
Hiding components
As the screen gets smaller it may be appropriate to hide certain form com-ponents. This may be due to the fact that a slimmed form may be more appropriate for a smaller screen size. However, only components which are not essential for the purpose of the form should be removed. Consider figure 5.3, which is an example of a possible form for registration. It contains fields which are relevant to creating a user account. However, it would be possible to remove the two fields that are not mandatory.
Figure 5.3: A form with two alternative fields
Now lets say we want to accommodate a smaller screen size. We could decide to hide input fields which are not required. It would result in 6 components instead of 8 and an overall smaller form. Figure 5.4 shows how the form with the hidden components, using fewer columns, could look.
Figure 5.4: A smaller form with no excess fields
Grouping components
The components in a form could be structured according to some context. Consider figure 5.5: in the figure we can make out two sets of components, each one targeting a specific type of information. The area marked with green targets the personal attributes of some individual such as the full name, the user name and password. The area marked with red targets information associated with the location of the individual.
Figure 5.5: A form with two groupings
compo-nents in the form. The compocompo-nents in the form should retain this contextual structure to generate a logic flow in the form. When reshaping the form to adapt to smaller screens, it may be appropriate to perform some type of grouping of these components. This would ensure that the components stick to together as the form reshapes. This could be achieved by placing them in a container. Figure 5.6 illustrates how the form could reshape to accommodate a smaller screen.
Figure 5.6: Reshaped version of form in figure 5.5
5.1.2 Components in XML file
In section 4.1 we explained the structure of an XML file that represents a web-form. In order to have the layout editor prototype parsing components from an XML file, we need to answer the following question: What
distin-guishes different components in the XML file that Ida Infront uses?
In section 4.2 we listed all components that will be used in the web application. Our prototype does not necessarily use every one of them since Ida Infront already have a parser for the components which they use with their desktop application. They will most likely use it or a version of it in their web application. But still, a variety of components would be beneficial for the demo presentation of the prototype. The components we chose to add to the prototype are the following:
• Text field
• Multi-valued text field
Note that there exist 3 versions of this component but since they all have the same visual output we chose to not distinguish them
• Drop-down • Date picker
What type of component an attributeType is on a web-form, is defined in several ways. For instance type=’date’ clearly tells that it is a date picker field. The same attribute with value ’String’ could be a text field, but if it also has values in the possibleValues node, then it would be interpreted as a drop-down selector in the web-form.
The following list of criterions shows what distinguishes the chosen compo-nents:
Component Criterion
Multi-valued field Attribute multiValued has value ’true’ Text area Attribute type has value ’long’
Drop-down Node with tag name possibleValues has 1 or more children Date picker Attribute type has value ’date’
Text field Attribute type has value ’String’ and none of the above criterions is true
5.1.3 Technologies
What technologies are suitable for the prototype taking into account the
fu-ture web application? We will distinguish the answer between back-end and
front-end.
Back-end technologies
Since the layout editor prototype hope to be fully or partially integrated in the future web application, it is important to make sure that the prototype can execute in the same environment. For that cause we chose the same back-end that is planned for the web application. Which is:
Apache Wicket[38] Web application framework Apache Maven[39] Build tool
These are Java technologies so any utility, for e.g. parsing XML, is also done with Java.
Front-end technologies
The front-end part leaves a wider range of variation when it comes to pos-sible technologies, since they are independent from the back-end and server technologies.
The chosen technology for drag-and-drop is an implementation of
Grid-sterwidgets for AngularJS, called angular-gridster.[40] AngularJS is a JavaScript
framework which is maintained by Google. Like a regular JavaScript library it can be distributed as a file either locally or remotely, it is then included in a web page with a <script> tag. AngularJS was originally leaning towards a client-side MVC architecture. According to Igor Minar, software engineer at Google, many refactorings and improvements has led it more towards a MVVM architecture.[41]
This framework is mainly designed for building CRUD web applications.[42] The maybe most notable feature with AngularJS is the two-way binding of data between the model and the view. Any changes to the view are imme-diately reflected in the model, and any changes in the model are propagated to the view.[43]
Gridster allows the drag-and-drop placement of form components in an underlying grid structure. This is useful since it provides a controlled way of how form components can be placed and represented in a grid.
Additional front-end functionality to interact with the user is done with plain JavaScript or JQuery.[44]
Visually the components and menus inherit style from the web applica-tion prototype which uses Bootswatchs Spacelab[45] theme for Bootstrap.
5.2
Main research questions and answers
For the question: How to specify responsive behaviour of a web-form? see section 5.2.2. The section describes how responsive design of a web-form can be specified using Bootstrap.
For the question: How to design a layout editor that can be used to
specify the responsive behaviour of web-forms? see section 5.2.1, 5.2.2 and
5.2.3. They all combined describes how the layout editor is designed. Each section focuses on different aspects of the editor.
5.2.1 Dynamic layout editing
The layout editor need to utilise drag-and-drop technology for changing posi-tions of the web-form components. For structure and control the components should be placed in a grid consisting of rows and columns. A technology which enables these functionalities is a JQuery plugin named gridster.js.[46] For this prototype we have chosen an AngularJS implementation of
grid-ster.js, which allows the components to be placed anywhere in the grid.
The components size is defined in the number of cells they fill both hori-zontally and vertically. Figure 5.7 is a modified, out-cropped image of the editor. It shows in the upper section a text-field with size 4 x 1 in terms of cells and a text area of size 8 x 2. The lower section shows a text-field in 6 x 1 and a text-area in 6 x 2. The figure also show how a web-form for one case is divided in sections also known as tabs, which is briefly mentioned in section 4.1. A web component belongs to one tab and cannot be placed in another.
Figure 5.7: Grid-like editor
Figure 5.7 has 2 widgets, which are enclosed by red borders. A Gridster widget is an underlying grid where form components can be placed. Each Gridster widget has an unordered list, or as they are defined in HTML:
<ul>. Each component is contained within a list-item, or <li>.
The column width, i.e. the number of columns, for a widget can be programmatically altered and its height is always compressed around the components. The height can grow just by placing a component further down. Figure 5.8 shows an example of how a form can be modified. In this example the text fields are increased in width by 1 cell and their positions are altered. The text area has decreased in width by 4 cells and placed one
row downwards.
Figure 5.8: Example of modification in layout editor
The HTML code for each component is described in section 4.2. In order to make each component draggable with the help of gridster, they must be contained within a <li> tag.
5.2.2 Layout editor and Bootstrap
The layout editor is designed to define Responsive Web Design for forms with the Bootstrap grid system. See section 2.4.2 for an explanation of the grid system.
The layout editor is designed to adapt to the structure of the Bootstrap grid system as the underlying grid for the drag-and-drop functionality. The layout editor uses Gridster widget as the underlying grid. The Gridster widget is configured to be 12 columns wide, this is to imitate the structure of the Bootstrap grid system. A result of this is that a placement in this grid can be represented by a position in the Bootstrap grid system. The width of a form component is then determined by in what column it starts and the number of columns it spans. The height is determined by which
row it is positioned and the number of rows it spans. Figure 5.9 depicts the grid system and how position and size of components are interpreted.
Figure 5.9: Bootstrap column and row mapping
In order to make the layout editor aware of the different devices, there needs to be configuration for which Bootstrap device class (lg, md, sm, xs) the layout should be applied to. This is solved by adding four different devices, which one can select. For the Gridster widget we can then define four configurations that corresponds to the Bootstrap device pixel-widths. When selecting a device, the width of the form currently being modified will decrease or increase to adapt to the pixel-width to the selected device. See figure 2.8 for the pixel width of each device class.
The design specification will result in a unique layout for each device. Figure 5.10, 5.11, 5.12 and 5.13 exemplifies form layouts with underlying Bootstrap grids.
Figure 5.11: Laptop view of a form
Figure 5.12: Tablet view of a form
Figure 5.13: Phone view of a form
Listing 5.1 corresponds to the form layout in figures 5.10, 5.11, 5.12 and 5.13. Each label and corresponding input control is enclosed by a <div> tag, which is configured by the Bootstrap device classes, defining the number of columns for each device.
Listing 5.1: Bootstrap code example
< body >
< div c l a s s =" c o n t a i n e r " >
< div c l a s s =" col - lg -4 col - md -4 col - sm -6 col - xs -12" > F i e l d A
</ div >
< div c l a s s =" col - lg -4 col - md -4 col - sm -6 col - xs -12" > F i e l d B
< i n p u t t y p e =" t e x t " s t y l e =" w i d t h : 1 0 0 % " / > </ div >
< div c l a s s =" col - lg -4 col - md -4 col - sm -6 col - xs -12" > F i e l d C
< i n p u t t y p e =" t e x t " s t y l e =" w i d t h : 1 0 0 % " / > </ div >
< div c l a s s =" col - lg -4 col - md -4 col - sm -6 col - xs -12" > F i e l d D
< i n p u t t y p e =" t e x t " s t y l e =" w i d t h : 1 0 0 % " / > </ div >
< div c l a s s =" col - lg -4 col - md -4 col - sm -6 col - xs -12" > F i e l d E
< i n p u t t y p e =" t e x t " s t y l e =" w i d t h : 1 0 0 % " / > </ div >
< div c l a s s =" col - lg -4 col - md -4 col - sm -6 col - xs -12" > F i e l d F
< i n p u t t y p e =" t e x t " s t y l e =" w i d t h : 1 0 0 % " / > </ div >
< div c l a s s =" col - lg -12 col - md -12 col - sm -12 col - xs -12" > F i e l d G
< t e x t a r e a s t y l e =" w i d t h : 1 0 0 % " / > </ div >
</ div > </ body >
For each device, it is also possible to hide components that are not to be displayed. The layout editor realises this functionality by providing the option to hide components for a device when that device is selected. By hiding the component, it will not be displayed in the form for that particular device. It is also possible to display components which have been hidden previously.
5.2.3 Persist configuration into XML
When the layout configuration is defined by the user, with the help of the editor, the components position and size need to be persisted. Since the components are all contained within a list in the HTML source code, it is
possible to loop through each list-item in order to get necessary data from each component. The data that needs to be read from each component is:
• id of the component • column and row position • width and height
• if it is marked as hidden or not
Additional data that is needed is the id of the web-form and which de-vice the configurations will apply to. This is needed to store the responsive configuration in the correct objectType of the XML file. Section 4.1 describes the XML structure behind the web-forms.
Listing 5.2 shows a skeleton of the configuration for responsive design of the web forms. The configuration is generated by JavaScript when saving the layout. The configuration is created by reading the position of the web-form components and to what Bootstrap device the layout should apply. This means that to configure the web-form for each Bootstrap device class, one would need to specify configuration for each device and save it separately.
Listing 5.2: Skeleton code of what is sent to server <! - - R o o t e l e m e n t for the f o r m - -> <c o n f i g u r a t i o n o b j e c t I d =" "> <! - - C o n t a i n e r for the c o m p o n e n t - -> <a t t r i b u t e id =" "> <l a y o u t C o n f i g u r a t i o n n a m e =" "> <p r o p e r t y n a m e =" "> <v a l u e> < /v a l u e> < /p r o p e r t y> <! - - M o r e < p r o p e r t y > n o d e s w i l l f o l l o w - -> ... < /l a y o u t C o n f i g u r a t i o n> <! - - M o r e < l a y o u t C o n f i g u r a t i o n > n o d e s for d i f f e r e n t d e v i c e s may f o l l o w h e r e - -> ... < /a t t r i b u t e>
<! - - A r b i t r a r y a m o u n t of < a t t r i b u t e > n o d e s for d i f f e r e n t c o m p o n e n t s - ->
...
< /c o n f i g u r a t i o n>
We chose to represent configuration for each device with a node named
layoutConfiguration, which will have the name attribute to define which
device it will represent. There may be up to four layoutConfiguration nodes per component, one for every mode defined in Bootstrap.
Listing 5.3 shows all the possible configurations for one device. Listing 5.3: Possible values for layoutConfiguration <l a y o u t C o n f i g u r a t i o n n a m e =" xs "> <! - - xs s m a r t p h o n e m o d e - -> <p r o p e r t y n a m e =" r o w P o s i t i o n "> <v a l u e> 1 < /v a l u e> < /p r o p e r t y> <p r o p e r t y n a m e =" c o l P o s i t i o n "> <v a l u e> 0 < /v a l u e> < /p r o p e r t y> <p r o p e r t y n a m e =" c o l S p a n "> <v a l u e> 12 < /v a l u e> < /p r o p e r t y> <p r o p e r t y n a m e =" r o w S p a n "> <v a l u e> 2 < /v a l u e> < /p r o p e r t y> <p r o p e r t y n a m e =" h i d d e n "> <v a l u e> f a l s e < /v a l u e> < /p r o p e r t y> < /l a y o u t C o n f i g u r a t i o n>
rowPosition row position in the grid colPosition column position in the grid
colSpan how many cells it will fill in the y-axis rowSpan how many cells it will fill in the x-axis hidden if element should be hidden
The information sent from the client is parsed and slightly altered. The
<configuration>node will only be used to locate the correct web-form and
then removed. The <attribute> node will be used to locate the correct web-form component, afterwards removed and its children will be placed in a responsiveConfiguration node. We chose to embed the new responsive configuration in the same file as the original configuration. Listing 5.4 shows an example of the new structure for the original XML-configuration file.
Listing 5.4: responsiveConfiguration introduced in objectAttributeType <o b j e c t A t t r i b u t e T y p e a t t r i b u t e T y p e I d =" s o m e _ i d "> <e x t e r n a l P r o p e r t i e s/ > <d e f a u l t V a l u e s/ > <! - - New a d d e d c o n f i g u r a t i o n - -> <r e s p o n s i v e C o n f i g u r a t i o n/ > < /o b j e c t A t t r i b u t e T y p e>
Discussion
6.1
Limitations
A limitation was our lack of knowledge in the area of front-end frameworks. This meant that considerable time was spent learning many of the technolo-gies used or relearning those we have had prior encounters with.
The prototype is fully functional on Mozilla Firefox version 38.0.1, In-ternet Explorer 11 and Google Chrome 43.0.2357.81. No other browsers or versions have been taken into account.
6.2
Conclusion
Responsive Web Design is still in its early stages, the continuous appear-ance of new devices of all sizes will continue to elevate the importappear-ance of responsiveness in web applications.[16]
We set out to investigate how a customer of Ida Infront, without the knowledge of development, could define the visual configuration for a web-form when displayed on different screen sizes. We examined possible re-sponsive design techniques, as well as web technologies that can be used to implement a layout editor, in which you can configure responsive design. Additionally, the responsive configuration was to be persisted in an XML file.
How to specify responsive behaviour of a web-form?
How to design a layout editor that can be used to specify the responsive be-haviour of web-forms?
Our answer consists of adapting Bootstraps approach of generalising the screen sizes into four different categories, which represent the most common devices, smartphone, tablet, laptop and desktop. Any screen size in between these breakpoints will inherit the looks of the closest smaller device. The responsive specification is stored in an XML file that also contains other configurations about the web-form. In short, the structure of this respon-sive configuration contains the position and size for each component and if it is to be displayed. At most, one component can have four different configurations, one for each device.
We let the user create this responsive configuration by using a prototype of a layout editor web application. The layout editor allows placement of components in a grid-like environment, with the use of drag-and-drop. This environment corresponds to the grid structure of Bootstrap’s grid system. The user can change the view of the web-form to represent any of the four devices. Changing the view means that the grid frame is adjusted accord-ing to the width of the device accordaccord-ing to Bootstrap’s standards. Any layout modification in a view only applies to the configuration for the corre-sponding device. A modification can consist of resizing or rearranging form components, as well as hide or make them visible.
A drawback with having a design for each of the four views individually, is that it is somewhat verbose. If there is need to redesign the web-form for every device, one would have to do so for each view.
Our design choices allowed us to create a WYSIWYG kind of editor, where a user can edit the layout without any knowledge about HTML or XML markup. When editing, the user would be given a continuous presen-tation of the final look of the web-form. From a user point of view, this functionality provides a direct visual representation of the design. This also means that there was no need to implement a preview mode, which would
