tokejepsen
commented
9 years ago +1 for C
Open mottosso opened 9 years ago
tokejepsen
commented
9 years ago +1 for C
mottosso
commented
9 years ago No love for colors? :) How about the icon? I was thinking that in the future, the icon could come from a database of sorts; like a thumbnail for the asset an instance represents, and plug-ins could have an icon too.
E.g.
/validate_namespaces.py
/validate_namespaces.pngThink I'm leaning to towards as simple as possible, which is probably just my taste:)
mottosso
commented
9 years ago Personal taste is fine :) I'm no designer and need all the help I can get.
mkolar
commented
9 years ago +1 for A If the coloring is based on families.
Icons and Thumbnails are great. It makes it quicker to see what is going on.
mkolar
commented
9 years ago Looking the pictures again I'd say that it's gone a bit too far in simplification. Just before publishing artist should see, what instances he's about to process (as is no the pictures), but also what is going to happen to them (Extractors).
mottosso
commented
9 years ago +1 for A If the coloring is based on families.
It could be.
Just before publishing artist should see, what instances he's about to process (as is no the pictures), but also what is going to happen to them (Extractors).
Sounds like we're almost back to where we started then. :) Feel free to doodle and share sketches of what you have in mind.
mkolar
commented
9 years ago Sounds like we're almost back to where we started then
Partly yes. I think it jumped between 2 extremes. 1st one had too much information (all the validation plugins), and this new one doesn't have enough.
Number of plugins processing an instance is irrelevant for end user. He should only care about the ones that fail. Or it needs to be clearly labeled as 'validation' #number doesn't tell him much. Seeing how many validators run is only useful if artist also sees what they are validating (so he knows what to look out for next time to make the scene pass on the first go), but that would bring us to square one.
This is what I think is important for artist to see at glance.
And these should be available upon request (maybe a rolout or something similar)
So practically I'd have 2 layers of UI.
mottosso
commented
9 years ago Summary of outputs he's going to create
When I first read that, I assumed you meant a summary of files a publish is going to create, but then it struck me that you probably mean a summary of outputs as in which "type" of output, e.g. to show the extractors themselves.
Showing future outputted files on the other hand would probably get really complex.
In any case, yes, definitely agree.
Description box where he can write comments that get passed on in conform step
This is a good idea, the comment box could simply append data to the context! I've struggled with how to make this as generic as possible, without getting too deep into how to finally store the data on disk. But this way, the GUI would be oblivious to how the comment is used, and any conformer could pick it up and make use of it.
Like!
Statistics (time it took last time etc. )
This is where Perspective comes in. It's coming.
So practically I'd have 2 layers of UI.
I've also thought along these paths. About having a button somewhere in the GUI where the user could switch between advanced and simple.
If you have any pictures in mind, could you mock something up and post it here?
mkolar
commented
9 years ago you probably mean a summary of outputs as in which "type" of output,
Mainly yes. So the artist is aware of what he is producing. Especially in case of pyblish which doesn't really have concept of primary publish (aka Scene file) by default. For instance animator could see list like this in outputs:
As you said, they should probably correspond to extractors. That way the functionality of optional extractors could stay intact as he would be able to untick them in this box.
mkolar
commented
9 years ago But this way, the GUI would be oblivious to how the comment is used, and any conformer could pick it up and make use of it.
I'd say that ideally we would give studios option to fill this space with more types of ui elements based on his choice (user input area). So every studio could then choose what extra info they need from artist and put it there. This would be very powerful if these user input UI elements could be created base on some attribute in plugins 'or whatever type of config'.
Example: If a conformer expects comment from user, this comment box would get created on the fly. So to make that ui item plugin could containt something like this
'UIextras': [
{
'label': 'Comment',
'type': 'text',
'name': 'comment',
'value': 'Write a comment about this publish',
}
]Another conformer expects A dropdown of options (e.g. statuses) for artist to choose from. so we would add this to plugin script.
'UIextras': [
{
'label': 'Status',
'type': 'enumerator',
'name': 'status',
'data': [option1, option2, option3],
}
]Pyblish finds this info when loading plugin and prepares UI based on that. This is of course just to illustrate the point. I've taken the config format from recent ftrack feature, which does exactly what we want here, but for web UI.
The point is to allow user to add simple UI elements to collect extra data from user, that would get passed into context and picked up by plugin.
mottosso
commented
9 years ago As you said, they should probably correspond to extractors. That way the functionality of optional extractors could stay intact as he would be able to untick them in this box.
Yeah, makes sense to me.
Especially in case of pyblish which doesn't really have concept of primary publish.
"Primary publish" is that a Shotgun term? Seems a bit ambiguous to me. To me, a publish is a serialisation of whatever it is you're doing, regardless of the amount of files being generated or which formats they are in. Primary and secondary seems to suggest only two levels of interest, either it's mandatory (always on) or optional (always off).
mottosso
commented
9 years ago The point is to allow user to add simple UI elements to collect extra data from user, that would get passed into context and picked up by plugin.
I like that, I'm seeing this sort of feature it in the new forum as well. Shouldn't be too difficult getting implemented either.
mottosso
commented
9 years ago What would such a feature be called? The forum engine (Discourse) calls it "User Fields".
mkolar
commented
9 years ago "Primary publish" is that a Shotgun term?
They use this terminology too, but aside from that. I see it as the file user is working on (source file that you need to create all the other (secondary) publishes. So maya scene I'm working on is primary and everything else being exported from there (alembics, cam, anim curves), are secondary. In our thinking Primary is always mandatory (it's the most important piece that takes long time to recreate), whereas secondary can be optional (and can be generated from primary without using any man hours). But it really is just about way of thinking I didn't mean to steer this issue into something else :)
What would such a feature be called? The forum engine (Discourse) calls it "User Fields".
'User Fields' sounds very clear to me. for reference this is how it looks in ftrack actions
Goal
To reduce clutter and bring forth what matters to artists.
Implementation
The first thing a user sees is the discovered instances and their history.
On a local machine without sense of history, publishes from previous runs on the same machine from the same hosts are considered. On a cloud-connected machine, history from previous runs would give the user a hint towards what to expect in terms of how long it may take, and how often a particular instance has been published (perhaps even a total, i.e. how many version it has).
Information per instance
Mockups
(click for full-size)