Archive for category Structure and Story
Project Conclusion
Posted by Briony Gray in Conclusions, Innovation and Creativity (Idea), Media Use, Structure and Story on 29/04/2015
Summary of the project
The aim of the project was to conceive, research and design the TravelSafe application to the point where it can then be subjected to extensive product testing, qualitative and quantitative research. As part of this development the group has kept an online journal that records our work out-put, project decisions and research outcomes in a clear and professional manner. These are easy to access and to follow, and are tagged in a coherent way that corresponds to the marking criteria. Each member has contributed to the online portfolio, and consequently to the development of the product.
Throughout the portfolio the group has explained and recorded many posts which illustrate a number of criteria. These include: an analysis matrix to compare multiple different suggestions, success criteria, similar applications research, establishing a target audience as well as justifying the reasons behind platform choice and pricing, determined a project methodology, sought and adapted the project to expert advice, numerous designs steps including theory and logo designs, numerous engineering steps and diagrams such as UML and class diagrams, utilised background research to influence engineering steps, and developed a product that may fit into a potential market.
What the group has produced
Design number 1.
The One Percent are pleased to announce the introduction of the TravelSafe application and its video demonstration.
TravelSafe is a mobile application for anyone travelling anywhere in the world, whether at home or abroad. The application will consist of a safest route generator, which generates three safe routes from point to point, as well as a safety rating of areas within a given city which are both generated using open data and crime statistics. It will also provide travel information, such as bus and train times, locations and maps as well as weather information including severe weather updates and safety tips compiled from embassies, the World Health Organisation and social media and news feeds. Other functions will be the ability for the user to input information such as their travel insurance, flight details and important numbers, such as a lost credit card and incorporation of translation functionality. Finally, there will be a resource pack available to download which will provide a summary of the information and can be accessed offline to avoid roaming costs.
Next Steps
Our next steps are to collate our work so far in order to pitch the idea of TravelSafe to a Dragon’s Den panel. We will be pitching for funding to help us continue with the user-based research for our application, as well as the costs of implementation and testing. This is of paramount importance to the product as in order for the app to advice on safety all data sets, usability and reliability must be at the highest level otherwise individuals may potentially be put in danger. Any remaining funding will then be used in the process of releasing our application, such as advertising initiatives including a company website.
Broken down, these are the proposed uses for the funding:
- market research: from user focus groups to expert opinions, funding will be used to attract participants and host these events in order to obtain a better understanding of the types of users and their ideas for the application
- implementation: if needed, money will be used to cover any costs for licensing, hardware or software
- testing: as with the market research, funding will be used to gather groups of users in two stages to test prototypes of the applications
- release: funding will also be used to release the application to the market, covering costs such as advertising and the creation and hosting of a business website
extra: any leftover funding will be used to cover overheads such as staff costs as well as further development costs as needed. This may vary depending on test results and dataset reliability.
Written by Briony and Emily.
This post represents Structure and Story, Creativity and Innovation categories within the marking criteria. This is evident as the post sums up the overall project, presents the product the group has created, outlines future steps for its development beyond our project and demonstrates innovation and creativity in both product idea and future considerations.
Success Criteria Revisited
Posted by Briony Gray in Conclusions, Media Use, Structure and Story on 28/04/2015
At the beginning of the project a list of Success Criteria were identified, which were based upon the marking criteria for the assignment. At the end of the project the set of criteria would be evaluated against the work out-put recorded in the portfolio. To recap, our list of the 15 Success Criteria is shown below:
- To have submitted a project brief (approx 200 words) that summarise our project and how we will go about organising its different stages.
- To have kept a running blog (portfolio) of our activities as a group throughout the assignment process, on which each member will post work and research associated with the project.
- To have evidence of participating in meetings with their appointed project mentors, and with other members of the group throughout the assignment process. These can be found throughout the blog entitled ‘Meeting Summary’.
- To have submitted a reflective summary by each member of the project team at the end of the project.
- To present a summary of our project followed by a Q&A session at the end of the assignment.
- To have a project that uses design appropriate social network solutions and interface or extend the designs of existing social network infrastructures.
- To have written evidence of being able to identify and analyse social network characteristics in the portfolio.
- To have written evidence of being able to identify and interpret domain and societal requirements for the deployment of social network solutions in the portfolio.
- To have evidence of group work and group organisation throughout the entirety of the project.
- To have evidence of clear stages of planning and research throughout the project, with equal contributions from all members in a number of topic areas that may include design, research, graphics, and technical issues.
- To produce a finalised description of our project at the end of its course, which includes explanations of its different features, the methodology used to select these features, and a realistic prediction of how this product may be used by the target audience.
- To have clear evidence of market and user research which have been used to underpin the design and technological choices of the project.
- To have clear evidence of tailoring our project based on research undertaken, literature reviews and expert opinions.
- To have submitted a portfolio that demonstrates a social networking solution to a gap in the market which has been undertaken in a professional and well organised manner, and in an original way.
- To have a product that has been developed to the point of needing further testing and qualitative research (which requires funding more than our means, and more time). This means that the product, at its completion, will have extensive background research, design stages, and engineering designs and may only be improved through further testing to the wider public which we ourselves are unable to do. This is a realistic goal for our project as it demonstrates an ability to produce and work on a product to a high standard, but also realistic time management as this product has a limited time and is run alongside other courses and coursework.
The evaluation matrix of this can be seen here, please click to enlarge.
An evaluation matrix of the original Success Criteria.
Written by Taekyun, Millie and Briony.
Cost Analysis for Future Testing
Posted by Po Ting Tse in Conclusions, Engineering, Innovation and Creativity (Idea), Media Use, Structure and Story on 27/04/2015
Introduction
Based on the future test plan and refined project plan, this post presents a vague cost analysis for the testing and release of the product.
Requirements Testing
The requirements testing contains 17 tests, which relate to 11 functional requirements and 6 non-functional requirements. The application will be tested with free automated validation tools.
As scheduled, the whole testing will be assigned 15 days, with 2 application testers working full time. According to ITJobSearch.co.uk which monitors the UK IT job market, an average annual salary of software testing job is £38,000. Therefore, the salary for hiring two application testers during the testing periods would be estimated to be £3200.
On the other hand, the facility and equipment cost may contribute to around £500, which includes buying two mobile devices for testing.
Accessibility Test
This test will be assigned 8 days to complete. Since the group will use free web accessibility evaluation tools (Pearce, 2015), no software fee contributes in this test category.
User Testing
This test will be assigned 8 days to complete. Firstly, it was a tough decision to decide how many users would be involved in the user testing, since the number of users will affect the estimated testing costs and time required. Researchers have various opinions on the number of users involved in the user testing, some suggested 5 users would be enough (Virzi, 1992), some claiming that 5 was not enough (Spool & Schroeder, 2001), while some suggested it should be around 8 to 12 (Hwang & Salvendy, 2010), and some claimed that 15 could cover most of the usability problems (Jakob & Landauer, 1993).
The group decided to keep the voluntary users number above all of the minimum ones that researchers suggested. Finally, the group agreed that the minimum number of user will be 2 sets of 15 voluntary users, resulting 30 users in total. By assuming each user contributes to £10 of the place rental cost, the place rental for user testing would be £300. On the other hand, the facility and equipment cost may contribute to around £500, which could be buying one additional mobile device for testing.
Release cost
The release cost is basically the publishing fees on different mobile application platforms. Up to 25th April, the Android Play’s (http://developer.android.com/distribute/googleplay/start.html) registration fee is USD$25 (ie. £16) and the iOS Developer Program’s (https://developer.apple.com/programs/ios/ ) is USD$99 each year (ie. £65/year) .
Estimated total cost for the testing and release of the product
Therefore, table 1 is the estimated cost for the testing and release of the product, which the total cost would be £4381 . From the pie chart in figure 1, the requirement testings dominate the cost, while user testing and release cost result are less than a quarter of the cost.
Table 1: Estimated cost for the testing and release of the product
Figure 1 Estimated cost distribution on testing and release product
Conclusion
This post gives a vague cost analysis for the testing and release of the product, and the estimated total cost would be £4381. The costs mentioned above are minimal expenses. Other factors, such as using proprietary software, recruiting users for testing and marketing, are not be considered in this analysis.
This post represents considerable consideration of the product above and beyond the marking criteria and the success criteria, showing innovation. It illustrates a realistic plan for a cost benefit analysis of the product which would be a vital component to testing and further development, showing story and structure. It also features media components to illustrate this such as a pie chart. Finally, this post discusses the break down of engineering stages and the costs that these would have.
References
Hwang, W. & Salvendy, G., 2010. Number of people required for usability evaluation: the 10±2 rule. Commun. ACM, 53(5), pp. 130-133.
Jakob, N. & Landauer, T. K., 1993. A mathematical model of the finding of usability problems. ACM Proceedings of the INTERACT’93 and CHI’93 conference on Human factors in computing systems., pp. 206-213.
Pearce, E., 2015. Future Test Plan for the App. [Online]
Available at: http://blog.soton.ac.uk/onep/2015/04/27/test-plan/
[Accessed 25 April 2015].
Spool, J. & Schroeder, W., 2001. Testing Web Sites: Five Users is Nowhere Near Enough. In: CHI ’01 Extended Abstracts on Human Factors in Computing Systems. Seattle: ACM, pp. 285–286.
Virzi, R. A., 1992. Refining the test phase of usability evaluation: How many subjects is enough?. Human Factors: The Journal of the Human Factors and Ergonomics Society , 34(4), pp. 457-468.
By Po Ting Tse
Meeting Summary 27/04/2015
Posted by Briony Gray in Meeting Summary, Structure and Story on 27/04/2015
Meeting Summary 27/04/2015
In this meeting the group discussed the limitations of the previous posts in the Engineering category. This included grammar checking, adjusting post names and re-formatting some of the figures to make the posts easier to follow. In addition to this, the group outlined some changes to the portfolio that would ensure that the portfolio was easy to follow and to navigate around. This included rearranging the posts to be in chronological order, reordering the posts to begin with the earliest post, adding a home page button, and choosing a clearer blog layout.
During the meeting the group discussed the next series of posts in preparation for the deadline of the assignment. It was concluded that the group should focus on a select couple of posts:
1. A concluding post that summarises the product, how it is used, who it is used by, and where it fits into the market. This post should summarise the entire project, and clearly state the product which the group has developed to its finishing stage.
2. A cost benefit analysis which indicates potential costs for testing the product extensively through qualitative and quantitative research. This will show consideration of the product beyond the time scale in which the group has worked on the product, but is necessary for a product to be released on the market.
3. Future test planning considerations in which the next testing stages of the product are evaluated against a time scale. This is vital for the testing stages of a product to be released to the public, and is again showing consideration further than the group’s time scale.
4. Future considerations for technology and tools which would again be vital for a product being released upon the market. This is particularly relevant for the TravelSafe app as it would require technological testing, and reliability testing of the data sets intended for use.
In addition to these tasks the group will finalise the format and grammar corrections to the portfolio, ensuring the highest quality of posts and usability to the reader.
For the next meeting
The group concluded that a first draft of these posts should be completed as soon as possible in order to allow enough time for editing, and portfolio editing before the portfolio deadline on May 1st.
This post represents that coherent structure and story are present in the portfolio which uses the entry and tags mechanism of the blog system. It tells the story of the project by explaining individual roles clearly, explaining why these were decided, and what outcome they will produce later on in the project.
Minutes by Briony.
Future Test Plan for the App
Posted by Emily Pearce in Design, Engineering, Structure and Story on 27/04/2015
Before the group begins implementation, a test plan has been developed to demonstrate how the TravelSafe web application will be tested and the tools that will be used, in order to provide an idea of how the success of the project will be determined.
Requirements Testing
| Test No. | Requirement | Test Description | Test Values | Success Criteria |
| F1 | The system must be able to allow a user to search and select a location based on GPS data | Open the application and use GPS data to select the user’s current location to be used with the application features | GPS data | The application pinpoints the users location and transfers this information to the next screen for use with functionality |
| F2 | The system must be able to allow a user to select a location from a list of saved locations | Open the application, select ‘View Saved Locations’ and then choose a location to be used with the application features | Saved Locations | Saved locations can be viewed and selected with the location transferred to the next screen for use with the functionality |
| F3 | For each location it must be able to generate three point to point safe routes using area safety ratings | Select ‘Route Generator’ | User’s current location and input destination | Three routes are generated from point-to-point with any necessary safety warnings labelled |
| F4 | For each location it must be able to provide a safety rating of a user’s surroundings area based on publicly available crime data | Select ‘Safety of Area’ | Location data | The application will pinpoint areas to avoid/be careful of with the reason numbered and displayed in a scrollable list |
| F5 | For each location it must be able to provide travel information from publicly available times and maps | Select ‘Travel Information’ and choose from Bus, Train, Underground or Travel Alerts | Bus Locations | For each transport type, a map of the stops and a timetable should be displayed |
| F6 | For each location it must be able to provide weather information from publicly available updates | Select ‘Weather Information’ | Location data | A 5-day forecast for the current location is displayed as well as a list of weather warnings |
| F7 | For each location it must be able to provide an updated news feed from RSS feeds of news and safety tips from Government sources | Select ‘News and Updates’ | Location Data | A scrollable list of breaking news and safety alerts, sorted by timestamp (most recent first) is displayed, with any safety alerts locked to the top of the list |
| F8 | For each location it must be able to download a pack of the data that can be accessed and used offline from on-device storage | Select ‘Download Pack’ | Location Data | The user can open an application specific folder on their mobile providing the information for the selected area |
| F9 | Provide translation functionality through use of the Google Translate API | From the home screen, select ‘Translate’ | Free text input:”Je t’aime TravelSafe” | User can select translation languages and Google provides translated text as well as an audio recording |
| F10 | Have a section dedicated to user-input information as free text | From the home screen select ‘My Travel Information’ | Free text input”Lost Credit Card Contact: 01111 111111″ | The user is able to store data in this section, with no limitation on character type |
| F11 | Be able to save new locations | Load a location and select ‘Save this location’ | Location Data | The user can click save on a location and it will appear in the list of saved locations |
| Test No. | Requirement | Test Description | Test Values | Success Criteria |
| NF1 | The system shall be a web-based application | As requested in the requirements | The code | The application is web-based |
| NF2 | The system shall provide a comprehensive list of help and instructions for use | The user can locate, open and scroll through help questions | User input | The user can locate the help section and find answers to their problems at least 80% of the time |
| NF3 | The system shall use a consistent style, layout and colour scheme throughout the application | Navigate through the application | User Testing | At least 90% of the users rate the application a minimum of 4/5 for style, layout and colour scheme |
| NF4 | The system shall take all reasonable steps to improve accessibility | Navigate through the application | Accessibility Testing | The web application conforms to accessibility standards |
| NF5 | The system shall be intuitive for use | Navigate through the application | User Testing | At least 90% of the users rate the application a minimum of 4/5 for being easy to use |
| NF6 | The system shall be compatible with Microsoft Internet Explorer, Google Chrome, Mozilla Firefox and Apple Safari to ensure compatibility with mobile browsers | As requested in the requirements | The code | The web application should be fully functional in each of the specified browsers. |
Accessibility
In order to determine if the application is accessible, the group will make use of a number of online resources, including:
- Tools from the Web Accessibility Initiative
- Web Accessibility Evaluation Tool
- Tools from W3C to validate CSS and HTML markup
- SortSite Evaluation Tool
Between them, these tools provide testing across the multiple standards and legislation as well as provide warning errors designed to increase ease of use for those with accessibility issues and therefore everyone using the application.
User Testing
In order to determine the success of the application, the group will also make use of user testing consisting of a questionnaire to be filled out during observed sessions. This will allow the group to take notes on the ways that different users use the application, any sticking points or common areas of confusion and help questions that need to be added, as well as providing the user feedback. This process will take place a minimum of twice with two sets of different users from varying demographics, with users taking part voluntarily.
Written by Emily.
This post represents that the group has considered appropriate economic and social Contextual Factors that directly link to the marking criteria, which are vital to the further development of the product after this project has finished. This is above and beyond what is expected from the marking criteria.
This post additionally represents Engineering and Design decisions. These are based on the Contextual Factors and literature review which the group have tailored the product to incorporate. This means that the app’s future is based upon considerable research, fluent design and well planned engineering steps. This post illustrates how and why the product has been influenced in its design, testing requirements and engineering. It also shows how the engineering and technology of the app is likely to be apparent in its future testing.
Meeting Summary 20/04/2015
Posted by Briony Gray in Meeting Summary, Structure and Story on 20/04/2015
Meeting Summary 20/04/2015
In this meeting the group discussed the current state of the blog and what each member could do to improve it based on mentor recommendations. The suggested improvements include:
– Each member should read through the posts that they have added to the blog and make sure that grammar and referencing is correct. This would contribute to the overall structure and quality of the blog and its narrative, making decisions and work out-put clearer.
– Each member should read through the posts that they have made and make that the formatting of figures and pictures is correct, and does not distract from any text associated with it. This would contribute to the overall structure and quality of the blog and its narrative, making decisions and work out-put clearer.
– Each member should think about ways to improve the readability of the blog. For example, would changing the blog theme contribute to easier reading. This would contribute to the overall structure and quality of the blog and its narrative, making decisions and work out-put clearer.
For next weeks meeting
It was concluded that each group member should contribute to the list of corrections above, and the portfolio will be evaluated again during the next meeting where Rob may further offer advice. Each member should also begin to consider how the portfolio should be concluded, and what issues should be addressed in order to fulfil the success criteria. This will be vital in summing up the project in a clear a concise way which fits the success criteria, and shows further initiative to the product development.
This post represents that coherent structure and story are present in the portfolio which uses the entry and tags mechanism of the blog system. It tells the story of the project by explaining individual roles clearly, explaining why these were decided, and what outcome they will produce later on in the project.
Minutes by Briony.
Meeting Summaries – Easter Break
Posted by Briony Gray in Meeting Summary, Structure and Story on 18/04/2015
Although the group were not able to have a meeting over the Easter holiday (as many members were in different countries), contact remained consistent via our group facebook page where work is shared, discussed and planned. Over the holiday the group made sure to keep track of our progress on this site weekly. Below are the minutes of the updates.
Week 1 of Easter ending 29/03/2015
During this week the group finalised a first draft of the design and engineering posts previously mentioned. These include Use case, wireframes, design theory, logo designs, activity diagram and a class diagram. For the next week it was concluded that each member would proof read each post.
Week 2 of Easter
The second draft of the afore mentioned posts were posted to the shared googledrive and each member would proof these once again. It was concluded that each member should think about how the posts could be improved and contribute where necessary. The group will email Rob updates on the portfolio progression by the next week.
Week 3 of Easter
The group has posted the first design posts that were discussed at the beginning of Easter. This includes design theory and logo designs. The third drafts of the engineering posts should be completed in order to post them to the portfolio next week.
Week 4 of Easter
The engineering posts have been added to the blog. The group concluded that due to other imminent deadlines each member would focus on these for the remainder of the week. For next week the group concluded that each member should think about future considerations for the product which will take place after the finishing stage of our development. This will illustrate that the group has considered the future testing and release of the app beyond the expectations that the group set out in the success criteria.
This post represents that coherent structure and story are present in the portfolio which uses the entry and tags mechanism of the blog system. It tells the story of the project by explaining individual roles clearly, explaining why these were decided, and what outcome they will produce later on in the project.
Minutes by Briony.
Meeting Summary 26/03/2015
Posted by Briony Gray in Meeting Summary, Structure and Story on 26/03/2015
Meeting Summary 26/03/2015
During this meeting the group found it important to note that this week all members had multiple deadlines for other modules, therefore were not able to contribute as much as usual to the blog. In order to combat this the group have changed the current post’s deadlines to allow for extra time. Despite this set back the group have will still meet the project planning dates stipulated by the gantt chart due to a realistic time scale.
Another topic of discussion within the meeting was that of design for the engineering aspects of the product. The group discussed which steps the product would need, and consequently which posts would sum this up in the most direct and conclusive manner. Below are the short-list of ideas based upon methodological design steps for an engineering project, outlined by Ginege and Murugesen (2001):
1. Use Case
2. Wireframes
3. Activity diagrams
4. Representation/class diagram
For the next meeting
For the next meeting the group decided that each member may select a post which they feel they could contribute the most to. In the next two weeks they should research this, consider design plans and how these may effect engineering aspects, and create a post which details the concluding designs. As the deadline for this will be over the Easter holidays it is important to note that the group cannot have weekly meetings (as some members will not be in the UK). Therefore each member should pay close attention to email and the social media group page in order to stay up to date with the project.
This post represents that coherent structure and story are present in the portfolio which uses the entry and tags mechanism of the blog system. It tells the story of the project by explaining individual roles clearly, explaining why these were decided, and what outcome they will produce later on in the project.
References
Ginige, A., & Murugesan, S. (2001). Web engineering: An introduction.MultiMedia, IEEE, 8(1), 14-18.
Minutes by Briony.
Meeting Summary 19/03/2015
Posted by Briony Gray in Meeting Summary, Structure and Story on 19/03/2015
Meeting Summary 19/03/2015
During the meeting the group discussed with Rob the app feature posts that we have made in order to receive some feedback and improvements to make. Rob provided some grammatical corrections and layout suggestions that each member will change for the next meeting.
For the next meeting
Following on from the corrections individuals have made to the feature posts, each member should put a copy of their post to the shared googledrive in order for the rest of the group to proof read. Each member should also think about what tasks would contribute most to the success criteria when considering planning the design steps for the product. This may include how usability can be illustrated through design, existing design theory for apps or consider wider tools, papers or theories on design.
This post represents that coherent structure and story are present in the portfolio which uses the entry and tags mechanism of the blog system. It tells the story of the project by explaining individual roles clearly, explaining why these were decided, and what outcome they will produce later on in the project.
Minutes by Briony.
Scope of the App
Posted by Taekyun Kim in Contextual Factors and Research, Design, Structure and Story on 17/03/2015
Introduction
An important consideration for the TravelSafe app is the scope of the intended area for its use. Although we fully intend for the app to be used on a global scale, this is not possible for a small group project with limited time. Therefore, we have decided to use the UK as a case study in which to test the app before its launch for use world wide.
Why the UK?
We have selected the UK primarily because all of the group work and live here, which makes tailoring the app and planning its stages easier for us. Also, we know the area very well, which will mean that app can be planned out very well. Along the same lines Miluzzo et al., (2008) reccommend that for apps which need testing in a smaller situation before expanding, a familiar area for the designers should be used which may then be scaled up.
Kangas and Kinnunen (2005) go on to further explain that user testing for an app should be tested in a single cultural and language zone first. Bigger areas should then be used so that easily identification of social, cultural and language barrier issues can be more easily identified and tackled (Kangas and Kinnunen, 2005). Therefore, this advice makes the UK the perfect area to demonstrate the usability of the TravelSafe app, as the area is small and the app can be adjusted before further use.
Limitations
By using the UK as a case study there will be limitations. One limitation is that in the UK there may be different demographics who may use the app, for example maybe more English people will use it when travelling to a different city rather than a different country. This should be fully considered in the qualitative testing in the future. Another limitation is that because of the previously mentioned one, the app may not be fully tested in different countries, therefore it may be difficult to know whether it works correctly. This will be addressed when the app is tested on a bigger scale. We suggest that future testing should begin in the UK, then expand to some other selected countries for example in Europe, and then if this works well, it should be scaled up once again. Finally this will be on a global scale.
Conclusions
The TravelSafe app should use a small area for extensive testing to make sure that any social issues can be addressed on a wider scale (Kangas and Kinnunen, 2005). The UK is the perfect starting point for the testing app as it is small, and the designers/engineers are english-speakers (Miluzzo et al., 2008). The aim of the project is to develop an idea that is at the stage of being able to be tested commercially and extensively, therefore the TravelSafe app at the end of this project will list future testing and technological considerations which may discuss how the app may be release on a global scale.
References
Kangas, E., & Kinnunen, T. (2005). Applying user-centered design to mobile application development. Communications of the ACM, 48(7), 55-59.
Miluzzo, E., Lane, N. D., Fodor, K., Peterson, R., Lu, H., Musolesi, M., … & Campbell, A. T. (2008, November). Sensing meets mobile social networks: the design, implementation and evaluation of the cenceme application. InProceedings of the 6th ACM conference on Embedded network sensor systems(pp. 337-350). ACM.