Skip to content
This repository has been archived by the owner on Sep 20, 2024. It is now read-only.

Pre-flight validation #1780

Open
tokejepsen opened this issue Jun 30, 2021 · 10 comments
Open

Pre-flight validation #1780

tokejepsen opened this issue Jun 30, 2021 · 10 comments
Labels
type: enhancement Enhancements to existing functionality

Comments

@tokejepsen
Copy link
Member

tokejepsen commented Jun 30, 2021

Goal

Generalize flagging updates to user on launch.

Motivation

There are a couple of crucial setups that needs to be flagged on launch rather than at publish;

  • frame range update.
  • resolution update.
  • container update.

Currently there are no flagging of updates to asset attributes like frame range and resolution.
Container updates are handled different per host and more importantly flagging to the user about container updates are handled different. Generalizing this feedback to the user, would lower the pipeline specific knowledge for a host.

[cuID:OP-1140]

@tokejepsen tokejepsen added the type: enhancement Enhancements to existing functionality label Jun 30, 2021
@mkolar mkolar added cu and removed cu labels Aug 24, 2021
@BigRoy
Copy link
Collaborator

BigRoy commented Apr 7, 2022

An "outdated containers" pop-up does exist (Maya+Houdini that I know of at least) and for FPS I believe there's also a validation on scene open and save in Maya (and Houdini?).

Anyway, I'd love to see some UX proposals of something that is a solid small notification of "this and this and this might be something you want to look into" and potentially propose solution(s) to the user for each too.

It should be some non-blocking notification UX that the user can also "ignore" however still be notified of.

Some Notification UX related posts:

I think these particular points are important

Non-interfering: A notification is a timely alert. However, it can distract the user. Hence, the main characteristic of a notification is that it should be non-interfering. It should achieve the purpose of letting the user know that something important is on the way.
Small in size: A good notification should be as small as possible but effective at the same time. An example of a simple unobtrusive notification is the calendar notification that usually slides at the top of your mobile screen. They are small in size but they serve the purpose well.

Would a small "stack" like one of these be nice?


Question: A scene can take a long time to open and if a notification disappears in X seconds/minutes the user might still miss it if they were away from their desk or the application for a moment. Would you expect the pop-up to remain open? Or maybe be slightly smart that it does something like if app or user idle do not countdown timer (and is that even possible across all hosts to detect?)

Currently the notification is a tad big and stays around forever and ever until closed or acted upon by the user.

@tokejepsen
Copy link
Member Author

Question: A scene can take a long time to open and if a notification disappears in X seconds/minutes the user might still miss it if they were away from their desk or the application for a moment. Would you expect the pop-up to remain open? Or maybe be slightly smart that it does something like if app or user idle do not countdown timer (and is that even possible across all hosts to detect?)

Think a timed or otherwise intelligent pop up, might be overkill for this. At least to begin with, I think it should be just a dumb pop up notification, which we can refine later as we get feedback from production.

Having it non-blocking is interesting. I would say it should be blocking, so newcomers to the pipeline are forced to look at the notification.

@BigRoy
Copy link
Collaborator

BigRoy commented Apr 7, 2022

Having it non-blocking is interesting. I would say it should be blocking, so newcomers to the pipeline are forced to look at the notification.

We originally had that and oh boy was that annoying. You just don't want anything to hold you back directly after a scene opens.

@tokejepsen
Copy link
Member Author

We originally had that and oh boy was that annoying. You just don't want anything to hold you back directly after a scene opens.

Fair enough :) Then it should be as obvious as possible to newcomers.

@antirotor
Copy link
Member

I know there is already work done on it and I am thinking about slightly more abstracted way too look at it - what about delegating the notification dialog to openpype tray. Client (DCC) would notify Tray using REST API, and Tray will display unified notification dialog. That would allow to use it even in hosts, where Qt is not available (Photoshop....?) I think we will need to do it anyway in v4.

@tokejepsen
Copy link
Member Author

Interesting idea. I guess this is only for notifications? You cant interact with the host from the Tray?

It's slightly disjointed having a notification in the the tray from a different application, but if its noticeable enough then its a valid route.

@antirotor
Copy link
Member

Right now, it is just one way - host initialize communication, tray reacts. For two way communication we would need to implement some kind of RPC server inside the host. But for plain notifications, it would be enough. But there are possibly more kinds of "notifications" to show. Some of them might even use system notification (for non critical messages like "your openpype version was updated to ...") but that tends to be ignored (at least by me :)). But showing popup notification like many other apps are already doing - Thunderbird, antiviruses, and so on.

Writing something that would respond to user action in notification window - like clicking on the "fix" button wouldn't be that hard but that's meat for another feature I would like to see - ability to control dccs from outside.

Notifications in tray have one more advantage - with some form of event system, you can notify users about asset changes immediately as the change happens (and event system picks it up). But again, that's probably for v4 too.

@BigRoy
Copy link
Collaborator

BigRoy commented Apr 21, 2022

I think that's definitely interesting to solve - and unifying the notifications to that extent could work really nice too. However, I do feel the first step would be to decide also on how we want the UX to look and feel.

In the end the artist doesn't really care where the notification gets generated from, as long as they can identify to which Maya session they have open it belongs to and that they see the notification at the right moment without interfering with their workflow and interupting them. It should really be that, a "notifcation".

@BigRoy
Copy link
Collaborator

BigRoy commented Mar 31, 2023

Just wondering - is there anything for Ayon in the works already to solve some more of this issue like the stacking message popups? Or maybe some better UX that could be used for this?

@BigRoy
Copy link
Collaborator

BigRoy commented Apr 7, 2023

Wanted to also reference this topic: getavalon/core#435

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: enhancement Enhancements to existing functionality
Projects
None yet
Development

No branches or pull requests

4 participants