LinkedIn
Twitter
All of my desktop apps use dashboards as their primary view display. Generally I am displaying walls of text in tables views along side a detail view for interacting with singular records. Currently I must use a whole bunch of work around methods when navigating from dashboard to dashboard because I need to have everything filtered down to a parent record that was previously selected. As time has gone on I have started to get into much more complex and user friendly looking dashboards within the limitations Appsheet provides. I “like” and “hate” the ability for users to customize how a dashboard is laid out. It provides power users(such my other developers or a couple of other people around the company) amazing flexibility like how my boss has a giant 42in monitor and 2 vertical flanking monitors while the rest of us plebs have moderate sized dual/triple monitor set ups. When it comes to end users that I have to say “click the google button” instead of go to your browser or open up chrome, it backfires because they will accidentally move stuff and I can’t lock it. I know there is the reset button but for some users remembering that button is too much. Greater flexibility when laying out the default and the ability to lock the whole dashboard or even parts of it(maybe asking too much here) would be amazing. Inline views are a really nice things to have in a detail view on a dashboard because it allows me to conditionally show much more information than I otherwise would but the very rigid width of the detail view and columns in table views makes them clunky and unusable in many cases. They just don’t fit correctly it feels. Another thing about sizing and rigidness on desktops is BROWSER ZOOM LEVELS. I can’t tell you how many times I format something to look right on my desktop, go to bosses office or a conference room to demo my apps and the zoom causes hidden columns. I use 80% zoom universally where as 99% of other users use 100%. The user experience on a desktop can range from completely amazing and perfect to unusable where as on a phone or tablet this is almost guaranteed not to be the case since you are already working with such a limited amount of space all the time.
Onto your actual questions now that I have aired all my complaints about using desktop Appsheet 
We have a whole accounts payable system that lives on Appsheet and is integrated to AWS Textract for document OCR and prefilling necessary fields. Users can see any invoice assigned to themselves or their departments, view where in the workflow any invoice they have interacted with is, and see all invoices that are waiting on accounting to put into our back office software that will pay the invoices. When filling out invoices, users can see the Invoice Image as it is laid on the background of a detail view, a deck with previous invoices with some smaller information, a deck notes section, a detail header section, and a table of the individual line items for the invoice. Actions are easiest to put onto our detail header section so that holds all the actions and minor information. We also have a separate app for historical stuff that is just a simple table and details when you click a record.
We don’t currently allow our users any reporting, metrics, and the likes in Appsheet since we are so busy making functional apps, we have neglected analytics as a whole for the users. This app ties directly into our back office software as well so they can get reporting from that if need be. Charts and SVG images in Appsheet don’t appeal to us right now so we wouldn’t do any of those things in app anyway.
For this app in particular we have no mobile or tablet users since there is such an emphasis on using it at a desktop. We have 1 tablet user that can use a tablet version although it used a completely different view designed specifically for said user.
This app would be my pride and I wouldn’t really say joy. We released it from beta hell just over a year ago and have ran over 10,000 invoices through it without too much difficulty other than Appsheet services going down/breaking out app. We have 2 other similarly large apps although one of those blurs the line between desktop/mobile as it is used on 50~ inch touch screens and tablets in our stores. The third app is our first project in Appsheet that has been due for a remodel since the day we released it but it relies on similar principals when it comes to how to handle dashboarding. Over all of our apps, the main thing that stays true is we are using it to interact with data and kick off external processes where necessary primarily from the desktop. If we ever need mobile apps we design them specifically for mobile and make much more robust and larger applications for the desktop users.
(Did I hit the limit 
)
(Feel like a CIA agent with all these black lines)
Here is the main home dashboard that we have for our navigation purposes:
This is the dashboard where our users do all of their interaction with the invoices:
What’s the app’s overall purpose?
I have fully automated R&D tax credit claims using the App
What types of tasks / flows are desktop views being used for?
The main uses of the app are to train people, allow users to capture the information that they need to gather in as close to real time as possible and then ultimately create financial and technical documentation on demand.
Are desktop users different from mobile users, or do the same users switch devices according to context / task?
95% of users will be desktop users as that is what they use in their day-to-day jobs. If Covid ever ends and people go back to work, some diligent people may use the mobile app to capture some details during commutes.
What are some of the current pain points your users are experiencing?
Directing users to the apps can be painful. People automatically navigate to the website rather than clicking the links I send them. The equivalent of a whitelabel for web apps would be amazing, where you could publish the app as a page on a google site.
In November, the grey background was not appearing in the card view and the cards looked really good floating over the background image. Something changed during December and the grey background is back but is not even always covering the full area behind the tiles. I think given the screen space on desktop apps the ability to display the background image is very important to UX.
What types of desktop views are seemingly not available in your current apps that would better address your current use cases?
For desktop apps, it would be good if the forms were wider filling more of the screen. On a wide screen monitor the form can look pretty small on the screen.
Also on web apps, the long text field in forms would be better if they kept expanding rather than created a scroll bar. People are more likely to be capturing more text data in these fields if they are on a browser.
1. What’s the app’s overall purpose?
For my original and main purpose, was to build an app that functions as a browsable menu. The ideal layout is widescreen tablet/desktop. Originally the menu was for in-store, but changes in rules, regulations, and laws, has pushed me to consider also hosting a separate version on our website. Either way, big screen real estate is what I’m looking for.
2. What types of tasks / flows are desktop views being used for?
I’ll just use pictures.
Looks good overall. Maybe a couple cosmetic tweaks could happen, but I have no major complaints here.
The second Inline tends to add additional unneeded space at the bottom. After fiddling with it sometimes it snaps up where it should be. But overall, there should be no reason for me to scroll down at all, because all of that information can and should fit on the screen being used for this example without scrolling. Both Inline and full versions of their views should appear identical. For example, an Inline Card List should look 100% the same (padding, outline, flex positioning). They don’t look as clickable as the full view versions - which is why I tried using only 1 out of 3 actions but can’t format it, so it’s black on gray. And stretching the Card’s width to match the Detail just looks silly. Coding the Inlines to function the exact same as their full version allows the UI team to play with width and layouts of the Detail view without need to worry about the impacts on Inlines (as much), since they can be flexible to their parent container.
3. Are desktop users different from mobile users, or do the same users switch devices according to context / task?
Small screens will almost never be used, but the thought that they can be used is always good.
4. What are some of the current pain points your users are experiencing?
A few UI bugs that are still waiting to be fixed (only using 1 out of the 3 action slots on Card Lists doesn’t respect dark/light theme or format rules). Certain Inline views looking vastly different to the full versions. And the white-space on the screen not being utilized.
5. What types of desktop views are seemingly not available in your current apps that would better address your current use cases?
Can’t think of a specific view type, other than just every view always making the most of whatever real estate is available. I feel like Card view nails this, mostly. The widths of each card and number in each row is variable to screen width. Every view should be built in this style. Detail views should start to rearrange some things more horizontally before going down vertically. Or, perhaps, Detail views should be built more drag n drop style. More control of the size/layouts of Labels/Descriptions when shown on Details/Forms. More control how confirmation messages look (easy to edit and format the yes/no options and also customize the header instead of just “Confirm” - yes, I could change this is localization, but maybe I only want to change it for just one).
EDIT:
I made this super quick and crappy mockup of the direction I think Detail views should go. Obviously, with some better cleanup than my copy/paste screenshot collage can do. With maybe a more square-able Header image.
Hey @Mike_Moss I just thought of something, and thought I would share it here.
When I view a detail view full screen, I’d like to see the details in more of a “dashboard” style view.
Dashboard-Style Detail View (Mock Up)
- All I did was rearrange the elements of the detail view from the video to take up more space of the screen.
The more I think about this, the more I’m liking it.
Just like dashboards, when there’s space enough the app will show you the dashboard; but when there’s not enough space, it lists everything vertically.
- The detail view is essentially that - everything displayed in a vertical column.
Now if there was a way to create a dashboard-style detail view, we could effectively make use of the entire screen. 
But How???
I can see a setup where on a detail view, under the columns included, is another space;
- This would function similarly to the dashboard view selection system; but instead of showing a list of views, it shows a list of reverse references and other list VCs (basically the inline views for that detail view).
- You select select the column you wish to view in this “dashboard style”
- even selecting how that inline view should be displayed (wide, small, tall, etc.)
- You select select the column you wish to view in this “dashboard style”
When you select things like this, when that detail view is displayed on a wide screen - it moves the main detail page to the left side of the screen, then populates the right side with the inline views selected.
As always, thanks for considering!
