Multiple objects on same motion path

[Zoe Summers]

I know this is similar to another post, but I've left feedback for the Blend
team that they should allow multiple objects to occupy the same motion path
and move at specified distances from each other.

i.e. Think of Cover Flow on the iPhone or a Carousel, or images falling down
a waterfall to collect at the bottom.

Again, this was closed as a 'not going to fix' and no discussion was had.

What is the point of a motion path that only ONE object can move around, and
only from certain MS defined start / stop points????

Is this really useful at all? Or just another example of a great MS product
being crippled because a great idea is only half implemented and NOT carried
thru to it's ultimate and most useful conclusion?

Anyone, any thoughts to stop me from grinding my teeth and pulling my hair
out?

[Steve White (MS)]

Hi Zoe, I'm sorry that it looks like my response didn't reach you. I read and
responded to your suggestion via our internal tool. We always respond to
Connect suggestions and we mark each one as being replied to so we never miss
one. Please remind me of the date you raised the issue and a hint as to what
was in the title as well as the user name you used and I'll try and find my
reply. I just looked for the issue now and I couldn't find anything from
Connect with 'Zoe' contained in the Source ID.

Anyway, my reply was along the lines of no, you can't do this with
AnimationUsingMotionPath. The platform and tools teams are all looking at
ways to achieve what you're after via a visual design tool. Today you simply
have to write some code. Designers with an ActionScript background will find
doing so natural, and of course developers will. The best suggestion I can
give is that a dev writes some code and the designer hooks that up and sets
properties. It's a discussion that extends beyond the scope of a simple
newsgroup query.

Regards,
Steve White
Blend Animation PM

[Steve White (MS)]

Hi Zoe, I found your feedback - it was created under a different first name
but the surname is the same so I'm sure it's you. Here's what I replied:

Updated on 11/5/2007 7:02:27 PM by Microsoft
Hi, thanks very much for your suggestion.

Apart from the carousel scenario, do you have other scenarios in mind where
you'd define a motion path once then place multiple objects on it at
different points and have them move in response to triggers?

Just triaging whether we really need the feature you describe or just an
easier way to build a carousel control.

Thanks,
Steve White
Program Manager, Blend

**Please check again and make sure you didn't get the mail 11/5 because if
not then there's something wrong with our internal tool.**

Many thanks,
Steve

[Zoe Summers]

Dear Mr White, thank you so much for replying to my posts, and giving me a
better understanding of what's going on and where (hopefully) you can take
these tools.

In reponse to the carousel suggest and other scenarios where this would be
useful, I believe you only have to look at the key area that I'm most
interested in, and that some of your R&D teams are working on....Touch.

Just like the iPhone (which IMHO in terms of UI and UX has blown away any
windows mobile / symbian / android UI and UX) fingers are finally becoming
more important.

The ability to use your digits to move objects around in the screen in a
linear fashion i.e. 3d carousel, or wrapping line as in Microsoft Surface, or
in vertical or curved path designs (just look at the silverlight demos on the
MS page) it makes much more sense to build UI's and UX's that allow this
'natural' and 'organic' behaviour, rather than continuing to force users into
the regimented 'Windows' or 'Keyboard and Mouse' traditions.

I'm currently developing a new technology for Vista that implements WPF and
Touch, and the lack of 'easy'?? or reuseable features like this AND the fact
that the WPF Expression Blend Trigger Events DO NOT explicitly allow for
TOUCH as a sole event - stylus doesn't apply as if you are modding the UX for
touch, and someone uses it on a device with a tablet pc and a finger, then
surely you don't want to have the pen UX changed???, these lacking features
for a developer in my 'field' mean that the tools are to a degree cripled.

When you look at MS Surface, Lucid touch from MS, Multi Touch monitors from
MS, the iPhone, the rumoured iTablet (multi touch Mac Book like a big iPhone)
and now the haptik touch system in the forthcoming Nokia S80... surely it's
time that these tools took these requirements seriously and became 'future
proof' in this regards?

I hope I haven't 'waffled' on too much here - but this area is a passion for
me - improving the UI / UX to the point when interfacing with a computer is
more natural and not solely reliant on a keyboard / mouse / pointer / small
icons...

I'd like to think I've said something useful here and that you or someone in
the WPF / Blend / Orcas teams will see the value of some of this.

It would certainly make my year!

Thank you again

Zoe

[Steve White (MS)]

Well, yes, I think that's some useful information.

To get some action points out of it I'd like to tease it apart a little. I
can identify three orthogonal topics of discussion: 1. The physical means by
which a user performs a gesture, 2. the logical semantics of a gesture, 3.
how the software feeds back that a gesture has been performed.

The first topic seems to be a hardware one - various devices can respond to
various input devices including mouse, stylus, touchscreen. The second is
around mapping those physical gestures to logical gestures which includes
being able to distinguish between stylus and touch if that's the requirement
but also being able to say that a mouse gesture and a touch gesture both map
onto the same logical gesture from the app's point of view if that is the
requirement. That's about being able to attach particular event handlers to
particular event types on particular elements in a many to many fashion and
is a platform issue. The third topic is really where the software and the
designer come in, mapping a logical gesture to some visual feedback behavior.
How that's done, whether using motion paths in markup, or using procedural
code, is really what my question was about. But you've answered it I think in
saying that the carousel belongs to a class of feedback behavior that you'd
like to be able to build in a tool for designers. My action point is to think
about achieving that. The other two discussions are probably best had with
the hardware and platform folks.

Steve

[uchiha]

I reckon that you are mentioning about a carousel, but feel troublesome on the
path problem.

I had some experiences on the C# carousel control:

http://www.kettic.com/winforms_ui/carousel_overview.shtml

I happen to get the materials for the introduction of path in carousel, which
might offer great help to your situation:

http://www.kettic.com/winforms_ui/csharp_guide/carousel_getting_started.shtml

Wish you good luck.