Category Archives: Elumenotion

Doug Ware’s SharePoint posts from the original Elumenotion blog.

SharePoint Wiki Page with Web Parts Pattern for Custom UI

In my previous post I used a scoring system to come up with an answer to the question: What is the most ideal type of page to use when customizing SharePoint? Somewhat surprisingly, the answer based on my criteria is a SharePoint Wiki Page. A wiki page which has the advantage because all wiki pages are served from a shared template instead of being actual files. Creating a wiki page doesn’t create a custom ASPX page that requires maintenance. By relying on the central template, the structure and features of a wiki page stays up to date as SharePoint evolves.

In this post I will cover one of the patterns for custom UI based on wiki pages we use in our apps here at InstantQuick: Wiki Page with Web Parts. This pattern is best if we want to allow the owners of the target site to modify the solution after it is deployed. It does not require a provider host and works when an add-in is fully contained in SharePoint. You can see this design pattern in action in the IQParts – Cloud App Compatible Web Parts using AngularJS and Bootstrap sample framework.

Wiki Page with Web Parts Pattern

This pattern is the easiest to follow because you can implement it using nothing but SharePoint and a text editor like notepad. The pattern consists of a wiki page, the default page type in a Team site, and one or more Content Editor or Page Viewer Web Parts that load the custom solution. Logically, the pattern looks like this:

The pattern is simple, but one important rule is that a customization’s appearance and behavior should depend only on the scripts, style sheets, and other resources included in the customization – not on the parent document’s or its related resources. Following this rule gives your customization the best chance for a maintenance free future as the SharePoint platform evolves.

The easiest way to enforce this rule is to refine the pattern to contain the customization in an iframe.

The iframe creates a new document that allows the customization to work in isolation from the parent document. In this version of the pattern the app must be contained in an ASPX page. The default permissive file handling settings will cause the browser to download html files instead of rendering the html in a frame. The file extension prevents the download.

The container ASPX used in in the IQParts – Cloud App Compatible Web Parts using AngularJS and Bootstrap sample framework is shown below. As you can see it does not contain any actual server side code.

What is the most ideal type of page to use when customizing SharePoint?

Very few platforms offer the range of customization options that SharePoint offers. The menu is huge! How does one go about the task of choosing the most ideal way to do anything?

In this post I am going to tackle one of the most fundamental choices everyone faces – What is the best way to make a custom web page for a SharePoint customization?

For this contest I am including only options that do not require third-party solutions and that work on-premises and in SharePoint Online.

The Contestants

The nominees for the best way to make a custom SharePoint web page are:

  • Custom SharePoint ASPX Page
  • External / Provider Hosted UI
  • Publishing Page
  • SharePoint App-in Web Hosted UI
  • Traditional SharePoint Web Part Page
  • SharePoint Wiki Page

Evaluation Criteria

Not long ago I wrote a post describing 8 Characteristics of an Ideal SharePoint Customization. I will judge each of the options based on these ideals, but to be as objective as possible pretend that each option meets the first and last ideals: It meets the needs of the people who use it without limitations imposed by the platform and It is manageable and governable.

In other words, I will try to do this without introducing hypothetical requirements or assuming anything about the ability of an organization to support and maintain the solution. This will let me answer the question of the most ideal option in general.

In real life, with real requirements and real people, you should always evaluate whether each option meets the needs of the people who use it without limitations imposed by the platform and if you can manage and govern the result. Sometimes the actual requirements will determine or limit your options. For example, if you are building a site using SharePoint’s publishing features, you will use Publishing Pages.

Finally, because this is specifically about pages the ideal, Runtime or configuration faults in a customization can only impact the customization, generally doesn’t apply; we use different tools to break whole sites.

That leaves five remaining ideals we can use to weigh the options.

  1. It doesn’t interfere with the operation of the underlying platform
  2. It uses SharePoint functionality as much as possible
  3. It depends on things other than SharePoint as little as possible
  4. It cedes runtime control to SharePoint as little as possible
  5. The other things it depends on are provided via supported mechanisms other than directly editing SharePoint Master Pages or ASP.NET files

Scoring

Here is a place where my ideals could use some refining, because ‘as little as possible’ is subjective. However, I am comparing each option to each ideal and saying ‘true’ or ‘false’ without giving partial credit. The one with the most true’s wins the prize.

Summary

 

A

B

C

D

E

Custom SharePoint ASPX Page

 

X

X

   

External / Provider Hosted UI

X

   

X

X

Publishing Page

 

X

X

   

SharePoint App-in Web Hosted UI

   

X

   

Traditional SharePoint Web Part Page

 

X

X

   

SharePoint Wiki Page

X

X

X

 

X

 

Custom SharePoint ASPX Page

Custom SharePoint ASPX pages are often created by modifying a Web Part page in SharePoint Designer.

Ideal Aspects

  • It uses SharePoint functionality as much as possible
  • It depends on things other than SharePoint as little as possible

Non-ideal Aspects

  • It interferes with the operation of the underlying platform
  • It relies on SharePoint for runtime behavior
  • It is a direct edit to an ASP.NET file

The way a custom ASPX page interferes with the underlying platform is by creating a custom page that is subject to safe mode parsing and be compiled. As a unique object it will diverge from non-customized pages over time.

External / Provider Hosted UI

External / Provider Hosted UI serves the user interface from a provider outside of SharePoint. The custom UI consumes SharePoint services via one or more client API’s.

Ideal Aspects

  • It doesn’t interfere with the operation of the underlying platform
  • It cedes runtime control to SharePoint as little as possible
  • The other things it depends on are provided via supported mechanisms other than directly editing SharePoint Master Pages or ASP.NET files

Non-ideal Aspects

  • Typically recreates functionality that could be provide by SharePoint
  • It is completely dependent on the external host

Publishing Page and Traditional SharePoint Web Part Page

These types of pages are examples of Custom SharePoint ASPX Pages and are ideal and non-ideal in the same says for the same reasons. Publishing Pages typically rely on custom master pages and page layouts. Client API’s create traditional SharePoint web part pages by copying the ASPX from an out-of-box page into a new file.

SharePoint App-in Web Hosted UI

SharePoint App-in Web Hosted UI is hosted in a special web in a domain outside of the containing site’s domain.

Ideal Aspects

  • It depends on things other than SharePoint as little as possible

Non-ideal Aspects

  • It interferes with the operation of the underlying platform
  • Typically recreates functionality that could be provide by SharePoint
  • It relies on SharePoint for runtime behavior
  • It is a direct edit to an ASP.NET file

Pages in SharePoint App-in Webs are Custom SharePoint ASPX Pages with less access to SharePoint functionality than the other types of custom pages in this competition.

SharePoint Wiki Page

SharePoint Wiki Pages are superficially similar to traditional SharePoint Web Part pages with one important difference – they are not custom ASPX pages. A wiki page is served from a shared template that changes over time.

Ideal Aspects

  • It doesn’t interfere with the operation of the underlying platform
  • It uses SharePoint functionality as much as possible
  • It depends on things other than SharePoint as little as possible
  • The other things it depends on are provided via supported mechanisms other than directly editing SharePoint Master Pages or ASP.NET files

Non-ideal Aspects

  • It relies on SharePoint for runtime behavior

The Winner!

In general, a SharePoint Wiki Page is the best type of page to use when customizing SharePoint. You can see one of our preferred design patterns in action in the IQParts – Cloud App Compatible Web Parts using AngularJS and Bootstrap sample framework. I will be covering our favorite design patterns and how they are constructed in a future post.

–Doug Ware

Atlanta Cloud Saturday – September 26th, 2015

Please join us at the Microsoft Greater Southeast District office in Alpharetta, GA on September 26 for the first annual Atlanta Cloud Saturday!

The goal of this event is to give you an overview of some of the cloud technologies being used today. Topics include Amazon Web Services, Azure, Office 365, Salesforce, IBM, DevOps, and more. Check out the great list of speakers and sessions (http://atlanta.cloudsaturday.com/sessions/) and be sure to register soon (https://www.eventbrite.com/e/cloud-saturday-atlanta-2015-registration-18034390347).

I hope to see you there!

Architects: SharePoint is a Platform, Treating it as only a Service is a Mistake

Last week my friend Andrew Connell wrote a rather provocative post titled Developers: SharePoint isn’t a Platform, SharePoint is a Service. In it he makes some persuasive points and advises people to move their front end development out of SharePoint. In this post I’d like to deconstruct a few of his points and explain why I think his advice in this regard is not very good.

The Past Product Engineering Failures at Microsoft Happened

A large portion of his post concerns the undeniable fact that Microsoft has offered a series of customization models for SharePoint over the years with varying degrees of success. I agree with just about everything in this section.

There has been a series of models from the SharePoint team, and, in some respects, Microsoft has shown a shocking lack of integrity as a vendor and business partner in the way they cavalierly advised customers to do things certain ways only to later say ‘whoops! We changed our minds’. Taken from a certain angle it’s almost unforgiveable.

On the Other Hand

I think everyone can agree that web technologies changed greatly between the births of 2003 and 2013. Office 365 was impossible in 2003 simply based internet speeds. Over the span of a decade, the medium (web) changed quickly and often in surprising ways. To that, add Microsoft’s adventures in rich internet applications (Silverlight) and the emergence of cloud technologies enabled by practically ubiquitous and fast internet connections. Is it surprising that Microsoft has tried to change SharePoint development to account for these things? Is it surprising that some of these were failures?

Just the same, it is possible to migrate solutions originally created for SharePoint Server 2003 to SharePoint Server 2016. Some migrate with little effort and sometimes it is so hard that it isn’t worth it. However, consider that the vast majority of other Web platforms you could buy in 2003 no longer exist as actively developed products. Then, ask yourself: how many of them allow you to take what you did in 2003 and move it with zero effort to their current version? Do you have anything in your current Web development stack that worked in 2003? Are there any that didn’t have some disruptive breaking change between then and now?

Getting $5 of Value from your $10 Purchase

A simple truth in software development is that the less a piece of software depends on other software, the better. This is always offset by the fact that depending on other software makes it faster and cheaper to build systems. Paradoxically the development experience can be much more pleasant even if it takes longer because as a developer you get much more freedom and you don’t have to deal with the quirks or restrictions imposed by the makers of the platform.

Naturally, faster and cheaper pretty much always wins. The users of the software still expect ‘better’, but it is a ‘better’ from their perspective: better at helping themselves do what they want to do. They don’t care how it gets built.

Deliberately tying a solution to a platform makes sense when you can trust the platform to stick around long enough and when the costs of depending on the platform are offset by a sufficiently positive return on investment over the life of the solution. One of those costs is that the implementer will often be more expensive than a generalist because they have to not only understand the set of development technologies and the customer’s requirements, but also understand the design and uses of the platform. In exchange it is expected that the implementers will leverage the platform well enough that the cost of the implementation will still be lower than building a custom solution. If not, it should be true that the total cost of ownership of the system over its life will be lower by using the platform than if it was custom.

If neither of these turns out to be true then the project is a failure on a certain level.

A model where SharePoint becomes a service to custom standalone systems significantly changes SharePoint’s value proposition because it is a deliberate decision to assume the dependency on SharePoint and all of its costs while simultaneously rejecting a big chunk of the features that you can use to offset the costs of ownership. Presumably your solution will still need things, like a user interface, that you could have gotten mostly or even completely from the platform. Perhaps a less expensive web developer could build those for you, but no matter what the hourly rate is, you still built something to use in place of something for which you’ve already paid.

This is a Design Problem

One thing Andrew and I agree on is that a good customization should be as isolated as possible and that a good design should actively address this concern. I think there are times when it is appropriate to treat SharePoint as a service. IQApp Central is a standalone provider hosted solution. It exists outside of SharePoint because we thought the design was most appropriate. On the other hand, add-ins like Instant Practice Manager, the Board of Directors Site, and IQApp Parts are integrated into SharePoint sites and fully integrate the platform. The previous few posts touch on how we isolate AngularJS and Boostrap in IQApp Parts so check those out if you are interested. Keep in mind that this is by no means the only possible way to isolate integrated functionality.

A Note on Patterns and Practices

Andrew says that he thinks Office 365 Dev Patterns and Practices is an example of trying to have your cake and eat it too. I say that it is actually the first time the SharePoint team has made an effort to directly engage and meet customers’ needs with regards to real world scenarios in quite some time. I dare also say that had the program existed the sandbox model would have never been born and the initial forms of the cloud app model would probably have looked very different from what we actually got from Microsoft. I recommend that you check out this post from Vesa Juvonen and decide for yourself if they are serious or not.

This is also a Trust Issue

At the end of day this is also a trust issue. Do you trust Microsoft not to make changes that cost you time and money if you integrate with their platforms?

You shouldn’t! I can guarantee that they will do things to make your life harder at some point in the future.

The same is true of any vendor that offers platforms with a long life span. It doesn’t matter how big they are. Times change and software has to evolve. Sometimes they will make a hash of it. Sometimes the vendor will screw up so badly it will even kill the platform.

If you trust Microsoft to avoid wrecking the bus, then acknowledge the potential bumps in the road and exercise defensive design, but wring every last dollar of benefit you can get out of the platform in the meantime. Moving everything outside the platform is not the way to do it.

If you don’t trust Microsoft to avoid wrecking the bus, that’s OK too, but move on. You are building custom solutions. Surely you can do better and more cheaply than SharePoint as a data and file storage service!

–Doug Ware

Using the SharePoint Client Object Model in AngularJS Apps

A common problem for SharePoint developers new to AngularJS is using the client object model within the context of AngularJS scopes.

The Problem Explained…

If you already understand AngularJS, feel free to skip this part!

Consider a controller that displays the name of the current user.

<div ng-controller="IQAppPart">
  <div ng-if="!!UserName">
     <h1>Hello <span ng-bind="UserName"></span></h1>
  </div>
 </div>
 

If the $scope variable of the IQAppPart has a value for UserName the greeting appears.

The IQAppPart controller function looks like this:

var iqAppPartModule = angular.module(‘iqAppPartModule’, []);
var iqAppPartController = iqAppPartController || {};
iqAppPartController.IQAppPart = function ($scope) {
//Make a request for the user
var ctx = SP.ClientContext.get_current();
var user = ctx.get_web().get_currentUser();
ctx.load(user);

//Send the request to SharePoint
ctx.executeQueryAsync(function () {
    //Set the UserName
    $scope.UserName = user.get_title();
  }, function (error) {
    alert(error.get_message());
  });
};
iqAppPartModule.controller(‘IQAppPart’, [‘$scope’, iqAppPartController.IQAppPart]);

Notice the highlighted line. This sets UserName and you might expect that this would in turn cause AngularJS’s magic data binding to display the greeting, but instead nothing would happen.

The code will run without error and retrieve the UserName, but that’s all. The greeting will not display. The reason for this is hard to see if you are new to AngularJS because the code sets the $scope and the line that does it is inside the controller function!

To understand the problem you must first realize that the call to SharePoint, executeQueryAsync, calls the success handler when it receives the result from SharePoint. The function call is an asynchronous operation that AngularJS knows nothing about.

The second thing you need to understand is that Angular’s model binding expects all operations of interest to start within the confines of an Angular process. When a page that is using Angular starts an Angular app via the presence of the ng-app directive on an HTML element or by calling angular.bootstrap(element), Angular starts listening for events specified element (with the attribute or passed to the bootstrap function) and all of the element’s descendants. So, it knows about clicks and other events. Whenever one happens, it reevaluates the model and then updates the HTML view.

Adding a call to $apply() as shown below fixes the problem. The call to $scope.$apply() tells Angular that something has changed and that it should do its work.

var iqAppPartModule = angular.module('iqAppPartModule', []);
var iqAppPartController = iqAppPartController || {};
iqAppPartController.IQAppPart = function ($scope) {
 //Make a request for the user
 var ctx = SP.ClientContext.get_current();
 var user = ctx.get_web().get_currentUser();
 ctx.load(user);
 //Send the request to SharePoint
 ctx.executeQueryAsync(function () {
   //Set the UserName
   $scope.UserName = user.get_title();
   $scope.$apply();
  }, function (error) {
   alert(error.get_message());
  });
};
iqAppPartModule.controller('IQAppPart', ['$scope', iqAppPartController.IQAppPart]);
 

Calling $apply() in the context of a controller is a big sign that you are doing it wrong!

Instead we need a mechanism that makes ClientContext.executeQueryAsync() work like any other service in AngularJS so that Angular will know when it is time to reevaluate the models and update the views.

The Solution

The solution is a service factory that wraps executeQueryAsync using Angular’s $q
service. $q is a service that helps you run functions asynchronously, and use their return values (or exceptions) when they are done processing.

//Angular service Wrapper for ClientContext executeQuery.
//The $q service makes it easy to wrap SharePoint's context.executeQueryAsync for use with Angular
var module = angular.module('iqPart', [])
 .factory('SharePointService', ['$q', function ($q) {
   var SharePointService = {};
   SharePointService.executeQuery = function (context) {
     var deferred = $q.defer();
     context.executeQueryAsync(deferred.resolve, function (o, args) {
       deferred.reject(args);
     });
     return deferred.promise;
  };
  return SharePointService;
}]);

To use the SharePointService we inject it into the controller and use it instead of ctx.executeQueryAsync as follows.

var iqAppPartModule = angular.module('iqAppPartModule', []);
var iqAppPartController = iqAppPartController || {};

iqAppPartController.IQAppPart = function ($scope, sharePointService) {
  //Make a request for the user
  var ctx = SP.ClientContext.get_current();
  var user = ctx.get_web().get_currentUser();
  ctx.load(user);
 sharePointService.executeQuery(ctx)
   .then(function () {
     $scope.UserName = user.get_title();
   },
   function (error) {
     alert(error.get_message());
 });
};
iqAppPartModule.controller('IQAppPart', ['$scope', 'SharePointService', iqAppPartController.IQAppPart]);
 

The end result is something like:

–Doug Ware

IQParts – Cloud App Compatible Web Parts using AngularJS and Bootstrap

We are in the process of releasing three free SharePoint Add-ins from IQApp Central: Absence and Vacation Request Management Site, Board of Directors Site, and AngularJS 1.4 and Bootstrap 3.3 Web Parts. We’ll release all three as side-loaded apps over the next couple weeks for host webs and the first two as SharePoint hosted apps will be available via the Office store. Until then, you can get all three using Free SharePoint Add-Ins page in IQApp Central.

Today I am pleased to introduce AngularJS 1.4 and Bootstrap 3.3 Web Parts. This is a sample created using IQApp Central​. It is a framework that allows for user configurable Web Parts built using SharePopint, AngularJS 1.4 and Bootstrap 3​. ​This sample contains two Web Parts, six sample apps, an extensible configuration system, a template to help you get started with your own apps, and some handy functions to make integrating with SharePoint pages and services easy.

This sample started as an exercise to attempt an ideal design based on the 8 Characteristics of an Ideal SharePoint Customization. Integrating AngularJS and Bootstrap with SharePoint while trying to maximize the 8 ideals is a great challenge because SharePoint and AngularJS are both very assertive, demanding frameworks that want total control over a page and Bootstrap wants to completely own the base styles.

For example, here is a SharePoint page.

And here is the same page with Bootstrap 3’s CSS loaded.

Most projects that use Bootstrap start with a custom master page and end with a complete theme. Naturally this is not an option when you are creating components that, like Web Parts, are expected to work on any site.

Here is one of the sample pages included in AngularJS 1.4 and Bootstrap 3.3 Web Parts. It contains three of the sample apps and has a theme applied. Note how the parts do not break the containing page or the site’s style.

Configurability

There are a few projects out there that have tackled the configurable Web Part problem including this very good one by Rachid Bouzalmat. This approach works, but it is less than ideal on a couple of counts (based on the 8 Characteristics of an Ideal SharePoint Customization). Specifically it uses jQuery to target particular elements in a SharePoint page. It also depends on the ability to hijack SharePoint’s JavaScript. In the interest of full disclosure, we have code that does both of those things for different reasons. I am just as guilty, just not in the case of this sample!

I will write more about how we implemented our Web Part containers and the configuration system in a future post. In the meantime you can see for yourself how it works by installing the sample. Until then here is a shot of the sample page in design mode.

–Doug Ware

8 Characteristics of an Ideal SharePoint Customization

I’ve been working with SharePoint for the last eight years. In that time I’ve built many SharePoint solutions using nearly every available approach. Eight years is a long time. It’s long enough to give, hear, and read a ton of ‘best practices’ advice. It’s long enough to learn from the lifetime of too many design choices to count.

This post is my attempt to enumerate the qualities of an ideal SharePoint customization based on what I’ve learned. Keep in mind that these are ideals and the real world involves trade-offs. What do you think?

  1. It meets the needs of the people who use it without limitations imposed by the platform
  2. It doesn’t interfere with the operation of the underlying platform
  3. It uses SharePoint functionality as much as possible
  4. It depends on things other than SharePoint as little as possible
  5. It cedes runtime control to SharePoint as little as possible
  6. The other things it depends on are provided only by using supported mechanisms other than directly editing SharePoint Master Page or ASP.NET files
  7. Runtime or configuration faults in a customization can only impact the customization
  8. It is manageable and governable

Ideal #1: It meets the needs of the people who use it without limitations imposed by the platform

This is the most important thing. Does it do what people need it to do? If someone asks if the system can be made to do something is the answer ‘yes, it will cost x‘ or ‘we can’t do that because…’? Is it available when they need it?

Sometimes what people need will be the underlying factor that drives decisions that result in successful but far from ideal customizations.

Ideal #2: It doesn’t interfere with the operation of the underlying platform

SharePoint is built to be a shared resource. It’s in the name. Customizations should be polite and let the shared services do their work unhindered by external customizations. Customizations that integrate directly with runtime processes have the potential to cause general denial of service conditions for an entire SharePoint property. Customizations that directly integrate with the platform might not cause issues in the present, but are later discovered to be significant obstacles to moving or upgrading a farm or site.

Ideal #3: It uses SharePoint functionality as much as possible

This may seem to go without saying, but often people recreate the wheel. Creating custom functions for out of the box features directly affects a system’s ROI by increasing the investment required and potentially its ongoing cost. SharePoint is a rich resource. Ideal customizations marshal the available resources to full effect.

Ideal #4: It depends on things other than SharePoint as little as possible

Sometimes people try to fit a square peg into a round hole. The more a customization requires things other than SharePoint the more likely a customization is a square peg. Of course it is often necessary in the real world to integrate with other systems and it is even more common to use third party components. Just the same, a customization that meets Ideal #1 by using nothing but out of the box functionality is, by definition, an ideal SharePoint customization.

Ideal #5: It cedes runtime control to SharePoint as little as possible

While an ideal customization makes deft use of SharePoint’s functionality it should do so in a way that works independently of SharePoint. For example a customization that fully controls an area of a page is better than one that consists of many hooks into SharePoint by depending on particulars of the HTML generated by SharePoint. The former can function as an atomic unit, the later can break any time the details of the page deviate from the original. It is better to provide an entire form than to hook into a button’s click event based on the ID of the element or a class name on the day the customizer did View Source on a page.

Ideal #6: The other things it depends on are provided via supported mechanisms other than directly editing SharePoint Master Pages or ASP.NET files

Meeting Ideal #1 may require you to directly edit SharePoint master pages or ASP.NET files. Doing so has a cost and it potentially requires ongoing maintenance. At times it might violate Ideal #2 if the customization lacks as of yet un-invented elements that later will come to be expected. As it stands, SharePoint provides a large number of supported integration options out of the box including Web Parts, custom actions, and a wide variety of API’s. Be aware that some supported mechanisms are counter to Ideal #5.

Ideal #7: Runtime or configuration faults in a customization can only impact the customization

This one is simple. If your app breaks for a user does it break SharePoint? Breaking SharePoint includes denial of service conditions at the server as well as client side problems that prevent pages from rendering or operating as intended. It is possible to meet Ideal #2 but not this ideal. For example, introducing a syntax error into JavaScript in the body of the default master page will not interfere in any way with the underlying platform but will still break a site.

Ideal #8: It is manageable and governable

Once created or deployed, an ideal customization is manageable and governable. It offers appropriate configuration surfaces and respects SharePoint’s policies, throttles, and security. It isn’t obscure, but rather easily discoverable. It is possible for it to be known and accounted for to the degree that is required. One example of a customization that is not ideal in this regard is a user custom action created by hand. At present out of the box there is no way other than interrogating the SharePoint object model via one of many APIs to determine a user custom action is present or modify the user custom actions associated with given object. Conversely, a customization that includes the same user custom action can be ideal if it includes the same custom action as long as the customization provides appropriate management features such as the ability to remove the action if the customization is removed or disabled.

Why is this important?

We have more options available for creating SharePoint customizations today than we’ve ever had before. We need a framework to help evaluate these approaches to make good design choices. Over time I will be writing about our designs here at InstantQuick. IQApp Central supports a number of different design approaches. I designed it to be respectful of people’s decisions by playing well with SharePoint. Still, there are some designs I encourage that I’d like to teach you about. When I say that something is better I’d like to do so in the context of concrete criteria. That way, when someone disagrees it is easier to engage in productive dialog!

–Doug Ware

A Tool that Answers the SharePoint Development and Provisioning Riddle

Solving the SharePoint App/Add-in Problem

Today I’m excited to be on the Office 365 Developer Podcast with Jeremy Thake to talk about the release of IQApp Central beta!

IQApp Central is the product of a multi-year effort to build a platform that makes creating, deploying, and managing SharePoint customizations easier. The goal is ambitious – to change the way people build SharePoint farm solutions, apps, and add-ins by offering better tools than they have ever along with a process that works the same on premises as it does in SharePoint Online. IQApp Central codifies everything I and others learned doing and teaching others about SharePoint for the last 8 years and what we at InstantQuick learned developing, maintaining, and operating our popular Instant Consulting Practice and Instant Legal Practice add-ins in the Office 365 Store.

Core to IQApp Central is the IQApp Editor, a set of tools that let you use SharePoint to create reusable solutions and components that are easy to deploy and track. IQApp Editor is backed up by an advanced provisioning platform that provides visibility into what packages are in use, where they are used, and how they are licensed.

Think I must be exaggerating? You can try IQApp Central for free, or watch the getting started videos. There are 6 and it takes less than 45 minutes to watch them all.

I Love My Surface 3 Pro

I’ve had a couple reminders recently that I’ve been neglecting the blog. The first was when I got an email asking if we are still in business and the second was when it took me 30 minutes to remember the username and password to edit some broken links I discovered in one of my older articles. Sorry about that, all the time has been going to make Instant Practice Manager better. We’ve got some great new features coming soon!

Today the family and I are packed into the van heading to see family for a long weekend. My wife Kim is driving and I am taking the chance to try my new Surface 3 Pro out from the road and do a little (way overdue) blogging.

Last year I did a similar exercise with my very large and heavy Lenovo W520. On that trip I used a laptop desk. The black thing under the keyboard in the photo above is a sleeve. It isn’t rigid, I just didn’t want to put it on the floor. So, I really am using it as a laptop and I find it to be perfectly comfortable.

This is my third day with the device. I was convinced to take the leap after reading this post by Corey Roth. It’s a great post and I won’t recycle it here, but I will add a few things.

Annoyances

Let me start by saying this is a great device. I’ve spent a couple of long working sessions writing code and I’ve gone to a couple meetings where I used OneNote and the stylus. I love this thing and I wholeheartedly recommend it. I don’t change hardware very often and I did a good bit of shopping and tire kicking before I made a purchase. Compared to the alternatives this device is a solid value. It isn’t cheap, but neither is it extravagant.

All that said, my first couple of days haven’t been completely issue free. The first challenge I had was when I used the traditional Remote Desktop app to connect to my W520 which runs Windows 7. For RDP into Windows 7 and 2008 there is no scaling and so I was presented with a 2160×1440 desktop on a the Surface Pro’s 12 inch screen. To my middle aged eyes it was completely unreadable. The new Windows 8 RDP app wasn’t any better and I thought, ‘this is a really nice device that I am taking back to the store.’ Fortunately my third try, Remote Desktop Connection Manager, http://www.microsoft.com/en-us/download/details.aspx?id=21101, works just fine and I still own the device.

The second issue was that the device would not reliably wake from sleep mode. If you da a search you will find that this is an issue that has plagued Surface users since v1 and that Microsoft has done a really poor job communicating with users. There is a full 26 page thread on the MSDN forums lasting over a year with some very disillusioned folks and not a Microsoftie to be found. Fortunately there is Twitter and Marc D Anderson let me know there is a firmware update. For some reason it didn’t show up in Windows Update for me and I had to download and install it manually. So far, so good and my sleep mode issues are solved.

Astonishment

The thing that impressed me most was how well the whole MS ecosystem is coming together and how well the integration works. I signed into the device the first time using my Microsoft account and was shocked at how well it pulled in everything with almost no effort on my part. It took me less than an hour to get Visual Studio and Office 2013 up and running and I didn’t have to blow a day setting up my environment. This is my first new machine since I really made the move to OneDrive and Office 365 and I just hadn’t noticed how seamless the integration really is.

I give the Surface Pro 3 two snaps and a circle.