web-dev-qa-db-ja.com

作業するアイテムのキューを管理するためのユーザビリティの懸念

これが私が気になる問題の一般的な話です:

ACME Companyの安全なWebサイトには、
オンラインで処理する必要がある「初期」ステータスの何千ものウィジェット注文の表。

ACME Companyの数十人のスタッフが同時にWebサイトにアクセスし、ウィジェットの注文を取得して処理します。そのため、作業するオーダーを取得した人は、「チェックアウト済み」のオーダーを処理できる唯一の人です。

ウィジェットの注文がチェックアウトされている間、注文のステータスが変更される場合があります。その場合、ウィジェットの注文は「初期」キューの外の新しいステータスに移動するか、または何らかの理由で注文をそのままにします。次の利用可能な注文を取得するか、ページに長く留まると、アイテムがチェックアウトされたままユーザーセッションがタイムアウトする可能性がありますが、その他の変更はありません。

アイテムのキューを通過するユーザーの観点から、このワークフロープロセスをできるだけユーザーフレンドリーにするためにどのような機能を追加できますか?

たとえば、ユーザーがアイテムをチェックアウトした後、セッションがタイムアウトした場合はどうしますか?彼らは次にその項目に取り組むことを強いられるべきですか? 1つのチェックアウトされた順序から次の順序にどのように移行しますか:フィルターを指定して、次に取得するバケットのオプションをスライスしますか?等...

このトピックに関するリソースへのポインタは役に立ちます。これまでの私のグーグル検索では意味のある結果が得られなかったためです。

3
mg1075

私の提案:

  • デリゲートバッチバッチごとの限られた数のユーザー(グループ)に。これは、ユーザーがアイテムを「取る」ときの衝突のリスクを減らすためです。

  • ユーザーがアイテムを受け取ったら、データベースで確認し、利用可能な場合はタイムスタンプを付けてそのユーザーのデータベースのステータスを設定します。利用できない場合は、衝突のあるポイントを参照してください。

  • タイムアウトを時々確認します-アイテムのアクティビティがx分間ない場合は、ロックを解除します。このタイムアウトは、セッションタイムアウトが発生した場合でも、使用中のアイテムを誤ってロック解除しないようにするために適切である必要があります。セッションのタイムアウトは問題になりませんが、他のタイムアウトの場合は、可能であればアイテムを自動的に再取得するか、タイムアウトのために新しいアイテムに転送されたことをユーザーに通知します。

  • バッチが完了したら、新しいバッチをグループに割り当てます

  • ユーザーが次のアイテムに移動すると、自動的に前のアイテムのロックを解除します(ユーザーはロック解除を忘れているため、これを自動的に行います)。

  • 衝突が発生した場合(多くのユーザーでこれが発生する可能性があります)、ユーザーを次のアイテムに転送し、選択したアイテムが取得され、新しいアイテムが割り当てられたことをユーザーに示します。

  • 再キューイングが必要なステータスを取得したアイテムは、新しいバッチに転送されるだけです。

バッチは常にバックグラウンドで作成されます。すべてのアイテムでキューを作成する代わりに、バッチでキューを作成します。

バッチアプローチを使用すると、衝突のリスクを減らすことができますが、同様のアイテムをグループ化して処理のリズムを改善することもできます。シナリオに応じて、ユーザーの出身地、会社、カテゴリ、ステータスなどに基づいてアイテムをバッチで割り当てるなど、他の多くの要素に基づいてバッチを作成することもできます。

私の2セント。

2
epistemex