Standardy interfejsowe Teneum

W dokumencie tym zebrano standardy, które należy stosować, aby wszystkie nasze aplikacje wchodzące w skład systemu Teneum wyglądały podobnie. Zawiera także dobre praktyki, dzięki którym nasze interfejsy użytkownika są spójne i czytelne.

W ustaleniu standardów uczestniczyli: Marcin Smereka, Damian Dziuba, Wioleta Mijas, Mateusz Jawulski, Piotr Operacz, Jakub Czyżkowski, Paweł Michoń.

Założenia

1. Standardy dotyczą okien Neosowych. Stare zostawiamy w spokoju. Standardy nie dotyczą Androida (technologii NeosX).

2. Różne moduły, tworzone przez różne zespoły / osoby mają sprawiać wrażenie, że są częściami jednego większego systemu, dlatego w ogóle powstają te standardy.

3. Monitory dziś są dosyć szerokie ale mają niewiele miejsca na wysokość (bo paski windowsa, bo wstążka aplikacji, itp), więc warto okna podzielić logicznie na kolumny / szpalty, ale nie warto dzielić okien na część górną i dolną.

4. Staramy się być konsekwentni i tytuły najważniejsze dane / parametry umieszczać u góry po lewej, a akcje u góry po prawej dla wszystkich typów okien. Dzięki temu użytkownicy przyzwyczają się, gdzie czego szukać.

5. Musimy dostosować się do ograniczeń windowsa i dysponujemy tylko następującymi typami okien:

   a. MDI - czyli zakładki, które działają równolegle, można się międzi nimi przełączać i z ich poziomu otwierać kolejne okna MDI oraz modalne

   b. Modalne - czyli okna, które blokują to, co jest pod spodem. Z okna modalnego można otworzyć jedynie kolejne okno modalne.

   c. Wolne - czyli okna, które nie blokują tego, co jest pod spodem, ale nie można ich zminimalizować ani zmaksymalizować, a więc przysłaniają inne treści. Można jednak takie okna dokować do lewej lub prawej strony.

Typy okien

Standardy budowania interfejsów wyróżniają kilka typów okien. Każdy typ okna opisano w osobnym rozdziale.

Okno typu Master Browse

Co to za okno?

Jest to okno typu MDI (pokazujące nową zakładkę na pulpicie aplikacji) zawierające co najmniej grida z listą danych. Możemy jednocześnie uruchomić wiele okien MDI, które działają niezależnie.

Do czego służy, kiedy go używać?

Każde okno które uruchamiamy ze wstążki, a zawiera tabelę z danymi jest typu Master Browse.

W szczególności okna zawierające całą dziedzinę kluczowych kartotek (lista klientów, towarów, zamówień, dokumentów magazynowych, itp) powinny być typu Master Browse.

Jeśli okno nie zawiera kluczowej kartoteki, ale oprócz tabeli z danymi będzie zawierać zagnieżdżone inne okna (przeglądania lub edycyjne) także powinno być typu Master Browse.

Układ okna

Zawsze wyróżniamy lewą i prawą stronę okna, nie robimy nigdy podziału góra / dół.

• po lewej stronie umieszczamy główną tabelę z listą rekordów, a nad nimi tytuł okna, akcje i parametry do filtracji

• po prawej stronie możemy umieścić jedną lub kilka zakładek zawierające zagnieżdżone okna typu detail browse, detail edit. Jeśli zawieramy tam panel edycyjny to robimy aby był nieedytowalny (odznaczamy znacznik "Wnętrze jest edytowalne").

Tytuł okna (nazwa widoku)

Znajduje się w lewym górnym rogu okna. Powinien on odzwierciedlać domyślną dziedzinę wyświetlanych danych, np "Klienci" (jeśli nie filtrujemy niczym), "Klienci aktywni", "Faktury sprzedaży", "Rozrachunki nierozliczone", itp. Pierwsze słowo to nazwa kartoteki a kolejne słowa definiują dziedzinę. Filtracja na company nie powinna być widoczna w tytule. Tytuł może być statyczny lub dynamiczny. Jego statyczna wartość pochodzi z etykiety kontrolki TABLE, jeżeli jednak chcemy dynamicznie generować jej wartość to musimy przeciążyć metodę GetGridViewLabel(). Obok etykiety automatycznie pokazuje się przycisk służący do zmiany ustawień widoku lub zdefiniowania nowych ustawień widoku. Jeśli w oknie mamy zdefiniowane i zapisane ustawienia widoku, to załadowanie zapisanych ustawień spowoduje, że automatycznie w miejsce tytułu okna pojawi się tytuł załadowanych ustawień widoku.

Tytuł okna na zakładce z listą otwartych okien

Powinien być stały i jasno informować, co znajduje się w oknie bez określania konkretnej dziedziny, np "Klienci", "Faktury". Jeśli mamy osobne okna do faktur sprzedaży i zakupu, to w tytule okna na zakładce także powinno być to odzwierciedlone, czyli "Faktury sprzedaży", "Faktury zakupu"

Parametry filtracji

Często jest potrzeba aby filtrować dane w tabeli. W tym celu tworzymy parametry obiektu biznesowego i umieszczamy je na formie w sekcji "parameters:", jaką widać w Neos Expercie po umieszczeniu komponentu TABLE na formie. Nigdy dla parametrów nie należy tworzyć osobnego kontenera typu left-right panel.

W oknie typu Master Browse parametry automatycznie rozmieszczą się w drugim wierszu zaraz poniżej tytułu okna, od lewej do prawej.

Parametry do filtracji mogą przyjmować dowolny sposób edycji (EDIT, COMBOBOX, CHECKBOX, itp). Należy inicjować parametry takimi wartościami, aby reprezentowały filtr, jaki najczęściej będzie stosowany w danym oknie. Chodzi o to aby użytkownik nie musiał przestawiać parametrów filtracji za każdym razem jak otworzy okno.

Jeśli stosujesz parametr typu COMBOBOX lub DROPDOWN, w liście wartości nie umieszczaj elementu "wszystkie" ani "dowolny". Traktuj pustą wartość parametru, jako wartość neutralną. W związku z tym słownik wartości nie powinien mieć białych znaków, aby wartość wybrana zawsze wizualnie odróżniała się od wartości pustej. Dodatkowo, podczas definiowania parametru, który dopuszcza pustą wartość zaznacz pole "Szybkie czyszczenie wartości". Spowoduje to pojawienie się w polu przycisku z krzyżykiem służącego do szybkiego wyczyszczenia wartości parametru.

Nie umieszczaj na oknie więcej niż 5-6 parametrów służących do filtracji danych. Jeśli potrzebujesz umieścić więcej, umieść je w definicji okna, ale oznacz jako niewidoczne. Będą wtedy dostępne z poziomu ustawień widoku tego okna.

Jeśli pewne parametry filtracji powinny być ustawione na pewne wartości, to należy im zdefiniować metody na inicjalizację oraz na walidację. Dzięki temu, jeśli parametry mają złe wartości, lub są puste, a nie powinny być puste, to wyświetli się komunikat walidacyjny. W metodzie na walidację warto zwrócić uwagę na sprawdzenie stanu edycji źródła danych. W szczególności, walidacja parametrów do filtracji powinna być tylko w stanie this.STATE == "B", bo jeśli tego nie uwzględnimy, to parametry będą także automatycznie walidowane w oknie edycyjnym, podczas edycji i dodawania rekordów.

Główne akcje / przyciski

Akcje należy umieszczać w sekcji "actions:", jaką widać w Neos Expercie po umieszczeniu komponentu TABLE na formie. Przyciski akcji automatycznie pojawią się nad tabelą, w pierwszej linii (tej z tytułem okna) po prawej stronie. Nigdy nie należy umieszczać w oknie komponentu "left-right panel" aby wkładać do niego przyciski akcji. Nie upieraj się, że chcesz mieć przyciski pod tabelą, albo po bokach okna. Pozwól aby Neos sam je rozmieścił w tym miejscu, w którym powinny być.

Wszystkie zasady dotyczące tworzenia akcji są wspólne dla wszystkich rodzajów okien, więc zostały opisane w osobnym rozdziale tego dokumentu.

Na liście akcji nie będzie automatycznie dodawany przycisk zamykający okno i nie należy go dodawać ręcznie. Zamykamy okna systemowymi krzyżykami lub z klawiatury (ESC).

Tabela z danymi

Zasady umieszczania kolumn w tabeli są wspólne dla wszystkich rodzajów okien, więc są opisane w osobnym rozdziale tego dokumentu.

Prawa strona okna

Po prawej stronie okna możemy mieć jedną z poniższych alternatyw:

• jeden panel zawierający obszar z polami edycyjnymi bieżącego rekordu - zrób tak, aby do edycji danych nie otwierać osobnego okna edycyjnego. Nadaj oknu edycji symbol "INNEREDIT" i zagnieźdź okno edycyjne po prawej stronie okna. Przyciski "Dołącz" i "Popraw" automatycznie przełączą w tryb edycji zagnieżdżony panel a nie otworzą nowego okna. Jeśli panel edycyjny zawiera dużą ilość pól, to może mieć zaznaczony znacznik, aby zajmować całą przestrzeń okna - wtedy pojawi się suwak między lewą i prawą częścią okna. Jeśli panel zawiera niewiele pól, może mieć szerokość ustaloną na stałe.

• jeden panel zawierający zagnieżdżone okno typu Detail Browse - jeśli w oknie chcesz mieć relację master-detail. Zrób tak np dla okna faktur, aby po lewej stronie mieć tabelę z listą faktur, a po prawej z listą pozycji faktur. Oba panele powinny mieć zaznaczony znacznik "Zajmij całą wolną przestrzeń okna" aby pojawił się między nimi suwak. Uwaga: aby między elementy zajmujące całą przestrzeń okna nie wstawiać elementów, które nie zajmują całej szerokości - takie okno jest niepoprawne. Panel z oknem detail powinien mieć niepusty tytuł, np "Pozycje dokumentu", "Szczegóły", "Załączniki".

• wiele zakładek - jeśli chcemy osadzić jednocześnie kilka innych okien, np. zarówno obszar z polami edycyjnymi jak i jedno lub więcej okien Detail Browse. Każda zakładka powinna mieć tytuł, aby dało się odgadnąć, co się kryje pod daną zakładką zanim się w nią kliknie.

• czy można w jednym oknie mieć więcej niż dwie tabele (master + detail)? Odpowiedź zawarto w tym rozdziale

Okno typu Master Edit

Co to za okno?

Jest to okno typu MDI (czyli pokazuje nową zakładkę na pulpicie aplikacji), otwarte w kontekście jakiegoś rekordu. Możemy jednocześnie uruchomić wiele okien MDI, które działają równolegle.

Do czego służy, kiedy go używać?

Jest to okno edycyjne głównych kartotek (np. towar, klient, zamówienie, dokument magazynowy).

Nawet jeśli okno edycyjne nie dotyczy jednej z głównych kartotek, ale zawiera zagnieżdżone inne okna (przeglądania lub edycyjne) także powinno być typu Master Edit.

Jeśli okno edycyjne może być otwarte przez dłuższy czas (np kilka godzin) i chcemy aby stale było na ekranie na swojej własnej zakładce i nie przeszkadzało w pracy z innymi oknami, także może być typu Master Edit.

Okno edycyjne, w którym chcemy mieć funkcje umożliwiające otwieranie innych okien Master Browse lub Master Edit, także powinno być typu Master Edit.

Układ okna

Zawsze wyróżniamy lewą i prawą stronę okna.

• po lewej stronie umieszczamy główny panel edycyjny z polami rekordu, w którego kontekście otwarto okno. Taki panel powinien być osobnym oknem o symbolu INNEREDIT, gdyż będzie wykorzystywany także w innych miejscach (np. jako panel edycyjny w formie Master Browse). Panel ten wygląda następująco:

  • u góry po lewej stronie umieszczamy tytuł okna

  • u góry po prawej stronie umieszczamy główne akcje. Do akcji stosujemy te zasady.

  • opcjonalnie, w drugiej linii może być podtytuł okna

  • w centralnej części umieszczamy wszystkie pola edycyjne

  • na dole automatycznie jest umieszczany panel z przyciskami zapisz / anuluj

• po prawej stronie możemy umieścić jedną lub kilka zakładek zawierające zagnieżdżone okna detail browse, detail edit

Tytuł okna

Tytuł powinien być dynamicznie budowany - identyfikujący rekord (np "Jagbox sp. z o.o.", "SPR/FV/123/2201", itp). Unikamy tytułu ogólnego np "Edycja danych"

Tytuł okna na zakładce z listą otwartych okien

Powinna tam być skrócona wersja tytułu okna.

Jeśli ikona okna jednoznacznie mówi, jaka to jest kartoteka, to do tytułu na zakładce nie dodajemy przedrostka. A jeśli nie ma ikonki lub jest niejednoznaczna, to na początku dodajemy przedrostek z dwukropkiem i spacją, np "Klient: Jagbox sp. z o.o.", "Faktura: SPR/FV/123/2201"

Ikona okna

Jest obowiązkowa, bo wyświetla się na liście zakładek.

Podtytuł okna

Opcjonalnie poniżej górnego paska może być drugi pasek, który zawiera jakąś długą etykietę opisową złożoną np z zestawu istotnych informacji opisujących dany rekord. Poszczególne informacje zaleca się oddzielić znakiem "middot", czyli taką kropeczką na środku. Np pod tytuł do okna danych klientów może wyglądać tak: "NIP: 123-456-78-90 ᐧ ul. Testowa 12 ᐧ 12-345 Warszawa"

Główne akcje / przyciski

Stosujemy te same zasady, co dla akcji nad tabelą

Jak układać / grupować pola na oknie?

Pola na oknie rozmieszczaj i opisuj wg zasad opisanych w tym rozdziale

Przyciski Zapisz / Anuluj

Na dole okna jest pasek na którym mamy osadzone przyciski "Zapisz" i "Anuluj". W oknach edycyjnych (tych uruchamianych w Neosie metodą ShowRecord()) dolny pasek z odpowiednimi przyciskami jest doklejany automatycznie przez Neosa. Przyciski zawsze są po prawej stronie okna, przy czym pod VCL mamy najpierw "Zapisz" potem "Anuluj", a pod Web - najpierw "Anuluj", a potem "Zapisz". Przycisk "Zapisz" jest tzw. primary buttonem, czyli przyciskiem ze skrótem klawiszowym ENTER. Powoduje to jego bardzo wyraźne wyróżnienie (pod WEB - inny kolor, pod desktop - wyboldowana czcionka).

Można w danym oknie wyłączyć automatyczne dodawanie dolnego paska i zdefiniować go w samym oknie. Robimy tak jedynie wtedy, gdy potrzebujemy dodać własne akcje związane ze sposobem zakończenia procesu edycji danych. Przykładem takich akcji są: "Zapisz jako...", "Zapisz i zamknij", "Zapisz i edytuj dane w osobnym oknie" itp. Wtedy jednak trzeba zadbać o osobną wersję okna dla desktop i dla WEB, aby dochować zasad odnośnie kolejności akcji.

Okno typu New

Co to za okno?

Jest to niewielkich rozmiarów samodzielne okno modalne zawierające pewną listę pól do edycji oraz dolny panel z przyciskami "Zapisz" / "Anuluj". W definicji obiektu biznesowego ma symbol NEW

Do czego służy, kiedy go używać?

Służy wyłącznie do dodawania nowych rekordów. Używamy go wtedy, gdy okno EDIT jest bardzo rozbudowane (jest wg standardu master edit) i po prostu jest zbyt ciężkie aby łatwo było w nim dodawać nowe rekordy.

Jeśli okno EDIT jest typu Sub Edit, to można je wykorzystać także do dodawania nowych rekordów.

Układ okna

Powinno zawierać tylko jeden obszar pól, a na nim maksymalnie 3 grupy pól. Definicje obszarów i grup opisano w tym rozdziale.

W szczególnych przypadkach okno to może działać jak kreator (wizard). Może wtedy zawierać kilka obszarów, które będą pokazywane zamiennie. Każdy obszar na dole powinien mieć przyciski "Wstecz" i "Dalej", które zmienią krok kreatora i spowodują przejście do kolejnego lub poprzedniego kroku. Aby to zaimplementować wystarczy zdefiniować parametr obiektu biznesowego, który będzie zawierał numer kroku, a każdy panel obszaru powinien mieć metodę na widoczność uzależnioną od tego parametru. Panel dla ostatniego kroku powinien zawierać przycisk "Zapisz".

Przyciski Zapisz / Anuluj

To okno na dole zawiera automatycznie dodane przyciski "Zapisz"/"Anuluj". Możemy to zmienić i dolny panel z przyciskami dodać ręcznie w definicji okna. Robimy tak wtedy, gdy chcemy dać więcej opcji zapisu, np "Zapisz i zamknij", "Zapisz i otwórz do edycji", "Zapisz i dodaj kolejny", itp.

Okno typu Sub Browse

Co to za okno?

Jest to samodzielne okno modalne zawierające tabelę lub drzewo z jakąś listą danych

Do czego służy, kiedy go używać?

Używamy go, gdy jest spełniony jeden z poniższych warunków:

• potrzebujemy wyświetlić jakąś listę, którą otwieramy jedynie na chwilę i zaraz ją zamkniemy i z tego okna nie otwieramy innych okien typu Master Browse lub Master Edit.

• okno to zawiera tylko jednego grida, nie ma w sobie żadnych innych okien zagnieżdżonych.

• obiekt posiada bardzo mało pól danych i nie potrzebujemy w ogóle osadzać okna edycyjnego, a wszystkie istotne pola mieszczą się jako kolumny tabeli

Układ okna

Praktycznie całą przestrzeń okna zajmuje jakaś tabela lub drzewo z danymi. Zasady umieszczania kolumn w tabeli są wspólne dla wszystkich rodzajów okien, więc są opisane w osobnym rozdziale tego dokumentu.

Nad tabelą może być jeden wiersz zawierający parametry filtracji z lewej i akcje z prawej. Taki wiersz będzie wygenerowany automatycznie, więc parametry i akcje w definicji okna przypinamy tak samo jak dla każdej innej tabeli. Wszystkie zasady dotyczące tworzenia akcji są wspólne dla wszystkich rodzajów okien, więc zostały opisane w osobnym rozdziale tego dokumentu.

Okno typu Dict

Co to za okno?

Jest to samodzielne okno modalne zawierające grida z jakąś listą danych oraz przycisk wyboru ze słownika.

Do czego służy, kiedy go używać?

Używamy go, gdy wyświetlamy słownik, z którego chcemy wybrać jakąś wartość. Okno typu dict może się otworzyć automatycznie, lub możemy je wywołać programowo poprzez użycie metody ShowDict(...)

Układ okna

Wygląda tak samo jak okno Sub Browse, jedynie na dole ma automatycznie dodany panel z przyciskami "Wybierz" i "Anuluj" (po prawej stronie).

Na oknach słownikowych, przycisk do zamknięcia okna jest dodawany automatycznie tylko wtedy, gdy tabelka posiada, co najmniej jedną inną akcję. Dzięki temu, okno słownika bez żadnej akcji, nie posiada niepotrzebnego panelu nad tabelką z danymi.

Okno typu Sub Edit

Co to za okno?

Jest to samodzielne okno modalne występujące w kontekście jakiegoś rekordu zawierające panel z polami edycyjnymi oraz opcjonalnie inne elementy zagnieżdżone.

Do czego służy, kiedy go używać?

Używamy go, gdy potrzebujemy wyświetlić jakieś okno edycyjne, które otwieramy jedynie na chwilę i zaraz je zamkniemy i z tego okna nie otwieramy innych okien typu Master Browse lub Master Edit.

Także wtedy, gdy okno to zawiera tylko jeden panel edycyjny, nie ma w sobie żadnych innych okien / paneli zagnieżdżonych

Także wtedy, gdy okno edycyjne musi się pokazać, gdy jakieś inne okno modalne jest aktywne. Zatem do niektórych obiektów należy zarówno zdefiniować okna MasterEdit i SubEdit. Wtedy lewa zakładka okna MasterEdit ("INNEREDIT") przechodzi jako pierwsza z zakładek okna SubEdit.

Układ okna

Okno może zawierać jeden lub więcej obszarów z polami do edycji danych. Na dole znajduje się poziomy panel z akcjami "Zapisz" i "Anuluj". Pola na oknie rozmieszczaj i opisuj wg zasad opisanych w tym rozdziale.

Jeśli okno zawiera jeden obszar, to ten obszar zajmuje całą przestrzeń okna. Jeśli zawiera więcej obszarów, to każdy obszar powinien być umieszczony na osobnej zakładce poprzez wstawienie kontenera "page-control" a w nim komponenty "top-down panel" dla poszczególnych obszarów. Przyciski "Zapisz" i "Anuluj" powinny być poza zakładkami.

Zasady umieszczania akcji na oknach

Gdzie i kiedy umieszczać akcje?

Nie wszystkie akcje trzeba umieszczać jako przyciski na oknie, gdyż akcje są także dostępne w popup menu dostępnym pod prawym przyciskiem myszy. Jeśli użytkownik powinien z danej akcji korzystać bardzo sporadycznie, pozostaw ją jedynie w popup menu. Jeśli akcja posiada skrót klawiszowy, skrót ten działa zarówno wtedy, gdy akcja jest wizualizowana przyciskiem, jak i wtedy, gdy znajduje się jedynie w popup menu. Nie działają jedynie skróty klawiszowe tych akcji, których nie ma ani jako przycisków ani w menu.

Jeśli istnieje kilka podobnych akcji (np różne operacje do wykonania na zamówieniu), to umieść je jako podelementy jednej akcji grupującej i nad tabelą umieść jedynie akcję grupującą. W przypadku akcji grupujących, akcje nadrzędne nazywamy rzeczownikiem, który najlepiej opisuje całą grupę akcji. Jeśli nie masz pomysłu na ikony dla akcji nadrzędnych, zastosuj ikonę "MI_OPERACJA" dla grupy 1 oraz ikonę "MI_6" dla grupy 2. Np. akcje "Akceptuj", "Wycofaj akceptację" i "Wycofaj do poprawy" powinny być akcjami podrzędnymi akcji nadrzędnej o nazwie "Operacje".

Note

Pamiętaj, że zagnieżdżone akcje definiowane są w zakładce "Akcje" podczas edycji obiektu. Na okno wystarczy przenieść główną akcję grupującą, pozostałe akcje zostaną wyświetlone po kliknięciu tej akcji na oknie.

Nie umieszczaj więcej niż 5-6 przycisków nad tabelką / w górnej części okna edycyjnego. Jeśli potrzebujesz zdefiniować więcej akcji, połącz je w grupę i umieść jedynie przycisk grupy (z ikonką hamburgera), jako ostatni na liście akcji. Akcje pojawią się wtedy w rozwijanym popup menu. Dzięki temu Twoje okno będzie wyglądać ładnie nawet wtedy gdy będzie zagnieżdżone jako zakładka w innym oknie i będzie mieć do dyspozycji o wiele mniej miejsca.

Nie umieszczaj przycisku służącego do zamknięcia okna. Zostanie on dodany automatycznie w razie potrzeby. Na oknach słownikowych, przycisk do zamknięcia jest dodawany automatycznie tylko wtedy, gdy tabelka posiada, co najmniej jedną inną akcję. Dzięki temu, okno słownika bez żadnej akcji, nie posiada niepotrzebnego panelu nad tabelką z danymi.

Akcje należy umieszczać w następującej kolejności:

• "Dołącz", "Popraw", "Usuń"

• pozostałe ważne akcje, które są widoczne zawsze, w szczególności:

  • akcja drukująca (sama ikonka bez etykiety)

  • potem inne ważne - specyficzne dla danego okna

• akcje grupujące inne akcje, w szczególności:

  • przycisk "Operacje" (ikonka pioruna - ICON_13) - grupujący akcje, które wykonują jakieś czynności na bieżącym rekordzie

  • przycisk "Inne dane" (ikonka trójkącika w dół - MI_6) - grupujący akcje, które przenoszą nas do innych okien pokazujących dane powiązane z bieżącym rekordem

• akcja grupująca z ikonką hamburgera (MI_MENU) pokazująca popup menu z pozostałymi, mniej ważnymi akcjami

Nie stosuje się akcji "Wyświetl", gdyż jest ona tożsama z akcją "Popraw". Technicznie realizowana jest ta sama funkcja (ShowRecord), która pokazuje okno edycyjne, ale przełączenie go w tryb edycji danych następuje dopiero po zmodyfikowaniu jakiegokolwiek pola.

Nie zawsze są potrzebne akcje "Dołącz", "Popraw" i "Usuń" w tabeli. Jeśli np edytujesz wiadomość e-mail i masz do niej listę załączników w postaci tabeli, funkcja "Popraw" nie jest w niej potrzebna. Potrzebujesz jedynie dodawać nowe załączniki i usuwać istniejące. Nie ma tu co poprawiać. Wyłącz wtedy widoczność na definicji akcji "Popraw", a zniknie zarówno z okna jak i popup menu. Czasami akcja "Dołącz" też nie jest potrzebna. Nie wszystkie bowiem rekordy dołączasz ręcznie. Np. wyżej wspomniane załączniki możesz przeciągać jako pliki z dysku, co oprogramujesz poprzez dziedziczenie metody DropFiles(). W takiej sytuacji jedynie akcja "Usuń" będzie wywoływana ręcznie, a więc tylko ona powinna być dostępna.

Nie stostujmy metody na widoczność i nie ukrywajmy przycisków z akcjami. Zamiast tego używajmy metodę na edytowalność i wyszarzajmy przyciski. Dzięki temu przyciski nie będą "skakać". Jedynie określajmy, które akcje są dostępne w pustej dziedzinie, a które nie i pozwólmy aby w pustej dziedzinie część przycisków automatycznie zniknęła.

Ukrywanie panelu nad tabelką z danymi

Jeśli chcesz, żeby nad tabelką z danymi nie był wyświetlany panel, muszą zostać spełnione następujące warunki:

1. Okno, na którym znajduje się tabelka, musi być typu Sub Browse (musi nie posiadać etykiety na kontrolce TABLE), bo dla okien Master Browse panel nad tabelką wyświetlany jest zawsze

2. Nie zdefiniowano żadnych akcji do panelu nad tabelką

3. Nie zostały dodane do panelu nad tabelką żadne akcje automatyczne (m. in. takie jak akcje Zapisz i Anuluj, które są widoczne tylko w trybie edycji). O tym, czy do panelu zostaną dodane akcje automatyczne, decydują następujące warunki, z których wszystkie muszą zostać spełnione:

   • Obiekt, na którym znajduje się okno, ma źródło danych tylko do odczytu lub jeśli nie, żadna z opcji Pozwól na szybkie dodawanie rekordu lub Pozwól na szybkie usuwanie rekordu nie jest zaznaczona

   • Na kontrolce TABLE nie jest zaznaczony checkbox Kolumny tabeli są edytowalne albo na właściwościach okna jest zaznaczony checkbox Zmiany danych zapisuj natychmiastowo lub checkbox Zablokuj całkowicie edycję danych, albo pole Pokazuj autom. Zapisz/Anuluj w trybie edycji jest ustawione na wartość nigdy

   • Obiekt, z którego pochodzi okno, nie jest analizą

4. Nie dodano do tabelki żadnych parametrów

Jeśli wszystkie powyższe warunki zostaną spełnione, to panel nad tabelką nie powinien być widoczny, o ile nie ustawiono filtra lub nie zmieniono ustawień widoku. Panel z nazwą filtra / widoku będzie widoczny tylko w momencie, gdy wybrany jest filtr / widok.

Uwaga!

Przeszkodzić w ukryciu panelu może zachowanie związane z tłumaczeniami. Załóżmy, że w pliku SMD, w parametrze Languages, ustawione są dwa języki - angielski i polski - a parametr DefaultLanguage jest ustawiony na język angielski. Jeśli w tłumaczeniach dla języka polskiego nie ma ustawionej etykiety kontrolki TABLE, ale jest ustawiona dla niej jakaś wartość w języku angielskim i użytkownik zaloguje się do aplikacji wybierając na ekranie logowania język polski, to panel tabeli zostanie wyświetlony i w etykiecie zostanie ustawiona treść tłumaczenia angielskiego (będącego językiem domyślnym). Panel wtedy wyświetli się, ponieważ etykieta kontrolki TABLE stanowi także tytuł okna i jeśli istnieje, to okno jest uznawane za okno Master Browse, dla którego panel nad tabelką jest wyświetlany zawsze. Należy wtedy usunąć etykietę z tłumaczenia.

Jak wizualizować akcje?

Akcje, które mają zdefiniowaną ikonę, która jasno bez etykiety informuje, do czego służy akcja (np ikonka drukarki) można umieszczać się w oknie jako przyciski z szerokością 1. Dzięki temu przyciski nie zajmują zbyt dużo miejsca. Nie przypisujmy ikony na siłę, jeśli nie da się znaleźć odpowiedniej.

Przyciski akcji wizualizuj jako BUTTON, a nie LABEL (link). Jako LABEL zdefiniuj jedynie wybrane akcje, które pokazują coś spoza aplikacji, np wchodzą do pomocy, otwierają jakiś link w przeglądarce związany z danymi, itp.

Uwaga!

Akcje zwizualizowane w inny sposób niż BUTTON lub LABEL będą wyświetlane jako BUTTON.

Akcje powinny być opisane jakąś etykietą. Aby zdefiniować poprawną etykietę zauważ, że akcje dzielą się na dwie grupy:

1. takie, które coś zmieniają w danych (np zmieniają stan rekordu, wykonują przeliczenia, itp)

2. akcje które jedynie kierują nas do innego okna, w celu wyświetlenia powiązanych informacji

Etykietę akcji grupy 1 sformułuj w postaci "ZRÓB_COŚ + NA_CZYMŚ", a więc czasownika w trybie rozkazującym z jakimś dopełnieniem. Np. nazwij akcję "Zaakceptuj dokument", a nie "Akceptacja dokumentu", albo "Oblicz amortyzację" a nie "Obliczanie amortyzacji".

Akcje z grupy 2 nazwij wg schematu "CO + DLA_KOGO", czyli rzeczownikiem związanym z wyświetlaną informacją i drugim rzeczownikiem określającym dodatkowe warunki. Wystrzegaj się czasowników. Np., przechodząc z okna danych klienta do faktur tego klienta, nazwij akcję "Faktury klienta" a nie "Pokaż faktury" ani "Wyświetl faktury klienta".

Akcje powinny mieć nadany symbol (unikalny w ramach obiektu biznesowego), który będzie stosowany w kodzie C#. Symbol akcji z grupy 1 powinien odpowiadać etykiecie akcji, przy czym pisze się go w języku angielskim i bez spacji, a więc "AcceptDocument", "CalculateDepreciation". Symbol akcji z grupy 2 tworzymy analogicznie, przy czym poprzedzamy go czasownikiem "Show", np. "ShowInvoicesOfCustomer". Dzięki temu, nazwy metod klasy C# będą zawsze mówiły jasno, do czego te metody służą.

Generalnie nie przypisujemy skrótów klawiszowych do akcji. Robimy to jedynie w przypadkach szczególnych, w których skrót klawiszowy może być intuicyjny, np:

• akcja wydruku dokumentu bieżącego - Ctrl+P

• akcja pokazująca pomoc lub jakąś dokumentację - F1

• niestandardowe akcje do zapisu zmian - ENTER

• niestandardowe akcje do anulowania - ESC

Jeśli bardzo zależy nam aby jakaś akcja była pod skrótem klawiszowym to wybieramy skrót Ctrl+ZNAK, przy czym unikamy znaków zarezerwowanych przez Windows (Ctrl+Z, Ctrl+X, Ctrl+C, Ctrl+V).

Niektóre akcje, zwłaszcza przeliczające coś, mogą trwać długo. Należy unikać sytuacji, w której aplikacja zwisa na czas trwania takiej akcji, gdyż to rodzi obawy użytkownika, że coś działa nie tak. Aby temu zaradzić stosuj programowanie asynchroniczne opisane w dokumentacji dla developera. Zaleca się, aby na czas trwania akcji asynchronicznej (metoda RunAsync()) przycisk akcji się wyszarzał, a etykieta zmieniała na postać "COŚ_SIE_DZIEJE..." np. "Trwa obliczanie...". Przycisk takiej akcji powinien mieć na stałe ustawioną szerokość, aby zmiana etykiety nie zmieniała szerokości przycisku i nie przesuwała innych elementów okna.

Umieszczanie kolumn w tabeli

Jakie pola umieścić jako kolumny?

Zastanów się, jakie pola umieszczasz jako kolumny tabeli. Nie umieszczaj na siłę wszystkich możliwych pól, bo scrollowanie grida w poziomie w poszukiwaniu interesujących kolumn nie jest wcale wygodne. Umieść następujące pola jako kolumny:

• identyfikujące rekord, ale nie REF (np Symbol, nazwa)

• pola, po których zwykle szukamy

• pola statusowe

Najważniejsze kolumny identyfikujące rekord umieść z lewej, a te mniej istotne z prawej. Nie umieszczaj kolumn technicznych (REF), ani zawierających niezrozumiałe dane (np jakiś STAN w postaci liczby 0 i 1 nie przetłumaczonej na opis "aktywny" / "nieaktywny" ani na ikony). Możesz także umieścić pola jako kolumny z zaznaczeniem, że są widoczne ale ukryte ("widoczność elementu" - TAK, "Czy domyślnie ukryta?" - TAK). Będą wtedy niewidoczne jako kolumny w tabelce, ale będą dostępne w ustawieniach widoków zarówno do filtracji jak i będzie możliwe ich pokazanie w ramach konkretnych ustawień widoku.

Staraj się nie tworzyć kolumn, które przeważnie są puste lub ich wypełnienie zależy od kontekstu, gdyż pusta tabela wygląda nieciekawie. Np jeśli masz pola KLIENT i DOSTAWCA, gdzie pierwsze jest wypełnione dla dokumentów rozchodowych a drugie dla przychodowych, nie umieszczaj takich pól jako kolumny, bo zawsze któraś z nich będzie pusta. Zamiast tego stwórz redundantne pole KONTRAHENT, nalicz je w BD i umieść jako kolumnę.

Stosuj kolumny dynamicznie pokazujące się i ukrywające w zależności od kontekstu wywołania okna. Możesz mieć osobne kolumny KLIENT i DOSTAWCA w jednej tabeli, ale tylko wtedy, gdy w kontekście wyświetlania dokumentów rozchodowych - kolumna DOSTAWCA jest ukryta, a w kontekście wyświetlania dokumentów przychodowych - kolumna KLIENT jest ukryta. W efekcie zawsze widoczna jest tylko jedna z nich.

Jeśli masz do zaprezentowania zbyt dużo danych, to musiałbyś tworzyć bardzo wiele kolumn w tabeli. Zamiast tego, lepiej w kolumnach umieść tylko najważniejsze pola, a pozostałą część danych umieść jako pola w osobnym oknie i osadź takie okno jako prawy panel (zgodnie z zasadami dla poszczególnych typów okien). Nadmiar kolumn możesz mieć jedynie wtedy, gdy potrzebujesz je sumować, sortować po nich, wyszukiwać, itp.

Co zrobić aby dane w tabeli wyglądały ładnie?

Określając sposób edycji pól (EDIT, CALC, DATE, COMBOBOX, itp) określasz jednocześnie sposób wyświetlania i edycji kolumn tabeli. Możesz co prawda zmienić sposób edycji bezpośrednio na kolumnie, ale należy z tego korzystać tylko w ostateczności. Zanim zmienisz sposób edycji kolumny tabeli lub pola w oknie edycyjnym zastanów się, czy nie trzeba zmienić domyślnego sposobu edycji tego pola w liście pól modelu danych obiektu biznesowego. Dostosowanie sposobu edycji pól i kolumn do rzeczywistego charakteru danych (czyli kwoty w polach CALC, daty w polach DATE, itp) powoduje, że tabela jest przyjemniejsza do czytania. Pola CALC formatują kwoty i wyrównują je do prawej strony, co ułatwia ich porównywanie.

Zawsze zastanów się nad szerokością każdej kolumny i staraj się ustawić ją na minimum, ale takie minimum, które pozwala przeczytać dane w kolumnie. Zwykle nazwy i opisy mieszczą się w szerokości 10-15, symbole - w szerokości 5-10, kwoty - w szerokości 5, daty - w szerokości 3, symbol waluty - w szerokości 2.

Tam gdzie się da, to tytuł kolumny powinien być taki sam jak tytuł pola edycyjnego. Jeśli tytuł kolumny jest bardzo długi, to zastosuj taki skrót, który zmieści się cały w szerokości kolumny, np "Akt. pł. VAT?" albo "VAT?". Pełny opis będący rozwinięciem skrótu umieść jako objaśnienie, np "Aktywny płatnik VAT?". Skrót stosuj tylko wtedy, gdy jest łatwy do zrozumienia. Tytuły pól typu boolean (dwuwartościowych) powinny kończyć się znakiem zapytania.

Jeśli pole jest dwuwartościowe, to zastosuj typ kolumny CHECKBOX. Wtedy wartość kolumny pojawi się jako checkbox. Nie stosuj tego typu do kolumn trójwartościowych (np 0,1,null).

Używaj ikon do ilustracji stanu rekordu w tabeli (np. dokument niezaakceptowany, zaakceptowany, wycofany do poprawy). Jeśli pole jest typu COMBOBOX lub DROPDOWN, w modelu danych określasz mu słownik wartości wraz z ikonami odpowiadającymi każdej wartości słownika. Ikony te mogą być użyte w kolumnach tabeli. Wystarczy aby kolumna też miała typ COMBOBOX lub DROPDOWN. Jeśli chodzi o szerokość kolumny z ikoną to:

• szerokość 1 stosujemy tylko wtedy, gdy ikona jasno mówi, jakie jest jej znaczenie i nie potrzebujemy widzieć tytułu kolumny

• szerokość 2 lub 3 wtedy, gdy potrzebujemy widzieć tytuł kolumny, a do prezentacji zawartości wystarczy nam sama ikona (bez tekstu)

• większą szerokość, jeśli do opisu wartości pola potrzebujemy zarówno ikony jak i tekstu. Tekstu potrzebujemy użyć wtedy, gdy sama ikona nie mówi jasno o stanie rekordu lub wtedy, gdy mamy więcej niż dwa stany. Nie używamy tekstu dla opisów prozaicznych, typu "tak", "nie".

Nie używamy ikon na siłę. Jeśli do jakiegoś stanu mamy tekst, a nie potrafimy dopasować ikony, to zostawiamy sam tekst. Jeśli chcemy użyć ikon, to w większości przypadków stosujemy ikony szare. Jedynie tam, gdzie chcemy przykuć uwagę użytkownika użyjmy ikon w innych kolorach. Np stan "niezaakceptowany" opiszemy ikoną czerwonego krzyżyka (MI_REDX), a stan "wycofany do poprawy / zablokowany" - ikonką kłódki (MI_PADLOCK). Dzięki temu uwaga użytkownika od razu zostanie skupiona na dokumentach niezaakceptowanych i wycofanych do poprawy. Jest to szczególnie przydatne w tabelach w których kilka kolumn jest opisanych ikoną.

Wybierz kolumnę po której dane powinny się domyślnie sortować. Najlepiej taką, na którą istnieje indeks w bazie danych. Użytkownik może zmieniać kolejność sortowania, ale nie powinien tego robić za każdym razem w nowym oknie. Jeśli chcesz wymusić konkretną kolejność rekordów w tabeli i nie chcesz aby użytkownik ją zmienił, to usuń wiersz nagłówkowy z tabeli (opcja: ukryj gadżety).

Edycja danych bezpośrednio w tabeli?

Edycję danych bezpośrednio w tabeli stosujemy tylko wtedy, gdy jest to uzasadnione:

• wymagają tego względy ergonomiczne (np. seryjne wprowadzanie danych w arkuszu inwentaryzacji, szybkie wprowadzanie cen w cennikach, itp)

• okno jest używane bardzo rzadko, ma nie wiele pól i nie ma sensu definiować dedykowanego okna edycyjnego.

Jeśli decydujesz się użyć edycji danych bezpośrednio w tabeli, to nie definiuj okna edycyjnego. Dzięki temu przyciski "Dołącz" i "Popraw" przełączą tabelę w tryb edycji i użytkownik zredaguje wszystko bezpośrednio w tabeli. Także słowniki kontrolek COMBOBOX i DROPDOWN działają bezpośrednio w tabeli. Nie działa natomiast słownikowanie w kontrolce EDIT, a więc nie ukaże się przycisk "F3".

Jeśli nie wszystkie pola mają być redagowalne, odznacz w Neos Expercie znacznik "Pole jest edytowalne" przy danej kolumnie.

A może drzewo zamiast tabeli?

Zamiast standardowego układu master-detail rozważ użycie kontrolki TREE - czyli drzewa. Możesz stworzyć widok lub procedurę SQL, która zwraca zarówno rekordy tabeli master jak i rekordy tabeli detail, przy czym tak generuje pola ID i PARENT, że rekordy tabeli detail są powiązane do rekordów tabeli master jako rekordy podrzędne. Jeśli stworzysz obiekt biznesowy do takiego widoku lub procedury, wystarczy że stworzysz w nim okno BROWSE z komponentem TREE, aby w ładny sposób zaprezentować dane w układzie master-detail.

Korzystaj z drzew w następujących przypadkach:

• masz wiele tabel detail do tabeli master i powiązania są złożone (np występuje autorelacja master-detail w obrębie rekordów jednej tabeli). Przykładem takiej struktury danych jest karta technologiczna w module produkcji, gdzie do jednej karty podłącza się surowce, operacje, itp. Zamiast budować znacznej ilości tabel w oknie i powiązań master-detail, łatwiej zbudować jedną procedurę SQL, która zwraca całą strukturę w postaci jednego drzewa.

• występuje autorelacja - np. rubryki kalkulacji karty technologicznej, wskazują na rubrykę nadrzędną (np. klient w kartotece posiada klienta nadrzędnego).

• dane do wyświetlenia są proste - do zaprezentowania każdego rekordu wystarczy jedno pole tekstowe. Np. wyświetlasz listę magazynów na pierwszym poziomie drzewa, a operatorów uprawnionych do tych magazynów - na drugim poziomie.

• potrzebujesz sortować lub wiązać dane metodą drag&drop - w drzewie możesz przeciągać rekordy nawet poza widoczną część drzewa. W tabeli tylko możesz używać drag&drop w ramach widocznych rekordów.

Nie korzystaj z drzew wtedy, gdy:

• dane master i detail są złożone i potrzebujesz wielu kolumn aby dane zaprezentować, innych dla mastera i innych dla detaila (np nagłówki i pozycje dokumentów)

• prezentujesz tabele z bardzo dużą ilością rekordów, które nie są na wejście mocno zawężane. Proces budowania drzewa wymaga bowiem pobrania wszystkich rekordów.

• dane w oknie będą często agregowane i filtrowane, sumowanie danych w tym widoku wymaga dobrego zaplanowania danych agregowanych, aby dane w węzłach nadrzędnych nie multiplikowały wartości z węzłów detaila

Jeśli używasz drzew do wizualizacji danych, koniecznie wykorzystaj ikony. Każde drzewo umożliwia wyświetlenie do dwóch ikon. Jednej ikony użyj do zobrazowania rodzaju elementu w drzewie (np. element nagłówka karty technologicznej, element surowca, element operacji, itp), a drugiej ikony do zobrazowania stanu tego elementu (roboczy, zaakceptowany, opcjonalny, itp). Użycie drugiej ikony nie jest konieczne, ale drzewo bez ani jednej ikony wygląda nieciekawie i łatwo się pogubić w jego strukturze.

Rozmieszczanie pól na oknie edycyjnym

Pojęcie grupy i obszaru

Grupa to komponent "top-down panel" gromadzący wewnątrz pola, posiadający etykietę nazywającą tą grupę, np. "Dane podstawowe", "Dane finansowe", itp. Jedna grupa nie powinna gromadzić więcej niż 10 pól. Jeśli okno zawiera tylko jedną grupę to nie nadawaj jej tytułu, gdyż wystarczy tytuł samego okna. Jeśli okno edycyjne będzie zawierać powyżej 10 pól, podziel je na kilka grup.

Obszar to fragment okna, zawierający jedną lub kilka grup pól umieszczonych obok siebie lub jedna pod drugą. Stosujemy w obszarze maksymalnie 2 kolumny z grupami. Grupy najważniejsze lub zawierające pola najczęściej edytowane umieść na górze obszaru.

Jeśli okno jest rozbudowane i zawiera więcej niż 6 grup lub grupy są tak obszerne, że ciężko je zmieścić wszystkie obok siebie wtedy budujemy okno wieloobszarowe. Obszarem jest także zagnieżdżenie innego okna, zwłaszcza gdy zawiera tabelę lub drzewo.

Jeśli pól w oknie jest kilkadziesiąt lub kilkaset, to w pierwszym obszarze zgromadź najistotniejsze grupy pól. Mniej istotne grupy pól umieść na pozostałych obszarach.

Jeśli obszar zawiera jedynie małe pola edycyjne to nie zaznaczaj obszarowi flagi "zajmij całą przestrzeń okna". Zaznacz ją jedynie wtedy, gdy obszar zawiera kontrolki gromadzące dane z wielu rekordów (TABLE, TREE, CHART, itp) albo pola z dużym tekstem (MEMO, HTMLEDIT, itp). Sprawdź, czy właściwa kontrolka zmienia rozmiar razem ze zmianą rozmiaru całego obszaru.

Jeśli kilka obszarów obok siebie ma znacznik "zajmij całą przestrzeń okna", między takimi obszarami pojawiają się "splittery", umożliwiające ręczną zmianę wielkości obszarów.

Rozmieszczenie pól wewnątrz grupy

W pojedynczej grupie umieszczaj kontrolki w wierszach, tzn. umieść left-right panel a w nim kilka pól o podobnym znaczeniu. Następnie kolejny left-right panel i kolejne kilka pól. Nie nadawaj etykiet panelom wewnątrz grupy aby zbytnio nie szatkować okna.

Standardowo neos umieszcza etykiety pól u góry, a nie po lewej stronie. Nie zmieniaj tego. W szczególnym przypadku można sterować tym ustawieniem w oknie właściwości panelu. Działa ono dla wszystkich kontrolek wewnątrz panelu, ale nie propaguje się na wewnętrzne panele.

U góry grupy umieszczaj te kontrolki które wymagają ręcznego wpisania wartości. Niżej umieszczaj te, które wymagają wypełnienia rzadziej i zwykle można je pozostawić puste lub z domyślną wartością.

Jeśli pole przechowuje tekst, który może być długi to umieść je jako jedyne w wierszu bez komponentu "left-right panel". Wtedy jego szerokość przyjmie szerokość całej grupy. Jeśli taka szerokość to zbyt dużo, możesz takie pole umieścić w wierszu z innymi polami, ale zaznacz mu znacznik "zajmij całą przestrzeń okna". Zwykle wśród grupy pól w jednym wierszu łatwo znajdziesz takie, które chcesz aby się rozciągało. Ale nie rób tego na siłę. Jeśli pole przechowuje jedynie krótki tekst lub jest typu COMBOBOX, DROPDOWN, CALC, DATE itp nie pozwól aby się rozciągnęło na całą szerokość grupy, bo to wygląda nieładnie.

Sposób edycji pól

Definiując pola modelu danych obiektu zastanów się w jaki sposób będą edytowane poszczególne pola i uzupełnij domyślny sposób edycji. Dzięki temu nawet jak stworzysz kilka okien edycyjnych, na każdym oknie dane pole będzie edytowane w taki sam sposób.

Pola tekstowe które są nigdy nie edytowalne umieszczaj w kontrolkach LABEL a nie EDIT (np. operator który zarejestrował dokument i timestamp rejestracji). Jeśli pole jest nieedytowalne a jego wartość występuje w tytule samego okna albo tytule grupy, to w ogóle go nie umieszczaj w oknie. Umieszczanie tej samej informacji dwa razy w tym samym oknie niczemu nie służy.

Ukrywanie / wyszarzanie pól

Unikaj tworzenia okien typu "rolnik", a więc nie pokazuj od razu wszystkich możliwych do wypełnienia pól. Staraj się pokazać jak najmniej pól, a więc umieść i pokaż tylko te niezbędne do wypełnienia. Ukrywaj pola, jeśli ich edytowanie ma sens tylko w pewnych przypadkach lub po wypełnieniu innych pól. Przykładowo jeśli na dokumencie możesz opcjonalnie wskazać odbiorcę ze słownika i wpisać indywidualny adres odbioru, to pokaż w oknie tylko pole służące do wskazania odbiorcy. Dopiero jeśli ktoś w to pole wejdzie i wybierze odbiorcę ze słownika, uwidocznij resztę pól umożliwiających wpisanie np innego adresu odbioru. Zadbaj jednak o taki układ pól, aby wraz z ukrywaniem / pokazywaniem jednych pól inne pola nie "skakały", czyli nie zmieniały swojego położenia.

Dla ukrywanych pól stosuj metodę na widoczność i ustaw widoczność domyślną na "nie". Nie stosuj metody na redagowalność, gdyż redagowalność należy wyłączać tylko wtedy, gdy dany operator nie ma prawa edycji tego pola, lub nie może ono być zmieniane w danym kontekście, natomiast przeczytanie jego wartości może być ważne. Np. wyłącz redagowalność dla pól pokazujących sumaryczne kwoty dokumentu, które się wyliczają automatycznie.

Etykiety i objaśnienia do pól

Definiując pola modelu danych zdefiniuj etykiety pól, które będą wyświetlane w oknach nad polami i w nagłówkach kolumn tabeli. Dzięki temu, nawet jeśli stworzysz kilka okien edycyjnych, na każdym oknie dane pole będzie opisane tak samo. Tworząc etykiety pól, kieruj się następującymi zasadami:

• Etykieta powinna być krótka i najlepiej aby była ta sama dla pola edycyjnego jak i dla nagłówka kolumny. Etykiety pól typu boolean (dwuwartościowe) kończymy znakiem zapytania. Jeśli etykieta miałaby być zbyt długa, to możemy stosować skróty, np "jedn.", "zam.", itp. Szerszy i pełniejszy opis bez stosowania skrótów umieść w objaśnieniu pola (hint). Opis w objaśnieniu może być bardzo długi, bo się sam zawija.

• W konkretnym oknie masz możliwość przeciążenia etykiety zdefiniowanej na polu modelu danych. Jeśli w tabeli BKDOCS masz pola REGOPERATOR i REGTIMESTAMP a etykiety pól modelu danych brzmią: "Operator rejestrujący dokument" i "Data rejestracji dokumentu", to w konkretnym oknie, w którym te pola występują obok siebie możesz je nazwać: "Zarejestrował" i "Dnia". Uzyskasz w oknie zwarty i jasny wygląd:

Zarejestrował Jan Kowalski Dnia 2014-12-19 13:25

• Zaczynaj etykietę wielką literą i kontynuuj małymi literami

• Nie umieszczaj na końcu znaku interpunkcyjnego (kropka, dwukropek). Jedyny wyjątek to znak zapytania przy etykietach pól CHECKBOX

Jeśli znaczenie danego pola nie jest oczywiste należy zdefiniować jego objaśnienie. W objaśnieniu możesz umieścić od jednego do kilku zdań. Jeśli pole może zmienić znaczenie w zależności od kontekstu (np od zawartości innych pól), to możesz zdefiniować metodę na objaśnienie i generować jego treść dynamicznie. Pamiętaj jednak, że objaśnienia statyczne pojawiają się jedynie gdy kursor myszy "najedzie" na pole, natomiast objaśnienia dynamiczne (generowane metodami na objaśnienie) pojawiają się samoczynnie zaraz po tym, gdy treść objaśnienia ulegnie zmianie. Możesz dzięki temu przykuć uwagę operatora w konkretnym momencie do konkretnego pola.

Dodatkowe etykiety dla pól słownikowanych

W sytuacji, gdy po wybraniu wartości ze słownika, wartość wyświetlana w polu może być niejednoznaczna, to warto na oknie zadbać o dodatkowy opis wartości wybranej ze słownika. Przykładem takiej sytuacji jest pole do wyboru klienta lub towaru ze słownika. Zwykle po wybraniu klienta w oknie wyświetlamy jego skrót. Jednak może istnieć kilku klientów o tym samym lub podobnym skrócie. Dlatego w takich przypadkach zaleca się, aby pod polem słownikowanym umieścić kontrolę LABEL zawierającą tekst opisowy zawierający dodatkowe informacje o rekordzie wybranym ze słownika. Jeśli umieścimy w tym tekście kilka niezależnych wartości oddzielmy je sekwencją znaków: spacja + middot + spacja. Middot to znak unicode kropki umieszczonej na środku. Przykład opisu do rekordu klienta:

"NIP: 123-456-78-90 ᐧ ul. Testowa 12 ᐧ 12-345 Warszawa"

Warto zauważyć, że obowiązują tu dokładnie takie same zasady, jak dla podtytułu w oknie master edit. Dlatego taką informację opisową może generować samo źródło danych obiektu biznesowego słownika i dokładnie ta sama informacja powinna być używana jako podtytuł w oknie master edit jak i opis w miejscach, w których to źródło danych jest używane jako słownik.

Przyciski z akcjami umieszczane obok pól z danymi

Wśród pól edycyjnych możesz umieszczać także przyciski z akcjami, ale tylko w następujących przypadkach:

• Akcja wpływa na wartość konkretnego pola. Np edytujemy pole RABAT i chcemy mieć wygodny sposób na zmianę rabatu +/- 1% pod jednym kliknięciem. Definiujemy zatem akcje i przyciski z etykietami +1% i -1% podpinamy pod pole RABAT. Przyciski pokazują się tak, jakby były wewnątrz pola RABAT. Jeśli zamiast etykiet dobierzemy ikonki to jeszcze lepiej.

• Akcja przenosi nas do jakiejś innej informacji powiązanej z danym polem. Np edytując pole RABAT często chcemy się dowiedzieć jaką klient ma historię rabatów na ten towar. Definiujemy zatem akcję "Historia rabatu" i umieszczamy ją obok pola RABAT. Stosujemy styl BUTTON - jeśli akcja kieruje nas do innego okna aplikacji, lub styl LABEL - jeśli akcja odpala jakiś zewnętrzny link.

Okna zawierające więcej niż dwie tabele

Jeśli posiadasz tego typu strukturę zalecane jest użycie widoku drzewa, które umożliwia wizualizację dowolnie głębokiej struktury master-detail-superdetail lub rozłączenie struktury na osobne okna, np. w jednym oknie łączymy master-detail, a po naciśnięciu przycisku na detail pokazujemy kolejne okno z danymi superdetaiil, albo w jednym oknie pokazujemy dane master, a po naciśnięciu przycisku pokazujemy osobne okno, pokazujące dwie tabele łączące detail i superdetail.

Jeśli jednak bardzo chcesz umieścić wszystkie trzy tabele w jednym oknie, możesz to zrobić, ale zorganizuj okno tak: umieść tabelę master po lewej, tabelę detail po prawej u góry, a tabelę superdetail po prawej u dołu.

Jeśli masz strukturę typu drzewo, które filtruje tabelę a do bieżącego rekordu z tabeli chcesz mieć jeszcze jakiś panel ze szczegółami, to umieść wszystkie elementy obok siebie w kolumnach, czyli: drzewo z lewej, tabelę w środku i panel ze szczegółami z prawej. Jeśli tych szczegółów jest dużo, to mogą tam być zakładki. Taki układ okna przydaje się w zastosowaniach typu:

• okno przeglądania dokumentów (z lewej drzewo folderów, w środku lista dokumentów w folderze, po prawej szczegóły wybranego dokumentu)

• okno przeglądania kartoteki towarowej (z lewej drzewo grup towarowych, w środku lista towarów w grupie, po prawej szczegóły wybranego towaru)

Różnice standardów interfejsowych między desktop a Web?

Okna przeglądania

Aplikacje Neosowe mogą być uruchamiane zarówno w kliencie desktop, jak i w kliencie WEB, pod przeglądarką. Jeśli chcesz aby Twoja aplikacja działała pod WEB, przestrzegaj następujących zasad:

• Nie twórz zbyt skomplikowanych okien. Lepiej pokazać mniej i umieścić akcję, aby zobaczyć coś wgłąb niż, pakować zbyt wiele powiązań master-detail.

• Na tablecie mieści się mniej więcej 1/4 tego, co na ekranie zwykłego komputera. Dlatego okna na tablety powinny zawierać tylko jeden grid, ewentualnie grid z jakimś dodatkowym panelem po prawej stronie.

• Stosuj template grida zwłaszcza w oknach Master BROWSE, aby dane prezentowały się ładnie.

Okna edycyjne

Aplikacje Neosowe mogą być uruchamiane zarówno w kliencie VCL, jak i w kliencie WEB, pod przeglądarką. Jeśli chcesz aby Twoja aplikacja działała pod WEB, przestrzegaj następujących zasad:

• Na tablecie mieści się mniej więcej 1/4 tego, co na ekranie zwykłego komputera. Dlatego okna na tablety powinny zawierać tylko jeden obszar.

• Formularze edycyjne dla tabletów powinny być bardzo uproszczone, gdyż na tablecie w trakcie edycji pół ekranu u dołu zajmuje klawiatura ekranowa. Planuj elementy edycyjne tylko w górnej części okna. W przeciwnym razie scrollowanie okna będzie bardzo niewygodne dla użytkownika.

• automatycznie Neos umieszcza najpierw przycisk "Anuluj" a potem "Zapisz". Nie zmieniaj tego.

Połączenie okien Neosowych z VCL

Okna MasterEDIT są typu MDI. Ale jeśli mamy inne okno otwarte modalne, to nie otworzy się nam okno MDI, tylko modalne. Dlatego należy stworzyć osobne okno EDIT, które będzie typu SubEdit z tą samą zawartością. Zamiast podziału na stronę lewą i prawą robimy wszystko na zakładkach.

Komunikaty

Rodzaje komunikatów:

• Informacja o tym, że coś się wydarzyło, co nie trwa długo (max kilka, kilkanaście sekund) np: skończył się OCR faktury, zaakceptowano zamówienie, wygenerowano fakturę do zamówienia). - używamy BaloonHinta

  • Tytuł - Jaka czynność została zakończona przez system (nie kończymy kropką)

  • Treść - Czego dokładnie dotyczyła(nazwa dokumentu, data przetworzenia)(jeżeli treść jest w formie zdania, zakańczamy kropką)

  • Ikona - IconType.INFORMATION. Jeżeli czynność zakończy się z ostrzeżeniem dajemy ikonę: IconType.WARNING

  • Akcja - jeśli chcemy aby coś się wykonało po kliknięciu w powiadomienie, to możemy przypisać akcję. Stosujmy, jeśli chcemy pokazać więcej szczegółów nt powiadomienia lub dokument, którego ono dotyczy.

• Informacja z prośbą o podjęcie decyzji w jakiejś sprawie - używamy MessageBoxa z listą akcji do wyboru.

  • Tytuł - Nazwa procesu w jakim trzeba podjąć decyzję

  • Treść - Pytanie o to jaką decyzje ma podjąć operator

  • Ikona -IconType.QUESTION

  • Akcje - Nazwa jednoznacznie ma określać działanie wykonywane po wybraniu akcji. W przypadku decyzji TAK/NIE - używamy Tak/Nie zamiast OK/Anuluj. W przypadku innych czynności używamy czasownika w trybie rozkazującym jako pierwsze słowo, np "Akceptuj", "Wystaw fakturę"m itp. Akcja najczęściej wybierana powinna być jako pierwsza. Nie używamy ikon.

• Informacja o błędzie popełnionym przez użytkownika i użytkownik może sam go poprawić - używamy MessageBox (Exclamation).

  • Tytuł - Uwaga

  • Treść - Zdanie jednoznacznie określające jakie działanie powinien podjąć operator/ czego dotyczy ostrzeżenie, jakiego dokładnie obiektu(np. jeśli brak stanu magazynowego, to zwróćmy dla którego indeksu z dokumentu itp.)

  • Ikona - IconType.WARNING

  • Akcje - Zamknij

• Informacja o nieprawidłowym zachowaniu systemu, bo coś się zaimportowało z błędem, faktura się nie zaakceptowała, itp. Użytkownik albo może na to zareagować, albo zgłosić komuś dalej, że ma problem. - używamy MessageBox (Stop).

  • Tytuł - Błąd

  • Treść - Zdanie jednoznacznie określające czego dotyczy błąd, jeśli jest wiadome, jakich danych dotyczy, zwracamy maksymalnie dużo informacji na jego temat (np. jeśli brak stanu magazynowego, to zwróćmy dla którego indeksu z dokumentu itp.). Do kogo powinien zgłosić się operator przy otrzymaniu tego komunikatu. Np. jeśli dotyczy konfiguracji/uprawnień do administratora, jeśli problem z połączeniem do administratora itp.

  • Ikona -IconType.STOP

  • Akcje - Zamknij

• Seria komunikatów nt postępu jakiegoś procesu (np import wielu wierszy z arkusza XLS, import wyciągu bankowego, zbiorcze wykonanie operacji na zaznaczonej dziedzinie dokumentów, itp) - tutaj każdy mechanizm powinien mieć jakieś indywidualne rozwiązanie, aby gromadzić historię komunikatów i móc ją potem przejrzeć na spokojnie. Przykłady:

  • mechanizm nowy importu Excel - jest okno ze statusem importu i listą błędów

  • Scheduler - ma zakładkę z historią przetwarzania