Wiemy dobrze, że oprogramowanie możemy podzielić na kilka typów, biorąc pod uwagę różne kryteria. Najczęściej rozmawiamy o klasyfikacji względem urządzenia i technologii (webowa, mobilna, desktopowa itd.), ale z perspektywy profesjonalnej (biznesowej) równie istotny jest zakres odbiorców. W uproszczeniu, wśród aplikacji można wyróżnić te o dostępie publicznym oraz prywatnym, ograniczonym do określonej grupy docelowej. W obu przypadkach możemy dalej wyszczególnić podtypy, w zależności od tego, do czego oprogramowanie ma służyć i jaki jest jego model biznesowy (o ile jest, ale przypominam - mówimy o perspektywie komercyjnej). My się dzisiaj skupimy na tym drugim obszarze, a konkretnie aplikacjach dla odbiorcy wewnętrznego, najczęściej dla konkretnej firmy lub organizacji.

Charakterystyka takich serwisów jest zupełnie inna niż portali, które odwiedzamy wszyscy na co dzień:

• służą konkretnemu celowi i mają usprawniać pracę,
• funkcjonalność i użyteczność jest znacznie ważniejsza niż estetyka i marketing (to zwykle nie są serwisy pozycjonowane, choć nie mogą też odstraszać wyglądem),
• wymagania są wyjątkowo sprecyzowane i dostosowane do praktyki w danej firmie (zwłaszcza, jeśli są tam niestandardowe procedury),
• często dostęp jest dodatkowo zabezpieczony (np. VPN, brak funkcji widocznych przed zalogowaniem się),
• usługa jest wykorzystywana przez dającą się opanować liczbę użytkowników, ale za to praktycznie przez cały dzień roboczy,
• błędy mogą mieć poważniejsze konsekwencje dla funkcjonowania firmy,
• wdrożenie wiąże się czasem ze szkoleniem i opracowaniem procedury adaptacyjnej, a także migracją danych.

Tego typu systemów projektowaliśmy, implementowaliśmy lub nadzorowaliśmy dziesiątki i we wszystkich występowała większość tych punktów. Należy mieć na uwadze to, że specyfika każdego zespołu czy firmy jest inna i czasem klienci proszą o rozwiązania, które zupełnie by nie pasowały do innych systemów i środowisk. Dlaczego? Bo tak pracują, tak są przyzwyczajeni i mimo że pewne rzeczy jako software house możemy doradzić lub przed nimi przestrzec, to i tak ostatnie zdanie należy do zleceniodawcy. Co nie oznacza, że nie oczekuje podczas konsultacji propozycji rozwiązań - wielokrotnie pisaliśmy, że o ile klient jest specjalistą w swojej dziedzinie, to po to wynajmuje firmę IT (która niejedno widziała), aby mogła mu doradzić w kwestiach interfejsowych lub ogólnie informatycznych.

Jedną z takich spraw jest nawigacja - firmy zazwyczaj wiedzą, co chcą robić w systemie, ale najczęściej nie wiedzą, jak chcą dochodzić do różnych elementów. A nawet, jeśli to wiedzą, to koncentrują się na podróży od ekranu do ekranu, a nie na "poczuciu sprawczości" w aplikacji. To, gdzie w ogóle się klika, jak wygodnie docierać do elementów i znajdować przyciski - to już rola firmy IT i ich wyczulenia na UX.

Dzisiaj właśnie porozmawiamy o tym, jakie elementy nawigacyjne proponujemy naszym klientom, dla których budujemy rozwiązania wewnętrzne. W większości dotyczy to naszego systemu ComMan, który właśnie stanowi bazę do wielu serwisów obsługiwanych potem przez firmy usługowe, produkcyjne lub hybrydy tych dwóch światów. Zaczniemy od spraw w miarę oczywistych (aczkolwiek być może przedstawimy kontekst, o którym wcześniej nie myśleliście), a potem przejdziemy do tych mniej poruszanych.

Dlaczego wspominamy o systemie ComMan?

ComMan będzie obecny w naszej historii nie bez powodu i to mimo że już o nim wspominaliśmy. Po pierwsze, na bazie naszych doświadczeń i rozmów, od momentu publikacji poprzedniego materiału powstała druga wersja systemu, znacznie lepsza, a przede wszystkim będąca bazą dopasowaną do aktualnych potrzeb rynku i łatwiejszą w dostosowaniu pod konkretne zastosowanie. Po drugie, bo to - jak już wspomniałem - idealny przykład aplikacji wewnętrznej. A po trzecie, bo przy okazji projektowania ComMana 2.0 powstały rozwiązania UX już zweryfikowane przez rzeczywistych użytkowników w "boju" i które pozwalają lepiej odnaleźć sie w systemie, a nawet czerpać z niego radość.

Sam ComMan to system, który służy przedsiębiorstwom, które zajmują się wytwarzaniem różnych produktów, wyrobów, ale także świadczeniu usług, co oznacza m.in. przyjmowanie zleceń. Wspólnym mianownikiem tych firm jest to, że:

• rejestrują i śledzą zamówienia dla klientów, jak i same informacje o kontrahentach,
• posiadają inne formy spraw, które muszą monitorować i mają związek z zamówieniami, np. oferty dla swoich zleceniodawców,
• posiadają katalog produktów lub usług,
• mają jakąś formę realizacji produkcji do płytszego lub głębszego śledzenia,
• potrzebują kontroli nad magazynem.

ComMan jest bazą dla systemu ERP, ale skrojoną pod małe i średnie przedsiębiorstwa (MŚP). Jest to celowe - rozwiązania dla bardzo dużych firm można znaleźć na rynku i zdecydować się na wdrożenie (co jest często bardzo długim procesem), natomiast mniejsze np. fabryki mają z tym pewien problem. ComMan wypełnia tę lukę i - jak wszystkie nasze przedsięwzięcia - jest tworzony zwinnie, lepiej i szybciej dopasowując się do potrzeb konkretnej organizacji. I to niezależnie od dziedziny - pod tym kątem system nadal pozostaje bardzo uniwersalny.

Menu

Zacznijmy od czegoś tak oczywistego, jak menu. Musi być dostosowane do funkcjonalności aplikacji i zupełnie inaczej wygląda od np. takiego serwisu jak Feedybacky, który jest dosyć kompaktowy i gdzie poszczególne opcje często są osiągalne ze stron danych projektów. W ComManie jest inna sytuacja, gdyż zazwyczaj poszczególnych widoków jest dużo i muszą być szybko osiągalne, aby użytkownik mógł zrealizować to, co chce, ponieważ np. klient czeka. Te widoki można też zgrupować w większe obszary, co prowadzi nas do wniosku, że dla zaoszczędzenia miejsca, a jednocześnie zmieszczenia wszystkiego, menu powinno być dwupoziomowe.

No dobrze, ale czy to naprawdę jest oszczędność miejsca? Przecież drugi poziom oznacza, że potrzebny jest np. kolejny pasek zajmujący przestrzeń. Albo coś rozwijanego, ale to jest ulotne, a np. pracownik chce często przechodzić pomiędzy widokami w obrębie tej samej sekcji. I przecież też dużo opcji oznacza, że napisy mogą się nakładać. A w ogóle co w przypadku, kiedy dana funkcja ma jeszcze podfunkcje (np. tabela jest CRUDem i chcemy mieć przycisk do dodawania obiektu)? I gdzie w ogóle najlepiej umieścić menu - z boku czy na górze? Tyle pytań...

Dodatkowo, użytkownicy systemów wewnętrznych często chcą jednego - jak najwięcej widzieć na jednym ekranie, bez przewijania i bez skakania po widokach w celu skompletowania informacji. Do tego, o ile system powinien być responsywny i wyglądać dobrze na urządzeniach mobilnych (w przypadku niektórych widoków, jak oznaczanie postępu pracy, jest to wręcz obowiązek), to jednak miejmy świadomość, że w większości przypadków będzie odtwarzany na szerszych ekranach, nierzadko panoramicznych monitorach, w godzinach pracy, przez 8 godzin w ciągu dnia. Odpowiednie upakowanie informacji na dostępnej przestrzeni jest tutaj kluczowe, a do tego potrzebna jest nawigacja, która z jednej strony pozwoli między nimi łatwo przechodzić, gdy już to jest konieczne, a po drugie - nie zasłoni zbyt wiele swoją obecnością.

Głowiliśmy się nad tego typu zagadnieniami właśnie w przypadku ComMana z uwagi na to, że pojedyncze instancje wymagały bardzo dużo funkcji, a trzeba pamiętać o tym, aby system był elastyczny z uwagi na przyszłe wymagania klienta (np. wprowadzenie kolejnego modułu czy rozróżnienie ze względu na uprawnienia). Po długich rozmyślaniach oraz konsultacjach z klientami, wypracowano następujące rozwiązanie:

• menu zostało zlokalizowane na górze, a nie z boku, gdzie ucinałoby część szerokości ekranu (a do tego byłoby więcej zamieszania przy responsywności),
• opcje podzielono na sekcje (duże ikony na górze, oznaczone jako "2" na grafice), których kliknięcie uruchamia podsekcje (małe ikonki na górze, oznaczone jako "3"), a aktualnie wybrana sekcja i podsekcja są podświetlane,
• paski muszą być wyłącznie tak wysokie, na ile jest to konieczne (z minimalnym wewnętrznym marginesem dla przyzwoitości) i wyraźnie odróżniać się kolorystycznie,
• zastosowano wyłącznie ikonki z natychmiastowymi tooltipami z podpisem, co pozwoliło uniknąć problemów wynikających z separacji tekstów, ich sztucznego skracania i wygląda ładniej (choć efekt uboczny jest taki, że ikonki bardzo trudno dobrać tak, aby każdy był zadowolony, co generuje dyskusje...),
• jeśli podsekcja posiada swoje sekcje (tzw. trzeci poziom opcji), to wyświetla się on po prawej, za pionową kreską ("4"),
• tytuł strony wyświetla się po prawej stronie menu ("10"), aby uniknąć ewentualnych niejednoznaczności (choć jest też obecny w karcie oraz często na samym widoku),
• lewa strona przeznaczona jest funkcjonalność, a prawa na tzw. rzeczy ogólne (kwestia przyzwyczajeń użytkowników, gdzie m.in. wylogowanie jest na końcu),
• samo menu może być chowane (ikonka kłódki, domyślnie wyłączona).

Tego typu układ był najpierw makietowany, a później zmieniany na kilka różnych sposobów, konsultowany z przyszłymi użytkownikami, co w końcu doprowadziło do hybrydy przedstawionych rozwiązań, która się sprawdza w praktyce. Menu zajmuje stosunkowo mało miejsca i mimo swojej obecności oraz przy dobrym ułożeniu elementów konkretnych widoków (co jest już inną historią) nie powoduje problemów z widocznością. Swoją drogą, w początkowych koncepcjach menu miało się zawsze samodzielnie chować i pokazywać dopiero po skierowaniu kursora na górę ekranu, oczywiście, z myślą o kolejnej oszczędności przestrzeni. Jednak zarówno konsultacje, jak i późniejsze refleksje spowodowały, że jest to bardziej zniuansowane, gdyż:

• niezależnie od tego, jak krótki będzie czas od momentu umieszczenia kursora do reakcji interfejsu, zawsze będzie to za wolne dla użytkownika kierującego się po pewnym czasie pamięcią mięśniową,
• manipulując kursorem na górze widoków, użytkownik może przypadkowo uruchomić menu, co będzie powodowało frustrację (reszta widoku przesunie się w dół),
• niejasne zachowanie systemu przy rozwijaniu podsekcji przy "groźbie", że menu może znowu się schować,
• ciągłe przesunięcia elementów mogą męczyć wzrok (czysto subiektywne odczucie),
• na górze ekranu zwykle znajdują się elementy samej przeglądarki, co powoduje, że trzeba umiejętnie poruszać myszką, a to nie jest coś, czego trzeba wymagać od pracowników mających swoją pracę w systemie do wykonania.

Tym niemniej, oczekiwania były różne - niektórzy użytkownicy chcieli manipulować widocznością menu, podczas gdy inni chcieli je zawsze widzieć na górze. Stąd decyzja o ikonce kłódki, którą można samodzielnie wybrac swój typ ("6").

Jak też widać na zrzucie ekranu, menu obejmuje więcej opcji. O bardzo istotnych skrótach, ulubionych oraz wyszukiwaniu globalnym jeszcze sobie napiszemy. Natomiast ostatnia ikona ("9") to avatar użytkownika, pod którym znajduje się przejście do zmiany swoich danych oraz wylogowania. A z kolei zielona ikona chrząszcza ("5") to nic innego, jak otwarcie znanego wszystkim formularza Feedybacky i zamiennik za standardową ikonkę wysuwaną z prawej strony (i faktycznie czasem zasłaniającą przycisk, co znowu jest obserwacją z pierwszych testów użytkowników). Przyjmijmy, że ten owad oznacza nie tylko bugi, ale też sugestie ;)

Breadcrumby

Teraz z kolei część widoczna na powyższym zrzucie ekranu (pod "11"), która jest oczywista dla wielu, ale początkowo w ComManie miała zostać pominięta. Breadcrumby, czyli "okruszki chleba" (ale będę używał spolszczonej nazwy angielskiej) to ciąg linków (lub innych elementów), które wskazują na proces dojścia do obecnego widoku. Najczęściej kojarzą nam się ze sklepami internetowymi i rozwijaniem kolejnych kategorii produktów, tworząc niejako drzewko, po którym możemy zobaczyć naszą drogę i wycofać się jak po sznurku. Okruszki mają generalnie sens przy serwisach, w których nawigacja jest bardzo głęboka i łatwo zgubić się po kliknięciu na kolejne ekrany.

W przypadku ComMana początkowo zamysł był taki, że duża liczba opcji obejmująca praktycznie wszystkie widoki powoduje, że breadcrumby stają się zbędne - użytkownik i tak ma łatwy dostęp do wszystkich ekranów, a trochę miejsca na ekranie można zagospodarować w inny sposób. Dodatkowo, udostępniona jest opcja ulubionych i skrótów, które pomagają docierać do specjalnie przygotowanych widoków pod potrzeby konkretnej osoby. Przy tym należy zadbać o prawidłowe działanie standardowych przycisków "wstecz" i "dalej" w przeglądarce i gdy to się stanie, to nawigacja będzie prosta bez dodatkowych zabiegów. Jednakże, tutaj wniosek z testów użytkowników był jednoznaczny - potrzebują okruszków. Nie dlatego, że gubią się w systemie, ale dlatego, że mimo dość bogatych w dane ekranów i tak często "żonglują" pomiędzy 2-3 widokami przy pracy nad np. klientem. W związku z tym potrzebują szybkie linki do ostatnio odwiedzonych stron, a do tego właśnie przydają się okruszki.

Dlatego, w przeciwieństwie do wielu systemów, breadcrumby nie są tutaj konstruowane na stałe, tj. tak, że jakąkolwiek drogą użytkownik trafi na widok, to w okruszkach jest to samo - tutaj by się to nie sprawdziło. Zamiast tego są to 3 ostatnio odwiedzone strony + kokpit, przy czym w przypadku ponownego wejścia na jeden z ekranów z listy, jest on przesuwany, aby nie wystąpił dwa razy (w efekcie czego ciągłe przechodzenie A -> B -> C -> D -> C -> D -> C -> D... nie powoduje skrócenia szeregu linków do dwóch). Oczywiście okruszki są klikalnymi linkami i z doświadczeń użytkowników wiemy, że ta forma się sprawdza i jest potrzebna. A jeśli mimo wszystko chcemy sięgnąć głębiej do historii, to pod trzema kropkami jest wcześniejsza historia - nie chcieliśmy bowiem przesadzać z "szerokością" wyświetlanych informacji.

Ulubione

Właśnie tutaj zaczyna się "zabawa" z systemami dostosowanymi do konkretnych firm, choć myślę, że zasada jest uniwersalna dla wielu branż usługowych i produkcyjnych. Wiadomo, że jeśli firma działa na rynku dziesiątki lat, to ma sporą historię zleceń, produktów, procesów, klientów itd., jednak nie zmienia to faktu, że w obrębie 1-2 miesięcy przez 90% czasu zajmuje się tylko kilkoma wybranymi realizacji, między którymi "skacze" i w krótkim czasie ciągle do nich wraca lub chce mieć pewne wzorcowe pakiety informacji zawsze pod ręką. Dodatkowo, gdy mówimy o bardzo złożonych obiektach (np. produkt mający wiele składowych), to najczęściej ich projektowanie lub uzupełnianie informacji wymaga obsługi kilku fragmentów na osobnych widokach. Teraz wyobraźmy sobie, że za każdym razem, chcąc się dostać do obiektu B, musimy albo przejść przez inny obiekt, który jest z nim powiązany (i ma link do niego) lub wejść na listę obiektów, przefiltrować i tam go znaleźć. Od razu na myśl przychodzi funkcja dodania czegoś do ulubionych, prawda? No właśnie.

Ulubione lub też zakładki (jak bywają nazywane w przeglądarkach) to mechanizm, który pozwala na zachowanie dokładnego linku do jakiegoś elementu, co stosuje się w przypadku szczególnie często odwiedzanych widoków lub tych, do których najszybciej chcemy docierać w najbliższym czasie (w menu widoczne pod "1" oraz "8"). Wiadomo, że tego typu "preferencje" z czasem się zmieniają, w związku z czym ulubione widoki będą częściej rotowane (choć menu ułatwia przewijanie długiej listy "serduszek"), a to oznacza, że ten proces powinien być prosty. No i taki jest poprzez odpowiednią ikonkę serca w menu.

Ale ulubione pełnią jeszcze jedną posługę. Wyobraźmy sobie sytuację, w której mamy środek 2026 roku, ale z jakiegoś powodu musimy jeszcze zrobić raport za rok 2025, co wymaga częstszego powrotu do listy, aby odczytywać pewne dane (chwilowo pomińmy, że zapewne istnieje też raport, który potrafi wydobyć takie zestawienie). Możemy ustawić sobie odpowiednie filtry, a ComMan ma nawet funkcję ich automatycznego zapamiętywania, co pomaga przy częstszym wracaniu do danego widoku. Jednak załóżmy, że czasem musimy przejść na listę z realizacjami z 2025 roku, ale równie często musimy zaglądać do najnowszych zamówień, przez co zapamiętywanie filtrów nie będzie tutaj odpowiednie. Jak to najłatwiej obejść? Zapisać stronę do zakładek, czyli widok z już ustawionymi filtrami czy innymi parametrami (zapamiętywany jest cały URL) i który można odłożyć w menu do późniejszego stosowania.

Skróty

Kolejnym mechanizmem ułatwiającym nawigację są skróty (na widoku menu pod "1", lewa ikona). Podczas rozmów o interfejsie systemu, czasem klienci nie poświęcają dużo czasu umiejscowieniu określonych opcji i łatwości dotarcia do nich, twierdząc, że software house to zaproponuje i będzie dobrze (spoiler: software house też potrzebuje poznać przyzwyczajenia użytkowników, sam z siebie nie zawsze "trafi"). Czasem jednak zleceniodawca poświęca całe spotkania na to i dopytuje oraz drąży. Niekiedy dostajemy także pytania "a czy każdy będzie mógł ułożyć swoje własne menu?".

W teorii jest to fantastyczna opcja - nie trzeba analizować oczekiwań każdego użytkownika i brać "średnią" przy pozycjonowaniu menu. Problemy zaczynają się przy realizacji, a dokładniej jej wycenie, która zwykle jest znaczniejsza niż zleceniodawca przewiduje, a nie jest to funkcja dająca taki zysk użytkownikowi, jakiego klienci na początku oczekują - ustawia się zwykle tego typu opcje raz, a poza tym człowiek, wbrew początkowemu oporowi, dość szybko się przyzwyczaja do systemu (oczywiście, o ile nie jest kompletnie źle zaprojektowany). Tym niemniej, czasem pewne roszady są wskazane z uwagi na pojedyncze widoki, umieszczone w kilku sekcjach.

I tutaj na scenę wkraczają rzeczone skróty, które pozwalają "wyciągnąć" daną opcję z głównego menu do swojego własnego, osobistego menu, zawierającego zwykle kilka przycisków. Ale to właśnie one stanowią 90% tego, co użytkownik potrzebuje w swojej normalnej pracy - jest to odpowiednik takiego pulpitu, gdzie umieszcza się ikonki najczęściej uruchamianych aplikacji, aby zawsze były pod ręką.

Wyszukiwanie globalne

Odpowiedzcie sobie na trzy pytania:

1. Czy jeśli chcecie wejść na stronę internetową, której adres znacie, ale nie macie w zakładkach, to zawsze wpisujecie adres URL ręcznie w pasku przeglądarki?
2. Czy jeśli chcecie uruchomić konkretną aplikację na swoim komputerze, to zawsze szukacie jej ikonki na pulpicie lub w menu?
3. Czy jeśli chcecie dotrzeć do konkretnego pliku na swoim dysku (lokalnym lub sieciowym), to zawsze przeglądacie foldery i pliki?

Wiadomo, że wiele osób nadal tak robi, jednak coraz częściej możemy złapać się na tym, że idziemy drogą wytyczoną przez Google'a nawet, gdy formalnie tego nie potrzebujemy - wykorzystujemy wyszukiwarkę nie dlatego, że musimy, tylko dlatego, że tak jest zwyczajnie szybciej. Mniej czasu zajmie nam naciśnięcie jakiejś kombinacji, która uruchomi pole tekstowe, gdzie zaczniemy coś pisać i wyskoczą nam interesujące nas obiekty, nawet jeśli doskonale wiemy, gdzie one się znajdują, ale trzeba by było użyć myszki i ją nakierować, co wymaga precyzji. Tak działa coraz więcej użytkowników i oczywiście, można powiedzieć, że to lenistwo, a Google nas zepsuł, ale oprogramowanie ma uprzyjemniać i przyspieszać pracę ludziom - im szybciej dotrzemy do interesującego nas obiektu, tym szybciej wykonamy naszą robotę i będziemy mniej sfrustrowani pracą oraz systemem.

Dlatego w ComManie podczas konstruowania interfejsu zaproponowano wyszukiwarkę globalną ("7"), która pozwala dotrzeć do obiektów w różnych kategoriach o danym fragmencie nazwy. Ma to szczególne znaczenie w spółkach technologicznych, gdzie czasem produkt, jego proces, dokumenty itd. są osobnymi obiektami, ale mają podobną nazwę, a do tego etykiety różnych realizacji są bardzo podobne do siebie (np. różne wersje danego narzędzia). Wtedy takie wyszukiwanie globalne jest na wagę złota, bo nie tylko pozwala uniknąc przedzierania się przez widoki, ale też podpowiada, czy to, czego potoczną nazwę mniej więcej pamiętamy, jest produktem, instrukcją, zleceniem czy dostawcą.

Natomiast pozostaje tutaj jeden problem techniczny - indeksowanie wszystkich obiektów w systemie (i to nie tylko po nazwie) jest czasochłonne, ale z drugiej strony wyszukiwanie nie może odbywać się na "żywo", gdyż wtedy wyświetlenie wyników nie trwałoby 3 sekundy, tylko 50. Stąd, w celu wykorzystania tej funkcji, ComMan musi użyć mechanizmu kolejek, które w tle dostarczają danych indeksatorowi, a ten stopniowo buduje swój słownik. Wiadomo, że nie jest to machina tak gigantyczna jak Google, ale dzięki temu też nie wymaga takich zasobów i średniozaawansowany serwer spokojnie sobie poradzi z tym zadaniem, co klienci doceniają.

Ponadto, w systemie prawie każda lista ma też filtr wyszukujący po wszystkim w obrębie danej grupy obiektów. To akurat element podpatrzony w starym systemie jednego klienta, gdzie sprawdzał się znakomicie i jego przeniesienie było jednym z warunków wprowadzenia ComMana. My też potwierdzamy, że to funkcjonuje bardzo dobrze i pozwala oszczędzić trochę czasu.

Nawigacja góra-dół

Mówiliśmy już o tym, że fakt obecności menu na górze ma swoje uzasadnienie, ale pozostała jeszcze jedna sprawa: czy w długich (wysokich) widokach można sprawnie operować z płaszczyźnie wertykalnej?

Otóż, można. W ComManie na dole strony jest wielki przycisk ze strzałką w dół, co - nie zgadniecie - przenosi użytkownika na sam dół. Aby dodać więcej magii, gdy chcielibyśmy podjechać do góry, to możemy użyć dużej strzałki w górę, która pojawi się zaraz potem, gdy odjedziemy nieco od góry strony. Już bez żartów, to może bardzo poprawić poruszanie się w momencie, kiedy przeglądąc szczególnie długi opis zlecenia uświadomimy sobie, że musimy zobaczyć produkt, którego dotyczy - zamiast mozolnie kręcić kółkiem myszy w górę, można kliknąć strzałeczkę i tam poszukać linku.

Druga sprawa to formularze i ich długość - ponieważ góra widoków jest często zajęta przez różne tytuły, opisy i indykatory, większość klientów decyduje się na przyciski "Zapisz" czy "Anuluj" na dole. W wielu przypadkach się to sprawdza, natomiast pewne niedogodności pojawiają się w momencie, kiedy formularz jest bardzo długi, my chcemy zmienić tylko jedną z wartości na górze i szybko zapisać (także dlatego, że ComMan ma funkcję wzajemnego blokowania widoków do edycji, lecz to materiał na inną historię). Ale nie można, ponieważ ten przycisk jest na samym dole i trzeba do niego dojechać, a strzałka w tym przypadku jest bezcelowa. Rozwiązanie? Pływający pasek przycisków zatwierdzania, który jest widoczny zawsze na dole i "odkleja" się dopiero po dodarciu na dół. Ale już te "pływaki" można klikać, oszczędzając sobie czas.

Czy to jest elastyczne?

Wyżej przeszliśmy przez różne ogólne elementy nawigacyjne, które może oferować aplikacja i zrobiliśmy to na przykładzie naszej bazy systemu ComMan, aby pokazać, jak różne aspekty wpływają na poszczególne elementy. Wszystko ma swoje uzasadnienie i chociaż pewne decyzje mają podłoże estetyczne lub "klienci tak chcą", to całkiem sporo rzeczy wynika z czysto funkcjonalnego podejścia, które może nie jest efektowne, ale za to szalenie efektywne.

Czy ComMan jest do tego ograniczony? W żadnym razie - nie wszystkie omawiane dzisiaj elementy muszą się znaleźć w takiej formie w każdej instancji, tak samo jak wybór na tym się nie kończy. Wszystko zależy od konkretnego środowiska, przyzwyczajeń użytkowników i np. zakresu sekcji. Można sobie wyobrazić ComMany tak małe, że wystarczy tylko górny pasek, ale także tak ogromne, że bardziej wykorzystywany będzie trzeci lub nawet czwarty poziom menu. Sam dobór funkcji to, rzecz jasna, kwestia konkretnej firmy, ustaleń i tego, co potrzebują. My z kolei zawsze mamy w zanadrzu kilka pomysłów, korzystając z naszego doświadczenia i analizy dobrych oraz złych interfejsów.

Natomiast niezależnie od wyborów możemy powiedzieć jedno - mimo skupienia się na dostarczaniu wartości biznesowej, ComMan nie ogranicza się do zapewnienia środowiska pracy, ale stara się też, aby była ona przyjemna dla użytkownika poprzez oszczędność czasu, który ten musi spędzić w systemie. Oczywiście, nie ogranicza się to tylko do nawigacji, ale też do innych obszarów systemu oraz jego projektowania i realizacji. Dlatego jest to platforma, na której można zbudować swoje zarządzanie przedsiębiorstwem z obszaru MŚP i rozwinąć dokładnie w tę stronę, w którą ta firma potrzebuje.

Pozdrawiam i dziękuję - Jakub Rojek.