Figure 1 - uploaded by Damiano Distante
Content may be subject to copyright.
Source publication
Refactoring was originally conceived as a technique for enhancing the design of an existing code base by applying small behavior-preserving transformations to the code. Later research extended scope of refactoring to other software artifacts, such as design models, and widened its intent to improve additional software quality factors, such as perfo...
Contexts in source publication
Context 1
... Web engineering methodologies organize the design of a Web application into three layers by means of three design models: content model, navigation model, and presentation model [6]. The content model defines the types, attributes, and relationships of the application contents and their associated behavior. Refactorings that apply over this model are traditional refactorings intended to improve internal quality factors. The navigation model maps classes of the content model to navigation nodes (units of information and behavior perceived by the user), and associations between content classes to navigation links . Moreover, associations with a multiplicity greater than one are mapped to navigation indexes , to organize the navigation space. The presentation model defines the Web application abstract user interface, which is mainly a collection of pages with their components: widgets that show node attributes, those that trigger node operations, and anchors for navigating over links. It is abstract because it does not specify the exact position of widgets, nor their graphical attributes, but just their type. Both the navigation and presentation models can be represented with stereotyped UML class diagrams [8]. Figure 2 shows simplified versions of a navigation diagram (left) and a presentation diagram (right) for the application presented in Section 2. Classes in the navigation diagram represent nodes or indexes, and classes in the presentation diagram represent pages. For space reasons we have omitted attributes of navigation classes and show a single presentation class corresponding to the “Wall” tab (see Figure 1). Attributes of a presentation class appear in stereotyped boxes where, for example, an “anchored collection” represents a list of anchors for links, mapping an index. Presentation classes can also be nested (e.g. “Basic information”). We have defined Web refactorings over the navigation and presentation models, which gives us a powerful abstraction mechanism as compared with the implementation level; we called them navigation model refactorings and presentation model refactorings respectively [7]. This classification is intended to help developers in choosing the right refactoring depending on the design attributes they need to improve, as further described in Sections 3.1 and ...
Context 2
... Web application is generally designed by means of three models corresponding to the following three design layers: content, navigation, and presentation [6]. We have elsewhere presented a catalog of refactorings over the navigation and presentation models of the OOHDM Web design methodology [7]. The refactorings in that catalog are intended to improve the usability of the final application derived from these models. In this article we stress the importance of characterizing refactorings by the design model to which they apply and by their specific intent. Our classification in navigation and presentation refactorings allows us to target the specific attributes of each model and the bad smells that may come up in them. We also generalize their mechanics to stereotyped UML diagrams. We found that, even when it is not clearly stated, there are some refactorings in the literature that are not intended to improve internal quality attributes: some database refactorings improve performance [4], and some HTML refactorings improve accessibility [5]. This shows a trend in software development to apply refactoring to improve external quality attributes. Following this trend, we have defined refactorings for Web application models that improve the usability of a Web application while keeping its content and functionality unchanged [7]. Let us first see an example. Figure 1 shows a comparison of two Facebook interfaces, illustrating a major redesign they did back in 2008. Many widgets have been moved around, but let us focus on the appearance of tabs to ease ...
Context 3
... the old interface ( Figure 1 left), the homepage of a given account showed personal information, list of friends, and a mini-feed of news about the account owner and her friends, among other things. This resulted in a homepage cluttered with information and links of different kinds, which required repeated page scrolling. In the newer interface (Figure 1 right), the homepage has been split-up in different pages and a new tab row allows navigation between them: one tab for the mini-feeds page, another for personal information, another for manipulating photos, etc. Focusing on this particular change, we can see that the basic behavior of the application is preserved: it still allows browsing the same information and accessing the same functionalities. However, the user will perceive a change in the graphical interface and navigation structure, which now balance the weight of the different kinds of information and provide some breathing room for each kind. We have catalogued this Web refactoring under the name “Split Page” [7]. We could discuss the mechanics of this refactoring at different levels. At the implementation or code level, it would amount to list every change in the source code in charge of building the homepage front end. For example, if we suppose that the site is based on HTML code, implementing this refactoring would entail the following actions: 1) create new HTML pages in which we want to split the original homepage and distribute into them the HTML code associated with the information, links, and widgets available in the original homepage. 2) add to each new page the HTML code to implement the tab row and the associated functionalities. These include: enabling navigation between the new pages; indicating the current page by distinguishing the active tab from the others; announcing the content of each page by using a meaningful label or icon for each tab. However, if the site uses a different technology, such as Flash or a Web application framework to generate the HTML pages, the mechanics will differ, in the same way as traditional code refactorings depend on the target language. This is one of the reasons that make it more appealing to discuss the mechanics at a model level, where they can be generalized as model refactorings on UML-like diagrams. Another reason is that Web design models provide a more abstract picture of the application and its different aspects, so that we can take informed decisions and synchronize the changes in the different design layers. For example, splitting a page may motivate splitting a table in the database that holds the content of that page. A third reason is that we believe that model driven development (MDD) is becoming a reality as more tools appear that can generate code from Web models (e.g. UWE4JSF - In this case the “new” HTML code would be derived automatically from the transformed ...
Context 4
... the old interface ( Figure 1 left), the homepage of a given account showed personal information, list of friends, and a mini-feed of news about the account owner and her friends, among other things. This resulted in a homepage cluttered with information and links of different kinds, which required repeated page scrolling. In the newer interface (Figure 1 right), the homepage has been split-up in different pages and a new tab row allows navigation between them: one tab for the mini-feeds page, another for personal information, another for manipulating photos, etc. Focusing on this particular change, we can see that the basic behavior of the application is preserved: it still allows browsing the same information and accessing the same functionalities. However, the user will perceive a change in the graphical interface and navigation structure, which now balance the weight of the different kinds of information and provide some breathing room for each kind. We have catalogued this Web refactoring under the name “Split Page” [7]. We could discuss the mechanics of this refactoring at different levels. At the implementation or code level, it would amount to list every change in the source code in charge of building the homepage front end. For example, if we suppose that the site is based on HTML code, implementing this refactoring would entail the following actions: 1) create new HTML pages in which we want to split the original homepage and distribute into them the HTML code associated with the information, links, and widgets available in the original homepage. 2) add to each new page the HTML code to implement the tab row and the associated functionalities. These include: enabling navigation between the new pages; indicating the current page by distinguishing the active tab from the others; announcing the content of each page by using a meaningful label or icon for each tab. However, if the site uses a different technology, such as Flash or a Web application framework to generate the HTML pages, the mechanics will differ, in the same way as traditional code refactorings depend on the target language. This is one of the reasons that make it more appealing to discuss the mechanics at a model level, where they can be generalized as model refactorings on UML-like diagrams. Another reason is that Web design models provide a more abstract picture of the application and its different aspects, so that we can take informed decisions and synchronize the changes in the different design layers. For example, splitting a page may motivate splitting a table in the database that holds the content of that page. A third reason is that we believe that model driven development (MDD) is becoming a reality as more tools appear that can generate code from Web models (e.g. UWE4JSF - In this case the “new” HTML code would be derived automatically from the transformed ...
Context 5
... us first see an example. Figure 1 shows a comparison of two Facebook interfaces, illustrating a major redesign they did back in 2008. Many widgets have been moved around, but let us focus on the appearance of tabs to ease navigation. ...
Context 6
... the old interface (Figure 1 left), the homepage of a given account showed personal information, list of friends, and a mini-feed of news about the account owner and her friends, among other things. This resulted in a homepage cluttered with information and links of different kinds, which required repeated page scrolling. ...
Context 7
... resulted in a homepage cluttered with information and links of different kinds, which required repeated page scrolling. In the newer interface (Figure 1 right), the homepage has been split-up in different pages and a new tab row allows navigation between them: one tab for the mini-feeds page, another for personal information, another for manipulating photos, etc. Focusing on this particular change, we can see that the basic behavior of the application is preserved: it still allows browsing the same information and accessing the same functionalities. However, the user will perceive a change in the graphical interface and navigation structure, which now balance the weight of the different kinds of information and provide some breathing room for each kind. ...
Context 8
... the navigation and presentation models can be represented with stereotyped UML class diagrams [8]. Figure 2 shows simplified versions of a navigation diagram (left) and a presentation diagram (right) for the application presented in Section 2. Classes in the navigation diagram represent nodes or indexes, and classes in the presentation diagram represent pages. For space reasons we have omitted attributes of navigation classes and show a single presentation class corresponding to the "Wall" tab (see Figure 1). Attributes of a presentation class appear in stereotyped boxes where, for example, an "anchored collection" represents a list of anchors for links, mapping an index. ...
Similar publications
![Figure 2: Oriented SHEL process for defining requirements [2]](profile/Rachida-Djouab/publication/224280066/figure/fig1/AS:302782868410368@1449200469079/Oriented-SHEL-process-for-defining-requirements-2_Q320.jpg)
It is known in the industry that software quality requirements engineering is still an immature discipline since its absence results in dissatisfied users and costly applications. The identification and specification of software quality requirements from system and user requirements is becoming a prominent task in software engineering. The lack of...
Citations
... To identify this type of UXDebt, we propose the concept of UX smells, which are hints of poor interface and interaction design that may be solved by applying UX refactoring (Gardey et al., 2020;Grigera et al., 2017). In turn, UX refactorings have been defined as changes to the navigation, presentation, or interaction of a web application that preserve functionality Garrido et al., 2011). Having concrete solutions in terms of UX refactorings makes UX smells an operational concept that may serve to identify, measure, and prioritize a technical form of UXDebt that appears in ITSs. ...
The metaphor of technical debt (TD) has generated a conceptual framework on factors that weaken the quality of software and accumulate a repair cost. However, user-related aspects like user experience (UX) receive little consideration among TD types, for reasons like the substantial focus on code TD, some dynamics inherent to agile processes, and an apparent lack of cumulative cost over time. This article has two main goals: first, to present evidence of the existence of UXDebt as a type of TD, with a cumulative cost for the development team as well as stakeholders; second, to propose a definition and characterization of UXDebt that may serve as a frame for further research on methods and tools for continuous management within agile processes. For the first goal, we have compiled evidence on the current state of UXDebt from three sources: a literature review, a survey among software engineering professionals in agile teams, and the analysis of UX issues in GitHub. All sources have evidenced some form of UXDebt; surveyed practitioners have recognized its poor management with a cost for the entire team that accumulates over time. Moreover, issue tracking systems allow to visualize and measure a technical form of UXDebt. For the second goal, we have defined a conceptual model that characterizes UXDebt in terms of both technical and non-technical aspects. On the technical side, we propose the notion of UX smells which allows us to discuss concrete management activities.
... The web refactoring approach [12] proposes the use of the refactoring technique, originally defined as changes that improve internal quality of software [11], to also identify changes that improve external quality factors like usability or accessibility [14]. Particularly, problematic patterns of user interaction have been catalogued as Usability Smells, which can be automatically detected while real users navigate a web application [15] or perform user tests [19]. ...
Automatic detection of accessibility problems is mainly performed by checking for compliance with guidelines on the HTML structure of web pages. While this method can find many problems, it has limitations in detecting difficulties that occur during user interaction. The purpose of this work is to find problematic sequences of interaction events, which we call Accessibility Events. These events occur dynamically as the user interacts with the page and can result in automatic detection of accessibility problems, called Accessibility Smells. We focus on visually impaired users interacting with the web through screen readers. Using previously and recently defined Accessibility Smells, we design Accessibility Events and heuristics to detect them. We describe an empirical study with visually impaired users accessing different pages with known Accessibility Smells. Using a logging tool, we capture Accessibility Events and report on their relationship (or lack thereof) with those smells. For the study, we recruited 8 volunteers, who performed user tests in different websites. During the study, we automatically captured the events on the interfaces and found that out of the 100 events detected during the sessions, 64 resulted in accessibility odors and 19 did not. The remaining 17 were inconclusive, but helped to reformulate the current odor heuristics to analyze potential new ones. The results indicate that it is possible to characterize special patterns of Accessibility Events that may be used to detect potential accessibility issues. While further studies are necessary, our findings provide a base ground for the dynamic detection of accessibility problems in web applications.
... However, adequate research is needed to support this assumption. Developers must understand the principles of usability before implementing them on the web (Affandy et al., 2020;Djordjevic, 2017;Garrido et al., 2011). Usability is a quality attribute that assesses the ease of use of the user interface. ...
Knowledge of English is very important nowadays. in the world of education, a teacher must be creative in choosing teaching materials. Therefore, this must be supported by the skills of the teacher and the suitability of the media in teaching. The purpose of this research is to find out whether the use of the learning house application can make it easier for teachers and increase students' interest. Rumah Belajar portal is a medium that can help teachers and students in the teaching and learning processThe data collection technique in this study is the process of collecting and processing information to evaluate results and use them for research. The research sample consisted of 20 students from eight grade. The results of the analysis The application of English learning material sources from the Rumah Belajar portal is very helpful for teachers in teaching English at SMP Satap 8 Baraka. This can be seen from the results of observations and interviews. The observation results show that teachers are successful in their performance to present their material, have a good influence on influencing students to follow their instructions, create good communication during sharing time, and make the class active. In addition, the results of the interviews showed that the teacher gave positive comments on the implementation of English subject matter sourced from The Rumah Belajar portal.
... The approach is based on the refactoring notion applied to external quality factors, like usability [6] or accessibility [9]. We build on the concept of "bad smell" from the refactoring jargon and characterize usability problems as "usability smells", i.e., signs of poor design in usability with known solutions in terms of usability refactorings [10]. ...
Different research fields related to the web require detecting similarity between DOM elements. In the field of information extraction, many approaches emerged to extract structured data from web documents, most of which require comparing sample documents to extract their underlying structure. Other fields of applicability like web augmentation or transcoding also require analyzing structural similarity, but on UI components with smaller structures than full documents, making them unsuitable for the algorithms generally used in information extraction. Instead, these approaches tend to rely on the DOM elements’ location, but this does not resist structural changes in the document, and cannot locate similar elements placed in different positions. In this paper we present two flexible algorithms to measure similarity between DOM elements by using a mixed approach that considers both elements’ location and inner structure, together with a wrapper induction technique. We evaluated our algorithms with respect to other known approaches in the literature by comparing how they cluster a dataset of 1200+ DOM elements, using a manual clustering as ground truth. Results show that both proposed algorithms outperform all baseline ones. The proposed algorithms run in linear time, so they are faster than most approaches that analyze structural similarity.
... To identify this type of UXDebt we propose the concept of UX smells, which are hints of poor interface and interaction design that may be solved by applying UX refactoring (Gardey et al., 2020;Grigera et al., 2017). In turn, UX refactorings have been de ned as changes to the navigation, presentation, or interaction of a web application that preserve functionality (Garrido et al., , 2011. Having concrete solutions in terms of UX refactorings makes UX smells an operational concept that may serve to identify, measure, and prioritize a technical form of UXDebt that appears in ITSs. ...
The metaphor of Technical Debt (TD) has generated a conceptual framework on factors that weaken the quality of software and accumulate a repair cost. However, user-related aspects like user experience (UX) receive little consideration among TD types, for reasons like the substantial focus on code TD, some dynamics inherent to agile processes, and an apparent lack of cumulative cost over time. This article has two main goals: first, to present evidence of the existence of UXDebt as a type of TD, with a cumulative cost for the development team as well as stakeholders; second, to propose a definition and characterization of UXDebt that may serve as a frame for further research on methods and tools for continuous management within agile processes. For the first goal, we have compiled evidence on the current state of UXDebt from three sources: a literature review, a survey among software engineering professionals in agile teams, and the analysis of UX issues in GitHub. All sources have evidenced some form of UXDebt; surveyed practitioners have recognized its poor management with a cost for the entire team that accumulates over time. Moreover, issue-tracking systems allow to visualize and measure a technical form of UXDebt. For the second goal, we have defined a conceptual model that characterizes UXDebt in terms of both technical and non-technical aspects. On the technical side, we propose the notion of UX smells which allows us to discuss concrete management activities.
... This is particularly relevant when different variations of a design are proposed, for example in the context of A/B testing (Speicher et al., 2014; or in the context of UX refactoring . Similar to the concept of code refactoring, UX refactoring applies small transformations to the user interface (UI) that preserve functionality, but in this case the purpose is to improve UX rather than internal code quality Garrido et al., 2011). ...
... In our previous work, as mentioned in the Introduction, we have studied user interaction within small portions of web pages, and proposed transformations to these small portions to improve external qualities of a web application while preserving functionality. That is, we have proposed the application of the refactoring concept, traditionally focused on internal code qualities (Fowler et al., 1999), to the improvement of usability (Garrido et al., 2011), accessibility (Garrido et al., 2014) and UX . UX refactorings, in line with the definition of UX previously introduced, include usability and accessibility refactorings (transformations to improve instrumental aspects) and also account for improvement of hedonic aspects . ...
The product of good design should render a tool invisible for a user who is executing a task. Unfortunately, web applications are often far from invisible to users, who struggle with poor design of websites and processes in them. We are particularly interested in web processes that involve form filling, so we have been studying how people interact with web forms. Besides cataloguing user interaction problems that are common in web forms, we have noticed that, in many cases, there is a single form element or widget to blame for a certain interaction problem, because such widget is not the most appropriate one for the required input in that particular context. This unfitness of the widget causes an extra burden to the user, which we call interaction effort. In this work we propose measuring the interaction effort of a widget with a unified score based on micro-measures automatically captured from interaction logs. We present the micro-measures that were found relevant to predict the interaction effort in 6 different types of web forms widgets. We describe a large data collection process and prediction models, showing that it is indeed possible to automatically predict a widget interaction effort score by learning from expert human ratings. We consequently believe that the interaction effort could be used as an effective metric to compare small variations in a design in terms of user experience.
... In particular, evaluators are supported in discovering UX smells in the pages of their websites. The term "UX smell" extends the notions of usability smells, which are defined as indicators of software interface aspects of low usability that may hamper users in correctly accomplishing tasks [8]. UX smell revolves around those aspects that mainly characterize UX, like users' emotions. ...
This demo presents SERENE, a Web platform for the UX semi-automatic evaluation of websites. It exploits Artificial Intelligence to predict visitors’ emotions starting from their interaction logs. The predicted emotions are shown by interactive heatmaps overlapped to the webpage to be analyzed. The concentration of negative emotions in a specific area of the webpage can help the UX experts identify UX problems.
... In addition, it is still difficult for an evaluator to identify which of the recommendations existing in the literature address a particular usability problem that appears on MUI. One of the most popular techniques to improve the usability of web applications is refactoring, which consists of inserting transformations to presentation or navigation of a web application with the aim of enhancing its usability by preserving its expected functionalities [4]. However, in the literature, the majority of existing studies [5,6] suggested manual or semi-automated refactoring recommendations that can be applied to fix a given type of smells without taking into account the riskiest usability smells to fix. ...
... Long navigation path smell means that the interface contains a long list of menu options. This may make the user disappointed and dissatisfied because he takes more time to search his preferred option [4]. ...
... Excessive detail smell is to display many details when reporting an error message for the users such as the reasons for this error, their nature and the recommendations of how to solve that error. However, most of these details are generally unnecessary [4]. ...
Usability is crucial for mobile app success. Usability evaluation and correction of Mobile User Interface (MUI) is fundamental phase to discover the usability smells and improve its quality. However, it continues to be a hard, expensive, and generally it is ignored. Several existing works depend on a subjective assessment of usability defects which relies on users’ feedback, that leads to time-consuming, human-centric, and error-prone task. Hence, recent works proposed tools for collection and analysis log user interaction when using the mobile application to understand user behavior and identify usability smells. But, these tools treat the defects with the same importance and rarely propose recommendations to help evaluator to improve their MUIs. It still also needed to identify concrete usability defects and fixed riskiest usability smells. In addition, most existing methods proposed to assess the usability of once the applications has been developed, which led to a lot of reworking by the designer because these changes can affect the development phases.In this paper, we propose an automated approach based on correction rules which combine literature evaluation metrics with usability smells to define recommended refactoring of MUI.To this end, we consider this refactoring recommendation as a multi-objective optimization problem. The purpose of this optimization is to maximize the number of refactoring per individual while minimizing the number of features per rule, the number of rules by solution, the misclassification rate, the information gain and improving the MUI quality in terms of guidance and cohesion coverage and minimizing the complexity of MUI. Moreover, we leaded a comparative study of four evolutionary algorithms to solve this optimization problem. The results prove the efficiency of the IBEA in terms of generating the most accurate refactoring rules with an average of 0.92 of AUC.This paper applied an evolutionary algorithm to recommend the best refactoring operations to enhance the quality of MUI. The results are promising. Our search-based algorithm successfully searches the best trade-off between eight objectives and recommending the most accurate refactoring rules compared with other studied algorithms.
... Since these usability smells are mostly circumscribed to one or a few elements of a webpage, it becomes easier to find concrete solutions in terms of transformations to those few elements. These transformations are called usability refactorings (Garrido et al., 2011), and are inspired in code refactorings (Fowler et al., 1999), i.e., transformations that improve quality and preserve functionality. Having the transformations be small allows for more manageable and safe changes. ...
The product of good design should render a tool invisible for a user who is executing a task. Unfortunately, web applications are often far from invisible to users, who struggle with poor design of websites and processes in them. We are particularly interested in web processes that involve form filling, so we have been studying how people interact with web forms. Besides cataloguing user interaction problems that are common in web forms, we have noticed that, in many cases, there is a single form element or widget to blame for a certain interaction problem, because such widget is not the most appropriate one for the required input in that particular context. This unfitness of the widget causes an extra burden to the user, which we call interaction effort. In this work we propose measuring the interaction effort of a widget with a unified score based on micro-measures automatically captured from interaction logs. We present the micro-measures that were found relevant to predict the interaction effort in 6 different types of web forms widgets. We describe a large data collection process and prediction models, showing that it is indeed possible to automatically predict a widget interaction effort score by learning from expert human ratings. We consequently believe that the interaction effort could be used as an effective metric to compare small variations in a design in terms of user experience.
... Therefore, the quality of the organization's website influences results. There is one way to distinguish between the work of a company and the work of other companies is to have a distinctive website following the standards adopted in building websites [3], [4]. The main issue is the measuring and evaluation of websites have to be speedy as possible. ...
Conventional usability measurement methods for measuring web applications are costly, sometimes time-consuming, and may require professionals. The frameworks, methods, approaches, and tools in which web applications are designed can fully support these limitations. The main issue is to speed up the evaluation process of websites in an effortless manner. To overcome this limitation, this paper proposes an instrument that can use for measuring the usability of web applications (IMUW-APP). A systematic literature review was utilized to determine the instrument dimensions and their items. The validity and reliability test were conducted via face and content validity, goodness testing, and pilot study. Cronbach's Alpha, factor loading, Kaiser-Meyer-Olkin, and Barlett's test were +calculated to ensure the validity and reliability of the proposed instrument. In the light of our analyses, the obtained findings indicate that the proposed instrument (IMUWAPP) is workable and can adapt. Besides, a case study is used to verify the proposed instrument to evaluate a university website. The collecting data have been analyzed and visualized. Ultimately, the overall findings have highlighted.
