If "stop being afraid and learn to love regular expressions" was a New Year’s resolution for you, then Grant Skinner just made things a whole lot easier for you. Seriously, if the System.Text.RegularExpressions namespaces isn’t part of your repetoire, then you’re missing out. It’s part of the Silverlight CLR too.
Looking for something to get those data visualization creative juices flowing? Look no further. This probably isn’t a comprehensive list of every cool data visualization I’ve seen in the last 2 years, but it’s really close.
There have been a lot of opinions flying around the web-o-net about the problems with the control templating model in Silverlight 2.0. I’m going to go out on a limb here, though, and say…I like it. That’s right, I like the new model. In fact (insert teeth gritting here), I wish we had done the same thing in WPF (gasp!).
The reasonable opinion against the new model (as I understand it) is based on the fact that Silverlight doesn’t have support for triggers in control templates (or just about anywhere for that matter). This means more code and less XAML for defining those behaviors.
In WPF, for example, if you wanted a control to respond to a mouse hover (and, say, change its color), you would create a trigger on the IsMouseOver property and then party in that trigger and create whatever storyboards (or setters) you want to implement that color change. This all happens in markup.
In Silverlight, on the other hand, the developer has to create an event handler for the MouseEnter and MouseLeave events and then explicitly load a set of storyboards with well known names to handle the transitions between those states. Silverlight is doing a lot less heavy lifting for you and there’s definitely a code component to what, in WPF, seemed like a simple XAML task.
See how much better Silverlight is? Okay, so the "better" part may not be obvious. Here’s my take though:
First, things got much cleaner in the new component model. Do you remember this doc? It’s an attempt to prioritize the eight (that’s right, eight) different "best practices" for expressing control state changes and behavior in your control. This includes: bindings, triggers, commands, named parts, etc. This is some serious complexity and leads to some serious lack of discoverability. This is why we needed projects like SimpleStyles. Templating for WPF controls is simply not predictable (let alone toolable, but we’ll get to that) so we end up needing a lot of sample code to get people off the ground. Plus, it’s really tough for developers. You have a myriad (well, eight) different recommendations for doing the same thing and the choice between them is not always clear even to an experienced WPF developer.
That said, you may have thought that the complexity was worth it. It may seem, after all, like this complex model puts flexibility in the designer’s hand since, of those eight, two (bindings and triggers) have a very strong markup component to them. Moreover, the Silverlight way (the named parts approach) looks a strong code component to it.
The thing that is easy to forget, though, is the fact that all of those bindable and triggerable properties and events had to be defined by a developer at one point. The IsMouseOver property had to be created somewhere. So at the end of the day, it’s not that behaviors require more code now, it’s just a different kind of code: more event handlers and fewer property change handlers to kick off behaviors.
Second, the Silverlight model has a very good chance of being much easier to use in a tool like Blend. Frankly, I haven’t seen a lot of people have great success with control templating in Blend. Button and Checkboxes don’t count. Try creating a template for a ComboBox or a Menu. It’s really hard, even if you know what you’re doing. Once again, this comes down to the complexity of the contract between the template and code.
Imagine, on the other hand, a model where you can simply walk through a checklist and provide elements for each of the UI "parts" of the template and storyboards for each of the "behaviors." Menu might have a lot of parts and behaviors, but at least there is a predicable way to discover and provide them. In this kind of a model, the designer could theoretically retain much (if not all) of the flexibility he has in WPF but have a much easier time accessing it.
Silverlight 2.0 isn’t there yet, but the model they’ve chosen is at least predictable and declarable and that gets us much closer to the templating Xanadu that I just described. Even in the meantime, we still have a model that’s much easier to understand and even code for and the only trade off is that now I the developer exposes behaviors by responding to events instead of responding to property changes.
Now having said all that, I would love to have triggers in control templates, styles and especially data templates in Silverlight. In fact, not having triggers in data templates has resulted in some serious hackery on my part (in which I end up creating a UserControl everytime we have a data template with any complexity). But I like where this new templating model is going and I hope it goes even further.
This is the best read I’ve had on a blog (if you can call A List Apart a blog) in a long time. It’s really mind opening.
Technical guys: don’t let the title fool you, this is for you too. For a long time, I’ve held on to the idea that creativity is a process that belongs to the technical guy on a team as much as the design guy. Andy would agree.
“Creativity is an inborn capacity for thinking differently than most, seeing differently, and making connections and perceiving relationships others miss. But most importantly, it is the ability to then extrapolate contextually useful ways of employing that data: to create something that meets a specific challenge. By this definition, creativity is merely a tool; it does not convey skill.” (my emphasis)
So, if you want a really unique perspective on what creativity is, where it comes from and how to best use a creative process (no matter what you do), definitely check this one out.
I’m behind. I wish I had found time to blog more over the last couple of weeks. MIX was awesome and I followed that up with an amazing week at SXSW. With all that, though, the thing that’s got me writing tonight is I finally have Silverlight content rendering in Kaxaml. That’s right, a real Silverlight surface in Kaxaml with back and forth communication. Woohoo!
Unfortunately, it’s not as done as it sounds. The good news is that I think I have all of the pending issues worked out except for one and that’s where I could use some help. There’s got to be a way to easily generate a schema for valid Silverlight XAML. I need it to run the code completion egnine. Unfortunately, I don’t know how to go about making one…any takers? Any XML geeks out there who know how to generate one or have one lying around?
Incidentally, WPFe.xsd (which gets installed with VS) isn’t complete. It seems to be 1.0 only. At the very least, I’d like to support the new 2.0 elements (Grid, Border, etc.). It would be nice to also include the SDK controls namespace since I can parse those.
If you can lend a hand, please do let me know. I’ll get the updated Kaxaml posted as soon as I can work through the other kinks.
The demand is outrageous! I only have like 80 left! (Okay, so I only started with 100 and I gave some to my kids before I left…but still). Don’t forget to get yours…they actually turned out to be really cool!
It wasn’t easy to find, so I thought I’d share the wealth: Here’s Deep Zoom Composer, the tool you need to prep images to work with Deep Zoom in Silverlight 2.0.
Not sure what Deep Zoom 2.0 is? Check out this Hard Rock Cafe memorabilia demo. (Non XAML nerds: you’ll need to install the beta of Silverlight 2.0 first) Very cool stuff!
One of the snippets that we’ll be discussing in our session on Friday is the code you need to wire up the MultiScaleImage (Deep Zoom) control. That means you can get it working in your app in something like 18 keystrokes (just a guess).
For that and other super handy snippets (for nerds and arists alike) be sure to check out the session (Friday at 10AM in Lando).
I love this guy. The topic is poignant and the delivery is superb. After you spend 20 unforgettable minutes with the message, get tips for delivery Sir Ken Robinson-style. My favorite nugget of wisdom: "Prepare, but don’t rehearse." Finally, someone is telling me not to rehearse. I couldn’t agree more, Sir Ken Robinson!
