Typy dokumentacji
Poniżej znajduje się krótki opis typów dokumentacji akceptowanych na amp.dev:
- Samouczek wprowadzający
- Samouczek zaawansowany
- Przewodnik wprowadzający
- Przewodnik po koncepcji
- Dokumentacja referencyjna
Samouczek wprowadzający
Samouczki wprowadzające pomagają programiście zrozumieć ogólną koncepcję tej technologii. Zaczynają się od kodowania, a kończą kompletnym podstawowym projektem „Witaj świecie”. Samouczki wprowadzające pokazują, jak krok po kroku zbudować kluczową funkcję AMP. W samouczkach można stosować próbki kodu inline i/lub pobierane próbki, wymagające od programisty minimalnych poprawek w celu wykonania.
Przykłady amp.dev:
- Utwórz swoją pierwszą stronę AMP
- Utwórz swoją pierwszą relację AMP
- Utwórz swoją pierwszą reklamę AMP
Dobrze | Źle |
Podaj wskazówki z krótkimi wyjaśnieniami i jak najkrótszą procedurą. | Nie zagłębiaj się w niuanse projektu. Być może cel samouczka można osiągnąć na wiele sposobów, ale nie chodzi o to, aby przedstawić każdy z nich, tylko jeden, a dobry. |
Zapewnij uproszczone środowisko i narzędzia do konfiguracji. | Nie zakładaj, że programista zna produkt i ma umiejętność kodowania na poziomie eksperckim. |
Staraj się, by próbka była wizualnie uproszczona. | Nie komplikuj spraw ze względu na styl, chyba że samouczek dotyczy stylów. |
Przedstaw zrzut ekranu z każdego kroku i gotowe demo. | Nie zapewniaj jedynie próbek kodu. |
Utwórz wezwanie do działania. Wskaż programiście, na co ma zwracać uwagę. | Nie łącz przykładu z dalszym wyjaśnieniem. Jeśli uważasz, że nie ma wystarczających wskazówek dalszego postępowania, zastanów się nad złożeniem wniosku o opracowanie poradnika lub samouczka. |
Samouczek zaawansowany
Samouczki zaawansowane pomagają programistom w wykonaniu określonego zadania. Zakłada się w nich, że programista ma pewną znajomość AMP. Samouczek powinien zademonstrować jak zbudować wrażenie, zintegrować funkcję lub opracować zadania wdrożeniowe.
Przykłady amp.dev:
- Jak skonfigurować podstawową analitykę dla stron AMP
- Dodawanie własnego kodu JavaScript do stron AMP za pomocą składnika amp-script
- Zmień swoją witrynę AMP w PWA
Dobrze | Źle |
Zapewnij instrukcje krok po kroku i zrozumiały projekt końcowy. | Nie przedstawiaj wyczerpujących szczegółów ani nadmiernie rozbudowanych koncepcji. |
Zapewnij próbki kodu lub kod początkowy do pobrania. Dodatkowo udostępnij do pobrania ostateczny gotowy projekt. | Nie podawaj alternatywnych przykładów ani procesu do osiągnięcia wyniku końcowego. |
Stwórz środowisko plug and play. | Nie podłączaj samouczka konfiguracji. Samouczki powinny być samodzielne. |
Przewodnik wprowadzający
Przewodnik wprowadzający zawiera przegląd istotnych informacji, umożliwiających rozpoczęcie użytkowania technologii AMP. Powinien identyfikować funkcję, opisywać czym jest, a kończyć na tym, do czego służy. Przewodniki wprowadzające zapoznają programistę z podstawowymi wymaganiami dotyczącymi danej funkcji, nie kierując go do jej wdrożenia. Jeśli przechodzisz przez proces krok po kroku z próbkami kodu, prawdopodobnie piszesz samouczek. Jeśli opisujesz wszystkie elementy programistyczne składnika AMP, prawdopodobnie piszesz dokument referencyjny.
Przykłady amp.dev:
Dobrze | Źle |
Zidentyfikuj treść dokumentu. | Nie rozkładaj go na poszczególne kroki procesu. |
Przedstaw cechy i koncepcje. Zamieść link do dokumentów referencyjnych zawierających szczegółowe informacje na temat zaawansowanego użytkowania. | Nie opisuj wyczerpująco. w szczegółach |
Zapewnij próbki kodu i rzeczywiste przykłady. | Nie twórz całej aplikacji. Zamiast tego podaj link do przykładów lub różnych wersji demo do dalszej analizy. |
Podaj listę zastosowań technicznych i ograniczeń. | Nie wymieniaj wszystkich możliwych zastosowań technicznych i sposobów ich wykonania. |
Przewodnik po koncepcji
Przewodniki po koncepcji pomagają programistom pogłębić wiedzę na temat AMP. Przewodnik po koncepcji jest jak mapa topograficzna — przedstawia różne szlaki w okolicy z takimi szczegółami jak zmiany wysokości terenu, ale nie wyznacza konkretnej trasy. Wyjaśniaj, czym jest funkcja i jak działa, a nie jak ją skonstruować.
Przykłady amp.dev:
Dobrze | Źle |
Zapewnij programiście wszystkie elementy potrzebne do skonstruowania rozwiązania. | Nie prowadź aktywnie programisty do określonego stanu końcowego. |
Omów wszystkie zagadnienia z zakresu tematycznego. | Nie skupiaj się na konkretnym zadaniu. |
Dodaj pomoce wizualne, takie jak schematy lub zrzuty ekranu. | Nie myśl za dużo, możesz poprosić o pomoc w zapewnieniu materiałów wizualnych w grupie roboczej ds. kontaktów zewnętrznych [outreach working group](https://github.com/ampproject/wg-outreach). |
Zapewnij próbki kodu i linki do innych przewodników. | Nie udostępniaj gotowego projektu do pobrania ani nie zbaczaj z tematu. |
Dokumentacja referencyjna
Dokumentacja referencyjna zawiera listę wszystkich elementów programistycznych składnika AMP. Dostarcza szczegółowych informacji o sposobie działania i jest przeznaczona do przeszukiwania. Dokumentacja referencyjna powinna zawierać próbki przykładowego kodu oraz przykłady użycia.
Dokumenty referencyjne amp.dev znajdują się w katalogu składników AMP.
Dobrze | Źle |
Używaj zrozumiałego i zwięzłego języka, aby wyjaśnić jak działa dany składnik. | Nie wyjaśniaj procesu ani nie twórz projektu. |
Porządkuj dokument za pomocą łatwych do wyszukania tytułów, nagłówków i śródtytułów. | Nie grupuj treści pod abstrakcyjnymi nazwami. |
Przedstaw fragmenty kodu, demonstrujące użycie składników. | Nie twórz pełnych aplikacji demonstracyjnych. |
-
Written by @CrystalOnScript