This article could be useful to any Office 365 developer who wants a quick reference to the recorded sessions from Microsoft Ignite, but it’s also intended as a companion to my opening talk at the Office 365 Developer Bootcamp on October 27, 2017, in Burlington, MA. The talk is intended to show you all the ways you can develop for Office 365. Office 365 includes the Office client programs, such as Word, Excel, and Outlook, as well as the online services, such as Exchange Online, SharePoint Online, etc.
There was a ton of great content at Ignite on Office development and, thankfully, most of it is available online. Here are links to the sessions that are available as recordings, so you can dive into whatever areas you like.
This week Microsoft mapped out a bold new plan for SharePoint. Microsoft is investing heavily to modernize the product to make it work as well in the Device and Cloud era as it once did in when the Web was still shiny and new. This article will explain how these changes could affect your organization’s SharePoint plans and how you can start preparing.
In economics, a widget is a name for a generic gadget or manufactured good; on the web, a widget is a generic piece of web functionality running on a page. What makes widgets special is that, unlike controls in ASP.NET or directives in AngularJS, widgets are generally released separately from the web page that hosts them, and are often deployed by end users.
If you’re reading this blog, you probably know something about Microsoft SharePoint, and this might sound familiar. A widget is a lot like a web part, only much lighter weight. In fact, widgets can easily be hosted in content editor web parts, on a list form, in a SharePoint add-in, or outside of SharePoint. If you’re careful, you can reuse the same widget in all those contexts!
NOTE: For more on this topic, please check out this episode of the Office 365 Developer Podcast where I discuss these topics with Microsoft’s Jeremy Take; it was a great discussion!
For many years, Microsoft and others in the SharePoint community promoted SharePoint as a Platform. The idea was to develop business applications within SharePoint sites, and thus to gain access to all the rich services SharePoint brings to the table such as document management, search, user profiles, enterprise content management, and more. Another promise of this approach was that IT could support one big application (SharePoint) and deliver may smaller applications to business users, and thus deliver on the “long tail” of application needs.
Microsoft invested in features like Business Connectivity Services and the Secure Store (identity mapping) service to make SharePoint a capable platform for building business solutions that integrate with other Line of Business applications. Yet this approach wasn’t all we had hoped it would be. Continue Reading
This article is reposted from my old MSDN blog. Please post comments here as I am no longer able to publish or respond to them on MSDN. Thanks!
Microsoft is cleaning house. Now that it has to maintain SharePoint for thousands of enterprises and millions of users in Office 365, Microsoft is working to clean up all the odd and messy bits of its flagship collaboration product. In a recent training course on Microsoft Virtual Academy, Microsoft urged developers to change the way they package and deploy their code in order to clean up a mess that has been building since 2003.