Couldn’t be more inspired. Want to rush back and change things. Want to improve the process, guide my clients (and products) to a better place. Better decisions, better process, better outcome.

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.

Advertisements

Flash evangelist has “gone to the Silverlight side” and talks about differences between Flash/Flex/Air and Silverlight.

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

SharePoint is a complex creature.  There are four ways you can insert your own custom css:

  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.

Silverlight 4

February 4, 2010

I know I’m fortunate.  I do.  I’m working on a challenging SharePoint 2010 project right now and enjoying it.  But I’m just going crazy because I don’t have any time to play with Silverlight 4 right now.  And there are *so* many companies that are starting to really dive into Silverlight, which thrills me.  But I want to be working on those projects too.  Can I clone myself?  Rats, I don’t have time to figure out how to do that either.

C# all the way, baby

January 6, 2010

My son knew even at 16 months that VB.NET was *so* uncool.

176

SharePoint 2010 Musings

December 12, 2009

After messing about with SharePoint 2010, I have a few comments.

Ribbon – It’s extensible, and supports MUI (multilingual user interface).  Stays pinned to the top when scroll.  Not sure I like that it stays pinned to the top.  While it is useful for editing (a user wants to insert an image near the bottom of a long page and doesn’t want to scroll to the top to get to the “insert image” button), the positioning (under the banner) chews up some valuable real estate, plus the CSS involved is not pretty.  Trying to do a sticky footer with this is… unpleasant.  Still, the idea is that the ribbon allows for fewer page refreshes as you’re editing different things.  I like this concept.  As for permissions, individual items on a ribbon are NOT security-trimmed.  For example, a visitor to a site can see the “Library” ribbon tab, which has items such as “E-mail a link” and “Open with Explorer”.  However, they can also see ALL the other items they don’t have permission to do (they’re grayed out), such as “Create view”, “Edit Library”, “Form Web Parts”, etc., which are things that I do NOT want a user to have to see. 

CSS – “!important” qualifiers are all over the place in the corev4.css.  I’m very disappointed in this.  Not a good practice.

Web parts – You can insert web parts within content blocks now as a default.  This is good or bad, depending on your point of view.  If I have a situation where I want to restrict where web parts can go, I have to nail things down.  Another interesting side effect is that you can actually style the contents of the web parts using the editing toolbar (only of web parts that were inserted into a content area).  Which again, is good and bad.  I liked the AJAX options that are available (make a refresh button available, allow for timed asynchronous refreshes).  Lastly, even users that are “visitors” are able to hover over a web part and see a checkbox in the top left of the web part area.  However, they don’t have permissions to do anything with that checkbox, so it’s just confusing.  Hopefully this is something that will be fixed before release.

Editing experience – When editing, pressing the Enter key doesn’t create a new paragraph, it creates a new div.  Very interesting choice.

Master pages – A few pages (login, error, etc.) can have a custom master page applied via PowerShell.  Haven’t tried this yet.  In addition, for pages that leverage application.master (it’s actually applicationv4.master now), looks like you can update that master page.  According to the official Microsoft documentation (provided at the SharePoint Conference):  “Administrators will be able to specify whether the system pages in the _Layouts folder are rendered using the site master pages provided by site owners or by default master pages available across the system. In SharePoint Server 2007, pages rendered from this directory used application.master. This presented a challenge to organizations who wanted to create a custom UI — since application.master is a system file and there was no option to use a custom master page for this, the only options available were to modify the system file or to style the page with a custom theme. It should be noted that customizing application.master was not recommended because in the event that something unfortunate happened to this master page, none of the system settings for a site could be accessed. Not only does SharePoint 2010 add greater flexibility for how to apply branding to these system pages but it also provides a fail-safe mechanism. If there is an error in the master page used for pages in the _Layouts, SharePoint will reference the default.master file so that system pages can still be accessed.”  I’m hopeful, but will provide an update once I actually get into this deeper.

Visual Upgrade – SharePoint 2010 will be able to use SharePoint 2007 master pages and CSS.  Here’s another blurb from the SharePoint Conference book:  “By default when a content database is upgraded post upgrade the sites will be displayed using the Office SharePoint Server 2007 visuals, giving the user their familiar look and feel. An upgrade site can then exist in one of three states: Office SharePoint Server 2007, SharePoint 2010 preview mode, and SharePoint 2010. This allows the site administrator the ability to first view the site with the SharePoint 2010 user interface before committing to it. This setting is at the Web level allowing for a very granular, flexible experience.”

XSLT – I’m also eager to examine the XSLT support that is provided for views.  Supposedly better editing in SharePoint Designer, too. 

Browser support – IE7, IE8, FF3.5 and Safari4, but NOT IE6.  I like the dance of celebration regarding this here:  http://blog.drisgill.com/2009/11/sp2010-branding-tip-5-handling.html  That blog post also mentions a cool control that can be leveraged, as well:  <SharePoint:WarnOnUnsupportedBrowsers runat="server"/>. 

Missed the Webinar?

December 4, 2009

If you missed my webinar, Microsoft Technet: Design Considerations for a Public Facing Site (in SharePoint), you can still watch it with live meeting replay.

Advertisements