A Methodological Process for the Design of Frameworks Oriented to Infotainment User Interfaces

Abstract

The objective of this paper was to propose a methodological process for the design of frameworks oriented to infotainment user interfaces. Four stages comprise the proposed process, conceptualization, structuring, documentation, and evaluation; in addition, these stages include activities, tasks, and deliverables to guide a work team during the design of a framework. To determine the stages and their components, an analysis of 42 papers was carried out through a systematic literature review in search of similarities during the design process of frameworks related to user interfaces. The evaluation method by a panel of experts was used to determine the validity of the proposal; the conceptual proposal was provided to a panel of 10 experts for their analysis and later a questionnaire in the form of a Likert scale was used to collect the information on the validation of the proposal. The results of the evaluation indicated that the methodological process is valid to meet the objective of designing a framework oriented to infotainment user interfaces.

1. Introduction

With the increase in the use of intelligent systems in vehicles, the use of infotainment systems has also increased in parallel. Infotainment systems are made up of software and hardware designed to provide a variety of functions for information display, entertainment, and communication such as movies, games, TV, navigation, and different services, including those related to sustainable driving [1,2]. Regarding sustainability, this has become a strategic priority for the automotive industry, which has implemented various strategies, for example, to reduce greenhouse gas emissions or reduce the fuel consumption of motor vehicles [3], which in turn has such a relevant impact that it is considered one of the United Nations Sustainable Development Goals [4]. An example of such strategies is called “eco-driving”, and it involves providing drivers with a variety of tips and feedback such as observe speed limits, watch vehicle weight, check tire pressure, or reduce air conditioning use [5,6,7] with the objective of minimizing fuel consumption and greenhouse gas emissions while driving. Advice and feedback can be provided through various means, including the website or brochure, class or training, and infotainment systems [6].

However, in practice, the benefits of infotainment systems implemented by the automotive industry, including “eco-driving”, are diminished due to the lack of adequate implementation.

Studies indicate that, in general, the user interfaces of infotainment systems do not present their information to the user in an optimal way due to various factors including overload of information through the interface, triggering the need for drivers to take their hands off the steering wheel, and diverting their attention from the road [8,9,10].

Consequently, the literature indicates that there is a need for strategies that help designers to create appropriate user interfaces [11,12] such as guides [13], heuristics [14], and guidelines [15,16,17], among others, which, although they exist, are disaggregated.

In this context, the union of some strategies for the generation of a framework could be presented as a viable option; however, in a first approximation, it was observed that it is difficult to find methodologies or tools for the generation of frameworks, especially oriented to user interfaces in the automotive field.

In this article, we propose a new methodological process for the development of frameworks oriented to interfaces in infotainment systems based on a systematic literature review about the methods used in the literature for the development of frameworks, which included those oriented to user interfaces, applications, human–computer interaction, and usability, among others.

2. Materials and Methods

To carry out an analysis of the framework alternatives and the options for their de-sign in the field of user interfaces, it was necessary to carry out a review of the existing information through a literature review. According to Whittemore et al. [18], there are different approaches or types of literature reviews according to the purpose to be fulfilled. For example, if you want to carry out a summary of systematic literature reviews, then an umbrella review should be conducted; if you want to synthesize the results of homogeneous observational studies through statistical procedures, then a meta-analysis of observational studies must be carried out; to synthesize the results of investigations or theories through narrative analysis (a research method that is applied to constituent parts of a narrative in order to identify concepts, keywords or other information of interest [19]), an integrative review should be carried out; for this research, which focused on synthesizing the results of experimental or non-experimental investigations through narrative analysis, a systematic literature review (SLR) was pursued.

On the other hand, in relation to the software engineering area, various studies confirm the usefulness of an SLR in this field due to the advantages it entails, such as its definition, universality, and generality [20,21,22,23]. In other words, in an SLR, the methodology to be followed is clearly defined, an SLR can be applied to any research problem, it includes all possible study sources, and it provides generalization techniques such as meta-analysis to extract information that is not normally available in a single study. In relation to this, various authors recommend the use of an SLR as an appropriate and useful method to reduce bias and ensure the quality of the review [18,21,24,25].

In general, the SLR process covered in this research is based on what is defined by the Kitchenham guidelines and its three phases, planning the review, conducting the review, and reporting the review. However, some recommendations from other research in the field of SLR carried out specifically in the field of software engineering have been considered. These suggestions are related to the process of selection of consultation sources [21,26,27] and the determination of the search period on which the SLR would focus [28,29,30], with the aim of solving those areas that the guidelines proposed by Kitchenham indicate must be adapted according to each investigation.

The information related to the SLR developed for this study is presented below, outlining the approach, the data extraction process, and the formulation and description of the methodological process derived from the research.

2.1. Data Collection and Research Method

The data for this study were obtained from the review of 42 selected studies [31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72] by conducting a systematic literature review (SLR) based on the guidelines provided by Kitchenham [73]. The objective of this SLR was to produce a methodology focused on the development of frameworks, specifically regarding the development of automotive interfaces.

• The most relevant research questions for the development of this work were: What method(s) are used for the design of frameworks related to interfaces today? Are there common steps during the design of the different frameworks found in the literature?
• The review was focused on research articles that proposed and/or developed frameworks, which included frameworks not related to the automotive field or user interfaces.
• The searches were carried out using the electronic databases ACM, IEEE Xplore, and Taylor and Francis, considering their specialization in terms of topics related to computer science such as user interfaces, as indicated by various authors [21], [27], [73], some of whom also recommend the selection of specialized databases on a specific subject on the use of services such as Web of Science and Scopus in order to prevent the possibility of omitting articles that could be relevant to the research, and at the same time facilitate the replicability of the SLR [74,75,76].
• According to Kitchenham, the establishment of the years covered by search in SLR is not necessary unless the study requires it [73]. As noted in previous sections, one of the main objectives of the research was to focus on current information, and therefore, a search period was considered between 2015 and 2020 as a first exclusion criterion, considering the definitions of time lapses used in some areas of the scientific literature [28,29,30], for example. It is worth mentioning that a first approach to the literature through the search chain without time restrictions yielded few relevant results with a publication date prior to 2015, because although the number of hits was higher and several keywords appeared in the results, the content provided poor information to solve the research questions. On the contrary, the most relevant studies corresponded to the approximate period of the second 4-month period from 2016 to the present.
• The search was limited by type of document to research article.
• The keywords were selected from preliminary searches and their contrast with the “IEEE Thesaurus”.
• The selection of studies was carried out in stages, using predefined inclusion and exclusion criteria. The first stage of selection was oriented in the reading of titles and abstracts. During this stage, sources mentioning phrases related to proposals or development of frameworks or tools were considered, and the works that did not include the keywords frameworks or tools were excluded. As a result, a set of 350 sources was obtained. During the second stage, the selection of sources was based on the complete reading of the text. The selection criteria was redefined, and frameworks related to hardware and mathematical models were excluded, as well as those that did not describe the process of development or proposal of the framework. Eventually, this stage resulted in a set of 42 sources. Figure 1 presents the diagram of the SLR process.

2.2. Data Extraction

To form a general understanding of the content, several readings were carried out for each of the 42 sources.

Subsequently, the data extraction process began to identify:

• Phases of the framework development process;
• Tools for the development of the framework; and
• Framework structure; then
• All information was identified, grouped, and categorized based on similarities and differences.

2.3. Methodological Process Background

Derived from the systematic literature review, four stages were identified. The first is conceptualization, which refers to specifying in theory the problems that the framework plans to solve around a specific topic, and thinking about the target user and their activities, such as developers of visualization tools [72], human–machine interaction designers [47], or teachers of the computational field [60]. The second is structuring, which is a stage used to define the constituent blocks of the framework [61], [32], which can be a set of various alternatives such as guidelines, design patterns, and methodologies, among others [64]. The third stage is evaluation, which is aimed at confirming the validity of the framework through various methods, among which the studies opt for evaluation by target users and experts [33,42] in the area the framework is oriented [64]. The fourth stage is called documentation; it was specifically suggested by some authors [60,64] and is focused on the generation of consultation documents that describe the conception, development, and use of the framework, as can be seen in Figure 2.

2.3.1. Stages of the Framework Development Process

Stage I. Conceptualization

Objective: At this stage, the development of the framework is determined, justified, and directed.

Activity 1: Goal setting. Before starting with the development of the project, researchers must ensure the need for a framework in the context of their interest, for which the task called “Establishment of need” is used, during which it is important to search for and identify the existence of other frameworks in common. It is also important to ensure that the project you want to develop is of interest to your target users at this early stage to avoid duplicating other similar works or making a framework that does not satisfy a need. Subsequently, it begins with the task called “Specification of the problem”, during which it is convenient to clearly establish the keywords that will guide the investigation in order to keep the development of the project focused. These keywords are related to the concept of framework that is mentioned previously. Once it has been identified that there is a problem to be solved, it is possible to identify the context or issue in which said problem occurs; this issue is called the “Fundamental concept” (F.C.). The focus later shifts to the group of people for whom providing a solution is planned—that is, the target user. The results face a problem during the development of a certain activity working in the context of the (F.C.), called “Activity on the concept” (A.C.). Subsequently, continuing with the focus on target users, we proceed to identify the object of interest; that is, the object on which it develops its activities. This object is called “Object of interest” (O.I.). Finally, these three keywords (F.C., A.C., and O.I.) are integrated into a statement that precisely describes the objective of the framework, a task called “Definition of the objective(s)”.

For example, the objective of the research developed by our team can be stated as follows: “Design a framework based on usability for the evaluation of user interfaces in infotainment systems”. In this example, the “Fundamental concept” (F.C.) for the development of the framework is “usability”, the “Activity on the concept” (A.C.) is “evaluation”, and the “Object of interest” (O.I.) is “user interfaces in infotainment systems”.

Tools: For the development of the tasks at this stage, the use of systematic literature reviews, multivocal literature reviews, and tools for problem solving such as mind maps, brainstorming, and team meetings, among others, are recommended.

Deliverables: At the end of the conceptualization stage, the result is a statement composed of the keywords (F.C.), (A.C.), and (O.I.) that specifically describes the objective of the framework that is planned to be developed. The keywords and the statement obtained must be reflected in a document called the “Concept Document”.

Stage II. Structuring

Objective: This stage is aimed at determining the components that constitute the modular structure of the framework.

Activity 2: Establishment of requirements. Since a framework is a structure with connection points, it is necessary to define each of these points or elements that constitute it. These elements solve or respond to needs established by the components that constitute a general problem; therefore, it is necessary carry out a task of “Requirements search” to define the components of our problem. For this, the three keywords obtained in the previous stage are used, (F.C.), (A.C.), and (O.I.). It is also possible to use the requirements established by other frameworks encountered during the “Establish the need” stage to complement or compare the research. Once the necessary requirements to resolve or ensure the F.C. during the making of A.C. are applied to O.I., a “Selection of requirements” is carried out for those that are considered most relevant to solving the problem. There are problems made up of many elements, so in this case, it is advisable to focus on the elements with the greatest impact on the problem. If the problem is made up of few elements, it is possible to select all of them, considering that a greater number of elements will also increase the complexity of the framework.

Tools: For the development of the tasks at this stage, the use of systematic literature reviews and/or multivocal literature reviews is recommended.

Deliverables: At the end of the activity of “Solution to requirements”, the result is a list composed of the corresponding keywords for each requirement. This list of requirements must be written in a document called the “Requirements Document”.

Activity 3: Solution to requirements. Once the elements of the problem to be solved have been obtained, it will begin with the determination of the structural elements of the framework that is being designed. These structural elements are the solution to each requirement that constitutes the list obtained in the previous activity. It is necessary to carry out a search for solutions available in the literature for each requirement and select those that best suit our specific context. There are different criteria to carry out this selection, including ease of use, effectiveness, and popularity, among others. Each team of researchers must define their own criteria according to their interests.

Tools: For the development of the tasks at this stage, the use of systematic literature reviews and/or multivocal literature reviews is recommended.

Deliverables: At the end of the activity of “Solution to requirements”, the result is a list composed of the corresponding keywords for each solution. This list of solutions must be written in a document called “Document of Structural Elements”.

Activity 4: Integration of solutions to the requirements. In this activity, the way in which each element will be positioned within the framework structure is defined. This composition is related to the target users because its workflow will be used to generate a logical sequence of assembly of the solutions obtained in the previous stage. For this rea-son, the first task of this activity is called “Defining the target user workflow”. To obtain this workflow, it is necessary to approach the target users and obtain first-hand information that will be documented and saved for analysis, validation, and the establishment of the workflow that the framework will have. Subsequently, the task called “Integration of solutions to requirements according to the workflow” consists of the logical ordering of each of the parts that comprise the framework, keeping in mind that they must be presented to the user at the appropriate time. Once an order has been obtained for each part, a first version of the framework is obtained, which, being based on the user’s workflow, should present a certain familiarity that varies in details, such as the approach to one or more new tools.

Tools: For the development of the tasks at this stage, the use of interviews, questionnaires, and a Gesell camera, among others, is recommended.

Deliverables: At the end of the activity of “Integration of solutions to the requirements”, a first version of the framework is obtained, with the possibility of being tested with the target users. This first version of the framework must be registered in the deliverable called “First version of the framework” that contains details convenient for researchers, such as name, date, objective, particularities, observations, and so on.

Stage III. Evaluation

Objective: This stage is aimed at determining faults and implementing improvements to the first version of the framework by obtaining feedback from target users and experts in the subject or research area to provide a quality background to the final framework.

Activity 5: User tests. Communication with the user offers valuable information regarding details that may be presented during the implementation of the framework to carry out its objective, that is why it is of great importance. The target users previously worked with can also carry out this initial test, however, it is important to select the way it will be carried out. In some cases, the economic factor could be a limitation. Another limitation may be the development time of a very polished version of the framework, so therefore, it is convenient to pay attention to the task of “Test type selection”. The task called “Application of the evaluation” consists of carrying out the activities concerning the selected form of evaluation, considering that the data obtained from the application of the test can lead to improvements to our design. All this information must be kept on file for analysis. The user testing stage can be iterated as many times as necessary until the framework manages to satisfy the target user. Thus, it is convenient, in addition to the feedback regarding the points to improve, to establish a form where the user can express that the framework is valid to fulfill its objective.

Tools: For the development of the tasks in this stage, the use of interviews, questionnaires, a Gesell camera, Likert scales, paper prototype, and Wizard of Oz experiments, among others, is recommended.

Deliverables: At the end of the “User testing” activity, the result is an operational version of the framework that has been tested and improved from its use in production. This second version of the framework must be registered in the deliverable called “Framework operational version” that contains details convenient for the researchers, such as name, date, objective, particularities, observations, and improvements, among others.

Activity 6: Validation by expert judgment. Although the framework has been ap-proved by the target users, improvements can still be found regarding the methodology and theories that support them, or even some improvement that responds to an update of the elements that constitute it. Therefore, it is important to carry out a validation of these theoretical and methodological aspects by experts in the problem or topic of interest. For this, it is necessary to carry out the task of “Test design”, which consists of the search for experts for a panel who will evaluate the framework in the above aspects. Therefore, the framework design team should prepare the relevant information as clearly and concisely as possible. Once you have the documentation to be evaluated, the task of “Applying the test” is carried out, which consists of providing the information to be evaluated and the evaluation method. Two important points of this task are to obtain information that helps to improve the framework and evaluate the validity of the theory and methodology used for the design of the framework. This activity can also be applied cyclically until a positive validation of the work is obtained.

Tools: For the development of the tasks in this stage, the use of interviews, questionnaires, multimedia presentations, and Likert scales, among others, is recommended.

Deliverables: At the end of the validation activity by a panel of experts, the result is a final version of the framework that has been tested and improved from the implementation of the observations suggested by the experts. This third version of the framework must be registered in the deliverable called “Final version of the framework” that contains details convenient for researchers, such as name, date, objective, particularities, observations, improvements, and so on.

Stage IV. Documentation

Objective: This stage is aimed at ensuring correct use and enabling improvements and updates in the future, preventing the project from being considered obsolete in a short time.

Activity 7: Intra-stage information gathering. During the development of the design of the framework, diverse information was obtained that was organized in the deliverables. Since they were obtained during the implementation of the methodological proposal, they follow a systematic order; however, it is still necessary to carry out a task of “Structuring the file of project”, which consists of analyzing the optimal way to present the information for future reference. Once this file design has been carried out, we proceed to “Filling the project file” with the information collected. In addition, if necessary, diagrams, tables, graphics, and everything that has been considered necessary during the design of the project file are added. It is important to develop an instructional text that helps during the use of the designed framework.

Tools: For the development of the tasks in this stage, the use of flow charts, checklists, and to-do lists, among others, is recommended.

Deliverables: At the end of the intra-stage information gathering activity, a file is obtained that contains the information necessary for the drafting of the tentative documentation of the framework. All these data must be stored in formats that the team of researchers consider pertinent.

Activity 8: Information integration. After collecting and ordering the data, it is necessary to integrate them in a logical and sequential way within a narrative appropriate to the context of the target users. Therefore, a task of “Drafting of tentative documentation” is carried out. It is suggested that it be subsequently subjected to a “Tentative documentation review” task by the members who designed the framework as well as some target users, so that a constructive criticism can be made, for example, around the jargon used in the documentation, clarity and detail, and the presence of information gaps that may occur because the design team takes for granted some aspects that may be necessary in the future. Based on this feedback, an “Improvement from review” task is carried out, which consists of acting based on the observations obtained. Again, this activity can be carried out as many times as deemed necessary until obtaining an approved documentation.

Tools: For the development of the tasks in this stage, the use of interviews, questionnaires, multimedia presentations, and Likert scales, among others, is recommended.

Deliverables: At the end of the information integration activity, the result is the “Framework Documentation”, which consists of a document with the information necessary to understand, use, maintain, update, or improve the framework.

3. Proof of Concept and Results

3.1. Experiment Description

In order to establish the validity of the proposed methodological process, the validation method by a panel of experts was chosen, which is defined as “an informed opinion of people with experience in the subject, who are recognized by others as qualified experts in it, and that they can give information, evidence, judgments and evaluations” [77]. In other words, an evaluation through expert judgment consists of asking a number of individuals to make a judgment on an instrument or to express their opinion on a particular aspect. For this, the experiment had the participation of 10 experts in implementation, development, or design in one or both of the two main topics of this work, “Frameworks in the area of Software Engineering” and “Methodologies”. The experts have a history of published works and recognition in their various areas of expertise, such as I.T. development methodologies, software solutions, and computer science research, and are from countries such as Brazil, Colombia, Norway, Peru, and Spain. This number of experts is consistent with what other research indicates, that is, a panel made up of at least five experts [78,79]. To determine the experts’ perceptions, the feasibility of the methodological process for the design of a framework oriented to user interfaces in infotainment systems, the conceptual model evaluation questionnaire [80] was used. This questionnaire is composed of eight questions in the form of a Likert scale. Likert scales are defined as a simple and powerful method to build an attitude or opinion scale, developed under the premise that groups of related questions can measure the attitude or opinion of a subject about some topic addressed by these questions [81], and according to the literature, they are classified as one of the best methods to ensure the reliability of the results obtained by the evaluation. Furthermore, in relation to the expert panel evaluations, these methods are commonly implemented due to their reliability [82].

The evaluation tool can be consulted at https://forms.gle/4xL8smBgdj2YZrGG8 (accessed on 4 January 2021). The questionnaire was prepared in Spanish because it is the common language among the participants. We intend to carry out a slightly larger study involving teachers from other countries, for which a questionnaire is being prepared in English.

3.2. Collected Data

The results obtained after applying the evaluation by experts are shown graphically below in Figure 3.

Questions 1 and 2 aim to point out a lack of solidity in the theoretical principles that support the proposal. In Question 1, 60% of the respondents indicated that they strongly agreed on this aspect, while the remaining 40% answered that they agreed. Meanwhile, in Question 2, 60% of those surveyed indicated that they strongly agreed on the relevance of the theoretical principles used for the development of the proposal, 30% indicated that they agreed, and 10% indicated a neutral choice.

Question 3 was related to establishing the significance of the literature reviewed for the topic in question, in our case, the development of frameworks. Of the respondents, 60% indicated that they strongly agreed on this question, 30% indicated that they agreed, and another 10% indicated a neutral choice.

Questions 4, 5, and 6 revolve around the determination of the basic logical rigor. Question 4 specifically evaluates the logical coherence of the proposal; in this case, 40% strongly agreed, 50% indicated that they agreed, and 10% indicated a neutral choice. For its part, Question 5 evaluated the fulfillment of the purpose for which the methodological process was designed; 50% were in strong agreement and 50% opted to agree. In turn, Question 6 was used to evaluate the congruence of the resulting methodological process with the research paradigm used; in this case, 60% of the responses indicated that they strongly agreed and 40% indicated that they agreed.

Question 7 corresponds to the evaluation of the contribution to knowledge that the methodological process contributes; in this case, 20% indicated they strongly agreed, another 40% indicated they agreed, and 40% indicated a neutral choice.

The importance of Question 8 lies in contextualizing the appropriateness of the presentation of the proposed methodological process for a scientific report; 40% of the responses were in strong agreement on this point and 60% agreed.

4. Discussion and Conclusions

Currently, the work teams have developed some options for frameworks related to interfaces. However, a quick search for methodologies specifically oriented to this type of framework failed to identify a common or popularly used process.

The methodological process presented in this document is the result of the use of an SLR developed with two main objectives. The first objective consisted of the identification of the methods currently used for the design of frameworks; however, the answer to this question did not clearly indicate an established methodology. For the design of frameworks, the work teams planned and developed their own processes adapting to the needs of their particular interest, which led to the second objective. The second objective consisted of determining if there were common steps between the different processes described in the literature related to frameworks and their alternatives. In response to this second objective, it was possible to identify four stages and eight activities with their respective tasks, as well as recommendations about the importance of developing deliverables. All the above were integrated into the proposed methodological process and it was subsequently evaluated that said process was feasible specifically for the design of a framework oriented to user interfaces in infotainment systems. The evaluation of a panel of 10 experts in the areas of frameworks and methodologies validated the methodological process. However, there are some limitations of the project, particularly in relation to the use of an SLR. For example, when establishing the criterion of leaving out frameworks related to hardware and mathematical models, the possibility of using or adapting the methodological process for equipment is probably limited in this area of research and is limited only to those projects that share the property of being developed in the form of a structure based on components. On the other hand, considering a change in the research perspective by eliminating the time limit currently set, the current proposal possibly accepts modifications. In this context, a future work could be developed under a scheme of comparison of results. Another possibility of future work could be developed by implementing the search and including gray literature to have a possibility of expanding the identification of relevant aspects with the subject from the point of view of experts in the professional field, considering that in that field, formal publication of contributions is often omitted, as described by Garousi [83].

As part of our future work, we plan to develop updates to the conceptual proposal material by further addressing the characteristics and specifications of the tasks and deliverables and to carry out a further peer review on a larger scale and to continue development of the proposed framework. Finally, we are also interested in analyzing the areas for improvement revealed by the evaluation, especially in relation to Question 7.