14
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

QGISプラグインを作る時に考えていること

Posted at

これは MIERUNE Advent Calendar 2025 の2日目の記事です。
昨日は @nbayashi さんによる pythonでGPVデータを元に天気図を作成する でした。

はじめに

ただのポエムです。過度な期待はしないでください。
あと、部屋は明るくして、ディスプレイから3メートルは離れて見やがって下さい。
(このネタ通じるんだろうか...)

正直、アドベントカレンダーに書くネタがなくて本当に困ってしまったので
QGISプラグインを作る際に、個人的にこだわっていることでも書いてみるか、という感じです。

じゃあ何をこだわってるんすか

個人的にこだわっているのは「UI/UXに意図を持つ」ことです。

...何を言っているのか、よくわかりませんね。

わかりやすく言い換えると、「なぜそのUI/UXにしたのか、理由を説明できるようにする」という感じでしょうか。

具体例が無いとさっぱり意味がわからないと思うので、私が作ったQGISDresserを例として見てみましょう。

QGISDresserはQGISのGUIを着せ替えするためのプラグインです。興味がある人は以下をお読みください。
https://qiita.com/nkmr_RL/items/32d706e8cb4001f05f84

QGISDresserは以下のような手順で利用できます。

  1. プラグインメニューからOpenを押して開く
    image.png

  2. 以下のいずれかで設定する背景を選ぶ

    • Use presetでプルダウンからスタイルを選択する
    • Use imageでローカル画像を選択し、文字色を白 or 黒から選ぶ
      image.png
  3. OKまたはApplyを押して背景を適用する
    image.png

基本的にはこれだけです。別に何ら難しいことはしていないシンプルなプラグインですが、たったこれだけの中でもこだわっていることはあります。

不必要なボタンは作らないor見せない

例えば、こんな経験はないでしょうか。

何かしらのプラグイン、もしくはプロセシングツールを起動したときに、無数の入力欄のあるダイアログが表示され、どこに何を入れれば良いのかも分からず、何となく実行してみたものの、エラーが発生して萎える、、、
(そもそもQGIS自体、ボタンがいっぱいあってよく分からないよ、という意見も聞くくらい)

基本的に多くの人は取扱説明書やマニュアルは読みません。なのでプラグインに限らずシステムは、UIを見ただけで、何を入力すれば良いのか瞬時に理解できるようにするのが理想です。

この時、「わかりやすいボタンにしよう、説明書を見なくてもわかるようにヘルプボタンを配置しよう」と考えるのは良い心がけだと思います。

が、その前に「その機能、本当にUIで設定する必要ある?」という疑問は持つと良いと思います。

QGISDresserの例で言えば、本当は以下のようなことができます。

  • 文字色を白黒以外に設定する
  • ツールボタンだけ別の色にする
  • Tree viewの背景色を変更する

開発した身としては、開発した機能は全てUI上でユーザーにひけらかしたいものです。

一方、9割以上のユーザーはそこまでニッチな機能は求めていません。(個人の感想です)

ボタンや入力欄は増えれば増えるほど、ユーザーに与える認知負荷も増えるため、ニッチな機能をひけらかす行為は9割以上のユーザーにとっては、ただただ苦痛を与えられるだけになります。

そのため、QGISDresserではニッチな機能を、UI上では一切利用できないようにし、プラグイン内のyamlファイルを直接弄ってもらう方式にしています。

もちろん、ニッチな機能を利用するハードルはぐんと上がるわけですが、9割以上のユーザーには関係ありませんし、使えなかったところで大した不便もありません。
(ほとんどのユーザーは背景変えられるだけで満足するだろうし)

とはいえ、どうしてもUI上に残しておきたい場合もあるでしょう。
その場合は、オプション設定という立ち位置にしておきQgsCollapsibleGroupBoxの中にまとめておくなど、「ここは見なくても良いやつかな」と判断できるようにするのが望ましいです。

image.png

操作ミスを想定する

ユーザーというのは、開発者の想定を二手三手上回った行動をするものです。バグの多くは、開発者の想定を超えたユーザーの行動に起因するのではないでしょうか。(これも個人の感想です)

なので、可能な限り意図していない操作は事前に防いでおくことが望ましいです。

QGISDresserの例で言えば、ローカルの画像を背景として利用するなら、プリセットのプルダウンなんて動かせない方が無用な事故が起きないわけです。そのため、ラジオボタンで選択されていない方のUIは操作できないようにしています。
image.png

ちなみに設定方法ですが、QtDesignerで設定する方法もありますが、QGISDresserの場合は以下のようにpyqgisで設定しています。

    def __init__(self, iface):
        # ラジオボタンと関数を繋いでおく
        self.ui.radioButtonPreset.toggled.connect(self.change_groupbox_status)

    def change_groupbox_status(self):
        checked = self.ui.radioButtonPreset.isChecked()
        
        # ラジオボタンに合わせて操作可否を切り替える
        self.ui.groupBoxPreset.setEnabled(checked)
        self.ui.groupBoxImage.setEnabled(not checked)

ユースケースに想いを馳せる

結局のところ、これに限るのかなと思います。上述の「不必要なボタンを作らない」、「操作ミスを想定する」ことも、具体的なユースケースを想像できていれば、自然と対応できます。

では、他にどんなケースを想定したのでしょうか。QGISDresserのUI/UXの裏には以下のような想定があります。

  • どうしてツールバーにボタンを配置しないのか

    • QGISはあくまでジオな処理をするためのツール。着せ替え機能みたいな本筋ではない機能のボタンを増やしてUIの煩雑さを増すのは望ましくない。
       
  • どうしてOK、キャンセル、Applyの3つのボタンがあるのか

    • 背景変更後のイメージがついている場合
      • 背景を変更したらQGISDresserのダイアログは速やかに消えて欲しいはず。OKを押すと背景変更と同時にダイアログも消えて便利。
         
    • 背景変更後のイメージがついていない場合
      • 背景変更後にイメージと違った場合、再度すぐに背景を変更したいはず。この場合、いちいちプラグインのダイアログを立ち上げ直すのはめんどくさい。Applyを押せば背景変更時にダイアログは消えないので、その後すぐに別の背景に変更することができる。
         
  • どうして設定した背景画像を記憶させておかないのか

    • 例えば以下のように痛QGISにして満足している人がいたとしよう。そのことを忘れて、顧客の前でQGISのデモを見せることになり、QGISを開いた場合、どうなるだろうか。あとは想像にお任せする。

ここまで書いてきましたが、冒頭でご紹介したように3つの手順で利用できるシンプルなプラグインですら、これだけのことを想定して作っています。

なんなら、これでも「考慮が足りてないな」と思うものがまだまだあります。

  • QGISDresserを開きながらQGIS本体の操作をすることはないだろうから、ダイアログは最前面に固定した方が良い
  • 画像選択時に全ファイル形式選べるようになっているけど、jpgとpngに絞った方が良い
  • 実はUse presetのラジオボタン、チェック外せる ← いや、直せよ

また、QGISDresserの例では出てきませんが、一般的なQGISプラグインとしては、以下のようなことも気にかける方が望ましいです。

  • 重い処理を走らせている時のUI(ユーザーが不安にならないようにするには?)
  • レイヤの順番(どの順番なら自然なのか)
  • マップ領域(着目している地物にクローズアップすべきかどうか)
  • Dialogを採用すべきなのか、DockWidgetを採用すべきなのか
  • 余計なユーザーアクションがないか

こうしてみると、UI/UXにこだわるのはちょっとした沼ですね。

現実には、プラグイン開発にかけられる時間的制約もあるので、全てに対応することは難しいかもしれません。

ですが、使いにくさに気づいているけど(制約の都合で)やらないのと、そもそも気づいていないのには大きな差があります。

気づいている場合、以下のような対応が打てます。

  • Issueとして挙げておく(誰かがやってくれるかもしれない)
  • 重要度に応じて優先順位をつける
  • (お仕事の場合)改善案として提案できる

なので、なぜそのUI/UXなのか、改善点はないのか、を語れる状態にしておくことは、結構大事なんじゃないかなーと思っています。

おわりに

ということで、プラグイン開発時に考えていることを書いてみました。
まあ、「ソフトウェア開発における原則が〜〜」とか「何たらの法則によると〜〜」とかではなく、あくまで個人的に気をつけていることなので、参考程度に読んでもらえたら満足です。

14
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
14
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?