Halfway There

It is been a while since I last wrote a blog post. I’ve been busy with some work outside of GSoC and didn’t have much time to write anything. But now that I’m back, let’s get to it!

Note: This is my 4^th Bi-Weekly blog. You can find the rest of them here

Summary

As always, for folks in a hurry, here’s a quick summary of what I’ve been up to.

The course creation modal PR has been merged and is now live on the Dashboard! With that out of the way, I got started on writing tests for the new UI, which also got merged yesterday.

With that, the work on the course creation modal is (mostly) done. Now, we move on to the next phase of the project - adding different scoping methods to an existing course. I haven’t started coding yet, but I’ve been doing a bit of design work and after discussing with Sage, I think I have a good idea of how to proceed.

And now, let’s get into the details!

The Tests

Tests are a really fun thing to write. I know that’s not a popular opinion but I imagine that stems mostly from people writing redundant and often useless unit tests. A lot of the pain stems from the fact that to test a piece of code, you must what that code does and how it does it - not to mention the fact that you have to mock everything under the roof to make sure that your tests are isolated and you’re not spamming external APIs.

But in the past year or so, I’ve realized that for the web at least, there exists a much more painless way to test your application - end-to-end tests. These tests are written from the perspective of the user and test the application as a whole. This means that you don’t have to worry about mocking anything - you just write the test as if you were a user and the test runner takes care of the rest. This means that your tests will fail if an external API you rely on is down, but that’s a good thing - you want to know when your application is broken. The users will know, so you might as well know too.

All this requires a different mindset than what you’d use for unit tests. But once you get the hang of it, it’s a lot more fun and more importantly, infinitely more useful. Even debugging is a lot easier since you can see the browser doing its thing and you figure out exactly what’s going wrong. The power of having a real browser at your disposal is not to be underestimated - I can’t count the number of times I’ve put in a sleep statement in my code just to get a chance to mess around with the browser and see what’s going on.

Having said all that, I did run into a few issues. Making sure that the environment the tests run in the CI is the same as the one on my machine was a bit of a pain. I’m not even talking about browser versions here - just that some Dashboard configuration options were different on my machine and the CI. But once I got that sorted out, it was smooth sailing from there.

With that merged in through #5451, the course creation modal is well and truly done

The Next Phase

With my focus moving to the UI after the course has been created, I have started to think about how it should look and work. I’ve been working on a few designs and after some discussion with Sage, I have pretty much finalized how this will end up looking like.

My designs can be found on Figma here - these contain the designs for the course creation modal as well as the ones for the next phase of the project.

The idea in its simplest form is to have a consistent interface - we reuse the same UI we had for the course creation modal. Not only does that simplify the code, but it also makes it easier for the user to understand what’s going on. Currently for example there’s autocomplete for categories, templates, and pages in the course creation modal. But there’s no autocomplete for the same in the UI after the course has been created. There’s an option to change the wiki in the Articles tab after the course has been created, but not in the course creation modal. And so and so forth. All of these are small things, but they add up and make the experience quite jarring.

This is what my goal for the next few weeks is - to unify these interfaces and make sure both have the same functionality, along with the same look and feel.

Conclusion

It might not feel like it, but there’s a lot of work that goes into making a UI look and feel good. I’ve been working on this for a while now and I’m still not done. But I’m getting there, and I’m excited to see how this turns out.

On the GSoC side of things, the mid-term evaluations are over and I’m happy to say that I passed! I know Sage is tired of hearing this, but I’m grateful for all the help and support I’ve received from him.

As for how much more work is left, I’d say there’s not a lot. If I had the time and energy, I could probably get this done in a couple of weeks. But there’s no need to rush - I’d rather take my time and make sure that the result is something that I’m proud of.

And that’s it for this blog post! I’ll see you in the next one! I don’t know when that will be, but I’ll try to get it out as soon as I can. Until then, take care!