With 4 weeks left before the project deadline, evaluation of our workflow and documentation strategy was key. Having a robust system for workflow is important, since in the industry if another team were to pick up the development of a project from where it had been delivered previously by another team, they would need to be able to know how the old team were working in order to best continue developing the project. This includes having complete access to all original assets used in the project, all notes, documents, and blueprints, in order to build a comprehensive picture of the original development strategy and be able to build upon this.
Achieving this state of overall project comprehension is a key reason for why documentation is so important – if every step of the development process is documented, for example – considering why a decision has been made, or why a feature is not implemented, how a feature is to be built, etc, then a new team can easily build an overview of the process and save time in knowing what has already been tried and explored before by a previous team. Additionally, documentation of prior development helps when planning further development on a project as additions can be built to be easily implemented in with the old ones. This would also include information like program versions, as there is differences between older and newer versions of SWIFT for example (cite?), file formats, and other format specifications – such as the resolution for images and videos.
Finally, the systems used for workflow and documentation need to be accessible and translatable in order for the new team to make use of it. A proprietary system for workflow may have benefits in terms of flexibility and privacy, but it needs to be documented well enough for the new team to make use of it. Alternatively, it could be argued that such a system may have disadvantages as it could be difficult to implement this into a new system. Documentation needs to be carried out in a systematic manner, which is easy to read and access – through a type of hierarchy or signposting.
We had originally opted to use our MediaWiki to host files as it was adaptable, permission-controlled, and also hosted the rest of our main content for the project. However, we eventually switched to using Google Drive (cite) to host the asset files for our project, as we found that use of the MediaWiki as a main channel for quickly sharing files did not work so well; it was lengthy to access, supported a limited range of formats and had a poor system for indexing and accessing uploaded content. Arguably, this could have been remedied for longer term usage with custom modifications, plug-ins and other changes however this was potentially not appropriate for the situation at hand. Changing to Google Drive allowed easy upload and access of files due to the well-designed interface, worked natively on a variety of devices held by the team allowing ubiquitous access to files and assets as needed, and its position as a standard service meant that the team was already familiar with its usage, unlike the wiki – for the purpose of sharing files. We also found ourselves employing other methods such as USB sticks, email, and direct file transfers for more acute, situational usages, where appropriate.
Primarily we communicated in person through arranged working sessions, however outside of this we used a private group session on Facebook. For similar reasons to Google Drive, we opted to use this as it was again, permission-controlled, offered a lot of very useful features, and most importantly was very already ubiquitous in its implementation. We all had Facebook integrated with our phones, laptops, tablets, and various other devices already, being frequent users, and we feel that this perpetual contact offered significant benefits for the project in terms of frequent, short progress updates and the sharing of minute details regarding the project which helped greatly in minimising gaps in communication. Due to the relatively un-indexed nature of communications on Facebook however, we also made good use of a page on the Wiki to post important updates and synthesise meeting notes to provide a steadfast central position from where the most important issues could be made clear to the team. We conducted the vast majority of project-defining decisions through once-weekly meetings and group working sessions which we conducted multiple times a week.
We continued to use Trello as an online SCRUM board equivalent for the duration of the project to keep an overview on tasks in general, however made use of various pages on our Wiki to discuss semantics, such as what was happening on a day-by-day basis. We designated tasks to ourselves and each other which worked well as it beckoned an element of responsibility and accountability, meaning tasks were completed on time as expected. This also helped us in knowing what tasks were in progress, and how, and when, targets would come together.
We documented meetings with the project manager using OneNote (cite) to quickly make notes of what was said throughout each agenda. This allowed for indexed, hierarchical, and accessible notes to be produced, which were then synthesised onto the Wiki and distributed to any other necessary channels, making changes to layout and content in order to improve accessibility for other team members. Tasks for the week were distributed to a page on the Wiki and to each team member, and client feedback was delivered to relevant areas (dependant on where the feedback was directed to) in order for changes to be made.
We used a system of making notes individually, on the task at hand, which would then be discussed at team meetings if need be, or developed into fuller documentation on the Wiki. The Project Manager would collate any notes and thoughts into relevant areas on the Wiki for easier access throughout the duration of the project. Notes were also developed into fuller documentation to keep a development log of blog posts regarding the project on WordPress.
Working documents were developed using software such as Microsoft Word, Calligra Words, Word Online, OneNote, Google Docs, and similar packages for their superior editing and proofing tools compared to the plain text entry used by the MediaWiki software, and then transferred to the Wiki when finished in order to make them easily readable and accessible for all members of the team, as a central part of the project. The Wiki became an invaluable cornerstone for documentation of the project as a structure soon developed listing all initial resources and assets from the client, the University, and individual contributions by team members including working documents from which features would be built and assessed, as well as documents showing content for the app, contact details for team members, roles, documentation for the use of the Wiki itself and to-do lists.