This week has gone by quickly as I have mainly been doing content build for web pages to be published in due course as the organisation's event looms. Initially, it seemed like a straightforward albeit laborious task but due to more people adding ideas and conflicting opinions, the final output has changed significantly (with some back-and-forth) which has created more manual and repeating work and more iterations.

From last week's blog, I managed to improve on the proof of concept for the interactive map feature after some googling, thanks to code from a GitHub Gist, the responsiveness can be performed using plain JS instead of pulling in another jQuery plugin.

I revisited the process in the Drupal admin to replicate a View for displaying data from a particular content entity type (it meant adding a new field and filtering using this field). It was a relatively painless process and shows how powerful Drupal Views is without touching the code. The next problem is the responsive representation of the rendered data. This is an issue we cannot resolve before the deadline as we just don't have the capacity to do a code review and iterate on the styling/javascript used to present the data. In fact, sprints and retrospectives are temporarily put aside and sometimes stand-ups don't happen if they conflict with more time-sensitive matters. I hope to revisit this mapping feature as it is an interesting mini-task and I like extending the capability of HTML and CSS when others may reach for frameworks and the like.

The interesting job of tech support ramped up the last couple of days! It's a task that anyone in tech should do at least once, to build your client-facing skills: effective communication (persuasion, customer empathy and apologetic tone of writing/speaking). I found it difficult to quickly close out tickets because a lot of the questions were not technical: they were logistical and I was torn between offering my 'best guess' which could lead to more complications in the future, but in the short-term closing the ticket. Or, telling the user to wait the whole day while I get an answer from a colleague better positioned to answer the question. More often, I chose the latter which meant I was forced to respond apologetically and in terms of performance (not hitting my target of fast resolution!). I've begun collecting responses to some support feedback surveys which I need to showcase for my apprenticeship but also could leverage in an interview.

I was learning by mistakes really, with the tech support app. But with each day of monitoring, I'm getting more efficient at managing and documenting the support process e.g. setting up shortcut answers to FAQs (this also works for surveys) and implementing an automated message when no one interacts with a user's question for 45 seconds to a minute. This required me to be proactive and seek out the answer from the chat support creator (ironically through their chat support) because we already had a trigger event for 'out of office' hours response, which when viewed alongside a scheduler feature, was confusing as we didn't know which of these was taking effect. Occasionally, during work hours, users posting questions would receive the 'out-of-hours' message. Turns out, this was happening during the occasional times when I was away from the keyboard (toilet break etc.) and my machine went into hibernation and no other tech support was logged in.

I'll be happy when this role is over but I do think it's character-building and tests your patience and ability to work under pressure.