Use the contact form if you have any questions relating to new web or SharePoint projects, branding, design, consultancy, photography or just fancy asking me something else.
Otherwise, enjoy browsing the site and feel free to comment on any of my work or blog posts.
Custom branding in SharePoint should not start and end with master pages, layouts and style sheets or making things look “pretty”. Anything that is customised should retain some level of branding consistency and the next two blog posts will explain what I mean.
Branding should encompass text as well as visual imagery. This can be website, or intranet content, but also administrative text such as titles and descriptions. Custom code should be relevant and on brand for all users, administrators, editors, contributors not just the end user. Branding, design and code should co-exist in harmony.
When creating custom code for a SharePoint project within Visual Studio you will use a feature to deploy the required code as a farm or sandboxed solution. The Main focus of this in development is to ensure the requirements are met and functionality is delivered and working as expected.
However, it shouldn’t stop there. Within the project feature you have the option to both name and describe the feature using a title and description. You may know what your custom code does, but what about the client or those who will later come to support these features? Ensure that you provide a useful name, title and a descriptive sentence or two about what the feature is deploying and how it is used. DO NOT just leave it as the default Feature1.feature, this is just down right lazy.
To apply a name, title and description do the following within Visual Studio:
When deploying features it is also possible to assign a feature image. This not only distinguishes the custom features developed by you but also strengthens the brand and highlights the functionality you should be proud of developing.
To apply an image to a feature do the following in your Visual Studio project (you only needs this once if using multiple projects):
Now each time a feature is deployed there will not only be a good naming convention but also a consistent set of branded features.
You are on the right track to having not only happy clients but a proud development team and a happy support team!
Part 2 of this topic will cover custom web parts, lists, libraries, content types and columns from a branding perspective.
You must be logged in to post a comment.
Recent blog comments