VOICEVOXエディターのデザイン/UI/UXに関しての議論一覧

[Hiroshiba]

ここは

今のVOICEVOXエディタのデザイン・UI・UXについて、いろいろ話せる場です。
確度が高いものはissueを作りやすいですが、なんとなくこう思ってるくらいのことを書ける場を目指しています。

内容

課題がありそうであれば新規に自由にコメントしてください 🙏
具体的な課題内容やスクショがあると、認識ずれにくいのでおすすめです（コピペで画像が貼れます）。
解決策のアイデアがあるとなお良いかもですが、アイデアのが長くなりそうだったら適宜分けると見やすいかも。

その他

出てきた課題や案がまとまってきたらissueを作ると良さそう。
将来的にはデザインガイドラインを作れるととても良さそう。

このdiscussionsの運用方法は模索中でいろいろ変わるかもです。

[Hiroshiba]

アクセントとイントネーション（とついでに長さも？）を同じ欄で調整できるモードもあると楽しそう。
雰囲気こんな感じ･･･？

[rokujyushi]

共通するまたは類似する機能を持ったボタンのフォント設定、デザインの統一について

完了、保存ボタンの場合

[Hiroshiba]

本当ですね･･･。なんか他にもあったりしそうですが、どうでしょう･･･？
統一ができるかまだ不明ですが、少なくとも語句の定義とこういうときはこっちというガイドラインが必要そうに感じました。

設定後の離脱で、キャンセルできない場合は「完了」、キャンセルできる場合は「保存」とか･･･？
（完了と保存で分ける必要ないかも）

[rokujyushi]

プリセットの登録も「確定」でした。
テキスト入力をするところについては「確定」で
「保存」と「完了」で別れているところのみ統一するというのはどうでしょうか？

[Hiroshiba]

「保存」と「完了」なら、やはり「保存」で統一が良さそうに思いました。
テキスト入力部分は「確定」にするの、保存と語句を分けている理由とかってあったりされますか 👀
（どういう感じがいいのか今市頭の中で組めてなくて、なんとなく聞いてみた感じです。）

[rokujyushi]

プログラムの処理によっても使い分けてるのかと思います。
入力内容を確定（Enter）→保存する（Ctrl+S）がテキスト編集ソフトでは自然な流れだと考えているので
ボタンを押下した段階でデータが保存されるなら「保存」されないのなら「確定」だと思います。
ただUX的にはボタンを押した段階で保存されていることが良いことだと思うので
統一するなら「保存」がいいのかもしれません。

[Hiroshiba]

なるほどです！
enterキー的な確定で言えば、テキスト欄に入力が完了した時点でユーザーはenterキーを押している（確定している）かもです。
押したときに保存されるものは全部「保存」が良い気がしました！！
（ちなみに「オプション」とかは閉じたときではなく変更したときに自動保存なので×ボタンで良さそう）

[rokujyushi]

共通するまたは類似する機能を持ったボタンのフォント設定、デザインの統一について

削除ボタンの場合

[Hiroshiba]

ここは「編集」がアイコン化できないので仕方ないのかなと思いました。
言語化するなら、一覧のセル内に削除機能をもたせる場合はゴミ箱アイコン、そうじゃない場合は削除ボタン、とかでしょうか。
あるいは単語一覧側を、一覧にセル内に削除があるようにできればありかもです。

こんな感じですが、どうすべきみたいな案とかってあったりされますか？ @rokujyushi

[rokujyushi]

設定の画面の方では「削除」のみを使ってるのでそちらに合わせるといいと思いました。
もしアイコンのままでも色を統一した方が良いと思います。

[Hiroshiba]

@rokujyushi なるほどです！
ちょっとお伝え漏れてたのですが、メイン画面のテキスト欄も、ホバーすると削除ボタンが現れます。
ここを「削除」にするのは現実的じゃないかもと素人ながら思いました。赤にするのも避けたほうが良いかもと思いました。
やるならテキスト欄ホバー時の削除ボタンだけは別扱い（というよりメイン画面は例外がありえる）、とかでしょうか。

[rokujyushi]

元に戻すができない箇所であれば赤色にすべきだと思います。
なのでメイン画面の削除ボタンは例外という認識です。

[Hiroshiba]

なるほどです、非常にわかりやすい取り決めに感じました！
アイコンか文字かは、削除ボタンのみならず汎用的な取り決めがあると良さそうに思いました。
ここでは一旦保留かなと。

[rokujyushi]

共通するまたは類似する機能を持ったボタンのフォント設定、デザインの統一について

キャンセルボタンの場合

[Hiroshiba]

プリセット側を「キャンセル」「削除」に寄せるべきかなと思いました。
これ系は以前統一したのですが、漏れていたかもです。お気づき頂きありがとうございます！

[thiramisu]

「プリセット削除の確認」の画像は多分0.14.7のもので、開発最新版では表記は統一されているはずです。

ただそれはそれとして、SHOW_OOO_DIALOG系のボタンが、他の文字系のボタンと違ってマウスを乗せるまで当たり判定の境界が分からない見た目なのは、何とかしたい感じがありますね。自動選択されるほうのボタンをprimary色での塗りつぶしありのボタン、違う方を枠だけのボタンにするとか…？

[Hiroshiba]

ただそれはそれとして、

あ。話題変わる時はコメントの始まりを変えといた方が後々見やすいかもとか思いました！
（discussions模索中なので軽く提案してみた次第です）

[thiramisu]

以下に分けてみました。
#1564 (comment)

[rokujyushi]

共通するまたは類似する機能を持ったボタンのフォント設定、デザインの統一について

戻るボタンの場合

[Hiroshiba]

これはヘルプだけドロワーを使った入れ子構造になっているので、戻るボタンをツールバーに置けず、変なUIになってるんですよね･･･。
なにか良い方法とかあればとても知りたいです。

[Hiroshiba]

パッと思いつきなのですが、例えばタブの「音声ライブラリの利用規約」の下にキャラごとの小さなタブを表示してしまって、戻るボタンを失くしてしまうとか思いつきました。

[rokujyushi]

私としてはデザインの統一できたらと思っていましたが
利用規約の見やすさが話題になっているので、構造を変えるのもありなのかもしれませんね。

[Hiroshiba]

なるほどです、デザインの統一には構造の抜本的な見直しが必要かもと思ってました。
もしボタンデザインだけ統一するとなると、良さそうなUIとかありそうでしょうか 👀

[thiramisu]

「クリック可能」なもの全般（主にボタン）

以下の3種類あります。ルールを整備し、統一感を持たせつつ、UIを考える際に迷わなくしたいです。
（セレクトやメニューなどの展開時は別枠な気がするので載せていません）

塗りつぶし

背景色がprimaryなら文字色はdisplay-on-primary。
背景色がbackgroundなら文字色はdisplay。

画像

（ツールバー）


（再生ボタン）


（設定 / オプション の ラジオボタン）

---

枠線のみ

背景色はbackgroundのみ。
文字色はdisplay、warning、primary。

画像

（設定 / アクセント辞書）




（設定 / キャラクターの並び替え・視聴）これに限らずキャラ系は全部「枠線のみ」のはず


（ヘルプ / ライセンス情報の戻る）


（プリセット）


（エンジン / エンジンの管理）

---

塗りつぶしも枠線もなし

画像

（メニューバー）


（設定の閉じるボタン）


（設定 / キー割り当て）


（設定 / オプション の セレクトボックス）


（プリセットの詳細設定ボタン）


（プリセット管理の削除ボタン）


（ダイアログ）


（ヘルプ）
「読み方・アクセント辞書」や「エンジン / エンジンの管理」もこれに近い。
ボタンというよりはタブなので別枠で議論すべきかも。

[thiramisu]

以下は自分の意見です。

こんな記事を最近見ました。
https://note.com/ritar/n/n0f6aad6c2560
枠線だけの方が新しい感じは出るかもです。

「メニューバー」は慣れたUIなので多分今のままで大丈夫なはず。他のものについては、

• 中身が文字の場合は太字にする
• 角をなるべく丸くする（逆説的に押せないものは角をあまり丸くしない）

1. 中身がアイコンで状態が1つの場合は塗りつぶしも枠線もなし
2. 状態が2つあるうちのactive/enable中の場合は塗りつぶし
3. ボタンが並んでいる内、ユーザーが一番選択したそうな場合は塗りつぶし
4. それ以外は枠線のみ

という感じが良いかなと思いました。

[Hiroshiba]

記事読みました、とても面白いです。

新しさでいうと　塗りつぶしボタン < 枠だけボタン < 枠なしボタン　なのかなと思いました。
でもツールとしての使いやすさを考えると、枠なしは結構視認性イマイチになりがちなので、塗りつぶしか枠だけボタンを主軸にするのは賛成です。

ちょっとテキストボタンに関していろいろ見て回ってみました。

このGithub見てる感じ、枠だけボタンがほとんど無かったです。こんな感じ。

Discordは枠ボタンがほぼなく、枠なしが主でした。

枠があっても極力目立たせない傾向を感じました。

zennは結構枠だけボタンが多いのですが、目立たせない傾向を感じました。

ちなみにyoutubeは

枠無しにしろ塗りつぶしにしろ、もうちょい目立たせない方が良さそうに感じました。
実際最近のデザインフレームワークはデフォルトボタンの枠薄めでした。

Ant Design

Bulma

Gmailの返信ボタンはちょっと濃い枠のみボタンでした。

[KRRyuki]

２０日追記：
今作ってみたUIの構想に　考えているポイントについて三つです。

1. 現状スクロールでは、新しいキャラを表示するには難しい（順番？）
2. ユーザーの画面では、すべてを、一気に見えるのは難しい
3. 平等の観点で新キャラを知らせる方法を含めたい

---

コメント失礼します。
DISCORDで送ったUIアイデア構想をまとめました
写真多くてすみません、PDF添付にしました。

PDF最新版：９月１９日の夜
IdeaVOIVO_FullCharacterUI_KRR.pdf

考えとして...

新キャラ、ランダム選択、お気に入り、お勧め

四つのモード

新キャラPR用

ランダム＝ガチャ

お気に入り　カスタマイズ機能

お勧め　簡単な選択肢でキャラを薦める機能

そして新しい構想です。

検索、スタイル履歴機能

検索　（PDFご参考ください）
*使い道：多数話者がいた場合、文字入力が早い方がほしいキャラを早く見つけること

スタイル履歴
*使い道：多数話者がいた場合、劇場ストーリーに役立つかも
メリット：スタイル選択の時間をは省ける

1クリックでスタイルを呼び出す

DISCORD上の質問について考えた結果ですヾ(•ω•`)
結論、呼び出すには1クリック、_選択するにはもう1クリック_必要かも

1.アイコンをクリックしたら他のキャラの透明度自動的に下がる

2.スタイルのあるキャラをクリックした場合、スタイルが自動できに飛んでくる（以下写真参照）
欲しいスタイルをクリックで選択完了

誤動作用の右クリック＝取り消し機能　（全モード共通）

例えば、ずんたもんを選択したい、めたんを選択しちゃった場合

右クリックで前のステップに戻る機能があれば便利かも...？

以上です。ご参考になれば幸いです。

KRR

[Hiroshiba]

あ、考えてるポイント（達成したい目標）も書いておくと目的意識がずれないかなと思いました！
こんな感じでしたっけ

考えているポイント
1. 現状スクロールでは、新しいキャラを表示するには難しい（順番？）
2. ユーザーの画面では、すべてを、一気に見えるのは難しい
3. 平等の観点で新キャラを知らせる方法を含めたい

新しいキャラと出会うのを画面遷移せずに行う場合はこんな風になるのかな〜とすごくイメージしやすいです！！

[KRRyuki]

ヒホさん　
ありがとうございます。<(_ _)>💦　追記で一番最初に書きました...！

多少ご参考になれば嬉しいです。

[thiramisu]

ダイアログか画面か

設定系やヘルプなどの「ダイアログ」がダイアログと画面の「中間」のようなUIで、曖昧な気がします。
ユーザーは見たことのあるUIの方が使いやすいはずなので、どちらかに寄せるべきかなと考えています。

自分があまりダイアログっぽくないと感じる理由としては多分以下のような感じです。

• ウィンドウ内で、かつバックドロップ無しに全画面で開く
  • ダイアログの場合、メイン画面とサイズが違うのが一般的かと思います。内容に横幅が（あるいは横幅に内容が）最適化された状態でメイン画面の横幅に関係なく開かれるものが多いかなという印象です。
  • エラー時などにまさにダイアログっぽいダイアログが表示されるのもあり、それ以外は画面っぽいのかなと。
  • バックドロップが無いので、Escキーを知らない場合に、閉じるボタンを探す必要があるのもあまり良くないと思います。
    ダイアログなら閉じるの位置は右上で自明ですが、画面だと認識している場合は「ホーム」「戻る」は左上のイメージが強く、閉じるボタンを少し見つけにくいので、もう少し強調したほうが分かりやすいのかなと思います。
• メイン画面のツールバーとタイトルバーで色・範囲が共通
  • デザイン的には面白いとは思いますが、UX的には少し怪しいかなと思っています。
  • bg-primaryの部分がダイアログのタイトルバーがモチーフであると分かりづらい気がします。
    • ダイアログとしてはheightが高すぎるように見えます。
    • ダイアログのタイトルバーには基本的に雑多機能のボタンはないはず。
    • 検索などを含めたいならダイアログではなく「画面」としてレイアウトを考えるのが良いのかなと。
• ダイアログは2階層以上の場所を保持することはほぼない
  • ダイアログの場合、新しい階層を表示するなら新しいダイアログが開かれる動作が多いと思います。

ちなみに自分は画面に寄せるのが良いのかなと思っているんですが、理由として大きいのは設定をダイアログで行うのは少し古いUIなのかなと感じているためです。（このUIの作成時もその考えが根底にあったので、ダイアログっぽくも画面っぽくもあるUIになっているのかなと思ったり。）
設定ダイアログの"画面化"の流れはスマホの影響も大きい気がします。例えばwindowsの設定UIはタブレットなどでの表示も想定されているはずて、この流れを汲んでいるので、参考になると思います。

逆にダイアログに寄せたい場合は内容にprimary色のborderを足す手もあるかもです。表示領域が狭くなるのであまり良い手ではなさそうですが…。

画面に寄せる場合は多分左に目次兼タブ、右に見出しと内容みたいな感じかなと思います。

[Hiroshiba]

今のUIはQDialogを使ってるという意味でダイアログだと思います。
「ダイアログ」や「画面」だと何を指すかの共通認識がずれうるなと感じました。ダイアログは一時的な取りをする画面だという定義も見かけました。

ちなみに自分は画面に寄せるのが良いのかなと思っている
逆にダイアログに寄せたい
ウィンドウに寄せる場合

このあたり、思い浮かべてるものが違うかもです。
なんとなくですが、広々と使えるから全画面＋状態管理が大変になるからOSレベルの新ウィンドウは作らない、だと嬉しそうです。（たぶん @thiramisu さんの言う画面？）
これはDiscordの例ですが、左にメニューリストを置くかは置いといて、こういう感じが良いのかなと。

良さそうなデザインのイメージスクショや絵があると認識合いやすい気がしました！
（今のUIだとなんかイケてないな感は僕も感じてます。）

[thiramisu]

目指すところは自分もそんな感じが良いと思っています！

最後の「ウィンドウ」は「画面」ですね、表記ゆれしてましたすいません…。(修正しました)

例えに出した「windowsの設定UI」のスクショを張り損ねてました。Discordのものに結構近いと思います。

目標とするUIは自分もこんな雰囲気が良いと思います。

ただ、もう少し根本的な所の認識がずれている気がしたので、蛇足かもですが、試しにもう一段階上の話をしてみようかと思います。

独自理論なので間違っているかもなのですが、自分の中でのUI設計のイメージはこんな感じです。
あるUIをこのグラフ上で上方向に移動するには「センス」が必要だと思うんですが、右方向への移動は「既存のUIに寄せる」ことで簡単に達成できると考えています。

また今回のUIは汎用的なUIなので、上方向よりも右方向の大きさのほうが重要だと考えます。

UIを既存のものに寄せるのはユーザーにも開発者にもメリットがあると思います。
ユーザー的には、既存のUIと似ていれば、それと同じ使い方をすれば良いと判断できます。
開発者的には、そのUIがどうしてそうなっているかや、ユーザーがどこに何を求めているかを元にUXを考えればUIを作れます。
双方にメリットがあります。

ではどこに寄せるべきかという話になります。
もしダイアログに寄せるならということで、典型的なダイアログはどういうものかを思い浮かべてみます。
自分は以下の2つを思い浮かべます。

…といった考えの下、自分は以下の考えには懐疑的です。

今のUIはQDialogを使ってるという意味でダイアログだと思います。

なぜなら上記2つの見た目からかなり離れているからです。
また、重要なのはユーザーからの逆算、つまりユーザーからどう見えるか・ユーザーがどう感じるかだと考えているためです。
ちなみに、参考に出されたページでも真っ先に「子画面である」という説明がされていて、メイン画面よりも小さいイメージがあることがうかがえます。この点からも離れています。

なので少なくとも現状ではダイアログとは言えないかなと思いました。それにもかかわらずダイアログを意識したUIのデザイン・色・配置も混在しているので、中途半端かなと感じた次第です。
（少なくともダイアログではないのではということに主眼があったので、ダイアログ以外のUI全般として「画面」と言ってましたが、「ページ」とかのほうがより近い表現だったかもです）

[Hiroshiba]

制約がきつい方が開発をしやすいと思っているからですね。

ちょっとここが何の話かわかりませんでした。
今のUIがダイアログなのかそうじゃないのかを深掘りしたい理由でしょうか･･･？ 🙇

---

既存のUIに寄せたほうが使いやすいのはそのとおりだと思います！
目標としているUIも似ていそうですが、どういう方針だとやりやすそうでしょうか？

[thiramisu]

制約がきつい方が開発をしやすいと思っているからですね。

書き方が分かりづらかったのですが、その下の話につながっていて、

開発段階では、UIパーツの新規配置や再配置にあたって、場所の候補がいくつもあると、センスや感覚が必要な部分が大きくなってきます。これが結構つらそうだなと思いました。

というのを一言で言うと「制約がきつい方が開発をしやすいと思っている」という感じでした！
今のUIがダイアログなのかそうじゃないのかを意識すれば、デザインの候補が絞りやすくなる（制約をかけられる）ので、開発がしやすそうだなと。

---

方針に関してですが、正直に言うと自分も経験はないので、どうすべきか考えても平凡なことしか思い浮かばなかったのですが、とりあえず考えをまとめておきます。

ボトムアップ的にUI単位で寄せる場合は、

1. 寄せたいUIと今のUIを比較して共通しているコンポーネントを抜き出す
2. その共通部分だけを真似して現状のUIを組み替えてみる
3. 非共通のUIの配置を考えて配置する

みたいな感じですかね。

もう少しトップダウン的に根本的にやっていく場合、汎用的なものを目指すなら、やはり広く使われている考え方を踏襲するのが良さそうだなと思いました。ということで、まずは自分からやってみるべきだと思い、マテリアルデザインをちゃんと読んでみています。
Material Design
日本語訳してくださっている記事(バージョン2準拠、一部？)
自分は今まで割と表面的な真似でやっていた部分が多かったのですが、ちゃんと原典を読んだらちゃんと参考になりそう！
と思って読んでる途中なのですが、結構分量があってまだ読み切れてません…中間報告まで…。

[Hiroshiba]

まあ実際デザインをどう決めていくか考えるの難しそうですね･･･。
昔VOICEVOXの外観デザインを考えた時は、ノートに3通りぐらいいろいろ書いてみたり、実際にパワポで作ってみたりしてあーでもないこうでもないと決めてました。
https://docs.google.com/presentation/d/17MuH7-IRpB-DSSIJ_WU2_AS9_CE5V4lwATiKLJhzUUE/edit?usp=sharing

とりあえず実装はさておいて、外観の模型や手書きの案を作って試行錯誤するくらいしか思いつかないですね･･･。

Material Design

一回ダークテーマとは何なのか知りたくてマテリアルデザイン読んだことあるんですが、陰影の付け方とか高さの表現の仕方とか色の選び方などのデザイン哲学は書いてあるけど、どういうレイアウトにすべきかとかはUIレベルの設計はあんま書いてなかった記憶があります。

全てのデザイン方針をマテリアルデザインに合わせる、というのは･･･ありかも･･･？
（マテリアルデザインとクリエイティブソフトウェアの相性がちょっとわからない･･･）

[thiramisu]

マテリアルデザイン、完全に理解とまではいかないんですが、概要はつかめた気がします。

確かに、スマホ・タブレットが主には想定されているようなので、若干未知数の部分があるかなとは思うんですが、一応デスクトップアプリにも応用は可能そうです。グラフィックではなくテキストデータの編集なので参考にはしやすいかなと。
そこら辺も含めたUI全体のレイアウトに関して述べられているのはこのあたりですかね。
https://m3.material.io/foundations/layout/applying-layout/window-size-classes#6e960b82-eff3-4f1b-92d3-5edb5e338f49

ただ、それでも一部ページは十分参考になるかなと思いました。
個々のコンポーネントのガイドラインとアクセシビリティの項目（例えばこのページ）、Foundationなどはマテリアルデザインを取り入れなくても割と汎用的な部分が多いかなと思います。

[Hiroshiba]

なるほどです！！

もうマテリアルデザインの方針に合わせちゃっても良いかもとちょっと思いました。規範が整ってるのが嬉しいです。
VOICEVOX（やPCソフト）と合わない点が出てきたら避けたいですが、少なくとも設定画面とかはしたがって良いのではという気持ちです。

（ツールバーみたく、ボタンがどうしても大量に出てくるUIとかは相性悪いかもですね）

[takusea]

これからコンポーネントの洗い出しや設計、画面のリデザインなどを行っていくにあたって、FigmaなどのUIプロトタイピングツールを用いてまとめていけたら良いんじゃないかなと思いました。

コンポーネントのデザインを状態ごと（ホバー時やクリック時など）に作れたり、色変数も使えたりなど、実装に落とし込みやすいように作れるんじゃないかなと。

デメリットとしては、プロプライエタリなサービス内でデータを管理することになることと、皆で作っていきたい場合は操作を覚えて貰うことやアカウント作成が必要なことが挙げられそうです。

試しに私なりにリデザインを行ってみたので、以下に共有します。左上のアイコンから各ページに飛べるはずです。（プロパティなどの値を見る際にはアカウント作成が必要そうでした…）
ご参考になれば幸いです。
https://www.figma.com/file/EzJX7fQTbTsRRSHAwdB4va

[Hiroshiba]

コメントありがとうございます！
figma見させていただきました、すごい作りこみですね！！！
デザインに統一感を感じました。UXに関する提案も垣間見えて勉強になりました。

figmaでデザインを管理するの面白そうに感じました！（ @thiramisu さんもこの辺り興味ありそう？ ）
確かに提案をしやすかったり開発効率が上がりそうな印象を受けました！
どうやってオープンにしつつ中央集権的にメンテナンスし続けるかが課題になるかもです。
プルリクエストの仕組みもfigmaにありそうですが、Enterprizeプラン以上での提供っぽく、さすがにお値段が･･･。

色々独学でデザインを勉強してみてはいるのですが、誰かに教わる機会がなくどうしても試行錯誤になってしまいがちだったのでとても勉強になります。
ちなみになのですが、VOICEVOXのデザインの改善に興味あったりされませんか？
もしモチベーションが合致しそうな点があれば何か進められないかなーと･･･！

[takusea]

確認ありがとうございます！自分もデザインは勉強している側の立場なので恐縮です…！

OSS開発で維持費が発生するのは避けたいですね。できる範囲でやるとなると、マスターファイルを複製して編集したものをコントリビューターに共有してもらい、それをメンテナーがマスターに移すか、手書きで共有したものをマスターに清書するかで擬似的にマージするなどですかね…

VOICEVOXのデザインの改善、とても興味があります…！

[Hiroshiba]

figmaのメンテナンスは大変かもですか、提案や認識合わせが簡単になるのはそうだと思うので、良い塩梅を探したいですね！

VOICEVOXのデザインの改善、とても興味があります…！

おお！！ぜひぜひ！！
･･･何をどう進めれば良いのか難しいですね･･･！
とりあえず、他のコンポーネントとあまり干渉せず、かつすでにちょっと浮いてる「ヘルプ」画面を置き換えることを一旦の目標にしていろいろ進めようとしてみる、とか･･･？

[takusea]

そうですね。まずは他の作業となるべく衝突しないように進めたいので、ヘルプ画面あたりから試しに取り組んでみるで良さそうな気がします。
あとはボタンなどのベースとなるコンポーネントも実装していきたいですね。