Showing posts with label google+. Show all posts

An overview: How to implement Google's Structured Data Schemas

As a result of working in web products (both personal and professional) I have become quite au fait with SEO from a technical point of view, and purely technical things you can do to put you in good standing - all of which really, are just web best practices to be a good web citizen - things that we should be doing to make the web better (proper use of HTTP headers, mobile friendly designs, good performance for people on slower connections etc). 

One thing that is a bit above and beyond that is the use of Google's Structured Data. I will talk about what it is and what it does below, but if you are dynamically loading webpages (e.g. your website isn't just HTML on a web server, but either served from a server-side application, or is an API driven JS application), then you are most likely well placed to easily and immediately start implementing it.


1. What is Structured Data?

Google has defined a set of schemas regarding Structured Data on websites. This is a schema that allows better definition of key data points from a given website. It's a sensible move by Google and is a natural progression for their search engine.

Think about it, there are millions of websites out there made up with sprawling HTML code and content - whilst HTML is a standard (more or less!) across the web, there are probably millions of different ways people use it. It would be nice if everyone used the H1 etc heading tags consistently, or if everyone used the <em> tag the same way (emphasis vs italics), but the reality is they don't - some sites will be using HTML as intended but many many more undoubtedly just rely on <span> or <div> tags combined with CSS classes to re-define every element they might need. 

This is all fine, Google is smart enough to pull out the content for indexing - yes, if you use span elements with custom styling for headings on your website rather than the H1+ tags then Google will penalize you, but it won't stop Google reading and indexing the site. Whats more, its getting smarter all the time -  I'd probably back Google to be able to pull out relevant clips or question/answers directly in a fairly reliable way. However, they are Google and much like the Microsoft/IE of the 90s, they have the dominant market share so they can define their own standards for the web if they want to. That's exactly what Structured Data is. 

It's Google saying: 

Hey, if you provide some data in your code that looks like this then we will read that, so we don't have to guess or work out stuff. Or we can just keep trying to work it out from your html content.. it's your call


As mentioned earlier, if you have control over the source code and the data on your website, then this is really powerful. You can define specific (keyword heavy) snippets of content and explicitly tell Google about them - what's more the Schema for Structured Data lets you define content such as FAQ or how-to directions - so you can go beyond keyword heavy snippets and actually create FAQ for questions that you have identified from Google search trends (or whatever SEO tools you might use).  

Hopefully you get the picture by now - this is a pretty powerful tool.


2. Schema tags: FAQ and HowTo

Two specific parts of the Structured Data Schema stood out to me as quite universally useful for websites, and also produce decent tangible results: FAQ schema and HowTo schema.

  • FAQ schema allows high level Q&A points to be provided in the metadata for Google - generally useful as most sites will have some element of their pages that could be presented as FAQ

  • HowTo schema allows step-by-step how to guides - less widely applicable, but if you have any website that provides how-to guides or anything with instructions this is applicable.

What exactly to these tags do and why do we care? Well, as well as trying to win favour with the all-seeing google search bot, if it gets picked up it also means we get more search real estate and increased accessibility to our content which should also increase the chance of click through conversion.

If you have ever seen search results like this:


These points are being scraped from the site by Google from their schema tags - if you can automate the creation and inclusion of these for your site then you can be in a pretty good position to improve your SEO (still relatively low number of sites implementing these schemas).


3. Automating your schema tags

As I have mentioned a couple of times, and as you have hopefully realised - if you have a dynamic website, you are likely already taking structured data (from your database for example, so reliably structured!) and building HTML pages (either server-side, or data as JSON to a javascript app for page creation client side) - but either way, we are starting off with structured data, and the Google Structured Data wants.. you got it, Structured Data! So if you have the content, it really is a generic, simple transform between structured data formats.

Below is some example code - It is based on jekyll, as thats what my most recent personal project has been, but it's also pretty close to pseudocode, so hopefully you can easily translate it to whatever tech you use:

As you can see, its a simple JSON based data structure and you just fill in the relevant parts of the object with your data. 

You can see the full code in my Jekyll food website over on github - likewise, you can see the end result in action on the website (hosted by github pages, of course) too - the project was a food-science site - covering science and recipes, so a perfect match for FAQ (science pages) and HowTo (recipe pages) - for example if you go to a chilli recipe page which naturally has structured data for step-by-step instructions, and view the page source, you will see the JSON schema at the top of the page, using the HowTo schema elements laying out resources required and then the steps required. Likewise on the Science of humidity in cooking in the page source you will see the JSON schema with FAQ:









4. Conclusion

If you have control of the data being loaded on to the page (a custom site - something like WordPress or another off the shelf platform might make this harder, but at the same time there are undoubtedly lots of plugins that already handle this for you on your given platform which make it even easier!), and are even vaguely interested in increasing organic traffic and search ranking, then I'd recommend implementing this. It's very easy to add (it's also primarily behind the scenes tech - it doesn't impact the visuals or design of the pages its added to) and can only be beneficial.

As with anything trying to improve SEO, its always hard to measure and get concrete details on, but its relatively low cost to add, minimal ongoing maintenance so I think its worth a shot.


If you have had experiences with Google's Structured data, good or bad, then I'd love to hear about it!

Hello Facebook..

I have been away on a mini-break for the last few days, and whilst relaxing I was mentally planning out a blog post about mobile phones as identity and the social platform they provide (again!), then, I woke up this morning to Facebook's announcement of their Hello app.  In short the app will attach FB user details to phone numbers, so if you get a call from a mobile number you don't know, but have the app installed on your phone, it will attempt display FB info to identify the caller.




For my money, this is a very smart move.


Moving down the stack

One of the questions for the future mobile landscape is whether players like Facebook and Amazon can move "further down the stack" - that is, to start being more core to devices, or making their own. Amazon have tried with their Kindle Fire phone, and Facebook had Home - both bombed out, however, and there hasn't been much to suggest that there is more promise for them.

However, Hello seems to me like it could be a small step to bridging that gap.  The app is simple in itself, and done well I could see it being very popular - after installing, it doesn't need any active engagement from the user, but (hopefully - without having tried it myself) just sits there and enhances the users phone experience (as long as they don't try and do anything stupid, crazy annoying notifications, battery hogging etc) - As a simple enhancement to the incoming call screen, I can imagine pretty high retention/install rate - because why would you go back to unknown numbers?

One reason this could be a huge win for Facebook is that this step could make Facebook more core to the mobile device (and seemingly appear more and more like just part of the OS).  If you have the app installed, and miss a call, I would expect the missed call notification screen to be Facebook's Hello - with the normal stuff you would expect - so and so called you, return call, send message etc - which will inevitably give FB the hook to drive users to FB messenger, WhatsApp etc - This is a chance for FB to hijack the core functionality of the phone and drive traffic to its other properties, quickly FB messenger could become the default messaging app.



Your phone as your identity & network

This is something that I have ranted about before - there are two powerful and fairly unique traits of mobile phones that have the power to really disrupt the social/technology/online space:

Your phone is your identity - Whilst people continue to struggle to fix online identification/authentication issues, with a host of different providers offering Login-as-a-Service (Twitter, Facebook etc) and lots of people complaining about the proliferation of user logins/passwords that need to be remembered, the phone offers an interesting solution to that - Granted, phone numbers are not for life, but they offer simple, unique identification of individuals, plus, with two-factor authentication, it can be simple to verify that the person attempting to login is in physical possession of the device.  And with more moves to ApplePay and NFC payment with your device, this identity/device becomes even more tightly coupled.  

By Facebook tying your phone number with your profile it is an impressive move to help future proof their platform: so your phone is your identity? Well now your FB profile is intrinsically linked to that too.


Your phone as a social network - For a long time, Facebook have been the dominant force in social networking. Despite Google's effort with Google+, they haven't been able to displace the social network king. Do you think they struggled because they couldn't match Facebook's superior product? You think people stay at Facebook because they just love the features so much? Of course not. They stay because of user inertia - the feature that keeps users at Facebook is the network effect, no one would move to Google+ without the rest of the network, and how to you move your network?  As if to prove this, there are fairly regular outcries from the Facebook masses when FB changes their layout, or people find out about some terrible clause in the privacy policy - but do people leave? Nope. They just get on with it and keep using Facebook.  After all, the users are the real product, not the software.

Now, mobile phones change that a bit.  Traditional online social-networking basically just models the real world network of friends/colleagues/etc - In your real life social network, you are the node in the graph, and your mobile phone basically represents your node - If you think of Facebook as a centralised social network, mobile phones are a distributed social network (in other words, Facebook knows about the entire graph, and keeps that information centralised, but with your phone you know about your immediate neighbours in the graph - e.g. the people you have contact details for, but not the rest of the graph).  This is a pretty powerful idea - and this is what has made it possible for apps like SnapChat and WhatsApp to enjoy sudden and un-precedented user growth where non-mobile only apps (Google+) haven't.

If we add to that the fact that modern smart phones aren't just an address book - they have your photos, they have your videos, they have your messaging, they have your friends - is there much on your Facebook profile that you don't have (the ability) to have locally on your mobile phone?

All of this makes the smart phone and the real world mobile connections a very powerful platform for anyone to come and disrupt Facebook's crown - So this move by Facebook again just helps establish them as leading the mobile-social platform, not just an old internet company trying to compete.



An aside - Google needs to catch up

My original thinking for the blog was going to be about how Google should, in my opinion, be capitalising on the Android platform as a social network, and rather than trying to convince users to sign up to Google+ (or Wave, or Buzz etc) focus their efforts on making Android a more social OS and make more of the Android as your identity.  They would have to do it carefully with regards to stuff like "private by default" so not to cause uproar, but if they could effectively make all their Android users a node in the social network, then all of a sudden they could find themselves with a pretty good social network, and can start thinking about how to add value to the product.  Furthermore, with Android being the OS (as low down the stack as possible) then they would have a lot more options with regards bringing together all the aspects above - Your smart phone knows instantly when you take a photo or record a video (because you are doing it with the device!), it knows your location, it knows when/who you are messaging, it knows who your friends are - some nice usability around that and it starts to sound like a very strong value proposition!

Google kill off Google TV (in favour of Android TV)



Following on from expectations on the TV front, Google have just announced that they are end-of-life-ing Google TV as Android TV is fully operational as part of Android 5.0 - expect they are working with some OEMs right now to start getting some interesting devices launched..



Was WhatsApp overpriced?

As is to be expected, in the aftermath of the WhatsApp acquisition, there has been a lot of talk about how it was overvalued and Facebook payed too much. $19billion is a lot of cash, however you look at it.

But did Facebook overpay? Possbily.  

If we look back through history, a lot of big acquisitions have been decried as overvalued, sometimes rightly, sometimes not. When Facebook bought Instagram for $3billion there was a similar uproar, but now, things have worked out ok, and $3billion is looking more and more like a pretty good price.  When Google bought YouTube, there was an uproar over the valuation but no-one is now saying that wasn't a good purchase.  Incidentally, Google paid around $40 per active user when they bought YouTube, which is a slightly higher per-user cost than Facebook just paid for WhatsApp, at about $38 per user (although it's not really a relevant comparison in this case though, as you could argue that Google's projected monetisation model for YouTube is clearly different for Facebook and WhatsApp).


Facebook should have just built it

This is also a common line of argument. With $19billion  to play with, they could easily dedicate a decent dev team to building something awesome, and then market the hell out of it, possibly even incentivising user installs (If they wanted 450million users, they could give the first 450million installs $5 each!  disclaimer: app installed != active user).

My suspicion is if Facebook had built the app/platform themselves, it would have bombed.

Facebook as a company are becoming less and less focused, which is to be expected as their product becomes so multi-faceted, and are apparently getting worse at building fast/well. If they tried to dedicate a bunch of their guys to build it, it would be taking the opposite approach of WhatsApp - 32 engineers, 450million users, 99.9% uptime - all possible because they were so single-minded in their focus on the core of the product - You think an internal Facebook team could achieve those stats if they built the platform? I think that might be a stretch.  You think they would have been able push back on no advertising? no integration with the FB graph? No integration with existing FB messaging?  Every integration point is a potential pain point. Every pain point is a potential outage.

They also wouldn't be helped by their existing brand - people are wary of FB. Between the NSA scandal, their ongoing privacy policy changes and their *apparent* general disregard for their users I think people would be inclined to go to WhatsApp over a FB app.  As mentioned before, these days your phone is a social platform/graph in its own right - so the FB core product doesn't really have much more to entice users away from something like WhatsApp - Sure Google+ couldn't get the FB masses to budge, but their is no intrinsic value offered in FB that would really enhance an app platform like WhatsApp. In fact it's most likely the opposite and WhatsApp simplicity and absence of additional clutter in the product that makes it so appealing. It just works.

FB have promoted their messenger app pretty hard, and it hasn't been hugely successful. They have had to recently retire their email system. My gut feel is that an overly aggressive push for their home-rolled WhatsApp competitor would just serve to irk even more people and drive them away from their offering.


Stopping Google

So this is where it gets interesting.

WhatsApp apparently turned down a $10billion bid from Google, and finally chose to go with FB even when Google matched the $19billion offered.

Despite both being formidable tech giants, you might think there isn't that much real competition in the market place between Google and Facebook - Facebook email failed to make a dent in the world of email just as much as Google+ failed to make a real dent in Facebook's world of social networking. But, in my humble opinion, Google with WhatsApp could have been a game changer. For real.


Let's think about this:
  • Google have Android - the most pervasive and widely used mobile OS available. Available on a range of devices, including relatively low-powered affordable ones (critical in developing markets)
  • Google have strong working relationships with several hardware manufacturers with their Nexus hardware range, but now also have skin in the game having bought up part of Motorola and are now producing their own (suprisingly good) handsets
  • Google have bout Nest (home automation software) - more on that below..


Google have the software, hardware and market dominance in the mobile space. Can you think of a reason Google couldn't/wouldn't take on the mobile carriers? They are building more and more infrastructure around the US, and in heavily populated areas is there any reason they couldn't shun the carriers traditional networks and create adhoc mesh networks - using the actual mobile devices to power the network. Sure it wouldn't work everywhere, but couple that with traditional mobile infrastructure and it is looking more and more like a viable option.


Now let's consider: 
  • Google has the infrastructure, software and hardware to take on traditional carriers
  • They have viable monetisation models across their products to make cost not a big deal, coupled with falling back on to a mesh network where available they could potentially offer people free mobile plans - have an android device and Google account? then call/surf/message for free - no ongoing costs
  • Tied in with Nest home automation, that is a pretty promising value proposition


This is all good and well, but why should Facebook care if Google move into the mobile carrier space? As I have said before, your phone as a social platform/graph means that traditional social networks like Facebook that currently have the market advantage by being the incumbents start to loose that edge - and actually, if your social graph can be built up based on phone numbers/contacts then it can start to look more and more worrying for them. And that's what WhatsApp would have offered Google - a social graph built up based on phone numbers as identities - plus the ability to message pretty much anyone else in the world, regardless of device/OS/carrier.

You think there wouldn't be a massive rush towards Google/Android if they started offering free mobile plans? If they offer that, I think it's game over. And WhatsApp would have been one step towards that.

G-Drive

Just another quick one, seems like Google have launched their long awaited G-Drive. Have signed up and got my 5gb free storage and installed the pc software for teh G-Drive, but will post more once I have had a look around.

Check it out here:
https://drive.google.com

Google Shortening URLs

As another quick follow on note from the below, one of the features that was built in to the application was the ability to share your resume or particular achievements with your friends on Twitter. To do this, I obviously wanted to share a link back to the URL of the resume, so to maximise the potential additional text I investigated URL shortening.

Their is a bit.ly API that uses OAuth, but for what I wanted to do, I decided that was overkill, as I didn't necessarily need to associate the shortened URLs to a users bit.ly account, all I really cared about was getting a shortened URL.

Fortunately, Google came to the rescue with their goo.gl URL shortening service that also exposes a public API without need for authentication.

So I simply wrote a service class that utilised the Spring RestTemplate class to shorten URLs:

@Service("urlShortenService")
public class UrlShortenService {

       private RestTemplate restTemplate;

       public UrlShortenService() {
              restTemplate = new RestTemplate(ClientHttpRequestFactorySelector.getRequestFactory());
              List<HttpMessageConverter<?>> messageConverters = new ArrayList<HttpMessageConverter<?>>();
              messageConverters.add(new StringHttpMessageConverter());
              messageConverters.add(new MappingJacksonHttpMessageConverter());
              restTemplate.setMessageConverters(messageConverters);
       }
	   
       public String shortenUrl(String url) {
              Map<String, String> request = new HashMap<String, String>();
              request.put("longUrl", url);
              LinkedHashMap<String, String> shortUrl = restTemplate.postForObject("https://www.googleapis.com/urlshortener/v1/url", request, LinkedHashMap.class);
              return shortUrl.get("id");
       }
}


I didn't worry too much about validating that the string passed in was a URL for the time being as I always had control of that, but that should be something that would need to be considered.

Google's AI Challenge

It is that time of year again that Google is sponsoring an AI challenge - It's a standard affair, you have to controll a set of ants and collect food and eventually defeat other ant hills, but its good fun and always a good opportunity to play around programming in a more competitive environment.

Full details are here, you can download the starter pack and get started in lots of programming languages, but unsuprisingly I have gone with Java for now - once you have the pack downloaded, they have some steps they recommend to get your ants doing the basics well, although you will obviously want to go beyond this minimum set, its a good chance to get your head around the object model and the APIs that are provided as standard.

I have just started this today and have completed the first 4 steps of the walkthrough, so not even started thinking about personal tactics and strategy.. so expect some posts to follow with those.

In the meantime, I am, as always, keeping my code on GitHub, so feel free to have a poke around how I have implemented the various steps in my code (only the first step of the tutorial is implemeneted in Java at the moment, the others are all currently in Python, so does require the slightest bit of imagination)

Software Engineering Interview Questions Part 2

There was also recently an article that was doing the rounds with the 20 most craziest interview questions, quoting allegedly real questions from interviews at places like Google, Facebook, Goldmans etc. Here are a few, along with my attempts to answer them..

Facebook: Twenty five racehorses, no stopwatch, five tracks.  Figure out the top three fastest horses in the fewest number of races.
This needs a few assumptions before we begin: 1) each track only races 5 horses, and races cant be started at the exact same time - preventing effectively just running all the horses at once; 2) horses run the lap in a consistent time (e.g. if horse A beats horse B in one race, and horse B then beats horse C, then A will also beat horse C)
  1. Race 5 races, each with 5 horses in it (so all horses have raced) (5 races)
  2.  Race 1 race with the winners of the first 5 races (6 races)
  3. Find the winner of race 6 and from that horse's original race take the horses that came second and third (2 horses); take the second place horse of race 6 plus the horse that came second in his original group (2 horses); take the third place horse of race 6 (1 horse) - Race these 5 horses, this will give the second and third fastest horses (we already know the number 1 fastest horse is the winner of race 6)
Total races: 7

Goldman Sachs: Suppose you had eight identical balls. One of them is slightly heavier and you are given a balance scale. What’s the fewest number of times you have to use the scale to find the heavier ball?
Answer: 2
  1. Arbitrarily split the balls in to three piles, 3-3-2
  2. weigh the two sets of 3 balls (first weighing)
  3. If the two sets of three balance (weigh the same) then we know the heavier ball is one of the balls in the set of 2, so weigh those two (second weighing), and you will see immediately which is heavier
  4. If the two sets of three do not balance, then take the heavier set and weigh any two of those balls - if the first two balls you weigh are the same then you know the third ball in the set of 3 is the heaviest. If they do not weigh the same then you will immediately see the heaviest ball


Google: You are climbing a staircase. Each time you can either take one step or two. The staircase has n steps. In how many distinct ways can you climb the staircase?
The trick to this question, as with a lot of complex sounding questions(things that start with "there are 100 prisoners.." or "there is a village with 1,000 married couples") is to break "n" (or the number provided" to a much lower number.

In this case, lets start off with n=2 (we will skip n=1) - in this instance its easy to do the mental arithmetic to work out the number of permutations: it can be 1,1 or 2. So therefore there are 2 different permutations. Obviously, in this case, whilst n=2, permutations(lets call it x)=2, but its safe to assume n=x will not be consistent as n increases.

So let's increase n, this time, n=3. Again, simple mental arithmetic and we can work out possible permutations: 1,1,1;  1,2 and 2,1. So again there are 3 permutations (x=3).
We will continue our approach to see if we can see a pattern emerging.

n=4: possible permutations: 1,1,1,1;  2,2;  2,1,1;  1,2,1;  1,1,2, so x=5
n=5: possible permutations: 1,1,1,1,1;  2,2,1;  2,1,2;  1,2,2;  1,1,1,2;  1,1,2,1;  1,2,1,1;  2,1,1,1;  So x=8

We could continue this process untill we could see a pattern emerging, although as n increases, the number of permutations increases so might need a pencil and paper if you wanted to carry on. Fortunately, it seems to be heading in the direction of the Fibonnaci sequence! So to find the number of permutations for n steps we just need to find the nth position in the fibonnaci sequence (still not that simple!)



I have not validated that these answers are correct, but this is what I came up with! Leave a comment if you think I have done something wrong somewhere along the way.