3-2、困難及解決方式

前端協作問題

問題：

初期有兩位前端共同協作，因此需要建立一定規範進行溝通。

解法：

• 建立相關規範（ git 命名方式、eslint 規範、typescript 規範、css style 規範等）。

• 定義 PR 流程，由 Coding 經驗較豐富的成員統一進行 PR，於 dev 分支上審核無誤後，才會接入 main 主支。

後續延伸狀況：

另一位前端因病休養一陣子，故需進行功能開發的順序調整及項目取捨，以最小可行性先進行。

---

影片步驟切割方式

問題：

介面規劃初期，團隊尚在摸索階段，除了由 UI/UX 組員，將初期 Wireframe 轉換成 Prototype 進行操作模擬之外，尚需各樣實驗。

解法：

前端進行影音上傳及編輯的可行性研究，並與 UI/UX 同步尋找、測試、驗證不同操作介面與流程之可行性，其中嘗試過：

• 秒數輸入方式

  • 為最初期方案，考量實際於手機操作沒這麼便利，且用戶不見得知道自己的影片各步驟秒數，因此廢棄。

• 時間軸 + 步驟區塊拖拉方式（影格拖拉法）

  • 原本使用 YouTube 的時間軸放大與定位方式，但因後續團隊考量優劣，使用 Vimeo 作為第三方影音平台，無法直接使用 YouTube 的功能。

  • Vimeo 本身並不具備此功能，經不斷實驗調整，後續使用：

    • 影片先於本地端顯示給用戶，由使用時間軸 + 步驟區塊的拖拉方式，讓用戶新增步驟。

    • 用戶完成步驟編輯後，再上傳至 Vimeo。

    • 後續客戶仍可使用相同影片進行步驟的編輯。

使用影格拖拉方式進行步驟切割

---

影音平台決定

問題：

初期挑選三個第三方影音平台，需決定使用哪一種平台，進行後續作業。

解法：

前端與後端不斷進行測試技術性、可行性，並分析各面向條件，後決定使用 Vimeo，以下為列點式分析結果。

Vimeo、YouTube、Cloudinary 條件比較