InDesign i document engineering
Dla wydawnictw, agencji, działów dokumentacji, operatorów DTP i firm tworzących powtarzalne publikacje projektuję rozwiązanie adekwatne do procesu: skrypt na zamówienie albo automatyzację realizowaną w ramach konkretnego projektu DTP.
Dwa modele pracy
Zakres może wykorzystywać ExtendScript i JavaScript, a gdy wymaga tego uzgodniony workflow - ScriptUI oraz panel Scripts. Rozwiązanie nie jest projektowane w oderwaniu od wersji InDesigna, systemu operacyjnego, dokumentów, fontów i linków, z którymi ma pracować.
Nie deklaruję zgodności z nieznanymi przyszłymi wersjami aplikacji. Przed wdrożeniem potrzebne są reprezentatywne kopie plików, ponieważ różnice między dokumentami i środowiskami mogą zmienić zachowanie skryptu.
Proces projektu skryptowego
01
02
03
04
05
06
07
08
09
10
Kompatybilność i testy
Kod, prawa i bezpieczeństwo
Przekazanie kodu i źródeł ustalam indywidualnie wraz z zakresem dokumentacji.
Prawa do modyfikacji, zakres wsparcia i sposób zgłaszania poprawek wymagają osobnego ustalenia.
Nie stosuję jednego domyślnego modelu. Licencja i ewentualna wyłączność są częścią uzgodnienia projektu.
Przed wdrożeniem zalecane jest testowanie na kopiach dokumentów. Nie obiecuję pracy bez kopii zapasowej ani zmian na jedynych źródłach produkcyjnych.
Powiązane usługi
Odpowiedzi porządkują zakres skryptów, testowania, praw do kodu i utrzymania.
Najlepszym kandydatem są powtarzalne czynności wykonywane na wielu dokumentach, folderach, stylach, linkach, danych lub eksportach. Skrypt ma sens, gdy reguły są względnie stabilne, a ręczna praca generuje ryzyko błędu albo zajmuje zbyt dużo czasu. Przy jednorazowym problemie lepsza może być procedura, checklista albo automatyzacja wykonana tylko w ramach konkretnego projektu.
Potrzebny jest opis procesu, reprezentatywne kopie plików, przykłady wyjątków, wersja InDesigna, system operacyjny oraz oczekiwany rezultat. Jeżeli skrypt ma pracować z danymi, przydają się próbki CSV, XML, JSON lub IDML. Bez realnych próbek łatwo zaprojektować rozwiązanie, które działa tylko na idealnym przypadku.
Tak. Pilotaż na kopiach dokumentów pozwala sprawdzić reguły, wyjątki i opłacalność automatyzacji przed pełnym wdrożeniem. Po pilotażu można zdecydować, czy potrzebny jest skrypt, interfejs ScriptUI, raport QA, procedura wsadowa albo tylko jednorazowe przetworzenie plików.
Od wersji InDesigna, systemu operacyjnego, struktury dokumentów, fontów, linków, stylów i użytych funkcji. Nie deklaruję zgodności z każdą przyszłą wersją programu ani z dokumentami, których nie dało się przetestować. Zakres kompatybilności powinien być opisany w dokumentacji rozwiązania.
Nie. Skrypt może wykrywać wzorce, braki, niespójne nazwy, błędne linki, różnice danych albo przygotować raport. Nie rozstrzyga decyzji redakcyjnych, merytorycznych i wizualnych, które wymagają oceny osoby odpowiedzialnej za publikację.
Przekazanie kodu, dokumentacji, praw do modyfikacji, licencji i ewentualnej wyłączności ustala się indywidualnie. Inaczej wygląda skrypt tworzony na zamówienie, a inaczej automatyzacja wykonana jako część zlecenia DTP. Te zasady powinny być jasne przed rozpoczęciem pracy.
Zmiana szablonu, nazw stylów, struktury danych, folderów lub wersji aplikacji może wymagać aktualizacji i ponownych testów skryptu. Nie zakładam bezterminowego utrzymania ani zgodności z nieznanymi zmianami środowiska. Zakres wsparcia i poprawek trzeba ustalić osobno.
Testy powinny odbywać się na kopiach dokumentów i reprezentatywnych paczkach, nigdy jako pierwsza próba na jedynym produkcyjnym źródle. Warto mieć przykłady poprawnych i problematycznych plików, żeby sprawdzić wyjątki. Wynik pilotażu powinien pokazać, co skrypt robi automatycznie, a co wymaga decyzji człowieka.
Podaj cel, używane pliki, liczbę wariantów, wyjątki, wersję InDesigna i oczekiwany rezultat. Testy wykonuj na kopiach dokumentów.