交互設計拆解——UC瀏覽器視頻聯播頁
跟著@miama的思路,一起來對UC瀏覽器中視頻聯播頁的交互設計進行拆解,在拆解的過程中探索體驗的本質。
一、豎屏模式
- 點擊推薦信息流里的視頻信息會進入到視頻播放聯播頁面,默認進入豎屏模式下,界面上半部分是導航欄及當前視頻播放器,播放器為播放狀態;下半部分是隊列待播放的視頻信息模塊。
- 如用戶本次觀看是上一次未看完的視頻,那么播放內容直接跳到上一次結束觀看的位置繼續播放。
1.導航欄
- 默認狀態下導航欄為非100%顯示;
- 當用戶對聯播頁有點擊、滑動等交互操作或視頻剩余播放時間小于等于5秒時,則100%顯示導航欄。
2.視頻信息
- 默認狀態下視頻信息100%顯示,2秒后進入非100%顯示狀態;
- 當用戶對聯播頁有點擊、滑動等交互操作或視頻剩余播放時間小于等于5秒時,則進入100%顯示狀態;
- 交互區域為用戶點擊發布者頭像&昵稱進入到該發布者所有的視頻列表頁,點擊關注標簽提示關注成功,點擊視頻標題進入視頻詳情頁。
3.操作模塊
- 默認狀態下,操作模塊與視頻信息顯示邏輯一致;
- 播放器右上角折疊分享的功能,左下角放置分享到微信好友及微信朋友圈的快捷入口,點贊及評論的匯總數據與操作按鈕顯示時播放器右下角。
功能歸類思考:分享到微信好友及朋友圈的快捷操作入口與播放器右上角的功能折疊入口在產品功能上屬于同一個類別,是否有必要把它們的位置距離分開的這么大?
4.豎屏播放器
- 默認狀態下,播放器中隱藏工具欄,工具欄顯示邏輯與導航欄一致;
- 播放進度條有兩種狀態,一種是不可交互狀態,另一種是可交互狀態,初始狀態下顯示為不可交互進度條。
播放進度條交互思考:播放進度條在沉浸式播放體驗當中是否需要出現,是否會給用戶心理造成緊迫感?
5.頁面全局交互手勢
- 向右拖動或滑動時,回到上一級頁面;
- 向上滑動觀看下一個視頻,視頻播放器位置錨點在導航欄下面;
- 向上拖動開始時,當前視頻(以下簡稱A視頻)播放狀態變為暫停播放狀態且非100%顯示,隊列待播放視頻(以下簡稱B視頻)中的視頻信息、播放器、操作模塊100%顯示,B視頻為暫停播放狀態;
- 向下滑動觀看上一個視頻,視頻播放器位子錨點在導航欄下面;
- 拖動狀態結束時,當B視頻中的操作模塊完整的出現在屏幕當中時,則B視頻進入開始播放狀態;
- 當B視頻停留在屏幕中間觀看時,向下拖動結束后,則開始播放A視頻。
觀看體驗:用戶觀看視頻時,手指拖動屏幕結束后,當播放器在屏幕外的情況時,是繼續遮擋觀看還是自動讓遮擋部分移入屏幕中?
二、橫屏模式
- 點擊豎屏模式播放器右下角的屏幕切換按鈕,播放器進入橫屏模式;
- 橫屏模式下需要觀看下一個視頻只能點擊右下角視頻列表入口進行選擇,不能通過手勢切換。
- 橫屏模式下點擊右下角的屏幕切換按鈕,播放器進入特殊豎屏模式;
在這里可以思考一個交互預期提出來給大家討論
- 點擊橫屏模式右下角的屏幕切換按鈕是否需要進入一個特殊的豎屏模式?
- 橫屏模式下的“屏幕切換”按鈕與“返回“”按鈕預期跳轉頁面是否一致?
- 進入到橫屏模式下的初始狀態時,播放器除視頻畫面外不出現任何元素,播放2秒后才出現(左圖所示元素),出現2秒后頁面元素再次隱藏,這樣的處理方式有必要嗎?
三、總結
@micma對于產品交互設計思考的方向:
- 拆解界面的每一個元素所放置的位置是否合理;
- 拆解用戶每一條使用路徑是否符合用戶預期;
- 拆解產品的每一條邏輯是否清晰;
- 拆解產品運營在每一個頁面當中是否有足夠的利用空間。
本文由 @micma 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自 Unsplash ,基于 CC0 協議
評論
- 目前還沒評論,等你發揮!