Végfelhasználói Kézikönyv?

Anonymous képe

Kedves Mindenki!

Úgy adódott, hogy ebben a hónapban 4 db végfelhasználói kézikönyvet kell megírnom, részben társadalmi munkában, részben ügyfélnek. Gondolom, ti is rajongtok az ilyen feladatokért...;)

Ráadásul az egészet egy éven belül újra kell majd csinálni, ha jön a Drupal 5, ahol kissé megváltozik az adminisztrációs felület.

Kérdés: Nem lehetne ezt közösen?

Arra gondoltam, hogy jó lenne, ha itt a Drupal.hu-n lenne kétféle kézikönyv: az egyik a fejlesztőknek (telepítés, modulok, stb.), a másik pedig a végfelhasználóknak.

Nyilvánvaló, hogy a Drupal nagyon sokféleképpen konfigurálható, és minden installáció mellé egyedi kézikönyvet kell(ene) írni. De a kézikönyvek egy része teljesen triviális, és mindig ismétlődik. Hogyan tudok blogbejegyzést feltölteni? Hogyan tudok fájlt csatolni a blogbejegyzéshez? Hogyan tudok YouTube videót beilleszteni az írásaimba? Hol tudom megváltoztatni az email címemet? Hol tudom letiltani az ex-férjem/feleségem jogosultságait?... És hasonló izgalmas kérdések.

Ha lenne valahol egy központi kézikönyv, akkor rugalmasabb ügyfelet egyszerűen oda lehetne irányítani – a kevésbé rugalmasaknak pedig a kézikönyv felét-kétharmadát másol-beilleszt módszerrel le tudnánk szedni innen.

Szerintem egy ilyen központi kézikönyv akkor lehet jól használható, ha:

  • az egyes bekapcsolt modulokat lehetőség szerint izoláltan mutatjuk be;
  • a szükséges képernyőképeket mindig valamelyik alap sminkkel készítjük.

Vélemények?

Fórum: 
csonti képe

Hello Edit,

én is hasonló cipőben járok, az ügyfeleknek rettenetesen kell kézikönyv, ha nem akarom, hogy 30 másodpercenként írjanak egy emilt teljesen triviális kérdésekkel.
Sajnos azonban egy jól érthető leírás megalkotása "nem semmi egy feladat" kategóriába tartozik.
Ezért én kínomban feltaláltam a power -kézikönyvet. :)
A kézikönyv ebben az esetben a köv. képpen készül:
1. Végigveszem pl. egy modul működésének bemutatáshoz a lépeseket, közben minden lépésnél mentve egy képernyőképet.
2. A gimp -ben kivágom a lényeges részt.
3. Előkapom az openoffice impress -t és létrehozom minden lépéshez a diákat, képeket és néhány mondatos magyarázatot téve mindegyikre.
4. Elmentem e cuccot powerpoint formátumban, hogy minden win***** platform alatt is élvezhető legyen.
Innem a power -kézikönyv elnevezés. :))
Ha itt lehetne fájlot csatolni, hozzátenném eme hozzászólásomhoz egyik jópofa, audio modul és menü-kategorizálás megértését segítő prezentációmat, mely kb. másfél óra alatt elkészült!
Lehet röhögni!
:)

dhost.hu admin

0
0
Illyés Edit képe

Szia csonti,

szétnéztem a portálodon, és pontosan erre gondoltam, ilyeneket kell nekem is gyártani nagy tételben.

Van a Firefoxhoz egy Screengrab nevű kiterjesztés, bár nincs még meg az FF 2 verzió. Korábban dolgoztam vele és nagyon kényelmes volt, jpeg fájlként rögtön lementette a böngészőablak képét, nem kellett ide-oda lépegetni a böngésző és a grafikai program között.

A power-kézikönyv az ügyfél szempontjából valószínűleg sokkal jobb, mint a sima weblap leírás. De a saját szempontjainkat is figyelembe kell venni: egy-egy leírást, képernyőképet gyorsan megtalálni, jobb egérgombbal kijelölni-másolni-lementeni, node-okat, egész könyvet exportálni-importálni, nyomtatóbarát verzió, PDF verzió, stb. Szerintem ezt a rugalmasságot csak a hagyományos Drupal könyvlap adja.

Végül is az egészhez csak annyi kellene, hogy aki be akar kapcsolódni, az kapjon .jpg, .gif, .png csatolási jogosítványt, meg legyen egy könyvlap, ami alá elkezdhetjük feltölteni a dolgokat. A többi meg majd kialakul... Én szívesen csinálnám, nekem most édes mindegy, hogy 1 vagy 2 helyre töltöm fel lényegében ugyanazt az anyagot...

Ui.: Ja, és persze kellenének a kép paraméterek. Elég szűk itt a hely a fő tartalmi blokkban.

0
0
Anonymous képe

https://addons.mozilla.org/firefox/3408/
Save As Image

Ez megy 2.0 ff-on. És jobb lett mint a Screengrab.

0
0
csonti képe

Hello Edit,

megmondom őszintén, hogy én nem vagyok túlságosan elájulva a book modultól. Ugyan, mondja már meg valaki, hogy miért jobb html -ben, könyvlaponként böngészni a kézikönyvet? Arról nem is beszélve, hogy a html -t az ember szinte élete végéig szerkesztgetheti, ha azt akarja, hogy jól nézzen ki az összes, egymással harcban álló böngészőben. :)

Szerintem nem mindig a "rend" meg a "logika" útja a legjobb. Azt kell nézni, hogy mi kell a felhasználónak, hogy mire "harap rá." tényleg szép és logikus egy katonás kézikönyvet csinálni, de ha ezzel temérdek pluszmunkát okozunk magunknak és a laikus érdeklődők meg csak néznek bambán, akkor minek?

Inkább létre kellene hozni egy kategóriát (pl. "mindenféle leírások"), melyhez tartozhatna mindenféle tartalmi forma és ebbe pakolásznánk az általunk kreált dokumentációkat: ppt fájlokat, könyvlapokat, videókat stb. stb. amit a saját felhasználóinknak készítettünk és megosztanánk másokkal. Ezen kívül csak egy dolog kellene: a dokumentációkat beküldők számára fájl feltöltési jogosultság.

Szerintem...
dhost.hu admin

0
0
Illyés Edit képe

Ugyan, mondja már meg valaki, hogy miért jobb html -ben, könyvlaponként böngészni a kézikönyvet?

Böngészni nem jobb, de apró lépésekben bővíteni, keresni benne, részeket kimásolni, már feltöltött és beágyazott anyagokra (kép, videó) hivatkozni, részeket vagy az egészet exportálni-importálni - erre a fapados HTML a legjobb.

Arról nem is beszélve, hogy a html -t az ember szinte élete végéig szerkesztgetheti, ha azt akarja, hogy jól nézzen ki az összes, egymással harcban álló böngészőben. :)

Hát igen, ilyen szomorú a webfejlesztő élete. Mennyivel egyszerűbb lenne minden, ha a web csak PowerPoint prezentációkból állna...:)

Inkább létre kellene hozni egy kategóriát (pl. "mindenféle leírások"), melyhez tartozhatna mindenféle tartalmi forma

A könyvbe mindenféle tartalmi típust beszerkeszthetsz. Csak a könyv nyitólapjának kell "könyvlap" típusúnak lenni, alá bármit betehetsz. A "könyv" egy absztrakt izé, ami leírja a node-ok egymáshoz való viszonyát, hierarchiáját. Ez egyébként le is van írva a már működő fejlesztői Kézikönyvben (ami ugye könyv jellegű, csakúgy, mint a Drupal.org dokumentációja).

0
0
Anonymous képe

De lehetne wiki is, ha a könyv nem jó. Bár szerintem tökéletes, utána bármilyen node-t kilehetne varázsolni belőle.

0
0
csonti képe

Hát igen, ilyen szomorú a webfejlesztő élete. Mennyivel egyszerűbb lenne minden, ha a web csak PowerPoint prezentációkból állna...:)

teljesen félreértesz. Én mindössze annyit akartam mondani, hogy a felhasználók letölthessenek mindenféle formában adott doksikat. Nem kellene csuklóból elutasítani egy lehetőséget, mert mindennek megvan az előnye/hátránya.

Amit pedig a készülő portálomon találtál, az egy tipikus könyvlap doksi volt és nem véletlen, hogy egyelőre nincs belőle, csak kettő.. :(
Szóval, ha lesz lehetőség arra, hogy fel lehessen tölteni dokumentációkat fájl mellékletként, akkor én szívesen feltöltök, de ha könyvlapok mellett döntötök, akkor jó munkát kívánok. :)

dhost.hu admin

0
0
Hojtsy Gábor képe

Hogy van az, hogy a könyvlap mellett döntünk *vagy* a dokumentációs fájl feltöltések mellett? Ezek szerinted kizárják egymást?

0
0
csonti képe

Hello Goba,

igazad van, végülis nem zárják ki egymást. Csinálhatom azt pl. hogy létrehozok egy könyvlapot, adok rajta egy leírást a csatolt dokumentációról és beküldöm.

dhost.hu admin

0
0
Illyés Edit képe

Én úgy gondoltam, hogy az itt lévő kézikönyv alapvetően egy mézesbödön, amire rájárunk, amikor a felhasználóinknak írjuk a kézikönyvet.

Persze rugalmas (szuperértelmes v. technikai iránt érdeklődő v. közeli ismerős) felhasználónak mondhatod, hogy www.drupal.hu/kezikonyv. De azért szinte mindig kell külön kézikönyvet írni a nagyszámú lehetséges konfigurációs beállítás miatt. Csak nem kellene nulláról kezdeni, lehetne szövegrészeket, képeket, egész lapokat, fejezeteket lopkovicolni innen.

Hogy ezt te milyen formában továbbítod az ügyfeleidnek - egy-az-egyben beimportálod a Drupal alá, vagy exportálod PDF-be, beszerkeszted PowerPoint-ba, stb. - az már mindenkinek a magánügye.

Ha engedélyezik Gáborék pl. prezentációk feltöltését fájlmellékletként, nekem úgy is jó. De akkor a munkád egy önmagába zárt egész, nem tudok pl. az általad lementett képernyőképekre a saját oldalaimból hivatkozni.

Kérdés, hogy mi a hatékonyabb: ha mindenki feltöltheti a saját dolgait tetszőleges formátumban, vagy ha megpróbálunk szabványosítani. Szerintem az utóbbi, de ez csak 1 vélemény.

0
0
Anonymous képe

0
0
Hojtsy Gábor képe

Nem rossz ötlet. Mire lenne ehhez itt szükség? Egy könyvlapra a kézikönyvön belül, és jogosultságra a potenciális szerkesztőknek a módosításhoz? (A dokumentációs csoport most nem létezik, nincsenek magyarul dokumentáló emberek, ez gondolom látszik).

0
0
Illyés Edit képe

  1. Eldönteni, hogy milyen formátumban készüljön a kézikönyv. Én arra szavazok, hogy csak alapmodulokat használjunk.
  2. Eldönteni, hogy a képernyőképek milyen formátumban készüljenek. Például:
    • .png;
    • 500x500 pixel;
    • 72 pixel/inch felbontás;
    • kiemelt részek 5 pixeles piros (#ff0000) keretben;
    • Bluemarine v. Garland smink;
  3. Dokumentációs munkacsoport képfeltöltési jogosítvánnyal.
  4. Az útvonal neve, ahová a feltöltött képek felkerülnek, hogy tudjunk rá hivatkozni. (A kézikönyv lapjain a képernyőképek alá mindig ki kellene írni a képfájl nevét, hogy ha más által feltöltött képet szeretnék új lapba ágyazni, ne kelljen a forrást bújni a fájlnevet keresve.)
  5. Egy leírás kép, képfájl neve, képaláírás beágyazásához (milyen HTML címkéket, CSS osztályokat használjunk).

Szerintem ezzel el lehetne indulni. Egyelőre ömlesztve tegyük fel az oldalakat a szülőlap alá, ha már van 30-40 lap, akkor majd kitaláljuk, hogy hogyan is lehetne rendszerezni.

0
0
Anonymous képe

Ezzel csak az a baj hogy az ügyfél ált. olyan portált kap ami picit sem hasonlít a bluemarine-re, ezért erőltetném ezt a http://drupal.org/project/site_tour megoldást. Bár ha a kedves ügyfélnél tiltva vagyon a js akkor kell egy "screenshot" megoldás is.

Kellene egy alap megoldás (ide), meg egy kiterjeszthető is (később).
Írjuk meg a szövegi részét Bluemarine-os sminkel, vagy ami 5-ben lesz oszt haladjunk. Marha tömören kéne megoldani, szerintem 30-40 lap sok. Nem szeretnek olvasni manapság.

ui. Miért nem lehet ide belépni @Drupal.org azonosítóval? Ha már van ilyen modulocska...

0
0
ingola képe

szerintem arra lenne szükség h elégséges számú emberke kezdjen hozzá mielőbb a dologhoz. (és a fapados html-t támogatnám) így hát én is beszállnék

0
0
Anonymous képe

így van, 4-en vagyunk rá szerintem elég.

0
0
ingola képe

forrás kézikönyvhöz:
http://lmv.hu/help

persze az oldal szerkesztőit meg kellene kérdezni, de nem hiszem, hogy ne ...

0
0
blast_art képe

Felejtve van a projekt?

Nekem is most kéne ilyesmit készítenem, csatlakoznék ha van még igény rá.

blast

0
0

blast

Illyés Edit képe

Úgy tudom illetékes kartársak valami musical-ben lépnek fel (!) meg egyetemen vizsgázgatnak, ezért nem érnek rá komoly dolgokkal foglalkozni.

0
0
blast_art képe

És te foglalkoznál ilyen komoly dolgokkal? :)

El kellene kezdeni mert feledésbe merül...

blast

0
0

blast

Illyés Edit képe

Eddig arról volt szó, hogy aki szeretne bekapcsolódni, az majd kap képfeltöltési jogosítványt. Szerintem nem fog feledésbe merülni, csak most karácsony van, meg vizsgaidőszak.

Elvileg akár én is nyithatok neki egy külön honlapot, ahol el lehet kezdeni a munkát. Csak úgy gondolom, ennek itt lenne a végleges helye, és amikor legutóbb néztem az Export-Import modult, még elég vegyes tapasztalatokat szereztem. Szóval kérdés, hogy ha egyszer megjön itt a fogadókészség, akkor a már elkészült anyagokat hogyan teleportáljuk át ide...

0
0
pp képe

Sziasztok!

Bennem is érlelődött a gondolat, hogy "dejólenne" egy ilyen kézikönyv. Neki is láttam és ez lett belőle. Ez csak egy kezdeményezés, remélem hasznát veszi a Drupa közösség.

pp

0
0
andrew képe

a flv fileokat mivel ill. hogyan tudod így megjeleníttetni drupal tartalomban?

0
0
Paal képe

http://drupal.org/project/video:

Key features:
 
    * Multiple video types:
          o mov, mp4, 3gp, 3g2 (handled by Quicktime Player)
          o rm (handled by Real Player)
          o flv (handled by FlowPlayer)
          o swf (handled by Macromedia Flash Player)
          o dir, dcr (handled by Macromedia Shockwave Player)
          o wmv (handled by Windows Media Player)
          o ogg theora (handled by Cortado Java Applet)
          o Youtube Videos
          o Google Videos
.
.
.
0
0

--
Palócz Paal Pál, a drupal.hu admin csoportjának tagja
Ajánlott olvasmány: Eric Steven Raymond - Hogyan kérdezzünk okosan

pp képe

http://www.jeroenwijering.com/?item=flash_video_player
(csak nem fizetős szolgáltatás esetén ingyenes, egyébként fizetni kell érte!)

Az első három videót simán html kódként másoltam be, de mostanra már írtam egy minimál szűrő modult,
ami az [akarmi.flv]-t lecseréli a neki megfelelő html kódra. Az flv-ket és a hozzájuk tartozó képeket meg egyszerűen ftp-vel feltöltöm egy könyvtárba.

Paal megoldása jó lenne, de nem tartom értelmét feltelepíteni egy olyan modult, aminek a szolgáltatásainak az 1 százalékát használnám ki, ráadásul az ötös Drupal-hoz még nem érhető el a modul stabil verziója.

Miért bonyolítjuk az életünket azzal a felkiáltással, hogy egyszerűbb legyen ;) Az általam fejlesztett modul az info fájllal, szép kóddal, help szöveggel együtt alig haladja meg az 1KB méretet ;) (az ajánlott modul 60x nagyobb ;))

pp

0
0
andrew képe

megnéztem az említett video modult, meg körbenéztem az összes modul között az elérhető flash player, videó lejátszó stb. modul között és hát úgy éreztem mégsem ez a megoldás adott...

közben én a bbcode modul bbcode-filter.inc -jét kezdtem bővíteni úgy, hogy flowplayer -hez legyen egy kényelmesen használható szűrő, de akkor kb ezt csináltad meg te is ha jól értem, csak külön modulban és másik lejátszóhoz...

0
0
pp képe

andrew képe

hát, hasznos tud lenni, lehet, h kapásból kiadhatnád a stable verziót belőle :)

0
0
pp képe

Azért ahoz egy picit maszírozni kéne a 0.1-es verziót.

Van egy csomó beledrótozott dolog benne, amit sokkal szebben kéne megoldani.

pp

0
0