最近使用したファイルのリストにある存在しないファイルは、ユーザープロンプトなしで削除する必要がありますか？
たとえば、アプリケーションに「最近使用したファイル」または「頻繁に使用するファイル」という共通点があるとします。
ユーザーが最近/頻繁に開いたファイルを移動または削除するのは簡単なことです。では、ユーザーが最近/頻繁に使用するリストでそのファイルをクリックするとどうなるでしょうか。
- 彼らは明らかに、ファイルがもう存在しないというフィードバック/通知を受け取るはずです。
- さて、ここで質問です：アプリケーションはリストから見つからなかったファイルも自動的に削除しますか？
議論
これについて私が持っているいくつかのアイデア：
- （+）長所：とにかく、ユーザーがそのようなファイルを開くことはできないため、このエントリはまったく役に立ちません。そこに留まれば貴重なスペースを奪います。
- （–）反対：場合によっては、ファイルを一時的に削除することしかできません。 Androidの場合は、これは決して当てはまりませんが、デスクトップシステムのネットワーク共有（FTPやsambaなど）で発生する可能性があります。このような場合、ユーザーはオフラインでファイルを後で開くことができます。
一方、アプリケーションはこれらのものをブラックリストに登録できます。 （ファイルパスを見てから） - （+）プロンプト：ファイルを削除するかどうかをユーザーに確認することもできます。ただし、ファイルが本当になくなった場合、これは単なるクリックであり、おそらく明白なので、これは実際にはまったく役に立たない可能性があります。
- （-）反対のプロンプト：通常、確認プロンプトは 最適なUXパターンとは見なされません なので、実際には「元に戻す」機能でここで意味があります。しかし、この場合、ユーザーを完全に混乱させることなく、これをどのように実現できますか？ （1.ファイルが見つからなかったことをユーザーに通知するためにも1.を行う必要があることに注意してください。）
- （-）手動での削除のみ：自動化することもできず、ユーザーがそれぞれの横にある「x」などをクリックすることしかできませんエントリなので、手動で削除できます。しかし、私見ではこれは非常に不十分です。この機能は独立して有用/必要かもしれませんが、ファイルがなくなった場合、アプリケーションとして完全に賢く、少なくともユーザーに自動的に削除することを提案できます。ユーザーが最初にエラーメッセージthinkを解釈してから、（正しい）エントリを手動で削除して適切に対応する必要があるのはなぜですか？ （これは「難しい」と思いますが、多くのユーザーがそうすることさえあるとは思いません。これもまた、リストの「壊れた」エントリを「蓄積」する可能性があります。）
ユーザーが最近使用したリストからファイルにアクセスしようとして、ファイルが見つからない場合、アイテムをリストから削除する必要があります。ユーザーにはファイルが存在しないことが通知されています。彼らは再びこのプロセスを経る必要はありません。彼らが再びファイルを見つけて開くと、、次にリストに戻ります。
考えてみると、開いているファイルだけがリストに表示されます。ファイルが閉じられ、しばらくしてから再度開かれた場合、リストアイテムにアクセスすると、ファイルが選択された時点で、リストからすぐに削除されます。その時点でのどの位置からも削除されることに注意してください-それはもはや最初ではないかもしれません。そして、successfullyが開かれると、リストの先頭に追加されます。
これにより、リストを適切に維持できます。アクセスされたファイルはすぐに削除され、それらを実際に開くことができない場合、リストに戻ることもありません。
一方、アクセスできないファイルをリストのn番目に残した場合-これは、ファイルが開かれなかった場合（ケースではない）と同じ結果で、リストの一番上に移動した場合と同じです。正常に開かれたことを意味します（ケースも異なります）。