Jose Fajardo

Silverlight and WPF

20080417 Thursday April 17, 2008

My "Digg Mashup" part 2 - laying your project out

Welcome back, this is going to be a quick post on the general layout of the DIGG project, explaining my naming convention and general choice in architecture...

Project Folders

Most Silverlight applications by the time they're completed will consist of hundreds if not thousands of files or if you take a more componentized approach will consist of many DLL's which themselves contain dozens of files. So how do you organize this mess? Folders. Pretty logical..

image

 

There are 3 folders that I sort things into, actually there are 4 but the forth one isn't included in this project because I haven't found a need for it yet...

1. Extended Controls - these are user-controls that are consumed within other extended controls or within a screen. Basically they are just a usercontrol that has controls or other user-controls in them. They are consumed through out the rest of the application.

image

One piece of advice I would like to impart on anyone wanting to listen, "don't be afraid of user-controls"! Learn to create them and create many of them. I've been doing this for a year and I can confidently say that I am where I am, in that I am 100% comfortable with Blend/Design and VS2008 because of this. I can hear a lot of fellow developers out there moaning "what about performance", true BUT I can tell you that it really doesn't affect it that much, and I have prototyped some massive applications (like a mail one that rivals the AOL's version). It does introduce other issues around code management etc. but the good outweighs the bad.

A lot of people will create one user-control (page) that contains all the controls in it, each to there own but for me I could never do that. That is one of the major problems with asp.net and windows forms, I've found my nirvana in using many user-controls and I'm going to stick with it :). And if you find that a particular user-control is overkill then refactor it back into an existing user-control or into a base page user-control. That leads to my second piece of advice...

Learn to refactor regularly, don't be afraid to change your code. As unproductive as that may sound in reality, because Silverlight is so new to everyone, it's probably the best approach to take given these circumstances. Taking the time right now to try new things, make mistakes, learn from them and refactor will set you up for a bright future in Silverlight RIA! That's been my approach.

I'll talk more later regarding user-controls ...

 

2. Screens - as the name suggests all my screens are found in here. Screens are just user-controls that have a whole heap of other user-controls, or actual controls, on them. I just find it easier to sort them into there own folder from a management perspective.

image

As you can see from my screen shot I have been doing a lot of prototyping to replicate the DIGG UI but pulling/pushing data from/to a lot of different 3rd party API's. I wanted to see just how well Silverlight handled the true mashup scenario. First impressions, not good :( Due to both MS's fault and the 3rd party providers fault. I'll talk more on this later...

 

3. Templates - skining in Blend 2.5 beta for Silverlight is currently non-existent, the reason why I'm fluent in skinning is because I've created a tried and tested approach to it. This is my approach and it's not rocket science, everything I want to skin has it's own user-control. If I want to create a skinned button, or a skinned scroll-bar, I create it in it's own usercontrol first. This allows me to visually tweak it and see that it does everything I want it to. Once it's perfect I have a methodical process of copy/paste into the relevant template area, if you read my previous post there are 4 potential places to put your skin in. This is the approach I take with all my skins and all of the skins I've created can be found in this folder.

image

The following is just some of the skins I've applied:

image

 

Once again I have to reiterate the importance of being comfortable with creating user-controls. Get in the habit of using them and removing them when you don't need them anymore.

 

4. Popup's - this folder is missing in this project because there isn't any popup's in this RIA. A popup is just another user-control. It may be the resulting list from a drop-down list control, the main display area of a tool-tip or an alert box that popup's up from a user initiated action. These popup's are launched using the actual Silverlight popup control.

more of this in a future post...

 

User Controls

I can only speak for myself, and as I've stated above I use user-controls like I do salt on chips. One of the downsides to having heaps of controls is that it blows out the size of your project. In the case of template controls I only use them to work out if a skin does what I want it to do, after it's confirmed I tend to exclude them from the project so that when it compiles it's not included in the xap.

With all this talk regarding using user-controls everywhere, please don't think that I just create them without concern for design and performance. I'm not that stupid. I create user-controls following these rules

(a) Makes the life of the designer better

(b) doesn't impact performance negatively (within reason from point a above)

(c) Makes the UI more manageable

(d) you need to skin a control

 

User Control Communication

When using user-controls take a step back and think about the bigger picture. A page is just a user-control. The UI elements sitting on the page are just custom user-controls built by you or Silverlight standard controls configured by you. Everything sitting on a page needs to communicate to the page and between each other, in my next post I'll walk through my "event model" and talk through a lot of things I uncovered regarding event's in general within Silverlight beta. There were a lot of lessons learnt especially around the UI and updating the UI from an event, stay tuned for these findings in my next post..

 

Ending Rant

I wanted to end with a quick rant, I didn't get the chance to do it at the end of my last post so I'm itching to do it now. There are 2 important points I want to make...

 

1. Designers are more important to the workflow then you might think. I've come to realize over the last year that what will distinguish RIA's from each other is not the managed code or the back end stuff but rather the user interface (UI) and the user experience (UX). The .Net community have been writing code for the last decade, we have an amazing arsenal of resources that include patterns and frameworks etc . In a years time after Silverlight is launched there will be an insane amount of code frameworks to leverage, even now there's heaps of code out there to call on. In the new world it will be the Designer that will be the bottle neck, and the really good designers out there will be worth their weight in gold!

As hard as you may want to fight it the role of the designer in the world of software development is inevitable! One of the major reason for me joining Cynergy is to see why Flash/Flex is taking off and how a true UI/UX design focused approach to software development works. It's been eye opening working here and I can honestly say that applications that have a UI/UX component to it is infinitely better than one that is run purely out of an IT department with only coders and  PM's managing it.

As the industry matures and more applications are released that make full use of this new UI model people are going to be forced into making their applications "beautiful" yet functional, it's only a matter of time till this happens!

Saying that not everything will need a designer, actually a developer using the simple tools in blend or vs2008 will fill the role of a designer much like they have been over the last several years with ASP.NET and Windows Forms.

I've had the pleasure working at all levels in IT from consultant to architect to software shops as a code cutter. The UI has always been the least thought thru part of the overall development process. Expression suite of products, VS2008 and XAML will change all that, in time it will!

 

2. Silverlight 2 is so close to being ready for prime time enterprise use. If you have a .Net team in house and if your in a position to influence technology uptake then by nature of your job role you should be investigating Silverlight, if you aren't already doing it that is. I'm not suggesting to use Silverlight over windows forms or asp.net, what am saying is that it is ready to be thrown into the evaluation process along side windows forms or asp.net based applications. It honestly is :)

 

Till my next post...

 

 

 

 

 

 

 

 

Posted by josefajardo | Apr 17 2008, 10:21:10 AM EST
XML