Tag: HTML

2 perspectives on animations

Posted on by ARSpaulding

On one hand, a friend of mine tells me, “Man, don’t even worry about the XAML – just design, use Blend, go crazy. Be artistic.” and on the other hand, I have a different friend who groans at the messy XAML which Blend puts out when using transition Visual state manager Double Spline Animations – he says it reminds him of the splatter which the archaic “MS Front Page” would spew out in HTML format, that there are cleaner ways of doing the same things with far fewer lines of XAML.

I’m SO there with the 2nd guy in relation to MS FrontPage and html. Me being the gal who would create something in photoshop, chop it up, and piece it back together – most of the time without looking up from the HTML, CSS – and all the Divs in between until most of everything was put together to verify that everything was behaving the way that I thought it should with my markup.

That being said – I kind of like the idea of, “Just be creative…” Man… I’d love that. To just… make it happen, and move on. I could get SO many other creations done – OR – spend so much more time on the details of the art! That’s not to say that I don’t already, but what if I had even more time? What greater level of polish could be gained with that additional time?

For all who visit who are in either/or/both worlds – do you have any opinion on this matter? What’s better? Cleaner XAML/Learning the alternative markup which blend 2 doesn’t have in its interface – or – using the VSM and the keyframe animation tools?

Is there a better side?

Anyone have an opinion? Should there be / is there a middle-ground?

HTML on coffee, monster energy drink, with lots of vegetables

Posted on by ARSpaulding

What is the title talking about?

XAML

There are many impressions of the experience from being a XHTML CSS Raster-based web designer to moving onward and upward to more User Experience technologies that I’ve skipped along the way.  Now that I have a blogging system in place that allows for more easy publication, I’m going to try to fill in the blanks.

So my first impression of XAML once I really got my feet wet was a strong familiarity.  XAML is like someone took HTML and fed it lots and lots of vegetables, gave it training on the track, music lessons, and then packed it full of coffee and monster energy drinks.  By the end of the day, you have the result of something more akin to Hal Milton, the hyperactive thoroughly intense, highly sarcastic and witty guy who works at the Sony Online Entertainment office leading the team creating the new PS3/PC game, The Agency.

Yes, I’m comparing XAML to Hal.

For those who have no clue what I’m talking about, but do know coding and markup enough to be reading this blog – I want you to take HTML, couple the base of HTML with some AJAX and wrap in lovely lovely CSS, and move back to the world of pretty formating, and you have XAML – sort of.  You could also say that its like flash only way slicker and easier.

For the HTML CSS markup designer, your wrist was slapped for using capitol letters.  Your elbow was flicked REALLY hard for using the enter key too often for spacing, and the back of your head popped for tabbing each child element out to make it easier to see… all in the name of quicker load times and most likely a UNIX based server.

XAML is going to – at first – appear to be fingernails on a chalkboard after these web standards have been beaten into you.

CamelCase naming (capitolizations, no spaces, no underscores unless creating an alt command, no numbers… what?!) schemes, tabbing to indicate parent and children (if you don’t, it won’t even run – and I mean run as in the application form of “run”) – aka ORGANIZATION and the app.xaml being your friend for those who are comfortable with CSS.

Moving backwards so we can move forward – you start out with Page.xaml as your root and App.xaml for sharable elements.  They may not be shared w/ anything else, but for organizational purposes, the same way that you would have your html set up as “index.html” and “style.css” – XAML brings you “Page.xaml” and “App.xaml”.  So you put your structures in place within your Page.xaml and tell the structure to look at some name which has the visual atributes defined within App.xaml.

The awesome part about xaml is that you are able to do a whole heck of a lot more.  We’re not working with raster-based (bitmap/pixel based) images (unless you want to).  We’re working with vector based shapes.  This gives a whole lot more flexibility in the visual attributes, what they do, how opaque they are, gradient scales, their x-y coordinate placing, and also allows one to do key frame animations.

Much like Flash, the versatility of silverlight utilizing XAML is only hindered by your abilities to be creative.

Puts me in a warm happy place.