GWT Goes Bidirectional!

Over 100 million web users speak languages that are written right-to-left, such as Arabic, Hebrew and Persian.

Right-to-left language support is not new to GWT. GWT makes it easy to build applications localized to both right-to-left (RTL) and left-to-right (LTR) locales, mirroring the layout of the page and its widgets so that an RTL-language page flows right-to-left. GWT even makes it easy to mirror those “handed” images that need to point in a direction that makes sense within the page. So, what’s the problem?

The Challenge of Bidi Text

An application localized to an RTL language is often used to access both RTL and LTR data, simply because data in some left-to-right languages like English is so widespread. For example, an Arabic movie review application may need to display Latin-script movie titles. Conversely, native RTL-language speakers often choose to use an English version of an application, but still use it to access and enter RTL data too. The point is that the data should be displayed in its own direction, regardless of the context’s direction. As a result, the text of the page as a whole goes in both directions; the page’s text is bidirectional, or “bidi”.

Unfortunately, inserting an opposite-direction phrase into your page without explicitly indicating where it begins and ends, often garbles it and/or the text surrounding it, putting the words and punctuation in the wrong order. For example, in an RTL context, “10 Main St.” is displayed incorrectly as “.Main St 10”. For short, we call the capability to display opposite-direction text correctly “bidi text support”.

The good news is that GWT has recently been enhanced with some powerful features for supporting bidi text. They allow your application to correctly display and enter opposite-direction text with very little extra effort.

Built-in Bidi Text Support in TextBox and TextArea

Since GWT 2.1 release, the TextBox and TextArea widgets are capable of automatically adjusting their direction as text is being entered (GWT Showcase example). This feature is enabled by default when at least one of the application’s locales is RTL, and otherwise can be enabled manually.

Built-in Bidi Text Support in Other Widgets

As of GWT 2.2 (to be released soon), several widely used widgets such as Label, HTML, Anchor, Hyperlink and ListBox gain built-in bidi text support by exposing two new interfaces:

  • The HasDirectionalText interface allows declaring the direction of text whose direction is known in advance. For example, a Label holding a phone number is always LTR, even in RTL locales, and must be declared as such to prevent garbling. You can do this by passing an extra parameter to either the constructor:
    Label label = new Label(phone, Direction.LTR);
    or to setText():
    label.setText(phone, Direction.LTR);
  • The HasDirectionEstimator interface allows widgets to cope with text whose direction is unknown (for example text previously entered by users). When direction estimation is enabled, the widget estimates the direction of the text content at runtime, and sets its display direction accordingly. Note that usually there’s no need to use this feature for boilerplate text (i.e. messages), since such text usually matches the overall page direction.

In the following example, an imaginary application collects reviews of books from the users. A user can add to the repository a new book with its name and review. To view the review of a specific book, one can select its name from a ListBox holding the books’ names. Note that books’ names may be of both directions, especially in RTL locales.

public class BookReviewApp() {
  private ListBox bookNamesListBox;
  …
  public BookReviewApp() {
    // Enable bidi support.
    bookNamesListBox.setDirectionEstimator(true);
    …
  }
  public addBook(String bookName, String review) {
    // ListBox item’s direction will be set automatically.
    bookNamesListBox.add(bookName);
    …
  }
  …
}

Bidi and Messages

BidiFormatter is a new class providing bidi text support primitives like estimating a string’s direction and wrapping it in HTML for correct display in a potentially opposite-direction context. The new built-in bidi text support features in the widgets mentioned above use BidiFormatter to do their stuff. Sometimes, however, you may need to use BidiFormatter directly. It is particularly useful with message placeholder values. While the message as a whole is usually localized to the user interface language, placeholder values may be in an arbitrary language and thus may have the opposite direction. Use BidiFormatter’s methods to wrap such values before inserting them into the message. A comprehensive example of using BidiFormatter with messages is available in the GWT Showcase.

Google Places Hack: Barnacle Marketing Goes Black

Update 8:00 am: Steve points out below that this is not just a hack but a bug in how Google handles the URL from the Places Page. Thus even when a Places Listing points to the specific directory page for a business, the Google SERP can interpret and rank the URL based on the higher level page in the directory. So while it can be a black hat technique, it can also be a Google induced error and the listing owner could be totally unaware of the reasons. My apologies to the Portland Mover that I used as an example.

Whenever Google changes things around, the bottom feeders are never far behind, always looking for angles and cracks in the system. Google Places Search, introduced October 27, is no exception.

It didn’t take the spammers long to find a way to get instant results. It was brought to my attention and the details figured out by Yam Regev (Puresheer). This hack has started to show for front pages local organic blended (LOB?) results across the country. It is easy to spot as the URL associated with a LOB result is usually from deep within a directory and the listing is claimed.

Here is a screen shot for the search local movers Portland Oregon:

Note that in the screenshot above the business links to http://www.123movers.com/movers/Portland_OR/z-97201/s-local_movers/results.html, a general business directory page

The technique is a variation on barnacle marketing that attempts to leverage the strength of an existing directory to highlight your business. While it doesn’t give you any web traffic, it does put your phone number front and center on the main SERPS. Because of this limitation it is a technique more commonly seen in service industries (you know the ones: locksmiths, movers, limos etc) with little or no bricks and mortar.

How does it work?

The Places search ranking algo has always had a strong component predicated on the authority of the website referenced in the Places listing. This was why, as Chris Silver Smith pointed out, a Wikipedia URL was a successful Maps hack.

However with the rollout of Places Search, a generally strong website was not enough. Google had rejiggered things so that more emphasis was placed on not just a strong, authoritative page but one that did well on specific local searches.

To execute this current hack, you need to find a search on which a directory page (or competitors page not associated with a Places listing) shows well organically, typically above the LOB result (See this search as an example- note the high ranking Superpages URL). Take the exact URL and use it in your Places Dashboard. Your listing will take on the relative strength of the organically successful page showing the Title Tags, Description and URL from the poached page but showing the phone number and address of the local business.

It could be that Google is already starting to fix this. I noticed that a search for Locksmith Palo Alto that returned one of these hacked results as recently as January 1 has been returned to its native state (see shot above). But the ability to use the technique to leach benefit from even a competitor’s site should make this gaping hole a priority fix for Google.

Mission Blue: Tracking the gulf oil spill recovery effort

Last April, we were all very aware of the major oil spill in the Gulf of Mexico. There were a variety of tools released to help track the spill, including aerial imagery, visualization tools, EPA data and much more.

However, now that the leak has been stopped for a while, people are turning their attention elsewhere. That’s where Mission Blue comes in. Their primary goal is to “raise public awareness and move people to help protect this vital natural resource”, and in this case they’re working to “identify areas with potential for Gulf ecosystem recovery”.

Because the impact of the oil spill is still under debate, they’re out on an expedition into the Gulf to see how the area is recovering from the spill. While they’re out there, information and videos are being shared as often as possible.

mission-blue.jpg

If you have the “Places” layer turned on in Google Earth, you can click the blue ship icon just outside of Pensacola, Florida. Alternatively, you can simply download this KML file to view the expedition. Through the KML you’ll find photos, videos, updates and links to updates on the National Geographic Mission Blue blog here.