Preliminary Feedback

The site was initially deployed locally within the Dependable Socio-Technical Systems research group in the Computer Science Department. Over a period of several weeks, users were encouraged to experiment with the different features of the system and to actively participate in its use. They were encouraged to use it to document what they were working on and to open up or continue discussions with other members of the group. If any bugs were spotted they were reported through the system by tagging a blog post with the keywords bug and Elgg. These were regularly checked for and prioritised, based on the development time required to fix them and

how often they would be encountered. The proximity of the users’ offices to that of the system administrator and the regular meetings held by the research group meant it was easy to get in contact and discuss any problems they were having and clarify any areas that were causing confusion.

After this initial period of use, semi-structured interviews were carried out to identify any key issues with the system that needed addressing before opening it up to a larger user base. From these it was clear that there were areas where improvements could be made to make the site more usable and guide future users.

In the interviews, several users raised issues regarding aspects of the interface they found confusing including the inappropriate labelling of certain sections and the variety of controls being used. While it is recognised that there are a large number of controls used and that their use is sometimes inconsistent, most public social network sites use similar ideas. Although it may not be entirely intuitive, after a short period of use you become familiar with the layout. One user commented that although it may not follow good HCI principles, most interfaces don’t and described the interface as ‘quirky but usable’. Using the feedback from these interviews, any confusing names were changed to ones that gave an indication of their functionality in a hope that this would improve the site’s usability.

After the site had only been in use for a few weeks, the amount of experimentation with the different features seemed to quickly slow down. This, however, is a phenomenon observed in the introduction of most new systems [31] and the introduction of new features can often help increase it again. It was decided that this was not a major problem, as the primary benefits that can be gained from the use of the social network system come from its basic features.

Related to the lack of experimentation was a lack of awareness of certain features of the site. In the user documentation, the decision was taken to focus on the basic features that were needed to get started and allow users to experiment with the others if they desired. This meant that sometimes potentially useful features such as the ability to organise files into a hierarchy and the use of widgets were missed. Others, which they were aware of such as the calendar plug-in that it was thought would be

useful, were ignored due to issues in their usability. RSS was also seen as a potentially useful feature. However, guidelines were needed to make users aware of how it works and the benefits it could bring. It was decided that users should be made aware of some of the site’s more advanced features and these were posted on the ‘Getting Started with Elgg’ community, which was designed to help users with how to use the site.

One of the main issues that came out of the interviews was that users were unsure of when to use which feature and that this had led to inconsistencies. Although this may not cause problems with a small user group, it may be more problematic when opened up to larger numbers. The idea of the test period was to allow users to experiment and it was hoped that in doing this best practices would become clear. This, however, did not happen with most finding their own individual ways of working. The main issue was when community spaces should be used, as opposed to individual ones. As it was decided that some guidelines for use were necessary, decisions were made in discussion with some of the current users as to when each sections’ use would be most beneficial. Guidelines were then produced and posted on the site in the ‘Getting Started with Elgg’ community and circulated via email. Some users also commented that it was hard to determine when to use email as opposed to the site. It was decided to leave this to the discretion of the users in the hope that norms would develop over time.

As with many social network sites, the term used to connect to other users is ‘friend’. Some users commented that this was not reflective of the connections they were making and that it might be a little too informal for use in a work setting. While this point was recognised, during discussions it was difficult to find a term that reflected the variety of connections being made so it was decided to keep ‘friend’ until a better option could be found.

The use of the tag cloud also caused problems, with some users being unfamiliar with the idea of tagging. One of the problems was the use of similar tags meaning the same thing, for example the use of plurals. By allowing users to select tags from tag cloud as well as creating new ones it was hoped this would be reduced. As the amount of content on the site increased the size of the tag cloud grew and this made it

virtually unusable. It was suggested that it be made domain-specific in the hope that this would make the more relevant tags easier to find. This change was implemented. The limited search capabilities of the site were also discussed and, although requests were made for a more complex full text search, the development time for this was deemed too great. Instead the search functionality was extended to allow a combination of tags to be included using basic Boolean expressions.

Most users simply adopted the default access restriction of ‘logged in users’. This was not seen as a problem as very little confidential information was being shared on the site. If the site were to be opened up to the public at a later date, it may become more of a concern. Past research into the use of access controls on private social networks such as Beehive has suggested that they are adopted much less often than in public sites as people want to share and gain feedback and are aware that the access is already restricted[122].

Overall users seemed to feel that the main issue with the site was simply one of adapting their work practices and adjusting the way they think to incorporate the site’s use. The lack of a hierarchy also takes some time to adapt to, with the site being used by professors, post doctoral researchers and PhD students. Everyone, however, agreed that it had made threaded discussions much more efficient and that it could develop to be extremely useful for sharing information with the different sites across the project.