Initial Design

[mottosso]

Goal

Establish an iconic look for Allspark.

Motivation

What we've got currently is functional but plain.

Implementation

Draw inspiration from GAEA and Meshroom.

• https://www.youtube.com/watch?v=1A1xXfTlKqM
• https://www.youtube.com/watch?v=v_O6tYKQEBA

Or, from Haiku, where the current icons are coming from.

• https://www.haiku-os.org/slideshows/haiku-1/

[dgovil]

Made some annotations of what issues I think this iteration of the UI has with the assumption that this is an artist facing tool first, and a TD facing tool second. Right now I feel like a lot of the design decisions are TD first.

[mottosso]

Thanks @dgovil, these are great! Will incorporate these into the design.

One thing worth mentioning that I think changes some of the comments, is the "Advanced controls".

It's meant to separate between what an artist and TD needs.

[dgovil]

Ah interesting, I missed that part. I also didn't realize there was a right click to launch various other tools, that's pretty neat.

[mottosso]

Cool, glad you like it. But you're right though that it isn't obvious. Maybe adding a tooltip/statusbar message about "Right-click for more options" would work?

The right-click is coming from the "tools = []" section of a Rez package, where the bottom part is added to every package, relative the platform.

[dgovil]

This is a quick mockup in XD. Trying to pare it down for what I think would be more in line with what I'd give artists. Might be a bit too minimal, but my goal is to have the main actions be the first thing you see (assuming sidebar is collapsed by default)

In terms of features:

• The configuration allows 3 fields by default : show, shot, task. This will allow studios with many tools (Imageworks and RnH had tons of tools) to cater configurations for specific departments. We also often needed to have alternate package loadouts for animators versus modelers etc.
• Shows if applications are localized or not (if localization is enabled of course)
• I didn't detail out the sidebar because I'm a little confused what all your current panels are, but I think they'd just be represented as tabs.
• Searching would be good for artists if there are multiple applications, so they can cut through the noise.
• Less common actions like launching a terminal, configuring preferences and getting help are in the bottom right corner.

My goal with this kind of design is that everything an artist needs is available right away without needing to right click or delve down into a side panel, but things for TDs are still available but one step away in the panels etc...

[mottosso]

Thanks @dgovil, that's a good start.

The first thing that comes to mind is that we should probably include more apps per default. The reference project I'm working towards at the moment has got 48 apps in a project. Some of which are "hidden", made visible via a developer/advanced toggle, similar to the other graphical items.

The configuration allows 3 fields by default : show, shot, task.

I was planning on having shot, and any arbitrary "level" visible, but having task is a good idea. Spontaneously, I'd imagine it being outside of the otherwise hierarchical project/episode/sequence/shot/etc structure, and apply to each of them separately, like modeling. But on second thought, if you're selecting task via the launcher, it must be to apply the associated overrides as provided by that tasks Package, so maybe it makes sense to include it in the hierarchy?

spiderman/
  episode1/
    ah05/
       1000/
          modeling/

Or, more realistically, a lesser amount of specificity.

spiderman/
  ah05/
    rigging/

That way, if there isn't any relevant overrides for a task (or shot etc), then there simply wouldn't be a package to select. Probably need more time to think that thought.. but does that make sense?

Shows if applications are localized or not (if localization is enabled of course)

Curious why to call it "cache" if it's "localised" and not "localised"?

I didn't detail out the sidebar because I'm a little confused what all your current panels are, but I think they'd just be represented as tabs.

That's a nice design choice, but there's one more feature not immediately made visible (yet) from the landing page which is the reason the tabs are outside of the side panel, which is the "master layout".

Searching would be good for artists if there are multiple applications, so they can cut through the noise.

Indeed, good idea.

Less common actions like launching a terminal, configuring preferences and getting help are in the bottom right corner.

That's a good idea. It's not as consistent, but perhaps expected. At least of "advanced" controls like a console.

Thanks again. I'll be on dedicating most of next week to applying these ideas, so the more you're able to throw at it till then the better!

[mottosso]

Forgot to include the mockup-mockup of the first point! Notice how the buttons and additional colors start to create noise.

[dgovil]

Notice how the buttons and additional colors start to create noise.

Yup, you're right it can get pretty noise. I should have added more items in there. I think that could be solved though by getting rid of the Info column and making the Run button just a small Play icon.

That way, if there isn't any relevant overrides for a task (or shot etc), then there simply wouldn't be a package to select. Probably need more time to think that thought.. but does that make sense?

I think I'd see the specificity as some form of layering.

So you'd have essentially

Facility
- Project
-- Shot
--- Task

where each one is a layer on top of the last. So if there's nothing specified for the Task, then it would just show the items from the shot, and if there's nothing specified for the shot, it would show the items from Project, and finally Facility.

So the configuration at each point would allow for things like overriding and filtering the previous 'layers' items.

Then there's also the issue that the Task layer may be defined at many points.

Facility
- Task

Facility
- Project
-- Task

Facility
- Project
-- Shot
--- Task

In my experience all of those are valid, and in previous companies, we'd have the most specific task win.

Usually we'd do this by finding the task under Shot -> Project -> Facility and break as soon as we find one.

It sounds a little unruly, but the implementation isn't too difficult and it's the sort of complexity I've hit on so many projects, that I think it's worth addressing.

But we should definitely discuss more, might be good to bring up in the slack etc...

Curious why to call it "cache" if it's "localised" and not "localised"?

Brain fart on my part. We called it cache in various places I've worked, but I'm more keen to not even have a header, and just show the icon if it's not localized/cached.

This of course ties in to your localization efforts, but I think it's good feedback to provide to know why an app may not launch right away.

That's a good idea. It's not as consistent, but perhaps expected. At least of "advanced" controls like a console.

Agreed, it's not consistent, but I think more technical users would excuse that as a concession to them.

---

Obviously this will need some iteration and riffing between us and anyone else willing to take part. Good to have this discussion going like this now.