I have been unusually silent on Twitter and on this blog in the last few weeks. The reason is that I have left Spenta / Beezy, after two wonderful and exciting years, and I have joined Sogeti Spain as Senior SharePoint Architect. I have nothing but words of gratitude for my fellow Spentians, and it is always a pain to part ways with so awesome a team.
My new work role in Sogeti Spain will be to keep building top-notch SharePoint solutions, but additionally I will be acting as a SharePoint Team Lead. I have already started making some changes in the development practice with the ultimate aim of creating a culture of excellence in SharePoint solution development.
I have been thinking lately of the evolution I witnessed in the corporate intranets working on many SharePoint projects. In this post I’m going to summarize my thoughts on that evolution. This is also going to be a technology-free post.
The main difference between intranet and public web site is that intranets are not anonymous. The user browsing the intranet has a name and a username (and hopefully more than that) and this information can be used in many ways.
The “Classic” Intranet
The “classic” intranet in the prehistory of SharePoint was fairly uniform in the content it presented. Little or no information was personalized for the user that was viewing the page.
The content of the intranet was “pushed” to the intranet from centralized locations such as the News Center or the Announcements of different sites. Usually, there were few people actively adding content and all the rest of the intranet users were passive consumers of that information.
So much for the “dynamic” content that was being added. However, the most of the content in the intranet was static or nearly static: telephone listings, project and department descriptions and so on. That content rarely (if ever) changed.
In consequence, the Intranet home page reflected that approach. The “push” model distributed news that were prominently displayed. There was also a myriad of shortcuts, links and navigation contraptions that allowed the user to further explore the intranet.
Naturally, this led to the unengaged intranet users. They just had no need to visit the intranet every now and then. Only a casual visit every now and then or a fact-finding necessity would cause the users to open the intranet in their browsers.
Some companies would leverage the user information to filter the information they see on their home page, such as showing only the information that is relevant to their department. However, the most of the organization didn’t have these problems as their volume of new information was low and filtering then served no purpose.
The “Social” Intranet
In the last 4-5 years the social computing technologies have made their appearance in the corporate world, after having taken the private user space by assault. The immediate nature of social updates and the viral-like features of popular content were seen as the cure for the unengaging, static intranets of the past.
The news section was being replaced or prominently complemented by a “wall“, “feed” or “conversation”. It’s dynamic nature ensured always-fresh content in the intranet. However, it also opened the way for information overload. From being starved to information death by old intranets to being choked by the sheer overload of information that is generated every day…in just a few years.
Social computing also features a network, where every users has connections to other users. It may be an explicit connection such as user follow action or an implicit connection such as having the same department. These connections are then used to show the information generated from the users the visitor is connected to. You could see documents and content created by the people you are connected to and hopefully this “social” filter capability would reduce the information overload to more personal level.
This filtering by user characteristics such as connections, context and behavior is what is being called a “pull” model, where the information is pulled for the current user out of the vast information overload.
To Push or To Pull?
In the light of the rising popularity of the social intranets, we may think that the “pull” model is superior to the “push” model. There is some truth in this, but in my opinion the answer isn’t just that simple.
I think that the key of the intranet success is the information context. This context is the thing that separates the raw data from useful bit of information.
The “push” model makes the context static and uniform to all users. The “pull” model makes the context unique to the user. And the answer lies in a wise mix of both push and pull models.
All the content in the intranet isn’t the same. There is a need for global information (such as IT services outage) that could benefit from the push model. All the rest of the information is more or less contextualized. So, the “news pushed to every user on their home page” are clear candidates to be ditched in favor of the pull model.
The pull model makes the context social and user-centric. This is true for many situations: the content I have been interacting with, the content created by the users I have interacted with, the content about the topics I find interesting and similar derived situations. However, there is no single recipe: the fact that I follow a user doesn’t mean that I am interested in all the thing he or she creates and shares.
Here is a feature that is missing from many “social” intranets: the curated content. The act of content curation is the act of providing context to the information. We need users to curate, collect, collate and organize the content that is relevant in a specific context and then make this context easily findable. Wiki pages are perfect containers for curated content, for example.
The art of good intranet design is the art of wisely combining the three models: pushed, pulled and curated content to provide the best experience for the intranet users. There is sadly no unique recipe to share here, that’s why I call it an art.
It is also what makes intranet information architecture projects so exciting!
Desde hace ya un tiempo andamos comentando internamente que sería un reto importante poder organizar un evento de estas características en Barcelona (y en España), pero que a la vez comparándonos con el resto de los grupos de usuarios de Europa vemos que podemos hacerlo. Por eso nos líamos la manta a la cabeza y empezamos a movernos para convertirlo en realidad.
¿SharePoint Saturday, mandeeee, lo cualooo?
Los SharePoint Saturday (o SPS) son eventos tipo conferencia, gratuitos y celebrados siempre en un sábado. Suelen tener varios “tracks” en paralelo y ponentes de gran nivel, con preferencia para los ponentes locales y personas destacadas en la comunidad que lo organiza.
Nuestro SharePoint Saturday inaugural se hará el sábado 26 de septiembre de 2015 en las instalaciones del Institut Químic de Sarrià (IQS). Nos haría ilusión llenarlo con 200 personas del mundillo SharePoint, entre desarrolladores, usuarios, administradores, jefes de proyecto y demás perfiles que directa o indirectamente estén relacionados o bien con SharePoint o bien con Office 365 y Azure.
¿Qué necesitamos ahora?
Necesitamos apoyo en tres frentes:
Tenemos abierto el call for sponsors para que las empresas que estén interesadas en tener presencia en el evento puedan patrocinarlo. Los niveles de patrocionio son 3: Gold, Silver y Bronze. Además, existe la opción de patrocinio Raffle, es decir de aportar un regalo que se sorteará entre los asistentes.
Si tu empresa podría estar interesada, ponte en contacto con nosotros en Twitter o en la web, por favor.
También tenemos el call for speakers donde los ponentes potenciales pueden proponer sus charlas. Las charlas serán preferentemente en inglés (para que los visitantes del resto de Europa puedan acudir también), pero si no te manejas bien en ese idioma no te preocupes, tenemos un lugar para tí también.
Sobre todo lo que necesitamos es que todo el mundo que tenga interés en SharePoint u Office 365 sepa que el día 26 de septiembre tiene una cita. Si tenéis amigos o compañeros de trabajo a los que les pueda interesar, haced correr la voz para que podamos llegar a esas 200 personas de asistencia que nos marcamos como reto.
Yesterday Microsoft announced the availability of Azure App Services, a new high-level grouping of services for building apps on Azure cloud platform. According to the announcement blog post:
App Service is a new, one-of-a kind cloud service that enables developers to build web and mobile apps for any platform and any device. App Service is an integrated solution that streamlines development while enabling easy integration with on-premises and SaaS systems while providing the ability to quickly automate business processes.
I immediately saw “On-Prem SharePoint Server” in the list of the available connectors for Logic Apps and API Apps.
Also, SharePoint is visible in the API Apps catalog in Azure, too.
It has made me think that a SharePoint 2016 could, in theory, use the new Azure App infrastructure to run workflows (now called Logic Apps, similar to BizTalk orchestrations) that span multiple services: SharePoint, Exchange, public and private social networks, data stores and so on. The logic of the workflow would be based in Azure and it would consume the other services through the connectors. The authentication clould be brokered by the Azure AD.
I like the idea. Only the Ignite will let us know how much of the idea holds true.
My last adventure with Lightswitch was trying to detect when a popup window inside a screen is closed.
You can close a Lightswitch popup window by clicking or tapping outside the popup. The jQuery Mobile popup widget that Lightswitch uses then closes the popup. However, I wanted to intercept that event and do some housekeeping such as discarding the changes made by the popup.
The difficult thing was finding out where to put the event hookup code. Then, it was just a question of using jQuery Mobile Widget afterclose event that is triggered when a popup is closed.
The right event to listen for in my case was the rendering of the popup content. In the Lightswitch designer add a postRender event handler and associate the afterclose event of the parent object (the popup itself):
Another weird SharePoint app bug happened yesterday. The solution was fairly easy once you know what’s going on, but it’s just weird altogether.
You have a custom app in your SharePoint 2013 App Catalog.
You want to add this app to a SharePoint site. You can’t find your app in the “From Your Organization” section when you click at “Add an app” in a site.
I first suspected that the current user doesn’t have permissions to add an app. However, the user is the site collection administration and thus has the permission to install an app.
Yet…a slight detail. The App Catalog site is, well, a SharePoint site. With its own permissions. And, by default, containing only the user who created the catalog in the first place (the system admin).
So, the current user, although a site collection admin, doesn’t have permissions to read from the app catalog. (This is the weird part, as I expected SharePoint to do the reading using a system account behind the scenes.)
Add the users that should be able to install your custom apps to the site permissions of the App Catalog site, with Read permission level. In my case it was “Dani Alves” (yes, I’m a Barcelona fan).
Now, the app is visible in “Your Apps” when you try to add it to a site. Yeah!
Last Friday, March 13th, I had the opportunity to speak about personal branding for developers at the Microsoft MVP Open Day for Spain, Portugal and Italy MVPs in Palma, on the beautiful island of Mallorca.
The choice of topic is very intentional. I firmly believe that building a personal brand is one of the best ways to differentiate yourself from the rest of the fellow experts. It doesn’t make you look famous, but it makes your unique message clearer and more available.
The talk was very well received. I had a lot of follow-up questions and discussions, which is in itself an indicator that the talk was needed.
Usually, on these meetings there are several technical sessions but I have talked to few fellow delegates who share my opinion that people skills and soft skills are even more valuable for the technology experts. The technical topics are our staple, but the other topics are many times unknown or misquoted at best.
What do you think about the personal branding as a developer? Are you engaged into it? Would you like to see a series of blog post about personal branding for developers here on this blog? Share your thoughts in the comments!
Another one of my strange adventures with Lightswitch has made me look deep inside the navigation framework that Lightswitch uses. I will explain the strange symptoms, the cause I found out and the solution that worked for me.
I have a Lightswitch app connected to SharePoint data. I have several screens, one for each list that is managed from Lightswitch. I want to be able to navigate straight to the screen I want from SharePoint, or to deep-link the screen.
To do so, I made a custom Promoted Links list. I added to this list my LS app deep URLs, such as https://appurl/HTMLClient/default.htm?SPHostUrlaaa&SPAppUrl=bbb&SPChromeColor=ccc#/ScreenName/[unique_number]. The ScreenName parameter is different for each screen, obviously. I also configured each link to open in a SharePoint dialog window.
Strange things happened. While I could open the desired screen by clicking on the promoted link, it would start displaying “Error Loading Page” message and keep a /spinning circle icon alive as if it were waiting for a long-running operation, after every navigation to and back from another screen or popup in the app.
These symptoms would disappear if the links were opened without dialogs (in the same tab or another browser tab). They would also disappear if I switched to another screen inside the app using the Lightswitch navigation menu.
I first suspected any custom JS files I added to the application. However, it was not until I used Fiddler tool to investigate the requests my app was doing that I found the answer.
Lightswitch app are Single-Page Applications (SPA). They leverage jQuery Mobile framework for Lightswitch navigation and maintaining app state in the browser. jQuery Mobile has a custom navigation feature that overrides standard browser navigation stack to be able to use Back button to go to the previous screen. In a SPA, there is only one “physical” page (default.htm) and all the further requests are done using AJAX calls to the LS backend services.
Fiddler showed me that the error messages were caused by a 404 HTTP not found response to a unknown page that was something like this: /ScreenName/IsDlg=1.
By opening any URL inside a SharePoint dialog, SharePoint automatically adds IsDlg=1 to the URL. It is used by SharePoint to hide any extra chrome such as navigation and toolbar from being displayed inside a dialog. So, my original URL was now changed to as https://appurl/HTMLClient/default.htm?SPHostUrlaaa&SPAppUrl=bbb&SPChromeColor=ccc#/ScreenName/[unique_number]&IsDlg=1. I could now reproduce the error even without SharePoint dialog, just by adding an extra query string parameter to the LS deep link URL and pasting it in the browser address bar.
Well, jQuery Mobile powered Lightswitch navigation seems to break when trying to parse a screen ID that follows the # sign and then finds another query string parameter such as &IsDlg=1. I tried to move the IsDlg parameter to the left of the screen ID. It worked, and I saw that I had to fix the URL in order for the navigation to work.
I first thought of rewriting the LS URL by adding a custom HTTP module or a IIS rewrite rules but it sounded too cumbersome. I had to find a simpler mechanism to achieve the opening of a specific LS screen in a SharePoint dialog frame.
Thanks to my colleague Sergio Gallego, I was able to find a solution. I made a copy of the default.html page in LS and called it screen.htm. I then changed the ready() event handler inside the page to check for a query string parameter called “s” (for screen). It would then pass the parameter value as a parameter to the LS msls._run() method. This method takes an optional string parameter that is then used to start the LS app and open the screen with that same name.
I had to rewrite my URLs to the following schema: as https://appurl/HTMLClient/screen.htm?SPHostUrlaaa&SPAppUrl=bbb&SPChromeColor=ccc&s=ScreenName.
Here is the full code of the ready() method in the screen.htm file.