it-swarm-eu.dev

Řešení skutečných dat v administrativní aplikaci

Při nakládání s informacemi založenými na pojištění často musíme implementovat použití efektivní data na většině našich údajů. Existuje mnoho důvodů, proč se do toho nedostanu, netřeba dodávat, že část designu nelze změnit.

Problémem, na který často narazím, je situace, kdy musím pro naše firemní uživatele vytvořit administrativní rozhraní pro tato data. Obvykle v horní části jakékoli obrazovky, na které se nachází, si uživatel vybere datum účinnosti. Toto účinné datum určuje, jaká data jsou jim předkládána pro účely editace. (tj. tato data jsou účinná pro dané časové období)

Nyní, kdykoli uživatel provede změnu, žádáme je o datum účinnosti této změny. Poté provedeme změnu databáze podle toho, co uživatel udělal.

  • Pokud odstranili záznam, označíme vlastně datum ukončení záznamu jako
    datum účinnosti změny.

  • Pokud aktualizují záznam, ukončíme datum starého záznamu a vytvoříme nový
    záznam s novým datem účinnosti.

  • Pokud přidají záznam ... přidáme záznam.

Zde jsou problémy, se kterými se setkávám při dobrém uživatelském rozhraní/uživatelském prostředí.

  1. Uživatel nám musí neustále sdělit datum účinnosti změny. To je pro uživatele těžkopádné a nepříjemné.

  2. Uživatel nevidí změny na své obrazovce, pokud neprovádí změnu okamžitě. Je to kvůli tomu, že datum účinnosti je vybráno v horní části obrazovky. Navíc téměř nikdy neprovádějí okamžitou změnu.

  3. A konečně, protože ve skutečnosti neprovedeme změny, které očekávají, nemůžeme jim pouze ukázat data v tabulkovém formátu, protože by jim to příliš nedávalo smysl. Jednou by si mysleli, že je tam kousek dat, ale viděli by to 25krát kvůli 25 změnám.

Doufal jsem, že se mi podaří získat zpětnou vazbu o tom, jaké změny v uživatelském rozhraní provedete, abych pomohl s takovým problémem. Nejsem si jistý, jestli je to problém, se kterým se lidé musí často vypořádat, ale v pojišťovnictví se s ním musíme vypořádat velmi často. Na technologii nezáleží, hustý klient, webová aplikace atd.

Upravit

Být trochu jasnější.

  1. Aplikace, na kterou odkazuji, je administrativní aplikace, která se zabývá úpravou dat typu backend. Samotná samotná aplikace je již na místě a běží pomocí uvedených dat z koncových zařízení.
  2. Při odkazování na datum účinnosti. Když skutečná aplikace požaduje data, předá se datum účinnosti, aby se zjistilo, jaké záznamy jsou k tomuto datu „účinné“. Existuje odpovídající „Datum ukončení“, které je buď nulové, nebo naplněné. V databázi 20 tabulek bude mít pravděpodobně nejméně 10 dat datum jejich účinnosti.
  3. Když říkám, neděláme to, co očekávají. Mám na mysli to, že říkají „Smazat tento záznam“ a vlastně jej ukončíme. Říkají „Aktualizujte tento záznam“ a my ho vlastně ukončíme a vytvoříme nový.
  4. Každá položka vyžaduje datum účinnosti. Pokud se jedná o nový záznam, musí aplikace stále vědět, kdy vstoupí v platnost, a zdůvodnění by mohlo být jednoduše proto, že v tom případě, kdy to podnik potřebuje, nebo proto, že tehdy vstoupí v platnost určitý zákon. Neexistuje způsob, jak to uhodnout.

Je pravda, že mohu po dokončení akce jednoduše uživateli zasílat potvrzovací/stavové zprávy, ale to, co jsem se snažil udělat, je implementovat uživatelské rozhraní, které tento proces dělá trochu plynulejším, informativnějším a intuitivnějším pro uživatele. koncový uživatel. Takže i když nemusí vědět každý malý detail toho, co se vlastně děje na zadní straně, budou mít jistotu, že dělají to, co potřebují.

5
Jeff Sheldon

Mohli byste vytvořit vertikální rozhraní karet, přičemž každá karta představuje účinné datum? Kliknutím na kartu zobrazíte data k datu účinnosti. (Přemýšlejte o stroji Apple Time Machine bez fantastické animace.)

Aby uživatel provedl změnu, začal by se zadáním účinného data. To vytvoří a vybere novou kartu, kopii té, která jí předcházela, s upravitelnými poli. Je tedy zřejmé, jaké datum účinnosti se upravuje, a je také možné proklikat karty a zobrazit zásady v jiných časových okamžicích.

Se zde navrhovaným modelem by politika nikdy „nekončila“ (ačkoli v DB stále existuje datum ukončení); bude to nahrazeno nejbližším datem účinnosti.

Bohužel to znamená, že politika nikdy neskončí po posledním datu účinnosti. Poslední záložku byste mohli označit jako značku signalizující konec zásady. Takže místo „mazání“ by uživatelé jednoduše změnili datum účinnosti koncové karty. (Můžete mít stále tlačítko „smazat“ - datum účinnosti karty Konec by se tak změnilo na dnešek).

4

Je těžké se obejít a požádat uživatele o datum účinnosti pro každou změnu pokud musí pro každou změnu uvést konkrétní datum účinnosti. Existuje však několik příležitostí. Proveďte průzkum toho, jak lidé používají váš software, a zjistěte, zda můžete zjistit některé vzorce. Například uživatelé pravděpodobně spravují účty a účty jsou vždy mutovány v poslední den v měsíci. V takovém případě byste se mohli přestat ptát uživatelů na konkrétní data těchto mutací a místo toho je prostě vyplňovat (výběrem výchozí možnosti nebo skrytím ovládacího prvku - testem uživatele zjistíte, co funguje nejlépe). Můžete také zkontrolovat, zda existují periodická data po celý rok nebo každý měsíc, ve kterých se určité věci odehrávají, a možná je nabídnout jako šablony. Například „Den kontroly výkonu“ nebo „Poslední pátek každého měsíce“. Nakonec je třeba určit vzory, abyste viděli, jak můžete optimalizovat pracovní postup a snížit vstup na straně uživatele.

Edit: undeleted a zbavil se většiny odpovědí, kde jsem nevěděl, co se děje

3
Rahul