Responsywny design nie tylko rzuca wyzwanie naszym narzędziom i podejściom do projektowania i tworzenia stron internetowych, ale także zmusza nas do przeglądu naszych sposobów planowania i zarządzania treściami. Nowe przepływy pracy wymagają odpowiednich narzędzi. Po pierwsze, otwiera to szansę na zupełnie nowe systemy zarządzania treścią (CMS) i platformy do publikowania (prawdopodobnie prawdopodobnie zobaczymy ich wiele w najbliższej przyszłości). Ale każdy, kto kiedykolwiek przeprowadził migrację z jednego CMS do drugiego, doskonale wie, że proces ten nie jest bezbolesny. Czy możemy więc dostosować znane i popularne CMS, takie jak WordPress, aby pomóc nam tworzyć i zarządzać treściami adaptacyjnymi?

Po pierwsze, musimy wszystko wyprostować. Co oznacza treść adaptacyjna i dlaczego potrzebujemy jej w czasach elastycznego projektowania? Omówimy także funkcje i narzędzia WordPress, które pomogą nam stworzyć przyjazną platformę do publikacji. Dążymy do osiągnięcia wysokiego celu: posiadania treści, które po utworzeniu mogą być prezentowane elastycznie na różnych urządzeniach iw różnych warunkach oglądania. Zobaczmy, jak blisko możemy się do tego dostać.

Adaptacyjne treści i dlaczego ich potrzebujemy

W jej ostatniej książce Strategia treści dla komórek , UX i specjalista ds. Strategii treści Karen MacGrane daje szczegółowe i uzasadnione wyjaśnienie, dlaczego potrzebujemy nowego podejścia do zarządzania treścią. Idziemy dalej niż budujemy responsywne strony - tworzymy treści, które mogą być publikowane na różnych platformach i dostępne na różnych urządzeniach. Co, jeśli jutro lodówka stanie się czyimś podstawowym narzędziem do konsumowania informacji? Czy Twoja witryna jest gotowa na taki przypadek?

Responsywny projekt powstał głównie z potrzeby zapewnienia mobilnym użytkownikom odpowiedniego doświadczenia. Szczerze mówiąc, "ruchomy" to tylko część obrazu. Jeśli pomyślimy o przyszłości, możemy łatwo oczekiwać innych nowych platform i urządzeń, na których pojawią się nasze treści: zegarki, lodówki, okulary, roboty do rozmów - wszystko, co można sobie wyobrazić. Czy to oznacza, że ​​musimy stworzyć wersję "mówiącego robota" na naszej stronie? To byłoby szaleństwo. Jakie jest rozwiązanie? Rozwiązaniem są treści adaptacyjne - treści, które po utworzeniu można ponownie wykorzystać w różnych sytuacjach i scenariuszach. Brzmi świetnie, prawda? Jak to osiągnąć?

1. Strukturalne treści

Nasza zawartość nie składa się już z "stron". Składa się z obiektów, z których każdy należy uznać za pakiet wstępnie zdefiniowanych elementów. Dla każdego elementu konstrukcyjnego - kawałka - system projektowania uwzględniałby sposób jego wyświetlania we wszystkich scenariuszach. Kawałki mogą być prezentowane w alternatywnych mediach lub formatach dla różnych przypadków użycia. Na przykład, jeśli mamy wideo w naszym obiekcie treści, możemy mieć tekst opisowy lub transkrypcję dla scenariuszy, w których wideo nie może być oglądane. Adnotacje dotyczące obiektu mogą się różnić w zależności od scenariusza - na przykład w przypadku udostępniania w mediach społecznościowych lub uwzględnione w wynikach wyszukiwania lub w witrynie.

2. Treści niezależne od prezentacji

Musimy zrobić kolejny krok w kierunku oddzielenia treści od prezentacji. W rzeczywistości jest to ważna zasada przeprojektowania i kamień węgielny standardów internetowych. Ale musimy pójść dalej i uwolnić się od mentalności WYSIWYG. "To, co widzisz" nie jest już "tym, co widzą Twoi użytkownicy". To jest niebezpieczna iluzja. Nie powinniśmy zaznaczać naszego tekstu kursywą ani wstawiać obrazów jako HTML w polu "treści" na "stronie". Powinniśmy po prostu dołączyć odwołanie do obiektu treści i pozwolić naszemu systemowi projektowemu zdecydować, jak zaprezentować obiekt.

3. Dane meta

Im więcej pracy poświęcamy narzędziom programistycznym (w końcu chcemy, aby nasze treści były prezentowane na różnych platformach automatycznie w oparciu o predefiniowane scenariusze, prawda?), Tym więcej informacji powinniśmy przekazać tym systemom na temat treści. Na przykład w przeszłości mogliśmy napisać po prostu po angielsku, że autorem tekstu był John Doe, a jego imię pogrubione - teraz nie możemy. Potrzebujemy osobnego pola w naszym CMS, aby wprowadzić nazwę i zestaw reguł, jak przedstawić ją w różnych scenariuszach.

4. Zawartość wielokrotnego użytku

Potrzebujemy jednego źródła treści i opartego na scenariuszu systemu publikowania, który może zdecydować, w jaki sposób zaprezentować żądaną treść użytkownikowi zgodnie z jego otoczeniem (urządzenie, rozdzielczość ekranu, szybkość połączenia itp.).

Czy wszystkie te aspekty można osiągnąć za pomocą WordPress? MacGrane obwinia WordPressa i inne oprogramowanie do blogowania za brak obsługi wydawców jako narzędzia do adaptacyjnych treści. W szczególności, wciąż mamy edytor WYSIWYG w WordPress, z pojedynczym obszarem tekstowym, aby wprowadzić nasz "post". Niestety, jest to sytuacja, w której projektant stosuje prostą, gotową do użycia wersję WordPressa. Na szczęście WordPress to coś więcej niż tylko "oprogramowanie do blogowania". Stało się to platformą programistyczną, platformą, dzięki której programista może zapewnić klientom prawdziwie nowoczesne i przyszłościowe doświadczenie.

Przekształcenie WordPressa w adaptacyjną platformę wydawniczą

Zobaczmy, jakie narzędzia mamy jako programiści i jak je wdrożyć, aby przekształcić WordPress w platformę do publikowania adaptacyjnego dla naszych klientów.

WordPress rozpoczął swój ruch w kierunku pełnoprawnego systemu CMS, wprowadzając niestandardowe typy postów i niestandardowe taksonomie. Inną potężną funkcją, która może być używana w połączeniu z tymi są tak zwane pola niestandardowe. Ta prosta nazwa odnosi się do GUI; w rzeczywistości te niestandardowe pola reprezentują zbiór metadanych, które można powiązać z dowolnym obiektem w WordPress. WordPress daje nam możliwość tworzenia wysoce konfigurowalnego interfejsu użytkownika dla danych meta i elastycznego interfejsu API do przechowywania i uzyskiwania do niego dostępu.

Dlaczego jest to pomocne? Dzięki niestandardowym typom postów nie jesteśmy już zamknięci w koncepcji "strony". Możemy utworzyć typ postu dla dowolnego potrzebnego obiektu (np. Wiadomości, wydarzenia, partnerzy - cokolwiek lubimy) i możemy zdefiniować strukturę obiektu za pomocą tego zestawu metadanych. Możemy również utworzyć oddzielny interfejs do zarządzania danymi meta. Wszystko to nadaje naszej treści więcej struktury. Gdy tylko WordPress pozwolił nam tworzyć metadane dowolnego typu, możemy użyć go do przechowywania alternatyw dla wbudowanych bloków treści, takich jak tytuły i opisy. (Na przykład możemy zobaczyć wtyczki SEO, które pozwalają na unikalny tytuł i opis kierowany SEO dla każdego obiektu treści.)

Jakie są jego ograniczenia? WordPress jest krytykowany za to, że nie zawsze zapewnia API do przechowywania metadanych. W szczególności możemy mieć metadane dla postów (i typów wpisów niestandardowych) i użytkowników, ale nie dla taksonomii (a wtyczka jest potrzebna za to). Utworzenie niestandardowego interfejsu użytkownika na ekranie edycji postu nie jest tak proste, jak mogłoby być. Brak predefiniowanych funkcji i standardów (dlatego różne wtyczki robią to inaczej, pozostawiając nam bałagan, a nie system). Jednak ostatnie zmiany, które pomagają ujednolicić i zoptymalizować pulpit WordPress, dają nam nadzieję.

Inną wspaniałą cechą WordPressa jest to, że umożliwia kilka wystąpień edytora tekstu sformatowanego na jednej stronie. Można to zrealizować za pomocą wp_editor funkcja, która nie tylko tworzy odpowiedni znacznik tekstowy, ale także przypisuje do niego funkcję edycji bogatej i przyciski wyboru mediów.

Dlaczego jest to pomocne? Dzięki tej funkcji możemy rozbić pojedyncze pole treści na kilka zgodnie ze strukturą obiektu. W ten sposób dodajemy element strukturalny do naszych obiektów. Ponadto każdy obszar edytowalny będzie miał ujednolicony i znajomy interfejs graficzny, który pomoże redaktorom łatwo wstawić niezbędny znacznik do odpowiednich pól, w tym krótkich kodów.

Jakie są jego ograniczenia? Powinniśmy przechowywać dane wprowadzone w tak bogatych obszarach edycyjnych, jak metadane, a to oznacza więcej wywołań baz danych itp. Tak więc takie podejście będzie wymagać dalszej uwagi w celu optymalizacji strony, takiej jak buforowanie. Nie ma wbudowanej funkcji do reprezentowania tych danych w szablonach, więc będziemy musieli go utworzyć.

Dzięki takiemu podejściu znajomy ekran edycji będzie całkowicie zmieniony:

Omówione powyżej narzędzia WordPress pozwalają nam lepiej ustrukturyzować nasze treści, definiując obiekty i zastępując jeden obszar blobu zbiorem pól przechowujących różne części i metadane treści.

Teraz zobaczmy, jakie narzędzia mamy do oddzielenia znaczenia i prezentacji. W rzeczywistości istnieją tylko dwie podstawowe zasady:

  1. Pozbądź się edytora wizualnego.
  2. Unikaj używania zwykłego kodu HTML w polach treści w jak największym stopniu.

Pierwsza zasada jest łatwa do naśladowania. Za pomocą prostego filtru możemy usunąć edytor wizualny dla wszystkich użytkowników.

add_filter('user_can_richedit', '__return_false');

Druga zasada jest o wiele trudniejsza do naśladowania. Na pewno nie będziemy polować na każdy tag HTML w naszym tekście - te, które reprezentują prawdziwie semantyczne elementy są absolutnie OK. Ale kiedy zaczynamy wstawiać

do obiektu treści, wpadamy w kłopoty. Jak wiemy, kolumna w jednym scenariuszu może być czymś zupełnie innym w innym.

Kolejny ogromny problem wynika ze sposobu, w jaki WordPress umieszcza bogate multimedia - w szczególności obrazy - w polach treści. Obecnie drukuje zwykły HTML, który koduje link do obrazu, jego rozmiar i znaczniki owijania. To najgorszy możliwy scenariusz dla podejścia adaptacyjnego. Co by było, gdybyśmy potrzebowali innej odmiany obrazu dla konkretnego przypadku użycia? Co się stanie, jeśli przeniesiemy naszą bibliotekę multimediów do innej domeny? Co się stanie, jeśli zmienimy projekt obiektu, a zatem potrzebujemy obrazu w innym rozmiarze? Co się stanie, jeśli zastosujemy technikę elastyczną, która wymaga od nas określenia kilku źródeł dla jednego obrazu? Wszystkie te przypadki użycia są absolutnie niemożliwe, jeśli nie zmienimy domyślnego zachowania WordPress.

A jednak WordPress ma prawie wszystko, aby dokonać przejścia do możliwego podejścia adaptacyjnego:

  • Każdy element multimedialny w bibliotece multimediów ma swój własny wpis w bazie danych, który przechowuje wszystkie istotne informacje, w tym dane dotyczące pliku źródłowego. Ale WordPress nie przechowuje bezwzględnego łącza do pliku; raczej przechowuje nazwę pliku i ścieżkę do pliku uploads folder osobno, aby pełna ścieżka mogła być budowana dynamicznie.
  • WordPress ma funkcjonalność shortcode, która pozwala ci odwoływać się do wszelkich znaczników w polach treści i dynamicznie tworzyć rzeczywisty znacznik, gdy treść jest drukowana z przodu.

Łącząc to wszystko, możemy reprezentować znaczniki dla mediów za pomocą krótkiego kodu zawierającego identyfikator elementu w bibliotece multimediów. Bardzo prosty przykład wygląda następująco:

add_shortcode('frl_image', 'frl_image_screen');function frl_image_screen($atts, $content = ''){extract(shortcode_atts(array('id' => 0, 'link' => 'file', 'size' => 'medium'), $atts ));$out = '';$id = intval($id);if($id == 0)return ''; // no attachment$out = "