LinkedIn
Twitter
Not a brief post, but thereโs a lot to touch upon. There will be further posts, as we develop, release and get feedback, but we wanted to let you know some things weโre up to. Still a lot in the works, and iterationโฆ
TL:DR;
Weโve been researching and working on some patterns for desktop apps; these will start being released in the Preview Program, giving us some extensive use across variety of apps, and iterating along the way. We asked the community for some desktop use cases earlier this year as well.
The major desktop elements are discussed below:
- Navigation rail (aka sidebar) and top appbar changes
- Detail view developments:
- Using the expanded real estate for laying out dense content
- App bar patterns, such as breadcrumbs, action buttons, and sibling navigation controls
- Splitting and grouping content
- Collection views
- Open search
- Split view options
Whatโs not in motion at this time:
- Dashboards
- Forms
Hereโs a high level overview and concept sketches of what weโre working on, and will be coming to the preview program:
1. New desktop element: Navigation rail (aka sidenav)
When AppSheet is being used on a desktop, weโre exposing the app views as a visible navigation rail on the left side of the viewport.
Besides being present at all times, weโd like you to be able to work with this in two modes: Collapsed or Expanded. Hereโs a sketch:
Collapsed mode
When collapsed, youโll see the icon associated with the view, and on hover youโll see the view name in a tooltip. Collapsed means you can have more space dedicated to the content pane. Either mode is scrollable for apps with lots of views.
If you donโt show an app icon in your app bar, youโll see the app icon (and the app name) when you expand the drawer, similar to what you see today on mobile.
Expanded mode
When expanded, it resembles the mobile navigation drawer you see today, except it occupies persistent space, i.e. the menu links are visible.
Moving the bottom app bar nodes into the navigation rail
Following a more standard desktop web app pattern, you wonโt see the bottom app bar on desktop.
Tab nodes โ Top of nav rail
This means we map the visible tabs on mobile to the top of the view list in the sidebar, putting them in the top position in the list:
Swapping menu and icon position
Another change weโre making is switching the position of the menu bars and the app logo (if you use one), so the menu control is directly aligned above the navigation links. Pressing the menu control toggles between Collapsed and Expanded states.
2. Detail view changes
Weโre starting with detail views, as itโs one of the most important and potentially information dense, and currently itโs designed primarily for mobile.
Weโre looking to use the available real estate afforded by desktop to break out the content into sections. These sections can be laid out across columns.
Letโs look at the basic structure:
Appbar top - breadcrumbs
Starting from the top, youโll see a a common pattern when you drill down into a detail from a collection: a (hierarchical) breadcrumb bar:
This means thereโs one click up to the collection, and if a user lands in this view from a link, itโs clear what collection this instance belongs to.
Overlay buttons placement
The use of Overlay buttons (aka FAB: Material Floating Action Buttons) is a fairly standard mobile pattern. The core idea is that itโs for the ONE most important action, but AppSheet lets you add multiple.
Translated to the desktop, Material originally kept the floating overlays in the bottom right of the viewport, but after testing and research, transitioned to the top app bar, because of discoverability issues and content overlay. App creators weโve interviewed have brought this issue to our attention.
System action primary buttons will have a label
Right now, weโre starting with having the primary system action button, Edit appearing as a contained button with a label.
How to handle multiple overlay buttons?
The remaining overlay buttons take are displayed as secondary action buttons, and other system actions (delete, sync) remain as icon buttons, and all buttons will have tooltips as well:
Hereโs a sketch of how we are structuring the top right of the app bar for Detail views:
Slideshow controls
For these, weโre moving to dedicated buttons for navigating sibling records. If you have to skim back and forth between records, the buttons are in a stable place, and close together. Weโre also exploring (future) keyboard shortcuts to aid in sibling navigation: This can aid in quickly traversing records, and is effective for power users.
You may have seen this pattern before: Weโre currently using it for detail views in dashboards:
Consolidating interaction patterns when possible is part of a larger push.
Content: Sections, columns, and flow
Right now, detail views form one long strip of mostly undifferentiated content.
Weโre working on a way of grouping these into the following types of sections.
- Primary
- Secondary: Properties (columns and their values)
- Inline lists
These sections can be ordered, and sections can be arranged into columns.
So a layout on a browser can form up to 3 columns, containing multiple sections.
Hereโs an sketch of a detail view with 1. a primary section with an image and some overlay text, a medium amount of secondary properties, and 2 inline lists:
Primary section
Consider a โprimaryโ section (name may change for clarity) as including some of the following:
- Title (often the instance name from the label column)
- Any other headers
- An image
- Actions (Prominent Display actions as currently seen in mobile)
There are many permutations of headers, images, and both combined, currently in apps. There are combination of headers and images, just headers (up to 6), or the card layout.
Right now weโre giving any and all of these prominent placements in the upper left of the content pane when multicolumn layouts are in effect.
Together a primary section of content allows you to:
- See the instance and most important details (expressed as headers)
- Take relevant actions (Prominent display actions)
- View the image (when there is one)
Properties
Next are the remaining properties (columns) of the record. These can have tremendous variance: we have customer apps with anywhere from 5 - 70 plus properties represented in their detail views.
Tradeoffs: There will be some potentially large height differences in sections, simply due to how many properties a section contains.
Grouping properties
To start with these will default to a single section, and we want to empower you to break these into more groupings, and weโd like to allow you to use the SHOW type header as one means of doing so:
Ref lists
The third section type is inline views, such as ref lists. These form other individual sections.
3. Collection views
Next we have our collection views. Starting from the top:
Top app bar: Open search
Another common pattern is a visible search field. With large lists, a persistent field with a visible label provides a quick way to find items.
The other aspect is that the filter icon is visible, and can be accessed with a single click.
Split pane patterns: collection detail views
We notice that app creators are configuring interactive dashboards, setting up a table or similar collection, and adding a detail view. This is recreating the common collection - detail pattern (aka split pane or two-panel selector).
Weโd like to allow app creators to configure a collection view to accommodate a split pane, no dashboard creation required. This will facilitate working in context, and avoiding jumping from collection to detail and back to collection. Hereโs a concept sketch:
Youโll see this pattern in Gmail: users can invoke the split pane from an icon control, and a single click allows for viewing details.
Iโm displaying a data table for the concept mock, but this pattern can apply to other forms of collections (cards).
In conclusion
Itโs a long post, but we wanted to bundle this together to give you a heads up, and break down some of the core concepts and patterns. Thereโs a bunch of details weโll dive into more in other posts.
We put out a call for desktop views and use cases earlier this year, and have gotten some excellent examples of dense data displays. We look forward to receiving more as we go forward.
Stay tuned for more specific detailsโฆThereโs a lot of tuning to do, big and small.
I have noticed that the date picker in desktop preview and normal browsers on chrome require you to move your mouse somewhere in the middle of the cell until your mouse cursor changes. Most of my users have not realized that and intuitively try and click on the calendar icon to open up the date picker.
Is this by design?
Just seems the current implementation is not very intuitive, but I am not sure if the implementation is controlled by the browser and not by AppSheet.
I wonder if AppSheet can force the date picker upon selecting the calendar icon in the cell.
Not sure what Appsheet's thoughts are on this
See Gif below
โ
@JayG hi, check on the Edit action itself, there is option "edit in place/open a form".
Change this to edit in form and check..
