Social Software to the Benefit of the Elderly – Planning an Experiment

After an investigation on consumer thinking and behaviour with specific focus on adopting advanced technology by the elderly, we are proposing an experiment to evaluate the findings achieved so far. The plan involves designing and implementation of a new prototype social software with certain unique functions. Statistical research conducted with the help of the proposed software will involve collection of both soft data, such as experiences and opinions of application users collected in their natural settings within the software, and hard data consisting of statistics about usage of the software, such as interactions with other users. The data will be matched and compared in order to evaluate three hypotheses about the process of a technology evaluation. The paper is presenting a research-in-progress. Among the goals of the paper is to raise awareness of the specifics of developing a software with inexperienced elderly users on mind, and also to get a feedback regarding the outlined application and the intended experiments.


Introduction
We were able to examine consumer thinking, behaviour and the forces behind, with specific focus on adopting advanced technology by the elderly [12] and to propose various models aimed to describe the reasoning behind, such as the model of acceptance [13] and model of appropriation [14]. One of our current goals is to evaluate our findings with a practical experiment using social software. First we evaluated existing social software, such as Facebook, Instagram and other rather niche systems. Because no existing social software meets the requirements on functions, user interface and usability in general, resulting from our research, several options were considered -such as to develop just a personalization façade or integrate more social software systems. But finally, we decided to transform our findings into a new prototype.
users aware of daily life of their close friends and family, provide them with feelings of closeness, ambient intimacy and affective awareness. The goal is to focus on relationships which already exist first, rather than building any new. The application should help to surrogate or re-establish natural social structures disrupted by distance, current pace of life, or by dehumanizing technology. Autonomy with anticipated support: The application should help users to keep their autonomy, but enable close friends and the family to provide valuable and meaningful support e.g. with remembering daily routines, scheduled events, etc. The feeling of closeness should likely lead to a higher level of positively perceived emotional and anticipated support, not making the user feel unnecessary dependent. The application might be able to help its user to free his family and close friends from worries, e.g. if the user follows routines prescribed by a physician. The application should make its users feel, that it is under their control.
Feeling of being competent: The application should also help its users, to be competent within a local community and friends, including those of the same generation. Users should not be forced to pretend higher competences than they actually possess, but they should be able to exploit the abilities they have. The user interface should not be based on confusing metaphors, should not be excessively changing its layout, functions should be precisely defined, control elements should be connected with the functions in an understandable, stable and intuitive way. Feeling of competence could be further supported by higher adaptability and intelligent customization, but still keeping it as simple and usable, as possible.
Feeling of helpfulness and self-worth: The application should make its users feel helpful and important for their close, not necessary bringing new ways they support their close, but leveraging the actual ways e.g. via better communication. Users should also feel, that, they can influence others e.g. by sharing their opinions and comments, memories, experiences or even expertise.
The following sections briefly describe the architecture, main functions, and user interface of the indented system.

4
Architecture of the Prototype System The system will be of three-tier architecture with a thick back end, providing most logic, and data stored in a database. The server part of the system will be developed mainly in Python language, which is suitable for rapid application development and easy prototyping. Server part of the application will be provided with a web interface for the purpose of management and configuration. Mainly for presentation and persistence, Python-based web2py application framework will be used. As we consider the elderly our primary users, the main client part of the system should be adjusted to their needs. Various studies such as [1,5,8] suggest that for the elderly who are lacking previous experience with electronic devices, it is easier to operate a tactile device, such as a tablet, rather than a computer. Because the display has to be big enough to serve well people with either visual or touch impairments, we decided to create the main client as an application for Android-based tablets. The native Android application has been chosen instead of a web application, because it allows better integration with the functions of the device, such as seamless support for touch-screen, offline mode, etc. To make it even more tightly integrated with the operating system and to provide even more coherent user experience, the application might be transformed into an android launcher application some day in the future.
A different associated client application, also created for the Android platform, will be aimed on members of the social circle of the primary user, such as his family members or friends. Different set of requirements applies there.

Main Functions of the Prototype System
A central concept of the suggested system is a content feed. The content feed allows the main client application to display a media element, either a picture, a short video, audio, a text or a combination (such as an article with a text and a picture) in a consistent way, one at a time. The user is given means to display the next provided content item and to move backward in the history. In this simplest setting, a new user is not required to learn any other functions besides moving forward and backward in the content provided by the feed. Usually, the first content pushed by the system to a feed of a new user, provides instructions how to use the basic functions of the application.
The set of functions available to the user (and the relevant user interface) is adaptive. New functions are gradually being enabled/added to the set of functions available to the user, as he gains more experience. In order to decide when to offer a new function to the user, the relevant algorithm will carefully assess the previous learning curve of the user. The goal is to avoid cognitive overload on the side of the user, but to provide an exciting experience with explorative feeling. Always when the system decides to offer a new function, the user has an option to either accept or reject the offer. If he grants the system to enable a new function, instructions on how to use the new functions will be provided in the content feed.
Feedback function is one of the first functions offered to the user. It allows him to rate the content displayed, in terms such as like/dislike. The feedback helps the algorithm on the backend side to adjust the contents of user's feed.
Regarding the sources of content, the backend side may combine various public online content providers, such as online encyclopaedia, news feeds, etc. with content created by users in his social circle, such as family members and close friends. The content from the circle members may originate either in the associated application. It happens either as a result of an action of its user, such as if a family member of a senior sends a picture or a text message. The associated application may trigger creation of a such content on its own, e.g. based on location of the device.
The backend part of the system may further process the received data. E.g. if it gets and information, that a member of a circle of one of the registered users changed its location, the algorithm may pull a relevant map and a weather data from the location and create a content item, which is pushed into the relevant content feed. So, the elderly user of the main client application gets an exciting content about his family members or friends, providing a feeling of connectedness, even if they did not initiate it. Further, the back end may be connected to other popular social network systems through specific connectors, so whenever a circle member posts on a Facebook, Twitter or Instagram, the elderly user of the main client application gets the content as well.
Though the content feed combines data from various sources, they are all transformed in a form, which allows to have them displayed in a coherent way in the main client application.
As the user of the main client gains more experience, more functions may become suitable for him, such as creating his own content (a picture taken using a camera, composed message, recorded audio). The content may be processed on the back end in various ways, such as to be displayed in the associated client, sent as an e-mail, or published as a Facebook post.
Items a user likes may be listed in his personal library, in order to make them easily accessible. Further, user may be given means to comment a content to provide a feedback beyond simply liking/disliking. Any feedback of a user may be used both as an input for the algorithm responsible for the contents of user's feed, and shared with his social circle in various ways. So, by these means, advanced users are able to interact with others. More functions might be considered, such as a calendar and/or reminder. But any such an extra function should be offered at a time, when it is very much sure, that the user managed all the core function perfectly. For this, the application has to collect information about user's interaction with the application and search for patterns of behaviour which might indicate confusion.
Though a fully-fledged social software should have a well-thought-of and precisely crafted security and trust model, the suggested prototype system won't need it, because it won't be dealing with big numbers of users and it won't be open for registrations beyond the testing circle of persons. However, our plan is to accommodate functions and interface of the system to the principles of a community of trust described in some of our earlier papers [15]. While in other models, a functionality regarding trust primarily assists to distinguish who deserves user's trust and who does not, in the community of trust all users trust each other as default, so the model fulfils rather different purposespromotes good activity, discourages from inappropriate behaviour and helps to keep the community clean. There is no need to "rate" fellow users for common interactions. Trust matters should be unobtrusive, doing their work beneath the surface and just giving users means to act, if something goes wrong. In the prototype application security, will be accomplished by following common principles of safe software and allowing only users whose trustworthiness has been granted out of the scope of the system, to get in.

6
User Interface of the Prototype System As mentioned earlier, the main client application is meant for a touchscreen device with reasonably sized display, such as tablet. The layout should respect the following principles.
Static: Logical parts of the layout, such as the content, buttons, notifications, should keep their position as much as possible. Contextual changes of the UI layout should be limited as much as possible. Hidden parts which appear as a result of user's action, such as context menus, menus sliding from sides of the screen, etc. should be avoided. In the case a software keyboard is needed, its (dis)appearance should be well-thought-of to avoid confusion. Layout should not have to accommodate to different types of content, rather any kind of content should accommodate to the layout.
Coherent: The layout should be clear. Buttons and any other active parts of the layout should be easily recognizable by the consistent style, colour, label, etc. Coherent means also memorable. E.g. use colours to help users to remember ("red stands for voice recording, blue for writing").
Accessible: Should work well for people with various impairments. E.g. touch gestures should be rather avoided, because even a simple slide may confuse beginners and cause troubles to users with tremor or touch impairments. Accessible means also legible, to respect people with visual sensory impairment. The requirement may help to determine minimal font size, distances, etc. The accessibility parameters of the user interface may be even adjusted by the system, based on the feedback from the user.
Expansive: Often it has been recommended to make user interfaces concise. Rather than concise, the interface should be well-explained and "foolproof". Pictograms (icons) should be easy-to-understand even for total beginners, and used with caution. Textual explanation of functions, buttons, etc. should be always provided, at least for beginners. Graphical wizard might be a good concept for the purpose. Wizard guides user step-by-step to perform his action, typically in series of questions. E.g. in order to share or send a media to others, user might be required to click "interested" button first, since only an item a user is interested is likely to be intended for sending. Then a dialogue appears asking questions such as "Would you like to share the item to someone?", "Would you like to share it with your family?", "Would you like to share it to others?", etc. Similarly, to create content, rather than providing several buttons for various content types, user will click "create an item", than the system will ask the user series of questions about the content type and purpose.
Familiar: Familiar does not mean the same as for a user interface aimed on regular users of electronic devices. Concepts such as menus, sliders, windows, etc. are not familiar for the target user group. Different familiar concepts, such as a telephone, printed news, picture frame, display board, could be considered and examined.
Responsive: It means couple of things. First, the interface should work fast. This is one of the reasons why the application is designed rather as a think client and main logic should be executed on the server side, so the performance of the client device won't affect the behaviour of the application in a great degree. The application may add to the responsiveness e.g. by utilizing a cache and a buffer for the content loaded from user's feed. The interface should also provide sufficient feedback to the user to inform him what is going on. The interface should also accommodate neatly and seamlessly to different resolutions of target devices and to their portrait/landscape orientation.
Forgiving: There should always be an easy way back, to undo an unwanted action or to return to a default state.

Intended experiments
Though a substantive amount of work has been done to identify the needs of the elderly, to formalize them and put them in the context of current available technology, such as social software, or products of ambient intelligence, we based our conclusions mainly on third-party data so far. No research specifically aiming the validation of the models of consumer behaviour has been performed. Further, our goal is to validate the theory on a prototype of a real product. In order to fill-up the missing gaps in our knowledge, we designed to perform an experiment, which will help us to asses, whether models of acceptance and appropriation harmonize with decisions of users and whether a prototype application, built according to the deep design principles, is significantly beneficial for the relevant target group.
The prototype application will be tested with groups consisting of about 5 participants. We are planning to involve both participants without any previous experience with smart electronic devices, and those who have limited experience. The concept of deep design has been formulated as culturally, socially, and economically neutral. So, in order to reduce a potential cultural bias of our research, we decided to invite participants with a different background, namely from the USA, Philippines, and the Czech Republic. The main reason why we decided to involve these distinct regions, is their significant cultural, social, and economic difference. The size of the testing groups has been decided in harmony with respected recommendations for usability testing which suggest, that increasing the size of a testing group above 5 does not substantially improve the amount of information collected [7]. Larger trial may follow any time later.
The prototype application itself will ask participants questions relevant to the research goals. Users will rate e.g. how they feel about the application, how they assess their ability to operate it, etc. Similar data collection method has been developed at Penn State University, it is called Dynamic Real-Time Ecological Ambulatory Methodologies (DREAM) and its purpose is to assess ongoing behavior, experiences, physiology, and environmental factors in people's natural settings [16]. Such a natural data collection approach eliminates the bias caused by the arbitrary setting in which questionnaires are typically filled-up. The collected "soft data" will be used for further analysis and for comparison with "hard data" about the usage of the application (frequencies of interactions, response times, etc.).
Regarding the support, we are planning to make detailed record about each support case which will occur during the trial, because the support is one of external forces, which may affect results of appropriation as well as the perception of the application by the trial participants. The impact of the support will be observed and discussed in the conclusion of the trial. In order to achieve the outlined goals, three hypotheses have been formulated:

Testing the Model of Acceptance
We will test the following hypotheses: Hypothesis H0: "Results of the model of acceptance [13] do not harmonize with decisions of users regarding the offer to participate on the application prototype trial".
Hypothesis H1: "There is no proof that results of the model of acceptance do not harmonize with decisions of users regarding the offer to participate on the application prototype trial".
Potential participant will be asked to assign weighs to the comfort sources recognized by the model (social touch, autonomy with anticipated support, feeling of being competent, feeling of helpfulness and self-worth). The purpose of the prototype application will be explained and briefly demonstrated to the potential participant and he will be asked to think whether to take part on the trial or not. His answer with any aired reasons will be recorded. If no reasons were provided, the participant will be asked to provide them. The participant will be asked to estimate, how the application might influence his comfort sources on a scale. Then he will be asked to estimate how much resources (time, effort, support) is he expecting to need to learn and use the application. He will be asked if he has anything more to say about the reasons for his decision regarding his participation on the trial. The fuzzy values provided in the questionnaire will be defuzzified on a scale and the model will be processed. The decision of the potential participant about the trial will be compared with the result of the model.

Testing the Model of Appropriation
We will test the following hypotheses: Hypothesis H0: "The results of the model of appropriation [14] do not harmonize with decisions of users regarding their continuation in the application prototype trial".
Hypothesis H1: "There is no proof that the results of the model of appropriation do not harmonize with decisions of users regarding their continuation in the application prototype trial".
At the beginning of the trial the participants will be asked to rate model entry values, namely the initial enthusiasm and initial qualms. Regularly, preferably with a daily frequency, participants will be asked directly by the prototype system to rate their disappointment, bore, mastering, perceived utility, and level of appropriation (with brief and clear definitions of the terms displayed within the form). At the end of the trial, the values provided by participants will be defuzzified. The model will be executed with the values collected. Levels of calculated variables as well as key moments in the model execution, such as rejection or appropriation, will be identified. The results of the model will be compared with the level of "appropriation" users were expressing. The results of the model will be further compared with the frequencies and characteristics of participant's actions within the systemhow many media elements the user shown each day, how many times he shared a content with others, how much content he created, etc. The goal is to check if there is any correlation between the activity and either perceived or calculated level of appropriation of the application.

Testing the Prototype Application
We will test the following hypotheses: Hypothesis H0: "The prototype application is not significantly beneficial for the trial participants".
Hypothesis H1: "There is no proof that the prototype application is not significantly beneficial for the trial participants".
At the beginning of the trial the users will be asked to answer set of questions regarding the subjectively felt levels of comfort sources (social touch, autonomy with anticipated support, feeling of being competent, feeling of helpfulness and selfworth). The same or similar questions will be asked at the end of the trial. The questionnaire will be followed with a dialogue, where the participants will be asked further questions about how they feel about the prototype program, about the content they could consume or share during the trial, how they think the program influenced the levels of comfort sources, etc. Answers from the two questionnaires (entryending) will be compared. Answers, both quantitative and narrative from the followup dialogue will be analysed. The results of different participants will be compared and discussed. Any of the hypotheses and the suggested procedures may be further adjusted, based on pre-trial preparation.

Conclusion
The paper summarized certain findings on the acceptance of advanced technologies by the elderly, based on our previous research. As a main contribution, a social software respecting the findings has been outlined. The proposal covers architecture of the system and main functions and user interface of the client application aimed on the elderly users. The principles considered in the application design may provide a vital inspiration to researchers in various fields, such as software usability, consumer behaviour, gerontology, or social networks. Besides them, software developers may understand better, which aspects to consider in order to prepare products, which might touch the deep needs of the elderly, while avoiding some of the traps, in which such projects may easily get caught. Finally, an early experiment using the software is introduced. The goal of the experiment is to validate our models of technology evaluation and the prototype application itself.