チェック/チェック解除時にWPFチェックボックスの視覚的な動作が逆になるのはなぜですか？
WPF（Windows Presentation Foundation）チェックボックスコントロールは、チェックされたときとチェックされていないときの視覚動作が逆になります。
つまり、マウスボタンを押すと、チェックマークが消え、マウスボタンを離してもチェックマークが残ります。もう一度押すと、チェックマークはマウスボタンが離されるまで留まります（その時点でチェックマークは消えます）。
チェック-マウスダウン
チェック-マウスアップ
チェック解除-マウスダウン
チェックを外す-マウスアップ
この動作は、機械的なトグルボタンの動作を思い出させます。ボタンが押し込まれ、所定の位置にクリックされます。もう一度押すと、元に戻るまで保持されます。
この動作からここで学ぶべき実用的なUXレッスンはありますか？
これらの微妙な視覚的手がかりは、ユーザーエクスペリエンスに何らかの価値をもたらしますか？
あなたが言うように、それは機械的なトグルスイッチに似ています。これが付加価値をもたらすかどうかに関しては、ユーザーが行っていることがコンピュータに影響を与えたというフィードバックを提供します。一般的に、このような微妙なフィードバックは、ユーザーが何かに（重要な）注意を払うことを要求せずに安心できるようにします。
実際には、3つの視覚的状態があります。MouseDown（ActiveClicking）、チェック、およびチェック解除です。 WPFでは、アクションコマンドは通常、MouseUpで発生します。DragAndDropなどの明らかな理由により、デスクトップアプリではかなり一般的です。
マウスダウン-チェックおよびチェック解除：アクションが実行される場所をユーザーに青いインジケーターで示します。使用するインターフェイスに関係なく：マウスポインター、タッチ、またはキー。
マウスアップ-チェック：最終状態を表示します。
マウスアップ-チェック解除：アクションが発生する可能性のある最終状態と青いインジケーターを表示します（キーを使用した制御に重要）。
これは一見混乱するかもしれませんが、Webの観点から見た場合に限られます。 Webレルムでは、アクションコマンドの開始時にOnClick（MouseDown）を使用します。ただし、DragAndDropおよびTouch（ホールドアンドジェスチャ）には欠点があるため、これは変わる可能性があります。
学習する可能性があります-コマンドがMouseUp/onMouseUpでのみ起動すると、開発者の生活が楽になります。
その他の（よく知られている）学習-青は、色覚障害のあるユーザーに適した指標です。 （すべてのインタラクティブ要素の中で）アクティブな要素のインジケーターは、キーボードの使用には必須であり、全体的な向きに適しています。
そして、それがどのように反応するかを見るためにクリックアンドホールド/タッチアンドホールド（DragAndDropまたはコンテキストメニュー）を試すことができるので、インタラクティブな要素の学習可能性を促進しますが、マウスを離してボタンを離すことで意図されたクリックをキャンセルできますクリックできない領域。