User Interactions

Hi all. Apologies for being quiet over the last few weeks, we’ve been preparing for our Beta test. This has been a challenging 4 weeks trying to  reach each phase of the process. The focus now is on refining every aspect of the app to maximize functionality and usability. Unsurprisingly, our interaction strategy has been integral to this this.

As referenced in earlier posts, we began our UX process back in February. Being integral and paramount to the design process, it was a key part of our workload from the beginning. Having progressed from testing users with paper prototypes in February to finished artworks prototypes in August, September quickly became overwhelmed with creating our MVP.

Our MVP focused on the two main functions of our app: searching and uploading. With the first drafts of code complete we were able to glean a clearer understanding of how these processes would benefit our user.

Today,  we will discuss our search interactions with you.

Filtering & Searching

Users found that our initial search screen wasn’t descriptive enough. At the time, they chose a category from the selector (people, places, groups, artefacts, events), entered their query into a search field and the database suggested results from each corresponding table. Users less familiar with mobile apps and the web were confused by this and wanted a more straightforward option. They essentially wanted to land on the page and immediately see the five categories as buttons: people, places, groups, artefacts and events. As such a large chunk of our target market don’t frequently use apps, we took this on board in refining our strategy.

 

 

Our next attempt was a filtering system. The user was presented with all of the data when arriving in the app and used filter buttons (people, places, groups, artefacts, events) to refine the data down. The chosen tags are then appending in a secondary bar so that user can, both, see what they’ve searched and remove unwanted search parameters.

 

 

Our target market were very happy with this and all responses to our earlier user tests were positive. However, upon our recent beta testing we’ve expanded to more tech savvy users. They have found themselves confused by the filter bar, believing it to be a navigation bar. This is because the solution just isn’t common place in apps and they don’t expect it to be there.

We are now developing a filter bar that will appeal to both types. We have two possible solutions:

1.   A drop down filter menu with a descriptive title such as,  “I want to find….”: People, Places, Groups, Artefacts, Events
2. The addition of a keyword search function that suggests categories to the user for their results. This would reverse the filtering process with the hope that, in time, the user would make the association between their results and filer categories. Behance have a nice example of this below.

 

We hope to update you with our results very soon. Watch this space for an account of our ‘Upload’ process

 

 

 

 

Adding new functionality – creating a personalised user experience

As the project has progressed we have found our focus shifting more and more to the individual as our core functionality has been developed and introduced. We have always envisaged the app as being a way for relatives to curate their own story from the publicly sourced content, to find and store the information that connects to them. To allow this to happen we have developed a range of functions that will give users the option to tailor their experience within the app. As we approach the formal testing phase of the project it seems like a good time to examine how we hope to do this more closely.

Collect – gather and arrange stories for later

 One of the main ways that people will be able to personalise their experience will be through creating a collection. When a card is selected from the feed the user will be brought to the card’s expanded view which will contain all the related information about the card including the associated tags and an ‘Add to Collection’ button.

If the user wants to add the selected card to their collection they click this button which will insert their user id and the card’s id into a ‘collection table’ in the database. This relationship can later be referenced to populate the user’s collection with the cards they want to ‘keep’.

The idea of ‘collections’ is that the user will be able to bookmark cards that interest them for future reference. In our conversations with users about their expectations for the app and the kind of functionality that they would like to see, this feature came up consistently. The collection is a shortcut to accessing certain content which is especially useful to someone who is trying to build up a library of information relating to a particular person, place or event. One of our primary use cases describes a person who wants to expand the story of their relative by gathering the related content of other users so the ability to keep relevant content together in one place is important.

There is also the possibility of taking this functionality further by allowing the user to create different collections so that content relating to different themes can be kept. This is something that we may implement later depending on user feedback. It may be that having this level of separation is unnecessary and even confusing to users but it is certainly something that we will need to look into further as we progress though the beta testing.

Conversations – find out more about stories of interest

Another area of functionality that we recently introduced is messaging. We felt that it was important to allow users to contact each other securely about their stories. We were already aware that the 1916 Relatives’ Association use their Facebook page to find out more information from their community about photos or other pieces of memorabilia. Often relatives will know some information about their relative’s involvement at a particular place, or in a significant event but have little or no evidence of it. We imagined that users seeing a photograph of their relative’s garrison or the place they were stationed would be interested in finding out more about it including where the user who posted it found it and whether they have any other similar content that might involve their relative.

The messaging functionality stores conversations that the user is having with other users. This allows them to keep track of exchanges of information and any leads which might develop. We are considering it as an extension of the app’s search functionality rather than a tool for users to chat. For this reason we may decide to restructure how the messaging works and perhaps make it more similar to an emailing system rather than a conversation.

Filter – selecting what you see

The filtering functionality was also introduced relatively recently as a way of tailoring the user’s experience of the feed page to suit their current needs. Users spoke about the importance of being able to search for useful content straight away on opening the app. However they were less comfortable with the search bar we suggested having on the feed page.

When we reshuffled the app’s workflow and merged some of the related pages, as described in previous posts, one of the things that we brought to the feed page was the ‘discover’ screen search options. These five categories representing the different types of tag available were popular with users so it made sense to integrate them into the primary content screen.

These categories, or filters, allow the user to select an individual tag – a person, place, event, group or artefact – or using the ‘All’ option to select multiple tags and find cards that feature any of them or all of them. The feed is updated dynamically to display the relevant cards so that the user can focus on the cards that they want to see. This feature is especially important for managing the potentially large quantities of data being uploaded.

Follow – prioritise the stories you’re most interested in

The following functionality allows users to ‘follow’ particular tags so that any cards that are uploaded with that tag are prioritised.  It is still in development as we try to figure out how best to make it suit our users’ needs. At present a user can select a tag to follow and the relationship is entered into our database, so it is functional but we still need to resolve how it will be represented in the app.

We are planning that the ‘following’ section of the user’s home page will contain all the tags that the user has chosen to follow so that they can access associated cards easily. We discussed having a list view of all the tags that are being followed with some associated information. However we have recently decided that it would be more consistent, and recognisable for the user, if we considered following as an aggregation of tags. In this version tags would be displayed as something like a ‘tag-cloud’ which would be similar visually to how tags are referenced throughout the app.

User experience is arguably the most important element of any app. Through-out the development process, from data structure to UI, we have tried to remember this and design each aspect of the app accordingly. We are now at a point in the project where we can ask users to engage with the app directly and test how success we have been. There’s still a lot of work to be done in refining the app and hopefully lots of feedback will come for us to act on. We will as ever keep you posted of all the latest developments.

Thanks for reading!

Refactoring and reorganising

In our last post we gave an overview of our recent progress including some of the major milestones that we’ve hit. The last few weeks have been particularly busy here with a lot of work going on behind the scenes. We made a big push to get our MVP up and running and once we did we began the process of reappraising what we had produced, working in parts and glitching in others, and what we wanted to produce in the end. The intervening period has been about bringing the former closer and closer to the latter, it’s been stressful and hectic but also extremely productive.

In today’s post we’re going to follow on from this and look at the process of developing the beta a bit more closely, including the evolution of the app from the MVP and the various hurdles we’ve had to overcome.

Languages – a breakdown in communication

So it all began with confusion over our languages. We had been working, as you know, in tandem with PHP and SQL on server side and HTML5, jQuery and CSS on the client side since the outset of the project. These two chains of communication, with the server and with the user had worked together relatively problem free for much of the project. We had arrived at the point where we were bringing our latest files into PhoneGap when it became clear that something had gone wrong. It transpired that our decision to use inline PHP in most of our files was a poor one. PhoneGap does not allow the use of PHP in files that are imported into it. This meant that we would be forced to restructure much of our code to separate out the inline PHP from the HTML and jQuery and have separate purely PHP files that would only be available through the server.

This was undoubtedly a setback, which took a significant amount of time to rectify. We had in the lead up this point been focusing on including more PHP in our files to allow for the use of PHP $_SESSIONS for user login. We had adjusted many of our scripts to include this piece of code which we had expected to be the key to ensuring our users’ settings were remembered when they logged in. In the wake of the PhoneGap realisation we were forced to undo this work and begin the process of refactoring our code for a second time in as many weeks. On a positive note we had in some places begun the process unbeknownst to ourselves.

AJAX – updating vs reloading

We had up to this point been passing JavaScript variables and user inputs to PHP using forms with the file name being given as the ‘action.’ This results in the user being redirected to the PHP script where the input or required variables are passed. We would often then just use these PHP files as landing pages and include some HTML and JavaScript to style them, treating them more or less as we would any page in the app. This was convenient and fast and in hindsight the root of our restructuring problems.

In some of our files however we realised that this was not suitable, we needed access to data already loaded to the page which would be lost if we were redirected, we needed to pass information to our PHP scripts and update the page dynamically according to the data being passed. AJAX was the answer.

AJAX is a method of asynchronously passing data between the client and server. It allows for the page, or DOM, to be updated without the user being redirected just as JSON which we were using extensively does, however unlike JSON, AJAX also allows you to post, or send data, as well as receive it. We had as a result begun to use AJAX in specific instances instead of inline PHP.

This gave us a head-start but we were in the position of having to refactor all the rest of the code to include separate HTML/jQuery files with AJAX calls and pure PHP files. This was a significant workload but we were aware that it was necessary for the project and actually beneficial for the user experience of the app. As AJAX is asynchronous it means that loading times could be reduced because in some cases only parts of the page would need to be updated making a full reload, which occurred in our previous version, unnecessary. This was most likely a direction we would have gone in regardless so having our hand forced in this way was not as disruptive as it might have been and at this stage, having completed the refactoring, is actually a positive.

Restructuring the UI – lessons from the back-end

Besides the restructuring of the actual code we also reorganised some of the key pages in the app, as outlined in our last post. This was driven by considerations about user experience, but as always there were implications for our code. The introduction of the filtering functionality is a prime example of the power of AJAX and how its introduction has changed how the app has been developed. The filtering system takes the input of the user, the tag they select, and passes it to the PHP scripts which communicate with the server. The page is then updated immediately to display only the cards which feature the chosen tag. Similarly the ‘All’ option gives the user  lists of all the available tags from which they can make multiple selections and call the cards which relate to all or any of them. Thanks to our forced back-end restructuring the development of the front-end has progressed perhaps more smoothly than would have been possible had we not overcome these challenges.

We’ve had to work very hard over the last few weeks but at last all those hours seem to be paying off. Our beta is rapidly approaching completion and the app is looking more and more as we had imagined it. Our next few updates should involve some exciting developments, so stick with us!

Thanks for reading.

The Approach to Formal Testing

Hello there! We’ve been quite busy coding for the last few weeks and finished our MVP (or Minimum Viable Product) a short while ago. We have since been trying to push this basic coded prototype into a coherent and user-friendly app before we begin formal testing. Having established that users could complete basic tasks, primarily uploading and searching, we have begun refining the workflow and UI. We have reduced the tab bar to 3 main pages, as well as a search page and message page.

We are also working on a filtering system to allow the user to control what kind of content they would like to see. Each filter pulls data with a corresponding tag, so if the user would like to only view information relating to O’Connell St they need only select ‘Places>O’Connell St.’ We are also working on different content views so that the user can control how the information is displayed. They can view it on individual cards, as lists of tags or as a photo gallery. The cards on the home screen are also ‘sortable’ now allowing the user to organise their own research space.

In other news, we have been putting a lot of work into our branding and have created a new logo. We’re in the process of incorporating the new identity into our UI and are almost finished making a loading gif out of logo. To conclude, we’ll be beginning our formal testing on the week of November 9th. We look forward to updating you on our progress!

Tagging and categorising – the importance of place

We’ve already talked at length about the intricacies of categorising information, especially when that information is both part of a family story and a nation’s history. These complexities are magnified when we factor in the amount of time that has passed since the events we are recording took place, what information is most integral to how we remember or think of events that happened a long time ago? We have also already talked about how we approached the task of sub-dividing the kind of data we expect to receive into categories to both encourage and inspire people to add details to their story when they upload it. A recent post [Designing a database – user feedback] got into the topic of how users viewed these categories and the weight they attached to places, events, people, roles and artefacts as useful tag types.

In this post we’re going to focus on just one of these types ‘place’. Why give ‘place’ its own post? Well there are a few reasons, but mainly because it is the type that has probably caused the most debate between us. It seems apparent that place is of vital importance to the events of the 1916 Rising and thus to any story relating to them. This has been confirmed through conversations with relatives and testing. In fact our earliest ideas for the app put place as the most important search filter, using a map as the means of exploring stories that users could ‘pin’ to the relevant site. For various reasons, some of which we’ve discussed, the map was side-lined in favour of a ‘people-centric’ view of story aggregation. Users do seem to feel that people are a good starting point for browsing and searching within the app yet place keeps coming up as being particularly significant. A number of recent interactions have brought the question of place to the fore again and we are currently in process of deciding how to deal with it.

Over the last few weeks there have been a number of indications that place would be a significant talking point for users. This began during a conversation we had with a relative who we’d been in touch with a number of times. She had carried out a lot of research into her own family but was also looking into sites in Dublin where fighting took place or the volunteers took refuge.  Although her own family were not directly involved in all the sites she felt that these places were important. She also had a particular interest in Moore Street, the site of the volunteers’ surrender. The Irish Government have purchased two of the most significant houses in the terrace but there is strong opposition, especially among relatives, to a proposed development on the site. For them the whole site should be preserved as a battlefield, despite the fact that little of the original street still exists, place in this instance is an extremely important way of remembering. She feels that a map showing important sites would be a very valuable resource in the app and an important way to educate people about 1916.

Leading on from this conversation we went up to Moore Street ourselves to speak to the people manning a stall to collect signatures for a petition to prevent the development. We’ve done this a number of times and the people there have been extremely helpful and generous with their time. During each of our meetings they have spoken passionately about the significance of places to the 1916 narrative and have told us stories about the events that happened at particular sites. They believe that most of the important sites [which they have mapped – pictured above] no longer exist, or have changed significantly over the years. This could potentially prove to be a sticking point for us would we need to find a historic map to ensure that all relevant sites are included? If we did would a modern audience know where these sites are? This is something we would need to research more fully though it is unlikely that the built fabric of Dublin has changed so drastically that these sites would be un-findable. Another issue however may arise from the way tags are created. We recently looked at implementing a Google place library API which would provide us with a database of place names. We felt that this could be a good way of ensuring continuity between tags being created by users but for a number of reasons we have put it aside for the moment. However the names in the library are contemporary, what happens in the case where a tag should refer to a historic location? Many place names were changed following independence indeed O’Connell Street was Sackville Street in 1916.

A relative whose grandfather was mobilised in Belfast, would be most interested in using the app to find anyone else with information about the Belfast battalions. Despite his research he has found it very difficult to find any leads that might help him. Official documentation relating to the battalion is often protected due to their sensitive nature so the best way of expanding on the information that he has may well be anecdotal evidence from people who share his connection – for him place in the key to his search.

Often the story of the 1916 Rising is focused on Dublin, which although the site of most of the significant events was not the only place involved. Just as with the relative trying to find information about Belfast, we recently read about those who mobilised in Enniscorthy in County Wexford. There is certainly a value in drawing attention to what happened in other parts of the country and the people whose 1916 story was not set in Dublin. This does potentially cause issues if we were to go with a map view. Though other places and communities were involved they are mostly pockets scattered around the country and most likely the majority of the stories on the app will be focused on Dublin. This presents us with a dilemma, if we introduce a map which shows the whole country most of it will be empty while the area around Dublin will be densely packed, yet if we focus the map on Dublin does that suggest a preference on our part for these stories over those in other areas? This is a question we will have to put to users and one which we will have to continue to discuss between ourselves.

The sites of the Rising are certainly an interesting chapter in the story of 1916 and one which is very meaningful to many people. There is a careful balance to be struck in the way we handle how our data is categorised and place will certainly play an important role.

As always, thanks for reading!

Progress Report

So we’re beginning the second cycle of development this week. Having completed our ‘following’ script, we’re also nearly finished our PHP search & messaging functions. We’re also trying an alternative to JQuery UI’s sortable: https://github.com/RubaXa/Sortable. We’ll be doing some final debugging on our JSON calls and interactions over weekend so that we can start testing the coded prototype, on device, early next week. Watch this space!

Designing a database – user feedback

In previous posts we talked about the process of designing a database for the project and about our efforts to engage users with our flick-through prototype and feedback survey. These are related exercises – the data structure needs to be arranged in a way that allows users to access the right kind of information in the right way, and to find out what information that is and what arrangement is most useful we need to ask the users.

The prototype and survey were disseminated a couple of weeks ago and the results are in! [Well at least some of the results are in the prototype is still doing the rounds.]  At this point though we need to begin to analyse the feedback and work out how we can improve the users’ experience of the app.

How users search

One of the most important things for us to get from the survey was input from the users on what kind of information was most relevant to them when searching for content in the app. We asked them what kind of search term would they most likely use – a person, an event, a group, a place or an artefact. 75% of respondents said that they would search by person. This would support an earlier assumption of ours about the data structure, that the person involved was the key to finding links between stories.

In terms of data structure this means that the profiles table is still necessary as a way of collating information relating to a specific person. The id number of a profile, as well as some other relevant information like a biography and profile image, is stored in a profile table for every person who is entered into the database. The id number of a new card and the profile id of any person who is tagged in it are stored in a connections table. The feedback suggests that this relationship is still important to users. If they are most likely to search for content through a person, then we must be able to aggregate information in a profile page so that all the information that is related to that person can be displayed clearly.

How users describe their relative

Another area of questioning in the survey related to how people would want to describe their 1916 relative. This covers the question of ‘role tags’ which we had included in the prototype after conversations with relatives and lecturing staff. We included a list of possible descriptions and asked users to select the ones they felt would best describe their relative or to suggest any that were missing from the list. We found from the results that there was a relatively even distribution between tags being selected which would suggest that the question of how one defines a relative is as complex as we had anticipated. It is positive for us that many people felt that the tags we had included were appropriate, and we have recorded any suggestions for future iterations. It would seem though that this is such a complex area with such a high level of nuance, that any list we provide will not be definitive.

For this reason it is important that users can add their own tags to the database, pre-baked tags will not be sufficient.

The survey also established that a large majority of users think that it’s ‘very important’ for people to have their own profile, affirming their choice of person as the most useful search parameter. When asked what ‘core information’ they would expect to be included in a profile we found that again there was a wide distribution between options selected. From the list we provided a significant majority of respondents selected, somewhat predictably, photo, biography and date of birth/date of death. Interestingly there was also a strong response for battalion, brigade and achievements.

As with roles, it would seem that defining the type of information that should be supplied about a person is difficult. In this case however we are talking about the kind of information rather than the information itself. These terms could provide input fields to prompt the user inputting profile information for a relative to be as thorough as possible, but would not necessarily dictate the actual input. For this reason there must be more rigidity in how we define the types of information included – the input form will require a fixed structure. This means that we will need to make a decision about which fields are most pertinent, using the survey results as a guide, but we may need to revise it further following further testing.

The knock on effect for the data structure is that we need to expand our profile table to include more input columns. The structure as it stands, and as was reflected in the prototype was quite simple including only profile name, biography and photo columns. At the most basic level it would seem users want at least a date of birth/death and additional information about how the person served to be included.

How users want information to be organised

We have already discussed how users have stated a preference for information aggregated by person. However we also wanted to gauge whether other information categories would be useful means of collating content, for example having a page for places or events like a profile page where relevant tags would be added. We asked users how important they felt it was for different tag types to have a ‘profile page’. The results showed that, as expected, most users felt that profiles for people were ‘very important’, we also found however that a large number of users also felt that it was ‘very important’ for places to have a profile.

This feedback is interesting because place did not show up as a popular choice for search category. It seems that people are interested in finding content relating to a particular place but would not necessarily search for information using that place as a criterion. This poses the question of how a user would access a place profile without searching for it. The primary distinction between a profile page and a list of cards displayed by selecting a tag is that the profile also contains biographical information. It is possible that we could redesign the table for place tags to include a descriptive note about each location added, organised in much the same way as the profiles for people are. If we were to pursue this restructuring we would need to find out from users what kind of information they would want to be included as we did with the profiles for people in this survey.

“Hopefully it can be a celebration as much as a historical piece.”

Tester

The feedback we received from the survey and prototype testing were really interesting. We found that some of our conclusions about how users would interact with the app were correct while others were a bit off. It uncovered in greater depth how users think about the content they have and how they want that content to be organised. Most importantly for us it has indicated how the data structure can be tweaked to store users’ data in the most constructive way. We have a lot of material to now take on another revision of the data structure and hopefully design something that people really want to use.

First Review of the Term

We had our first meeting today to check-in after the holidays. While the build is going well, particularly on the server-side, we need to look at a few a key areas. Primarily we need to fine-tune our interaction strategy. We’ll be looking at using an indexing system to iterate through our buttons and event-handlers. We’ll also be seeing if we can use Phonegap for some of the core functionality to save us using several JQuery libraries. For now, we’re moving on to a PHP search function and messaging function. We’ll keep you posted on how it goes!

Why we’re making this app – conversations with relatives

So far we’ve talked about the progress that we’ve made in developing the app. We’ve posted about technical challenges and processes and about design decisions and user influence. Something we have yet to discuss though is motivation. Why are we developing this particular app? In the broadest, least poetic sense, we are doing all of this because we need to produce a final project for our Master’s degree. We went through an ideation phase early in the project that resulted in this idea being chosen [perhaps we’ll write about that process in another post?]. The genesis of the idea, all those months ago before we started looking at 1916 in earnest, was storytelling. We were interested in the stories people told and in their reasons for choosing particular stories to tell. One of the things that kept coming up as we explored this was that people like to talk about their families, to reminisce about memories and to share their ‘family folklore’. Another thing that we noted was that many of the people we spoke to have some family connection to the Easter Rising. As 2016 approached and our collective consciousness turned to the centenary of this important chapter in Irish history it seemed that it was a good time to ask people about their 1916 stories.

There are a lot of stories out there

Considered in this way it was a very pragmatic decision on our part to focus on something that is of current interest. Certainly we entered into this with our eyes open, yet at this point in the project it does seem disingenuous to talk about the project in purely practical terms. The reason for this is our conversations with the relatives.

We began our search for stories with people we know, our families, friends and colleagues. We found that once we started the conversation a lot of people had connections to the 1916 Rising that we were unaware of. In some instances this connection is tentative – We’ve spoken to people who have items of memorabilia whose providence is uncertain, or who have stories about their school or locality. However people seem happy to share these connections and we are always interested to hear their often unusual anecdotes. On a number of occasions our conversations have revealed that people have neighbours or friends who are related to a famous figure from the Rising. The stories of 1916 are ingrained in so many families and communities that there is huge scope to reveal the fascinating connections between people.

We have also been fortunate to speak to a number of people who had relatives who were involved in the Rising. These relatives have generously given up their time to share their family stories with us. Although each story is different, reflecting the many roles that people occupied during the Rising, a common thread has been the passion that the relatives have for their stories.

Telling family stories can be a labour of love

Some relatives have been aware of their family’s involvement for a long time, either through stories passed down or through personal research. Others have only begun to look into their family connections and are finding that the process of gathering information [where it even exists] can be a labour of love. Still others we have spoken to, know relatively little about their relative’s story and are unclear about the facts. Recently we spoke to a man who knew that his great-uncle had fought but had little detailed information about him, in spite of this he wanted to talk about him and went on to tell us about his wife’s grandfather who also fought and had consequently been interned. It is often the case that these people whose stories were not well known are overlooked by posterity and in records, leaving little for their descendants to go on when researching them. However these family connections are very important to families especially to the children and grandchildren of those involved. We are consistently inspired by the dedication of ordinary people to the memory of their family’s often incredible stories. Some of these people have spent years researching and curating to ensure that their stories don’t disappear.

Remembering each relative’s contribution

Another thread that we have been made aware of is the desire that people have for recognition for their relatives. They want to have the individual contribution of their relative recognised, if not celebrated. The majority of people we have spoken had connections to people who were not so well known, this is backed up by conversations we’ve had with staff in the National Library of Ireland who told us that most queries they had received from visitors were in relation to people who were involved but not famous.

There is also a real sense among those we have spoken to that remembering the events of 1916 is truly important not just to preserve family histories but for the education of future generations. In the words of one relative there is a desire when sharing these stories “…to actually say to the people of Ireland to learn your history and celebrate these incredible people.” The relatives want to share their story and they want people to take note. Many of the relatives that we have talked to cite the ideals of the Rising as laid out in the ‘Proclamation of Independence’ and the importance they attribute to them today. One relative talked of his belief that Irish independence wouldn’t have happened without the stand taken by the rebels of 1916. For many of the relatives there is a conviction that the legacy of the Easter Rising is of continued significance and that contemporary society would benefit from remembering it.

So we are developing this app because of the relatives we have spoken to and the hundreds who we have yet to speak to, for the thousands of relatives who attend meetings for the garrisons that fought during the Rising, or who have joined groups on social media to share and exchange stories. We are developing it because now is a good time to look back at how far Ireland has come in one hundred years and reflect on the contribution of some of her citizens to a hugely significant time in our history.  Regardless of politics or personal views our conversations with 1916 relatives have demonstrated the value for all of us in learning more about 1916 and the people who played a part. We hope that with this project we can provide an outlet for people to come together and share their individual stories, to connect them and to learn, whether the user has direct connections or not. Ultimately we want to honour the memory of those whose stories we’ve heard, in the words of one relative, ‘Respect. Just show respect.’

Developing a coded prototype

In our last post we talked about the process of designing a prototype for our app. Here, we are going to talk about developing a prototype again, but this one is different. The app which we have been sharing with many people over the last few weeks is a vision of what the app may be in the future. We approximated transitions and page structures to give the user a sense of how we think a more developed version of the app might look and work. These kinds of prototypes are important for a variety of reasons we’ve already discussed. It’s useful however to return briefly to that other prototype because it is the sibling of the prototype we’ll introduce today. This prototype is not glossy, or carefully styled or even at first glance particularly impressive, its talents are hidden. This prototype developed in tandem with the flick-through offers a vision not of the app’s future but of its immediate present. It is in essence a very early version of the final project.

For months now we have been quietly chipping away at code, honing and developing our knowledge of the data-structure and moulding the script accordingly. Each step has been deliberate and slow, and especially at first, progress would often grind to a halt entirely in the face of any number of errors small or large. This prototype was not shown to other people or discussed much beyond “oh yeah, we’re working on code” and as shifts in workflow and page structure could be mapped and marked as progress in the flick-through, the code edged forward imperceptibly.

However recently we have seen our app begin to emerge from all those files of script. Although it’s not much to look at it marks an exciting point in the development process because it represents real working functionality, albeit nascent. We began the process of building some functionality back in the early summer. We discussed what our priorities were and set out a list of the things we would want our code to do by September. These things included allowing a user to upload an image and descriptive text, to add tags to their post and to display the user’s input back to them on screen. Thankfully we have achieved all of those things and have begun to move into other related functionality, working out how profiles will work, getting cards to display correctly filled with data from our tables, the list goes on.

So we have arrived at September with some functionality and a great deal of momentum behind the coding end of the project but we have not shown it to anyone besides each other and one of our lecturers. This is because for most people there’s not much to see, a lot of the struggles that have been overcome relate to the server, to the database, to querying data and getting it to sit in a page correctly. These are the things that happen behind the scenes but which mean very little to the average user. We are hopeful though, that before long we will be in a position to put this prototype in front of people. The flick-through version is of course easier to test because it looks like an app and acts more or less like a user would expect an app to act. However it is only a vision of what the app might be. With a coded prototype we will be able to test real functionality, to allow the user to experience each interaction in real life.

Having gathered feedback from our other user tests our coded prototype should be more refined to the user’s needs and expectations. It is the fruit of a long development process having been tweaked in parallel to the flick-throughs and taking cues from our changing data-structure though the pace of the changes is somewhat slower and the priority is to have working code first. It is also sometimes the case that realisations made in the course of the development have influenced certain design decisions as well. In fact having both prototypes in the works at the same time has been really useful for giving us insights into each aspect of the project, although they are separate pieces of the puzzle now, they will need to be integrated so this slow convergence is a big help.

That convergence is manifested in a number of ways. We have a home screen with cards displaying data from the card table in the database. These are automatically generated and arranged. We have included the multiple tag inputs in the upload form, and implemented autocomplete functionality to mitigate variation in tags that are added, which users were concerned about. Following upload the user’s ‘card’ is displayed back to them with a list of the tags they added. By clicking on any one of these the user can call all the other cards in the database that also contain that tag. We have also started to implement a system to prompt a user to create a profile for any people they have tagged who do not already have a biography on the database. All of this functionality is beginning to coalesce into what will be a useful, enjoyable and efficient user experience.

For us there is a lot of satisfaction in knowing that tasks that seemed complex and at times insurmountable are being resolved. There is however much, much more work to be done. The prototype is developing day on day and although progress can be painfully slow important aspects of the app are beginning to come together. We have certainly come a long way since we set out to build a coded prototype with some functionality. The next one will be better.