search

getavalon / core

The safe post-production pipeline - https://getavalon.github.io/2.0
MIT License
218 stars 48 forks source link

Launcher 2.0 #374

Open mottosso opened 5 years ago

mottosso commented 5 years ago

The current iteration of the launcher has been in action for some time now, what do we like about it? What don't we like?

I figure we could take a moment to reflect on what its strengths are, along with its weaknesses. I've come across a few launchers since I first put this one together, and have a few ideas on what could be improved from a UX perspective.

  1. There's too little information on-screen at once
  2. There isn't any room for more information, like
  3. Animations are distracting
  4. It's QML, a separate beast from the rest of Avalon, both to maintain and to get PRs from others

On the upside.

  1. It's uncomplicated and intuitive
  2. It looks nice
  3. It performs well

What could this critical, first line of defense that is the Launcher do to improve?

mottosso commented 5 years ago

Sifting through issues, here's one I would like to unpack. :) I want our Launcher to be preferable to anything else, what is it about ftrack that the user prefers?

mottosso commented 5 years ago

One of the things I'd like to support is information about the user, his tasks and history. E.g. Ben is logged in and sees tasks related to Ben, along with his last few launched applications - and possibly which files those applications were launched with, e.g. my_model_v035.ma. I'd also like to support images; such as of the user, of the project, or the asset and of the task.

We'd need a document in the DB to hold that kind of data, which could be ingested via a Python API but won't need a GUI, since it would normally come from e.g. CGWire/ftrack/Shotgun or the like.

tokejepsen commented 5 years ago

what is it about ftrack that the user prefers?

When using a production tracker like Ftrack, the users starts off there reading comments etc.

The launcher could maybe facilitate all the data from the production tracker, but that seem like a lot of data syncing for little gain.

mkolar commented 5 years ago

So far none of our current and potential clients are interested in launcher other than as backup option when ftrack is down. It's too much hassle for artist to click through it considering they always first need to find ftrack task for comments and overall context. In Kredenc for example it wasn't launched a single time in past 4 months.

Second thing is that we found that users prefer launching global actions (the ones in launcher visible without a project), from tray icon menu directly. it's quicker. We have a good version of tray, that we're happy to share and push to core if there is interested. Looks like this

image

That's just a really quick one from me. I think it could me made much more useful fairly easily. So I'll comment more in a bit.

mottosso commented 5 years ago

The launcher could maybe facilitate all the data from the production tracker, but that seem like a lot of data syncing for little gain.

I was thinking about this and think you're right; the amount of data that would effectively need to be duplicated isn't a good way forwards.

So then it got me thinking that maybe the answer isn't to:

  1. Duplicate the data
  2. Use the duplicated, now internal, data in Launcher

But instead to:

  1. Read from optionally implemented "hooks" in Launcher

A hook could be e.g. external.find_icon({"type": "icon", "project": "Spiderverse", "asset": "ab1002"}) which doesn't actually read from the Avalon DB, but rather calls on find_icon which may or may not be implemented in a config. A vanilla config could then, e.g. take this query and always return the same generic icon. A studio could implement a studio-specific, but still generic icon for all assets. And finally, a studio could implement the function to take into account their internal projects, which in turn may call on cgwire or ftrack or what have you.

So long as the function always returns the same type, perhaps given the type key, then it'd be entrely polymorphic; i.e. it's a duch if it quacks like a duck.

This way, we could support arbitrary external data, without duplicating anything.

One immediate consequence is that queries could take longer than normal queries to the Avalon DB, e.g. if they physically connect to an ftrack db somewhere. But for that we could quite easily implement a caching mechanism under the hood of such calls to remedy that, and/or make any calls to external sources asynchronous and take a callback for the result.

tokejepsen commented 5 years ago

Think "hooks" sounds like a very interesting idea! I guess they aren't just going to be for fetching but also pushing data back to the trackers? For example updating a status or adding a comment is still needed in the production tracker, because coordinators aren't going to be using Avalon.

One issue I could foresee is accommodating the workflows of the production trackers. For example CGWire and Ftrack may not have the same idea how commenting works. One could work with a flat commenting, and the other could enable users to reply to comments. Think Slack, where you can both comment in the channel as reply or reply directly to a post.

mottosso commented 5 years ago

I guess they aren't just going to be for fetching but also pushing data back to the trackers?

Exactly, they wouldn't need to as Avalon isn't the place for authoring such things. I think we can leverage that property to make the interface that much simpler.

One could work with a flat commenting, and the other could enable users to reply to comments.

True, each hook would need to translate the data to something that make sense for how things are drawn in Avalon.

tokejepsen commented 5 years ago

Exactly, they wouldn't need to as Avalon isn't the place for authoring such things. I think we can leverage that property to make the interface that much simpler.

I was saying that Avalon would need to be able to push data back to the tracker. For example comments. If we are wanting users to not spend time in Ftrack, we would need to facilitate all the needs of the user from the Ftrack interface, like replying to comments.

mottosso commented 5 years ago

If we are wanting users to not spend time in Ftrack

No, that's not what anyone wants. Avalon and ftrack serve complementary purposes. Also this issue isn't specifically about ftrack, but about making Avalon better, especially for those that don't use ftrack or want/need an alternative.

What I've got in mind is for production data - including but not limited to comments - to appear throughout Avalon, such as in the Library and Launcher, when relevant to what the user is doing.

Both of these are things a user shouldn't have to go someplace else for, they should happen in-context. Likewise, if they are already in ftrack, then it would make sense to also launch an application from there, and it's good we're able to facilitate both.

Lowering the amount of context switching is key here.

BigRoy commented 5 years ago

Some work has been done on trying to test an integration with allzpark as a launcher for Avalon. and for future reference I also wanted to link the gitter discussion about Avalon + Allzpark too.

Also see: https://www.youtube.com/watch?v=5BkQL6TG1-A

And there's now an own issue for it: https://github.com/getavalon/core/issues/409