Based on input in regards to the current UI being too complex and carrying too much information at the same time, let’s have a chat about how to best simplify things and make it more friendly.
Here’s a small suggestion.
Where the current view is located under the Overview tab, and the comment would end up in context.data["comment"] to be optionally handled by your plug-ins.
What else is good?
I still think the artists want access to the instances to choose what to publish.
As I said in the other thread, I think the most condensed view would be to have instances and attention required plugins like errored ones.
I was thinking that you could have the list of instances, then when publishing, the right side would populate with errored plugins.
Bring out the mockup pen so we can all have a clear view of your idea. It doesn’t have to be animated, though you get 2x bonus points if it is.
Edit: for reference, here’s the other thread.
Do you animate yours or mock up the gui and record?
I use Photoshop, it has that “timeline” feature where you animate layer visibility on and off.
So I’ll link this back to an issue on github and the topic where this was discussed before. Just those don’t get lost
I agree with Toke in that artists need to see instances and be able to toggle them on and off. Secondly I’d keep any optional plugins in the ui too, so artsts can have some control over formats exported for example. Any other plugins I’d only show in case of problems.
Overal I’d make the UI bigger. Actually I’d say that a version of the one mentioned here would still be the best.
Here’s an ugly mockup so take it with a pinch of salt.
Left - Instances and maybe basic info about them.
Middle - Optional plugins and those that developer specificaly marks as visible. (or the other way. showing all and giving option to hide from UI when writing plugin)
Right - Additional publish info. Ideally Each of of these might be a plugin, so we could populate it with what we want. This could be shared the same way as plugins now. This would require giving developer an option to choose how such plugin would show up in the GUI (image box, text box, button as other plugins…) This is probably a feature on it’s own that would need to be discussed, but hopefully you get the jist.
In case of failed plugins, we could either roll them out from the bottom, just switch to the overview tab, that could look the same as publishing now, where these could be dealt with.
Here a slight adjustment suggestion for @mkolars design, which might also simplify the ui development.
Here is the simplified view I was talking about;
I realise now that I left out the categories of plugins, so sorry about that. I think @mkolar suggestion with showing optional plugins would be great.
So initially there are only optional plugins showing. After the publish/validation, the GUI shows the failed plugins as well.
Great suggestions everyone. About this last one, I like the minimalism of it, but don’t you think it can get a little bit confusing, or even frustrating seeing things pop up you didn’t know were there?
I don’t think the artist care about that. It is certainly annoying for developers, but developers would know to look in the overview.
I agree with @tokejepsen here. Artist really don’t need to know what is being validated, unless it fails. Best case scenario, where artist had a a very clean scene, it gets published without bothering him at all. Worst case, he gets a list of things he needs to deal with.
Maybe I’d add a little status bar on the bottom, which would just print what is being done currently so he get’s progress of publish in some way. You can seen what is being processed now by it being highlighted in the UI, so equivalent of that. Just so it doesn’t look frozen if everything goes well and it takes a while.
Thats a good point. +1 for progress bar or similar.
I’ll plus 1 this too, having recently had some experience with this from an artist’s perspective, I can see how most things in that list are a nuisance unless they need my attention.
As a hint, I think implementing this should be very simple; the mechanics of hiding and showing items dynamically based on their data within the model is already there (it’s what happens when there are no supported families, for example), and the data already being updated.
It’s done through a “proxy” that either includes or excludes items based on their data, so you could simply add another filter to it to only include items with it’s data hasError set to true.
Either way is good. I think right now, the Overview is sort of a mix between two ideals; one where we see everything, and one where we only see what is relevant at the time.
If we go the route of slimming down the overview to only showing relevant things, and making a new view for the more “expanded view”, or if we go the other way around, making a new view for relevant things, I think both are good paths to take. Whichever is simpler to implement might make sense to implement first.
I posted this elsewhere but should reference it here as well: Simpler GUI mockup
A simpler overview for the artists:
The overall idea is:
Processing... or even related to the plug-in type that’s being run, like Collecting..., Validating..., Extracting...
I think it’s important to:
This would be an additional tab that runs as the default one.
As such more in-depth debugging could still be done.
Here’s one from me.
Like @BigRoy suggested, the tabs would provide access to the current overview and this could serve as a landing page.
Some of the things happening in the gif.
As I was making this, it occurred to me that a straight-line version might be an interesting alternative. It would feature the exact same thing, but either be a horizontal or vertical line, where the rest of the GUI would be populated with the status messages, and probably do a better job at it too.
Here’s one from me.
Wow, alternative! 
What about optional plugins?
If we are to have some plugin/context input from the user at some point. The user would need to select a plugin.
Maybe they could each have a little white checkable flag? Filled versus hollow for checked status.
Or maybe, when you hover that portion of the circle, checkboxes could appear where there are optional plug-ins?
Very interesting.
Somehow I’m completely missing what the artist would still want to manage/see easily, like the toggling of instances so they know there work is “processed” like they think it is. (For example seeing rig / Peter01). Just some basic reassurance of what will be processed before clicking “Play”.
I’m also thinking the Artist cares less about the amount of Plug-ins that will be run, but more about what Instances are processed for what “family” (and for them they are not interested in “family” since they won’t know what it means without some Pyblish background). They would be interested in what’s processed and does it process and produce the output I’m expected to create from my work file.
Even though I love the look of this I’m imagining this particular one to be a “sidebar” kind of thing or one that would be nice for something that processes in the background: Just a “ok it’s processing” feeling than something you would open up to investigate for seeing the information. Does that make sens?
Here’s another minimal mockup based on your circular one. This kind of provides the information that I’m assuming the artist is looking for.
Still I’m thinking that the features like “toggle all” for a specific family was added based on Artist’s requests. So even in the minimal form I’d opt for a structure (or layout) that would allow you to see them “grouped” by family where you’d be able to click the family and toggle all…