Keywords

1 Introduction

How can we support the development of age-appropriate system design? And how can the demographic change and steadily increasing percentage of older adults be used to create something meaningful for each individuum and for the society? The Historytelling project (HT) addresses these issues by developing a digital social platform for older adults to empower them in recording, visualizing and sharing their life stories. These stories are an anchor to strengthen the ties between different generations and to tie new ones. The research project relies on the strengths of older adults, giving them a voice in the development of the software and seeks positive impact on the societal, group and personal level (for an illustration see Fig. 1). On a personal level, HT offers possibilities for reminiscence, for biographical work and for stronger contact to one’s own history and other people. On a group level it can strengthen the ties of existing relationships with friends and family and help establish new ones. And on a societal level, HT offers the possibility to experience history from multiple perspectives and to pass on life experience and knowledge from generation to generation.

Fig. 1.
figure 1

Illustration of the three levels Historytelling addresses: personal, group and societal

Full size image

The core of the HT project is an interactive website, creating a digital network on which older adults can document their life stories, enrich them with multimedia content and embed them in a temporal and spatial context. Furthermore, story sharing is possible within a family and public space to help establish vivid interaction between users through the stories, providing a powerful trigger to write even more stories.

For the development of HT, the integration of potential users as participants is crucial. Participants should be integrated in the development process from early on and continuously in preferably all steps of the HCD process. HT uses the HCD+ framework [1], which in turn helps to improve this framework by adding new guidelines for the participatory development with and for older adults. HCD+ is an approach based on Human Centered Design (HCD), to develop information and communication technology for older adults and focuses on “user characteristics and their impact on the design process and results” [1].

1.1 First Development Steps

As stated above, the involvement of older adults throughout the development process is important for HT. Thus, 19 interviews with older adults were conducted already in the ideation phase of the project [1]. Preliminary results can be found in [2]. Interviews were analyzed using the User Centered Design Canvas developed by [3] based on the Business Model Canvas to visualize information about challenges and motives. A project plan was created based on these results, and the HT topic was further narrowed to specific features. This plan was used to simultaneously develop features in a component-based software engineering approach, first described by McIlroy [4]. Although the idea of component-based system engineering is not new, with the advent of (web-) technologies focusing heavily on this approach, it gets easier to reuse and test parts of the source code within different user interfaces, increasing the development speed, yet creating new usability challenges, especially regarding consistency [5,6,7].

Figure 2 shows resulting interface examples described in [8,9,10]. They show that there is little consistency among the interface elements, although the usability of each interface tested positively in isolation. Figure 3 emphasizes this fact in detail by displaying all different buttons of the HT interface. One approach to address these challenges and ensure consistency among interfaces is to establish an age-appropriate style guide.

Fig. 2.
figure 2

Example of HT interfaces prior to style guide development

Full size image
Fig. 3.
figure 3

Interface inventory of all buttons used in the various HT components

Full size image

1.2 Style Guides

User interface style guides are about as old as user interfaces themselves and were first introduced by Apple for the Macintosh, with IBM and Microsoft following shortly thereafter. The importance and benefits of these style guides were also discussed early on [11]. As Gale [11] stated, the objectives for style guides are to “promote visual and functional consistency within and between different applications”, “promote good design practice” and to “reinforce company branding or an organization’s public image”. Frost [12] and Debenham [13] define style guides as a clearly defined collection for documentation and organization of design materials to provide guidelines, practical application and guidance. In the literature, various motivations for using style guides are mentioned, among them:

  • Consistency and therefore efficiency [11, 14, 15]

  • Having a clear, tangible output [11]

  • Increased user participation in design [14]

  • Increased user acceptance [14]

  • Higher software development efficiency [14].

With the development and usage of style guides, there are potential pitfalls to consider. Occurring problems can be divided into two groups: “Problems with the contents of a style guide and problems with handling the document” [16]. Some potential problems and challenges regarding style guides are the following:

  • Shifting responsibility for design away from the programmers [11]

  • User interface and style guide complexity and quantity of guidelines [11, 15]

  • Low or no update frequency [11]

  • Development process and schedules [15]

  • Incorrectness and inconsistencies within the style guide [16]

  • Continuous appearance of new style guide tools [16]

  • Lacking style guide introduction within the organization [11]

  • Access [16].

Some of the problems only occur with offline or paper-based style guides and could be bypassed by using online open source style guides. Vogt [16] discusses some of these challenges in further detail. For example, regarding incorrectness and inconsistencies within the style guide he states that these are solvable intrinsic problems. Concerning the appearance of new tools, Vogt states that the development of new tools will not slow down in the future. Torres [15] sees a solution to the challenges of style guide usage and development in applying HCD principles. He stresses the importance of setting measurable goals, keeping users involved throughout the development process, appealing competitiveness, designing the whole user experience, designing with a multidisciplinary team and evaluating designs and design decisions. Gale [11] also proposes a collaborative approach to style guide development with the following five steps based on the involvement of developers and users throughout style guide creation: (1) “Raising awareness amongst developers and end users. (2) “Building consensus” (3) “Documenting the Style Guide” (4) “Providing training and support material” (5) “Establishing an environment which enables the guide to evolve”.

Also, Gale sees advantages in using enriched style guide. He argues that a style guide should not just be a document, but rather an “interactive demonstration to illustrate the look and feel”, using “reference tables for quick reference of critical data”, and provide source code to “promote sharing user interface code.”

Olsson and Gulliksen [14] promote the communication and involvement of users as an inherited feature of style guides. They built a hypertext based online accessible style guide with the capability to communicate opinions and ask questions. The advantage of this approach is, as Olsson and Gulliksen state, the easier maintainability and the possibility to perform revisions.

Looking at the “Website Style Guide Resources” by Anna Debenham [17], it is apparent that the usage of the term “style guide” is nearly extinct in today’s use. Instead, terms like “design system” or “pattern library” are used. One example is the carbon design system by IBM [18]. Often, these design systems contain not only design guidelines but also the company’s corporate identity. As Debenham [13] states, design systems are an umbrella term for design principles, design of language and tools. Pattern Libraries in contrast focus on the integration of elements and components into a website and address the needs of programmers and less the needs of designers.

For HT, style guides can help on two levels: (1) the consistency of the developed user interfaces and (2) the coordination and efficiency of student’s work on theses and other qualifications creating them. Students usually have little programming experience and work only briefly on the HT project due to the nature of qualification work. Therefore, there is little time for onboarding and first steps guidance is critical. Also, with a growing number of components, documentation and source code, the onboarding into the development and the maintainability of the project gets more difficult, impeding the goal of age-appropriate design.

1.3 Age-Appropriate Guidelines

With higher age, limitations in perception, cognition and motor control increase, which are relevant for using digital technology [19]. Also, socio-cultural factors and the acceptance of technology usage among generations and can influence or impair user behavior [20] and it is important to consider the diversity of older adults as a group, especially regarding their limitations, capabilities and experience with technology [19]. To avoid stigmatization, labeling user interfaces as ‘specific for older adults’ should be avoided [21].

Much has been written about age appropriate guidelines for older adults, mostly based on a combination of literature reviews, focus groups, interviews and user studies and concluding to list age-specific requirements [20,21,22,23,24,25]. Arch, Abou-Zhara and Henry [22] conducted a literature review based on 150 articles and observed some recurring patterns in user requirements. Information overload was one of the most common challenges, in particular the number of various items on one page, making it hard to focus on relevant information, the usage of advertisements and animated elements which were distracting, non-linear navigation through websites and inconsistency regarding layouts, navigation and interaction. The authors saw a lack of information in three areas: (1) Considering hearing loss and deafness. Although hearing loss was identified as age related, most of the literature did not include recommendations to address hearing limitations. (2) Assistive technology or adaptive strategies were rarely mentioned and thus guidelines regarding these technologies are seldom included. (3) Existing Web accessibility guidelines are mostly not acknowledged or discussed and thus many authors develop redundant recommendations.

2 Development

The implementation of the HT style guide is based on a preexisting CSS framework and uses the component-based approach of the underlying source code. There are many usable frameworks for different purposes. Typical examples for general purpose frameworks are for example Foundation, UI Kit, Semantic UI and Bootstrap [26]. CSS Frameworks have the benefit of providing predefined initial CSS rules, reusable layouts and UI elements, meeting a certain standard [27]. Also, they make differences between general and age specific style guides testable. The style guide developed for HT uses Bootstrap because of its high amount of predefined UI elements, which can be used first and then be adapted to age specific guidelines step by step. In analogy to the development of the underlying HCD+ approach, the adjusted Bootstrap framework will be called Bootstrap+.

2.1 Bootstrap

Bootstrap provides HTML, CSS and JavaScript patterns for layout, typography, forms, buttons, navigation and further user interface elements. These components can be extended and adjusted by using a CSS and JavaScript layer on top the framework. The current version is 4.2.1. Bootstrap describes itself as a CSS framework for “responsive, mobile-first projects on the web” and as “the world’s most popular front-end component library” [28]. It comes with good documentation, has an active community with 1059 contributors (as of February 2019) since 2011 and is the most starred CSS framework repository on github with over 130.000 stars. Originally, Bootstrap was developed and published 2011 by Twitter and is by their own account used by NASA, FIFA, Spotify and others.

2.2 Bootstrap+

Bootstrap+ consists of two components: the style guide documentation and the associated implementation (accessible via the node package manager npm named historytelling-styleguide [29]). The recommended way to include the style guide into a project is by installing it via npm. If a module bundler, such as webpack, is used inside a project, the provided SCSS preprocessor files can be included into the project and adapted if required. If no preprocessor is used, also a standard CSS file can be used inside a project. The loadable index file loads bootstrap, adjusted variables and the custom HT styles, such as colors. The second component of Bootstrap+ is the documentation, accessible at [30]. The various UI elements are divided into different categories according to Debenhams design system [13]: Components, Elements, Tokens (See Table 1 for an overview).

Table 1. Overview of the components, elements and tokens used within the style guide documentation
Full size table

Tokens define basic design bits such as color schemes, fonts and icons. Elements define stand-alone UI elements such as buttons, text areas and headings (See Fig. 4 for an example). Components define combinations of elements which should have one single purpose such as indicating the current login status (see Fig. 5 for an example). The implemented pages typically consist of various components. Each item consists of a heading, an explanation, a graphical representation of the element and copiable code. The documentation exists as a living style guide in an open github repository in which suggestions for improvement can be submitted by the issue tracker or pull requests.

Fig. 4.
figure 4

An example for an element. The element is described, visually represented and source code is provided

Full size image
Fig. 5.
figure 5

An example for a component. The component is described as well as other used components and elements and the component is visualized

Full size image

3 Empirical Evaluation

To evaluate the developed prototype with age appropriate adjustments, it was tested in an A/B-Test with the standard Bootstrap interface without age appropriation and without style guide adjustments vs. the adjusted interface simply called Bootstrap+, as has been suggested by Torres [15]: “A new style guide should be evaluated against predecessors competitive style guides, just as products are evaluated.” Below, this empirical evaluation is documented regarding participant recruitment, testing atmosphere and procedure as well as methods applied as described in the HCD+ approach [1].

3.1 Recruitment of Participants

Participants were recruited in two ways, one successful, one less so: at first, people were directly approached and asked for participation in spontaneous short interviews at the central train station. The aim was to quickly reach a high number of diverse participants, yet that approach failed leading to merely one participant. Thus, local residencies, care facilities and associations were contacted, based on established connections from previous projects as well as new internet search results. Most of the new care facilities and residential homes dismissed the request due to a stated lack of technology use by older residents. Ultimately, only one residential home with 9 participants and two local women’s associations (Frauenring Lübeck and Lübecker Landfrauen) with 9 and 12 participants could be recruited for the empirical evaluation of the prototype. Hence, a total of 31 mostly female (22 f; 9 m) older adults aged 51 to 93 years (M = 71, SD = 9) were interviewed. 74% of them indicated daily use of at least one ICT device such as computers, tablets or smartphones, 19% estimated a frequency of at least three times a week, and 6% declared that they do not own any of these devices. 15 participants used the Bootstrap interface and 16 the age-adjusted Bootstrap+.

3.2 Procedure and Atmosphere

To allow for a natural conversation between participants and interviewer, the survey was carried out in teams of two: one interviewer and one recording observer.

Interviews lasted 15 to 20 min and focused on participants solving six hypothetical tasks. These tasks confronted participants with different system processes, examining how well the system was perceived and understood. Tasks included the following functions: search and read a story, comment, register for the platform, create a story, publish a story and navigate.

All interviews but the one at the train station were held in well suited locations, such as a common room within the residential home, a university usability lab, an empty café and a private home – all of which allowed for a pleasant conversational atmosphere. In the residential home, interviews were conducted at an afternoon coffee gathering, leading to high noise level and some insecurities among the participants. Also, a number of residents interested in the project did not consider themselves capable enough for participation.

3.3 Methods

For the evaluation, an A/B between subjects design was chosen with an even split between Bootstrap (N = 15) and Bootstrap+ (N = 16) interfaces. A detailed evaluation sheet was used in which the recording observer categorized participants performance for each task, based on an adjusted evaluation scale presented by [31]. The performance on each task was rated as not solved, partly solved (e.g. with help) or completely solved (alone). The evaluation sheet combined quantitative and qualitative data, revealing common problems, misuses or other observations while at the same time including individual opinions and ideas of single participants. Results from the evaluation sheets were aggregated and analyzed in search for patterns or similarities in the distribution of code-frequencies. Qualitative data was aggregated and interpreted using content analysis [32]. Based on this analysis, specific problems and potentials for optimization of the adjusted Bootstrap+ interface were identified and integrated into the developed prototype of the style guide. See Fig. 6 for an exemplary comparison of both interfaces.

Fig. 6.
figure 6

Examples of interfaces used in the evaluation. Standard Bootstrap on the left and Bootstrap+ on the right.

Full size image

4 Results

The following section provides a description of the results from the collected data in regard to general demographic aspects of the participants, as well as relevant information on differences in participants performance between the two interface versions.

4.1 Quantitative Data

Findings indicate a higher task completion rate (effectiveness) across tasks for the adjusted Bootstrap+ version, see Table 2. Looking at individual tasks, Bootstrap+ showed higher task completion rates in all tasks but the third, concerning the registration process for the platform. Accordingly, there were more tasks solved with help or not solved at all with the unmodified Bootstrap interface.

Table 2. Comparing effectiveness (as task completion rate) for Bootstrap (N = 15) and Bootstrap+ (N = 16) interfaces across all tasks
Full size table

4.2 Qualitative Data

Qualitative data was summarized in task-specific categories and clustered into general themes. In general, they support the improved effectiveness of Bootstrap+, in detail a few findings for the tasks shall be described here as follows:

  • Task 1 (searching for stories), difficulties with Bootstrap found with the timeline, as the depiction of two beams (one selecting the year and the other the month) lead to confusion and misinterpretations

  • Task 2 (commenting), the emoji-bar was either not noticed or not understood in the Bootstrap interface, suggesting a better visualization in Bootstrap+, which still showed a lack of comprehension regarding the interactivity of the emoji-bar

  • Task 3 (registration), common problems across versions, e.g. with the displayed progress bar, understanding the presented information or general attitudes towards user registration

  • task 4 (story creation), difficulties with Bootstrap interface regarding text input for the story title and navigation through the process of story-creation, suggesting an improvement in Bootstrap+, which still showed problems with the temporal and spatial classification of stories

  • Task 5 (story completion) and 6 (navigation) again show common problems across versions that provide good starting points to improve the existing prototype (see Table 3).

    Table 3. Frequencies of participants’ difficulties with the style guide’s interface elements for Bootstrap (N = 15) and Bootstrap+ (N = 16) interfaces
    Full size table

Also, participants stated their demands for the interface and potential further development of the style guide and HT: Options to set restriction for stories’ visibility to others (6), Sharing stories via email (2), Uploading option for documents (1), Uploading option for externally created stories (1), Keyword integration (1), Freedom of not completing the story creation at once, option to review and revise (1), Enhanced community functionality (1).

5 Discussion

The goal of this paper was to show how the development of age-appropriate system design can be supported. In first iterations of HT, it became apparent that the component-based development process efficiently produces components with high usability scores, but lacks consistency across HT components. The development of a style guide helps to harmonize the development of HT and presents possibilities for other researchers and designers to implement age-appropriate software. Furthermore, new style guide approaches like Debenhams [13] with components, elements and tokens, work well within the component-based development approach of HT.

As Gale [11] stated, one of the reasons why style guides fail is a lack of updates. Thus, as Gale [11] and Torres [15] suggest, a collaborative approach for the development of the HT style guide was used. Also, the style guide has been implemented as a living online document, which can be easily shared and edited. Finally, there are special requirements for the development of HT: Since the nature of student’s qualification work brings about short collaboration times, fast onboarding with a short training period is essential for the success of new component development. On the other hand, the setting makes it easier to follow Gales suggestions [11]: (1) “Raising awareness amongst developers and end users” (2) “Building consensus” (3) “Documenting the Style Guide” (4) “Providing training and support material” (5) “Establishing an environment which enables the guide to evolve”. For the HT project, we were able to show that both components of the style guide, the documentation and the customized CSS source files, can help to improve the effectiveness measured as task completion rate.

6 Outlook and Future Work

Future development of HT will follow Bootstrap+ to maintain consistency across all components of the interface. Of course, there is still much room for improvement. Over time, new HT components will be developed, and new elements will be added to the HT style guide documentation and the source code to attain an ever more complete style guide for more general purposes. Also, for further development and establishing it will be crucial to formalize the organization and usage of it and parameters for goals and objectives have to be set as for example Kholmatova [33] states. To keep the style guide alive, new functionality will be added to it, such as a feedback loop for developers and an option to edit content without editing the source code.