Whalebirdのサポート方針と,マルチカラムについて

Whalebirdを作ったときに,まじでこんなに色んな人に使ってもらえるとは思ってなかったので,真面目に利用人数をトラッキングする仕組みなど一切考慮していなかった. そのため,今現在何人くらいのユーザがいるのか,俺も正確な数値はわからない.

が,とりあえずサポートについて少し書いておく.

問い合わせ窓口について

現状要望等を届けるには3つの方法がある.

  • 問い合わせフォームから送る
  • GitHubにissueを立てる
  • GitHubにpull requestを立てる

Whalebirdは問い合わせフォームを用意している.これはApp Storeに提出する際に必ず必要になる窓口であり,App Storeには窓口のURLが記載されている. https://whalebird.org/desktop/contacts/new

ここから要望を送った場合,俺のメールアドレスに要望が届くので,基本その後はメールで返信をしてやりとりを行う. 今までもこのルートでいくつか問い合わせはいただいている.できる限り返信はしている……がいかんせん個人なので,忙しい時等で返信が遅れる場合がある. ご容赦願いたい.

バグ報告・要望の優先度

要望

Whalebirdは無料のソフトウェアであり,OSSであり,MITライセンスで公開されている. そういう経緯もあって,開発者からの要望を最重要視している.

基本的に要望に関する対応の優先度としては,

Pull Request > Issue > メールによる要望 >>> エゴサで見つけた愚痴

となる. メール等でいただいた要望に関しては,必要だと思えばIssue化する.その時点で,他のIssueと一緒に順番を考えて開発している.

ただし,あくまで対応するかどうかの優先度であり,俺が不要だと思った機能に関しては,たとえPull Requestであっても最終的に受け入れられないことがある.

バグ報告

たまに単なる要望をバグとして送ってくる人もいるのだが……. 基本的にバグであると判定されるものは,どのような報告ルートであってもできるだけ早く解消しようと努力している.

ただし,

  • 再現がほとんど不可能に見えるもの
  • 固有のOSにおそろしく依存しているらしきバグ
  • Electron側の不具合によるもの

に関しては残念ながら対応順位を下げざるを得ない. ご了承ください. 一応調べたりIssue作ったりはしているんだけど,俺一人の力でどうにかならないものもあるんだ.

今後の機能実装について

以上のような優先度で開発しているが,今後の方針について.

マルチカラムに関して

マルチカラムに関しては,最初のブログでうっかり触れてしまったのがよくなかったかもしれない.

現状の思いを言っておくと, 当分の間Whalebirdをマルチカラム化する気はありません

Whalebirdのコンセプトにマルチカラムが合わない理由

そもそも今のWhalebirdにマルチカラムは合わないと思っている.理由は以下の通り.

  • Slackライクではなくなる
  • キーボード・ショートカットですべてを操作する気持ちよさが消える
  • 普段カラムに入れていないタイムラインをどうやって表示するか?というUI上の解決策が見つからない
  • そもそも不要だと思っている

WhalebirdはもともとSlackのような見た目・操作感のクライアントが欲しくて作った.マルチカラム化というのはそこに逆行することになる.マルチカラムな見た目は,明らかにSlackではない.どちらかというとTweetbotだ.

次に,俺はWhalebirdをキーボード・ショートカット天国なクライアントにしようとしている.事実,ショートカットはだいぶ増やしている. そしてショートカットによる操作性が,マルチカラムとあまり相性が良くないと思っている. 例えばマルチカラム化した場合,Mastodonであれば当然のように複数アカウントのタイムラインをそれぞれカラムに割り当てたいと思うことだろう. ではその場合に,新規トゥートはどのアカウントでトゥートすべきだろうか?

よくあるUIでは,これを新規トゥートウィンドウでアカウント選択させたりする.だが,これはショートカットに優しくない(今のWhalebirdならCtrl+数字,Ctrl+nすれば良いだけなのに).

また,ふだんカラムに割り当てているタイムラインならともかく,そうではない,例えば「今このタイミングでだけハッシュタグのタイムラインが見たい」というような場合はどこに表示すべきだろうか? Tweetbotでは一番左のカラムに,MastodonのWebでは一番右のカラムでそのようなことを実現できるだろう.だが,未だにこのUIは使いやすいとは思えない.それをやった場合,やはりいちばん端のカラムは潰されるわけだ. そしてそれらをショートカットで移動できるようにするにはどうしたらいいだろう?

つまり,そもそもマルチカラムのUIでこれが使いやすいと俺が感じるものが,今の段階で思いついていない.

そもそもマルチカラムが不要だと思う理由

そして,そもそもWhalebirdにマルチカラムは不要だと思っている.

まず,みんなMastodonのWeb見た?あれマルチカラムだよね?. 公式でマルチカラムを提供してくれているのに,わざわざ別のアプリを使ってマルチカラムを表示する必要性がどの程度あるだろうか?

俺が昔Twitterを始めた頃,愛用していたのはTweenというクライアントだった. Linuxを使い始めた頃,俺を楽しませてくれたのはmikutterというクライアントだった(このときはまだシングルカラムだった). 一番Twitterが楽しく,一番多くつぶやいていた時期に使っていたのは夜フクロウというクライアントだった.

結局Twitterを一番楽しく使っていた時期は,シングルカラムクライアントばかりを使っていた.

その後Tweetbotとかを使うようになったけれど,俺としてはツイートが減った.

マルチカラムでいろんなリストを一望できて,一覧性があって,すごく満足した. だけど,見て満足するのと,自分がつぶやくというのは別物だと思った. いろんなリストのいろんな人たちの話題の流れは一望できるようになったけれど,カラムに載せていないリストの人たちとの関わりは激減した.

結局,すべてのリストの扱いが平等ではないので,話題の把握は局所的になる. また,たいていのマルチカラムは横幅をできる限り狭くしており,1TLにおける1画面に表示されるステータス数は,シングルカラムより少なくなる傾向にある.こうなると,TLの流れを追うためにいちいちスクロールが必要になるために,流れを追うのがおっくうになる. 加えて,見えている画面に別の話題を話している流れがあるというのは,個人的にはつぶやきの障壁になっているように思えた.

夜フクロウのように,リストがすべて平等にタブとして表示されていて,リスト間の移動がストレスなくできる状態こそ,つぶやくのに最適だったように思う.

そういうわけなので,俺は今からマルチカラムのクライアントを使いたいとはあまり思っていない.

どうするのか

どうしていくかというと,割と目指す方針は夜フクロウに近い. リスト間やアカウント間の移動コストを極力減らしていきたい(今はローディングがあったりして,そこまでスムーズとは言えない). また,各アカウントやTLの未読管理をしていきたい.

マルチカラム化よりも,こちらの方が今の温度感は高い.

というわけで,当分の間マルチカラムにする気はないという答えになった. ただ,もしショートカットでのトゥートや移動が使いやすいマルチカラムUIを思いついた場合はこの限りではないので,当分の間と言っておく.

身勝手な思い

個人的にはサービス開発に関してはかなり独裁的で良いと思っている. Whalebirdは万人受けするクライアントを目指していないし,そのために多機能化していこうとも思っていない.

皆さんからの要望はとてもありがたいし,有用な要望もあって,要望起因で実装しているものもかなりある. しかし全体的な実装方針としては,あくまで 俺が 楽しく,気持ちよくMastodonができるクライアントを目指している.

これを逸脱すると,たとえユーザ数が多くても俺の好きなWhalebirdではなくなってしまうと思っている. そして多分,開発者自身が使わなくなったOSSは廃れる.