首先要說的是，嚴格講起來 Rive 有兩套軟體：Rive Editor & Rive Runtimes，Rive Editor 是給設計師製作動畫用的，完成後會輸出一個 .riv 檔案，Rive Runtimes 則是給工程師用的 library，用來在瀏覽器或其他環境上解析 .riv 檔，把動畫渲染出來。

所以想用 Rive 的話，必須要設計師 & 工程師兩邊一起配合，因此今天會先站在設計師的角度，說明 Rive 有什麼優點，這裡我列出三點。

帶參數給動畫

很多時候我們希望動畫可以是活的，可以根據參數改變動畫的內容，例如這隻 Duolingo 的小貓頭鷹，我們希望他可以在不同的情況，講不同的話。傳統的動畫是靜態的，不能帶參數進去，所以只能把對話框 & 小貓頭鷹分開做，對話框由前端手動切版，但如果對話框有其他動畫或 transition 的話，其實沒有那麼好切，特別是如果動畫比較精細的話，設計師跟前端通常會有很多……恩……熱烈且充分的意見交流。

但 Rive 有提供 State Machines & Rive Texts，讓設計師可以先挖好空格，讓開發者帶不同的參數進去，就可以產生不同的動畫效果。

讓使用者跟動畫互動

這一點跟帶參數也有關係，在前端的世界中，使用者跟動畫的互動，最終會被轉換成參數，所以如果動畫無法帶參數，那使用者就不太能跟動畫互動。Rive 因為有 State Machine Inputs 的關係，可以藉由參數改變動畫，再加上瀏覽器內建的 event listener，就可以讓動畫跟使用者互動，藉由使用者的行為改變動畫，例如 Day 01 提過的火柴人。

而針對 event 這個部分，Rive 有提供更進階的 custom event，除了讓設計師可以直接在 Editor 裡面寫前端的 event listener 以外，也可以透過 Rive 主動丟 event 給前端，開啟了一條「使用者 ⇄ 設計端 ⇄ 前端」雙向傳遞資料的管道。

降低溝通成本

我覺得這是 Rive 最大的優點，如同 Day 01 提過的，Rive 讓設計師的設計檔案，可以直接在瀏覽器上跑，省下了與工程師溝通的成本 。

我想特別提一下的是，溝通成本其實沒有想像中的低，裡面有非常多的摩擦成本在，畢竟人的問題通常都是比較難處理的。所以如果是一個很注重視覺的專案，或是團隊中有很注重細節的設計師、客戶、老闆的話，能省下溝通成本，會是非常划算的一件事。

小結

帶參數給動畫，讓使用者跟動畫互動，同時降低設計師的溝通成本，以上是對於設計師來說，Rive 的幾個優點。當然如同開頭說的，Rive 需要設計師 & 工程師兩邊一起配合，所以明天會換成站在工程師的角度，說明 Rive 有什麼優點。