it-swarm-ko.com

관리 응용 프로그램에서 유효 날짜 다루기

보험 기반 정보를 다룰 때, 대부분의 데이터에 유효 날짜를 사용하도록 구현해야하는 경우가 종종 있습니다. 디자인의 일부를 변경할 수 없다고 말할 필요가없는 여러 가지 이유가 있습니다.

내가 자주 겪는 문제는 비즈니스 사용자를 위해이 데이터에 대한 관리 인터페이스를 만들어야 할 때입니다. 일반적으로 화면의 맨 위에있는 사용자는 유효 날짜를 선택합니다. 이 유효 날짜는 편집 목적으로 제공되는 데이터를 결정합니다. (즉, 해당 기간 동안 데이터가 효과적 임)

이제 사용자가 변경을 할 때마다이 변경의 유효 날짜를 요청합니다. 그런 다음 사용자의 행동에 따라 데이터베이스를 변경합니다.

  • 레코드를 삭제 한 경우 실제로는 레코드의 종료 날짜를 다음과 같이 표시합니다.
    변경 날짜.

  • 레코드를 업데이트하면 이전 레코드 날짜가 끝나고 새 레코드가 만들어집니다.
    새로운 유효 날짜를 기록하십시오.

  • 그들이 레코드를 추가하면 ... 음 우리는 레코드를 추가합니다.

좋은 UI/사용자 경험으로 겪고있는 문제는 다음과 같습니다.

  1. 사용자는 변경 날짜를 지속적으로 알려야합니다. 이것은 사용자에게 번거롭고 성가신 일입니다.

  2. 변경 사항을 즉시 적용하지 않으면 사용자가 화면에서 변경 내용을 볼 수 없습니다. 이것은 화면 상단에서 유효 날짜를 선택했기 때문입니다. 또한 거의 즉시 변경 사항을 적용하지 않습니다.

  3. 마지막으로, 실제로 변경하는 것은 아니기 때문에 데이터를 표 형식으로 표시 할 수는 없습니다. 데이터는 그다지 의미가 없기 때문입니다. 그들은 한 조각의 데이터가 한 번 있다고 생각하지만 25 가지 변경으로 인해 25 번 볼 수 있습니다.

이와 같은 문제를 해결하기 위해 UI에 어떤 종류의 변경 사항을 적용했는지에 대한 피드백을 얻을 수 있기를 바랍니다. 사람들이 자주 다루어야하는 문제인지 잘 모르겠지만 보험 업계에서는 자주 다루어야합니다. 기술은 중요하지 않습니다. Thick Client, Web App 등.

편집하다

조금 더 명확하게.

  1. 내가 언급하는 응용 프로그램은 백엔드 데이터의 수정을 처리하는 관리 응용 프로그램입니다. 실제 애플리케이션 자체는 이미 백엔드 데이터를 사용하여 실행 중입니다.
  2. 유효 날짜를 언급 할 때. 실제 응용 프로그램이 데이터를 요청하면 해당 날짜에 "유효한"레코드를 찾기 위해 유효 날짜를 전달합니다. 해당 "종료 날짜"가 null이거나 채워져 있습니다. 20 개의 테이블이있는 데이터베이스에서 10 개 이상은 레코드에 유효한 날짜를 갖습니다.
  3. 내가 말할 때 우리는 그들이 기대하는 것을하지 않는다. 내 말은, "이 레코드를 삭제합니다"라고 말하고 실제로 종료합니다. "이 레코드 업데이트"라고 말하고 실제로 날짜를 끝내고 새 레코드를 만듭니다.
  4. 모든 항목에는 유효 날짜가 필요합니다. 새로운 기록 인 경우, 애플리케이션은 여전히 ​​효력이 발생하는 시점을 알아야하며, 추론은 단순히 비즈니스가 원하는시기 또는 특정 법률이 시행되기 때문일 수 있습니다. 추측 할 방법이 없습니다.

작업이 완료되면 간단히 확인/상태 메시지를 사용자에게 게시 할 수 있지만, 내가하려고하는 것은이 프로세스를 조금 더 매끄럽고보다 유익하며 직관적으로 만드는 사용자 인터페이스를 구현하는 것입니다. 최종 사용자. 따라서 실제로 백엔드에서 일어나는 일에 대한 모든 작은 세부 사항을 알지 못할 수도 있지만 필요한 일을하고 있다고 확신 할 것입니다.

5
Jeff Sheldon

각 탭이 유효한 날짜를 나타내는 세로 탭 인터페이스를 만들 수 있습니까? 해당 날짜를 기준으로 데이터를 보려면 탭을 클릭하십시오. (멋진 애니메이션없이 Apple의 Time Machine을 생각하십시오.)

변경하려면 사용자는 유효 날짜를 입력하는 것으로 시작합니다. 그러면 편집 가능한 필드가있는 새 탭과 그 이전 탭의 복사본이 만들어집니다. 따라서 어떤 유효한 날짜를 편집하고 있는지 명확하게 알 수 있으며 탭을 클릭하고 다른 시점에서 정책을 볼 수도 있습니다.

여기서 제안 된 모델을 사용하면 정책이 "종료"되지 않습니다 (DB에는 여전히 종료 날짜가 있음). 다음 발효 일로 대체 될 것입니다.

불행히도 이는 정책이 마지막 유효 날짜 이후에 끝나지 않음을 의미합니다. 마지막 탭을 정책의 끝을 알리는 마커로 만들 수 있습니다. 따라서 사용자는 "삭제"대신 종료 탭의 유효 날짜 만 변경하면됩니다. (아직 "삭제"버튼이있을 수 있습니다. 종료 탭의 유효 날짜가 오늘로 변경됩니다.).

4

각 변경에 대한 유효 날짜를 사용자에게 묻는 것은 어렵습니다 각 변경에 대해 특정 유효 날짜를 제공해야하는 경우. 그러나 몇 가지 기회가 있습니다. 사람들이 소프트웨어를 어떻게 사용하고 있는지 조사하고 패턴을 알아낼 수 있는지 확인하십시오. 예를 들어 사용자가 계정을 관리하고 있고 계정은 항상 매월 마지막 날에 변경됩니다. 이 경우 해당 돌연변이에 대한 특정 날짜에 대해 사용자에게 묻지 말고 대신 기본 옵션을 선택하거나 컨트롤-사용자 테스트를 숨겨서 가장 적합한 것을 확인하여 돌연변이를 채우십시오. 또한 일년 내내 또는 매달 특정 날짜가 발생하는 정기적 인 날짜가 있는지 확인하고 템플릿으로 제공 할 수 있습니다. 예를 들어 "성능 검토 일"또는 "매월 마지막 금요일"입니다. 궁극적으로 패턴을 식별하여 워크 플로우를 최적화하고 사용자 측의 입력을 줄일 수있는 방법을 확인해야합니다.

편집 : 삭제되지 않고 내가 무슨 일이 있었는지 몰랐던 대부분의 답변을 제거했습니다.

3
Rahul