The external dependency chosen and integrated

My website's central features/focus is the poetry and wedding application/ match finder and thus using an appropriate external dependency will be most beneficial on one of these pages.

First, I explored the poetry homepage and looked at possible (application programming interfaces) APIs [1], Javascript libraries, and CSS frameworks. The API's were explored with the intention of implementing the following features:

Various APIs were researched and suitable ones were implemented. Looking back, the biggest issue with these API's was that it didn't add much value to the website. The user could simply open another tab in their browser and search for poems. The functionality allowed by these APIs did make this process easier but it did not add meaningful value to the overall site.

Concerning the search functionality, it was more appropriate to use the JQuery javascript library [2] rather than an API. I then implemented this. The various JQuery files were coded and implemented on the poem homepage. (These code files can be found in the JavascriptFunctionality folder).The desired outcome was achieved but the exam constraint was considered: we are only allowed to use ONE dependency. I reviewed this feature and decided that it was certainly helpful but it did not add meaningful value to the overall site (it was simply one search function on one page). I could have added more JQuery's and search functionalities on other pages, but from a technical view, this was still only one feature (search). This wasn't sufficient.

I then explored options to enhance my poetry. I experimented with bringing my poetry to life via Augmented Reality [3] and 360-degree images. I implemented this and it worked (these code files can be found in the JavascriptFunctionality folder). Reviewing this, I found that this feature did not represent Johannesburg effectively. The places and images used were from all over the world and rather than using a complex API, an iframe HTML element [4]could achieve the same outcome. This idea was consequently scrapped.

Feeling as if I reached a dead-end I began exploring options for the wedding application/ match finder page. The central feature I was looking to implement was more coherent methods of processing the input on the wedding application form. After research and review, I realised that ultimately I wanted to do something more than just provide users with their match score/percentage, I wanted to process the input in such a way to provide a more meaningful result. This led me to the idea of matches (finding suitable partners for people) as found in dating apps and websites for example.

Matches in terms of your compatibility and matches with other people (not just with me as the application form suggests). I began looking at various existing applications such as Tinder and Facebook, with special focus around how it suggests possible matches and friends via one's profile [5]. This is what I wanted to incorporate and I began looking through the Tinder API [6] and Facebook Graph API [7]. These APIs would allow me to provide the user with possible matches in their area. This was very important (that matches were area-based) as it satisfied the exam requirement- "in context of the representation of Johannesburg".

This idea, of providing the user with possible matches based on their area, proved to satisfy the exam requirement as it augmented the physical world with the digital world and it was in the context of the representation of Johannesburg.

For the Tinder and Facebook Graph API, I would require the user to log in to their respective accounts and give me certain permissions. This would allow me to call various commands and provide possible matches. Reviewing this and being realistic, it was unlikely that people would be willing to provide me with their details to access their Tinder/ Facebook accounts to perform searches on their data (it feels very uncomfortable to allow a website to search through your social media accounts to find potential matches). After much consideration, the use of the Tinder and Facebook Graph API was removed.

CHOSEN API

After the above thoughts, I thought of other methods to implement my intended feature of providing users with possible matches. This led me to an API called Random User Generator [1].

What is it?

This API provides user data based on provided inputs and restraints. In my case, for example, these are gender and number of matches. This fittingly solved my idea.

Try it out

Fill in the match finder form and experience the workings of this API.

How do you use it?

To use the API, the straight forward fetch command is used. The more difficult part is constructing the string (based on the user's criteria) to provide it to the API. To construct the string, the various values were extracted from the input elements and then formatted and concatenated in the relevant order to provide to the API.

Why did I choose this API?

This API allows for more control over the data that it provides via its' various parameters it can accept. This allows me, and ultimately the user, to get personalised responses and tailor the results based on the provided input. This is exactly what I require, as this will allow the generation of personalised matches for users.

Possible alternatives

Other methods to achieve this functionality could be the use of (previously mentioned) the Tinder and Facebook Graph APIs. Using these APIs one can achieve similar functionality with the key issue of requiring the user's personal social media information and permissions.

Technical impact

Firstly, this API returns very large amounts of data, for example: names, date of birth, age, pictures, email, phone numbers, ID numbers, etc. There is a total of 13 fields that are returned with each having its respective subfields. This has the potential to result in lag and cause the site to become unresponsive and crash, should large amounts of data be requested [8]. To overcome this, I have set up the input string into the API to specify what fields to be returned. This significantly reduced the above problem from occurring.

The returned data needed to be represented in such a way that it can be scaled and moved around freely i.e. without causing the page to crash. To achieve this, the results are represented via a CSS grid structure [9]. This allows the various matches to dynamically adjust based on the current page's scaling, for example, if you half the webpage the number of columns and rows will adjust accordingly and not get cramped.

As the user must specify their various inputs and constraints, this allows the potential for invalid input data. To prevent this due care has been taken via implementing more appropriate input elements together with data validation code. This code performs various data validation checks [10] such as: presence checks, data type checks, and range checks. Various coding structures were used to allow this such as the try-catch structure [11]. These data validation techniques prevent the site/ webpage from becoming unresponsive and crashing from invalid input data thus reducing the technical impact that invalid input can have on the site.

Data files

Should you be interested in viewing the code that handles this overall match finder functionality, the code can be found in a file called matchesGenerator.js. (From the GitHub repository or via your browsers DevTools under the Sources tab) The file path as follows: Resources/JavascriptFunctionality/ArrangedWeddingApplication/matchesGenerator.js

Conclusion

Overall, the incorporation and manipulation of this API allowed for an interesting and relevant feature to be implemented on the website. This added a new dimension and allowed the website to become more personal to users. The feature challenges the physical world with the digital by using the power of the digital world to enhance physical relationships and the lives of people in general. The feature is also location-aware in the context of the representation of Johannesburg.

References

Return