I’m posting my notes here in hopes that something that grabbed me will be useful to someone else.  feel free to ask questions, make corrections, etc. This isn’t everything I saw, but rather the things that caught me as being the most interesting/exciting/poignant.  These won’t be nearly as condensed and edited as Ben Cloward’s observations, which are an easier read by all accounts.  I’m throwing more of the raw notes up here (in a semi-edited form), in hopes that there are things that didn’t grab me immediately that will later, or that someone else will find instructive.

As I’m currently working on thesis work, I’ll be typing these up during breaks from content creation and rolling them out as I finish typing each section.  I hope they’re instructive in some way, shape, or form.

Monday:

Riot Games/League of Legends Postmortem

  • Difficulties:
    • Always in development, always adding new fundamental features
    • emergent work — game is live, users are finding bugs
  • Solutions:
    • Triage daily (daily mandatory playtests)
    • Separate teams for live issues and feature additions
      • This allows for devs focused on immediate problems to focus there, and those focused on adding content to be focused where they need to be
      • Focus on the teams’ different cultures and levels risk aversion.  Put people where their personalities fit best ( this seems to tie in with Seth’s talk on Tuesday)
    • Scale testing
  • Other Observations
    • Don’t change UI for small changes
      • UI changes have a high cost;
      • Even if the change is going to have a positive impact across the board, you’ll have people who are used to looking/clicking in one place and will have trouble shifting to the new location

Tuesday (Tech Artist Bootcamp):

Keith Self-Ballard – Volition, In Advocacy of Tech Art – slides here

My note: This was a fantastic talk, and, in my opinion, one of the most important talks of the bootcamp.  The notes are a little sparse, partially because I was just warming up my note taking for the morning, but largely because the talk was very to-the-point.  Once the slides are released, I’ll be sure to post a link.

  • What Makes  a Tech Artist?
    • Flexibility and Adaptability
      • Bronwen Grimes later said the #1 quality she looks for in a Tech Artist is the ability to learn
    • Smart, Gets things done [and not a Jackass]
  • Why do we need tech artists?
    • Communication between artists & programmers
    • Good tools give an employer the chance to address problems with low performing employees
      • Low performing content creators can hide behind the fact that the tools are bad [ when they are].
    • Focus
      • Content creators can focus on content creation, worry less about the tools themselves
      • Engineers can focus on engineering
  • Challenges
    • Artists may grow overdependent on TAs
      • Arists need to be mandated to learn how to solve certain problems and remember when the same error shows up 2, 5, 15 times
      • Artists may stop looking for creative solutions
      • This was discussed at the Tech Art Roundtable on Thursday

Scott Kauffman, Making Tools your team will actually use – slides here

  • 1- Know your clients
    • Artists can’t often describe what they want or need
    • Be a Generalist:  Know what every department does, and how they do it
      • Be able to understand the workflow that the artist is trying to improve without them having to explain it or show it to you
      • “Know just enough to be dangerous”
    • Find beta testers:
      • Attributes of a beta tester:
        • Technical – able to understand in some way what is happening with the tool and what went wrong when it breaks
        • Patient – willing and able to deal with a tool that is still in beta, and has some bugs
        • Eager – Active, not reactive, in seeking help when it is needed, and solving problems when it is not
        • Pathfinder – Willing to accept the challenges of being the first one working with a tool, and also willing and able to evangelize the tool to the rest of the team
        • In short, people with a little bit of TA in them
      • Meet with them regularly to collect feedback
        • Be proactive
    • Keep tack of who is using what
      • Make a database of telemetry on tools usage (who, how often, how long, how many clicks, etc.)
        • Find out who uses new tools the most
          • These will be good candidates for beta testers
  • 2- Define the goal
    • Three questions
      • What problem is this tool supposed to solve?
        • This should go in the source code  at the top
        • Any time the tool does not meet this definition, it is broken
      • Who will be using it?
        • Design UI/feature set for target audience
      • Can this solution be added to an existing tool?
        • Helps prevent tool clutter
  • 3- Deploy in stages
    • Version 1.0 should be as barebones as possible
      • get this to your beta testers as soon as possible
    • Once basic functionality is there, polish UI, add additional functionality
  • 4- Simplify the UI
    • Intentionally or not, we design tools for ourselves
    • Example (bad): Zbrush
    • Integrate into the target environment (Max, Maya, Houdini, World Editor, etc.)
      • Artist should not be able to distinguish custom tools from built-in tools
      • Put new tools in logical integrated location and in custom tools menu
    • Avoid tool clutter
      • Occasionally do a tool list review
      • Too many tools = confusing
    • Make the UI expandable
      • Only show the currently required UI, expand the rest
      • A user will not use a tool that scares them
      • Hide complex UI until user needs/requests it
      • Start tools in a read only mode if applicable
    • Avoid customizable UIs and Hotkeys
      • Figuring out the beset layout and hotkey is your job
      • Any two users doing the same thing with the same tool should have the same UI
    • Button clutter is worse than menu clutter
      • Try to reduce button count.  If it doesn’t meet one of these criteria, move it to a menu:
        • Does it need to be clicked frequently or repeatedly?
          • Frequently: move, rotate, etc.
        • Repeatedly: Grow selection
    • Re-use your UI elements
      • Programming and Use efficiency
  • 5- Provide Help
    • Don’t roll out a tool until it’s documented
    • Every tool should have a help button
    • All help docs should be in the same format
      • Use a standard template
      • Provide specific usage examples
  • 6- Advertise
    • New tools
    • New Features
    • Breaking changes
    • Functionality changes
    • Pop up release notes on new changes
    • Create a one-sheet for new hires
      • Name of tool, one sentence description of what it does
      • If you can’t fit all of your tools on one sheet, maybe you have tool clutter?

 

Well that’s it for my current posting.  Hope that something here is helpful.  I’ll try to continue posting sometime today or tomorrow.