Team:Meeting 012
Toto je zapis z meetingu c. 12, konaneho dna 12.06.2006 v rotunde. Obsahuje zbezny popis toho, co sa na meetingu riesilo, pripadne k comu sme dospeli ci naopak nedospeli.
- Tento zapis urobil: zlatka.
- Na meetingu sa prebrali tieto temy: use casy Uvodna stranka uzivatela a Detail fotky; zmeny v use case a class modeloch.
Zapis z predosleho meetingu. Zapis z dalsieho meetingu.
Contents |
Formatovanie
Najprv sme riesili, ze by bolo dobre zvyraznovat odkazy, aby sa vedelo, ze to su naozaj odkazy. Dohodli sme sa, ze budeme pouzivat slovicko sekcia. Cize napr. vid sekcia Nastavenia uzivatela.
Tiez sme sa dohodli, ze treba pripravit formatovanie pre "tlacitelnu" verziu wikiny, aby sme jasne videli co su attr, classy a usecasy (napr. sikmo a tucne). O tom, ako bude formatovanie textu vyzerat pri zaverecnej tlaci sa dohodneme neskor.
Moznosti uzivatela
Zlatka toho popisala zbytocne vela, tam kde to nemalo byt. Skrati teda jednotlive kolieska a oznaci rozpisane texty ako move do prislusnych sekcii.
Mala by tiez dorobit:
- vsade kde su odkazy na usecasy nechat velke pismeka, su to zaciatky kapitol
- pozor! tagy su len pre vlastnika fotky (uz neplati!)
- opravit session - last access sa bude menit aj pri pokuse o akciu, ktora sa nepodari napr. koli pravam
- dat dokopy okienka na hlavnej stranke (spravne pospajat a popisat, co to bude, ako sa to ziska a ako zobrazi) - vid. poznamky o hlavnej stranke
- prehodit zoznam prihlasenych priatelov do okienok hlavnej stranky
- pridat timeout na online uzivatelov (nebudeme vyhadzovat zo sytemu naozaj, len ukazeme, tych co su aktivni :) )
- aplikovat move na: profil a nastavenia, skupiny (pozor na linky od Peta), albumy, fotky (mozno sa nieco hodi Jane)
- opravit odhlasenie (co s talkom o timeoute u odhlasenia???)
Simlo dostal za ulohu:
- prerobit usecase na profil a nastavenia uzivatela tak aby to bolo uz naozaj spravne, nech sa to stale nemeni hore-dole
- pridat niekam atribut na ukladanie nastavenia okienok na hlavnej stranke
- pridat atributy access_time_photos a access_time_group (?), kvoli oznamovaniu, ze je nieco nove
Hlavna stranka
Riesili sme jak by asi tak mali vyzerat okienka na hlavnej stranke. Zhodli sme sa na tom, ze sa budu spajat skupiny aj albumy, vzdy tie, ktore uzivatel vlastni a tie v ktorych je zapisany (skupiny), resp. ich ma ako oblubene (albumy). Bude teda jedno okienko pre skupiny, jedno pre albumy. V oboch budu uzivatelove viditelne odlisene od tych druhych.
Okienko skupin
Dalej sme sa dohodli, ze v okienku skupin chceme robit oznamenia o tychto zmenach:
- pocet novych uzivatelov za posledny tyzden (pevne zvolene obdobie)
- pocet novych prispevkov v diskusii k skupine (od posledneho pristupu do skupiny)
- ak ma uzivatel na to prava, zobraz mu pocet cakajucich udalosti na potvrdenie
Okienko albumov
V okienku albumov chceme robit oznamenia o tychto zmenach:
- pocet novych fotiek (od posledneho prihlasenia)
- pocet novych prispevkov v diskusii k albume (od posledneho pristupu do skupiny)
- ak ma uzivatel na to prava, zobraz mu pocet cakajucich udalosti na potvrdenie
Albumy, ku ktorym bude mat uzivatel pristup, ale nebude ich vlastnikom, ani ich nebude mat ako oblubene/notifikovane nebudu uzivatela nijak upozornovat na svoje zmeny.
Okienko fotiek
Tak tu sme sa nezhodli, ci na hlavnej stranke zobrazovat okienko s fotkami tiez spolu so zmenami pri fotkach. Bude treba dohodnut neskor. Ak by sa to robilo, bolo by to (podla Zlatky) zbytocne moc velke, ale na druhej strane by sa to vraj mohlo niekomu (podla Simla) zist.
Maily uzivatela
Riesili sme dovod existencie dvoch mailov v systeme a pripadnu moznost vyberat si z nich, ktory bude kedy pouzity. Padol navrh na jeden registracny mail a jeden zobrazovany mail.
- Registracny bude pouzivany ako kontaktny z pohladu systemu: zabudnute heslo, notifikacie, ..
- Zobrazovany sa bude zodbrazovat v profile, budu na neho posielane spravy od uzivatelov, atd.
Menu
Bude treba vymysliet, co bude obsahovat menu. Bude sa zobrazovat vzdy, takze by malo byt rozumne zostavene.
Navyse bude treba rozlisovat, co ma dane menu obsahovat v konkretnom systeme. Nema napr. zmysel ukazovat zobraz prehlad skupin ked su skupiny zakazane. Neskor sa bude musiet spravne pripravit aj navod na pouzitie systemu, aby neboli tie jednoduche zaplacane zbytocnymi informaciami.
Detail fotky
Jana este opravi par chyb, ktore sme objavili. Napr treba viditelne zvyraznit, ako je to s fungovanim zobrazovania detailu pre navstevnika a pre uzivatela. Najlepsie to napisat niekam na zaciatok.
Mala by tiez dorobit:
- ako sa bude zobrazovat detail fotky (jak to bude vyzerat)
- dokoncit pocitadlo
- poslatie notifikacie pri pridani komentara
- ako sa komentar prida
- smazani komentare (moznost mazat cely podstrom sme zamietli kvoli tazkej implementacii)
- editacia fotky (mozno najde nieco v userovi :)) zlatka toho popisala zbytocne vela)
- dopisat co je to vlastne kos, ze sa z neho da nieco este vybrat
- oznacit veci okolo posielani mailu ako move a napisat len v skratke
Simlo musi prerobit:
- prehodit v usecase vytvorenie notifikacie k uzivatelovi, pre navstevnika to nema zmysel
- vytvorit novy usecase pre udrzbu systemu
Pristup k detailu fotky
Vznikla otazka, ci je spravne povolit zobrazovat detaily o fotke kazdemu (aj navstevnikovi) bez ohladu na to, ci ma k fotke ako uzivatel pristup. To by znamenalo, ze by sa nekontrolovalo, ci ma uzivatel pristup do albumu, v ktorom fotka je. Vacsina teamu preferuje mat moznost zobrazit fotku vzdy, ked na nu uzivatel pozna odkaz. Zlatka sa to zda ako bezpecnostna diera, pretoze sa tym da obchadzat napr zakazovanie pristupu do jednotlivych albumov a teda napr. skupiny by uplne stratili vyznam. Tiez by to znamenalo, ze by sa ku komentarom fotky dostal kazdy (aj skaredy) uzivatel a mohol ich navyse aj pridavat. Mysli, ze by sa mala spravit kontrola podla albumov, v ktorych fotka je. Simlo to povazuje za zbytocne vela snahy pre dosiahnutie pomerne maleho vysledku.
Diskusie a komentare
Dohodli sme sa, ze z prispevkov do diskusie a aj z komentarov k fotkam vyhodime atribut subject. Obmedzia sa tym nezmyselne ci zbytocne nadpisy. Ako subjekt sa bude zobrazovat zaciatok prispevku, ktory bude mat pevne (v kode) zvolenu dlzku.
Tiez sme sa bavili o moznosti mazat viacero prispevkov naraz a riesili mazanie prispevkov uprostred stromu.
Captcha obrazky
Padol navrh mat moznost nastavit dlzku captcha obrazkov namiesto vyberu ci ich zobrazovat, alebo nie.
Zaroven sme sa dohodli, ze ak sa obrazok neopise spravne, tak sa zobrazi novy. A tiez sme sa dohodli na tlacitku vygeneruj novy obrazok.
Tagy
Simlo navrhol zobrazovat (obcas) tagy zoskupene podla zaciatocnych pismenok. Bude sa medzi nimi lahsie orientovat, ak ich bude viac. Tiez je moznost, ak je viac aj pre jedno pismenko pridavat rozdelenie aj podla druheho (prip. tretieho, stvrteho, atd.) pismenka. Muselo by sa ale vyriesit pocitanie tagov pre jednotlive pismenka a ich preskupenie do vyvazenych skupin (staci aby nemali viac ako nejaky zadany pocet tagov).
Reminderon: zoskupovanie tagov. |
---|
|
Taktiez sa vymysleli 2 sposoby editacie tagov k fotke. Ten prvy textovy sme uz mali, pridal sa dalsi s multiselect zonamom uz pouzitych tagov, kolonkou na novy tag a tlacitkami pridaj a odober. Pricom by sa vzdy brala do uvahy len jedna moznost editacie, ktoru by si zvoli uzivatel.
Vyriesili sme case-sensitivitu tagov. Do systemu sa budu ukladat tak ako ich uzivatel zada (prip. prvy vyskyt, ak zada viac rovnakych), vyhladavat sa podla nich bude bez ohladu na velkost pismeniek.
Trieda Photo_version
Dohodol sa novy attribut last_access kvoli udrzbe uloziska fotiek.
Casom bude treba vyriesit sposob generovania nazvov suborov jednotlivych verzii fotiek v systeme. K md5 hashom bude treba nieco pridavat, ak by sa mala pridanim novej fotky prepisat uz v systeme existujuca fotka.
Notifikacie
Chceme dat moznost vytvarat notifikacie pre upload novej verzie fotky? Hodilo by sa to napr. pri neskorsom nahravani kvalitnejsich fotiek miesto povodnych nekvalitnych. Ak by sme to pridali, lepsia implementacia by bola zaradit to ako notifikaciu o zmene v albume, tj ako keby doslo k pridaniu fotky.
Dalej sme sa zhodli, ze sa nebude dat menit notifikaciu. Bud sa vytvori, alebo sa zmaze. Jediny atribut je na frekvenciu posielania a ta sa vztahuje na vsetky notifikacie dokopy. Cize nie na kazdu zvlast, tak ako to bolo doteraz.
Editacia udajov
Mali by sme dohodnut jednotny sposob editacie roznych udajov (detail fotky, profil uzivatela, atd.) aby to nebolo vsade inac.