benlangham-hackspace-collab

[benlangham-hackspace-collab]

Brief for project - Context outline

We began with an in person Hackspace hackathon with the intention of facilitating quick idea generation and project ideation. The first of two hackathons setup during the Hackspace module, this one with the intention of collaborative ideation. The brief was open and would allow us to explore multiple ideas in groups and ideate on these collaborative thoughts. This blog is an in-depth documentation of the process and the realisation of the project and all its components. 

The brief being so open meant that within our groups we would need to quickly run through a number of project ideas, looking at feasibility and our skillset. We ended up deciding that the context of the project was surrounding the generation of character connections for use in games and maybe with a future development for general storytelling. The project would aid in the creation of character wireframe, a web of connection with a number of assets, this ultimately being helpful adding depth to a game of Dungeons and Dragons for example.

Hackathon - Techniques

Though I have already mentioned the idea and the context it's embedded in, the idea only came to fruition through the hackathon. Only through the use of these techniques mentioned were we able to nail down the project and how it would address certain issues.

We started the Hackathon with a page dump, trying to note down as many areas or concepts as possible then we began to refine the assortment of concepts and help narrow down areas for focus. This technique was helpful in applying some restraints to the creative process, creating a small amount of pressure for the development of ideas. Through this method we were able to as a group nail down specific areas for theme development. These were Connections, Dreams, Parallel. We looked at a combination of all three when attempting to ideate through possible applications. 

Failed Ideas / progress

We found an initial idea that centred around an alarm application that would be able to track your sleep and then deliver a personalised wake-up routine to ease the transition from sleeping to awake.

Using these themes we were able to come up with this idea quickly, we spoke and attempted to develop it further having to complete a small presentation for the class in order to receive feedback and critique. We continued to look at possible technologies in order to achieve the application. We quickly found that the technical ability in the timeframe we had would not be feasible in combination with the feedback we had received from the group.

The Idea

After moving away from our initial idea we continued to think on an application with user benefits that would fit the technological and time constraints of this collaborative project. Joel pitched an idea for a character generator with the application to aid users in the quick creation of character connections for use in games such as Dungeons and Dragons where characters are heavily focused. We also spoke about future applications being for writers, generally aiding in creating webs of characters with relationship indicators.

In terms of reaching the foundations of this idea we looked at a number of methods outlined in the teaching during the Hackathon. Reverse brainstorming helps facilitate this idea heavily. Being able to identify a problem that many of us have faced, look at a possible solution and develop a real solution to said area. We found that attempting to come up with a large collection of characters quickly with a few attributes was difficult, only being able to figure out the central character. We found that using a bank of many attributes, names and relationship levels we could quickly create a character web for story based situations.

We were also able to apply a number of techniques from the Scamper Method, Adapting a similar concept of generators. Example: Name generators, idea generators. There seemed to be an endless amount of generator websites for all different areas. Using the Adapt concept we had changed the context of existing models, applying it to a more niche market and adjusting the tone for a more creative story orientated product. It could also be loosely applied to the Rearrange concept, having reordered the users journey giving them a platform to build from rather than shaping their characters whilst involved in a specific game or story situation. It hadn’t completely removed this aspect as the generator served as a baseline for users to work from and adapt, adopting as little of the generated information as they desired.

What followed and the development of the idea

Paper prototyping

Initial meeting

We spoke about what kind of technologies we wanted to use when creating the product

We decided initially on an entirely web based stack, using html for the frontend with an RESTful API for the sending and receiving of data. It would also allow use to connect the entire application to a database for persistent storage

Began to paper prototype some interface designs, Nishesh was set the role of UI designer and began working on some high fidelity mockups to add in the frontend development that would be undertaken by Joel.

First Tasks

I had researched a number of technologies from our initial conversations regarding what stack to use, we had come to the conclusion that each of us brought certain skills and we should utilise them. In keeping with this, I had come to the conclusion that Node js, Express, Mongoose and Mongodb would be our key backend technologies.

I began researching possible implementations for Mongodb (The database) and the Node js server using express as a framework. I had only used Mongodb once before and after researching I found Mongoose a package that allowed me to customise schemas for sending and receiving data from the database

I then began creating the API, creating specific routes for specific data, this would create documents in the database that could be queried and updated.

Technical Design

Backend

GitHub Repo: https://github.com/blanghamm/hackspace-collab-api

MongoDB

Document stucture for MongoDB, collections on the left hand side.

The backend structure was very important in dictating the frontend usage and also how we stored all the user information as well as the template names and attributes. We needed something that was flexible, this was the main factor in choosing MongoDB as the database. MongoDB is a NoSQL database, it relies on collections that contain documents rather than tables (SQL). Its lack of structure in comparison to SQL is what makes it very helpful for robust flexible data management.

Mongoose

Schema for the structure of data inside of the database when moving through the server.

Mongoose was used as middleware when creating the server that connected to the database, it facilitated the creation of schemas. Schemas allow for a number of rules to be set up restricting the information parameters be it for incoming or outgoing data. For example the schema model for sending data is structured as below (Image) it shows the type of data it expects. This allows for the data we send and receive to be consistent throughout the API. This would help with interpreting the information later in the frontend application.

Express

Main server file that contains all the routes for the API.

Express is a framework for Node js , it helps in easing the process when creating a server. Having a myriad of HTTP utility methods and middleware built in. It states on their website that ‘creating a robust API is quick and easy’. https://expressjs.com/ Having used it previous I found this statement to be pretty accurate. I was able to quickly create a server with a single entry point and then begin to attach various routes.

Hosting

List of builds on Heroku allowing for access to the API with a URL.

It’s not very exciting but here’s the link for the API with the endpoint firsnames, which will return a JSON dataset with firstnames stored in the database. They are structured by the Mongoose schema pattern linked above. 

https://hackspace-api.herokuapp.com/firstnames

Once I had created the different endpoints depending on the data needed for the frontend I made it more accessible by hosting it on Heroku. A hosting platform specially designed for web applications. This meant it was accessible from anywhere with the correct URL. This meant when Joel began testing the frontend application he was able to access the data without having to download all of the necessary files.

Frontend

GitHub Repo: https://github.com/JoelRobinsonUK/ConnectionGenerator

Prototype

Here’s a link to the working protoype: https://joel-robinson.itch.io/character-relationship-generator

We initially decided on an entirely web based application, many of the team wanted to try out some new technologies. Once we had begun researching all of the necessary technologies we found that creating the frontend in purely HTML and JS would be quite difficult without a framework for live data manipulation. We therefore decided to use Unity for the frontend application as this was more familiar to the team. 

The combination of a Unity frontend and Node js backend proved to be a strong combination but there were a number of issues along the way. One main issue we had when attempting to retrieve the data from the API was how Unity interrupted JSON data which is what the server stored all its information in. Initially using the Unity plugin JSON Utility to decode the data we found that it was not able to process objects wrapped inside of a top level array. We therefore found another plugin that allowed use to decode the JSON data inside of Unity. JSON.net was that plugin that helped us with data transfer.

The code needed for a web request, pointing at the heroku hosted URL.

We used a web request to retrieve all of the data from the API and also send data back when needed, it allowed us to manage the data separately and only request it when needed. This helped with removing a large dataset inside of Unity and meant updating information would be much easier due to its external nature.

Maximum degrees of separation

Degrees of separation decide the amount of single point connections that stem from the main character. Adding more degrees will create offshoots further away from the central character.

Not all smooth sailing

When speaking to Joel about any technical setbacks, he found that attempting to sort the degrees of separate had some odd outputs from the node rings that are pre-placed. When the user begins interacting it limits the amount of nodes that are shown depending on the degrees of separation, but this would cause some interesting connection lines between the nodes that wouldn’t strictly follow the users rules.

Visual Design

When planning the visual side of the application we found a quick way to move forward with the prototyping phase was to paper prototype a user interface. (Image) We wanted to have a central area with the connections clearly highlighted followed by a number of settings and modifiers surrounding it to allow for a constant reconfiguration. It would give the user the ability to regenerate a set of character relationships on the main dashboard without having to start the process from scratch.

These two examples above are from the original high fidelity designs Nishesh created from the paper prototypes. The video above is the second iteration and closer to the desired design.

When moving forward with the UI designs, Nishesh began developing the initial version of high fidelity designs. He initially used Sketch to create the designs sharing them through Zeplin, which also included the css properties though they were no longer needed due to the change in frontend framework. The second refined designs were created using Adobe XD as they had some collaborative features that would be useful for future developments. I’ve included some screenshots of the UI itself (List Order) Also attached is a video with a run through of how to use the interface.

Here’s a link to all of the visuals used throughout the projects development:

https://drive.google.com/drive/folders/1fa5MCDmFke7bUY2hwkxnC577YSi0c410?usp=sharing

User Testing

“Overall I really like the product. It’s a good way to develop a story as what often delays the plotting process is coming up with the characters and deciding what their relationships to each other are. This tool offers prompts to help with that process.

Suggestions: An option of seeing “biggest fear” or “dreams” to have a better understanding of the characters.  

The option to change the type of relationship between two characters, and add/remove connections.”

We found through some quick user testing that the application fit the area we had intended to deploy it to, helping with the process of character relationships. With the feedback we received we were able to add a number of possibilities to the future development document, adding more customisation for users would be the next logical step. Made possible by the flexibility of our system architecture.

Critical Reflection

Development

The overall concept for the project fit nicely with the prototypes we created and used a number of key technologies that utilised skill sets within the team. It focused on a problem and adapted current applications such as name generators to create a unique character relationship generator for story based games. Also being able to test it on a number of participants helps us to diagnose areas that require more focus. 

The requirements for the project were met, we were able to create a number of visual prototypes that could showcase the UI and design aspects of the project. Moving from the paper prototypes and adapting them to fit the needs of the application. Using technology such as Node js allowed for the creation of a flexible and scalable platform that would facilitate future development of the project. This coupled with a Unity frontend that could be attached to the backend system helped with quick prototyping of a reactive product.

Being that we had used these two separate technologies also meant that for future development the project itself had become rather modular and therefore if we found weakness in certain technologies we could reconfigure the stack depending on the specific boundaries.

Roles & Collaboration

Being that the initial concept took a few sessions to iron out, it allowed us to fully understand each other's strengths and assign each role to the correct team member. I think this is apparent in the progress the project made and the wide range of technologies that contribute to the final prototype. Throughout the project we kept to our initial concept and made sure not to scope creep too heavily, any additional ideas were added to a future development document which Wiktor had been updating and assessing how that would benefit our project in the future. This had been vital in keeping on track with the concept and delivering a prototype as close to our original idea as possible. 

Possible areas for improvement were only due to the lack of knowledge in specific areas, it was marginally disappointing that when jumping between technologies we all lacked a slight understanding of each other's role and tech. There were of course areas that we could help one another but it would have been better as a team to be able to jump between all roles and offer as much assistance as possible. As much as this was a disappointment in terms of having more input to specific aspects, I feel the team was very effective in their area delivering some high quality prototypes, that in tandem with consistent communication throughout.

Personal contribution

There were moments during the project that certain aspects felt a little aimless in our goals but I feel that as a team we were able to address this issue with each of us pushing the others on certain aspects and putting us back on track. Throughout the project I felt as though I personally had to do this, scheduling meetings to share progress and make sure everyone was comfortable with their personal objectives. 

I enjoyed working on my specific technology and believe that it contributed heavily to the project and made sure it was scalable and easy to use for other team members. Throughout the project I felt that the leadership was mainly managed by Joel and he helped align the scope throughout but there were times when I would need to check in and monitor that everyone was happy and on course which worked well not putting too much pressure on one team member.

Future Developments

When looking at future developments for the project a number of ideas that we had taken during the development process had been added, as not to scope creep. Being able to save the character web for future reference and allow for the editing and saving of an updated character web. This would be easy to implement with the flexibility of the backend API, the overall structure of the database would allow users to save full webs and recall when needed. 

References

parentElement LLC (2017) JSON .NET For Unity (2.0.1). Available at: https://assetstore.unity.com/packages/tools/input-management/json-net-for-unity-11347 (Accessed: 20 October 2020).

Heroku., 2020a. Platform as a Service | Heroku [online]. Available from: https://www.heroku.com/platform [Accessed 6 Nov 2020].    

Mongoose., 2020b. Mongoose ODM v5.10.12 [online]. Available from: https://mongoosejs.com/ [Accessed 6 Nov 2020].    

MongoDB., 2020c. The most popular database for modern apps [online]. MongoDB. Available from: https://www.mongodb.com [Accessed 6 Nov 2020].

Express., 2020. Express - Node.js web application framework [online]. Available from: https://expressjs.com/ [Accessed 6 Nov 2020].