I have some feedback but I'm not totally sure what the intent here is: do you expect users to still use this new version of the "View" mode as a standalone view (for example, a standalone page that you might bookmark or link to from a wiki page), or only during editing/management and always "view" a dashboard by installing it somewhere? Or something else?

Hmm, I guess I didn't test just a plain "view" mode. I meant this to be both viewing (if you don't have edit access) and view/edit if you do.

Offhand, seems to work fine if I don't have edit permissions as just a plain view of the dashboard.

With Dashboards persistent in Home and Projects, I don't expect much (any?) browsing from the Dashboards application itself. But it seems to work fine.

As a "view" mode, it feels a bit broken for me if I have edit permission because it's very, very difficult to select text. When I go to select, say, T123, which I do pretty frequently, my cursor picks up the whole panel to reposition it instead. If I'm lucky, that's the worst that happens -- but if I'm moving too quickly, I might reposition the whole panel, and then go figure out what I just accidentally did in order to undo it.

The extra actions in the UI (edit, delete on each panel, add panel at the bottom) feel a little off, too. And some options (notably, the "" button to "View All Query Results") aren't visible at all in this combined "Edit/View" mode, while they would be on a normal "View" version of the dashboard. These aren't huge concerns -- text selection is the major issue -- they just feel a little rough.

I can get around the text selection issue by installing the dashboard on Home, or a Project, or Favorites, then using it from there. I think that's totally reasonable in 95% of cases and we should expect that most dashboard use will probably be in the context of other applications going forward, but I worry that the implicit "install" step may make dashboards less usable. That is, as currently written, it feels like there's a completely hidden "now, go find some application or project and install the dashboard there, then you can use it" step at the end of the dashboard creation flow, and the dashboard isn't really usable until then: I can't see the "good" view where I can select text until I do that. But the UI doesn't give you any hints about this, and it gives you an interface called "View" that feels bad as a view (text selection / editing clutter).

I also vaguely don't like that this UI feels so different for users with edit permission vs users without. In most other applications, we'd show all the same UI elements (like "Edit" and "Delete") and disable the if you don't have permission. I think this pattern is a particularly good one from a support viewpoint, since it means that when one user sends another user a link to a page they're always seeing pretty much the same thing. With this view, one user may see "Edit" and "Delete" while the other sees "View All Query Results". This isn't hard-and-fast, but it feels like we aren't getting much by having a hybrid view here.

Maybe a better approach would be to keep separate "Edit" and "View" modes more similar to how they are now, but swap them, so the default mode is "Edit" and there's a link to "View Standalone" (instead of the default mode being view with a link to "Manage")? Then everyone can do "View Standalone" to get the view experience, but it's no longer in the way as much if you're using Dashboards with profile menus, as I think we're expecting most people will be as we move forward.

Ok, maybe I can explain it a different way. I expect Dashboards the app to be about management of Dashboards, and not viewing. I'm happy to reconsider this approach if we do in fact have people that use the application separately, but I don't think we do offhand.

It's not hard to keep around a pure View, but it seems a little pointless. I think most issues with headers, cursors, can be resolved if needed.

(also, this is just one dashboard diff, I'm expecting more to fix install / editing, panel selection, etc)

If we don't expect users to use dashboards from this interface, I think non-editors should not see a "View" view of it, and the page shouldn't be called "View", and there shouldn't be a modal action to switch into an "Manage" mode, the "Manage" mode shouldn't be the only mode with the "Edit" action, etc. When the page is called "View", and there's a button that switches me into a different mode, and then you return to that mode by clicking "View Dashboard", and then text selection doesn't work, it feels like a bug / broken UI to me.

As this currently works, it feels strongly like there's a "View" mode for consuming dashboards and an "Edit" mode for editing them, except that the view mode isn't useful and the edit mode can't actually edit the dashboard.

If you don't think we should have a "View" mode at all, how about turning this into one page with everything on it (properties, actions, all the panels always in "Edit" mode with edit/delete greyed out if the user can't edit them, history)?

Although I think "you don't use Dashboards from the Dashboards" application is basically a reasonable way forward, I'm concerned that the application may sort of dead-end users by not making it clear that they need to go find somewhere to install the dashboard to actually use it. Do you have plans around this (e.g., an "Install Dashboard" workflow)? Are you not concerned about it (e.g., users will probably read the docs)?

I can address those, no problem

good jiff

okay well to start with you put a lot more icons on it and you know I love icons so that is cheating

Ohhhhhh. It kind of makes sense when you see it on Home. I think the element is probably reasonable to at least try as an attack on linking embedded-dashboards to Dashboards better, but it wasn't obvious to me that it was footer crumbs when I saw it on "Arrange" and "View". If it collects a little more stuff it might be more clear, my first thought was that it was some sort of ObjectBox rendering with just a header and no content or something.