This last term has been craaazy! I have no idea where to find time to finish all assignments, projects, business proposals, researches, and at the same time get ready for midterms! I missed a few posts for Open Source class because of the terribly heavy workload. But they are coming soon! Today I want to share some of the work I did for Release 0.7 of Telescope project.
This release started for me with a Triage meeting where I was one of two people who ran it. The purpose of such meetings is not to solve issues, but rather to keep track of the project’s state, discuss the problems, and make sure everyone has pieces to work on during the release. I was responsible for taking notes and posting them to Telescope Wiki pages.
During the next class, we had a planning session and I had the same responsibilities. The resulting notes that you could find on Telescope Wiki. In the planning session, we were discussing our goals for Release 0.7 as well as later releases. There were a lot of things our team had in mind that could be implemented. I think we shared some cool ideas and even I as a newbie in the project had something to add too. Unfortunately, we are limited in time: the end of the term is close. At the end of the meeting, I had a feeling that we managed to set aside high priority tasks and divide them among the remaining releases.
It was really pleasing to get such a feedback as I really tried hard to make notes as understandable and well structured as possible 🙂
Release 0.7 for me was all about the frontend which I did not actually enjoy. I created a low fidelity prototype for one of the pages we decided to create. This part was fun, I like drawing and creating something new. To come up with a prototype, I went through a few popular online platforms that have similar functionality. One of the main ‘inspirations’ for me was Outlook’s ‘Update your profile’ page. I liked how interactive it was compared to the others. Additionally, I was relying on my previous experience from the coop work where I was developing the backend and fixing bugs in frontend for a credit and risk assessment application. Back then I noticed how many of the applications screens looked very similar to Outlook profile and configuration screens. I found such kind of the layout of a page (with interactive dropdowns, instant error messages, no additional pages and windows) more user-friendly and easier to understand, develop, and debug. Drawing on these thoughts I created sketches that are attached to this issue.
As a next step, I asked to be assigned the implementation issue for the page I have prototyped. The plan was to take on a simple issue first, so here is a bug I was assigned to bug. The description has been changed since I started working on it, but you can still see the old version of it if you unfurl ‘old issue text’ collapse element.
A simple issue it looked, but the reality turned out to be much more complex. First, I struggled with loading this page locally on my laptop. I was trying different methods to run Docker, change code in
.env file, etc. Having spent a day in fruitless attempts, I decided to talk to our Slack community. It appeared I was not the only one with such a problem. As I now understand, I was running backend server locally, which was enough for my previous work on Telescope, but in order to work on the frontend, I also need to run the frontend Gatsby development server.
I started working on the issue where I just needed to remove general styling that was unwanted on this page.
I could not reproduce the issue in two different browsers I had installed on my workstation – Safari and Google Chrome. After a discussion with the creator of the issue, I found out he was using Firefox.
I was requested to make changes in the .css file, so I just added elements’ IDs to the stylesheet with necessary properties. And again, what looked like an easy walk in a park, turned out to be a confusing mess. See my follow-up to this issue on github:
As suggested I used port number for a Gatsby live-reloading development server. My changes worked but, this should not be surprising at this point, a new problem had occurred. The HTML for our frontend is automatically generated by Gatsy, so many elements do not have IDs specified, while available classes are not necessarily unique for a given page. For example, the body element of the page where I had to modify styling, was automatically generated by Gatsy and did not have the ID. It made impossible to write a selector in CSS file which would affect only this page. This made me look into other options I had to modify styling on the page. I learnt that it is possible to inject styles with java script but it looked too complicated for such a small fix. I’ve never worked with Gatsby before, I was not sure whether it was OK to change code in our .js file because the task was to update .css only and I did not like the idea of such fix. I decided to bring up this issue in the class, and hoped my classmates agree that we had to change the approach to such problems or that someone could show me a less awkward solution.
Indeed, the discussion in the class highlighted a hidden conflict with our initial approach. The Telescope uses both static CSS files and the Material-UI styles via Gatsby which don’t work well together. Also, it is a bad architectural design to have styling defined in two completely different places of the project. With this in mind, the team decided to go with Material-UI as the single source of styling information. It supports a CSS-in-JS approach to extend existing styles with custom-defined ones, and this will most likely be the way we will control web page styling in the Telescope going forward.