Handyman Toolkit

Posted on

By the end of Chapter 5 of the book, I’ve discovered that yes, you can learn how to use this software without the assistance of a book, but had I been able to obtain this book a year ago when I started tinkering with Blend during my spare time, I would have greatly benefited from having this “in my back pocket” sort to speak.

The biggest confusion factor which I had when cutting myself off of Adobe products, cold turkey, to force myself to learn how to use Design and Blend, was the “when do I use the stackpanel over wrap panel?” or “Should I make this a canvas or a grid?”. Plus there was the creation of something primarily vector instead of part raster and part vector – that bit is something that illustrator gurus will likely not have any problems with, but most who design for the web tend to take preference to Photoshop – and only on occasion delve into primarily vector bases.

Now, the intent of this chapter was to get you familiar with the Layout elements and the unique attributes each layout element presents, however, there are underlying instructions which would assist a raster-based designer into being more comfortable with the ideas and ease when using vector shapes. They’re not that different to create and have the added scalability that raster(bitmap based) images just cannot do due to their innate nature.

In any event, the entire chapter is essentially “This is what X is, how about we apply this to give you hands-on experience with X”. We went over the following: Border, Canvas, DockPanel, Grid, Scroll Viewer, StackPanel, UniformGrid, ViewBox, and WrapPanel layout elements.

By the end of the chapter, the application is like a circus of vendors in graphical format. Victor is sure to mention in his book that he’s well aware of the lack of space towards the end.

Without further ado, I present my circus:

Click to view full sized image
Click to view full sized image

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

Posted on

What is the title talking about?


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.