For a lot of people if you mention the Uno Platform they would immediately place it in the same bucket as other cross platform, .NET, technologies such as .NET Multi-platform App UI (.NET MAUI) and Avalonia UI and if you’re only interested in the core capability of create apps that run on multiple platforms from a single codebase, this categorisation fits nicely. However, as we all know, building applications isn’t just about the ability to build and run an application. This post is going to try to set the scene as to why the Uno Platform has invested in Figma tooling and why you should really attend my up-coming session at NDC Sydney, Figma meets .NET developer, to learn about both the Uno Platform Material Toolkit and the Figma Plugin – Uno Platform (Figma to C# or XAML).
NDC Sydney: Figma meets .NET developers (Thursday 13:40 – 14:40, Room 3)
App Development
Let’s start with a quick overview of a typical app development process. I’m not going to state that this is the process taken by every app; and I acknowledge that a lot of applications get created without any design consideration. I am going to examine a typical process for app development where there is a designer/design team involved. As an aside, in my experience the best applications I’ve worked on have been lead by a strong UX/design focus, yielding an application that not only looks great but is also intuitive and easy to use.
Ok, to back to the process, which of course starts with a combination of requirements gathering and UX research, which at some point leads into the creation of mock-ups and over time, high fidelity designs in a tool such as Figma. I also acknowledge that I’ve just skipped nearly all the steps that a designer would go to, just to cut to the point that a developer (such as me) would get involved. Also, I’m not saying that having developers engaged earlier in the discussion isn’t valuable; it is; but for the purpose of looking at the development process, we’ll work with developers getting hands-on at the point where there are designs.
Now that we have designs, there’s often a handover process to developers. This might be as little as an email, with an export of the designs as a PDF. As the tools have progressed, developers are often given access either directly to the Figma or Sketch file, or via a viewing tool like Zeplin. In some cases, the designer will take the time to go through the designs with the development team, providing them a brain dump of the decisions they made, things to be aware of etc. If I were a graphical artist this is where I’d insert some clever meme illustrating the almost total disconnect between designers and developers, and the chasm where information about the design seems to fall. Designers and developers often use different terms for the same thing; they have different priorities and they tend to focus on different details. I’m not saying one is more detailed orientated than the other, just that they focus on different things. The point being is that a lot of this information is lost as part of the handover process.
Hot Reload
One of the buzz terms that frameworks such as React/React Native and Flutter made popular was Hot Reload, in other words the ability to make changes in code and have it immediately update the running application. Ironically in the .NET space we’ve had Edit-and-continue for the longest time but it was such a hit-and-miss feature that it was pretty much ignored by most developers. Hot Reload has been gradually adopted in the .NET space but it’s only been in recent months that it’s got to a point where substantial parts of the application can be modified without requiring a restart. Furthermore, it’s been up to frameworks such as Uno to implement the last mile when it comes to updating the UI layer.
Hot Reload definitely makes the process of fine tuning an application easier, allowing for strong collaboration between designer and developer. However, it’s still a developer technology, meaning that it’s likely to be used mainly by developers in order to implement a design that’s been handed off, rather than the application being built in a pair-programming style.
Design Handoff
One of the unique characteristics of a XAML based framework such as WinUI / Uno is that the design can be specified in a declarative manner. In fact, C# Markup for Uno was designed to be declarative, to ensure a clear separation between the UI and any application logic. The benefit this has in the design handoff is that the designs can be exported using either XAML or C# Markup, leaving no room for misinterpretation or errors in intepretation of the designs.
In the Figma meets .NET developer session at NDC Sydney, I’ll be going through the Uno Platform Figma offerings which includes the Uno Platform Material Toolkit and the Figma Plugin – Uno Platform (Figma to C# or XAML). If you’re not able to attend the session, check out the the Figma portion of the Uno Platform website for more information on how to get started with Figma.