I agree that VisualStateManager is definitely the preferred approach over EventTrigger (particularly for controls), but in the remarks this seems to be justified with the claim that EventTrigger's are "unsuitable for most run-time interactions" because "you name the event in the EventTrigger.RoutedEvent property." This seems a little misleading to me because it appears to be saying that it's ok to name a VisualState, but not an EventName; both are string values that can potentially change so why would the naming of one be preferred over the other? Granted, the justification was mentioned for non-controls/StoryBoard, but it's rare to use VisualStateManager without also using a StoryBoard. $0$0 $0 $0On another note, what if I have a property bound to my non-control object from my view model (i.e. IsSelected). To also toggle or set the view model's property and not just the object's animation, would I have to use two-way binding with a converter since EventTrigger is discouraged (to prevent strongly coupling my view with a view model in code behind)? Or if I start the StoryBoard using a Behavior, would I have to either bind the StoryBoard in the Behavior's instantiation or strongly couple some sort of reference to it (thus resulting in unfavored separation)?$0 $0$0 $0 $0I guess I'm trying to focus on what the best practice is for animating properties of an object that are bound to or affected by properties of, say, a view model, such that the set up of animation for the object's properties does not compromise the integrity of the property bindings. So if I want my object's property to be animated differently based on a property value of its data context, but want to allow user interaction to change the data context's property value, what's the best practice approach to accomplishing this (since EventTriggers and custom triggers are discouraged)?$0