Tip: Fix List Issues After Migration 2010 -> 2013

Once again, faced with issue after issue. There was a SharePoint intranet that was migrated from SP2010 to SP2013. There was a list in the intranet, containing crucial information that should be easily searched. However, there was no list search available. Also, none of the columns were site columns. So I set out to create a search page for the list data. Everything runs cool if you just try to search with data in the title field (or author). However, there were some other fields including data to search wih.

Piece of cake, I thought to myself, disregarding the fact that most of the time the pieces of cake are tough to chew when it comes to SharePoint. I created some site columns and added them to the list, positioning them next to the original ones, with the intention to simply open the list in quick edit mode and copy values from list columns to site columns. Easy enough!

However, the list being a custom list originating in SP2010, the quick view was unavailable. I contemplated on exporting the data to Excel, modifying it there and creating a new list using that sheet. Before attempting that, I decided to google just a bit in hopes of finding a solution. And I did, hurray for Saludeen Rajack!

Since I had already tried most of the tricks in the blog post, in vain, I crossed my fingers and opened the list page for editing, opened list web properties and added clienttemplates.js to the JS Link property of the web part (at the very bottom of the Miscellaneous section).

And lo and behold! First of all, the list search box appeared at the top of the list and secondly, the quick edit button became active. 

Now I could proceed with my plans properly.

Tip: Targeting a specific SharePoint site with global CSS

Just a little css tip, that came out handy today. Generally, with a global css (say, an alternate style sheet that is deployed throughout the site collection), you don't even attempt targeting some specific site, but go with the global styles instead. Today, however, I was struggling to display the titlerow (logo and navigation) in the enterprise search center without having it become visible in the dialogs as well.

Some Microsoft logic it is, I guess, that the search center by default hides the site collection navigation using the same class as the dialogs, the .ms-dialogHidden. And as anyone working with SharePoint CSS knows, the sites have no IDs in the body tag so that you could e.g. tell your css to display the navigation in search site but not in the dialogs. None, except for the action attribute in the form tag.

I guess it never was as big of an issue before, since I never thought of it before, but indeed, in a site collection already populated with sites, you can target one specific site by using the attribute selector for form tag in your css rule, for the form action contains the relative address of the site in it + in SharePoint, the whole page is always inside of that form tag. So here's the rule for un-hiding the titlerow for this specific search center, just as an example:

form[action*="searchcenter"] #s4-titlerow.ms-dialogHidden {

    display: block !important;

}

And, yey, the dialogs remain untouched and furthermore, there is no need to impelemnt page level css on each and every search center page.

Inbuilt IE8 hack for SharePoint 2013

Doing yet another UI branding for a customer, and especially the optimzation for each and any Internet Explorer version from 8 on, I stumbled upon something quite interesting and useful too.

I mostly prefer the CSS rule hacks (e.g. using /9 for IE8) over comments and separate stylesheets and/or classes (read more about the options in Web Designer Wall), and try to come up with the most browser-generic solutions as possible. But IE8 is a problem child, that's for sure (fortunately, with SP2013 we don't need to deal with IE7 anymore!). 

The SharePoint team has obviously noted this too. So what I discovered today, when changing the color of the left side of the suite bar (id="suiteBarLeft") is this general class ms-core-needIEFilter that gets inserted to the page by some SharePoint JavaScript when the browser mode is Internet Explorer 8.

For example, this suiteBarLeft just happens to get an IE8 fix for its background, resulting in my custom background color not taking effect. And !important does not do the trick, for the overriding CSS rule is actually a filter rule, not background(-color) rule - which is there too, actually, set to transparent, so the complete fix for the suiteBar backgrouns customization is

.ms-core-needIEFilter #suiteBarLeft {

    filter:none;
    background-color: #92D050;

}

As stated, this class ms-core-needIEFilter exists globally (somewhere - I could not place the class in the DOM tree) on the SharePoint pages when browser is IE8, and thus is quite useful for any IE8 hacks that are needed in any custom UI. I tried out a few, and it works like a dream :)

Creating a Metro Tile Web Part

Metro style is the hot topic right now, so it is only right to take a look at how to make your SharePoint site more Metro too. You can build Metro blocks in the Content Editor Web Part, of course, but wouldn't it be so much easier to manage the tile content if the data was in a SharePoint list instead of being static content in a CEWP?

What you need in your (Empty SharePoint project) is

• a List Definition and a List Instance for your source list - and I took it one step further by creating the Content Type for the list as well
• the WebPart
• your own CSS stylesheet in the mapped _Layouts folder

I am not going to go step by step through the process of creating these elements. For more info on creating SharePoint projects, webparts, content types, stylesheets etc. please check out some of my previous posts, e.g. in categories WebParts, Branding and Customization.

There's a whole lot of little things to do to put the thing together, and I will walk through the main points here.

For the Content Type (or the List Definition, if you are not creating a Content Type), you need to add the list fields and field references in its Elements.xml file. I used four fields in addtion to the Title field:

• tile icon url field
• tile content note field, setting the parameter HTMLEncode="true" to enable HTML tags in the content
• tile background color (text) field for the background color as HEX code
• tile url field (used to create a link wrapper around the icon and title)

In the ListDefinition Schema file you need to add the field references to the default view (BaseViewID 1) to show them in the AllItems view of the list. With the Fields and FieldRefs, remember that whether the tag has an endind tag or not really is of essence:

• in Content Type Elements.xml both the Field and FieldRef tags are one-piece, eg:
  <Field Name="TileLink" DisplayName="Tile Hyperlink" ID="{GUID here}" Type="URL" Required="true"/>
  and
  <FieldRef Name="TileLink"/>
• in List Definition Schema.xml the FieldRef inside the Content Type element is as above, but the FieldRefs in the View elements are two-piece:
  <FieldRef Name="TileLink">
  </FieldRef>

Also, remember to check the titles, descriptions and urls for the ContentType, ListDefinition and ListInstance, as well as the Web Part too, of course.

Once the list is done (and tested), add the Layout folder mapping to your project, and an empty CSS stylesheet in the project folder inside Layouts.

Then, add the WebPart to your project. In the WebPart .cs file, inside the CreateChildControls method, you need to

• add the CSS reference
  If you are not trying to override corev4.css, this simple line is fine:
  CssRegistration.Register("/_layouts/MetroTileWebPart/TileStyles.css");
  and as for this project, this goes fine, since only our own classes need to be used. But if you need to make sure that the CSS is read after the corev4.css, see this blog post for the instructions.
• retrieve the list items
  SPSite thisSite = SPContext.Current.Site;
  SPWeb rootsite = thisSite.RootWeb;
  SPList tilelist = rootsite.Lists["MetroTilesList"];
  SPListItemCollection items = tilelist.GetItems();
• loop through the items 
  A foreach loop is fine. 
• get field values for each item
  For any e.g. string type data (here the color and the content) you can use:
  string tilecontent = item["TileContent"].ToString();
  But if you try this with the hyperlink fields, due to the Description field embedded in it, you will get a double hyperlink value, separated by a comma, and that won't work. So you need to use the SPFieldUrlValue to get only the url value:
  SPFieldUrlValue TileUrlvalue = new SPFieldUrlValue(item["TileLink"].ToString());
  string tileurl = TileUrlvalue.Url;As for the title, you can simply refer to it with item.Title.
• and create the html for the webpart
  Using LiteralControls you can quite easily create the HTML for each tile, using the field values in the places needed:

And then you need to create the CSS for the classes. The key points in the CSS here being:

• the main element here is the tilecontainer, and for this 3 in a row, my CSS rules for it are:
  width:30%;
  padding: 10px;
  float:left;
  margin: 5px; /* to create a consistent 10px space between tiles */ 
• using the pseudo-element :nth-type-of(N), you can make the n:th (in this case the fourth) tile position itself neatly below the first tile instead of e.g. below the last tile of the row, if the tiles differ in height:
  div.tilecontainer:nth-of-type(3n+1) {clear: left;}
• the background of the content span is white opaque so that it sits nicely with which ever color tile, but the IE7 and IE8 don't understand the rgba-rule, so I set the background as #dedede for them:
  background: rgba(255, 255, 255, 0.4);
  *background: #dedede;

Otherwise, the CSS is all about the positionings and colors and margins etc. of the contents of the tiles.

For more info on Metro style UX desing, see: http://msdn.microsoft.com/en-us/windows/apps/.

[See also: Add Properties to Your Web Part]

SharePoint UI Version5

Some 6 months or so ago I downloaded this demo MasterPage v5 zip, i.e. a package containing a MasterPage done in HTML5 format, CSS3 used for styling and some JavaScript to make the UI responsive and adapt to different devices and size of screens. I have been so wrapped up in other stuff, that I tried it out first time only this week, to demo it in the seminar on Tuesday.

The example is quite cool, featuring most of the general branding scenarios, and triggered the onClick in me, starting the learning-by-doing process. In a sense, I have long known how to go about it, but never have really taken it to my core line of work, to implement the stuff in SharePoint. So off to work I was, and as for here and now, welcome yourself to some notes on how to make it happen.

As for the MasterPage, you can build it more or less the way you always have, for HTML5 understands all of the old fluently. But, if you really want to use HTML5, you might want to rethink the normal DIV repertoire and replace some divs with the new elements, e.g. HEADER, HGROUP, SECTION, FOOTER, NAV, to mention the most probably needed ones. One thing to keep in mind though, is that section != div. You still need the divs. Sections are more general semantic element.

My basic structure for the MasterPage looks like this (after the basic workspace and bodycontainer divs, and discarding all the rest of the SharePoint stuff like page editing status bar etc.):

<header>

  <hgroup> <!-- in my case this is a bit unnecessary though, since my top nav is outside the header -->

    <!-- several divs for sitelogo, search etc. -->

  </hgroup>

</header>

<nav id="topnavi">

  <!-- global navigation -->

</nav>

<section id="contentwrap">

  <nav id="lefnavi">

    <!-- left navigation -->

  </nav>

  <div class="s4-ca with-leftnav" id="MSO_ContentTable">

              <!-- mso_contentdiv required, helps SharePoint put the web part editing pane in the main body on the right -->

        <div id="MSO_ContentDiv" runat="server">

                  <!-- page content loads from the pages and pages layout -->

                  <asp:ContentPlaceHolder ID="PlaceHolderMain" runat="server" />

        </div>

    </div>

</section>

<footer>

  <!-- divs for footer content -->

</footer>

Oh, and note the HTML5 Doctype and HTML tag (for MasterPage), simply with no schema declarations:

<!DOCTYPE html>

<html lang="<%$Resources:wss,language_value%>" dir="<%$Resources:wss,multipages_direction_dir_value%>" runat="server" __expr-val-dir="ltr">

As for the CSS, many things are just the same as with XHTML. But then there's a lot more you can do. Plus things to do to maintain the backwards browser compatibility! Without any regard to this, this is what you might get

in IE9 and any other current browser:

and this is how it looks like in IE7 (IE8 isn't much different but at least it understands floats!):

So how to go about it? I will point out some of the things I did with this UI of mine, and how to make them work in the older browsers as well:

• The general older browser fix is to set the SECTION, HEADER etc. to display:block by default in your CSS
• In my styling the trickiest parts are the drop shadow of the header and the selected link, the rounded corners, the opacity used in almost all backgrounds and the gradient background of the whole workspace. They currently require several different targeted rules in order to fly in all browsers.
• Let's start with the gradient background. "Simply" apply CSS rules for all different browsers, using the ms filter fix to make it happen also in IE7/8 (already implemented in the picture above):
  background: #fff;
  background: -moz-linear-gradient(top, #7e8598 0%, #fff 75%);
  background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#7e8598), color-stop(75%,#fff));
  background: -webkit-linear-gradient(top, #7e8598 0%,#fff 75%);
  background: -o-linear-gradient(top, #7e8598 0%,#fff 75%);
  background: -ms-linear-gradient(top, #7e8598 0%,#fff 75%);
  filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#7e8598', endColorstr='#ffffff',GradientType=0 );
  background: linear-gradient(top, #7e8598 0%,#fff 75%);
• Then there are the rounded corners. As for most browsers, they can be done in a combo way of several rules, e.g. my header corners:
  border-radius: 10px;
  -webkit-border-radius: 10px
  -moz-border-radius: 10px;
  -o-border-radius: 10px;
  As for IE7/IE8, they won't be round unless you want to use e.g. the htc fix or some code, such as CurvyCorners - see this pretty good article on rounded corners. 
• The header also has a drop shadow. For most browsers, you need a similar set of rules as the corners:
  -webkit-box-shadow: -1px -5px 5px rgba(0, 0, 0, 0.5);
  -moz-box-shadow: -1px -5px 5px rgba(0, 0, 0, 0.5);
  -o-box-shadow: -1px -5px 5px rgba(0, 0, 0, 0.5);
  box-shadow: -1px -5px 5px rgba(0, 0, 0, 0.5);
  and then the filters for IE7 and IE8 - they don't make as fancy a shadow though, so I simply left it out of the final UI:
  /* for IE8 */
  -ms-filter: "progid:DXImageTransform.Microsoft.Shadow(Strength=5, Direction=45, Color='#333333')";
  /* For IE 5.5 - 7 */
  filter: progid:DXImageTransform.Microsoft.Shadow(Strength=5, Direction=45, Color='#333333');

The IE8 version of a shadow:

• Then there is the transparent background color. As for the CSS3 compatible browsers, this is quite simple:
  background: rgba(255, 255, 255, 0.95);
  the last decimal number being the opacity value.
  As for IE7 and 8, there's ways of doing this, some of them work, some of them didn't seem to. I decided to make things easy for me and go with solid colors for older browsers.

Add some multiple backgrounds and stuff, and there's more to do, this was just the basics for this site. I suppose we're getting there, but (ok, I know I'm repeating myself now) until we're done with IE8 and older + the other browsers start to all implement the standard CSS3... unh...

For more information and HTML5 + CSS3 tutorials, see e.g. w3Schools tutorials. And besides these, there are many other good ones for HTML5 and CSS3. I myself found e.g. the Impressive Webs quite cool, not a conventional tutorial really, but having many cool tips and info in edible bits.

Branding SharePoint - What, How, Why?

In our own SharePoint seminar Hyvät, pahat ja rumat (the good, the bad and the ugly) I gave a presentation on SharePoint Branding - what you can do and how you should do it. Many aspects of this topic I have covered in several posts in this blog from a quite technical perspective, jumping straight to how. Let's have a look at the what and why, and a bit more general how.

Why?

SharePoint out of the box is fully functional and ready to use from the UI perspective, too. But to be honest, it's not exactly pretty. Whereas the v4.master for team sites is maybe adoptable for a team site based intranet, the nightandday masterpage can really not be seen as anything else but an example of a publishing master. Neither one of them has the look and feel of the company implementing SharePoint, naturally. The best you can do without some sort of web development is use themes and change the logo, and save the site as template.

In most cases this is not enough. Even the intranet should look nice and reflect the company brand. Once I had made this branding solution to a company, the page all branded and looking nice, but when the customer representative first saw it, his first comment was: "That ribbon is the wrong color!" I changed the color of the ribbon row and he sighed: "Now it's feeling more homey." Despite what the IT guys and the developers might like to believe, branding is important, beyond the usability issues.

What?

SharePoint pages are HTML and CSS, just like any other web pages. It's got a whole lot of server side C# code and client side JavaScript in it, but as for the UI, it is (to be exact) XHTML (1.x) and CSS (2.1), and thus almost as customizable and flexible as web development in general. Almost. So why isn't any web developer capable of SharePoint branding? Because of the server environment, special functionalities and UI with the ribbon and webparts, and that server side code.

It is essential to understand the structure of SharePoint in order to understand what can be done, what not, and how to do it in a SharePoint way. You need to know about the SharePoint controls in order to know what to use and what to maybe ditch. You need to know that you can never ever delete the PlaceHolders from the masterpage (the what from where? - exactly! you need to know!). You need to know that there are limitations to the branding. E.g. webparts have a table-based HTML structure with a limited amount of unique IDs and as for the branding of web parts you are tied to this. You can go to an extent, but you may not be able realize all of the wild visions of the designer who knows nothing about the SharePoint limitations.

How?

Microsoft and several other instances promote SharePoint Designer a lot. But seriously: it is a good tool for e.g. external data connections, customizing list views on a specific page, creating a custom workflow etc. stuff for a single existing site, but it is not a branding tool when you want to have a managable branding solution that can easily be deployed in several site collections and not breaking with migration. For that, you really need a proper SharePoint branding solution made in a managable way in VisualStudio, deployed as a .wsp package, full with features.

A typical branding solution can contain:

• 1-4 custom masterpages
• 0-4 custom page layouts
• 1 or more CSS files
• branding images
• possibly JavaScript files
• possibly content types
• possibly custom Content Query Web Parts
• feature and event receivers to automatize the masterpage implementation

Currently I still use XHTML and the CSS v2. There are a whole lot of IE7s still in use in the customer organizations, and even these web technologies create some problems with IE7 and require some specific CSS rules (instead of separate stylesheets, I prefer the * prefix to target IE7) in order to look like it should. HTML5 used in the way intended requires a whole lot of polyfills to work in older browsers, and CSS3 features are still partly browser tech dependent (i.e. webkit vs. moz) as is, so using those already means double work in many places, let alone targeting IE7, unless we simply decide the IE7 users be left with a less rich UI.

But, the future is in HTML5 and CSS3 plus JavaScript, so it's only a matter of time really. Mobile world is already there, more than the regular PC.

Some resources for browser compatibilities:

http://html5readiness.com/
http://mobilehtml5.org/
http://www.findmebyip.com/litmus/
http://www.quirksmode.org/m/table.html

Top Appeals of HTML5 & CSS3 - and Why It's Not Yet Enough

Taking a quite subjective viewpoint here to this much discussed topic, this article is about what I find to be the most appealing features of HTML5 and CSS3, and then again the reasons why I still don't use them (at least not much), in my line of work.

I create branding solutions according to graphic layouts created by graphic designers at advertisement agencies. Most of the branding solutions are for company intranets/extranets, quite often with a pre-defined set of browsers, quite often with a clausule "most of our employees still have Internet Explorer 7". Look at eg. the chart here to see how much use there is of HTML5 and CSS3 with the IE7! So yes, this is the uttermost reason for me to not to use HTML5 just yet. CSS3 I do use a bit, knowing that the IE7 users will be missing the fun.

As for the appeals, or should I say, the things that I most anticipate, waiting to be able to fully start to utilize these newer web technologies:

1. rounded corners
2. drop shadows
   The designers and the customers love this stuff! And yeah, they look nice. But did you know that in order to build a box with rounded corners (and/or drop shadows) takes either a fixed size (you can use a single background image), 3 div-elements (partial sccalability), or all of 6 divs (full scalability)? And when the borders and shadows and fills are different colors here and something else there, you need a new set of classes for each box. It's not a walk in the park with CSS3 yet either, what with the different browser supports, but it has potential.
3. transparency
   You can do it without CSS3 too - but you need a different atribute for each browser.
4. multiple background images
   Multiple background images? Not without multiple divs - but with CSS3 it's possible and this would be extremely useful in many cases, especially when the designers decide to make web parts look extra fancy.
5. the new css selectors such as nth-child, last-of-type etc.
   How many times is the request to have "every other line (eg. of a SharePoint generated list) with light gray background or the first one looking like this and the last one like that and maybe we could even have the second last look a bit different"? With CSS3 you can.

So actually, the top 5 for one working with SharePoint branding is all about CSS3. Then again, SharePoint branding is more about CSS than (X)HTML. The site wire frame is such basic html that whether I use div class="footer" or simply footer-element, is mostly irrelevant. But if I needed to choose the two most appealing HTML5 features in general, they would be:

1. video embedding
   Now, if we could forget the IE7 (and even IE8), this would be one of the best working features in these single-browser environments (since the whole video format support part of this is still a mess) like we have in quite many companies.
2. easier forms
   This would be an extremely cool thing if only the browsers would support the features for real. I made a little experiment on my own (non-SharePoint) test site, out of curiosity. I made an HTML5 form, using all of the new features available, and NONE of the browsers (Opera, Safari, Chrome, IE7-9, Firefox - the newest versions available at the time, Aug. 2011) supported everything and in most cases most of the more useful features simply were lost. And as for me again, I don't really need to create forms, or if I do it's InfoPath.

Ok, among the other cool things, there is also the canvas, the geolocation, the local storage and session storage etc. etc. But they don't really play any role in my line of work, so I'll leave it to someone else to sing their praise. With SharePoint, especially with intranets, especially with the older IEs still in the picture, I'm still waiting for the right time to switch to HTML5, and CSS3 for good.

P.S. The mobile browsers generally have a pretty good support for HTML5 and CSS3
Most of the mobile browsers, eg. for the Safari for iOS, and most Android browsers, have a nice support for the most common HTML5 and CSS3 features. Take a look at this here chart. Looks nice, huh?