If you're developing a desktop app in Electron, NW.js, or a similar tool, it's tempting to just create a "website for the desktop" and leave it at that. But there are a few different UI conventions that you may not have noticed between websites and desktop applications!
The cursor does not change to a pointer (finger) from the default (arrow) on buttons
On websites, if you mouse over actionable elements, your cursor generally turns into a pointer. This includes both hyperlinks and buttons that control the UI. Interestingly, by default when using the <button> tag, the cursor acts just as a desktop UI does and stays an arrow. But when using a stylized <a> or <div> tag that looks like a button, or perhaps by intentionally changing the behavior of a <button>, the cursor changes to pointer.
On desktop applications the pointer is used exclusively for hyperlinks and not for the UI actions. For example, your desktop browser's bookmarks and buttons don't change your cursor into the finger pointer, it stays as the default arrow. Chrome's Dev Tools actually has inconsistent behavior for this - the Elements, Console, Sources, Network, etc tabs use a pointer cursor like a browser, but if you're in the Elements tab and select an element, the second set of tabs for Styles, Event Listeners, DOM Breakpoints, Properties, etc follow the desktop convention of leaving your cursor as the default arrow.
You can't highlight/select/copy any text
On websites, mousing over any non-link will generally give you the text-selection (caret) cursor and allow you to select and copy that text.
On desktop applications, you are generally not allowed to select text nor does your cursor change; text that is supposed to be selectable generally resides in a text field.
You can't select nor drag images
On websites, you can select and copy an image, or straight up drag the image around. An easy way to save an image, for example, is to just drag it from a site directly to your desktop.
On desktop applications, images are handled like text; you can't interact with them.
Right clicking is a thing that people do on the desktop
The right-click context menu may need to be handled in a desktop application, either by disabling right-click in most contexts or populating it with sensible actions. For example, Electron by default doesn't do anything when right-clicking, while right-clicking a text field should allow you to cut/copy/paste/undo/select-all.
Be sure to catch random hotkeys that shouldn't work on desktop
Does ctrl+r do something in your app that it shouldn't on a desktop? How about ctrl+-/+? Does ctrl+w kill your program when it shouldn't on the desktop? Refreshing and zooming might be allowable behavior, but it also might not be, depending on your app.
Oldest comments (0)