The vTual Project: Build Alpha v.0.1 Report, Part 3
It's been roughly a month since the last update about Part 2 of vTual Build Alpha v.0.1 Report was written. In this summary, we'll delve into the details of what's transpired since.
Major Change
The scope of major changes encompasses aspects that have a significant impact on the system and UI/UX, directly influencing their functionality and user experience.
Revamped Front Page
As a programmer, I must admit that I'm more comfortable with backend development than frontend design. That's why I relied heavily on Bootstrap for these 5 years, which provides a range of preset classes to simplify the design process. Despite this, I still struggle to fully grasp the principles of good UI/UX design.
Throughout my journey, I've come to realize that the initial design of vTual's interface was stiff and uninviting. It's ironic and dangerous, considering that a well-designed interface is essential for capturing users' attention and interest.
From the design above, you can probably tell how uninviting the layout I created was. It's a far cry from the modern, sleek designs that we've grown accustomed to, and I can only imagine how off-putting it must have been for users who encountered it.
After careful consideration, I finally decided to "invest" in vTual's main interface by conducting market research on designs that could potentially meet the platform's needs in a marketplace.
I spent a significant amount of time weighing my options, carefully evaluating and filtering through various designs. Ultimately, I found a template that I believed would be a great fit for vTual, and I decided to purchase it. This decision marked a significant turning point in the platform's development, as it allowed me to revamp the user interface and create a more modern, visually appealing, and user-friendly experience.
By leveraging a pre-designed template, I was able to tap into the expertise of professional designers and bring a level of polish to vTual that I wouldn't have been able to achieve on my own. Despite this, the new template presented a fresh experience and challenge.
You see, I was accustomed to using Bootstrap's "UI kit" which is essentially a pre-built, plug-and-play solution. While it's convenient, it also means that the design may end up looking uniform or similar to many other websites.
In contrast, the template I purchased is built using Tailwind, a "utility-first" framework that takes a DIY approach. This means that I have the flexibility to create a unique design, but it requires extra customization effort.
It's a trade-off, seriously. I have to invest more time and energy into tailoring the design to my needs, but the payoff is a more distinctive and personalized look for vTual. It's a departure from my comfort zone, but I'm excited to learn and grow from this experience.
So far, the design of vTual is still largely based on the default presets provided by the template, with only minor modifications to suit our specific needs.
This is because I haven't had the luxury of dedicating sufficient time to fully learn and master Tailwind. As a result, I've had to rely on the template's built-in features and configurations, rather than fully customizing the design to my vision.
But after seeing the preview of the new design, I'd say that it's definitely a step in the right direction, as the new look is somewhat more refreshing compared to the original design, right?
Infrastructure Changes
Since the vTuber culture originated from Japan, the vTuber market and fanbase is quite large in the Southeast Asian (SEA) region. Also since I'm based in Indonesia, I initially felt that having the infrastructure in SEA would be ideal.
Not only would it be closer to our target market, but as a developer, I would also find it easier to maintain and manage the infrastructure. As proximity would allow for faster response times, easier troubleshooting, and more efficient maintenance, which would ultimately benefit our users.
Additionally, being in the same region as our target market would enable us to better understand their needs and preferences, allowing us to tailor our services to meet their expectations more effectively.
With this in mind, I choose a multiple provider that virtually or physically located in Singapore to host server for website, server for database, server for email, server for storage, CDN, and also serverless infrastructure.
By having a localized presence, technically we're able to reduce latency and improve overall performance for potential users in SEA, as we could providing a faster and more reliable experience. This strategic decision was made to cater to the growing demand for digital services in the region, and to ensure that vTual is well-positioned to meet the needs of its users in SEA.
But sadly, the issue is that infrastructure in Singapore (or SEA as a whole) is a luxury commodity. Even during the testing period, where all variables can still be controlled, the costs are already draining my pockets.
I worry that if this continues, it will be extremely challenging when we reach the launch stage, not to mention when it comes to expansion.
The high costs of infrastructure in the region could become a significant obstacle to vTual's growth and scalability, making it difficult to sustain and expand our operations. This is a critical concern that I need to address in order to ensure the long-term viability of vTual.
However, decisions must be made, no matter how difficult or heavy they may be. After careful consideration and taking into account vTual's financial capabilities, I finally made the decision to relocate our entire infrastructure to Europe, where most providers can offer same or even better quality infrastructure at a lower cost.
This was not an easy decision, as it meant abandoning our initial plan to seamlessly operate in the SEA region. However, the financial realities and the need to ensure the long-term sustainability of vTual made it a necessary choice.
By making this move, I hope to be able to reduce costs, improve performance, and create a more stable foundation for vTual's growth and expansion. It's a calculated risk, but one that I believe is necessary for the future success of vTual.
Worry not as our infrastructure in Europe is still equipped with much more powerful hardware and networks compared to what we had in Singapore.
This significant upgrade will ensure that our services are delivered with even greater speed, reliability, and performance, despite being located in a different region.
Minor Challenge
The scope of minor challenge encompasses aspects that have a significant impact on the system development, directly influencing the development progression.
Almost Land on Juicy Project
I guess about two week ago, I received an intriguing offer to develop an application for one of the travel companies. What caught my attention, of course, was the total price tag of the application, which was substantial due to its complexity.
The project proposal outlined a comprehensive and feature-rich application that would require a significant amount of development time and resources. While I was initially hesitant to take on such a large project, the potential reward was too great to ignore.
So I decided to carefully consider the proposal and weigh the pros and cons of accepting the offer. Because if I were to accept this offer, I would have to put the development of vTual on hold for several months to come.
However, since I feel that vTual is still lacking in terms of financial resources, I decided to accept the offer as a means to boost our financial capabilities and support the future development of vTual. By taking on this project, I hope to generate a significant amount of revenue that can be reinvested into vTual, allowing us to accelerate our development roadmap and achieve our goals more quickly.
I think that it's a strategic decision that will require some short-term sacrifices, but I believe it will ultimately benefit vTual in the long run.
However, since the potential client missed the negotiation deadline by a week without giving a single word, I got the feeling that this project wouldn't run smoothly even if it can be forced, so I didn't have the intention to do any follow up on it.
You know that I was prepared to put vTual on hold to pursue this opportunity, but their lack of responsiveness has given me a convenient reason to exit.
I can now refocus my attention on vTual without any distractions, and I'm relieved that I don't have to compromise on our development timeline. It's a welcome turn of events, and I'm excited to dive back into vTual's development with renewed energy and focus.
I will explain that this doesn't mean I'm easily dismissive of projects with significant value and prospect. However, if a project lacks mutual respect, then personally i think it's not worth continuing, especially considering how chaotic and undervalued the developer community is in Indonesia.
Conclusion
So, it seems that vTual's development is safe for now and thank you for being a part of this exciting journey!
Last Edit for following extra paragraph: October 11, 2024.
After experimenting with customization on Tailwind for the past few days, I was surprised to find that a significant number of default classes were unavailable for use. As a result, I ultimately decided to purchase an alternative template built on Bootstrap, which I'm more familiar with, to accelerate the development of the visual interface.
This decision was largely driven by the need for efficiency, as I've had prior experience working with Bootstrap, and I'm confident that it will enable me to work more quickly and effectively.
By leveraging a framework I'm already comfortable with, I can focus on refining the design rather than spending excessive time figuring out the intricacies of Tailwind.
The irony, however, lies in the fact that despite the template's visually appealing design which perfectly aligns with vTual's needs: The template developer behind it seems to have made a rather questionable decision.
They decided to combine the entire javascript library into one file called main.min.js and then minified it. In fact they don't even provide the unminified javascript, making it very difficult to categorize which javascript is needed and which is not.
This left me with a staggering 14 MB of main.min.js and i wonder why they still deeming it suitable for use in a production-ready product.
This raises some eyebrows, as such a large file size can significantly impact page load times and overall user experience. It's puzzling that the developer didn't consider the potential performance implications of including such a massive file, especially in today's fast-paced digital landscape where speed and efficiency are necessary.
Let's say this is a skill issue from my side, but please... It would be better if such paid product made it easier for the buyer.
And you might be wondering why I still went ahead and purchased the template despite knowing about the hefty javascript file. Well, let me explain!
As a developer and content creator, I'm fortunate to have a relatively fast internet connection with speeds of around 100 Mbps. When I first previewed the template before buying, the 14 MB javascript file didn't seem like a significant issue, likely due to my robust internet connection.
The file loaded quickly, the visuals are appealing and I didn't experience any noticeable lag or performance issues: heck it's perfect. Everything is theoretically applied when accessed 100 Mbps internet speed.
It wasn't until I was about to upload all the static assets after completing the UI development that I stumbled upon this issue.
I was taken aback when I saw that the total file size was nearing 50 MB, despite having a relatively small number of files.
My initial reaction was, "How is this possible? What's causing the bulk of the file size?" - and that's when I discovered that the 14 MB javascript file was the main culprit, courtesy of the template's main main.min.js javascript file.
It was a bit of a shock, to say the least, and I couldn't help but wonder how this oversight had slipped through the cracks.
I mean I don't really care if the total size reaches hundreds of MB or even GB, after all disk space or bandwidth is not really a problem for us. But a single 14 MB javascript file is a big blow.
You see, when we purchase a template legally we're entitled to a special privilege; Direct access to dedicated support, where we can reach out for assistance with the template issue. In this case, I could have done just that, but I knew it would significantly slow down the already delayed development process of vTual.
I would have to wait for the support team to respond, troubleshoot, and potentially provide a fix, which would only add to the project's timeline.
But as a developer, I'm acutely aware of the importance of meeting deadlines, and I didn't want to risk further delays that could impact the overall project's release.
Also as a developer, I'm a strong proponent of the DRY (Don't Repeat Yourself) principle, which emphasizes the importance of reusable code.
To achieve this, I always apply the concept of Components to all the UI elements I develop. This approach allows me to break down the user interface into smaller, modular pieces that can be easily reused throughout the application.
Once the initial UI development is complete, I take it a step further by refactoring these components into even smaller, more granular pieces.
This process enables me to create a library of reusable components that can be easily assembled and reassembled to build new features and interfaces, reducing code duplication and making maintenance a breeze. By doing so, I can ensure that my codebase remains efficient, scalable, and easy to maintain.
I don't really want to go back and forth in uncertainty regarding UI matters and separating component really is tiring. So... With issues cropping up left and right on the UI front, and the launch deadline rapidly approaching, I ultimately decided to stick with the original vTual design for the beta launch.
I figured it would be more practical to focus on getting the application up and running first, and then revisit the UI development once the beta version was live.
This approach would allow me to prioritize the core functionality and ensure a smoother launch, rather than risking further delays by trying to perfect the UI at this stage.
Throughout the UI development process, I hadn't even touched the backend, which still required far more critical optimization. In fact, I had deliberately put the backend on the backburner, knowing that it needed a significant overhaul to ensure the application's performance and scalability.
By doing so, I could buy myself some breathing room to refine the design and address any remaining issues in a more iterative and incremental manner, rather than trying to tackle everything at once.
I'll conclude this lengthy writing with a statement: As a developer, I always strive to use a license that aligns with its intended purpose, regardless of whether the product resulting from that license meets my specific needs or not.
I may not have the financial means, but I still have a moral compass that prevents me from engaging in piracy. Despite the temptation to cut corners and save a buck, I believe that intellectual property rights must be respected, and creators should be compensated for their hard work and innovation.
This is proof of purchase of a Tailwind-based template.
And this is proof of purchase of a Bootstrap-based template.
Though all of these bad decisions cost me a staggering $48 (Rp. 751.632) that could theoretically be used for extending the infrastructure. Fuck man, that's so damn expensive.
Welp. Someone please refund me lmao.