Import CSV zaczyna się przed przyciskiem „Importuj”

Dwanaście wierszy w pliku nie musi oznaczać dwunastu nowych produktów. W naszym hipotetycznym imporcie trzy pozycje mają powstać, cztery zostać zaktualizowane, dwie pozostać bez zmian, a trzy wymagają wyjaśnienia. Podpis „Zaimportuj 12 produktów” zaciera wszystkie te różnice, zanim użytkownik podejmie decyzję.

CSV jest formatem przekazania tabeli, a import czynnością zmieniającą dane. Przed zapisem trzeba rozpoznać znaczenie kolumn, tożsamość rekordów i oczekiwany skutek. Sam komunikat „plik poprawny” nie odpowiada na pytanie, czy szerokość zostanie zapisana we właściwej jednostce ani czy pusta komórka skasuje dawny opis.

Przejdziemy przez projekt importu do fikcyjnego katalogu elementów wyposażenia pracowni. Przykładowe liczby i stany służą wyjaśnieniu decyzji; nie są wynikiem wdrożenia ani próby w usługach dostawców. Interesuje nas droga człowieka od otrzymanego arkusza do świadomie przyjętych zmian.

Wybrany plik jest materiałem do rozpoznania

Pierwszy ekran powinien określić cel: do jakiego katalogu lub tabeli trafiają dane i jakie czynności import może wykonać. „Dodaj nowe elementy” ma inny zakres niż „Zaktualizuj istniejące”. Jeżeli produkt dopuszcza oba działania naraz, użytkownik musi móc je rozpoznać przed naciśnięciem przycisku końcowego. To część zadania, nie zaawansowane ustawienie dla administratora.

W pliku od dostawcy mogą znajdować się kolumny „symbol”, „opis”, „szer.” i „stan”. Każda wygląda znajomo, lecz „stan” może opisywać liczbę sztuk albo stan techniczny. Dobra nazwa pola docelowego i próbka wartości pomagają wykryć różnicę. Automatyczne przypisanie na podstawie podobnej etykiety powinno pozostać propozycją do oceny.

Przed mapowaniem pokaż, jak aplikacja rozdzieliła plik. Czy pierwszy wiersz został odczytany jako nagłówek? Czy polskie litery są zachowane, a wartości nie przesunęły się przez separator wewnątrz opisu? Użytkownik powinien rozpoznać te skutki, nawet jeśli nie zna kodowania, czyli sposobu zapisu znaków. Jeżeli cały wiersz trafił do jednej kolumny, nie powinien ręcznie przypisywać jej do przypadkowego pola i przechodzić dalej.

Nagłówek jest wskazówką, nie dowodem poprawności danych. Pierwsza kolumna może być nazwana „ID”, a zawierać kolejne numery wierszy z arkusza. Katalog potrzebuje własnej definicji identyfikatora. W modelu danych produktów określamy te pojęcia wcześniej; importer powinien z nich korzystać, zamiast tworzyć nową definicję przy każdym pliku.

Odbiorca powinien też rozpoznać zakres podglądu. „Przykładowe 5 wierszy” mówi co innego niż „Sprawdzono cały plik”. Jeśli aplikacja pokazuje tylko początek, zaznacz to przy tabeli. Nie wolno nadawać całości zielonego statusu tylko dlatego, że fragment dobrze zmieścił się w oknie. Do pełnego sprawdzenia potrzebny jest mechanizm, który rzeczywiście obejmuje ustalony zakres.

Przy wymianie pliku zachowaj jasną identyfikację nowego materiału oraz unieważnij wyniki poprzedniego sprawdzenia. Wcześniejsze mapowanie może się przydać, ale musi zostać porównane z aktualnymi kolumnami. Osoba nie powinna oglądać podglądu pliku B pod nazwą pliku A ani przyjmować starych wyników kontroli jako nowych. Ten stan warto narysować, zanim połączy się ekrany z przetwarzaniem w tle.

Mapowanie łączy znaczenia, nie tylko nagłówki

Przy każdej kolumnie źródłowej pokaż wybrane pole docelowe, kilka wartości i możliwość świadomego pominięcia. Pole obowiązkowe wymaga wyjaśnienia, czego brakuje. Jeśli użytkownik nie ma odpowiedniej informacji w pliku, właściwym zakończeniem bywa powrót po poprawiony materiał. Nie trzeba zmuszać go do przypisania dowolnej kolumny, żeby formularz stał się kompletny.

Atlassian opisuje automatyczne oraz ręczne mapowanie kolumn w nowym imporcie Jira Cloud. Zaleca kontrolę automatycznych przypisań i wskazuje, że kolumny niemapowane są wykluczane. To konkretny przykład różnicy między obecnością informacji w pliku a jej przyjęciem do systemu.

W naszym katalogu „szer.” ma trafić do szerokości produktu w centymetrach. W dostarczonym pliku wartości zapisano w milimetrach: wejściowe 120 mm powinno odpowiadać 12 cm. Samo wybranie pola nie powinno po cichu uruchamiać domyślnego przeliczenia. Jeżeli import oferuje konwersję, podgląd musi pokazać wartość przed nią i po niej. Jeżeli nie oferuje, wskaż potrzebną poprawkę materiału zamiast udawać zgodność samą nazwą jednostki.

Przy wartościach liczbowych istotne są także przecinek, precyzja i dopuszczalny zakres. Projekt pola liczbowego pomaga rozstrzygnąć interpretację wpisu, lecz import ma zastosować ją do całej kolumny. Przykład „12,5” powinien pozwolić rozpoznać, czy aplikacja otrzymała dwanaście i pół, czy inny zapis. Wyświetlenie właściwego wyniku obok wejścia oszczędza zgadywania.

Wartości słownikowe wymagają własnego przypisania. „Gotowy” w arkuszu może odpowiadać „Do publikacji” w katalogu, ale nie musi oznaczać „Opublikowany”. Pokaż, które wartości zostaną przetłumaczone na istniejący słownik, a które wymagają decyzji. Automatyczne tworzenie nowych opcji również zmienia strukturę pracy zespołu. Nie powinno dziać się wyłącznie dlatego, że łatwiej przyjąć wszystkie słowa.

Oddziel pominięcie kolumny od braku wartości w jej komórce. Przy aktualizacji opisu puste pole może znaczyć „nie mam nowej informacji” albo „wyczyść dotychczasową treść”. Użytkownik ma wybrać regułę zgodną z zadaniem. Jeszcze lepiej, gdy podgląd pokazuje jej skutek na konkretnym rekordzie, którego dawny opis jest niepusty.

Shopify przy nadpisywaniu produktów rozróżnia pustą wartość w nieobowiązkowej kolumnie i pominięcie takiej kolumny. Pierwsza może wyczyścić istniejącą wartość, a druga ją zachować; dokument opisuje również zależności między polami. Własny import musi więc ujawnić regułę, zamiast sugerować, że każda pustka jest obojętna.

Aktualizacja potrzebuje kryterium tożsamości

Dla naszego katalogu produkt o kodzie PR-014 już istnieje. Jeżeli import dotyczy tego samego wariantu, można zaproponować zmianę szerokości. Podobny tytuł nowego produktu nie wystarcza do aktualizacji tego rekordu. Podgląd powinien pokazać podstawę dopasowania i rozpoznawalny obiekt docelowy, żeby osoba mogła potwierdzić, co ma zostać zastąpione.

Airtable w CSV import extension pozwala wybrać pole do łączenia z istniejącymi rekordami. Opisana reguła rozróżnia wielkość liter, a pusty klucz może utworzyć nowy rekord. To zachowanie tego rozszerzenia, którego nie należy przypisywać każdemu importerowi. Pokazuje jednak rzeczywisty skutek wyboru klucza i jego braków.

W interfejsie pokaż osobno nowy rekord, aktualizację i przypadek bez rozstrzygnięcia. „Znaleziono podobny” nie jest jeszcze decyzją „nadpisz”. Przy ocenie łączenia rekordów przez AI ta granica wymaga osobnych dowodów. Tutaj projektujemy moment świadomego przyjęcia konkretnej propozycji, niezależnie od metody, która ją przygotowała.

Dwa wiersze pliku mogą wskazywać ten sam produkt. Użytkownik musi poznać zasadę: odmowa, jedna wspólna zmiana czy inna uzgodniona obsługa. Nie zakładaj, że wygra po prostu ostatni wiersz. Jeśli źródło zawiera sprzeczne wartości, dodatkowa etykieta duplikatu ma prowadzić do decyzji, a nie jedynie ozdabiać podgląd ostrzeżeniem.

Podobnie kilka rekordów docelowych może pasować do jednego wejścia. Nazwa produktu powtarzana w dwóch wariantach to zwykły przypadek, nie egzotyczna awaria. Bez właściwego identyfikatora importer nie powinien wybierać rekordu według wygodnej kolejności. Przed zapisem pokaż niejednoznaczność i zakres, który pozostaje wstrzymany. Człowiek musi rozpoznać, co nadal wymaga wyjaśnienia.

Przy projektowaniu importu w Aeneia Design takie przykłady pomagają połączyć ekran mapowania, podgląd zmiany i raport wyniku. Zamiast zaczynać od pustego szablonu, można przynieść kilka rzeczywistych nazw kolumn oraz umowne wartości pokazujące trudne przypadki. Projekt musi odpowiadać uzgodnionym regułom zapisu danych.

Podgląd próbki nie jest potwierdzeniem całego pliku

Pierwsze wiersze dostawca przygotował starannie. Dopiero pod koniec pojawiają się braki kodu i nierozpoznana jednostka. Jeśli panel pokazuje tylko początek, osoba nie może samodzielnie odgadnąć tych problemów. Status powinien odróżniać podgląd reprezentacji od wyniku pełnej kontroli. Są użyteczne do innych decyzji i mogą powstawać w innym czasie.

Dokumentacja nowego importu Jira Cloud opisuje sprawdzanie pierwszych 30 wierszy podczas mapowania. Ostrzega, że błędy w dalszych wierszach nadal mogą spowodować niepowodzenie lub niepełny import. Ograniczenie próbki nie znika od tego, że ekran pozwala przejść dalej.

W hipotetycznym pliku dwunastu pozycji podsumowanie ma pokazać trzy nowe, cztery aktualizowane, dwie bez zmiany i trzy do wyjaśnienia. Liczby sumują się do dwunastu wierszy wejściowych w tym przykładzie. Nie zakładamy ogólnie, że wiersz zawsze odpowiada jednemu produktowi: plik wariantów albo powiązań może mieć inną strukturę, którą projekt powinien nazwać.

Przed zatwierdzeniem aktualizacji warto umożliwić obejrzenie różnicy wartości. „Zmieniono szerokość” nie pokazuje, czy 120 zastąpiono 12, czy tylko inaczej sformatowano zapis. Własny widok zmian powinien ujawnić obecną i proponowaną wartość wraz z jednostką. Podgląd całego wiersza bez wyróżnienia różnicy przerzuca porównanie na pamięć osoby obsługującej.

Zmiana mapowania wymaga nowego obliczenia skutków. Jeśli „stan” zostaje przypisany do innego pola, stare liczby aktualizacji nie mogą nadal wyglądać jak aktualny wynik. Projekt potrzebuje stanu oczekiwania lub oznaczenia, że wcześniejsze podsumowanie wymaga odświeżenia. W przeciwnym razie użytkownik zatwierdzi zakres pokazany przed swoją ostatnią poprawką.

Zgoda dotyczy wybranej wersji i określonego skutku

Końcowy przycisk powinien nazywać przyjęty zakres. Dla naszego pliku może brzmieć „Dodaj 3 i zaktualizuj 4 pozycje”, jeśli system pozwala przyjąć te siedem, pozostawiając wyjątki poza operacją. Jeżeli jeden błąd zatrzymuje cały plik, potrzebny jest inny model zakończenia. Ekran nie może obiecywać częściowego zapisu, którego aplikacja nie realizuje.

Między podglądem a zapisem ktoś może zmienić istniejący produkt. To wymaga reguły działania uzgodnionej z wykonawcą: ponownego porównania, wstrzymania konfliktu albo innej kontroli wersji. Samo okno potwierdzenia nie zamraża danych. W interfejsie należy pokazać wynik rzeczywistego sprawdzenia i dostępny następny krok, a nie wyłącznie ponowić pytanie o zgodę.

Po rozpoczęciu pokaż stan trwającego zadania i zakres możliwości anulowania. Zamknięcie okna może tylko schować widok, a nie zatrzymać zapis. Jeżeli przycisk „Anuluj” przestaje być dostępny po określonym etapie, trzeba jasno nazwać ten skutek. Nie należy sugerować możliwości cofnięcia wszystkich zmian samą obecnością krzyżyka w rogu panelu.

Szczególnie przy wolniejszej operacji potrzebna jest możliwość odnalezienia wyniku po powrocie. Nazwa pliku, cel importu i identyfikacja zadania pomagają odróżnić dwa podobne przebiegi. Osoba powinna wiedzieć, czy nowe uruchomienie tworzy kolejne zadanie, czy wraca do już przyjętego. Podwójne kliknięcie nie może stać się przypadkową metodą dodania dwóch kopii produktu.

Odbierz wynik, który pozwala naprawić wyjątki

Podsumowanie po wykonaniu pokazuje to, co rzeczywiście zapisano, pozostawiono i odrzucono. Może różnić się od wcześniejszej prognozy, lecz każda istotna różnica wymaga objaśnienia. „Import zakończony” bez liczebności i odniesienia do rekordów nie pozwala ustalić, czy można dalej korzystać z katalogu. Status całości powinien ujawnić również wynik częściowy.

Airtable wyjaśnia też, że nieprzyjęta wartość pola nie musi zatrzymać utworzenia lub aktualizacji rekordu. Opisany importer może pozostawić pustą komórkę, a podsumowanie nie wylicza pominiętych wartości. Sukces rekordu nie jest więc automatycznie potwierdzeniem przyjęcia każdej jego wartości.

W naszym projekcie raport powinien z tego powodu rozdzielać zapisane rekordy oraz pola wymagające poprawy. Przy problemie wskaż źródłowy wiersz, pole i przyczynę możliwą do poprawienia. Numer potrzebuje jasnej definicji, zwłaszcza gdy tekst komórki zawiera nowy wiersz albo plik ma nagłówek. Użytkownik ma trafić do właściwej pozycji, a nie liczyć linie inaczej niż aplikacja. Rozpoznawalny kod produktu pomaga sprawdzić, że poprawia właściwy przypadek.

Plik z wyjątkami może ułatwić dalszą pracę, jeśli zachowuje potrzebne kolumny i powód odrzucenia. Jego postać również wymaga projektu. Eksport danych do innego programu powinien zachować znaczenie wartości, a nie tylko liczbę wierszy. Raport, którego nie da się poprawnie odczytać, tworzy następny problem w tej samej drodze.

Ponowny import poprawionych pozycji nie powinien tworzyć kopii już dodanych produktów tylko dlatego, że użytkownik wysłał cały plik. Zasada rozpoznawania rekordów i sposób wyboru zakresu muszą to rozstrzygnąć. Projekt pokaże, co zostanie ponowione, a co pozostaje przy wcześniejszym wyniku. W przeciwnym razie naprawienie trzech braków może znowu otworzyć pracę nad wszystkimi dwunastoma.

Jeśli materiał przygotowano w arkuszu wykorzystywanym w procesie AI, sprawdź także wartości rzeczywiście zapisane w pliku po edycji. Wyświetlany numer produktu mógł zmienić typ, a kod utracić zero. Kontrola danych wejściowych powinna rozpoznać taką zmianę przed dopasowaniem rekordu. Zaufanie do podglądu arkusza nie zastępuje odczytu przekazanego materiału.

Poprawnie odebrany import pozostawia zrozumiałą decyzję: które kolumny przyjęto, według czego dopasowano produkty i jaki wynik uzyskano dla każdej grupy. Nasze dwanaście wierszy przestaje wtedy udawać dwanaście nowych rzeczy. Użytkownik wie, co wpłynęło na katalog i co ma jeszcze wyjaśnić, zanim dostawca prześle następny, wyjątkowo ostateczny arkusz.