Jak aplikacja webowa pomaga geologom szybciej analizować dane offshore

Przegląd projektu

Kadme jest jednym z czołowych dostawców oprogramowania dla branży węglowodorowej. Ich narzędzia wspierają wiele dużych firm w zarządzaniu danymi. Kadme korzysta z najnowocześniejszych technologii, takich jak uczenie maszynowe, przetwarzanie w chmurze i sztuczna inteligencja. W ich portfolio znajdują się aplikacje przeznaczone głównie dla specjalistów ds. danych i analityków.

Ale co ze specjalistami terenowymi i geologami, którzy mają dość błądzenia w labiryncie liczb, tabel i wąskospecjalistycznych interfejsów? Kadme potrzebowało zupełnie nowej aplikacji dedykowanej tej dotąd niezaadresowanej grupie.

Wyzwanie

Potencjał geologów jest ograniczany przez dostępność menedżerów danych i złożoność istniejącego oprogramowania. To wąskie gardło wpływa zarówno na szybkość, jak i zakres analizy danych. Naszym celem było stworzenie aplikacji, która otwiera nowe możliwości dla branży E&P, wyzwalając kreatywność geologów.

Nasza praca

Aby osiągnąć namacalne rezultaty w wyznaczonym czasie, musieliśmy zarządzać zwinnym podejściem i skupić się na szybkich, przyrostowych dostawach.

Wspólnie z klientem zbudowaliśmy zespół projektowy odpowiedzialny za pierwszy etap tego projektu. Dzięki wsparciu deweloperów mogliśmy szybko weryfikować nasze pomysły i projekty. Jednak żaden projekt nie może się rozpocząć bez:

Najpierw faza odkrywania

Podczas intensywnej fazy odkrywania musieliśmy zrozumieć nie tylko perspektywy i potrzeby użytkowników i biznesu – odbyliśmy też intensywny kurs domenowy. Ważne jest pełne zrozumienie specyficznego języka, koncepcji, definicji i specjalistycznej wiedzy o branży.

Dzięki bardzo zaangażowanym przedstawicielom klienta mogliśmy łatwo dotrzeć do użytkowników, jednak samo badanie ich było trudnym zadaniem. Byli poza naszym zasięgiem i musieliśmy wykazać się kreatywnością, czerpiąc z wiedzy klienta na ich temat. W tamtym czasie jedyną akceptowalną metodą były badania ankietowe.

Projektowanie w niezliczonych iteracjach

Biorąc pod uwagę, że wkraczaliśmy na nieznane terytorium, a ani my, ani klient nie mieliśmy jasnego pomysłu na ogólny układ aplikacji, zdecydowaliśmy się eksplorować możliwości, a decyzję odłożyć na później. Doprowadziło nas to do koncepcji "maplikacji" – aplikacji, w której moduł mapy odgrywa kluczową rolę.

Spośród trzech zdefiniowanych podejść wybraliśmy koncepcję częściowej mapy. Założyliśmy też, że ostateczna decyzja może zostać podjęta dopiero po zaprojektowaniu głównych komponentów GUI.

Przeszliśmy więc do głębszego zgłębiania procesów i sposobów ich realizacji. Nasze początkowe prace nad interfejsem przypominały bardziej tworzenie cegiełek niż kompletnego projektu. Te izolowane elementy były intensywnie testowane i walidowane wewnętrznie z przedstawicielami klienta, zanim złożono je w pełnoekranowy makiet.

Wszystkie komponenty UI zostały "przetłumaczone" na bibliotekę React.js w Storybook.

Iteracja po iteracji dbaliśmy o wysoką użyteczność zarówno poszczególnych elementów, jak i całego interfejsu systemu, gdy zaczął on powstawać jako całość. Musieliśmy mieć pewność, że nasz projekt jest intuicyjny i łatwy w obsłudze w wielu różnych scenariuszach użycia. Nasze narzędzie mogło być używane nie tylko na nowoczesnym komputerze stacjonarnym w spokojnym, przytulnym biurze, ale też na wytrzymałym tablecie podczas złej pogody na platformie wiertniczej.

Praca z danymi

Naszym celem było zaprojektowanie systemu, który pomaga użytkownikom przeszukiwać ogromne ilości nieustrukturyzowanych danych, plików i encji agregowanych z wielu źródeł. Każdy element mógł zawierać różne informacje, dlatego zdefiniowaliśmy hierarchię i logikę wyświetlania, nie przeciążając interfejsu. To nie mógł być lepszy edytor arkuszy kalkulacyjnych!

Naszym głównym punktem skupienia było zapewnienie wizualnych wskazówek ułatwiających szybką orientację (np. hierarchii dla najważniejszych elementów, gdzie "źródła danych" lub "rozszerzenia" wyróżniają się na tle reszty) oraz ułatwienie podejmowania decyzji na pierwszy rzut oka. Wiedzieliśmy, że bez dobrej logiki wyszukiwania nie będziemy w stanie pomóc użytkownikom przebić się przez miliony wyników.

Postawiliśmy na projekt skoncentrowany na wyszukiwaniu – z potężną wyszukiwarką umożliwiającą budowanie złożonych zapytań (z użyciem technik boolowskich i quasi-regex), wzbogaconą o szeroki wachlarz filtrów do zawężania wyników.

Doświadczenie mapowe

Kontekst przestrzenny ma ogromne znaczenie dla procesu eksploracji geologów. Naszą pierwszą zasadą przy projektowaniu mapy było traktowanie tego modułu jako uzupełnienia reszty interfejsu, a nie głównego obszaru interakcji. Koncentrując się wyłącznie na najważniejszych elementach, nie przeciążyliśmy mapy wszelkimi możliwymi danymi (choć była to kusząca opcja:).

Dopasowywaliśmy się do głównych przypadków użycia i wyświetlaliśmy minimalną ilość informacji potrzebnych w kontekście wyszukiwań użytkownika. Taka responsywność pozwoliła nam uniknąć potencjalnych problemów z trudno czytelnymi mapami i ogromną różnorodnością kolorów i elementów – o czym warto wspomnieć: musieliśmy być ostrożni przy doborze kształtów, linii i ograniczonej palety kolorów. Znalezienie użytecznych i estetycznych kolorów nie było łatwe, bo projektowany przez nas system miał być renderowany w jednym z trzech motywów kolorystycznych.

Z całą pewnością nie będzie przesadą stwierdzenie, że zdobyliśmy nowe kompetencje w dziedzinie projektowania GIS i wizualizacji danych!

Praca z motywami kolorystycznymi

Samo przemalowanie systemu na inną paletę jest stosunkowo proste. Wyzwanie pojawia się wtedy, gdy paleta ma swój cel i specyficzny kontekst użycia – dokładnie tak było w naszym projekcie.

Celem było udostępnienie ciemnego motywu jako opcji do naszego oryginalnego projektu. Niektórzy specjaliści pracują w dość ciemnym otoczeniu, a jasny, dość biały interfejs szybko by zmęczył oczy. Ciemny motyw z łatwością rozwiązuje ten problem.

Ponieważ od samego początku myśleliśmy o różnych sposobach użycia kolorów i motywach (co zaowocowało stworzeniem quasi-wytycznych i reguł), opracowanie nowej palety kolorów dla danych przestrzennych na mapie było jeszcze łatwiejsze.

Wyzwanie dostępności dla osób z zaburzeniami widzenia barw

Jednym z największych wyzwań było przygotowanie unikalnego motywu dla użytkowników z zaburzeniami postrzegania barw (deuteranopia i protanopia).

Na początku przeprowadziliśmy gruntowne badania. Nie było oczywiste, jak w takich przypadkach prezentować pewne informacje na mapie. Skończyliśmy na niezliczonych iteracjach – szukaliśmy jednej, sprawdzonej odpowiedzi w internecie i zasobach różnych organizacji zajmujących się dostępnością, sprawdzaliśmy każdy możliwy scenariusz mapowy i rozwiązania konkurencji w tym zakresie. Z pomocą narzędzi symulujących zaburzenia widzenia zmienialiśmy kolory jeden po jednym.

Ostatecznie zastosowaliśmy ciemny motyw dla warstwy mapy bazowej i jasny motyw dla reszty interfejsu, ponieważ tam uzyskaliśmy lepszy kontrast.

Wiedzieliśmy, że mieszanie jasnego i ciemnego motywu w jednej wersji byłoby sprzeczne z ideą motywów dostosowanych do różnego natężenia światła w otoczeniu – jak wspomniano wcześniej – ale w naszym MVP nie mogliśmy zadowolić wszystkich. W pierwszej kolejności chcieliśmy osiągnąć nienaganną czytelność interfejsu.