Reliable Microsoft

Microsoft has released a new future proof development method, with the last 3 versions of SharePoint. We’ve seen Sandboxed solutions, CAM applications (or should I say Add-ins?) and now they are about to release the ‘SharePoint Framework’. SharePoint is responsive now and our enterprise collaboration platform will work much better on mobile devices.

Public sites, like WordPress, must be response and mobile first nowadays, but collaboration sites for office workers can and should definitely focus on desktop (only?). If you want to add a limited, search driven, mobile view on top, sure, go ahead, but not mobile first. Weird as it may seem, in the enterprises I visit, most employees still use a desktop or laptop for office work. I don’t see a lot of employees with an empty desk, writing Word documents with their thumbs.

The funny part is that in January 2015 Microsoft discontinued the “SharePoint Online Public Website feature” for the following reason: “As part of the evolution of the Office 365 service, we periodically evaluate the capabilities of the service to make sure that we’re delivering the utmost value to customers. After careful consideration, we concluded that for public websites, Office 365 customers would be better served by third-party providers whose core competency is public websites. Therefore, we’ve made the difficult decision to discontinue the SharePoint Online Public Website feature so that we can focus our efforts and investments on delivering capabilities in Office 365 that will bring more value to our customers.”

So they first acknowledge that they have no real understanding of public web sites, and now they change the collaboration UI so it will behave more like public web sites? Okay…

The real problem I – as a consultant – face however, is that they’ve become a completely unreliable partner. The biggest laugh I had is when they suddenly shutdown coded Sandboxed solutions a few weeks ago. Yes, they’ve been telling us not to use coded Sandboxed solutions anymore because they are deprecated, but unfortunately the CAM model is still not up to par yet. Sometimes it is simply not possible to update or upgrade your coded Sandbox solution towards the CAM model. The reason they gave for stopping these coded Sandboxed solution now, is that they are not able to maintain this infrastructure as it does not scale. However…
When several migration tools stopped working, they somehow could make an exception for just those tools. These exceptions are however not available for paying customers. So not alone the infrastructure is still in place – even though they said they cannot do that anymore – but we now know who Microsoft values more, and it is apparently not its paying customers.

Now what can I advice my clients? I cannot tell them to use the “Yet Another Dev Method” for their future proof customizations. We’ve seen that these new development methods are as future proof as whip cream. So maybe the only honest advice I can give them is to either change their processes so they fit OOTB SharePoint, or not to use SharePoint at all anymore.

One last thing. I’m going to be bold here and make an prediction on when and what the new future proof development method for SharePoint web parts will be. In 2019 the new future proof development method for SharePoint web parts is: Web Components!

Responsive Designs

As a consultant I encounter many customers that ask for a responsive design. Whenever I ask them why, they simply answer that they want their website or application to work well across all devices. Now what do they mean by “work well”? Ever thought of that? When I see the examples on Responsive Designs and the frameworks that are created to “easily” implement responsive designs, I truly don’t understand what we are trying to achieve here. We create one HTML with a lot of large class attributes and a lot of very complex CSS to ensure a nice layout on all screen sizes. The complexity alone makes it very difficult to design your layout. But there’s more stupidity. Here’s an example of Zurb Foundation:

<div class="row small-up-1 medium-up-2 large-up-3">

Hmmm… remember when we used to say that we should not add style our HTML tags? HTML is a markup language and styling should be done with CSS. The reason for that is separation of concerns and maintainability. To change my layout, I should not need to change my HTML.
When I look at the sample above I actually see layout being defined in the HTML again. If I now want to change the layout of my site, I no longer need to change just the CSS, I need to change the HTML just as well. So far for maintainability.

Another big issue I have with these frameworks is that I’m not downloading the style rules for just the layout I need, but for all layouts I might (not) need at the same time. Especially on mobile connections this is a waste on bandwidth and because of the complexity of the CSS it also consumes a lot more processing power and thus battery. Then do we meet our goal of “work well across all devices”? I honestly don’t think so.

Now reconsider the goal. What is meant with “work well”? Not all screen sizes lent themselves to provide the same functionality. Reviewing a Word document on your phone? Scrolling through thousands of list items with “infinite scroll” and then edit them on a mobile phone. You simply do not have enough screen real-estate to make that work well. How about large application forms? On a large screen I might want to see all fields, while on a small screen a wizard like walkthrough would make a lot more sense. In my opinion a proper UX can only be achieved if we indeed design a UX for different screen sizes and device types.

Now what? We need to think about the functionality that we want to deliver and how to best deliver that across all devices. Responsive design is not just about adaptive rendering, it is about adaptive response just as well. Based on the device, our servers should send a different response that actually suits the device. We will of course miss the nice transitions whenever we resize the browser but, let’s be honest, that is just a gimmick for web designers and developers anyway. It just looks good on demo’s. As if the end user is continuously resizing its browser to see my awesome effects.

Unobtrusive HTML

Long, long time ago, I can still remember it. We had HTML without JavaScript. Slowly but steadily we started to include JavaScript into our HTML. At a certain moment, we noticed that a page with a lot embedded JavaScript was difficult to maintain. We apparently all decided it was time for a change. And with that we separated the JavaScript from the HTML. Hurray! We now had unobtrusive JavaScript. This meant that we first created the working and proper HTML and after we were done, we added some JavaScript goodness to the page. All good and well!

Nah, not all. We were all struggling with the different JavaScript engines and their intrinsic details. So along came jQuery. jQuery allowed us to use a single codebase for all browsers which is awesome. At the same time I started to notice something else. People started to write jQuery plug-ins and a lot of these plug-ins output HTML. And at that moment I started wondering. We moved from embedded JavaScript, which was bad, to embedded HTML. Not alone we were back to where we started, but now we lost all intellisense, tag completion, and refactoring as we edited the HTML inside JavaScript strings. With JavaScript inside HTML script tags, like we had before, we at least had some intellisense. So some people noticed that rendering HTML inside JavaScript, mostly used for some kind of databinding, is bad. And luckily for us, AngularJS version 1 came along.

AngularJS version 1 allowed us to write a controller in JavaScript, a view with binding tags in HTML, and fetch our data from a RESTful API. We now had a real MVC framework! All loosely coupled. We could in effect create several HTML files targeted to different outputs and reuse the controllers. No need to change a single line of code. Awesome! And then AngularJS version 2 was announced.

Angular JS version 2 is supposed to be faster and much better than version 1. Everybody is hyping it. But, when I looked at the code samples, I noticed that they are defining HTML views in class decorators. We are back at writing HTML in JavaScript string properties again and by using decorators we have no way to do dependency injection to define a viewengine, which in turn could select the proper view for the device being used. It almost feels like they are implementing ASP.Net Web Forms user controls in a complex client side way. If you do so, at least implement the composite pattern.

We are running past our goal and are circling right back to where we started again. Only difference is that we now have to find a way to embed unobtrusive HTML inside our JavaScript. With that we might get our intellisense, tag completion and refactoring back.

I honestly don’t understand why we keep running in circles. Anybody?