社区中心
注册
Advertisement
Emblem-notice
正在翻譯的頁面
本頁面尚未翻譯完成,歡迎使用者協助翻譯。更多正在翻譯的頁面

大家好!

幾週前,我們發布了第一個公開的FandomDesktop預覽版,統一Fandom和Gamepedia的桌面體驗。在那次預覽中,我們加快履行在社群研討會承諾的「更多就是更多」,這代表著更透明、更多設計思維,在推出之前更深入了解會發生的變動。 為了延續這項承諾,讓我們回顧一下FandomDesktop如何利用額外的洞察力,改變條目頁面。

從問題的核心下手[]

談到wiki是Fandom的核心體驗時,條目就是核心體驗的中樞,不只是身為創作者的您所關注的,也是絕大多數讀者訪問wiki的原因,他們起初就是透過搜尋結果給的連結進到您wiki的條目頁上,因此從提高讀者和登入編輯的體驗開始,就像史巴克先生說得:「一切都合乎邏輯」。

解決多項使用案例的問題[]

現在的Fandom和Gamepedia在內容呈現的方面有項根本的設計差異,就是Fandom的Oasis皮膚是以標準寬度的設計來呈現條目內容,維基媒體基金會和IBM的研究證實這更適合閱讀文字;Gamepedia的Hydra皮膚則以更寬廣的視圖展示條目內容,對於那些以手工打造和戰利品為主軸的遊戲,他們所使用的重型數據表會更有利,《流亡黯道》的官方wiki幾乎是玩遊戲時不可少的第二螢幕體驗。

對於在Gamepedia登入的編輯者而言,這是個更寬廣的體驗,因為右側的廣告欄消失了,撇除某些平台存在的使用案例外,自Oasis發布以來,我們也從Fandom使用者那裏獲得相當多的回饋,雖然標準寬度的視角除了这些在各自平台上存在的用例外,自Oasis发布以来,雖然標準寬度的視圖可以很好呈現某些內容,但不是所有情況都是理想的,如果可以的話,他們反而希望有更寬廣的體驗,我們知道自己需要找個好方法來滿足這兩端的使用,所以我們的做法是......

ANON - Default

這是薩爾達傳說wiki在FandomDesktop未登入情況下顯示的情況,它是結合Fandom和Gamepedia的社群,由於跨項目的因素,目前仍屬於Gamepedia的設計,您可以在條目的左上方(也就是目錄和編輯鈕的上方)看到像是全螢幕的按鈕,沒錯它正是用來切換寬度,這是FandomDesktop瀏覽條目的兩個重大變化之一,採用了適合集中閱讀的標準寬度視圖,也可以擴展為全寬視圖,視圖可依瀏覽器能使用的寬度進行調整,用於資料也很適合。

ANON - Expanded

這就是全寬模式的樣子,比現有的Fandom體驗還寬,相當於未登入使用者看到的Gamepedia體驗,隨著網絡的發展,顯示器的尺寸也不斷改變,在一個那麼多顯示器可以選擇的時代下,「一種尺寸適用全部」的標準寬度顯然代表我們沒有正確服務讀者,因此我們要解決這個問題。

想切回標準寬度嗎?只要再按一下切換按鈕,就能切回去,運作模式就是這樣。

等等...還有更多![]

注重細節的網誌讀者們(也就是你們大部分人)肯定注意到我說這是瀏覽條目的兩個重大變化之一,那另一個是什麼?我們為已登入的編輯者增加第二個選項,無論是全域或只透過頁面切換,已登入的編輯者可以隱藏右側欄位,將內容區擴大得比Gamepedia已登入使用者的視圖還寬(1.1%,根據我六年級學來的預代數技能,多謝Waters女士!)。

Logged In - Collapsed Right Rail

正如我所說,您可以透過偏好設定或點擊右上角的箭頭切換來實現,這個選項是源自於社群委員會、Gamepedia Fellowship、Fandom與Gamepedia編輯者在一對一的研究訪談中直接給予的反饋,以及社群交流會議的參與者也是。編輯者們希望這個選項能盡可能騰出越多內容空間,面對這樣統一、可操作的反饋,我們很容易就做出了決定。

這是已登入使用者的福利,右側欄位在未登入使用者的視角中是投放廣告的區域,因此這個切換功能無法擴展到已登入使用者以外的人,符合Gamepedia的全寬選項,只限定已登入的使用者。

當我們深入更多關於新的編輯工具、搜尋增強功能、新的探索途徑,以及其它我現在還不能說的事情時,由於右側欄位的額外價值不會隨著FandomDesktop推出就顯現出來,如果我們現在說讓您保留右欄,並承諾未來會有一些還不確定的額外用途的話,並非是正確選擇。在這裡,使用者代理是場遊戲,如果您選擇關閉右欄,我們希望您重新打開它,參與我們往後會放在那裡的新事物。

那些其他的按鈕呢?[]

Glad you noticed them, especially since I mentioned them in passing! We have added two persistent page tools which follow you in a scroll state: Table of Contents and Page Edit.

Our design team performed heat map testing of article pages which indicated that, while having the Table of Contents at the top of the page is a logical design, it doesn’t serve all the use cases in practice and actually adds more scrolling to a user experience. What’s the first thing someone does when they hit an article page? They start scrolling and blow right by the Table of Contents. If they’re on a long page and need help navigating it, they have to scroll all the way back up to the ToC.

As first debuted with the FandomMobile experience, the persistent Table of Contents button allows you to get to the article navigation quickly from any point on a page, which is particularly useful for long pages like Link’s page. No more need to scroll all the way back up for the Table of Contents. Just press the button and out it pops as a navigational element. No more scrolling back up to get to the table of contents on the Jon Snow page (one of the pages we did heat mapping on).

ANON - Scroll ToC

Like I said, this originally came from work on FandomMobile. We knew early on in that work that we wanted to have the Table of Contents as a persistent element that scrolls with you for better page navigation, since that experience of having to scroll back up to the top for the navigation is even worse when you’re on a touchscreen. While designing the FandomMobile experience we went through a few different iterations before we arrived at the button on the side that you see live on the mobile site today. One of the early explorations involved a ToC bar following you down the page, but we didn’t like how much content it covered, especially on phones. The small button off to the side, floating in the border of the content area made the most sense and we carried over that design to our work on FandomDesktop. Not only did it make sense from a continuity perspective, but with the expand view button and the Page Edit button, having a different setup for a persistent ToC entry point would be rather out of place for our users.

Once more, into the editor![]

Another noticeable visual change is the article header CTAs for Edit and Comments changed from a button style to an icon-only approach. The intent here was to let the content shine and present an immersive experience for our readers. To help with this we dialed back the visual footprint of secondary features which allowed the content to really come to the forefront like never before. We then carefully sprinkled in a few components that would help the reader move throughout the page, but still focused on keeping as small of a visual footprint as possible so they wouldn’t compete with your content.

The Page Edit button is one of two full page editor entry points in FandomDesktop’s article page design. There’s a traditional Page Edit entry in the top right corner of the page, but now you can also enter the full page editor experience anywhere on the page scroll. As a logged in editor, you still have access to section edit entry points throughout the page, but this additional fixed entry point gives you better access to the full experience wherever you are.

The Page Edit button’s visibility is dependent upon the user in question being permitted to edit the page they’re viewing. For example, a logged-out user on a wiki with anonymous editing disabled will never see the Page Edit button. Likewise, a logged-in editor viewing a page which is protected only for admins to edit will not see the Page Edit button.

More is More[]

This blog was billed as a look at how article pages were changing and, if you expected that we were going to be making big changes to content, I’m glad your expectation was subverted. The content itself? It just works. When users click on a Fandom search result link, they expect to see a table of contents, infobox, and links to other pages that will start their journey down the wiki rabbit hole. That’s not changing. Article pages remain the nucleus of the core experience that everyone knows and loves, and as a bonus we’ve found new opportunities to make experiencing the content better and with more user choices.

In addition to the big changes to width selections and page controls, we are also giving the entire article page a little polish. We’re making more use of MediaWiki standard components, which are in use on Gamepedia today and much more up to date than their Fandom counterparts. We’re also expanding our use of object oriented user interface theming, which makes the experience more modern. And we’re also applying Theme Designer to more components..

We had the perfect combination of feedback telling us something and an opportunity to do that thing: solving for more use cases of article consumption that either Oasis or Hydra address on their own while also refreshing the familiar experience.

外觀 Logged-out options Logged-in options
Oasis Standard w/ rail Standard w/ rail
Hydra Full w/ rail Full w/o rail
FandomDesktop Standard w/ rail

Full w/ rail

Standard w/ rail

Full w/ rail

Standard w/o rail

Full w/o rail

Like we’ve said a few times: More is More.

接下來?[]

There is a lot more to cover as part of the FandomDesktop work (and beyond!), so be on the lookout for blogs on customization and Theme Designer, global and local navigation, editor tools, and what we’re doing with the bottom toolbar (can you see it?).

In the meantime, start counting down until you get full width and Ultrawide Mode, as I’m calling the full w/o rail experience. FandomDesktop becomes available for testing later this spring, with existing wiki migrations happening this summer.

Please let us know what you think in the comments! Also happy to answer any questions that I can about what you’ve seen here.

If you’d like to read the research from IBM, here’s the link.

Advertisement