Fixing Facebook preview picture of your SharePoint site

/

 

I have a lot of friends in the SharePoint community, and I see a lot of SharePoint related links shared in my social circles.  Sometimes, these links are hosted on a SharePoint site.  Universally, you know they are hosted on SharePoint because Facebook has picked a really bad picture as preview for the site.

image

 

Freebie referral: rules.ssw.com.au - SSW's Rules are some of the best I've seen documented in one place.  Check them out.  The site is beautiful.  It's just unfortunate that Facebook picks a really horrible picture asset for the preview.

image

 

Setting up the Preview Picture

Facebook publishes how to talk to its crawlers.  The specification that talks about the Open Graph API is Open Graph - Using Objects.

To specify a preview picture is actually very simple.

<meta property="og:image" content="/storage/JohnLiu.jpg" />

 

You can also use the pre-Open Graph syntax, if you don't provide og:image, Facebook can infer it from rel="image_src"

<link rel="image_src" href="/storage/JohnLiu.jpg" />

You need to have this inside your <head> tag.  Add this to your Master Page.  Easy!

 

Debugging

Facebook actually has a pretty nice debugging tool that will tell you how the scrapper is visiting your site.  And this can be very valuable to get insight into why the picture you've chosen isn't appearing.

https://developers.facebook.com/tools/debug/

image

Here, it's showing me the problem.  My picture is too small.

image

 

Fixed.

 

Now Facebook will pick the right picture all the time!

image

SharePoint Saturday Canberra 2013

/

Introduce your drastic UI changes... slowly

/

 

We are in the middle of a somewhat sudden rebranding exercise.  One of the main colours that was used prominently in the previous theme of the website is now being retired as the UI is simplified.

 

So here is what we have right now:

image

 

And here is where we're going (currently in development).

image

 

Where's the Yellow?

 

In every case where we ask one of our existing users the first response is always: Where's the "Company Yellow"?

There's of course a marketing message that will go out with our latest release. 

But here's the secret developer compromise.

 

We can reduce the yellow, slowly, overtime

 

The old header background will remain.  But in the Javascript that's run on every page, we introduce a small piece of script that modifies the opacity of the background header.

var days = (new Date("2013-08-20") - new Date()) / (24*60*60*1000);  // remaining days until 2013-08-20
var opacity = (days > 0) ?  (0.5  * (days / 14)) : 0;   // starts from 0.5 opacity to 0
$(".header-banner").css("opacity", opacity);

What this does, is that over the course of two weeks, the yellow's opacity reduces from the original (50% at this next release) to 0%.  So as days go on, the yellow header begins to fade, and after two weeks, it will simply disappear!

I wonder what'd be the water cooler conversation.  Each person will wonder what happened to the yellow as it slowly faded out of our lives.

SharePoint Saturday Melbourne 2013

/

It's that time again!  I'm down in Melbourne for SharePoint Saturday later today on July 27. 

I'm presenting TypeScript and SharePoint, with updated notes as I have been working with TypeScript since Feburary.  It's been just awesome.

The SharePoint Saturday version of the presentation will be more developer focused, and I'm hoping my audience will come with their dev hat on and ready to play with JavaScript and TypeScript.

I'll update this post later to include the download files for the presentation.

See you at SharePoint Saturday.  Early night and early morning for me later.

 

Update

 

Again, I had a lot of fun in Melbourne, had a lot of fun discussions and talked to a number of you guys about TypeScript in the real world.  Drop me a line as you start to play with TypeScript in your own environment.

Happy Birthday shout out to Elaine van Bergen!

 

Downloads:

Chrome, the Trojan Horse we didn't know about

/

 

I do not like where Chrome browser is going, and I'm typing this on Chrome.
Let me explain, there are a few pieces in this puzzle.

Language and API

  1. Google is working on a javascript pre-compiler, Dart.
  2. Google argues that because javascript will never be as fast as native code, Dart will eventually run on its own VM. Dartium. The Dart development browser has two VM's, the Javascript VM (Chrome's V8) and Dart VM.
  3. Dart provides its own methods to talk to the browser and access features such as storage, camera, geo.

Browser

  1. Google splits off from WebKit and starts its own browser engine Blink.
  2. Google says this will allow them to drop support for legacy features in WebKit and focus on new stuff. What I think they mean is that eventually Dart VM will be included side by side with the chrome Javascript VM (V8).
  3. I think this was never about WebKit. This decision is purely so that they can structure the chrome development to be completely in-house, and they can dictate including a second VM, without having to get approval from Apple's Safari guys.

OS

  1. Google continues to manufacture the Chromebook. Even with a very low market penetration.
  2. The Android operating system is under the ChromeOS group. Now that may seem strange. Android has huge penetration, Chrome OS is unheard of. Why are they structured like this?

Java

  1. Oracle sued Google for Java infringements, and Google does not licensing Java from Oracle. This means Google can't use a number of improved Java VM from Oracle who holds much stronger patents. Aka. Java performance on Google Android's Dalvik VM can't go faster because Google doesn't license those techniques from Oracle.

Joining the dots

  1. I think Dart will tie the whole thing together.
  2. Dart will provide API to Android, allowing developers to work directly with Android OS without going through the Dalvik VM.
  3. Dart will provide javascript developers ways to call the Operating System functions through Chrome browser, even APIs that aren't finalized by the W3C. Because Google will dictate these APIs.
  4. Chrome OS will run Dart natively, yes right now it's just a notebook that only runs a browser. But what if that browser now has access to OS level APIs? Suddenly it's a device that can run code that goes outside of the browser.
  5. Both javascript developers currently writing Chrome apps as well as Android developers will suddenly form that army that will be able to develop Dart apps. These will run across Chrome OS, Chrome Browser and Android.
  6. Dart is Google's version of Microsoft's .NET Framework. Born out of a necessity to control the entire ecosystem and with a gentle push (lawsuit) from Oracle. To give them a complete framework and API that they can control completely, without having to ask for approval from anyone.
  7. Chrome browser is the Trojan Horse that will allow Dart to run on Windows & Mac. It will run on Android and ChromeOS (which Google controls).
  8. The only places where Dart won't run are going to be few: WindowsPhone and Windows RT - neither OS Google cares or has any plans to support. iOS currently has Chrome (without Dart) - it remains to be seen if Apple will bow to public pressure if Google plays the card to include Dart within the iOS Chrome browser. But I think that war will come, especially since Chrome is the gateway drug.
  9. So while we're bashing Adobe's Flash and MS' Silverlight for being non-standard and plugin architecture degrades the security of our systems, Google's been ramping up to ship another VM right under our noses.