1
votes

I work for a large company that has adopted sharepoint. I have been tasked with customizing and branding the site/subsites with CSS. My experience with sharepoint is minimal.

The development cycle is as follows:
1. Usability Requirements and design are delivered to The sharepoint developer.
2. The sharepoint developers comes up with the HTML
3. And I have to style that html as well as the sharepoint generated HTML.
4. Goes to test

This is driving me crazy-- The primary reason behind this cycle is that the "sharepoint developers" dont know CSS. The development environment is craziness itself. The css development is not centralized, it is VM based... So, I have to go developer by developer and log into their vm to work on their code.

TI go line by line some custom and some out of the box code to style it. The sites I am working on require EXTREMELY large amount of customization -- This is what is paying my bills so I just work hard -- but I am going mad in the process.

Can you guys share how you went about sharepoint customization. What kind of Development methodology and process did you use for sharepoint CSS. Do you believe that the Developers should be doing CSS customization and why?

No answer is useless, so please share. Thank you.

2
Wait, the "SharePoint Developers" don't know CSS? How can you work on the web and not know CSS? - Jermismo
Buy them CSS books for Christmas and all you guys sit down and work together ;-) - IrishChieftain
I'm sure they know 'some' CSS. I know CSS and I can even work with PhotoShop! That by no means makes me qualified to work on the design of the kind of sites my company produces ;) Leave it to the experts I say! (and C# is much more fun) - ArjanP

2 Answers

0
votes

Thats how it is.. I've never seen the stereotypical developer being any good at doing CSS work. (Yes there are exceptions but I've never met anyone who was exceptionally good at making CSS from a PhotoShop file who was also a developer. I gladly yield the job to people who are better at it.)

My designer works with SharePoint Designer and has access to the _layouts folder to put artifacts in. I make sure those artifacts end up in my deployable Visual Studio solution. Anything he does in SPD is manually copied, just stays in place or is put into features by me.

It does mean we have a lot of virtual servers, one for each project/client. I've never seen that is an issue because it is better than having to deal with the crap of all your other projects if you start sharing a server across projects. Also, these machines are available on the network and easily accessed using SPD and file shares. The designer never uses remote desktop.

Key is I facilitate the designers' work, make it as easy as possible. Your developers should do the same! They should:

  • Use out of the box sharepoint styles for custom code as much as possible (if they make their products look reasonable, it will be easier for you to finalise them)
  • Ask you for html templates on completely custom code & web parts. That way you can give them html that you have already styled, put in the right structure and added appropriate css to. When they deliver you'll get something that is easy to finish.
0
votes

There are 2 approaches to doing sharepoint branding (styling).

  • Developer Centric
  • User Centric

  • Developer centric means nobody but the designer /developer touches the css torugh a tool like SharePoint Designer (SPD). any changes are made using deployment of solutions etc.

  • User Centric means you just add files though SPD or the UI.

I am guessing you use the second, while I always use the first one, because that way the branding (styling) is controlled and changes are centralized / deployable. I have created a master page that is full xhtml strict 1.1 (but when actually used the crap SharePoint outputs negates this of course :-D), that i use in all my projects and for which the baseline css is pre defined and is so generic it can fit almost any layout form. Any functionality specific styling is put in a separate file and added to the masterpage.

To answer your actual question: knowing css in depth is IMHO not a requirement for a sharepoint developer, when the css is implemented as the C in CSS implies, i.e. cascading, developers need not even add css to their controls / webparts, they need to put everything in it in a surrounding container (a div or span etc.) which gets a class. any classes used inside the control (like for instance a table using an alternating row class) should be relative to that container class and should have a default implementation as well.

This would look something like:

/* default alternating row class */
.row-alternating
{
  background-color:red;
}

In a separate file define an override for this class when the design needs it. the developer need only know that the class for alternating rows is called .row-alternating

/* a developer adds a new control and wants the style to differ */
.newcontrol-container .row-alternating
{
  background-color:blue;
}

The control would look something like

<div class="newcontrol-container">
  <table>
    <tr>
      <td>bla</td>
    </tr>
    <tr class="row-alternating">
      <td>bla</td>
    </tr>
  </table>
</div>

P.S. if you want my mastpage + css leave a comment.