• Editor
  • [Editor] Ideas for the UI

A few months ago, I drew up a super rough mockup of UI changes that I thought could solve some of the less optimal parts of Spine's UI: https://dl.dropboxusercontent.com/u/567 ... 201306.jpg

A lot of things have changed since then and Spine Editor now handles more complex setups better. I don't think these changes (or changes that solve the same problems) warrant immediate implementation or attention, but I thought it would help (Nate and Shiu) if there had a bigger pool of ideas for improvements you could pick and choose from, or argue against. I definitely don't think these are the best and most optimal solutions but I guessed it's at least useful as something to think about and push closer towards a really good solution to some old, lingering UI problems.

(1) I thought the Animate Mode/Setup Mode toggle was too far to notice or reach. Apart from giving it a shortcut key, I thought it would be a good idea to move it down next to the Dopesheet. This would make it visible at a glance and easier to reach with a mouse. Thinking about it now though, I guess a shortcut key would suffice for the reach problem.

(2) I thought the animation name was also very obscure. I thought it made sense to put the name right next to the big Animate (Mode) text and in the viewport. But also thought it would be a good place to put a shortcut to select animations instead of needing to scroll down to the animations node in the tree.

(3) Likewise, the currently selected Skeleton and Skin can have their big-text indicators too, which also double as shortcuts to switch between (or manage?) different skeletons and skins.

In general, I think indicators for "what am I working on/looking at right now" should be right next to the viewport at least and not scattered in 5 different places. Or maybe they could be scattered but not something you have to move your mouse at all for.

I guess the big-text indicators might not look so good if they're always on, especially in smaller screens.

Or there could just be a key you press to see all these things in one place and switch between them. (skeleton, skin, animation)

(4) The "bone-inspector panel" mockup is just a bunch of loose ideas as to what functionality can be moved away from the tree so the tree can be more consistently useful for getting a good read on and manipulating the hierarchy of the bones. In my mind, this is probably an alternate view you can toggle in and out of instead of one that totally replaces the current one (which has its merits for closely mirroring the structure of the JSON). It's also probably something much smaller and of a radically different shape than I drew here.

So yeah. Just ideas to get a constructive conversation going.

Related Discussions
...

Cool, it's good to think about all kinds of improvements. 🙂

1) A hotkey would be good.

2&3) Spine can work with multiple animations (in different skeletons) concurrently. There may be some improvements we can do when working with a single skeleton and animation, as that is quite common, but we don't want to lose the multi skeleton and animation functionality.

The tree has the most flexibility to provide all sorts of functionality, but you're right that it isn't as easy to use as other approaches could be. It's a deceivingly complex data model. If we do try to change the tree or add new UI sections we have to take all the use cases into consideration. Doing this while developing the app is asking for trouble and extra work. As things settle down I think it makes sense to think about, and we might be getting close to that point.

We should think about the use cases that the tree makes awkward. The filter buttons can make working with only bones reasonable as well as provide alternate views for other use cases (draw order, filling in skin attachments, etc). Switching animations is a bit annoying, especially since you have to scroll way down. What else?

It would be nice if the tree would be separated in the sections that people use the most. For example, we can have the little window as is, but with only the setup of the skeleton / images / skin and a separate section for Animations, which would scroll independently.

This way, scrolling the skeleton area would not scroll the animations area, and switching them would be much easier (this would be applied to another sections too, like images which needs a lot of scrolling when you do the setup of skin attachments / slots).

I'm not asking for flying windows (like eclipse, visual studio or other IDEs) but separating the tree in some sections with their scroll bars would be enough I guess 😃

Spine shows multiple skeletons (each with their own animation). I think it's an awesome tool that lets the animator see and animate different skeletons in each others' context and align things much more easily without resorting to putting a million markers on backgrounds or whatever. I'd hate to see it go too. I've already used this feature and I LOVE it. : p

I don't think the single persistent current-skeleton & current-animation indicators conflicts with that feature, but there could be other things that affect it or other things you're planning. So I don't know.

But as it is, the editor already focuses on one skeleton at a time anyway: the "active" skeleton is the only one that's at full opacity in the viewport and the other skeletons are made a bit more transparent.— I really like how this was handled in the viewport, by the way.

I was thinking the big skeleton name and animation name would be for skeletons that are actively being selected/edited/animated. And you could switch between skeletons through that too (or it automatically switches if there's some other way to select other skeletons in the viewport) So the list of animations and the current animation would be contextual to what skeleton that's currently "active".

Or something similar would serve this function of being a kinda persistent indicator of what you're currently working on. Maybe the current skeleton/skeleton selection could have something like browser tab UI. It could be in combination with the big-text animation name. I dunno. : p

Totally right about the use case of switching animations. More palpably:
One task that needs to be done when polishing an character skeleton after previewing and testing and saying stuff like "hmm. The run looks a bit weird where it loops" or "we need to change the pose to make him run more like Bugs Bunny."; the animator would need to modify several animations in each other's context. With animations transitioning into one another and poses being interrelated, you need to do a LOT of switching back and forth or between animations and moving bones and keying images or whatever (so you also need to keep the filters off, at least for now while there's no other way to key image swaps— or draw order changes...?).

Having the tree scroll to and highlight the currently selected bone is a great feature. But the current setup makes you lose sight of which animation you're working on (visible in the dopesheet, I know. Where it is is also still really obscure and can still be scrolled away.) or the other animations you need to switch to. It gets a bit hard to find animations too when there's so many of them and the list keeps scrolling around.

I think as long as they're in the same tree, a long list of bones and a long list of animations aren't fun to work with. :p

There's also this other related thing for this polishing task were you have to copy a pose from one animation to another. It gets kinda complicated when a pose is a result of a combination bones reaching that final pose at different points in time. But that's a story for another time. xD

17 días más tarde
Pharan escribió

Having the tree scroll to and highlight the currently selected bone is a great feature. But the current setup makes you lose sight of which animation you're working on (visible in the dopesheet, I know. Where it is is also still really obscure and can still be scrolled away.) or the other animations you need to switch to. It gets a bit hard to find animations too when there's so many of them and the list keeps scrolling around.

I think as long as they're in the same tree, a long list of bones and a long list of animations aren't fun to work with. :p

You can turn off the auto scrolling in the tree, the target looking button next to the tree filter buttons.

I have read everything you wrote and I'm sure at some point we'll look at improving the workflow by changing the UI. 🙂