Year 3 Semester 1: Week 1 Reflection

I thought it would be a good idea to blog and reflect on each week of my final year of university studying digital media development. The aim here is to aid the writing of my Reflective process report at the end of each semester by documenting what goes on each week and reflecting with images/screenshots what goes well and what goes wrong etc. Here I will be justifying all of my decisions in terms of the process. As in why I do certain things over potentially taking a different route etc.

DM3109: Negotiated Development Placement

This module is completely focused around our experience on placement. Looking at our development and undertaking of projects in industry.

Despite it being the first week of university I was fortunate enough to be able to start my placement back in July. Since not a lot has happened the first week of uni I will use this space to catch you all up on all the progress made with this project so far. Before starting any work or projects me and Paul, my mentor at The Bot Platform, established a weekly hour catchup session. This would be done through the BlueJeans video calling app. Slack would be used for day-to-day communication while we would use Trello for project management.

Overtime, as the project has progressed along with the complexity, the Trello board has evolved. We have a basic Kan-ban process setup, at the beginning there was only need for a simple 4 column system: one being for Backlog, In-progress, Code Review and Done.

Since then it has turned into what you can see below. This is how it currently stands:

As I mentioned earlier the board has evolved. Since the first initial 4 columns we had. Me and Paul have organised to never have no less than 4 items in the backlog when we leave a meeting. Meaning that throughout the week we would never find ourselves with nothing to do, we could always get started on something in the backlog.

The board typically follows a Kan-ban structure. It became necessary to add new columns for issues and issues done (we'd discussed and completed). When I began work on components, especially after creating the first initial simple text components and progressing to add buttons to them, there was some complication to how we could go about doing this, so I created an issue: 'Button component architecture - Button version for every sort of component? Or singular button component to be output following selected component?'. This became a topic of discussion in our next meeting. The issue column became a place to put any issues we came across for discussion in our next meeting, from this also stemmed a new column called IDS (Identify Discuss Solve) where during meetings we would put the issues we were discussing to keep track, ones of the highest priority being discussed first and not left unresolved. After they have been resolved they would then be moved to the issue done column.

A Ready To Start column seemed like a good idea so items could be moved from the back log to see what our intentions were before starting something. It also became necessary to complete non-code related problems like creating system diagrams etc. These we decided was best to keep separated from code related tasks so we created a To-do and To-do Done column for these. On these sorts of tasks, such as the diagram or reverting merges etc they're often quite important. This makes accountability very important as well. For these sort of tasks we have labels: Done, Not Done (1 week) - orange, Not Done (2 weeks) - red. These are so the tasks don't just sit in the To-do column for weeks and weeks and never get done. Instead, in meetings they get flagged and everyone can ask the relevant questions as to why. This sort of system makes people responsible and gets people asking the right sort of questions.

Up until now I had been focused on recreating components used in Facebook's Messenger / workplace and Microsoft's Teams, with the addition of some custom components. During this time, in meetings, me and Paul were able to discuss what the final product would look like and what our hopes were for it. This included discussion of how backend and frontend comms might work - with Paul's experience in how The Bot Platform's systems work a To-do was assigned to him to draw up a diagram of exactly this.

Up until now there have been 2 code related issues I have had to deal with. The first was one that creeped up fairly immediately after making my first pull request and was commented on when the story was in code review. It wasn't much of an issue just more of a potential solution for readability and a good talking point in our meetings. This was the use of react CSS-in-JS library such as the use of emotion/styled components. I had been using a traditional CSS method previously with styles kept in a separate file. The decision to switch to a CSS-in-JS approach was so obvious once suggested. With traditional CSS styling methods in React it is considered bas practice to use in-line styling - components quickly become very messy and unreadable. This means the next option is to store them in another file. Like for Button.js for that component there might also be a button.css, however we have a lot of components to create which means double the amount of files when their css counter parts are included. It would be ideal to have everything that makes up a particular component contained in its own file, where you can find the architecture that makes up the component, with the props and functions passed to it etc, but also the dynamic styling. A css-in-js solution like styled components would achieve exactly this. I decided to use Styled Components over an alternative like Emotion purely based on the popularity and how widely used it was.

The other issue I faced was one I briefly mentioned earlier: Button component architecture - Button version for every sort of component? Or singular button component to be output following selected component?. Essentially, in The Bot Platforms chatbot configuration tools a user is able to apply a button to lot of the different components such as a simple text component, or even a carousel - but to make it more complex not a button added to the entire carousel but the potential for one or multiple buttons to be added to individual cards in the carousel. With this came the issue of how we would go about including a button with these components? Before tackling this I made sure to complete and make components for a singular button for both Teams and Messenger which you can see in the Storybook here. From here I made the decision to tackle this issue by creating a button element that accepted props for the name of the button but also for the contents of a message. This props data for the message would go on to be used to render this text component I made previously inside this button component, then render the button underneath. You can see this below:

import Text from '../Text/Text';

...

const TextButton = styled(Text)`
  border-bottom-left-radius: 5px;
`;

export default function Button({ message, button: { title } }) {

  return (
    <Wrapper>
      <TextButton message={{...message, author: message.author.BOT }} />
      <ButtonContainer platform={message.platform} onClick={action('clicked')}>
        <ButtonInner platform={message.platform}>{title}</ButtonInner>
      </ButtonContainer>
    </Wrapper>
  );
}

This worked, but immediately upon reflection it was obvious it was very over complicated. As it stands the only way to render a button was exclusively as a single message, with only one button - not multiple, plus buttons wouldn't be able to be output with any custom component. Clearly another solution needed to be find, any component should be able to have multiple (or no) buttons attached to them. You can see here in the GitHub pull request how I developed from the previous method I have discussed here to the solution we went with.

Instead of having the message passed to the button component and rendering that, instead the button component should just be passed to each component. If the message's JSON contains anything about a button, or multiple, then the button component will be rendered.

export default function Text({ button: Button, className, message: { id, title, platform, author, date, user }}) {
  return (
      <Message author={author}>
        <MainMessage className={className} platform={platform} author={author}>
          <Meta platform={platform}>
            {author} {date}
          </Meta>
          {title}
        </MainMessage>
        {
          (Button) ?
            <Button platform={platform} />
          : null
        }
      </Message>
  );
}

Chatbot Testing / Comparisons

Last week saw me look into and try out a library for creating and managing a chatbot in React called React-Chatbot-Kit. It's a fantastic library and I'm sure a very ideal choice for most, however with our specific brief and use-case trying it out saw me find a lot of issues:

• I found that each chatbot uses its own config, actionProvider and messageParser - changing one wouldn't change the other, the same changes needed to be made to both instead of just to one.

• Framework is unable to output a custom widget without a text message first.

• Specifically had to call a function to create bot output as opposed to just passing a JSON block Caused confusion to how we would go about turning JSON data into chatbot output?

Evaluating these issues in our weekly meeting with Paul (15th September) we came to the conclusion that we should first try out another popular option for chatbot management: React-Simple-Chatbot but if not, develop our own system. We discussed what we thought was a necessity from these frameworks so I would know what to look for when trying it out:

• Two separate views (one for each platform) that can use the same dataset and configs.

• Ability to output custom components

• Change the styling

Following the meeting I created a branch off of the master in order to try out React-Simple-Chatbot. It was all very polished, it did seem good as it followed json and in what is sort of like 'steps' where one step (message) could trigger another etc. But it's not flexible in the sense that users only have text input when specified in a step. It also allowed for custom components to be output and also on their own without a text message but changing the default user and bot message components it didn't allow, instead only allowing you to pass an object with styling. If we could take parts from both packages into one that would be ideal. With this in mind I made the decision to go down the route of creating it ourselves.

This is what I focused on this week, week 1 of uni. Analysing the potential of Simple-React-Chatbot and beginning development of our own chatbot view.

When creating my own chatbot view I looked back at what I liked and didn't like of the two previous libraries. I liked the way that React-Chatbot-Kit allowed you to output your own custom components for basic messages, I also liked the way that you could simply pass configuration to the chatbot component as props in order to alter it. However I didn't like the way you couldn't just pass in a JSON conversation like you could with react-simple-chatbot.

With this in mind I was able to achieve a very simple looking chatbot component. I was able to call two of these for a messenger and teams view, pass to both the same conversation JSON data but with each, respectively pass in the name of the platform as a prop in order to style it correspondingly.

DM3107: Major Research Project

Our first week saw the introduction to our dissertation. We were told how this semester would focus on a literature review which would tie into and be apart of our dissertation as a whole the following semester. We were tasked with choosing an area of digital media we wanted to focus on for the next session next week.

DM3105: Enterprise Focus

Our first week also saw us introduced to the Enterprise Focus module.

In our lecture we looked at the different types of businesses, since we are developers we focused more on those that are software oriented (SaaS). For example Netflix, Uber, Deliveroo, AirBnB etc. They are all massively successful organisations but all have the fact they own no physical assets in common. For example Netflix in the early days of their success owned none of the films or TV shows, Deliveroo don't own any restaurants, Uber own no taxis and AirBnB own no properties.

With all of this in mind our task for the next week was to come up with ideas for our potential business.