Smarter than the average Pierre

Sunday, February 12, 2012

A Simple Facebook Cover Photo Hack

For those of you who haven't entirely abandoned Facebook for the uprising Google+, you'll likely have noticed that Facebook has once again made a significant change to the Profile page. The Facebook Timeline is the product of Facebook's new focus on UI design. Love it or hate it, it's here to stay.

One of the most beloved changes has been the addition of a large "cover" photo to the profile page. Facebook tells us to: "Fill this wide, open space with a unique image that represents you best. It's the first thing people see when they visit your timeline." Indeed, the cover photo and the profile picture provide a great opportunity for one to show off their creativity. See "Facebook Timeline Cover: 40 creative examples" for some interesting cover hacks.

A simple Facebook cover photo hack is to use the profile picture as a transparent window into the cover photo. LifeHacker recently posted an article describing how to do exactly this with Photoshop or Gimp. Inspired by this post, I decided to make a simple HTML page to preview this kind of cover photo. Below you will find the source code to this test page:

To test out your cover photo, you would modify the img tag (.background img) to point to your large cover photo. The cover photo is 850x315px, but you'll need a larger image than that to show through to the profile picture. Using the Chrome Dev Tools, Firebug, or a similar CSS/DOM debugger you can adjust the dimensions and position of the cover image to your desired position.

Now you still would need to fire up your image editor to crop out your profile picture, which needs to be 180x180, and your cover photo which should be 850x315px. This will require keeping track of the offsets and the dimensions you've been testing with. It makes for a simple tool for seeing what kind of cool cover/profile combinations you can come up with. You can test out your profile picture by enabling the commented out profile img tag and seeing if it worked out the way you desired.

You could now, in theory, do some simple crops with your default system image editor and avoid using the heavyweight Gimp or Photoshop. However, I've found it to be tricky to get Facebook to do exactly what you'd expect with your uploaded photos. I had to do a few uploads of profile pictures before I got the satisfactory alignment which completed my Facebook cover photo hack.

Saturday, October 1, 2011

Bad Android Typography: A Tale of Text Justification

"From all these experiences the most important thing I have learned is that legibility and beauty stand close together and that type design, in its restraint, should be only felt but not perceived by the reader." —Adrian Frutiger

When speaking of typography, one must consider a multitude of variables that go into the art of arranging type to display language. There is the selection of the typeface, the point size, the line length, the line spacing, the spacing between groups of letters and the space between pairs of letters. The end goal is of course legibility, however a good designer will seek a visually aesthetic expression of the language through typography. There is an emotive response that follows the sight of visually pleasing typography, it encourages the consumption of the content. Magazines, newspapers and books all have a rich history in beautiful typography.

Figure 1: Bembo text

The Web, being the new canvas for textual content, has been slowly following the lead of its dead tree predecessors. The implementation of the W3C's Web Open Font Format (WOFF) among all modern desktop browsers gives designers limitless possibility for beautiful text design on the web. Where the Web trails behind is in text justification. Full text justification on the Web is known to be flawed (See Batchelder: Bad Web Typography). Text that is fully justified on the Web may lead to terribly inconsistent word spacing that is very noticeable to the reader.

I stand here today humbled by the task before us, grateful for the trust you have bestowed, mindful of the sacrifices borne by our ancestors. I thank President Bush for his service to our nation, as well as the generosity and cooperation he has shown throughout this transition.
Forty-four Americans have now taken the presidential oath. The words have been spoken during rising tides of prosperity and the still waters of peace. Yet, every so often the oath is taken amidst gathering clouds and raging storms. At these moments, America has carried on not simply because of the skill or vision of those in high office, but because We the People have remained faithful to the ideals of our forbearers, and true to our founding documents.

The text above is fully justified with a left and right margin of 200px. Observe the spacing of words on each line and notice the inconsistency. Text justification involves aligning to the left and the right, stretching word spaces to obtain the most uniform amount of per word spacing. When the words are too "loose" it makes for a visually displeasing effect. Hyphenation is used in typography to reduce the looseness of lines. However, browsers don't hyphenate fully justified text. There have been efforts to hyphenate text using Javascript. A script called Hyphenator.js was developed to automatically hyphenate text and is available on Google Code.

On Android, using the standard TextView widget, the problem is worse. The TextView, which is a View used to display text, does not support full justification at all. This means if you wanted to make a reader application similar to the Amazon Kindle app using a TextView, you'd get text that looked like this:

Figure 2: Android TextView left aligned text

The jagged right side of the text is quite unpleasant and there is much wasted space where more text could fit in the viewport. There is a fairly simple way to get full text justification on Android; it requires using a WebView. A WebView essentially is like embedding a chrome-less browser into your Android application. This means you get all the benefits of laying out text on the Web, as well as the aforementioned deficiency.

Figure 3: WebView with fully justified text Figure 4: WebView with fully justified text and hyphenation

The image on the left shows how mobile WebKit (the rendering engine which powers the WebView) lays out the fully justified text. The second image shows the layout hyphenated by the Hyphenator.js script. The use of two hyphens greatly improved the spacing for lines like "seen grasshoppers and" and "ladybugs. My uncle Bob". The hyphenated WebView text, while superior to the default TextView and the standard fully justified Web text, still has its flaws. The Amazon Kindle Android app does a better job of laying out the excerpt of Roger Ebert's "Life Itself: A Memoir".

Figure 5: Amazon Kindle Android Application

The Kindle app does use hyphenation although it is not shown above. It clearly has a much more uniform spacing of the words though some lines are still suspect. For example: "me. Hal Holmes has a red" stands out. The difference in the WebView layout and the Kindle layout may be attributed to the difference in font type and size, margin size, line spacing etc. The WebView examples use Helvetica and I am not sure which font is being used by the Kindle app. It is also unclear whether or not the Amazon Android app is using its own layout algorithm or is using a WebView with a hyphenation JavaScript.

So it seems that the problem with full justification on the Web plagues Android because developers must use a WebView to achieve it unless they are brave enough to roll their own text justification algorithm. In case you are interested, try solving this problem from Kleinberg's Algorithm Design concerning "pretty printing" of text:

But unless you are passioned by Markov Chains or Dynamic Programming, you'll probably stick to a WebView with text-align: justify.

[Update] I've just discovered that the new CSS3 Text W3C working draft describes support for hyphenation within the browser: http://www.w3.org/TR/css3-text/#hyphenation. In fact, it's been rolled out in the latest WebKit browsers and in Firefox. I haven't tested it out yet but the usage is fairly standard:

p {
    -webkit-hyphens: auto;
    -moz-hyphens: auto;
    hyphens: auto;
}

It's great to see typography on the Web moving forward.

Thursday, September 15, 2011

Measuring FPS On The Web

Hello world. I imagine you've all forgotten about me in my absence. No, I was not away nor ill, rather I've simply been busy with life, the universe and everything. I have written a blog post that was published on CodeAurora Forum* entitled "Measuring FPS On The Web". This post was made as a Qualcomm Innovation Center employee rather than as a rogue technologist. For those of you whom have not visited my Linked In profile, I've been working at Qualcomm for a couple years as a Graphics Engineer focusing on the Android Browser. In this post, I speak of the inherent problem with measuring frame rates in JavaScript and why today's web benchmarks for the HTML5 canvas are flawed.

CodeAurora Forum: Measuring FPS On The Web

*The Code Aurora Forum is a mutually beneficial non-profit corporation promoting open source software that enables mobile and wireless ecosystems that rely on wireless internet and cellular technology.

Monday, April 4, 2011

Google I/O Sunspider demo Round 2: iPad vs Nexus One vs XOOM FIGHT!

Google showed off its speedier Froyo V8 JS engine in a demo that put the iPad up against a Froyo running N1 at Google I/O last year:

Times have changed. Apple's added the nitro JS engine to iOS 4.3 which has significantly increased performance.

We ran the swimming Android demo on an iPad running 4.3, Nexus One running Gingerbread and a Xoom running Honeycomb.

Who wins the gold? Check the video to find out!

N.B. There was a rendering artifact with the animation on the XOOM where the screen would flicker when the swimming android reached a certain area of the page.

Sunday, February 13, 2011

Making Software: Evidence to Diffuse Programming Holy Wars

I'd like to review a new software development book that I've found particularly interesting: Making Software: What Really Works, and Why We Believe It, edited by Andy Oram and Greg Wilson. After thoroughly enjoying Oram and Wilson's Beautiful Code, I was very much anticipating this next amalgamation of the thoughts of some of the industry's leading voices. Greg was a professor of Computer Science at U of T, my alma mater, and has been a great advisor to me in my career. He currently spends his time working on Software Carpentry, an effort to teach programming practices to scientists.

Does TDD work?
Is Python better than Java?
Are good programmers really 10 times more productive?
How do you measure programming performance?
Is open source software better than proprietary software?
Do design patterns work in practice?

It is enough to whisper one of these questions around a group of programmers to begin an impassioned debate. Can anyone actually be right? How can we answer these seemingly subjective questions? Making Software attempts to find credible qualitative and quantitative evidence to answer such questions. It is no longer adequate to present arguments without showing the facts. It is time we apply the scientific method to these questions, gather some solid evidence and impartially evaluate the implications.

In 2009, Thoughtworks' Martin Fowler gave a talk entitled "Three Years of Real-World Ruby" in which he presented the results of the 41 Ruby projects his company had worked on during that period. He surveyed programmers to see how they felt about working with the language. He argued for the adoption of Ruby by showing evidence of its success within his organization. This was fascinating real-world study and is exactly what the authors of Making Software would like to see more of.

Internally many software development companies are gathering evidence of their failures and successes in hopes of finding the magical formula for developing quality software fast. Few companies are willing to release such information to the public. This is part of why we don't have an abundance of empirical studies on software development. However, in recent years, more such studies have been appearing. High quality studies are out there waiting to be referenced.

My favourite chapter of the book was Steve McConnell's "What Does 10x Mean? Measuring Variations in Programmer Productivity". McConnell, of course, being famous for the highly successful Code Complete and other popular works such as Rapid Development and Software Estimation: Demystifying the Black Art. In this essay, McConnell provides substantial evidence that the "order of magnitude" difference in programming productivity is not merely anecdotal but a provable hypothesis. I've definitely seen this difference in productivity during my time at Electronic Arts; there were numerous experienced game developers who were clearly getting things done much faster than I could. However, I would imagine that familiarity with the code base played a major factor in that particular example. More interesting are the studies where programming teams are given new projects to work on and they are more or less on an even playing field. I find this is a very hot topic as such research may reveal the productivity secrets of the elite programmers. Now that's information us mere mortals are dying to hear.

What makes this book interesting is that it attempts to treat issues in software development in the same manner that we would treat anthropological issues. The authors take on controversial topics that programmers love to argue about and give us meaningful evidence to further the debates. Making Software is a great read for all programmers, regardless of whether you are 10x more productive or not.

Saturday, January 22, 2011

SMS timestamp issues on myTouch 4G

My recent switch from the Nexus One to the myTouch 4G brought me an unexpected bug. I used SMS Backup & Restore on Android to transfer my SMS history to my new phone. I've done this before; it works great. Now all my SMS conversations were on the myTouch 4G device. Along with T-mobile's Android skin comes a new messaging app that is far from an improvement on the stock one. In fact, it seems to come with a weird message timestamp bug that has annoyed me enough to make me fix it myself.

Here's the bug: the messaging app shows incoming SMS's as being received 5 hours earlier than the current time. So, in an SMS conversation, all incoming messages will be grouped together and all my outgoing messages follow. Makes the conversation view pretty useless.

When I first powered on the myTouch 4G, there was a notification asking me to change my timezone; I did this. My timezone is EST, a UTC time offset of -5 hrs. So it would seem that incoming SMS timestamps are stored as UTC and interpreted as EST and outgoing are stored as EST. Interestingly enough, when I installed an alternate messaging app, Handcent, it shows the conversations in the correct order, but the times reflect the same issue.

This probably indicates that Handcent is not sorting by the SMS timestamp but by the database ordering of the messages. Okay, so now we have a reasonable hypothesis: incoming and outgoing SMS timestamps are interpreted with different timezones. The issue has corrupted the messages in the database since my switch from the Nexus One.

There are different approaches to fixing this. One is to modify the database in the mmssms.db file on the Android filesystem. I'll pass on the SQL. Another is to use the SMS Backup & Restore app to export the SMS's as an XML file and modify the timestamps in the file and reload them into the phone --at this point you should be picturing an intense programming and blogging scene à la "The Social Network". But unlike Zuck, I'm a real programmer so I'll use Python instead of PHP. Burn. But seriously folks, I could have just as easily done this in PHP. I just prefer Python.

The XML file produced by the backup looks like this:

<smses>

</smses>

According to the SMS Backup & Restore webpage, the date is stored in milliseconds since the epoch (January 1st 1970). The type attribute is either 1 or 2; received or sent. Let's look at the timestamps for the 4 messages from the screenshots: 1295532538000, 1295535724000, 1295550555219 and 1295558651937.

We'll make use of the Python time module to inspect these timestamps. The time.gmtime method converts a time expressed in seconds since the epoch to a struct_time in UTC. The time.strftime allows us to convert that into a human readible format. Our timestamps are stored in milliseconds so we'll need to divide them by 1000.

The two incoming timestamps:

>>> time.strftime("%a, %d %b %Y %H:%M:%S", time.gmtime(1295532538000 / 1000))

'Thu, 20 Jan 2011 14:08:58'

>>> time.strftime("%a, %d %b %Y %H:%M:%S", time.gmtime(1295535724000 / 1000))

'Thu, 20 Jan 2011 15:02:04'

The two outgoing timestamps:

>>> time.strftime("%a, %d %b %Y %H:%M:%S", time.gmtime(1295550555219 / 1000))

'Thu, 20 Jan 2011 19:09:15'

>>> time.strftime("%a, %d %b %Y %H:%M:%S", time.gmtime(1295558651937 / 1000))

'Thu, 20 Jan 2011 21:24:11'

Looking at older messages from my Nexus One days, I can see that the times are actually stored in the database as UTC and the -5 is applied by the messaging app. Makes sense. The outgoing messages are correctly saved with a UTC timestamp, but the incoming messages are stored with the EST time. The T-mobile and Handcent messaging apps correctly apply the -5 to the timestamps when displaying the formated time. The bug is actually that incoming messages are stored in the database with the EST timestamp instead of the UTC one. This makes it so the messaging apps show incoming messages as 5hrs earlier than the outgoing ones. To resolve this for all the messages I've received since I switched to the myTouch 4G, I simply have to add 5 hrs to the timestamps of all incoming messages starting at the switch date: January 6th 2010, 1294290000000 in milliseconds since the epoch.

Code... code... code...

#!/usr/bin/python

from xml.dom.minidom import parse

import os
import sys
import time

START_TIMESTAMP_SECS = 1294290000000
HOUR_TO_MILLISECS = 60 * 60 * 1000
RECEIVED, SENT = (1, 2)

def format_time(timestamp_in_ms):
    return time.strftime("%a, %d %b %Y %H:%M:%S",
            time.gmtime(timestamp_in_ms / 1000))

def convert_est_to_utc(timestamp_in_ms):
    return timestamp_in_ms + (5 * HOUR_TO_MILLISECS)

def replace_timestamps(document):
    smses = document.getElementsByTagName('sms')
    for sms in smses:
        received = int(sms.getAttribute('type')) == RECEIVED
        date = int(sms.getAttribute('date'))

        if received and date > START_TIMESTAMP_SECS:
            sms.setAttribute('date', unicode(convert_est_to_utc(date)))

def main():
    if (len(sys.argv) < 2):        sys.exit('Usage: %s sms_file' % os.path.basename(__file__))

    sms_file = sys.argv[1]

    document = parse(sms_file)
    replace_timestamps(document)
    print(document.toprettyxml(encoding='utf-8'))


if __name__ == '__main__':
    main()

See http://pastebin.com/SmgkKcsR.

This code takes in the backup SMS XML file and prints out an updated XML document. Using the SMS Backup & Restore app I restore to the output XML. Et voilà!

It would be nice to know exactly where this bug originated. I have not seen this issue on the Nexus One. It must be a bug in the T-mobile software layer. I haven't solved the problem of new incoming SMS's having the incorrect timestamps; I've only fixed the timestamps of all the messages I've received so far. For this and a bunch of other reasons, I'm going to switch back to the Nexus One until I get Cyanogen Mod on this myTouch 4G.

This scene will be an awesome addition to the movie they make about my life after I become a billionaire entrepreneur. It might win a few Golden Globes.

Monday, September 13, 2010

The Life and Times of an Icon URI Scheme

It all began with a bug report complaining about the then dry and unvarnished FTP and file directory listing pages in Chrome [1]. The bug compared Chromium's vanilla listing pages to Firefox's respective pages; clearly Mozilla had put more effort into prettying up these pages.

Figure 1: Firefox 3.5.3 file directory listing page

Figure 2: Chrome 4.0.221.6 file directory listing page

One of the most significant shortcomings of this page was the lack of icons for files and folders. In fact, folders in Chromium's listing pages were only distinguishable from files by their trailing slash.

I decided to tackle this bug as I really like Firefox's presentation of these pages. Out of curiosity I took a look at the source code for Firefox's listing page and found out that they are using a custom URI scheme moz-icon to specify the icon images in the listing page HTML.

/**
* nsIIconURI
*
* This interface derives from nsIURI, to provide additional information
* about moz-icon URIs.
*
* What *is* a moz-icon URI you ask?  Well, it has the following syntax:
*
* moz-icon://[ |  | ]? ['?'[]]
*
*  is a legal file: URI spec.  You only need to specify a file: URI inside the icon
* if the file you want the icon for actually exists.
*
*  is any filename with an extension, e.g. "dummy.html".
* If the file you want an icon for isn't known to exist, you can omit the file URI, and just
* place a dummy file name with the extension or content type you want: moz-icon://dummy.html.
*
*  is of the format:   stock/
*
*  is a valid icon name, such as 'ok', 'cancel', 'yes', 'no'.
* XXXcaa Should these considered platform dependent or can we share and document them?
*
* Legal parameter value pairs are listed below:
*
*   Parameter:   size
*   Values:      [ | button | toolbar | toolbarsmall | menu | dialog]
*   Description: If integer, this is the desired size in square pixels of the icon
*                Else, use the OS default for the specified keyword context.
*
*   Parameter:   state
*   Values:      [normal | disabled]
*   Description: The state of the icon.
*
*   Parameter:   contentType
*   Values:      
*   Description: The mime type we want an icon for. This is ignored by stock images.
*/

Interestingly enough, this scheme is web accessible --meaning that any web developer can use this scheme as the src for their Image objects in their HTML and JavaScript code. What's great about this scheme is that it allows developers to present platform specific icons to users. For example, <img src="moz-icon://.zip?size=16" /> would resolve the icon used by the operating system for the zip filetype.

Chromium also has a similar URI scheme for retrieving platform icons. If you look at the downloads DOM UI page, Chromium uses chrome://fileicon with a file path query to retrieve the icons for respective downloaded items. This scheme is not web accessible. The chrome:// URLs have special security privileges in Chromium that would prevent us from exposing the chrome://fileicon scheme in the manner of moz-icon. We could, of course, create a new similar scheme that would be web accessible for the use of developers and file listing pages alike.

Discussions in the Chromium-dev mailing list led to a suggestion that this "icon" URI scheme should become an open standard that every browser could implement. So I decided I would give this standardization business a shot.

The process for registering a URI scheme works as such:

Propose the scheme to the Public Webapps W3 mailing list [2] for feedback
Write a URI scheme registration template (usually contained in an Internet Draft) describing how the new scheme works. Internet Drafts must conform to the Guidelines for the Authors of Internet Drafts [3]. The registration template must conform to the Guidelines and Registration Procedures for New URI Schemes [4]
Send a copy of the template (or containing document) to the URI review mailing list [5] as well as any other relevant mailing list requesting a review
Once any review issues have been addressed, submit the document to IANA [6] specifying whether provisional or permanent registration is required.
If all goes well the URI will get registered and appear on the IANA registered URI schemes page [7]
Profit!

The entire process is structured and very iterative. Peer reviews are required to assure that the new scheme will be useful, that it is well specified and that all security risks are considered.

After this long and arduous process, I managed to get provisional registration for the Icon URI scheme [8]. W00t! You'll find it listed on the IANA URI Scheme page at least until December when it expires.

Well it's nice to have an Internet Draft for the Icon URI scheme but it would be nicer if we had an implementation of the scheme running in a modern browser.

So I wrote a prototype implementation [9] in Chromium to help move the scheme forward. Unfortunately, there were concerns that added potential security risks of this scheme outweigh the benefits. Security concerns were addressed in the draft, however it would be tricky to assure that this scheme could not be used to determine what applications a user has installed by some sort of user interaction attack. With Chromium being a security first type of browser, it would seem that the shiny new web accessible Icon URI scheme may not be the best fit. Sigh.

Well that was a whole lot of yak shaving! Didn't this start with a simple bug request for icons in file listing pages?

I plan to let the Icon URI scheme expire at the end of the year in light of Chromium not using it. It would have been a nice feature, but it was hardly a necessity. The original use case bug for this scheme can be resolved in other ways. I wrote a patch that adds icons to the Chromium file and FTP directory listing pages. There are 3 types of icons: file, folder and parent folder. The icons are hard coded as data URI into the HTML.