Twitter

How to get count per link?

        http://urls.api.twitter.com/1/urls/count.json?url=http://www.perl.org/
        {"count":351,"url":"http://www.perl.org/";}

Statistics tool?

Not yet but soon? https://dev.twitter.com/blog/introducing-twitter-web-analytics

How to hook to an event?

https://dev.twitter.com/docs/intents/events

http://stackoverflow.com/questions/4947825/is-there-a-callback-for-twitters-tweet-button

        twttr.events.bind('tweet',    tweetIntentToAnalytics);

How to create button?

http://twitter.com/goodies/tweetbutton https://dev.twitter.com/docs/tweet-button

    <script src="//platform.twitter.com/widgets.js" type="text/javascript"></script>
    <div>
      <a href="https://twitter.com/share" class="twitter-share-button"
         data-url="http://bit.ly/twitter-api-announce";
         data-counturl="http://groups.google.com/group/twitter-api-announce";
         data-count="vertical"
         data-lang="es">Tweet</a>
    </div>

Supports Open Graph?

No - https://dev.twitter.com/discussions/1244

Facebook

How to get count per link?

        http://graph.facebook.com/?id=http://www.perl.org/
        {
           "id": "http://www.perl.org/";,
           "shares": 370
        }

Statistics tool?

http://www.facebook.com/insights/

Needs meta tag on the root page.

        <meta property="fb:page_id" content="159636650742750" />

How to hook to an event?

http://developers.facebook.com/docs/reference/javascript/FB.Event.subscribe/

How to create button?

http://developers.facebook.com/docs/reference/plugins/like/

        <div id="fb-root"></div>
        <script>(function(d, s, id) {
          var js, fjs = d.getElementsByTagName(s)[0];
          if (d.getElementById(id)) {return;}
          js = d.createElement(s); js.id = id;
          js.src = "//connect.facebook.net/en_GB/all.js#xfbml=1";
          fjs.parentNode.insertBefore(js, fjs);
        }(document, 'script', 'facebook-jssdk'));</script>

        <div class="fb-like" data-href="http://www.perl.org/"; data-send="false"
        data-layout="button_count" data-width="450" data-show-faces="true"
        data-action="recommend"></div>

Supports Open Graph?

Yes - https://developers.facebook.com/docs/opengraph/

Debug tool - http://developers.facebook.com/tools/debug

Google+

How to get count per link?

        https://plusone.google.com/u/0/_/+1/fastbutton?count=true&url=http://www.perl.org/

Statistics tool?

https://www.google.com/webmasters/tools/

Navigate to "+1 Metrics"

How to hook to an event?

        <g:plusone size="tall" callback="plusone_vote"></g:plusone>

How to create button?

http://www.google.com/webmasters/+1/button/

        <!-- Place this tag where you want the +1 button to render -->
        <g:plusone></g:plusone>

        <!-- Place this render call where appropriate -->
        <script type="text/javascript">
          window.___gcfg = {lang: 'en-GB'};

          (function() {
                var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true;
                po.src = 'https://apis.google.com/js/plusone.js';
                var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s);
          })();
        </script>

Supports Open Graph?

Yes - https://developers.google.com/+/plugins/+1button/

Recently there was a discussion on PerlMonks whether to add FaceBook "like" buttons or not. tye said "there will never be a standard facebook button on PerlMonks so long as I have any say". None of us is crazy about putting other sites JavaScript or even images on their site unless it is 100% necessary. On the other hand the social networks and in particularly sharing is important.

What about following solution (already implemented on the right side of this page)? After clicking the link "If you like it, share it.", the page element is replaced by different sharing site links which lead to current url submitting.

(Kudos goes to sixtease and his project csobo for the enormous list of share links.)

Theory, fail 1, fail 2 => so now the current (good?) solution. To get to it, I didn't had to develop a new idea, but I had to escape the old idea that the best thing to do for a mobile devices is to send the images in the native screen resolution. This is still true for the older handsets, but not any more for the new age of smart-phones.

It's enough to put following tags to the HTML header:

<meta name="viewport" content="width=640, user-scalable=yes"/>
<meta name="HandheldFriendly" content="true"/>
<meta name="MobileOptimized" content="640"/>

and then just optimize the page for 640px width. This works awesome good for recent devices with recent browsers, or in general the browsers that supports the viewport meta tag. Both image and font-size will be adapted to the screen size and the page will look similar on iPhone 3 or 4, iPad, Android 2.x, new MS phones and Opera browser.

So at $work we will still support the old devices that needs image resizing, for the other companies that doesn't have time, budget or an interest, it might be enough to target the recent smart-phones via 640px optimized pages with a proper viewport tag.

After the theory, first wrong solution, here comes the second wrong solution. It's easier one and the JavaScript is used only for iPhone-s where it was also tested. The problem with iPhone 3 and 4 is that both hardware versions are using the same OS and because of that the same user-agent string. So there is no way of knowing which resolution does the device have when the HTTP request comes to the server.

Following two meta viewport tags works fine for all phones besides the iPhone. The first one is when scaling should be disabled, the other when enabled.

<meta name="viewport" content="width=device-width, minimum-scale=0.5, maximum-scale=1.0, user-scalable=no, target-densitydpi=device-dpi"/>
<meta name="viewport" content="width=device-width, minimum-scale=0.5, maximum-scale=3.0, user-scalable=yes, target-densitydpi=device-dpi"/>

To get the native resolution for the iPhone 4 I had to create a JavaScript that detects 320px vs 640px resolution, sets the cookie and makes a refresh while setting the url parameter so that it also works when cookies are disabled. Then our server-side code has to resize the images properly and update the "width=640" in the viewport meta tag. Still a little complex, right? But works! :-)

Now what are the problems.The fonts can get pretty small as iPhone 4 applies the 0.5 scale and the Androids with high resolution uses the high-densitydpi. And it doesn't work so well for Opera too.

Here is the JavaScript code (much less lines then the previous one):

The part1 described some troubles with the screen sizes of the mobile devices. Since then I spend some time playing around with the problem and I found 2 wrong solutions until I got the (hopefully) right one. So let's start with the first of the wrong ones.

The solution relies on the fact that we have the device screen width and height in our DMS (Device-Management-System) database and this is compared with the real width of the device using JavaScript, then if there is a difference a cookie is set and via this cookie our Renedering-Engine on the web server is instructed to resize the images using the zoom level. It requires refresh, lot of "junk" in the HTML header and all the "machinery" on the server side. But the images are properly fit even for Opera browser that has the same user-agent string for different devices with different screen sizes.

See the code below, it's a nice example of a working-complex-bad solution :-)

First time that I've tried to use "#" instead of "?" for url parameters was on the CPAN2Deb page. No page reloads needed everything handled by JavaScript. Yesterday I've tried that same, but for search.youonl.com. How does it work? Every time a new search is made the location bar is updated without a need for page reload. This is fast (the browser makes no unnecessary request to the web server) and it allows easy bookmarking or copy&pasting of the current search configuration.

Here are some examples:

• http://search.youonl.com/en/#s=gw;q=axiology (Google+Wikipedia search for Axiology)
• http://search.youonl.com/en/#s=gg;l=ende;q=axiology (Google+Google search for "Axiology" in English and German)
• http://search.youonl.com/de/#s=yo;l=deen;q=wien%20besuchen%20tips (Yahoo+WolframAlpha in German + English for "wien besuchen tips")
• http://search.youonl.com/sk/#s=ww;l=ende;q=Rak%C3%BAsko-Uhorsko (phrase in Slovak language showing English and German Wikipedia article for "Rakúsko-Uhorsko")
• http://search.youonl.com/en/#s=gt;q=learn%20juggle (Google + Helper tags for "learn juggle")

The ";" vs "&" for separating the arguments is good because "&" needs to be escaped in HTML while ";" can be simply copy&pasted directly.

One side effect of switching from "?" to "#" for the url arguments is much more privacy for the clients as the requests with arguments are not passing to the server, so there will be no user queries in the server logs any more. search.youonl.com still uses Google Analytics for statistics, but the search queries are shared exclusively between the client (web browser) and the search engines that he uses.

And last, but note least, is that fewer requests to the web server means less processing and data transfers.

I spend some time recently fiddling around with meta viewport, so I'll share some notes. First here are the specifications:

• Apple
• Google
• Mozilla
• Nokia (but they are referring to an Apple documentation)
• QtWebKit
• Microsoft

The blog posts A pixel is not a pixel is not a pixel and The two viewports are good to read describing the "problem" with zooming and viewport. The trouble is that high dpi mobile devices are zooming in by default. Speciality of the iPhone is that the user-agent string is totally the same for 320px iPhone 3 as for the iPhone 4 which is 640px wide. To get the nice sharp images on an iPhone 4 one needs to use 640px images and set the image width attribute to 100%. At my $work we resize images to exact size of the mobile devices. With this auto-zooming features of modern devices the life's getting more difficult.

And here is what I found regarding the <meta name="viewport"> tag. This are two+1 generally usable examples:

<meta name="viewport" content="width=device-width, minimum-scale=0.5, maximum-scale=1.0,
    user-scalable=no, target-densitydpi=device-dpi"/>
<meta name="viewport" content="width=device-width, minimum-scale=0.5, maximum-scale=3.0,
    user-scalable=yes, target-densitydpi=device-dpi"/>
<meta name="viewport" content="width=640,          minimum-scale=0.5, maximum-scale=3.0,
    user-scalable=yes, target-densitydpi=device-dpi"/>

• width=device-width will tell the browsers to use the native resolution of the phone.
• target-densitydpi=device-dpi is needed for the phones with Android and a high-resolution (or high-dpi, example screens with 480x800, like Samsung Galaxy S) to not zoom. Note that the target-density is at the end of the content attribute. This is because it is unrecognised by iPhone and if iPhone encounters and unrecognised option in the viewport content attribute it stops parsing and will ignore the rest of the string.
• maximum-scale=1.0 together with user-scalable=no is there to forbid zooming in. If the page is optimized for the mobile resolution it's ok to disable it.
• maximum-scale=3.0 together with user-scalable=yes can be used to let the freedom to the users to make the fonts/links/images bigger. Just one note here. Once the user applies his own zoom on the page there is no way with JavaScript to get the native screen resolution.
• minimum-scale=0.5 is a little bit tricky. The 0.5 is there for the iPhone 4. This device under normal conditions is rendering images 320px wide to the full screen width, which means zooming them in => 320px images is shown on the full width of 640px wide screen. I found just one way to force iPhone 4 to show 640px images natively (without width attribute) and that is to set width=640 in the viewport meta tag. The problem is that the only way to recognize iPhone 3 from iPhone 4 is via JavaScript and window.devicePixelRatio == 2. But the JavaScript is a little bit too late for the content of the page.
• width=640 setting the proper (fixed) width is also necessary for the windows mobile phones with IE in order to have the native resolution.

This is not all. There are device databases (WURFL, DeviceAtlas) that collect user-agent strings and helps to provide screen widths to the mobile page rendering engines, but for an Opera Mini & Opera Mobile the user-agent string is the same/similar for all kinds of devices. And the change of device orientation is also worth to consider, as just by turning the phone around, width of the screen changes from 480px to 800px.The only way to get the screen resolution is in JavaScript, but that is too late, the page is already there...

One solution I've described in the beginning and that is to let the browser scale down the high-resolution pictures. This works for the modern phones and is not too bandwidth friendly (providing 640px wide images to all types of phones) and not so reliable with the old phones either. Another solution, that I'm testing currently, is to try to guess the screen width as good as possible based on user-agent string and then use JavaScript to get the proper screen width, reloading the page with a cookie set if necessary (if the width is not what was expected) or having the proper width set for the next page request.

One final thought - Why don't the mobile browsers send the display width and height in the http headers? This will save us a lot of troubles with device detection.

I've created a screen cast about why the www.youonl.com exists => simply because one search engine, one language and the first page of search results is not always enough. Watch the video for more "why" and "how".

Once I listened as my favourite college Liz Mihaescu called with a doctor (yes we have an open-space) and repeated her name for the 5th time to the phone, I thought to my self, this is really a pain. I'm also hearing our receptionist Timea, from time to time, trying to say clearly the company email addresses over the phone. The hostname is short but some people has really long names like Markus - mhohlagschwandtner@mms.ag. I wouldn't want to spell it out too often...

So what can be done about it? What's easy to pass over the phone? Numbers! There are just 10 types of them, can be clearly pronounced and hard to mistake. What if there will be a web service where one can paste a complex text and have it stored on a pure numeric URL? (besides the top-level-domain-name as there is no numeric one in the world)

The task sounded like a challenge and not so difficult to do in my spare time, so I've created 31415.eu. Here's an example - http://31415.eu/59676716. It's valid for 3 months from now on, that is why so many numbers. The shorter the period, the less numbers it will have. (ex. 0-99 for 15min expiration) Still it's easier to tell 13 numbers (if the page is known to the other person then just 8), then to spell out the information that I've pasted there.

What do you think about it?

Who is inventing this things? For years we have this already, don't we? It is just called ad banners. ;-) The idea and message is there. You like this page/article/service? Then just click some random banner to say "Thank you!". Simple and doesn't cost anything to the users. :-)