是在新瀏覽器窗口中打開鏈接？還是在原有窗口中打開鏈接？看似不是問題，但實際上是個很重要的事兒；似乎已經(jīng)有了權(quán)威的論斷，但權(quán)威的論斷還并不完美。

目前有三種做法：
　1.始終在新窗口中打開
　2.始終在同一窗口中打開
　3.索引頁之間在同一窗口中打開，具體的信息頁在新窗口中顯示。
　　

第一種和第二種做法比較容易使用戶建立起正確的心理模型，也就是說，用戶很容易理解，但是這兩種做法都存在一定缺陷。

第一種做法的缺陷：只要點擊就會打開一個新的瀏覽器窗口，一種類似于病毒的行為方式，瀏覽這樣的網(wǎng)站，很快用戶電腦的任務欄上就會充斥大量的任務標簽，標簽過多，使得標簽上無法顯示文字，無法識別。使用這樣的網(wǎng)站，用戶需要時常關閉一些已經(jīng)瀏覽過的窗口。

第二種做法是一些可用性大師所倡導的，比如Jakob Nielsen在他的很多文章里都提到這個問題，他的建議是“除去PDF之類的“non-Web documents”，所有的鏈接都應當在同一瀏覽器窗口中打開。”在他所進行的調(diào)查中，網(wǎng)頁設計者將鏈接設置為在新窗口中打開的理由是：這樣做可以留住用戶（Designers open new browser windows on the theory that it keeps users on their site.）。

但這種始終在同一窗口中打開的方式卻并不是最理想的。當我在瀏覽Nielsen的www.useit.com網(wǎng)站時，我的做法經(jīng)常是將自己感興趣的多篇文章先都在新窗口中一一打開，然后關掉索引頁，再逐篇閱讀。因為我會擔心也許幾分鐘后我會被其他事情打斷，再回到電腦前的時候可能就會忘記再拜讀他的其他文章了，即使我當時有充足的時間慢慢瀏覽，我也會覺得如果現(xiàn)在先進入到一篇文章中閱讀，讀完后再返回原先的索引頁，查找下一篇文章，那樣的話，我需要再次面對索引頁，即使我不久前見過這個界面，它對于我來說仍舊是陌生的，至少不是十分熟悉，仍舊需要花費時間了解、認識這個頁面，我希望只了解一次索引頁就找到所有我需要的鏈接。線性的，反復操作會降低效率。

“用戶總是把絕大部分時間花在其他網(wǎng)站而不是您的網(wǎng)站上”---《專業(yè)主頁設計技術(shù)》Jakob Nielsen著。用戶總是在面對新的界面，即使不是全新的，至少也不是他（她）十分熟悉的，那么對一個界面的認識過程就確實存在，花費時間也確實存在，能減少認識界面的次數(shù)可以提高效率。

我相信這種需求不是我個人獨特的怪異的行為習慣，更不是為了反駁Nielsen而特意編造出來的，這種行為習慣是來自于生活實踐中的：在你編輯一個頁面的代碼時，如果需要你給一篇共有20段的文章每一段都加上p標記（即，在每一段文字的開頭加上“<p>”,在每一段的結(jié)尾加上“</p>”），你會怎么操作呢？剛一開始，也許你會逐段的添加，但是很快你就會發(fā)現(xiàn)，如果先復制了“<p>”然后逐個選擇每段的開頭位置進行粘貼，再復制“</p>”進行類似的操作，效率會高的多。類似的經(jīng)驗產(chǎn)生了習慣的行為模式，“將相同的操作集中起來完成是高效的”。應用這種經(jīng)驗出現(xiàn)了社會分工，“一個人只負責整個生產(chǎn)流程中的一部分，比每個人都負責整個流程效率高?！边€是應用這種經(jīng)驗，出現(xiàn)了上面描述的那種網(wǎng)頁操作行為。因此，“在新窗口中顯示”這個需求是存在的，也是合理的，當然，“在同一窗口中顯示”的需求也是存在的，比如，在一個注冊流程中，當用戶要進入第二步的時候，通常不需要保留第一步的頁面。

在設計頁面的過程中，我們往往需要構(gòu)造用戶的“任務流”，“用戶希望先做什么，接下來，用戶需要做什么了，之后還要做什么...”根據(jù)這樣的任務流設計相應的頁面，然而從上述的“窗口問題”我們可以看到，任務流并不總是存在的，更準確的說，用戶的任務并不總是在一個頁面中就能夠完成的。當用戶的下一步任務需要在多個窗口中完成時，就需要打開新窗口了。一個典型的例子是google的搜索結(jié)果頁，恐怕很少會有可用性專家職責google的搜索結(jié)果頁每一個結(jié)果都是在新窗口中打開的，那么“所有的鏈接都應當在同一瀏覽器窗口中打開”這一準則是不是還應該再加一個google的限制條件呢？會不會再有第二個google呢？這個準則的適用范圍到底有多大呢？誰能保證互聯(lián)網(wǎng)的發(fā)展不會催生出更多的新服務呢？這些新服務又有多少應該被劃定在這一規(guī)則之外呢？

我質(zhì)疑Nielsen得出此結(jié)論的過程和理由，我相信在新窗口中打開的設計不僅僅是為了留住用戶，但并不反對“鏈接應在同一窗口中顯示”這個結(jié)論，“在新窗口中打開”與“在同一窗口中打開”相比較，“在同一窗口中打開”能夠保證一個頁面既可以在原窗口中打開也可以在新的窗口中打開，只要用戶在點擊之前按下shift鍵或右鍵選擇“在新窗口中打開”，而“在新窗口中打開”不征求用戶的意見，總是在新窗口中打開。相比之下“在同一窗口中打開”為用戶提供了更多的選擇，更大的自由度，同時也要求用戶付出更大的操作成本。

　　為了能在適當?shù)臅r候打開新窗口顯示，出現(xiàn)了第三種顯示規(guī)則，但是第三種做法本身又存在缺陷：由于對“索引頁”的定義并不十分明確，使得這種方式的應用并不規(guī)范，在用戶看來，這種方式更象是無規(guī)則的，用戶很難在使用過程中注意到這種顯示規(guī)則，也很難確切的猜到設計規(guī)則。

始終在新窗口中打開是一種帶有互連網(wǎng)風格的設計，互連網(wǎng)在開始之初，主要的功能就是以索引的方式展示信息，這對于交互的要求相對是比較低的；始終在同一頁面種顯示是一種帶有軟件風格的設計，在通常的軟件中，用戶的使用狀態(tài)是不斷的完成一個個任務流，用戶有著相對明確的目的性，當然，這對于交互設計的要求是高的，設計師需要清楚用戶隨時的需求。隨著互聯(lián)網(wǎng)的發(fā)展，在網(wǎng)站所能實現(xiàn)的功能越來越復雜，網(wǎng)上交易、在線銀行、網(wǎng)上社區(qū)...這使得web界面需要更接近軟件設計才能滿足這些要求，于是在同一頁面中顯示方式表現(xiàn)出它的合理性。網(wǎng)站對交互設計的需求是復雜的，不同類型的網(wǎng)站的交互應用水平是不同的，即便是同一網(wǎng)站內(nèi)，不同的欄目，交互應用水平也是存在很大差異的，所以選擇那種顯示方式才會始終不能達成共識。

我曾經(jīng)有意識的注意過，在即將點擊開一個鏈接時我自己的心理，到底是希望在原有頁面中打開呢，還是在新頁面中打開，實際的結(jié)果是，有時我希望在同一頁面中打開，而有時我希望在新頁面中顯示。這樣的現(xiàn)象說明，即便進行更大規(guī)模的用戶調(diào)查也不能在“同一頁面中顯示”和“總是在新頁面中顯示”兩者之中選擇出一種，用戶群的需求不是單一的，甚至對于同一用戶來講，這種需求也是變化的。

面對“窗口問題”，新的瀏覽器給出了新的解決方法。在Maxthon（MYIE2）中，在釋放鼠標左鍵之前，將光標拖動，離開原來鏈接的位置，則可以將原本在同一窗口內(nèi)打開的鏈接在新窗口內(nèi)打開，這種拖動操作代替了IE瀏覽器的按下shift的操作，用戶省去了左手的配合操作，并且比點擊右鍵，在菜單中選擇效率要高很多，這種方式不僅給“窗口問題”一個好的解決辦法，同時也為web界面的交互設計提供了一個好的思路。web界面由于受技術(shù)的限制，很多圖形操作系統(tǒng)中的操作都無法實現(xiàn)，比如拖動、圈選、左鍵雙擊...web的交互設計也因此受到了很多限制，Maxthon解決“窗口問題”的辦法給出了這樣一個思路：將web技術(shù)上的問題留給瀏覽器，瀏覽器是客戶端軟件，能夠?qū)崿F(xiàn)圖形用戶界面的全部功能，整個web界面的交互功能由界面本身和瀏覽器共同實現(xiàn)，對于“窗口問題”，一個始終在同一窗口中打開的網(wǎng)站加上Maxthon瀏覽器就是個不錯的組合。不過，Maxthon的這種解決辦法并不是完美的，window界面中對于鼠標點擊的操作是這樣設計的：對于web上的鏈接、表單中的各種元件，比如按鈕、單選按鈕、復選按鈕...“如果用戶在鼠標按鍵按下時，移動光標離開控件，那么控件就會回到未按狀態(tài)。盡管知道釋放鼠標按鍵為止，輸入焦點仍然在控件上。但當釋放鼠標按鍵后，輸入焦點切斷了，任何事兒也沒發(fā)生。如果用戶改變了主意，這也是一條方便的逃逸途徑?！?--《ABOUT FACE 2.0》 而在Maxthon中，對文字鏈接的這種操作被賦予了新的功能，表單元件仍然不變，這樣一來，第一，文字鏈接失去了這種“逃逸途徑”，第二，這種拖動的操作在Maxthon中有了兩種不同的功能，對于表單控件是“逃逸途徑”而對于文字鏈接是在新窗口中打開，用戶需要時時牢記才能確保操作正確。

目前最為可行的方法仍舊是在同一頁面中打開，使用這種方式的前提是，確信該web界面所面對的用戶群都知道在按住shift鍵的狀態(tài)下點擊鏈接，鏈接所指向的內(nèi)容會在新頁面中打開，至少也應該知道在鏈接上點擊右鍵可以選擇在新窗口中打開。這樣，用戶在希望打開在新窗口中打開鏈接內(nèi)容時，只要按下shift鍵就可以實現(xiàn)了，當然，用戶至少又要多占用一個左手的手指了，也許當時用戶左手里正拿著一支紅河牌香煙，而煙灰也許會在他按下shift鍵的同時掉落在鍵盤上。