Don't display pencil FAB when on desktop

Development
1

Hi all,

the following is the rationale behind the removing of the pencil Floating Action Button (FAB) on Desktop

  • Hash: 371581da5ca37848ebd8c2c00cdad6a9caf3272c
  • Subject: “Don’t display pencil FAB when on desktop”
  • Message:
    • Before this commit, the floating action button was being display
      whenever the user is on view mode on desktop, this is not only
      unnecessary but it’s counterproductive as it directs the user to
      opposite side of the screen.

The change does not remove functionality, it removes a misplaced duplicate control that violated platform conventions, broke the user’s mental model, cluttered the document canvas, and directed attention to the wrong part of the screen. It embodies the SHE (Shrink, Hide, Embody) from Maeda’s Reduce law to remove what can go “without any significant disadvantage”, achieving "true simplification”).

Desktop Already Has a Better Control

The viewModeDropdown is the desktop-native control for switching between “Viewing” and “Editing” modes. It lives in the toolbar: exactly where desktop users expect mode controls to be. It offers a dropdown menu with both “Viewing Mode” and “Editing Mode” options, it updates its label
dynamically (“Viewing” / “Editing”), and we even show a tooltip and trigger an animation whenever the user tries to type, to convey where which mode they are in and where to switch. Watch the screen record: private/pedro/improve ux around view mode by pedropintosilva · Pull Request #14911 · CollaboraOnline/online · GitHub

For the cases when the user cannot write at all (switch mode), it gracefully degrades to a static “Read-only” label.

→ Showing the FAB alongside this dropdown creates two competing affordances for the same action, placed in two different regions of the screen (chameleon).

Behavioral Consistency

The FAB was created first as a mobile/tablet pattern to solve a mobile/tablet problem (the user holds the device with one or both hands, and the thumb has a limited arc of reach). Desktop office users do not have a mental model (even Google Docs on desktop removes the FAB in favor of a top located dropdown!) for floating circular buttons hovering over their document canvas. User on desktop applications normally look up where key controls that thy know live: toolbars, menus, and dropdowns, not at the bottom and not FABs. I would say it’s better to stick to stick with common (most used) user interface elements.

Also the location is much to be desired for desktop. When we putting things at the top or down the right or left side of a screen or window, we make them more or less discoverable ( see Jakob
Nielsen’s F-Pattern from eye-tracking studies). The viewModeDropdown sits in the toolbar, precisely in the F-pattern’s hotspot. The FAB sits in the bottom-right corner of the canvas, a location that is, as I said in the commit message: “the opposite side of the screen” from where the user’s attention naturally rests on desktop.

Additional notes that can be expanded:

  • Google’s own guidelines :

  • Mental model: Better to move closer to the user’s mental model than to the implementation model.

  • Modes and Jef Raskin, in The Humane Interface: “modes are a significant source of errors, confusion, unnecessary restrictions, and complexity in interfaces.” and they become even worst when they are non-obvious: “what mode am in?”

  • Top-down visual hierarchy

  • Reference to Maeda’s Context law, related to how FAB on desktop is peripheral to user’s attention vs on mobile/tablet where is the primary interaction model (not just space, it’s also how you hold the device

    image
    image488×345 60.7 KB

    from Lukas Mathis, Designed for Use, page 140).

1 Like