2009-10-12

「讓 AJAX 網頁可以被網路爬蟲讀取」的建議書

原文網址: http://googlewebmastercentral.blogspot.com/2009/10/proposal-for-making-ajax-crawlable.html

今天,我們很興奮地提出「讓以 AJAX 為基礎的網站可以被網路爬蟲讀取」的規格建議書。這將有益於網站管理者和使用者在製作豐富、互動的 AJAX 網站時,可以讓所有的搜尋引擎讀取到想要被搜尋到的部份。我們相信,這類的內容如果可以被網路爬蟲讀取以及被索引,將會讓網路有長足的進步。

當 AJAX 網站受到使用者歡迎的同時,搜尋引擎並無法讀取這些網站的內容。我們的最新調查顯示:有 70% 的網站在 form 或是其他地方使用了 JavaScript。當然,大部分的 JavaScript 並不是 AJAX,但是如果搜尋引擎可以處理、索引 AJAX 的內容,開發者就可以在他們的網站上做出更多豐富的內容,而搜尋引擎依然找得到。

下面是這份建議書希望達到的目標:

  • 當網站成長時,所需要的變動是最小的
  • 使用者跟搜尋引擎看到的是相同的內容(無須 cloaking)
  • 搜尋引擎可以直接讓使用者導向到 AJAX 的 URL(而不一個靜態複製網頁)
  • 網站擁有者有方法可以驗證他們的 AJAX 網站顯示正常,也因此網路爬蟲可以讀取所有的內容。

下面是我們初步建議書當中,搜尋引擎處理、索引 AJAX 內容的方式:

  • 把 stateful 的 AJAX 頁面的 URL fragment 稍作修改:
    無論何時,直接讀取 stateful 的 AJAX 頁面都會顯示一樣內容。這些頁面可以變成搜尋結果。我們想把像這樣的 URL「http://example.com/page?query#state」 加上一個 token 成這樣「http://example.com/page?query#[FRAGMENTTOKEN]state」以作識別。在檢視網路上的 URL 之後,我們建議使用驚嘆號「!」。在搜尋結果當中顯示的 URL 會像這樣「http://example.com/page?query#!state」。
  • 使用 headless 瀏覽器,讓你的 web server 有一個 HTML 的 snapshot。
    headless 瀏覽器用來讀取 AJAX 頁面,然後最終瀏覽器的結果產生 HTML。只有特別標記的 URL 才傳給 headless 瀏覽器處理。在 server 端作這件事情時,網站擁有者可以控制 HTML  的產生,也就可以輕鬆地驗證所有的 JavaScript 是否正常執行。HtmlUnit —open source、沒有 GUI 的 Java 程式—就是一個 headless 瀏覽器的例子。
  • 允許搜尋引擎的爬蟲去讀取有對 state 作 escape 的 URL
    URL fragment 並不會隨著 request 送到 server 去,所以需要稍微變動 URL 以讀取該頁面。同時,這也會讓 server 啟用 headless 瀏覽器去產生 HTML 而不是傳回有 JavaScript 的頁面。此外,既有的 URL—使用者看到的那些—則會用平常的方式處理,不會啟用 headless 瀏覽器。我們建議 escape state 資訊,然後把它加到 query parameter 當中,變成一個 token。用上頭的例子,URL 可能會長這樣:「http://example.com/page?query&[QUERYTOKEN]=state」。依照我們對現在網路上 URL 的分析結果,我們建議用「_escaped_fragment_」來作為 token。建議的 URL 會變成:「http://example.com/page?query&_escaped_fragment_=state」
  • 在搜尋結果當中,顯示原來的 URL
    為了改善使用者經驗,這會讓使用者直接連回 AJAX 頁面。搜尋結果當中顯示原始的 URL(如前面的例子:http://example.com/page?query#!state)就可以做到。搜尋引擎可以檢查被 Googlebot 索引的文字,是否跟使用者看到的一樣(或是子集)。



總結來說,如果一個 stateful 的 URL,例如:「http://example.com/dictionary.html#AJAX」,同時給使用者或網路爬蟲使用的 URL 會變成「http://example.com/dictionary.html#!AJAX」,而可以被爬蟲爬的 URL 會變成「http://example.com/dictionary.html?_escaped_fragment_=AJAX」,但使用者存取還是用「http://example.com/dictionary.html#!AJAX」

2009-10-07

GWT Animation 再探

在〈GWT Animation 初探〉當中,程式已經能讓畫面看起來有動畫的效果,「表面上」要怎麼使用 Animation 是沒有問題了;不過這樣子有些無趣,還是要殺進去 Animation 來瞭解這一切背後的內幕(?)。

起點當然是 Animation.run(),沒有呼叫這個 method,是不會有什麼反應的。run() 有兩個,run(int duration, double startTime) 的 duration 是 Animation 預計持續作用的時間;startTime 是預計執行的時間。為甚麼用 startTime 的 data type 是 double 呢?這點在 Animation 不算是有用到的 Duration.elapsedMillis() 可以找到答案:
Returns the same result as System#currentTimeMillis(), but as a double. Because emulated long math is significantly slower than doubles in web mode, this method is to be preferred.
因為在瀏覽器上頭,使用 double 處理起來比模擬 long 還要快得多(btw... 為甚麼 Animation 只用了 Duration.currentTimeMillis() 取得時間,而沒有用 Duration.elapsedMillis() 去計算時間差,這我一直想不透 XD)。另一個 run(int duration) 其實還是呼叫 run(int, double),只是自動以當下時間傳給 startTime。

回到 run(int, double) 的內容,關鍵點在於下面這段
if (animations == null) {
   animations = new ArrayList();  //point-A
   animationTimer = new Timer() {
    @Override
    public void run() {
     updateAnimations();
    }
   };
  }
  animations.add(this);
這邊要回頭看一下 Animation 的資料結構。講起來有點饒舌。大致上來說,Animation 有一些 static 的 field 跟 method,目的是統一處理系統當中所有的 Animation object(程式碼 point-A)。這裡也可以看到,其實 Animation 裡頭是用 Timer 來實做的。Timer 的細節得先跳過,這裡只要知道看到 animationTime.schedule(int delayMillis) 就表示隔了 delayMillis 個 ms 就會執行 updateAnimations() 的內容,而 updateAnimations() 會呼叫 update()。那麼,勢必有需要好好看一下 update() 的內容:
private boolean update(double curTime) {
  boolean finished = curTime >= startTime + duration;
  if (started && !finished) {
   // Animation is in progress.
   double progress = (curTime - startTime) / duration;
   onUpdate(interpolate(progress));
   return false;
  }
  if (!started && curTime >= startTime) {
   // Start the animation.
   started = true;
   onStart();
   // Intentional fall through to possibly end the animation.
  }
  if (finished) {
   // Animation is complete.
   onComplete();
   started = false;
   running = false;
   return true;
  }
  return false;
 }
裡頭依照不同的狀況,呼叫了 onUpdate(), onStart()onComplete()。嗯?為甚麼只有 onUpdate() 是 abstract 的呢?因為這兩個到最後還是去呼叫 onUpdate(),progress 的值給 0 表示剛開始、給 1 表示結束。接下來就是最詭異的部份啦,傳給 onUpdate() 的數值,居然還要經過 interpolate() 的計算,這又是為甚麼呢?根據 javadoc 的說法:
Interpolate the linear progress into a more natural easing function.
看個對照圖可能比較好懂:

在開始跟結束的部份比較緩和,或許這樣比較符合人類視覺觀點?總之,這是為甚麼 Animation 的 javadoc 會說「at a non-fixed frame rate」了。(順帶提一點,相同的 duration,呼叫 onUpdate() 的次數應該會一樣,但是 progress 值會有差異。這應該是 Timer 先天上無法很精準的缺陷?)

看到這邊,Animation 應該可以說沒有秘密了。剩下來就是如何運用的問題了...... [遠目]

2009-10-05

GWT Animation 初探

Animation 是 GWT 內的一個 class,名字取的很美妙,實際上是在做什麼的呢? GWT 的 showcase 給了一個示範,不過裡頭的程式碼實在有點古怪,姑且直接來看 1.6 版的 API doc 怎麼說。
An Animation is a continuous event that updates progressively over time at a non-fixed frame rate.
哈哈... 根本就是騙人的,哪來什麼動畫 [笑]。簡單地說「Animation 是一個會持續要求 update 動作的物件。而間隔的時間是不固定的。」阿?這什麼鬼?還是用程式碼來說明好了...

import com.google.gwt.animation.client.Animation;
import com.google.gwt.user.client.ui.AbsolutePanel;
import com.google.gwt.user.client.ui.Label;

public class HelloAnimation extends AbsolutePanel{
 private Label hello = new Label("Hello Animation");
 private final int WIDTH = 800;
 private final int HEIGHT = 200;
 
 public HelloAnimation(){
  this.setPixelSize(WIDTH, HEIGHT);
  this.add(hello); //要先加上去,才有辦法移動
  Player player = new Player(this);
  player.run(5*1000); //point-A
 }
 
 public void playOneFrame(double progress){
  this.setWidgetPosition(hello, (int)(WIDTH*progress), HEIGHT/2);
 }
}

class Player extends Animation{
 HelloAnimation target;
 
 public Player(HelloAnimation t){
  target = t;
 }
 
 @Override
 protected void onUpdate(double progress) {
  target.playOneFrame(progress);
 }
}

只要 new 一個 HelloAnimation,然後加到 RootPanel 上頭去,就會看「Hello Animation」從畫面左邊跑到右邊。(至於最後「Hello Animation」突然換行的狀況,先跳過... XD)

裡頭兩個 class 分別負責兩件事情。HelloAnimation 負責畫面顯示的部份,直接 extends AbsolutePanel,搭配 AbsolutePanel.setWidgetPosition() 就可以很快速地設定 widget 的位置,這樣在上頭的東西「動」起來就相對方便。playOneFrame() 這個 method 就是在處理這件事情,至於 progress 這個參數的作用,就必須回到 Animation(也就是範例程式裡頭的 Player才能說明。

Player 這個 class 其實很簡單,extends Animation 之後,只有一個 method 必須實作,就是 onUpdate()。這個 method 就是 API 提到的效果,當 Player 起作用的時候,onUpdate() 就會持續地被呼叫、並且給予不同的參數 progress 值,值域介於 0~1 之間,會隨著時間會越來越大,乘上 100 就是完成度啦,因為實際負責「動」的物件是 HelloAnimation,所以在呼叫 HelloAnimation.playOneFrame() 時候就原封不動地傳進去。這個參數在製作像動畫這種東西時,就很方便,因為 Animation 幫你算好 progress,不用自己動手。像這個例子當中,「Hello Animation」要在指定的時間內橫越指定的寬度,但是在撰寫 playOneFrame() 時完全不用理會「指定的時間」有多長,只要把寬度乘上 progress 就解決了。現在動畫的長度是五秒鐘(程式碼 point-A),要改成兩倍慢 or 兩倍快,就只要在 player.run() 時給 10 秒 or 2.5 秒就可以了。

看到這裡,是不是覺得 GWT 設計的很好、使用起來很簡單呢? [奸笑]

至於 Animation 的細節,我們下次再談(初探嘛...)