Search

My next few posts will cover branding including design packages, composed looks, standard branding like SharePoint 2010 and navigation options. Keep in mind that all of this will be from a developers perspective and will mostly focus on how we as developers can take something that has been created by our designers and develop/deploy it regardless if it is in a design package, a composed look or a simple master page.

1. Design Packages – Are these useful to developers?
2. Composed Looks – How can these be deployed from a WSP we have built?
3. Standard Branding – Developing and deploying branding the same as SharePoint 2010
4. Navigation – The options
5. Style the masterpage

Design Package – What’s kool

Before I go into detail on using design packages for deploying changes, let me mention some kool stuff that can be half used with this just while in development, or pure config in production. The design manager has a few purposes, to specify what to do for different devices, allow users to add code snippets, create masterpages, manage display templates and page layouts. So you can see there may be bits and pieces you decide to use when using these new features. Keep in mind that you need publishing features turned on to access this kool stuff…

Editing Masterpage and page layouts. The new masterpage functionality where you can upload a masterpage is pretty kool, i think its easier to give a designer the seattle.html file however, and then they can edit from there. I mostly say this as its easier doing it that way with the sharepoint components already added, than it is for sharepoint to add the bits back in. If you upload a master page directly it still needs a bit of tweaking to get it really going.http://msdn.microsoft.com/en-us/library/dn205271.aspx

Design Package (exported) – What’s inside?

Design packages look like a good thing for designers, or power users who do not have the skills to create a custom solution in Visual Studio to deploy branding. But as developers should we utilise this functionality? It’s worth having a quick look to see what a design package really is, there may be some components we can use.

Lets make some changes to our site first before we export a design package.

1. Go to Site Settings > Look and Feel > Design Manager

2. Click on Edit Master Pages

3. Click on Create a minimal master page

4. Type in a name for the master page and click OK

5. Now click on Create Design Package

6. Type in a name and click on Create. Once this is finished click on Your Package is ready. Click here to download.

The first feature deploys list instances and content types related to themes. The content types and fields that are included here are OOTB ones, as we haven’t created anything.

Open the Composed Looks list instance.

You can see here that it is creating each item that already exists in the site it was exported from.

Feature 2 – Modules

Now expand the Master Page Gallery. Even though the WSP appears to deploy all of the composed looks and themes, it only adds in our custom master page (but all associated html files for the other master pages).

Scroll on down to Modules and expand the _catalogsthemeThemedC7475956_. This appears to deploy a whole bunch of stuff that already exists in the theme gallery under Site Settings, Themes > themed > C7475956.

Feature Three – Property Bag

The third feature deploys items into the property bag of the site collection.

Open up the PropertyBags elements.xml file. I don’t know about you, but I’m slightly scared by not knowing what all this is! Surely I don’t need this just to deploy my one master page! Also there seems to be some propertys set with a base URL of the site I exported from, not sure if this is good.

Let’s try and import the design package into a different site…

Create either a new site collection, or web app. We will import our exported wsp and see how it goes.

1. Go to your new site collection and enable the site collection publishing feature.

2. Go to design manager and on the welcome page click on Import a complete design package

3. Browse to the location of the exported wsp/design package from earlier and click Import.

4. Here’s the nice new waiting screen…

5. Once the import is done. Have a look at the site collection features, your’l notice that there are no features like we saw in the design package so these must be hidden away somewhere.

6. If you go to the design manager and look at Edit Master Pages you will see the master page that was created earlier.

7. The good news is, nothing appeared to break! However, our example was pretty simple using only one custom masterpage. It would be interesting to see how well this works with full site customisation including the search components and any device channels.

Conclusion – What can we get out of this?

Design packages look like a great way of moving around customisations and allowing designers to use their own tools to directly change master pages and components in SharePoint. However, as a developer I wouldn’t feel comfortable deploying one of these packages to production, it seems to be bloated and include a lot of items that don’t need to be deployed just so that we can have a master page or a theme. What it would be useful for is a designer doing what they need to do to get SharePoint styled on a test site collection, once they are done they could export all of their work and send it to the developer. From here the developer could extract the theme, font, master page files and anything else required.

We still need to make a decision however about if a theme is needed or just a standard master page deployed like we are used to previously. I will go in to this in the next couple of posts.

I want to start putting together some branding stuff to deploy, so I need to create a solution and some base projects before I get started.

I have decided on the following projects to start off with

GISIT.SharePoint.Branding – Masterpage, css, images, page layouts, themeGISIT.SharePoint.PageComponents – Webparts (if we decide to add apps later we will need to add a different type of project specific to apps but I’m not sure on this yet)GISIT.SharePoint.Common – This will be a class library for constants or any common SharePoint functions. There are two ways this could be implemented, a class library or a sharepoint project. The difference between these is the class library needs to be added as a dll to the SharePoint package of any other projects (branding and page components wsp’s), whereas the WSP way would allow you to directly deploy and update the dll directly using the wsp built. If something needed to be only changed in the dll such as a constant value, we will have to to an update on either the branding or page components, which I am happy with at this stage.

1. Open Visual Studio

2. Create a new project.
Name it [Company].SharePoint.Branding
Select SharePoint 2013 Empty Project
Change the solution name to [Company].SharePoint

3. Click on the solution and add a new project

4. Select Class Library (or SharePoint 2013 Empty Project if you want to deploy this as a WSP)
Name it [Company].SharePoint.Common

5. Create another new project in the solution.
Select SharePoint 2013 Empty Project
Name it [Company].SharePoint.PageComponents

6. Right click the whole solution and select Rebuild

7. Add the common dll to the branding and page component projects. First go to the branding project and right click Reference. Click on Add Reference.

8. Click on Solution on the left hand side, then select [Company].SharePoint.Common. Click OK

9. Double click on the package for branding.

10. Click on the advanced tab

11. Click on Add, then Add Assembly from Project Output

12. Select [Company].SharePoint.Common then click OK

13. Save the package file and follow the same steps for the Page Components project.

14. The project is now ready for us to start adding content to. Starting with branding.

I created the main (and only) site collection with the team site template. Before I start looking into the new branding features I have to figure out what’s new in SharePoint 2013 and decide the best way of creating the master page and theme etc.

Firstly lets look at what we get when we use the Team Site Template

Themes don’t use office themes anymore but instead use two xml files with the extensions .spfont and .spcolor. These are then used in Composed looks.

Composed Looks are new to SharePoint 2013 and allow users to choose a masterpage, fonts, colors and a background image.

To create a new composed look, click on new item in the composed looks gallery. Here you can specify the links to your masterpage, spfont, spcolor and an image.

Composed looks can be applied by clicking on Change the look under Look and Feel in Site Settings.

Lets Activate the Publishing Features

Head to the Site Settings Page and firstly activate the publishing Site Collection Feature. Site Settings > Site Collection Administration > Site Collection Features > Activate SharePoint Server Publishing Infrastructure.

We have some additional items under Look and Feel now, Design Manager, Device Channels, Import Design Package and Navigation.

Device Channels

This allows you to define a different master-page for different devices. We won’t be implementing device channels, and there’s a couple of posts already that explain this in detail so I will link these

There is now an option to export design packages, what this includes is changes to the Master Page Gallery, Style Library, Theme Gallery, the Device Channels list and Page content types (msdn article on this). This is a WSP file of the branding components required (excluding pages, navigation settings, or the term store). This allows designers to export and import design packages without the use of Visual Studio. I will cover this a little more in the next post about implementing branding where I export out one of these packages to take a look at what’s in the WSP.

Navigation

Navigation looks the same other than the new managed metadata navigation. This allows users to define their navigation as a hierarchy in the term store. NOTEEEE this is ooonly useful if you want the navigation to be on one site, yes site, not site collection :(. I was quite looking forward to this, but maybe in future this will be available across at least a whole site collection. To read about setting this up go to this Nothing But SharePoint Post. Heres a link to an MSDN article that covers talking to the metadata navigation programatically http://msdn.microsoft.com/en-us/library/jj163978.aspx. I’d be very interested to see if someone will create custom navigation that programatically talks to the managed metadata navigation that is associated with the top site / main site collection making it cross site and site collection. Maybe one day….

Design Manager

Design manager allows users to manage page layouts, masterpages and the look and feel of the site by mapping the SharePoint files to a file location where they can edit them using Visual Studio, Notepad++, Dreamweaver or any other tool they prefer. The file a user will edit has commented out snippets of SharePoint Masterpage code that they can work around. SharePoint Brian has covered each of the areas of the design manager here.

Lets Activate the web’s Publishing Feature

Go the Site Features and activate SharePoint Server Publishing

This gives us a Pages library, changes the main URL and gives us more options in the Look and Feel menu.

Most of this is the same as it used to be. There is a new option in the Master page menu which allows you to use the css file associated with your master page (in the master page gallery you can set this on the master page item). All items set in here apply to all channels, so some sizing etc may need to be overwritten in the other device master pages CSS files.

The welcome page url will need to be changed to a page in the pages library. At this stage there isn’t any pages, so you will need to create a default page and point the welcome page url to there.

The site url will change from /_layouts/15/start.aspx#/SitePages/Home.aspx to /SitePages/Home.aspx.

What have we decided so far for our branding implementation?

From what I have played around with so far and read, I prefer the idea of creating my own solution for branding and not exporting anything (this seems cleaner and you will see why in my next post). This means the implementation will be very similar to SharePoint 2010, deploying a master page, images and css etc. The main difference being instead of setting the masterpage and css on the spweb object on activation I suspect we will have to insert a new list item into the composed looks list and then set a property on the web which tells it what composed look to use, OR it will be the same as it used to be… We will find out!

At this stage Visual Studio 2012 is released/RTM but the developer tools for Office and SharePoint are still in preview. The below instructions apply to the latest preview at the time of this post, which is preview 2. There will be screenshots soon anyway.

Install Visual Studio 2012. You can choose to include the Office developer tools, at this stage (I THINK) the SharePoint 2010 templates will be included but not the 2013 ones.

Using the Microsoft web platform installer (I’m not entirely sure if this is a must as I prefer to download and install directly instead of the platform thingy, but my brief googling didnt help find a direct link)Click here for the download link for the web platform installer/selection of current Office/SharePoint components needed, then click on DOWNLOAD THE TOOLS under TOOLS.This will select the components required and you can go ahead and install these. At the time of the post, I had to install Workflow Manager Tools for Visual Studio 2012 and Microsoft Office Developer Tools for Visual Studio 2012 – Preview 2

Once these are installed, open Visual Studio and you should have the templates under Visual C# > Office/SharePoint. The first time I installed these it wouldn’t work… turns out in another session I still had Visual Studio open deerrr, after I closed this the installation went fine.

Sites

Sites are easy to script, and having a small script to create these means when we upgrade to the full release of SharePoint I can just run the script again.

The sites that we will start out using are:

Root Web
It Support Site
Social/Fun Zone Site
Courses
— 2012
—— Course One
—— Course Two
— 2013
—— Course One
—— Course Two

This will change as we properly script the courses once we have a full list as well as have the template implemented. For now a few empty course sites will do for development.

Run up SharePoint 2013 Management Shell
You may get the below error, but this can be ignored as its a preview issue: This article here mentions thiscould not create a CmdletConfiguration for CmdletName Start-BulkOperation, CmldetClass , CmdletHelpFile C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\CONFIG\PowerShell\Help\Microsoft.Office.Education.Institution.dll-Help.xml.Cannot process argument because the value of argument “implementingType” is null. Change the value of argument “implementingType” to a non-null value.

Go to All Site Contents (slightly different to normal….) Click on the cogg icon then View Site Contents, this is on the RIGHT TOP OF THE PAGE by the way.

Now you will see your sites (scroll to the bottom past the “apps”). Done!

Content Types and Fields

I’ve always had issues deciding when to use features or scripted content types, or manual… They seem to fit into different situations, heres where I place them

Feature

When…

— The content type won’t change over time
— The content type name and id must stay the same everywhere (for custom functionality relying on this)
— No one wants to run a script or create content types manually
— The user doesnt need to delete the content type

Feature Drawbacks

— Users cant delete content types
— Next time the feature is updated it either wont change anything (particularly fields at a list level), or it will override everything the user has changed
— Users may need to change content types, this means that a developer may have to keep the solution/feature content types up to date. When this is implemented into the clients environment, it can be risky in terms of whether new fields etc will be added properly, particularly at list level. Extra code can be written for a proper upgrade of the feature, but this is a bit of overhead if it isn’t normal practice.

Pros?

— Easy one click deployment for the client depending where they want certain content types.
— Good for deploying content types that are hugely tied to functionality where the id’s and names, and even fields shouldn’t be changed. This also means the content type and fields are created on activation with the other relevant functionality.

Scripted

When…

— There aren’t a large amount of content types
— Content types will change heavily over time, so the user needs full control over them after implementation
— The content type may need to be deleted

Scripted Drawbacks

— Unless the client is using a content type hub, the script will need to be run against each site collection, and any new site collections in future. If the content types do change and there isnt a content type hub an admin or dev may have to keep this script up to date.

Pros?

— Usually deploy once, and from there on a client can fully manage their own content types with no feature restrictions
— Can be re-used accross environments and site collections during initial deployment

Manually Create

When…

— There aren’t many content types or fields on those content types
— There aren’t many site collections (if not using a content type hub)
— The id’s of the fields and content types don’t need to be the same, new content types and fields get a new GUID, so they would be different per site collection (if not using a content type hub)
— You don’t mind re-creating per environment (test, uat and prod)

Creating Drawbacks

— Obviously creating the same thing over and over can be time consuming
— Have to name everything the same and not make mistakes

Pros?

— If there aren’t very many content types, only 1 or 2 environments and not many site collections… this would be less time consuming

Mention of the Content Type Hub…

A Content Type Hub, or Metadata Hub allows users to create content types and fields in one place. They can then publish these fields and content types out to all of the other webs/site collections so there is no need to deal with them at every level. This can be great for documents that are scared across an intranet where there may be multiple team site collections and they all share common document content types for example.

What to do???

For a start, we know what we want for content types and there aren’t many, we don’t need a content type hub, we only have one environment with no plans for more. The easiest thing we can do for this implementation is manually create the content types and fields. One thing to keep in mind, if we did want more environments, it would be best to grab the details of the existing content types and fields and re-create those using a feature or script in other environments. The same would apply for any new site collections.

Its important to think about what we need for the solution to get started such as search requirements, content types, fields, sub sites etc. This will help out with development if we know what is required here, then I can add some test data in when I start developing.

Web Application

There will only be one managed path for search (/search). This will be an explicit path, so there can only be one site that the url /search goes to (instead of /search/mysearchsite if it was wildcard).

Site Collections

The data requirements are quite low as there will only be around 200 documents uploaded each year. Because of this we are only going to use one site collection for the main portal. The search center will have its own site collection and will be based on the enterprise seach site template.

Sites

Most of the content will be driven from the course sites which will be created each year.

Root Web
It Support Site
Social/Fun Zone Site
News
Courses
— 2012
—— Course One
—— Course Two
— 2013
—— Course One
—— Course Two

Templates

Course sites will have a template with content types and lists required already set up. This will save tutors time each year when they have to create new course sites that are the same as last year, the only difference is the documents. Documents can be easily uploaded by clicking and dragging them into a library, so this will be an easy task each year.

Page Layouts

I’m not sure at this stage what OOTB page layouts are provided with SharePoint 2013, but at this stage we would need two:

NOTE: Most of our fields are managed metadata, this will help students to search and refine documents based on course and type, and find discussion items easier with tags. In SharePoint 2010, search automatically set up refinements for managed metadata where the results included values for a specific field, so I am hoping this is the same if not better in 2013…

Content Types

There won’t be a lot of documents in this system, and the documents that are in the system will be for similar purposes such as a course document, or an assignment. Because of this we won’t have many content types, but will create a structure that can be expanded on in future. For documents, there is a base type called GISIT Base Document which is purely a placeholder. This will come in handy if the structure expanded significantly and another field was all of a sudden required across all documents. Instead of adding the field to all documents, we can just add it to the place holder.

Naming Decisions
– Discussions vs. forums. We decided to go with discussion instead of forum, this is mostly a preference thing but consistency is the key here (i had used the term forum and discussion in the designs which wont be reflected in the implementation).
– Course resource vs. course document. There are two main types of documents, documents that a tutor uploads that are purely course related, and documents that students upload which can be assignment based, class work based or group based. We decided to use Course resource for the tutor documents and course document for the students, this gives us a bit of flexibility and fields can be added later on to distinguish the different types if needed, or the content types could be extended downwards to more levels.

Lists – Top Level

Away Today (Calendar)
Course Events (Calendar)

Search

Search is going to be fairly simple as we dont have many content types at this stage. We have however identified a couple of scopes that could be useful for students searching content!

Scopes
— All Content [OOTB]
— Discussions
— Course Resources

We are hoping that the course discussion areas will be popular for students asking for help and sharing ideas. If these are tagged appropriately with subjects for certain types of issues or technologies an additional search option to search will be useful.

Permissions

Only I.T students can access the system. For group assignments a new sub site will be created under the course site. The tutor will have access to this as well as the members in the group, other students wont see each others group sites. Students that are in a course will have contribute rights to their course site so they can upload items into discussions and document libraries. At the top level of the site only administrators will edit content, this is the mostly the pages library and news list, the rest of the data is rollup data from elsewhere. We will know more about this as we get further into development.

________________________________

I will likely be changing this post as time goes on as there are usually changes in terms of fields or forgotten items. Also, i havent figured out all the managed metadata options for tags yet….