My (long overdue) SharePoint Conference 2014 wrap-up

So almost 4 months ago now I was lucky enough to attend SPC14 in Las Vegas. I was always intending to write a wrap up of my experiences but having committed to doing an internal presentation along the same lines, didn’t want to spoil the material before it ‘went to air’ so to speak. Long story short, that presentation didn’t happen until this month, hence this extremely delayed blog post. In the interest of preserving this experience (and probably only for my own benefit) I figured I’d still throw it up here, so here goes.

Given I delivered it in presentation form, i’ll write this post as I have some of my other presentations. The headings will match the slides, so click along for context.

 

Introduction

Over 40 hours on planes and in airports for a week in Vegas. Sounded like a fair trade at the time – turned out to be a bargain. Was totally worthwhile, would rate it right up there as a professional highlight (and right up there with some of the personal trips I’ve been on!) and would do it again in a heartbeat. Will hopefully get the chance to do it all again the next time around!

There was of course, Vegas being Vegas, a need for a disclaimer. Some of the stories would have been more suited to a chat over a beer at the pub rather than the office setting, so at the risk of being severely cliched.. Sometimes what happens in Vegas..

Networking

Looks like a bad case of name-dropping I must admit, but at the end of the day one of the most valuable aspects of these conferences is the networking. I was lucky enough to have been given the wise advice before I left – I asked my mentor what I should be focusing on for the week and without delay was told to speak to and meet as many people as I could. If you were to ask me now what the best part about the conference was it’d be exactly that – the people I met and the conversations I had with them.

The conversations at the time might not even be work or conference related – we met people on the first night over sushi, sake and mechanical bull riding that got 2 guys from Perth who knew almost no-one into private parties with CEOs and senior staff within Microsoft teams. We had discussions with people who I’ve since lent on for advice regarding problems I’ve faced on client sites. Connections with event organisers to discuss presenting opportunities for colleagues. Money-can’t-buy advice and insight from some of the best in the business. You get the idea. Worth the price of admission alone.

SharePoint TV and Hands-on labs

I thought it worthwhile to highlight some of the lesser known aspects of conferences for the uninitiated. SharePoint TV – the panel style interviews now available over on Channel9 – were a pretty cool concept I’d not seen before and the ones I decided to check out didn’t disappoint. Hands-on labs are another generally undervalued offering available. Unfortunately I didn’t find the time to do any at SPC, however I have done them before and rated them highly. There’s just too much to do at SPC it’s impossible to fit everything in!

The future of forms

I think something worth remembering with these types of events is that the sessions that get chosen and particularly heavily marketed are there for a reason – it’s always worthwhile taking notice of the messages being repeated in sessions to see where Microsoft is leading us. One of the major focuses of the event was along the lines of the future of forms. InfoPath has been the defacto standard for a while now however when the 2013 version of Office really offered no upgrades to the product the writing was kind of on the wall. The death of InfoPath was announced shortly before the conference so there was big hype around what the next direction would be.

To be honest this topic has been covered comprehensively in so many different places it’d be pointless for me to do the same – so if you’re interested in reading up I’d suggest checking out these posts here, here and here. However perhaps the most important messages to come out of this were the ones around continual improvement and the desire to listen to the community and take on board the feedback provided. This is actually a message which is being heavily pushed by Microsoft recently and in my opinion it’s a great thing.

The future of social

Another one of the golden topics throughout the week was the future of social – it’s probably been a big focus for a while now not just for the conference. There were a tonne of highly rated social sessions available. I didn’t delve too deeply into discussing this topic as a colleague of mine had presented on it a couple of months earlier. Long story short, it’s now blatantly obvious that Yammer is the way to go for social in SharePoint. The really cool innovations coming – some of which have already started making their way into Office 365 – are around embedding the social functionality throughout SharePoint and Office 365 which is something I highly recommend keeping abreast of, it really is becoming more and more powerful in terms of the immediate and contextual value it can deliver.

I guess just as important as the news delivered around social was the consistent messages being portrayed in the sessions. Microsoft obviously see the barriers to organisations harnessing these social technologies as organisational culture, adoption issues and a failure to extract or recognise the value they are delivering so almost any session highlighting what social could offer touched on these points as well – they’ve obviously invested a lot into acquiring Yammer and definitely believe in the value it can bring to organisations and thus making Office 365 an even more attractive offering.

Public facing sites / responsive design

Of course having a great interest in public facing sites I couldn’t help but keep an eye on what was being said during the conference about the topic. Funnily enough it actually wasn’t a great deal – I guess because it’s primarily the domain of on-premises installations. What was said focused a lot on mobility and responsive design, and trying to advertise the cloud for hosting public facing sites. The main messages I took here was that even with the device channel offering provided in SharePoint 2013, they really seem to be pushing the responsive design angle. Also, when it comes to public facing sites particularly if you are wanting to leverage the cloud, then hybrid is the way to go. Be that a hybrid solution between responsive design and adaptive design or hybrid around SharePoint Online and Azure websites.

The architecture and developer streams

Now this slide might seem a bit unbalanced but there’s good reason. The way I approached the conference and even how I approached the sessions I reviewed once I got back was to focus on an area I wanted to improve in and mix in topics that I thought I’d find really interesting or entertaining. At the end of the day I chose the architecture or IT pro stream given I’ve been more known as a developer for the majority of my SharePoint career. I think that’s an important lesson I took out of my experience across the week – at the end of the day there is going to be so much you want to see and learn and its simply impossible to do it all in that short amount of time. I feel I got more out of focusing my energies rather than spreading them across a range of topics but at the end of the day everyone will take a different approach when it comes to session selection.

On-prem v o365, the push to the cloud and the App Model

Another one of the beauties of conferences like SPC is that if you meet the right people at the right times (and that generally means after a few beers) you can often get some really interesting conversations happening! Obviously none of these conversations were going to see the light of day published on my blog, but what I will say is that my opinion on some of the more controversial topics I’ve expressed views on in the past (Why wouldn’t you use the App model for On-Premises SharePoint solutions?) have changed a little. Long story short – it’s happening, so either ride the wave or try and swim against it, choice is yours.

There was of course just as much within the carefully crafted message at the conference as there was in the hallway conversations. It’s becoming more and more obvious that Microsoft see the resistance of moving to the cloud as an IT battle and one they’re trying to win by shifting the perception of what IT should be. They’ve also almost given up on the desire to get everyone to the cloud ASAP and are being more realistic and pushing the virtues of staggered migrations and hybrid scenarios to get organisations used to the idea of using cloud technologies.

So many other great sessions

It goes without saying that there was a tonne of other quality content available throughout the week and there’s no way known I could have watched it all and spoken about it all in this presentation. Going through the sessions I noticed that Search was still positioned as a big ticket topic and there were numerous top rated sessions on that. Another concept that stood out was the user stories and case studies – a lot of these were really highly regarded too and it’s actually something I wish I dropped into a couple of sessions for and is still on my never ending catch up list.

Post Conference Training: Hybrid Scenarios with Office 365 and SharePoint 2013 Workshop

One thing worth mentioning about the conference are the pre and post conference training sessions that are made available to sign up for, most at an extra cost but a couple that were free. I signed myself up for the full day on Sunday and the half day that was available for the Thursday after all the sessions had finished. Overall I found it to be a bit of a mixed bag but that was largely of my own doing. Trying to step off the plane, into the pubs and then into a days’ worth of training was really never going to end well and it kind of showed in the value I got out of that day. That said, the post session I did was really impressive and the resources I got out of it are bound to be worth the price of admission alone. In future I’d probably more seriously assess the value I thought I’d get out of a session before signing up, given the time could have been spent networking for just as much value in some instances.

Ask the Experts

I know I flagged the networking as probably the most valuable part about the conference but if I had to choose a close second it’d definitely be the ask the experts session. This is something they have at Tech-Eds as well and I’ve always used as a chance to eat the free food and drink the free beer then kick on partying somewhere, but I decided to actually have a few chats that night and it turned out to be one of the best things I did. I was able to bring back all of the advice I got that night and use it at the client I was at which was extremely valued and appreciated. Highly recommend.

Conclusion

To wrap things up I thought I’d finish on a fun note. It may sound like the SharePoint conference was a non-stop learn-fest filled with early nights, early mornings and cramming as much information into ones head as possible but there’s definitely another side to it though and it’s a massive challenge trying to do it all on a few hours’ sleep a night. The parties were awesome though. I know of some people who avoid them but to be honest unless you already know a lot of people it’s the best way to meet the people you’ll have some of the best and unique conversations with. There’s something on every night, everything is free, the food and the drinks, and it’s hard not to kick on with new friends after each one and enjoy everything Vegas has to offer. I’ll finish up on that note with a nod and a wink and leave the rest of those stories for another time. Thanks for reading!

Responsive Web Design v Device Channels in SharePoint 2013

With the introduction of Device Channels in SharePoint 2013, and 2013 having been dubbed the ‘Year of Responsive Web Design’, the question is often posed which method is the right one to enable a mobile experience on your SharePoint-hosted public facing website.

This post will briefly explore what both options entail and run through some of the benefits and limitations of using either method. By the end you should be confident in choosing a road forward for your mobile-optimised implementation.

Responsive Web Design (RWD)

RWD at its core relies on grid layouts, media queries and CSS to alter the display of a web site based on the width of the browser accessing that site. Depending on the number of widths targeted via the queries, a web site’s display can be made to differ on large desktop screens, tablets and mobile devices so they render in an optimal fashion no matter the viewing platform.

The main benefit of RWD is that no matter what the device width, the site will display in its optimal (or nearest-to-optimal) form. Given the large number of device widths that already exist, and this likely to only exponentially grow in the future, the method can be considered largely future-proof.

The method is also search engine friendly. Search engines prefer a URL to always render the same HTML and utilising RWD achieves this.

RWD however does not come without its faults. Its biggest drawback is what enables that SEO-friendly approach – the fact that the HTML served is the same. This means that while images or sections may be hidden in the CSS, the resources will still be served to the device which is not an optimal approach when targeting low-bandwidth mobile devices. It also provides a less flexible approach to targeting a given device allowing less options for modifying the display.

On top of this, RWD can often be costly to implement in terms of the number of tweaks and regressions required when targeting different browser widths. Todd Baginski and Michael Sherman in their SharePoint Conference session SPC390 stated that they anecdotally noted that 25% of developer time was spent dealing with such requirements.

Device Channels

Device Channels in SharePoint 2013 rely on targeting the device accessing the page and serving up customised HTML based on the device which will be rendering the content. This ensures that you can provide a completely customised user experience depending on whether the user is on a desktop, tablet or phone. You could even go as far as serving up different content depending on the type of device (iPad, Surface, Android for instance).

This option therefore comes with a number of advantages. It negates the main drawback of the responsive designs – HTML can be served in a manner which completely optimises the page load for the device being targeted. A desktop version could be highly interactive and visual, serving large images where the mobile experience could be lightweight for improved performance.

It also offers far greater flexibility in terms of the designs you can render to the different devices. Rather than relying on the same HTML and grid-based flows, you have the opportunity to structure the HTML rendered in any manner you desire, providing the capability to have far more interactive experiences on the desktop compared to mobile devices.

The disadvantages of this approach again mirror the advantages of the responsive approach. As has been previously stated, search engines prefer the HTML being rendered at a given URL to be identical, however device channels serve up different content at the same URL for different devices.

There is also a limit to the number of devices which can be targeted, meaning the coverage of designs would be less compared to the potentially limited coverage of a responsive design.

Another drawback of the device channel approach is that it is even more limited when it comes to hosting public websites on Office 365. Only 2 device channels are available there, a default channel and a mobile ‘catch-all’ channel, meaning the flexibility to target different devices is reduced greatly.

For an example of how device channels can be used to implement a mobile site on SharePoint, view my previous post How my latest mobile-optimised site was built using SharePoint 2013.

Which is the best option for you?

As should be becoming clearer, there is no ‘best practice’ approach when it comes to making the decision between responsive designs and device channels in SharePoint 2013. There are advantages and disadvantages to both and a number of other factors may end up affecting the decision.

If you’re dealing with a design company to provide the site design, particularly if this process happens before the SharePoint team gets involved, the decision may be made for you. It is common for design companies to provide completely different HTML templates for standard sites and mobile-optimised sites and that immediately lends itself towards device channels. It could also be more cost effective to receive one responsive design from a design company rather than multiple device-targeted designs which could also impact the decision.

If you’re dealing with a team that will be responsible for both the design and implementation, then the decision may come down to the flexibility required for the site design and weighing up the approaches outlined above to choose the one that best suits the goals of the site.

The Hybrid Approach – a better way forward

There is an option available which provides the best of both worlds and is particularly appropriate when hosting public sites on Office 365 – the hybrid approach. This involves utilising device channels to target particular devices, but ensuring the designs within them (or at least some of the smaller devices) are responsive for the different browser widths which may be encountered. It may not be the most cost-effective approach available however it would definitely be the most effective from a user experience point of view.

 

Note – As this post was written in a very different manner to my usual blogging style, I failed to properly work in the references I had read in researching this topic into the post itself. As such, i’ve included them below for prosperity:

Device channels v/s Responsive web design by Prashanth BS

Responsive Web Design vs. Device Channels by Jean Paul

Responsive vs. Adaptive Web Design – What about Device Channels? by Stefan Bauer

Digital Design Shift: From Mobile to Multichannel by SiteCore (must register)

Harnessing SignalR in SharePoint 2013 (Office 365)

Over a year ago I wrote a post on Harnessing SignalR in SharePoint. Back then, SignalR was fairly new and the amount of information out there was limited. Getting SignalR to work with SharePoint posed some challenges, all of which are outlined in that post, however eventually we got it working. Since then I’ve had little to do with the technology however the colleague I worked with on that proof of concept, Elliot Wood, has continued to keep on top of the changes to the library and the implications that may have for SharePoint integration. While i’m posting this to my blog, i’m doing so on behalf of Elliot who is responsible for all of the magic soon to be displayed.

Even though there was a fair amount of excitement in regards to SignalR, and particularly the work we did around getting it working in SharePoint, the number of subsequent posts along the same lines was fairly limited. One person who carried the torch was Maximilian Melcher – his post SignalR in SharePoint 2013 – the real-time web is coming! outlined that integrating SignalR in SharePoint 2013 wasn’t as easy as one might expect – even though we were now on the .NET 4.0 framework which should have made life much easier. Max ended up getting his solution working and subsequently posted a codeplex solution, however the post was enough to pose the challenge to Elliot to get it working as easily as possible.

The solution presented uses an autohosted App for SharePoint 2013 hosted on Office 365. With Microsoft’s direction seemingly steering away from full-trust and sandboxed solutions and straight towards the App model, this can be considered the most viable and future-proof solution to the ‘SharePointR’ dream.

To ensure the focus of this post remains focussed on integrating SignalR with SharePoint i’m going to avoid the specifics about SignalR and how to program with it. I’m also going to avoid specifics on how to create and deploy SharePoint Apps. We’ve come a long way with SignalR and the information out there is much better – I’d recommend reading ASP.NET SignalR Hubs API Guide – Server (C#) if you need an overview of programming with SignalR. For those that need a primer on SharePoint Apps, particularly in relation to provider-hosted Apps on Office 365 (the more ‘production-safe’ way of hosting Apps on Office 365), then head over to Chris O’Brien’s post Deploying SP2013 provider-hosted apps/Remote Event Receivers to Azure Websites (for Office 365 apps) for a quick read.

Now that you’re comfortable with the theory, it’s on to the solution. There are 2 pieces to the autohosted App puzzle – the SharePoint App and the SharePoint App Web.

SharePoint App

The purpose of this project is to define the Remote Event Receiver (RER) and also configure the Installed Event Endpoint for the App. The former essentially sets the types of events that will trigger the remote service and points the App to that service, the latter points to the service which will trigger when the App is installed.

Adding the RER is as simple as right-clicking the project and adding a new Remote Event Receiver and selecting the events you want to listen out for. Everything else will be taken care of for you including creating the Package, Feature and tying the RER to its class which will be hosted in the SharePoint App Web.

Configuring the Installed Event Endpoint requires you to edit the properties of the SharePoint App project and set the Handle App Installed property to true. Once again Visual Studio takes care of the rest.

The final step is to access the Permissions tab in the AppManifest.xml editor and add the necessary permissions to the Web and List to ensure your App has the required levels of access to your site.

That’s all there is to it.

SharePoint App Web

Setting up the SharePoint App Web project is a little more involved than the above however is still relatively simple. The first step is to add a SignalR Hub Class to the project – having this native in Visual Studio is fantastic and greatly simplifies the process of getting up and running with SignalR ensuring all necessary references are added to the solution (note that you must have installed the ASP.NET and Web Tools 2012.2 update before you can add this class natively). Alternatively you can add SignalR via the Package Manager Console.

Elliot has also decided to implement the hub using a Singleton instance for optimum performance. For this you’ll need to add another class and insert the following code:

    public class SharePointR
    {
        // Singleton instance
        private readonly static Lazy<SharePointR> _instance = new Lazy<SharePointR>(() =>
            new SharePointR(GlobalHost.ConnectionManager.GetHubContext<SharePointRHub>().Clients));

        public SharePointR(IHubConnectionContext clients)
        {
            Clients = clients;
        }

        public static SharePointR Instance
        {
            get
            {
                return _instance.Value;
            }
        }

        private IHubConnectionContext Clients
        {
            get;
            set;
        }

        public void NotifyDataChanged(string ListName, string Event)
        {
            Clients.Group(ListName).dataChanged(Event);
        }
    }

Once that’s been created we can edit the Hub we added earlier and insert:

    [HubName("SharePointRHub")]
    public class SharePointRHub : Hub
    {
        private readonly SharePointR _sharePointR;

        public SharePointRHub() : this(SharePointR.Instance) { }

        public SharePointRHub(SharePointR sharePointR)
        {
            _sharePointR = sharePointR;
        }

        public void Subscribe(string ListName)
        {
            Groups.Add(Context.ConnectionId, ListName);
        }

        public void UnSubscribe(string ListName)
        {
            Groups.Remove(Context.ConnectionId, ListName);
        }

        public void NotifyDataChanged(string ListName, string Event)
        {
            _sharePointR.NotifyDataChanged(ListName, Event);
        }
    }

One final piece to the SignalR puzzle is to add a Global.asax file which should include the following:

        protected void Application_Start(object sender, EventArgs e)
        {
            var hubConfiguration = new HubConfiguration();
            hubConfiguration.EnableCrossDomain = true;
            hubConfiguration.EnableDetailedErrors = true;
            RouteTable.Routes.MapHubs("/signalr", hubConfiguration);
        }

Now we have our SignalR plumbing we can set up our event receivers. The first cab off the rank is the AppEventReceiver which will fire when the App is installed. What we want to achieve here is to manually hook up the item event receivers to a list in the host web, for instance an Announcements list.

    public class AppEventReceiver : IRemoteEventService
    {
        private string ReceiverName = "RemoteEventReceiver";
        private List<EventReceiverType> EventType = new List<EventReceiverType>()
        {
            EventReceiverType.ItemAdded,
            EventReceiverType.ItemAdding,
            EventReceiverType.ItemUpdated,
            EventReceiverType.ItemUpdating,
            EventReceiverType.ItemDeleted,
            EventReceiverType.ItemDeleting
        };
        private string ListTitle = "Announcements";

        public SPRemoteEventResult ProcessEvent(SPRemoteEventProperties properties)
        {
            SPRemoteEventResult result = new SPRemoteEventResult();

            using (ClientContext clientContext = TokenHelper.CreateAppEventClientContext(properties, false))
            {
                Web hostWeb = clientContext.Web;
                clientContext.Load(hostWeb);

                List docLib = clientContext.Web.Lists.GetByTitle(ListTitle);

                string opContext = OperationContext.Current.Channel.LocalAddress.Uri.AbsoluteUri.Substring(0,
                   OperationContext.Current.Channel.LocalAddress.Uri.AbsoluteUri.LastIndexOf("/"));
                string remoteUrl = string.Format("{0}/RemoteEventReceiver.svc", opContext);

                if (properties.EventType == SPRemoteEventType.AppInstalled)
                {
                    foreach (var eventType in EventType)
                    {
                        EventReceiverDefinitionCreationInformation newEventReceiver = new EventReceiverDefinitionCreationInformation()
                        {
                            EventType = eventType,
                            ReceiverAssembly = Assembly.GetExecutingAssembly().FullName,
                            ReceiverClass = "SignalRProxyService.Services.RemoteEventReceiver",
                            ReceiverName = ReceiverName + eventType.ToString(),
                            ReceiverUrl = remoteUrl,
                            SequenceNumber = 1000
                        };
                        docLib.EventReceivers.Add(newEventReceiver);
                    }
                    clientContext.ExecuteQuery();
                }
                else if (properties.EventType == SPRemoteEventType.AppUninstalling)
                {
                    IEnumerable<EventReceiverDefinition> receivers = clientContext.LoadQuery(docLib.EventReceivers
                        .Where(e => e.ReceiverName == ReceiverName));

                    foreach (var rec in receivers)
                    {
                        rec.DeleteObject();
                    }
                    clientContext.ExecuteQuery();
                }
            }
            return result;
        }

        public void ProcessOneWayEvent(SPRemoteEventProperties properties)
        {
            // This method is not used by app events
        }
    }

We then want to code up the Remote Event Receiver to handle the events triggered on the site and push a message via SignalR to our page. This is a very simplistic example that shows that the item affected in the list we’ve subscribed to is what is causing the update on the page.

    public class RemoteEventReceiver : IRemoteEventService
    {
        private SharePointRHub client = new SharePointRHub();

        public SPRemoteEventResult ProcessEvent(SPRemoteEventProperties properties)
        {
            client.NotifyDataChanged(properties.ItemEventProperties.ListTitle, properties.EventType.ToString());
            return new SPRemoteEventResult();;
        }

        public void ProcessOneWayEvent(SPRemoteEventProperties properties)
        {
        }
    }

The final step is to code up the page. There are a number of aspects here which should be completed to get the branding right for the App – these are covered in greater detail in the how-to guide listed at the end of this post. For now i’ll highlight the main code needed to hook up SignalR on the page (note that references to scripts not yet mentioned in this post are also covered in that guide).

    <!--Script references. -->
    <script src="//ajax.aspnetcdn.com/ajax/4.0/1/MicrosoftAjax.js"></script>
    <script src="/Scripts/jquery-1.8.2.min.js"></script>
    <script src="/Scripts/json2.js"></script>
    <script src="/Scripts/chromeLoader.js"></script>
    <script src="/Scripts/jquery.signalR-1.0.0.js"></script>
    <script src="/signalr/hubs"></script>

    <!--Add script to update the page and send messages.-->
    <script type="text/javascript">
        $(function () {
            var connection = $.hubConnection();
            proxy = connection.createHubProxy('SharePointRHub')
            proxy.on('dataChanged', function (eventType) {
                $('#MainContent').append('<li>Data changed - ' + eventType + '</li>');
            });
            connection.start()
                .done(function () {
                    //Subscribe to Announcements list
                    proxy.invoke('Subscribe', "Announcements");
                    $('#MainContent').append('<span>Now connected, connection ID=' + connection.id + '</span>');
                })
                .fail(function () {
                    $('#MainContent').append('<span>Could not Connect!</span>');
                });
        });
    </script>

And that’s about it! The image below gives a sneak peak into how an event triggered via a SharePoint list can be reflected on a separate page in real time. It is far more impressive however seeing it in person, so I’d encourage you to follow the guide provided below and get ‘SharePointR’ up and running for yourself – the possibilities this technology opens up is limitless and it will be exciting to see the kinds of solutions designed which leverage SignalR within SharePoint in the near future.

PreviewDownload: Walkthrough-Deploying a SignalR autohosted App to Office 365