Build Great Tools: Workflow Guidelines from Vicarious Visions

[Music] all right before we get started we have to do something really important on the count of three i want everybody to do jazz hands okay one two three thank you for that there will be more jazz hands at the end of the talk let's get started suppose i want engineers at my studio to be able to build tools now maybe these are new engineers new hires or maybe they're veteran engineers who have been working in a different discipline altogether and haven't done a lot of tools work in the past let's say i want them to be empowered to bring great tools to whatever teams that they are working on and i want them to create tools that fit into whatever tools ecosystem we already have at the studio so what advice would i give to such an engineer who's interested in

doing tools development what do i wish that somebody had told me what can i impart to them well i might think back over all my experiences and all my trials and errors and trials by fire and i might say something like don't build tools for engines too many of us build tools that have the engine as their primary customer but the engine isn't our customer it doesn't suffer it doesn't call for help it doesn't have great ideas to make the tools better so as nice and pithy as that is i think we can do better it's easy to say don't do this or don't do that but what do you do instead we build tools for humans yes our customers are human and humans think about things differently than engines do humans also make mistakes but that's not good enough because an engineer might just build tools for themselves right something that reflects how they think about the game content that's

being built build tools for humans who aren't you this is good because while you as an engineer are probably a brilliant technical mind you might be building tools for brilliant non-technical people but i like this though this is starting to sound more like what all the ux books out there tell me to do design with your users in mind right it's getting better but i'm not quite satisfied with this because game development has this weird problem we have a lot of engineers and they could turn out human-centered tools it's true but then maybe you just end up with a pile of tools does anybody here know what i mean when i say a pile of tools i see nodding heads are they fun to work with i see shaking heads so it makes me wonder are we building the right thing and i want you to build tools i want you to build workflows things that comprise all of those steps

that content creators take right and all the tools they involve and how the users flow through their work i want users to have a cohesive coherent experience it's getting there right this idea that you should build workflows for humans who aren't you is something that i think most engineers would agree with philosophically but even this is over simplistic making it practical is especially hard and making it practical is exactly what we wanted to do at vv because we're interested in enabling disciplines to work together and collaborate and we want new engineers in this space to be successful quickly so what i'm sharing today grew out of sort of this line of thinking we wanted to distill learnings from our past and our successes into knowledge that could guide future engineers even non-tools engineers because we did have past success

shortly after i started vv i worked with other tools engineers to create alchemy laboratory alchemy is vv's proprietary engine tech and laboratory is its tool set all of its tools are oriented around workflows which roughly mapped two disciplines and our users could mix and match different parts of the tool to craft whatever worked best for their workflow this for instance is the world built the default world builder workflow where we built levels for skylanders and crash this is visual script builder wherein we built visual scripts there are other workflows in the toolset too for ui and vfx and cinematics and localization and all that laboratory was a big investment in workflow development at vv and we came out of it with really good results i got to work with some crazy smart engineers who had a passion for building tools with users and produce great results in the year that we brought lab online workflows and efficiencies were seen as our studio's biggest strengths

and our users rated them very highly compared to others that they had used in the industry we don't attribute our success in laboratory to any one guiding principle nothing that simple laboratory was the culmination of years of tools engineering expertise and a lot of it came from trial and error and a lot of it came from investment in new things and conversations with users and partners and some of it was learned through disruption and false starts and inefficient deliveries so we wanted to codify some of what we felt had made vivi successful at workflow development over the years we also wanted to provide direction for future efforts right we wanted to sort of declare where we wanted our investments to go in a blue sky sort of way we wanted to make something that we could share with engineers that were new veteran engineers and now good people like you we created a set of wiki pages and we

called them our workflow development guidelines the original target audience was those engineers i've been talking about who wanted to participate in workflow development but i think that this advice is consumable by really anyone working in this space tools designers ux thinkers and the like the guidelines themselves are technology and project agnostic and they're organized into three categories ui and ux design engineering and implementation and something i call creative mindsets we want engineers to look at these guidelines and think okay this is something i can actually do this is concrete this is a trade-off i can make this is a decision i can think about or talk about with my team now standard gdc disclaimer i'm sharing these because i feel that they will be valuable to your discussions back home i hope you agree but they are not the only way this is not the one true path these are what we want not necessarily what we have remember some of these are

partly aspirational i think though that you'll get a lot of insight into what we have come to value based on our past experiences and where we think ground is still fertile they are not scientific what you're about to see is more of an applied retrospective it's a distillation of many past wins and not wins observations conversations lessons learned and all that business it's not backed by any quantitative user research though we would not discourage that or we wouldn't turn it away but they are sound recommendations despite the lack of hard data and they have sparked some really good conversations and back home not so much here this is a living document i was making changes to these guidelines as recently as last night so we expect these to change over time as our business changes as our engineers change and as our learnings change so we'll start with user interface and user experience

design a lot of you probably know that ui and ux design are really big fields outside of game development there's been an upward trend in ui and ux jobs over more than the last decade and it's my opinion that the literature is sort of still catching up to some of the practical aspects especially game development a lot of it i find is geared toward helping people buy stuff online which is not really what we're trying to teach our engineers we wanted something that was more approachable these guidelines are more of a highlight reel these are lensed through experiences we've actually had that the literature probably wouldn't even know how to emphasize all right the first section is boost workflows with keyboard support because skilled users have very high expectations for making keyboards a part of their work to help them work faster here are some things you as an engineer

can do you can support precise input because users may know exacts they may know exactly how many missiles a turret should fire they may know exactly how long a cinematic shot length is don't force users to type in an exact quantity don't force users to express an exact quantity using anything slower than typing it on their keyboard they will appreciate the acceleration it is however good and clever to blend gross precision with precise um sorry gross input with precision inputs such as using controls like a drag slider there where you can type on the note click on the number to type something new in or you can drag it like an up down spinner you can accelerate data entry by anticipating input users should avoid typing what the tool already knows or can infer users may know exact names or identifiers or they may only know fragments of them you can support both with predictive input or you can anticipate those little micro

workflows so if you think of file open as a micro workflow that's something you can accelerate too with like a recent files list you can accelerate tasks with shortcut keys shortcut keys save users time by reducing mouse movement or streamlining the flow from one activity to the next so for example if a user intends to select two objects group them and then move the group you have an opportunity to accelerate that by adding a shortcut key to the group operation right generally you should favor assigning shortcut keys to actions that would otherwise require the user to shift their focus away from what they're currently looking at and you should also beware shortcut key pitfalls because users are prone to typos so don't put create next to delete be careful of proximity shortcut keys are a scarce resource and unless your workflow has a very good custom binding mechanism

be judicious about assigning new ones because shortcut keys are forever users internalize and habituate these very quickly and after they've had that opportunity you risk changing them at your peril can make keyboard support discoverable tooltips are great for this info tips too like the kinds that you see in just about any microsoft product right now right you can promote discoverability also by deferring to idiomatic shortcuts ctrl s always means save f2 always means enter some kind of editing mode if you're in a text field next section build cohesive workflows or features that play together stay together cohesive workflows feel organized and task oriented and integrated with the user's other work while incohesive workflows feel disjointed scattered they may even seem incomplete here are some things that you can do you can promote discoverability and find

ability discoverability is the degree to which users can discover what features are available to them findability is the degree to which they can find what they already expect to be there and to promote these things you can keep things close together clustered by task like this doesn't do this is a screenshot from laboratory laboratory context menu in the world builder one of these things is not like the other remember i said this is what we want not necessarily what we have keeping things close together can mean minimizing certain distances concrete and abstract distance can be mouse movement eye movement it can also be number of clicks number of levels deep in a menu that a person has to go in order to find what they want over time users are going to build a strong mental map of your workflow and over time they're going to learn where to find what they expect or they're going to know how to make a reasonable best guess they're also going to remember what they haven't tried yet so they can go back to

it later you can avoid dumping grounds you see this most with any settings dialogue and in some rushed ui designs where widgets are sort of thrown into a big pile because nobody knew where else to put them dumping grounds indicate poor cohesion in your workflow maybe you're not clustering things quite appropriately you are at risk of users having to do lots of parsing and scanning to find the things that change the behavior they're interested in if they find it at all and don't give up and the bigger these get the harder they are to internalize and the more likely users are to ignore them so pay attention to how you group things in your user interface pay attention to offering searchability and filterability and things where long lists are the rule of the day we see this good trend right in a lot of settings dialogues you're probably familiar with like resharper lets you search for settings ios chrome we're seeing it more and more and

more you can understand the before and after users may already have previous steps and next steps in the front of their mind as they're working they might have context switched into your workflow and they're very likely to context switch out of it so consider where is that attention coming from where is it going next are those contexts easy to switch between is the user having to do any mental gymnastics or heavy load conversion in order to sort of ship their their mental map from one context to another if so is there anything that you can do to help can your workflow or some software integration help ship meaningful data between contexts can your proprietary tools send data to the dcc tool so that the user can avoid a big export import workflow it's probably worth it you can ask yourself what bigger task

what bigger creative goal maybe is the user trying to accomplish because that may affect the inputs and the outputs that they either have or that they want that your workflow may have to produce talking to them is really good for this in the engineering section which is general guidance about sort of some of the implementation details that we find are really helpful you can practice defensive engineering consider the potential for abuse because users are always looking for the paths of least resistance one tools developer at vv was always fond of saying it is amazing what content creators will put up with and i'm sure a lot of you know what suffering and silence means scott meyer is a famous programmer he had some really good advice for people who were building interfaces in code he said make interfaces easy to use correctly and hard to use incorrectly and i really

like that i think it applies really well to workflow design as well because if it's easier to do something if it's easier to do something the wrong way and still get the same result you should expect that your users will find and converge on that way they will tell their friends they may find shortcuts to circumvent certain validation processes in your tool we had a problem for a long time where users would modify game data in notepad after a bad merge because the workflow for doing it in the tool was harder we had some that's a problem we had to solve whenever flows get bad like that the increase that it increases the likelihood that users are going to look for shortcuts and it's always happening you can avoid exposing everything this is similar to dumping grounds but this is more about focus and reducing demands on users attention

there are more knobs and dials in a modern game engine than any individual user is going to know what to do with and what we've observed is that when users are confused they'll just start probing the ui they don't know what anything means they'll just start clicking buttons to see if they can elicit a response from the game or from the tool eventually they're likely to get confused and into some confusing state and they probably need help getting out so it helps if you reduce your ui to only that subset of controls and knobs and dials the users need to do most of the job eighty percent of your users probably only need a subset that one user who really does need access to the texel blending function on the fourth technique in the pipeline they can go to a different part of the ui maybe an advanced dialogue or something like it avoid relying on tribal knowledge because it is a

fallacy that most users will know the right way to do something when faced with this situation it really hurts their confidence they'll literally start asking questions like what do i do next is this going to work i don't recognize any of these terms i don't i don't see any meaning here how do i make this do what i want especially for engineers who are working with other engineers tribal knowledge sometimes includes what you shouldn't do consider any engineering trap in your code base that everybody at your studio knows how to avoid knows that it's there knows to step around it now you partner with a different studio and there's no documentation and the other studio doesn't know that that pitfall is there vivi has been on the giving and receiving end of that particular relationship it is no fun i had a really hard time finding a visual aid for this slide but i did think this was fun this word cloud

is all of the names we ever gave to tools in the alchemy tool set prior to laboratory can anybody tell me vb guys don't current vv employees don't count but i'm curious to know if anybody else here can anybody tell me which one of these is the visual effects workflow or the world building workflow you can't what no you can tolerate surprises do what you can to tolerate the kinds of surprises that can cause people to lose work laboratory has really good fault tolerance it has auto save and recovery it has process isolation to make recovering from crass crashes faster fun fact auto save and recovery was motivated in no small part by our studio's propensity for power outages

they know what i'm talking about consider content models this is a kind of put yourself in the user shoes kind of guidance understand what content concepts your users are expecting to work with jacob nielsen is a researcher with the nielsen norman group and for years he's been doing usability research to try and make the internet easier to use and in one of his articles there's a really good quote says the system should speak the user's language with words phrases and concepts that are familiar to the user rather than system oriented terms and i think this applies to workflows really really well they ought to speak the language of the content creator right not the language of the system the engine for which their data is being produced i think we can introduce a concept here called content model that means the concepts and the relationships with the with which users express content ideas

in your workflow basically it's a metaphor in which they work right so for example level builders workflow exhibited a layer i'm sorry level layer group object content model it's pretty straightforward and all the users could tell you what it was and it mapped very well to the way that they thought about the content they were building in the level another example is our cinematic builder i believe that good tools and workflows should abstract away engineering complexity at every opportunity and they should fill gaps so that users have less mental mapping to do this ui expressed a visual effects queue as a resizable rectangle on a timeline you could drag the left side you could drag the right side and you could shift it in time but underneath a visual effects queue is modeled actually as an array of spawn and kill keyframe objects that are inside an array which is inside another array

the two instances are in no way related to each other it's purely up to the tool to make sure that they make sense this was confusing a preceding workflow took a much more literal approach to presenting that engine data those engine structures and make the user think about them hard which meant that users could put the start keyframe after the end keyframe it meant that the start and end keyframes were shown on separate tracks in the timeline and most of this was because our engine was reflecting over the data structures just automatically we we simply didn't build a custom ui until then good workflows that keep users close to their content will allow users to concentrate less on the runtimes demands and more on the content that they're building there are at least two really important representations in a workflow there's the runtime representation and there's the user's content model so

if you think of those as two opposing extremes if you as an engineer can minimize the distance between those two representations you will have saved yourselves a lot of complexity i call this category creative mindsets and my goal with this category is to capture benefits that are hard to quantify but still have an observable impact on user satisfaction you can call it touchy-feely roi i also want to reinforce some common sense that i think is easily forgotten or overlooked when you're in the trenches trying to build software but i also want to inspire right i want the people who who read these guidelines to come away thinking i never thought about it that way there might be some good ideas here invite your engineers to apply their unique expertise to the creative process

we'll start with promoting user confidence when a user is confident they will try cool new things without fear and when they're not confident they may avoid workflows altogether and they may tell their co-workers to avoid workflows altogether and they won't tell you that you've done this we've observed and we have been told that users work confidently when the tools are doing what they ask they can change their minds quickly and they aren't afraid of breaking other people they aren't afraid of introducing bad data downstream that somebody comes and yells about them about later because when that somebody comes and yells at them about bad content they introduced there's a better than zero chance that they will have no idea that they did anything wrong unless your workflow is good at pointing out those cases so here are some things you can do to promote user confidence sure that undo and redo work

this may be one of the single most important things for promoting user confidence because when you think about it undoing redo is more than just about correcting mistakes it's about what if thinking it lets people try things and then immediately discard that idea right or multiple ideas ctrl z ctrl z ctrl z it improves iteration time by reducing rework it reduces the cost of making mistakes and its importance even impacted our architecture for laboratory it offered undo and redo as a service at one of the lowest possible levels you could go so that all plugins got the benefit of it it was actually hard to build a plugin for laboratory that didn't feature undo and redo you can support source control this may not sound like a promote user confidence tip but hear me out you can save users a lot

of confusion mucking around in perforce because if you put yourself in their shoes for a second imagine how much of their content state they are having to reconcile with the depot state if they are unassisted that's actually a really large mental load and especially if your data contains complex dependencies and users need to remember that if they add this visual effect file they must also remember to add this texture and the texture binder and all these other things otherwise the build will break downstream and people will come yell at them if they don't have any assistance that's more likely to happen that erodes confidence it introduces doubt this was another case where our architecture was really impacted by this point like undo laboratory offers per force integration at one of the lowest possible levels you can go it's pretty much automatic and plug-in

authors don't even have to think about it you can do rigorous data validation don't allow users to introduce bad data downstream so for instance you can probably guard against them exporting assets that have 4 billion polygons you can probably help them avoid adding a bad reference a reference to something that doesn't exist users might not know though what correct or safe is so you should expect odd input in your workflow if something's wrong find it and tell the user what is wrong and tell them how to fix it that's important you can preview changes if an operation makes big changes help the user see what's going to happen before they commit to it for no additional cost give them an opportunity to change their mind you can do this before or after a change has begun and this is one example of what i'm talking about a lot of you have probably used

docking systems right and this one is previewing the change that you're about to make before you go to the trouble of committing to it another example is in our visual script builder when you slot when you splice a node into an existing connection the tool shows you what's going to happen to the connections unless you change your mind or unless you bail out laboratories curve editor had a similar feature by hovering over a button it will show you what clicking on that button would do if you in fact clicked on it you can show the path to safety when errors occur because is there anything worse than not knowing how to fix an error make errors helpful when they occur do your best to recover gracefully that is guide the user back to a familiar state from which they are confident they can continue and if corrective action of some kind is required be clear about those next steps do they need to

reload do they need to restart do they just need to try again do they need to enter a different value or reformat their value consider engaging users to give you feedback on your error messages and i don't mean type in what was going wrong when the crash happened i mean show them an error message as a sentence and say if a tool showed you this error message would you understand what it meant and then iterate on that mind feature requests for hidden value this is the guideline that i think resonates most with the people i talk to both engineers and creatives alike you should be aware of treating user requests as specifications by doing this you risk incohesive solutions when several different engineers who have all been told the same problem offer different solutions and create a franken app it can result in band-aid solutions that

leave root causes unaddressed and then lead to subsequent band-aids because the root cause is unaddressed which leads to subsequent band-aids etc and it can inherit bad practices from other workflows learn to recognize opportunities when you can help a user in ways that might not explicitly match the stated request right and or maybe it's in a way that they don't know how to ask for because they lack the vocabulary mind you you could be having new creatives you could have veteran creators who have completely different vocabularies asking you for different problems one of them might be coming from a different tool set where everything was completely strange and alien so if you ever hear somebody come to you and say something like i want it to work just like after effects or i want it to work just like excel you've probably got a communication gap you should probably dig

a little deeper because it's almost certain that you're not getting the whole picture there that's a very loaded kind of statement we assess our tools candidates partly on their intuition for this one of my favorite interview questions is to say a user comes up to you and asks that you change the transform gizmo to be yellow and i have some candidates who will without missing a beat they will tell me where in the view model they'll go find the color of the gizmo and they're pretty good about guessing where that is and they change it to yellow and they submit a code review and they're done and then i say okay now imagine that the undifferent user comes to you and says they want it thicker well some of them will say okay well we just changed the thickness i say now imagine a user comes to you and says they want it bigger and eventually the candidates have a sort of aha moment and they realize that continuing on this track is going to give you nothing but a big yellow thick transform gizmo because it's not the actual problem the problem is that the thing is hard to see

it might be hard to see because of what content is currently loaded in the world it could be hard to see because they have a super high res monitor and it's drawing one pixel thin lines what we want not what we have getting to the core of that real problem is useful because it's going to cause you to rethink the situation rethink the problem in more meaningful terms so talk to user talk to your users and discover that additional values you can try questions like this if you're ever stuck and you feel like you're not quite getting to the bottom of it you know back up a step and ask why is the user concerned with this at all i wouldn't have thought that this would be a problem maybe there's some maybe there's a gap in my understanding you can ask could we look at this differently could we maybe make a more general solution that helps more people with similar problems is this an opportunity to bring more value straddle that line of premature abstraction you know you want to

what player experience are they targeting right there could be a knowledge gap it could be that you already have a tool in your pipeline that does exactly what they want to do and they just don't know that it's there and you should ask yourself are there any potential bad habits unintended consequences so if a user comes to you and says i want you to change the default value of this field from one to a thousand and you do it have you blown a lot of budgets all of a sudden without realizing it be careful because that happens this section is called keep users close to their content we want creative people to see hear and feel what the player will see hear and feel success here means making exploring a creative space easy and fast and rewarding we want to increase the time spent seeing hearing and feeling and we want to decrease the time

spent learning how to operate an interface right learning how to navigate a pipeline this can be done by helping creative people notice little details showing them things in context so that they can appreciate it from a more player perspective or by enabling them to broadly explore a lot of ideas or deeply explore just a few of their best ideas i think tools can really innovate here a good case i think is user generated content tools little big planet dreams which they were showing earlier today and it is fantastic i loved it user generated content experiences are really cool because when you think about it they have one job and that is to make people feel like they are producing good creative coherent work reasonably fast i think there's a lot of wisdom we can draw from that i think that maybe these workflows might actually be participating in the creative process

itself this is getting into some of that more aspirational territory we're going to keep going you can support direct manipulation direct manipulation means making natural feeling changes directly to content instead of some intermediate representation so for instance dragging a manipulator in a viewport rather than picking geo in a in the scene from a list or something like that we embraced this with crash and brought some direct manipulation to a workflow that didn't have it before to choose and adjust bulk points that visual effects could fire from it used to be that you had to select the bullet point in a list first and then type in the adjustment you wanted to make to the bolt and then send that information to the game the mini step process instead we put manipulators right into the viewport and saved our users a lot of time and made everything a lot more intuitive

you can pick things from a list but to be more direct you could pick something in a viewport you could apply a material to a selected object or you could drag the material onto an object you could type the start and end of a range in two separate text inputs or you could use a new slider that lets you adjust them visually in both fine and gross adjustments i think transform widgets you know that have the constraints like x y plane constraints uh access constraints that's a great example of this right because you get to choose the constraint just by nothing more than choosing how you begin to interact with the thing you should augment content not obscure it because if you want to keep users close to your content close to their content don't come between them and the content that they're trying to create a simple example a trend i like seeing more and more is instead of shading a selected object with some solid color

outline it so that you don't disrupt the texture so that you aren't obscuring what the content creator expects to see debug spew try not to display tables of real-time data on your game if you can help it it tends to be really hard to read anyway we did this for a very very long time and we got to a point where we wanted to think about this differently because it was becoming unmanageable so we implemented i am gui in alchemy and allowed ourselves more real estate we shrank the game down to a part of the window and used the remaining space to display meaningful instrumentation but then we thought you know we could do one better our tool set written in wpf is a lot richer and it's a lot easier to interact with and it affords us more capabilities out of the box so why don't we bring the game into the tool set so we made the game itself dockable

users could dock the game alongside the rest of their workflow and get all of that rich interaction that wpf has to offer augmenting might also mean visualizing information that's already there so for instance one of our engineers built this really cool visualization every time you jump a graph appears and your jump is plotted on the graph alongside actual you know more numeric and explicit information and graphs that show the acceleration and the velocity this allowed our users to iterate on the all-important crash jump much more quickly than if they had not had it and it allowed them to keep their focus on the game a lot more than they used to you can promote mixing board thinking where i use the word mixing board to mean controls that blend and constrain many inputs into one or just a few results approaches like this relieve users of

having to maintain complex mental models of data structures and the dependencies between them and the rules that apply to them it invites them to play more with the result and try combinations safely with parameters that you get to enforce rules on behind the scenes all right so you see this with character creators all the time right it's skyrim offers lots of sliders and numbers and black desert takes a more direct interaction approach where you can tug on the cheeks and tug on the eyebrows to adjust the way that your character looks but these are all mixing boards right they're taking inputs and they're weighting them and they're blending them with influences in order to produce some result that is safe and unless you go to monster factory on youtube you won't get yourself into trouble right you're going to produce something that works within the context of the game some workflows support modifier stacks like macs all right i think of these as sort of

modular mixing boards the result of one mixing board feeds into the next mixing board and you may have seen animation workflows that have a palette of expressions for a character's face and you're able to dial in amounts of expression by clicking things in the palette and you can dial in a lot or you can dial in a little but you're mixing the result of a mixing board a rig you can promote copy transform combine thinking now this is probably the most abstract guideline in the set but it is a very concise expression i think of a very powerful idea behind some of the best tools that that i know of and i found it very inspirational still trying to articulate it in guideline form so here we go i was exposed to this first in a video called everything is a remix by kirby ferguson and in it he asserts that these three steps copy transform combine are

foundational to any creative endeavor but it's obvious to me that they have a certain special importance to content creation workflows you can help users explore creative spaces and stumble on new ideas by building workflows that excel at these operations copying is foundational to content creation right it lets you skip boilerplate work it's a branch and a thought process and it lets users rapidly create sets and repetitions that can vary independently or together it lets programmers create ad hoc checkpoints in their work like shelving a copy of your files in perforce so that you can return to later so things you can do as an engineer are support copy and paste operations for values for selected objects for most of the stuff that users can actually interact with you can support prefabs instancing or some or or get the needle closer to

a place where you can support those because they're not trivial you can support robust cloning of your data models we spent a lot of time defining very strictly what copy meant when you took a chunk of data in alchemy which could have a complex dependency web and chose to clone it questions like how far in the graph do you travel which instances do you break which instances do you make unique which ones do you keep which references do you have to correct and fix up it pays off though because it makes copying faster and it allows you to do more with the content that you have it's also useful to infer bookkeeping and other metadata so if you're shift cloning an object don't prompt people for a new name every time you release the mouse button chances are the tool can probably guess at one the user can keep doing what they want to do and they can go back and rename things later

transformation is the next step in creating variation that's the vehicle with which we explore creative ideas right and it typically follows a copy sometimes users have a clear end result in mind when they make a transformation they know exactly what they want to do but other times they don't other times they're just playing around they might be experimenting they may not have a clear intent and so let's try this idea tools can help infer things to make that possible so things that you can do are support randomization support mutations of sets if you can do something to one selected object it is almost always true that you should be able to do that to a selection of multiple objects you can get users to success faster by guiding their transformations you might infer snapping google sketchup is really really good at this you can help users change content between compatible representations

one of my favorite apps is a wireframing tool called balsamic and balsamic has this neat feature where you put a widget on your canvas and you type in some text to make it show things like choice one or choice two and then you can choose to transform it into a different kind of widget like a label and if i choose label it will change it to a label and it will keep as much of the text that makes sense for a label saving me of having to drag out a new label copy in the same thing or do something else it's just one of those little things right combining concepts contributes to uniqueness and innovation things you can do here are show things that can be combined and show the user when things can't be combined you can accelerate combination with implicit edits like visual scripts node splicing feature we didn't always have that it used to be that if users wanted to splice a node into a connection they had to delete the connection move the node and re-establish the connections the way that they wanted

this was a way to save time on that combination transformation can occur explicitly you can move a vertex on a piece of geometry but combination lets transformation happen implicitly right like procedural deformation i can move a vertex on the spline and the deformation driven by that spline affects the box tools can interpret combinations in clever and meaningful ways they can choose to use as much or as little of the metadata underneath these constructs as they want to or as it makes sense you can even give the user certain choices about how a combination is formed i think modifier stacks again are a great manifestation of these principles because they yield this really powerful idea right that you can combine the results of transformations in a sort of workflow i remember when i saw the max

modifier stack for the first time and how profound it was to me because i started to think that when intermediate transformations become parametric like this that's awesome because it means content becomes programmable it means that variation becomes injectable and it's ideas like that that led us to take a modifier stack based approach to our new visual effects system our users got to choose what they wanted to contribute to the final visual effect they could insert variation they could take out transformations that they didn't want and they knew the way we had visualized it that it was just a top-down flow you start up here and things are applied in layers almost and you go down to the result nothing i'm saying are really new insights about copy transform combined but i think that for people who are who are in the trenches it might sort of be hard to grok this to internalize it and so i think that

guidelines like these can reinforce these really important ideas for techno-creative people i think the real magic here the thing i want to shout from the rooftops is that tools can combine things in meaningful ways i want to go from 2 plus 2 equals 4 to 3 plus 2 equals more tree right i think engineers can contribute a lot here because engineers already understand a lot of these concepts and using a different vocabulary you understand polymorphism you understand operator overloading and implicit type conversion and all that groovy stuff we're really good at making the incompatible compatible and we're really good at sort of content algebras right defining rules that govern how things can be put together to keep users close to their content i think we should give them fewer reasons to be distracted by it

by making creation like this more seamless i think making combination effortless we can help users stay in their flow and stumble upon some really cool stuff that part was really abstract i get it i do want to recap though by promoting user confidence by mining requests for hidden value and by keeping users close to their content we're trying to help engineers put themselves in that creative mindset we're trying to help themselves put themselves in the user's shoes we want them to understand some things that are probably probably come a lot more naturally to their customers than it does to them but through reinforcement i feel like this is a skill we can cultivate in engineers this is vv i'm the guy doing the jazz hands near the back

and that's all i've got guys any questions [Applause] [Music] [Applause] [Music] [Applause] oh and this is for you heather we have time for questions i think about 12 minutes so um hi great talk thank you i'm definitely an advocate for what you're selling here um uh when you're dealing with a like a tool set that's uh that's been supporting your content for a long time obviously maybe five or ten years ago you made some decisions with the interface and then you've you know rethought it you want to make changes that will be improvements based on these guidelines how do you uh what experiences have you had uh selling that to users who may have become like designers and creatives who become addicted to the bad old way uh it is a process for sure it's uh it may be one of those cases where you have to rip off the

band-aid and be careful about how you do that there i actually attended a talk on monday i confess i forgot who gave this talk but they were talking about just this issues there are ways to safely or at least with due diligence rip off the band-aid for the better other times though whatever the case you should be talking with your users you should let them know that this change is in the work so that it's being thought about and they'll probably give you very good input on it ultimately though i think that that change is something you sort of have to force of will it and with enough demonstrations and enough talking with your users i think you can probably help them see the light worst case you can add a chicken switch you can add an option that lets them keep the past behavior but i always caution people against doing that because it means there's more to support there's more for support staff to be confused by

and i think that it it doesn't solve that underlying problem because chances are if you are considering making a fundamental change to somebody's workflow or their interaction model i hope there's a good reason for it and i hope that that reason is something like what it's doing now is actually at risk of producing bad content or what it's doing now is actually costing people time if they're not that one person who understands it and likes it hi um thanks for your talk girl is really practical um i have a question regarding that one slide in which you showed um iteration on the crash bandicoot jump with a graph in scene it really reminded me of a talk a very famous song by brett victor i don't know if you've seen it it was called inventing on principle in which there was precisely the idea of like visualizing and playing with data um not in a site editor but like directly in the scene or 3d view and i was wondering if you somehow managed to generalize that idea or apply it to more

than just one specific instance where you had to code for like this one jump this one graph or if you found approaches to maybe integrate the data and visualization more often into the workflow directly it's something i would love to explore more i'm a huge fan of brett victor's work by the way uh what we did with crash there was actually i mean you know when crash came out it was actually relatively recent this exploration into more sophisticated visualizations is something we've only just begun to start exploring with with any rigor i think the visualization is incredibly powerful and i think it's sort of an untapped resource in a lot of tool development because if you can get your engine to expose the data you need to visualize then i mean actually visualizing it is not really that hard of a problem i think that um well first of all have i answered your question at all yeah okay great i'll stop there and let another question go thanks for

talking some great great advice there thank you um i kind of wanted to pick up on something you said fairly early on about how some of your um you had some examples where people had had to sort of break out into notepad to patch up some game data and although it's undesirable it it's always the case that there are some features that your tool doesn't have and things that people want to do that your tools aren't capable of doing and so i was wondering if you had any advice as to how you sort of allow for users to escape the constraints of the tool in a in a controlled way so that they're not you know hampered by what they can't do yet i don't think we have a silver bullet but i do think we have a solution that helped in most cases if not all our tool it was very important to our tool designers at the beginning of laboratory that we offer a robust way to edit raw data basically that meant reading a file and showing it as a property grid a big property grid but a property grid that took all the hints from the runtime type

metadata like how to display this as a color picker as a slide or whatever and also took any validation rules that were in place and enforced them so imagine i think the closest equivalent i can come to is like view source in a web browser it was sort of like that it provided a a minimum viable interface around the job of editing data at just just peaking and poking values i think that there is more we could do there but it's not i think that that was a good enough solution except in some cases where um where data got munged in an upstream process their self-healing is something i think we could do better there do you find the balance between the need for creating new features and the need for improving what you have already and make it more usable for users

it tends to be based uh on a project by process project by project basis it's often the case that we will look to the project that we're working on and of course things that are going to bring value to that project get ranked higher in that list at the same time i feel very fortunate that vv is a studio that has that horizon on its mind all the time and with enough rigor with enough due diligence it is possible for an engineer to make a pitch for a longer term feature one that might extend beyond the value of this project it it always involves impact we want to know what impact will a change have how many users is it going to affect how much time is it going to save how much time is it going to take to build and then we we try to prioritize based on that i i try to blend um i try to avoid like the tyranny

of prioritization where you only work on what is item one in the giant tools backlog that lasts forever i try to do a blend of big things and little things i try to make sure that some of those priority threes always get attention i really believe that it's the little things that can make a big difference but i i just got an email from my uh uh tools engineers who said we cleared out all the priority one bugs in the sprint's backlog i'm like great job guys that's awesome now they can work on some of the other things we kind of play at sprint to sprint hi so kind of building off the same question or the previous question um at what point when you're looking at workflows you've already shipped it but you realize that the workflow that you've designed is actually not exactly how it's actually being used by your users as you're getting feedback how do you determine where that line is

between whether or not you should actually make changes which would actually cause users to have to change their habits and we potentially learned the workflow and determine whether it should actually be an actionable improvement i think that if you can boil it down to a measurable positive impact you've gone a long way in in sort of making that case depends on who you talk to some people are more conservative about making changes to workflows that are already in circulation already in the field others are a little bit more aggressive and are a little more comfortable with ripping off the band-aid and just telling users look we we understand this may be disruptive but we use our professional expertise to tell you that this is going to be for the best based on what we've learned what we've talked to you guys about and what we understand about the problem if you don't think that our understanding is complete please come

talk to us but other than that we're going to change it next sprint unless anybody tells us not to i don't think that the line is really very clear i think it's very much a case-by-case basis and it depends on where your focus is where you want your team's focus to be if if like me you are leading a group of tools engineers i have found that they tend to prefer to focus on one area rather than make bunches of changes in lots of different places and so if our focus is in that area and we feel we can make a make a dent um that's something we'll explore if their focus is isn't in that area we may wait till another time just so that they don't have to do as much context switching does that answer your question um yeah okay well um one minute two minutes follow up in that case yeah so let's say you do um have to make a change um do you do anything special to actually heard or i guess navigate your users

through the changes they have to make in their workflows um and if you do you have any tips for that the best tip i've ever given anyone was bring them over to your desk he hasn't gone to lunch yet let's go get him and bring him over and show him what it is we want to do i'm a big believer in in proof of concepts show me the change you want to make mock-ups are great working software is better verbal descriptions are almost never good enough we have to be able to feel it we have to be able to use the mouse use the keyboard and and make sure that this makes sense up here and not just on paper the users will give you that feedback and it's going to turn into a discussion but that's okay they may they may need more convincing they may need to understand more about the problem and your engineers might too fair enough thank you thanks

bye guys