web-gelistirme-sc.com

İdari Başvuruda Etkili Tarihlerle Başa Çıkma

Sigorta temelli bilgilerle uğraşırken çoğu zaman verilerimizin çoğunda Etkili Tarihler kullanımını uygulamamız gerekir. Bunun, tasarımın bir kısmının değiştirilemeyeceğini söylemeye gerek yok, çok fazla nedeni var.

Sık sık karşılaştığım sorun, bu veriler için iş kullanıcılarımız için bir yönetim arayüzü oluşturmam gerektiğidir. Genellikle hangi ekranın üstünde olursa olsun, kullanıcı geçerli bir tarih seçer. Bu yürürlük tarihi, düzenleme amacıyla kendilerine sunulan verileri yönlendirir. (yani verilerin o zaman dilimi için geçerli olduğu)

Şimdi kullanıcı her değişiklik yaptığında, bu değişikliğin geçerlilik tarihini isteriz. Sonra kullanıcının yaptıklarına bağlı olarak bir veritabanı değişikliği yaparız.

  • Bir kaydı sildiklerinde, kaydın bitiş tarihini
    değişikliğin yürürlüğe giriş tarihi.

  • Bir kaydı güncellerse eski kaydı bitirir ve yeni bir kayıt oluştururuz
    yeni yürürlük tarihi ile kayıt.

  • Bir kayıt eklerse ... iyi bir kayıt ekleriz.

İşte iyi bir kullanıcı arayüzü/kullanıcı deneyimi ile karşılaştığım sorunlar.

  1. Kullanıcı sürekli olarak bir değişikliğin geçerlilik tarihini bize bildirmek zorundadır. Bu kullanıcı için hantal ve sinir bozucu.

  2. Kullanıcı, değişikliği hemen etkili hale getirmedikçe değişiklikleri ekranlarında göremez. Bunun nedeni, ekranın üst kısmındaki geçerlilik tarihinin seçilmesidir. Buna ek olarak, neredeyse hiçbir zaman bir değişikliği hemen etkili kılmazlar.

  3. Son olarak, gerçekte bekledikleri değişiklikleri yapmadığımızdan, verileri yalnızca tablo biçiminde gösteremeyiz, çünkü onlar için pek mantıklı olmaz. Orada bir kez bir veri olduğunu düşünürlerdi, ama 25 değişiklik nedeniyle 25 kez göreceklerdi.

Böyle bir soruna yardımcı olmak için bir kullanıcı arayüzünde ne tür değişiklikler yapacağınız konusunda geri bildirim alabileceğimi umuyordum. İnsanların sıklıkla uğraşmaları gereken bir sorun olup olmadığından emin değilim, ancak sigorta endüstrisinde çok sık uğraşmamız gerekiyor. Teknoloji önemli değil, Kalın İstemci, Web Uygulaması vb.

Düzenle

Biraz daha açık olmak.

  1. Bahsettiğim uygulama, arka uç verilerinin değiştirilmesini idare eden idari uygulamadır. Gerçek uygulamanın kendisi, söz konusu arka uç verileri kullanılarak zaten yerinde ve çalışıyor.
  2. Geçerlilik tarihlerine atıfta bulunurken. Gerçek uygulama veri istediğinde, o tarihte hangi kayıtların "Etkili" olduğunu bulmak için geçerlilik tarihinden geçer. Boş veya doldurulmuş karşılık gelen bir "Bitiş Tarihi" vardır. 20 tablodan oluşan bir veritabanında, muhtemelen en az 10 tanesi kayıtlarında geçerli tarihlere sahip olacaktır.
  3. Dediğim zaman beklediklerini yapmıyoruz. Demek istediğim, "Bu kaydı sil" diyorlar ve biz aslında tarihi sonlandırıyoruz. "Bu kaydı güncelle" diyorlar ve biz de tarihi sonlandırıyoruz ve yeni bir kayıt oluşturuyoruz.
  4. Her girişin geçerlilik tarihi vardır. Bu yeni bir kayıtsa, uygulamanın hala ne zaman yürürlüğe girdiğini bilmesi gerekir ve bunun nedeni basitçe işin istediği zaman veya belirli bir yasa yürürlüğe girdiği zaman olabilir. Tahmin etmenin bir yolu yok.

Bir işlem tamamlandıktan sonra kullanıcıya onay/durum mesajları gönderebilirim, ancak yapmaya çalıştığım, bu işlemi biraz daha pürüzsüz, daha bilgilendirici ve sezgisel hale getiren bir kullanıcı arayüzü uygulamak. son kullanıcı. Bu nedenle, arka tarafta gerçekten olup bitenlerin her küçük ayrıntısını bilmeseler de, ihtiyaç duydukları şeyi yaptığından emin olacaklar.

5
Jeff Sheldon

Her sekme geçerli bir tarihi temsil eden dikey bir sekme arayüzü oluşturabilir misiniz? Bu geçerli tarihten itibaren verileri görmek için bir sekmeyi tıklayın. (Apple'ın Time Machine'i süslü animasyon olmadan düşünün.)

Değişiklik yapmak için, kullanıcı geçerlilik tarihi girmekle başlar. Bu, düzenlenebilir alanlarla yeni bir sekme, kendisinden önce gelen sekmenin bir kopyasını oluşturur ve seçer. Dolayısıyla, hangi etkin tarihin düzenlendiği açıktır ve sekmeleri tıklayıp politikayı diğer noktalarda görüntülemek de mümkündür.

Burada önerilen modelle, bir politika asla "sona ermez" (DB'de hala bir bitiş tarihi olsa da); bunun yerine bir sonraki yürürlük tarihi geçecektir.

Ne yazık ki bu, politikanın asla son geçerlilik tarihinden sonra bitmediği anlamına gelir. Son sekmeyi politikanın sonunu gösteren bir işaretçi yapabilirsiniz. Dolayısıyla, "silmek" yerine, kullanıcılar yalnızca bitiş sekmesinin geçerlilik tarihini değiştirecektir. (Yine de bir "sil" düğmesi olabilir - bitiş sekmesinin geçerlilik tarihini bugüne değiştirir).

4

Her değişiklik için belirli bir geçerlilik tarihi vermeleri gerekip gerekmediği konusunda kullanıcıdan geçerli bir tarih istemesi zor olabilir . Yine de bazı fırsatlar var. Kullanıcıların yazılımınızı nasıl kullandığına dair biraz araştırma yapın ve bazı kalıpları bulabileceğinizi görün. Örneğin, kullanıcılar hesapları yönetiyor olabilir ve hesaplar her zaman ayın son gününde değiştirilir. Bu durumda, kullanıcılara bu mutasyonlar için belirli tarihler hakkında soru sormayı bırakabilir ve bunun yerine yalnızca onlar için doldurun (varsayılan bir seçenek belirleyerek veya neyin en iyi olduğunu görmek için kontrol - kullanıcı testini gizleyerek). Ayrıca, belirli şeylerin gerçekleştiği yıl veya her ay periyodik tarihler olup olmadığını kontrol edebilir ve bunları bunları şablon olarak sunabilirsiniz. Örneğin, "Performans İnceleme Günü" veya "Her ayın son Cuma". Sonuçta, iş akışını nasıl optimize edebileceğinizi ve kullanıcı tarafında girişi azaltabileceğinizi görmek için kalıpları tanımlamanız gerekir.

Düzenleme: silindi ve neler olduğunu bilmiyordum cevabının çoğundan kurtuldum

3
Rahul