It’s 2020 and many companies are starting to port their desktop software over to the web. Applications like spreadsheets and even video editors—once thought to be impossible to run in a web browser—are now taking advantage of advanced browser features and web frameworks. Although there are many advantages to moving software from desktop to web, there are a couple of things to think about from a design and user interface (UI) perspective.
Right Click
Users have been trained over the years that right-clicking on the desktop is different than in a browser. The desktop provides additional options for whatever software you are using, but right-clicking on a web page will almost always give you browser stuff. Although you can hijack the default right-click menu in a browser and replace it with your own, this is usually advised against due to discoverability. You’ll need to really let the user know that you can right-click.
So, what are we to do when we need that menu? You can display additional actions on hover or use flyout menus. Not having that right-click functionality is a real bummer. But please don’t hijack the right-click menu. Flash did it, and you don’t want to be like Flash, do you?
Scaling & Sizing
Is it responsive? Sure, desktop software can be resized, but sometimes it breaks, or you can’t get to certain elements. The expectation with the web is that if it’s a browser, it should be completely usable from 4k to mobile. If you’re building a complex professional web app (think data manipulation, spreadsheets, etc.), you will have users who expect it to work on smaller screens or only half the screen. Desktop software has the advantage of more screen real estate (no browser menu), and great tools for content layout, as opposed to somewhat limited CSS.
Even if you’re just a UI designer with no HTML or CSS experience, it’s worth the effort to learn the capabilities of Flexbox and CSS Grids. Find a video tutorial to see how they scale, stretch, and position elements. This should help when you are designing and talking to developers about how the layout should behave.
Data Density vs. White Space
Desktop app—especially data-rich ones—can really pack the UI with 9pt fonts, small icons, and data grids with 40 rows per screen. The web, on the other hand, has embraced scrolling and white space. While having an airy open design might look great for dribble, in my experience, users would rather have the information right on hand instead of hidden further down the page or in tooltips.
Common web patterns can also entice the designer to place unsightly additional data in modals, side-panels, flyout menus. But usually, what is hidden away is hard for the user to discover. If you are building a complex data-dense web app, keep that in mind.
The Internet
Your new web app lives and dies by its connection to the internet. Connectivity quality and speed can significantly affect the experience, leading to user frustration when things slow down or fail to load. If your app populates charts and data-grids, consider loading these independent of the UI. Also, be sure to alert the user that data is loading through messaging or animation.
Having someone stare at a white screen while your app loads and loads may lead them to think something has gone wrong, and they may refresh to page or close the tab. Use messaging like “data is loading,” progress bars, or empty state messaging. If something does fail to load, make sure to notify users with helpful error messaging that has solutions or next steps to resolve the issue.
UI Performance
Web applications have a reputation of being, well, pokey in performance and animation. How the UI is rendered can lead to laggy performance that can be caused by triggering something called ‘Paint.’ In web browsers, “Painting” is the process of rendering code to UI. It’s the browser laying out the pixels, like tiny little bricks. Every time you move to a new screen, all those little pixels need to be wiped and laid out again. It is the longest-running task in the pipeline, and visibly demonstrates poor performance in the UI.
When it comes to changing properties in the UI, anything other than CSS opacity and transforms fill force the browser to paint. If you’re seeing stuttering animation of flashing of content when the UI changes, try to think about if there’s a way to avoid triggering “Paint.”
Complex Operations
Want to generate a report or run a resource taxing operation? This may be easy on a desktop app, but your web app might need to offload this to the server, which can take longer to complete. This can be unavoidable in a web app, leading to more UI complexity and additional screens. You may need to create a bevy of components and messaging to support this. You’ll need to let your users know that the report is being generated and what will happen next, especially if they can keep working or log off. You might need to design a state where they can retrieve them. And don’t forget notifications when things are done.
Start by creating a flow diagram so your team understands that you simply can’t fire off a report PDF and serve up a download.
Wrapping Up
In this blog post, I focused on UI “gotchas.” In my next one, I’ll go over the benefits of moving your app to the web.
Justin is a Senior Product Designer at SentryOne. He loves designing complex, data-rich applications and advocating for the user. He’s utilized his talents at companies like Lowe’s, RV, and AvidXchange.
