2009-07-03 55 views
1

我正在研究這個有點像博客的應用程序。我正在考慮做一些事情,用戶可以使用谷歌閱讀器這樣的「無限滾動」功能滾動瀏覽所有帖子。「無盡滾動」是否可以編輯的東西工作?

這就是我所期待的問題......如果用戶點擊某個帖子進行編輯,那麼他/她將會進入一個新頁面。很快,他們會想要回到滾動視圖,他們可能會想要返回到他們點擊「編輯」時所處的位置。

我想如果他們沒有看到他們點擊「編輯」時發現的同一個帖子集合,他們會被嚇倒。他們不想回到逐漸加載滾動過程的開始,而必須重新開始。

我曾想過在會話中存儲累積帖子的ID和滾動位置,並在用戶返回時重建所有內容。但是如果他們在點擊「編輯」之前滾動了數十或數百個帖子呢?在合理的時間內加載數據可能太多。

然後有一個想法,使用對話框,而不是去一個新的頁面進行編輯,但它引入了一整套其他問題。例如,如果用戶試圖在新選項卡中打開對話框,會發生什麼情況?

所以也許這對於「無盡的滾動」來說不是一個好的設置。也許傳統的分頁方式是可行的。

有沒有人執行過這樣的事情?有什麼想法嗎?

回答

1

當心:我覺得 '無盡滾動' 煩人。它將作爲位置指標的滾動拇指弄亂了,並且出現了驚人的變化和停頓。在某種程度上,它會變得很笨重 - 你提到的「數百個帖子」場景 - 除非更復雜(當你深入的時候丟棄頂部的項目,提供隨機訪問)。

但是,請考慮Google Reader(您引用的示例)如何處理該問題:您很少從無盡滾動窗口導航。一些項目操作(標記)發生內聯,但大多數鏈接在另一個窗口中打開以完全避開問題。如果你想改變設置,那麼'回到谷歌閱讀器'你的滾動位置會回到頂部 - 所以也許這不是什麼大問題。 (雖然值得注意的是:當你回來時,列表的範圍是所有以前加載的項目 - 原來剛頂裝更多關於這下面。)

我會考慮在非模態位置編輯 - 編輯框插入滾動區域,在正在編輯的項目的頂部或旁邊。或者,如果一個關鍵位的連續性是你想要發回人們準確地查看他們剛剛編輯的項目,請確保'返回列表'鏈接包含一個指向視圖應該自動執行的地方的指針,滾動(例如,在#fragment錨點中)。此外,如果您的代碼或瀏覽器有效地緩存了數百個前面的項目(正如我上面提到的Google Reader看起來那樣),則前滾應該是即時的,無需重新加載。

0

我已經做了一些動態數據類似這樣的事情。我輸出一個定位標籤,它是帖子的ID並通過POST或GET傳遞它,或者根據用戶點擊的內容將它傳遞給帖子,以便當他們再次導航到頁面時,我的代碼將放入錨點。

類似:

header("location:http://www.myDomain.com/posts.php" . "#" . $post_id); 
1

無盡的滾動用戶界面已知有一個學習曲線 - 取決於你的用戶基礎,他們可能是一個相當陌生的領土和混淆不止幫助。這可能會在未來幾年或幾個月內發生變化,所以這一切都取決於...

一如既往,如果有疑問,請從您的用戶自己瞭解。理想情況下,您應該運行一個觀察性研究,您可以使用類似的無限滾動用戶界面來觀看它們。他們完全失去了吸引力嗎?或者他們是否快速「明白」並將其視爲比傳統分頁更快的解決方案?請記住,像我們這樣的人(使用twitter和谷歌閱讀器)在我們的前面,我們的需求,目標和期望可能會與您的目標用戶羣不同。

所以,簡而言之,您應該首先了解無盡滾動UI是否合適。這完全有可能不是 - 因此巧妙地迴避了上述問題。

1

無盡/長卷軸是糟糕的可用性實踐。即使您在編輯後設法將用戶重定向到正確的帖子,他們可能已經忘記了他們在編輯過程中的位置。然後,他們將進行分頁確認他們在哪個頁面上。

也許只是保持簡單,並限制每頁文章&提供分頁功能。這是用戶熟悉的UI功能,不會迷路。

或者只是提供每個帖子的標題,這可以通過點擊展開/收縮以分別查看和隱藏完整帖子。這將允許每頁更多的帖子,而沒有過多的滾動。

相關問題