SUPLA - pomysł na instrukcje do modułów

Masz pomysł na funkcjonalność lub koncepcję na rozwój projektu. Opisz wszystko tutaj.
QBA-dev
Posts: 48
Joined: Sat Mar 03, 2018 5:48 pm
Has thanked: 2 times
Been thanked: 3 times

Post

Witajcie Panie i Panowie

Przybywam tu z elitarnego portalu wypok. Miałem ostatnio w pracy zadanie rozpoznania tematu formatu .adoc w pisaniu dokumentacji, i pomyślałem, że nada się też do SUPLI. Aby nie przedłużać...

Zauważyłem, że o ile instrukcje do modułów sprzedawanych przez firmę ZAMEL są bardzo dobrze zrobione, to te do gniazdka WiFi, modułu bramowego itd. krótko mówiąc... odstają poziomem. I tu mógłbym pomóc nieco w rozwoju dokumentacji.

Jest taki format/język programowania? jak asciidoc, służy on do pisania dokumentacji. Pliki posiadają rozszerzenie .adoc. Asciidoc przypomina Markdown i jest również interpretowany na githubie.
Zasadniczą zaletą pisania w asciidoc jest to że pisząc skupiamy się na treści dokumentu, nie na formatowaniu. Ponadto asciidoc pozwala na dodawanie instrukcji warunkowych, dzielenie dokumentu na podrozdziały w osobnych plikach, importowanie plików .csv do tabel itd.

Aby się tu zbytnio nie rozpisywać zapraszam pod ten link po więcej:
https://asciidoctor.org/docs/what-is-asciidoc/

No i fajnie, no i spoko, ale po co to komu?
Z plików w asciidoc możemy generować strony HTML lub pliki .PDF

Tak jak pisałem wyżej - plik zawiera treść, formatowanie jest zależne od pliku .css dla HTML albo pliku motywu .yml dla generowania plików .pdf, ponadto mamy instrukcje warunkowe i inne bajery.

Dzięki temu można stworzyć jednolity styl dokumentacji - plik motywu, który będzie wspólny dla generowanych dokumentów.
W przypadku zmiany np. logo, wielkości nagłówków, przypisów w stopce itd. trzeba edytować tylko plik motywu. Cała dokumentacja zostanie przebudowana według niego automatycznie.

Dodatkowo dzięki instrukcjom warunkowym można robić dokumenty wielojęzyczne mniej więcej tak:

Code: Select all

ifeval::["{lang}" == "pl"]
 	Witaj SUPLA
 	sekcja tekstu po polsku.
endif::[]

ifeval::["{lang}" == "en"]
 	Hello SUPLA
 	text section in english.
endif::[]
W takim wordzie chcąc mieć dwa języki trzeba by było mieć dwa pliki i w każdym robić zmiany, nie mówiąc o dodawaniu, czy skalowaniu obrazków, tabel itd.

W załączniku dodaję plik pdf - fragmenty instrukcji do gniazdka wifi wygenerowany z użyciem napisanego przeze mnie motywu dla supli.
Jak wygląda ten tekst w asciidoc można zobaczyć tutaj:
https://pastebin.com/LytsB89E
Zrzut ekranu z 2018-03-03 18-48-59.png
Ta instrukcja jest niekompletna, ale nie o to tu chodzi. Jak podoba Wam się formatowanie(nagłówki, stopki, strona tytułowa)? Rzeczy takie jak spis treści, daty, nazwy rozdziałów w nagłówkach i stopkach, numeracje, itd. są generowane automatycznie.
doc.pdf
Jak bym to widział w przypadku SUPLI:

repo na github:
supla-adoc-common zawierające motyw, obrazki użyte w motywie, pliki lokalizacji(obsługa języków), czcionki motywu. Trzymałbym tu też na przykład screeny konfiguracji w przeglądarce i na smartfonie. Interfejs SUPLi ewoluuje, i obrazy te w instrukcjach nie są aktualne. Tu wystarczyłoby je aktualizować w jednym miejscu, i z automatu leciałoby to na całą dokumentację odwołującą się do tych obrazów.

W repozytoriach z projektami pliki .adoc z instrukcjami i dołączonym supla-adoc-common zewnętrznie jako submodule, a także skryptem .sh/.bat do generowania plików .pdf
You do not have the required permissions to view the files attached to this post.
User avatar
fracz
Posts: 2342
Joined: Fri Oct 28, 2016 10:56 pm
Location: Kraków
Has thanked: 4 times
Been thanked: 6 times

Post

1. Nie widzę zalet w porównaniu do innych już dobrze przyjętych formatów, np. choćby wspominany markdown. Markdown za to ma dużą zaletę - jest coraz bardziej popularny i każdy zaczyna powoli się z tym oswajać. Wszystko co piszesz o eksportowaniu/kolorowaniu CSSem itd w Markdown też jest możliwe.
2. Języki ifologią? Moim zdaniem niewygodne i błędozachęcające jakieś krzaki wstawiać żeby zrobić sekcje. Osobny język w osobnym pliku i nie, nie doc, bo to musi być pod kontrolą wersji a wersjonowanie doców nie jest najprzyjemniejsze.
3. Chciałeś nam tylko pokazać czy może chcesz coś napisać? ;)
QBA-dev
Posts: 48
Joined: Sat Mar 03, 2018 5:48 pm
Has thanked: 2 times
Been thanked: 3 times

Post

Jeśli tylko potrzebujecie, to mogę przepisać instrukcje w asciidoc, i opublikować wszystkie pliki. Pytam jak na razie czy taki koncept się podoba.
Co do języków w osobnych plikach, to można też robić całe rozdziały i je include'ować w wymaganych miejscach. Najgorsze są sytuacje gdy trzeba coś dopisać, przeformatować, dodać rysunek. Z tymi if'ami w asciidoc pracujemy na jednym pliku, w wordzie by trzeba było robić to po dwa razy.
I zgadzam się że wersjonowanie plików .doc nie jest fajne.
User avatar
pzygmunt
Posts: 20302
Joined: Tue Jan 19, 2016 9:26 am
Location: Paczków
Been thanked: 59 times

Post

Instrukcje, które znalazłeś na www.supla.org są obecnie najmniej istotnie. Najważniejsze są instrukcje/dokumentacja do
supla-cloud, supla-server, supla-dev, aplikacje klienckie, API (choć API będzie się teraz generowało automatycznie).

Problem w tym, że nikt ich jeszcze nie napisał.
SUPLA.... Nareszcie w domu.
QBA-dev
Posts: 48
Joined: Sat Mar 03, 2018 5:48 pm
Has thanked: 2 times
Been thanked: 3 times

Post

Dokumentacja do rzeczy wymienionych wyżej, będzie raczej tylko w internecie, więc tu myślę że lepiej Markdown się nada tak jak napisał @fracz. A do dokumentów drukowalnych - instrukcji obsługi dla urządzeń DIY mógłbym udostępnić szablon z motywem, o ile uważacie że jest OK, ewentualnie coś pozmieniać aby było spójne z szatą graficzną na stronie i w aplikacjach.
I też przepisać te instrukcje do Asciidoc - w takim celu napisałem tego posta.

Return to “Pomysły i koncepcje”