Perhaps it would be better to ask, which one would you NOT use?

But I’ve just recently switched jobs.  And I have to say, I’m pleased as punch.  Fresh outlook, new perspective, regaining my energy.  And I’ll say what I haven’t said in too long:

I love my job, I love my job, I love my job.

But now, as a Silverlight developer, I’m thrilled to see Windows Phone 7, and see that I can develop Silverlight 4 apps for Windows Phone 7.  And all the development tools are FREE.  It’s… it’s…  well, the only way I can describe it is that I was sitting in the audience at MIX10, listening to the announcements and my palms were sweating (in a good way).

I have to say, it’s a pretty impressive strategy from Microsoft.  Develop RIAs, Desktop (Out of Browser) Applications and Mobile apps, all with one tool, one language: Silverlight 4.

As soon as I have my first Windows Phone 7 app developed, I’ll let you know… hopefully in a few days.  I’m thrilled!  Yeah, yeah, yeah, Silverlight 4 isn’t actually supported in the mobile browser itself, but whatever.  Soon.  Very soon. It’s all coming together.

Get your free development tools here:  http://developer.windowsmobile.com

I realize that I am not necessarily entitled to some of the grumblings I have indulged in recently. Namely, I look at wireframes as a defined set of functionality and when someone messes with that, it frustrates me.

First, and most frequently, designers take a wireframe, and then they change things. They go outside the lines. And while conceptually it should be fine to change a layout when going from wireframe to storyboard, it can still have an impact on the development sometimes (what was one unified section for RIA gets split into two because they’re no longer next to each other, for example).

Don’t get me wrong, I’m all for championing the designers and making sure that the design fits the client’s vision. It’s an essential piece that too many projects neglect. However, I’m very cognizant (due to the nature of my business) of the fact that there need to be documented, measurable deliverables. I work in a business of developers. There are scrums, there are features, there are deliverables, there are deadlines.

And somehow, we all are surprised when things don’t align perfectly to the wireframes and specs, especially when design is thrown into the mix. Now, I happen to live between two worlds — the developer and the designer. I know what each needs, and I know each is essential. I also know that there needs to be a balance between these two worlds, and that we have to work together to guide, craft and deliver what the client really wants.

I see now that there are expectations that need to be managed better. I think it’s a great idea (from Nishant Kothary’s "Elephant in the Room" session) to have a contract that is defined between the designer and the reviewer. I’d like to apply that to my own thoughts — a contract around the wireframe.

And I liked Anthony Franco’s "The Laws of User Experience" session, where he reminded me that we should EXPECT to rewrite code. So rather than get frustrated when I need to rewrite, I want to remember that it’s part of the necessary process to get to the truly successful result.

Oh I love my job again. Gotta get to the next session.

http://channel9.msdn.com/shows/SilverlightTV/Silverlight-TV-Episode-2-Perspectives-on-Flash-and-Silverlight/

1. Create a custom theme and apply that theme.
2. Add a <link> to your css in the master page: 
   <link rel="stylesheet" type="text/css" href="/customstyles/sample.css"/>
3. Specify an AlternateCSS url (available via browser on publishing-enabled sites, but available via PowerShell on ALL other SharePoint sites).
4. Add a link using <SharePoint:CssRegistration>to your master page:
   <SharePoint:CssRegistration name="<% $SPUrl:~SiteCollection/Style Library/HtmlEditorCustomStyles.css%>" runat="server"/>

Note that all of the above will override core.css – except item 4. 

The Simplest Way

So if you want to load your own css after core.css, the simplest way is to use method 2.  In your master page, it should look something like this:

<Sharepoint:CssLink runat="server"/>
<SharePoint:Theme runat="server"/>
<link rel="stylesheet" type="text/css" href="/customstyles/sample.css"/>

The Details

SharePoint:CssLink loads a bunch of css files (including core.css) for you automatically, and in a special order, over which you have no control.  Say, for example, if you used method 4 above, and added a CssRegistration pointing to a special custom css file.  You can put that registration anywhere you like in the master page, but it will still load that css BEFORE any other.  Here’s a simplified guideline to the order:

[Any CSS files defined by CssRegistration, e.g., Band.css – see method 4]
[Optional CSS files defined by loaded controls, e.g., HtmlEditorCustomStyles.css] 
[Any CSS files defined in page layout, e.g., pageLayouts.css]
Core.css
[Any  Custom AlternateCss – see method 3]

So as you can see, CssLink controls the order of CssRegistration and alternate css.  But YOU have control over where you put ye olde school <link> to css (method 2). 

Another thing that is not loaded via SharePoint:CssLink is any theme css.  That’s done via SharePoint:Theme.  And the order you place SharePoint:CssLink and SharePoint:Theme WILL affect the order of the theme css.  Out of the box, SharePoint:Theme is last, and thus the theme css will load last.  If you swap the two so that SharePoint:Theme is first, then your theme css will load first, then all the other SharePoint css files, in the order specified above.

Clear as mud?  I thought so.  Just wait til I post about the order of CSS in SharePoint 2010.