UI : Which XSI is your XSI - and is it the right one?
February 20th, 2006 by Luc-Eric - Viewed 3516 times - Popularity: 6%In XSI 5.0 we did something new by introducing a new interaction model. If you launch Modo or Motion Builder, one of the first things you get to choose is the interaction model. In the case of Motion Builder, it’’s a choice between Motion Builder, 3DS Max, Maya or XSI keymaps. In XSI 5.0, you get to choose between variations of Softimage, and a ‘QWERTY’ keymap, which we all understand to be Maya. Is this a new era of software developers admitting defeat?
Let’s delay the answer to that question for now and look at a less interesting one first.
In a recent XSI 5.0 introductory book, I’ve read something that goes like this: ‘Users of ‘the other program’ may turn on an option called ‘Transform Manipulators’ in the MCP['.]‘. That comment raises an interesting question’ The question is, who are the users coming to XSI and where did they come from? The book had noted that manipulators are ’slightly miss-named’ because they’re visual indicators and aren’t really used to manipulate (which is true only if they’re turned off). It is also recommended to turn off sticky keys, setting Nil Tool as the default tool, and Softimage|3D Selection model.
These suggestions are ok, but these are the settings used for people coming from Softimage|3D, and they are not the default and recommended options in XSI. Which leads to another question: What exactly do the people who make XSI want to you to use, and how is the application actually tested and designed?
——————————————————————————————-
First thing, everyone who uses software gets used to them and do not want to change unless they absolutely have to. For software developers, you’ll have people who still use Emacs or vi even when there are better editors out there. But the vast majority of people do move on as the tools move on, and it isn’t clear that one is actually more productive than the other. It all seems to be about muscle memory and personal habits.
In the world of 3D it’s in my opinion a little worse. The main reason is that the main tasks have been completely different between applications. In a text editor, once you start typing text everything is the same as in every other applications; it’s the auxiliary tasks that change, like searching, copy/pasting, saving files, those that take a small percentage of the time. The major tasks seem to be different between 3D applications.
However, the language isn’t actually that much different between 3D applications as it first appears. The application that sticks like a sore thumb, here, is Softimage|3D. Softimage 3D is the only application that you’ll likely encounter on your computer where you need to hold down space bar and click to select something. Why that is, and what were the benefits to that, the original designers are not here to tell us. It might have simply been easy to program ‘ that’s the reason behind too many user interface items people have gotten use to. (Seriously, at least the “edlin.exe” guy can”t have had a good reason.)
I remember years ago before Avid acquired Softimage, we were looking at Media Composer and couldn’t understand why you couldn’t click a clip on the timeline and drag it to another location. That’s just the way it was, and some users were freaked out that you could ‘mistakenly’ move clips on the DS timeline with your mouse. That’s just the way these people were trained.
Now, when we designed Sumatra/XSI we designed it looking at the present and future, not backward. It was blissfully obvious then as it is now that anything you see on-screen, you should be able to click and move it.
When you introduce a backward muscle-memory patch such as the ‘nil tool’, i.e. a tool that does nothing when you click in the 3D view port, you’re satisfying an immediate transition need at the expense of the global interaction flow of the application, and the experience for users without that muscle memory.
One thing to keep in mind that in Softimage|3D, EVERYTHING required you to hold down a key and EVERYTHING worked the same. In the function curve editor, for example, you needed to hold down M to move keys. You couldn’t just click and move a key. Everything was very consistent.
XSI however, was designed with modern user interface elements and concepts. This includes standard controls like edit boxes, list views, the tree view in the Scene Explorer. Most of the muscle memory from Softimage|3D are incompatible with modern applications controls, however this does not bother old time users because they are used to dealing with inconsistent interactions as they switch between applications. New users should not be subjected to this.
Maya was also designed as a modern application, Alias have had a strong user interface design group and Max of course has been designed as a true Windows app (after years of dreadful DOS user interface).
The question at the top was: are developers admitting defeat when we are offering keymaps for users by other applications. The answer is: No. 3D applications are converging toward the same workflows and manipulations. These basic tasks isn”t where XSI will shine, it’’s in the more advanced stuff that it will.
We don’t really care if you use ‘S’ or ‘ALT’ to navigate your camera, or ‘W’ or ‘V’ to activate transforms, it ends up being the same. Past that, into the actual organization of the software, we do not intend to imitate other applications, because we believe that our organization does provide significant benefit, and it’’s our identify. Using the Z key over ALT, however, we don’t really care. The only issue is that the tutorials are harder to follow.
All applications are converging. However, Softimage 3D is quite a bit outside that convergence line, so if you’re using the compatibility switches we put in, you’re not really using the XSI we are building. The best thing you can do is use it with the default, and tell us what are the problems with these tools.
——————————————————————————————-
Manipulators are interesting issues on their own. XSI does not have manipulators to please Maya or Max users; it has them because we strongly believe that this is the future of human interface. It was in the Sumatra/XSI plans from day zero.
They have been around for about 15 years now, first in research and now all applications use them at one level or another. We’re designing our application around manipulators and are an active part of the collective research the industry is doing about them. Each application brings the concept and workflow a little further.
On the other hand, the Softimage 3D interaction has nowhere to go, and nowhere to grow. It’s based on having 3 mouse buttons, with one button for each axis, plus a series of settings on a separate panel to control its various settings. It’s a done deal.
Our philosophy about manipulators is simple and the same as other tools. If they don’t do the job in some cases then we need to fix them, not hide them. In the future we will likely be more aggressive about this.
If for every new user interface element we add to XSI, we have a switch to revert it back to the way the application was in 1995, then XSI will never go forward. Some great feedback we get now days are from people who have given up on Softimage, or have always been with another application, and are coming to us with a fresh look at what we are doing. They’ll ask, why is this? For example, why can’t you select keys directly in the DopeSheet? Sometime we must say, it’s because it was that way in Softimage|3D. It doesn”t necessarily bother the old timers.
Already in XSI 5.0, we made a very bold move. We changed the default Move Point tool! The M key, which has worked the same since 1994, was changed into the Tweak tool. We’ve also unitified the ‘S’ key for navigation in the various views. Sometime this broke an habit, but we think the trouble is worth finally having consistency; it’’s for the greater good.
So does that mean that XSI will be abandoning its legacy? No. The Softimage 3D keys and workflows in XSI that are there ‘ there are already serious holes if you expect the app to work like Softimage|3D ‘ will continue to work, but fewer and fewer people are going to care about them.
It will happen naturally; the goal is not to remove tools, but rather to offer something that is worth dropping the old habits. For example, the Tweak Tool is worth it. And manipulators? Well, supporting not using manipulators for the basic S, R, T is trivial, and we will never remove this ability. However, we do want to create more and better manipulators and make users switch to them because they are worth the trouble of changing the habit. Obviously we need to continue to work with users for this.
Already, most of Softimage|3D is gone, only some broken memories remain. In the first year of XSI, people complained that we were using Windows menu and they were not like the ones in Softimage|3D. Recently, people have complained that we do not use exactly the standard Windows menus’ time change.
In future releases, in addition to doing the obvious and looking at new things, we will also continue to move forward in traditionnal tool areas like the Dopesheet, the Schematic, and more.
We are not going to stand still. Some applications may need a total rewrite to move forward, but we’ve built XSI to move be able to grow for many years to come.
February 21st, 2006 at 9:03 am
Great article Luc. I do have one comment I would like to share, however.
“However, we do want to create more and better manipulators and make users switch to them because they are worth the trouble of changing the habit. Obviously we need to continue to work with users for this.”
Softimage has to be careful when making something that forces an user to switch to. Obviously, the item in question should be very intuitive, intelligently thought out and as simple as possible. If I may digress alittle, I think that a current example problem (perhaps not with items such as SRT, but more in the field of navigation) is that there seems to be a question of consistency (or lack thereof).
Only in version 5 does the ”S” key work in all applictaions (texture editor, animation editor, etc..) But those of us using the configurable ZOP formation still suffer from this. So what does this translate to? Well, let’’s just say that I”m not sure what the designers” intentions were when putting this whole ”S” key and ZOP key navigation thing together. But the point is that some people are forced to use a nav system that isn”t consistent. This all leads me to my point of Soft making people switch to better (in this case, manipulators) ”because it’’s worth the trouble of changing habits”. Apps these days should be all about personal preference. I do agree that older methods fall out of favor as systems evolve. No dispute there. And as far as the manipulators go, so far, so good from my point of view! :)
So long as older methods can be retained for as long as possible while the system can support it, this should satisfy both user groups (new and veteraned). Giving choice is a must in this day and age, as apps should be all about personal configurations and preferences (within reason.. not suggesting that users be able to configure between 5 totally different SRT manipulator systems here). And by adding at the end of that snippet (”Obviously we need to continue to work with users for this.”), you are absolutely correct. :)
I think stuff like the tweak tool is simply an amazing idea. But so long as the older manipulators are still in place, more experienced (dare I call them ”Legacy”) users can jump back and forth between the tweak method or the good ol fashioned way of , say, going into point mode and moving them with the keyboard mapped Translate key).
Great article though! :)
Cheers,
NRG
February 21st, 2006 at 10:42 am
Z-O-P are definitely legacy keys for zooming in paning, which is why you”ll be seeing inconsistencies and falling support. The keys come from Softimage 3D and the people obviously intended to use the first letter of every english word, as oposed to what could be ergonimical, and the slow-medium-fast mouse button assignment.
it’’s simply not viable to implement them in all views in a meaningful way, and I am not aware that other applications has such a set of navigation commands. Our intention is really to have users use the S key and we have Z as well for basic zoom and especially rectangle-zoom. If the speed of the S key is an issue in some cases, we definitely need to fix that; I know a collegue has also looked at mouse wheel support.
February 21st, 2006 at 12:58 pm
Thanks for the speedy response, Luc-Eric! Much appreciated.
While I do understand that the z-o-p may be legacy, it is still in use (as there are some users who have made note of the consistency issues on xsibase, myself included), and I don”t think it ever has the need to become obsolete. It represents yet another method of viewport navigation (like our friend the ”S” key). So if there is already in place a customizable keyboard mapping system (which obvisouly there is) which allows the user (who prefers to use the z-o-p configuration) to map z-o-p to their likings, why not stay consistent in other veiws?
To give a clear example, (as you mention that you are not aware of any application that does this), let’’s use 3DS Max as an example. I have ”z” mapped for zoom and ”x” mapped for pan (this is for the main modelling viewports)
Guess what keys Max uses for the 2d space equivilent of ”zoom” and ”pan” respectively in say the texture editor? In my case, z & x. respectively… The system is coded to look at what key is mapped to ”zoom”, and replicate the ”zoom” effect in 2d space. Likewise, the same goes for ”pan”.
Therefore, since the ”S” key has the ability to replicate the equivilent of ”zoom” and ”pan” in 2d space, why can Softimage not have the system look at what keys are mapped to those elements in 3d space and mimick them (using the exisiting functionality of the ”S” key) in something like the texture editor while using the viewport mapped z-o-p keys?
For Softimage to want users to use the ‘’s” key feels somewhat like being pigeon-holed into one method only, while there are clearly users out there who prefer z-o-p (much like myself). Is this the definition of flexability? (nevermind how ”good” or ”cool” the ‘’s” key may be… that is irrelevent). I”ll mention this again.. apps should be about configuration and choices. Not pigeon-hole-ing users into something so customary such as user defined navigation systems..
I apologize if I”m starting to drag this out.. It’’s not my intentions to do so. Im just really curious as to why ”it’s simply not viable to implement them in all views in a meaningful way”, when an app like Max clearly manages this flawlessly. (and no, the lack of an ‘’s” key in Max is not a viable answer, as Im sure if Max ever did implement such a system, Im sure they would still be mindful of current users preferenmces and have the current system still hold).
No insult to you or anyone intended Luc-Eric :) I am now recognizing that this is really straying off topic of manipulators and whatnot. But again, thanks for your initial response. I”m just curious as to the actual resonings behind the slowly-but-surely forceful ‘’s” key approach.
Sincerely, your z-o-p dedicated..
NRG
February 21st, 2006 at 2:18 pm
I”d like to take issue with a few points brought up here in discussion.
First, Softimage should never have any plans to force anybody from ”ZOP” to ”S” navigation (or vice versa). For some people, like me, I will never make the switch no matter how good ”S” becomes. Why? Because I”m left-handed which means my right hand is free to roam the keyboard. Accessing ZOP is significantly more ergonomic than reaching over for the ”S” key, plus ZOP offers more functionality. I really liked Softimage|3D because it’’s key mappings were heavily biased towards a left-handed user such as myself. All the major functions I do repetitively were within a small patch on the keyboard and allowed me to keep my eyes on the screen without having to look down to see what key I was pressing. That’’s good design as the intention of the application was to be ergonomic. I find XSI’’s default key mappings to be very clunky because there is no (which leads me to my next point)….
…Consistency. You hit it on the head Luc-Eric. Softimage|3D, as old and crusty as it is now, was very consistent. Made it very easy to learn and teach because even if you didn”t know what a tool did, you had a decent idea of where to begin. Also, forcing users to press keys to invoke actions reduced the number of inadvertant errors one makes from accidental mouse clicks or key presses….which in turn meant less dependency on the ”undo” function. As much as XSI has grown, I think one area it has regressed is the UI for user interaction, in terms of design. Individually some are very nice, but the lack of consistency makes it much more difficult to learn and use than it should be. Not just in key mappings, but key behavior when mapped to a particular function as Norman mentions. Terminology is inconsistent in places too. While it’’s nice to offer fancy click-n-drag controls, they need to be carefully thought out in the grand scheme of workflow and how it affects the user’’s pipeline from start to finish and not just within a smaller context such as modelling or texturing toolsets. A simple case: The resizing icons on the viewports. In Softimage|3D you use LMB to resize uniformly, MMB to resize vertically, and RMB to resize horizontally. One click of the mousebutton no matter how you wanted to resize. In XSI, you use LMB to resize uniformly, MMB to resize horizontally, but have to use ALT + MMB to resize vertically. Why? If you use RMB or ALT + RMB you get a popup menu. Why not just make RMB resize like LMB and MMB do, then put the popup in a key-combo such as ALT+RMB? Why do I have to use 2 buttons to resize vertically? Inconsistent within itself. It’’s important to mention this because these exceptions to the rule is what slows workflow down as the user has to pause and think of what they”re doing before they do it. Not good. If you want a simpler example, selecting scene elements. XSI defaults to being in object selection mode, but only until you do something else. Then at times you”ll have to tap the spacebar to get back into object selection mode. I cannot tell you how many students have been confused by this simple inconsistency. This very same inconsistency has led to a majority of the mistakes they make because they are not aware they are no longer in object selection mode, or conversely, object selection mode never returned after performing another function. This is one case where I think forcing the user to press a spacebar makes sense as it doesn”t leave any doubt and a good reason to keep the NIL tool.
While user interfaces are certainly capable of being upgraded over predecessors such as Softimage|3D, the negatives have to be weighed just as much as the positives, and I think that’’s been lost on most of today’’s softwares. They get so caught up in re-inventing the wheel that they lose sight of the fact that sometimes simple is better and these older softwares got it right in the first go around. I can honestly say I made significantly fewer inadvertant errors using Softimage|3D than I ever did using XSI, and I used Softimage|3D for a lot longer. I rarely needed an undo key in Softimage|3D, I need it frequently in XSI. Same goes for many people I have worked with. While I”m not wishing the Softimage|3D model be etched in stone, there are many areas which XSI development could borrow and learn from. Consistency and ergonomics of a homogenous workflow are two such areas. The best designs are simple. XSI is not simple.
February 21st, 2006 at 2:25 pm
I guess my point here is only that legacy adds more redundant but different tools to the application, it’’s not something that you”ll find in many other applications. I”m not threatening to remove the support for these keys.
Legacy modes can sometime produce a less than ideal experience of XSI. For example, if Softimage|3D interaction is on, then you can right-click to get the context menu, without holding ALT down. Some users don”t know that there is a context menu at all. In other views, you do not need to hold down ALT. Selection is also pretty consistently using SHIFT and Controls in editors and controls, but it can be different in other parts of XSI if softimage|3D compatibility keys are used. Not having to deal with legacy can make new applications like Modo look more elegant and gives them an advantage in interaction design.
With S-Z-O-P that ends up meaning that XSI has 4 different keys assigned to navigations which makes the UI unclear about how it should be used - and sometime failing to please all the users it’’s trying to. For example, P uses the three mouse buttons in a certain way that is not then in other tools, so it adds an inconsistency. These are sometimes obvious to new users, less so when we”ve been using the tools for many years.
In the case of the Texture Editor, I *think* you”re asking for the support of “P”. That’’s totally reasonable and you should log that with support; it’’s a good example of legacy support, where the team isn”t looking as much at the very small group of people still using Softimage3D keys.
We do know that most users also use other applications and sticking with tools like the S key that are the pretty much the same in other applications is a definit advantage. For everyday workflow, it’’s a definit advantage that application converge on the basic things.
February 21st, 2006 at 2:57 pm
>In XSI, you use LMB to resize uniformly, MMB to resize horizontally, but have to use
> ALT + MMB to resize vertically. Why? If you use RMB or ALT + RMB you get a popup menu.
> Why not just make RMB resize like LMB and MMB do, then put the popup in a key-combo
> such as ALT+RMB?
I”m certainly not rejecting your comment, but for this particuliar problem I would say that its context menu on the right mouse click button is pretty much the industry standard and it adds a lot of frustation to most users when XSI is inconsistent by for example putting this on keyboard modifiers there is no way of discovering. Adding content menu on ALT+RMB is re-inventing the wheel, not the other way around. Another user could easily ask, why is Softimage’’s context menu not like other applications, why did they re-invent the wheel.
Three mouse button-optimize workflows like this can also block Softimage from making better use of pen tablets as serious input devices, for example.
Item like this can be seen an inconsistency, but at least some of these affects mostly people who have been trained in Softimage|3D, which is a group of people that is shrinking, by definition. Most users are totally new to Softimage nowdays, and are not migrating from Softimage|3D. This article doesn”t really take a position or have any clear answer on that subject, but it certainly raises the question of who the primary interaction design should target.
Again I want to make sure people understand that I”m not writing that the software is giving up on Softimage|3D users, but rather that it’’s best to try to use XSI without the legacy switches, so we can all move forward and create a consistent and modern application.
February 22nd, 2006 at 2:03 pm
> Legacy modes can sometime produce a less than ideal experience of XSI.
> For example, if Softimage|3D interaction is on, then you can right-click
> to get the context menu, without holding ALT down. Some users
> don’t know that there is a context menu at all. In other views,
> you do not need to hold down ALT.
Softimage|3D never had context menus (other than the swiftmouse feature introduced in v3.7), so to force Softimage|3D mode in XSI to show a context menu on a RMB vs. holding ALT for native XSI functions I think is an XSI design flaw rather than a Softimage|3D legacy issue. In this particular example there is no reason why ALT+RMB couldn”t behave the same for both Softimage|3D and XSI modes as it wouldn”t confuse older users. If anything, it would”ve eased their transition to the XSI way of doing things despite their groans.
> Selection is also pretty consistently using SHIFT and Controls in
> editors and controls, but it can be different in other parts of XSI
> if softimage|3D compatibility keys are used. Not having to deal
> with legacy can make new applications like Modo look more
> elegant and gives them an advantage in interaction design.
Again, an XSI design flaw as Softimage|3D didn”t have much to speak of in terms of using ALT and CTRL. Softimage|3D only used CTRL or ALT for swiftkey mappings to menus (eg: ALT + M to open material editor). This is one area it would have made more sense to force users to the XSI method.
> With S-Z-O-P that ends up meaning that XSI has 4 different keys assigned
> to navigations which makes the UI unclear about how it should be
> used - and sometime failing to please all the users it’s trying to.
> For example, P uses the three mouse buttons in a certain way
> that is not then in other tools, so it adds an inconsistency. These
> are sometimes obvious to new users, less so when we’ve been
> using the tools for many years.
Yes, and this is where XSI becomes very inconsistent as many tools only utilize the LMB and MMB, while a bunch of others use all 3. Just my opinion, but I think it’’s best the application be optimized for the context in which it’’s used rather than trying to conform to everybody else’’s software. While it’’s certainly useful to reuse conventions such as CTRL-C to copy, or CTRL-V to paste, it doesn”t make much sense to go too far beyond that because those using an application like XSI are going to be spending heavy amounts of time there and not in many other places. Therefore, behaving like everybody else is rather irrelevant other than for the hooks which XSI connects with everybody else (eg: browsers, file manipulation, etc…).
> In the case of the Texture Editor, I *think* you’re asking for the
> support of “P”. That’s totally reasonable and you should log that
> with support; it’s a good example of legacy support, where the
> team isn’t looking as much at the very small group of people
> still using Softimage3D keys.
My comment was targetted at XSI as a whole, not the texture editor or modelling tools specifically - although I could certainly go into detail within each. My point is that from a user’’s POV, XSI behaves as a discrete palette of toolsets that don”t see outside their own box to how other toolsets are functioning. It’’s as if they”re oblivious to what other toolsets are doing at times which makes it difficult to put together a cohesive workflow.
February 22nd, 2006 at 2:35 pm
> I’m certainly not rejecting your comment, but for this particuliar problem
> I would say that its context menu on the right mouse click button is pretty
> much the industry standard and it adds a lot of frustation to most users
> when XSI is inconsistent by for example putting this on keyboard
> modifiers there is no way of discovering. Adding content menu on
> ALT+RMB is re-inventing the wheel, not the other way around.
> Another user could easily ask, why is Softimage’s context menu
> not like other applications, why did they re-invent the wheel.
> Three mouse button-optimize workflows like this can also block
> Softimage from making better use of pen tablets as serious input
> devices, for example.
I disagree here. There aren”t too many standards in the computer industry other than just about every OS uses a mouse and possible CTRL-c/v/x to work with files and text. Even in that context alone there are no standards. For the longest time MacOS was primarily a 1-button mouse interface. Windows a 2-button interface. Many UNIX systems a 3-button interface. The basics of working with menus and hotkeys are radically different because of it. So to instill XSI with all these goofy ALT+click combinations for the various interaction modes and claiming they”re based on ‘’standards” is just nonsense. With XSI you should be making a purebreed (make a decision on workflow and stick with it throughout the software), but instead are making a mutt (and confusing the heck out of users). XSI seems to want to support the Windows model whereas it’’s predecessor Softimage|3D was shaped after the UNIX model. Both have their merits, but considering XSI is a 3D system and not a 2D office spreadsheet, it makes more sense to go with the 3-button model as that’’s the expected workflow of a 3D system. It makes too much sense to use all 3-mouse buttons in a key mapping to represent XYZ axes and the like.
As for pen tablet support, just my opinion again, but I think it would be better to offer an interaction mode specifically for pen tablets that makes sense for pen users. Most pen users probably aren”t going to be animators, they”ll be modelling, texturing/rendering artists. So to compromise half the software’’s workflow for pen users at the expense of mousebutton users who use the entire software more heavily seems ridiculous to me. Design to your primary and most experienced user, then make whatever variations you need off of that. While there are a gazillion interaction devices on the market, the most frequently used can be reduced to mouse, trackball, midi, pen, scanner, and some derivative of a monkey (isn”t everything a derivative of a monkey?).
> Item like this can be seen an inconsistency, but at least some
> of these affects mostly people who have been trained in
> Softimage|3D, which is a group of people that is shrinking,
> by definition. Most users are totally new to Softimage nowdays,
> and are not migrating from Softimage|3D. This article doesn’t
> really take a position or have any clear answer on that subject,
> but it certainly raises the question of who the primary interaction
> design should target.
From experience both working in the studios for many years as well as teaching XSI professionally (and in the colleges) I can honestly say Softimage|3D legacy has nothing to do with it. New users who have never seen or heard of Softimage|3D are just as confused as Softimage|3D veterans. What causes the problem is XSI’’s lack of consistency in how to implement it’’s own workflow regardless of whether the tools are new or legacy. A decision needs to be made on the primary user and everything from that point on has to follow suit.
Personally, I think you”re primary user should be the seasoned veteran who has tons of experience in working in various types of pipelines and knows what’’s important to get day-to-day work done fast and with high quality (and most importantly - has clean workflow, not a hack). By molding to that prototype you”re instilling the expected habits and workflows onto rookies and converts. Rookies know what they like, but they don”t know what’’s correct. So to cater to them would only slow everybody else down. The rookie will change his views and opinions frequently as he learns which will only introduce more inconsistency. The convert will be helpful in opening the eyes and exposing you to how other people do things, but will often be short sighted into understanding how or why that older workflow won”t fit into the XSI scheme.
> Again I want to make sure people understand that I’m not
> writing that the software is giving up on Softimage|3D
> users, but rather that it’s best to try to use XSI without
> the legacy switches, so we can all move forward and create
> a consistent and modern application.
As a Softimage user since 1993, I”ve never had any problem with doing away with Softimage|3D workflows and ideas if they didn”t work. What I don”t want to see is for XSI to re-invent the wheel in areas that Softimage|3D was already very successful in terms of ergonomics and functionality. The rest can be tossed and replaced at will and not a tear will be shed. I”m sure if you poll a number of Softimage|3D users, they”d say the same thing. What many have taken issue with is the XSI replacements for many of the older Softimage|3D tools have been a regression from previously available functionally. That should never be the case, especially after all the reassuring and campaigning in the ‘’sumatra” days.
February 22nd, 2006 at 3:12 pm
Matt, the post you”re quoting wasn”t in response to your post, but to a previous post. I just apears here after yours because I was posing at the same as time as you.
>Softimage|3D never had context menus (other than the swiftmouse feature
>introduced in v3.7), so to force Softimage|3D mode in XSI to show a context menu on a RMB vs. holding ALT f>or native XSI functions I think is an XSI design flaw
The context menu on ALT+RMB occurs with Softimage 3D legacy modes, because as you state SI3D uses all three mouse buttons and no context menus. That’’s not how we want it to be and we are not forcing menus on RMB in SI3D mode. Quite the opposite, my point was that the context menu is on ALT when using the legacy switches, which introduces inconsistencies.
RMB is also taken in Extended Component Selection, which is a hybrid mode for SI3D users, so it’’s also for legacy. Without Si3D selection mode and Extended Component Mode, the context menu is on RMB, except Object Selection mode.
In object selection mode, the RMB is taken by Select Tree, one last remaining inconsistency, which is something we might get rid in the future when not in SI3D selection mode.
It makes sense as you say that since people stay in XSI all day, it doesn”t have to be consistent with all other apps. And we use that in some areas.
However SI3D wasn”t forward-looking and works like no other GUI applications, so if we do something like SI3D did, it needs to be because it is really, really better than the not doing that.
It needs to be more than simple muscle memory from SI3D, because Si3D users are a tiny percentage, and shrinking, of the CG out there.
February 23rd, 2006 at 7:32 pm
> ../.. Past that, into the actual organization of the software,
> we do not intend to imitate other applications ../..
> ../.. 3D applications are converging toward the same
> workflows and manipulations ../..
> ../.. We don’t really care if you use “S” or “ALT” to
> navigate your camera, or “W” or “V” to activate
> transforms, it ends up being the same ../..
That’’s an interresting paradox.
It’’s pretty clear actualy, better stick to what is or what will becomes “standard” ( read windows/words standard ). Sorry for professionals. 3D Democratie they said ? Right.
One could say that standardisation in this matter is an insult to the adaptability of mankind. Adaptability toward something less standard but much more efficient.
The Human Being is pretty good at adapting himself to interact with his environment, however he is pretty bad at trying to process datas.
I would rather like to hear:
“3D applications are converging toward the same datas formats, being 3d objects, animation, scene description, textures and image file fornats, scripting, shading language, ..”
But I”m affraid we will end-up with 3D sofwares having exactly the same interface and workflow, but incompatible, unable to “talk”.
This might be pretty funny.
February 23rd, 2006 at 9:33 pm
Well, I work on user interface and interaction, including the issues for Max and Maya animators. There is an entier other team focusing on data exchange and pipelines, including the Collada file format, which is heading up to be that future common 3D scene data language.
February 23rd, 2006 at 11:20 pm
Interesting topic. I must say that the only 3D application that i felt was ok in interface is Sketchup (i know it’’s a little more simple than XSI) but it was a “flow” to model a building for exemple. After 1-2 days i was modeling 4-5 building in the morning. And it’’s not an apps that uses much keys.
In XSI was puzzled for the spread of keys by the keyboard without apparent logic.
IMHO an interface should be thought about clusters (means keys that are comonly used for a similar propose should be near each other) and Hierarchies. Also keyboard layout could drive logic behind keys. I am not such advanced in XSI to say if it is possible but top keyboard horizontal line for Animating. Middle Line for Camera, Selecting and Transforms and the third line for other options.
For example i maintained A the default Frame but i made Shift+A the Frame seleted. So for Framing i just need to remember A key for framing . The fact that A is near S makes a good “cluster”
I made also one key : move, rotate, scale (last 2 by ,alt, shift) so i can keep the finger in same place for all them.
One key for selecting Polygons with alt for options like raycast, another key for points and alt etc for options and and another key for edges and alt, etc options. Also there is an hierarchy the left key is “more complex” so W is polygons then came Edges in E key and R is the points. This might seem arbitrary but in my mind as an user not as a coder the points “build” the edges and the edges “build” the polygons.
Of course there is a conflict if raycast should be a key in itself. I think for the learning curve we must respect a sort of hierarchy and raycast is at lower level than “default” Polygon select for example.
As you can see there is an apparent inconsistency i choosed diferent main keys for polygons,edges and points but not for move,rotate and scale. The reason is that i dont use options for move, rotate and scale often but i use raycast option often.
For a user that dont use XSI always or is starting less keys to think about better. Also less finger moving and what definitions we can use to help us define the logic behind.
February 26th, 2006 at 1:59 pm
Thanks for the comment, “bullit”
March 2nd, 2006 at 3:57 am
XSI interaction really suffers from inconsistency, whether this is due to legacy features, rapid development, or trying to please a wide spectrum of users. As powerful as XSI is, these inconsistencies detract from its appeal and do hinder its usability. Every ‘Editor’ has it’s own workflow and way of interaction which is different form other parts of the application. Even ‘similar’ work spaces have different interactions.
For example the Texture Editor and the 3D View Ports seem a likely candidate for sharing interaction models, as the user is manipulating meshes of connected points (one space is in 2D the other in 3D) but in XSI they are drastically different.
As an example, selection modes available in the 3D space (like lasso) aren’t available in the 2D space. The way pivots are set in 3D space is much different then the way pivots are set and activated in the 2D space. Tools that are shared in the 3D and 2D space behave differently; the Proportional falloff tool is available in both views but some options such as the ‘consider neighborhood’ option are ignored in the 2D view and the area of influence (both screen icon and point highlighting) aren’t implemented in the 2D view… etc.
Sadly this seems to be the norm between all Editors in XSI. It makes the application feel like many disjointed pieces.
New releases attempt to address the application consistency, like making the ‘S’ a uniform navigation tool for all views and editors. Unfortunately new ways of interaction leave a snail trail of additional inconstancy behind.
In version 5 for example, the new tear off-menus were added… but not all menus in all editors (even some of the submenus within tear-off menus are supported). The switch to MMB to set ‘key-time’ was made… but the Animation Editor still uses the RMB for setting ‘key-time’. The new ‘tweak tool’ was added… but now XSI has on screen icons widgets which XSI has stayed away from as a whole (icons and 3D viewport UI).
Users will adapt to new applications, workflows, and UI’s, as long as the interaction model is kept simple and consistent.
August 27th, 2006 at 3:56 am
Dave
Interesting topic… I”m working in this industry myself and I don”t agree about this in 100%, but I added your page to my bookmarks and hope to see more interesting articles in the future