I have a habit of nuking my posts because people tell me I write too many of them and I wanna keep on writing all day long, so I sometimes feel like if I delete the a few of them, I can write another one! Plus I have a way of communicating which is very raw and unfiltered, and that gets kind of embarrassing sometimes when I reflect back on it. But anyway, user-end design! Ill try to talk about how I tackle problems here. To me, there is this saying in software, Always optimize the common case. And this is a golden rule in software, because if you have a software that is not grossly inefficient anywhere, optimization ceases to become something you get for free. Youre usually trading off efficiency in one area to achieve it somewhere else. For example, you might make a renderer take longer to start up by building a higher quality accelerator, exchanging startup times for faster render times. It becomes a smart trade-off if your users are spending more time waiting for renders to finish than they are waiting for renders to begin. It could be a horrible tradeoff for an interactive renderer that needs to respond to constant scene changes on a per-frame basis: there startup time might be even more important than render time. So I apply this same philosophy to software design. Im most interested in the common case. For example, lets take a motion system design. Do we want one pivot at the central level for both rotation and scale, or two? And I ask myself, what do people usually need? And to me the answer is one. Most of the time you dont need a separate scale pivot from a rotation pivot, it would be awkward to deal with these two separately instead of having just one pivot per item. Now, the few times you really need two separate pivots per item, having two could be a lifesaver. But in exchange, all the times you dont need two separate pivots per item, its going to be making the workflow more clunky. So I would never choose two separate pivots per item, Id go with one, going by the optimize the common case rule. I dont care what Maya is doing, and if interchange with Maya means I have to support two motion pivots per item, Ill simply not support Maya interchange. And for the few times you actually need an item to have more than one pivot, we can solve that with something like motion operators that allow you to transform items with arbitrary pivots. Now someone could emulate the effect of having ten pivots animated over time if they want. That implies a clunky workflow for the rare case when you need more than one item pivot, but a less clunky workflow for the common case when one is all you need. And this is how I design everything. Not saying its the right way, just saying this is how I do it and this is what people can expect. The way I see it is that you usually need a software to have some clunky workflows somewhere, so lets try to avoid them in the things people do the most often.
Posted on: Sat, 22 Nov 2014 09:32:53 +0000
Trending Topics
Recently Viewed Topics
© 2015