When it comes to UI rendering, there’s no one-size-fits-all “correct way.” This is especially true for us because we’re building across various platforms and ecosystems, each with its unique user behavior. Consequently, there’s no universal UI rendering approach that suits every situation.
In today’s article, we’ll delve into our first component: the “Neko Profile.”
A Neko profile is what we call our “user.” This term applies not only to Mochi but also to everything we’ve built, from Pod Town to NFTs and beyond. When we say “user,” we’re not just referring to actual end-users but also to external applications built upon our system. In essence, we consider these applications as “users” too.
A Neko profile can take various forms, such as a wallet, a Discord or Telegram account, an email address, or a conventional username/password-based system—literally anything.
Initially, we didn’t anticipate any rendering issues. Everything seemed straightforward on the surface. However, when we started implementing it, we encountered a real mess.
On certain platforms, we can provide a streamlined syntax like @hnh, and the platform itself will interpret it correctly. Each platform has its own syntax, but our data response remains consistent across all platforms. This means that every client must devise its method to extract the correct metadata (like Discord IDs or Telegram IDs) to render it in the platform-specific manner.
Indeed, user behavior varies from platform to platform, and their preferences for viewing content differ as well.
For instance, on Discord, we tend to use “embedded content” because it’s the norm. However, it’s important to note that many users on Discord have their notifications muted.
On the other hand, on Telegram, users are more accustomed to text-based content with numerous buttons. Here, the behavior is quite different from Discord, and mentioning profiles or roles is considered quite normal.
This platform-specific behavior influences how we design and present Neko Profiles, ensuring they align with the user expectations and norms on each platform.
The solution to this issue is rather straightforward, and it’s essentially the only viable approach. For each platform, we render content in the way that’s best suited to that specific platform. Instead of trying to create a one-size-fits-all format, we take a direct and platform-specific approach.
If you want more details on how we’re accomplishing this, you can refer to our documentation in shared-ui-lib.md. This document outlines our methods for handling platform-specific rendering, making it easier for each client platform to work with their respective rendering requirements.