Talk:Meeskond: Fontastic: Difference between revisions

From ICO wiki
Jump to navigationJump to search
Ntingas (talk | contribs)
Ssaks (talk | contribs)
No edit summary
Line 19: Line 19:


[[Meeskond: Nocturne No. 20 in C-sharp Minor]]
[[Meeskond: Nocturne No. 20 in C-sharp Minor]]
== Retsensioon prototüübile ==
Esiteks märkasin kohe, et andmebaas initsialiseeritakse automaatselt selle puudumisel. See on prototüüpi avaldades kahtlemata vajalik funktsionaalsus ja palju meeldivam oli prototüüpi hinnata.
Samas, märkasin sellega seoses ka kohe bugi: süsteemi installeeritud fontide nimekiri loetakse andmebaasi loomisel andmebaasi, kuid hiljem süsteemi fonte lisades seda nimekirja andmebaasis ei uuendata. Usun et kindlasti peaks rakendus ka fontide nimekirja vähemalt taaskäivitusel vajadusel uuendama.
MVVM arendusmustrist ei ole kinni peetud, kogu kasutajaliidese kood asub MainWindow codebehindis. Kuna tegu on WPF rakendusega, siis MVVM on tugevalt soovitatav arendusmuster mida kasutada.
Üldine mulje kasutaja seisukohalt rakendusest on hea, rakendus töötab piisavalt kiiresti ning kasutajaliides on arusaadav. Rakendus võiks meeles pidada muudetud Example text-i käivituste vahel. Samuti jääb pisut selgusetuks hetkel tab-ide mõte. Kui tabid on ainult tagide grupeerimiseks, siis võiks kindlasti olla ka võimalus luua tage mis ei ole otseselt ühegi tabiga või on seotud mitme tabiga. Näiteks tagid serif/sans-serif võiks olla nähtavad igas tabis.
Aine seisukohalt tekitab muret rakenduse lihtsus. Juhul kui rakendusele mingit suuremat funktsionaalsust enam juurde ei ole planeeritud, siis usun et vähemalt MVVM mustri kasutamine oleks korralike punktide saamiseks vajalik.
Samas, juba prototüübifaasis on peaaegu kogu planeeritud funktsionaalsus saavutatud, nii et hästi tehtud.
[[Meeskond: Spooky Scary Skeletons]]

Revision as of 01:41, 20 December 2015

Retsensioon analüüsile

Käesolev retsensiooni on koostatud meeskonna Fontastic analüüsile fontidest ülevaate saamiseks ja nende haldamiseks loodavale töölaua rakendusele. Analüüsi retsenseerimisel on lähtutud juhendis “Kodutöö aines “Programmeerimine CSharp keeles” (2015)” projekti analüüsi kohta toodud nõuetest ning võrreldud analüüsi vastavust nendele.

Rakenduse eesmärk on analüüsis selgelt välja toodud. Leitud on aktuaalne probleem, seda on põhjalikult käsitletud erinevatest aspektidest ja esinemisvormidest lähtudes ning selle põhjal koostatud nägemus lahendusest. Siiski ei saa nõustuda väitega, et kuigi Adobe on graafikadisaini tarkvara tootmises peaaegu monopoolses seisus, oleks tema poolt pakutav Typekit justkui ainuke fontide halduse lahendus. Fontide halduse tarkvara käsitlev Wikipedia lehekülg pakub üle 30 alternatiivi, millega oleks meeskonnal ideede kogumiseks ja lihvimiseks kindlasti mõistlik tutvuda. Samuti on Google’il veebipõhine fontide halduse lahendus Google Fonts.

Analüüsis on toodud loodava rakenduse funktsioonina põhiliselt erinevad viisid fontide kuvamiseks, otsimiseks ja valimiseks. Seoses funktsionaalsusega jääb arusaamatuks, mida täpsemalt mõeldakse “[---] Fonte kuvatakse kaartidel, mida on ühes reas näiteks 4 tükki [---]” all. Kas mõeldud on näiteks reas olevaid pilte või hoopis tabeli rida. Üldjoontes võib öelda, et analüüsi eesmärgis toodud probleemi pakutud funktsionaalsus tõenäoliselt lahendab ehk pakub süsteemis installeeritud fontidest parema ülevaate ja võimaluse neid organiseerida.

Sellegipoolest võiks kõnealune rakendus tegeleda ka tegelikult fontide haldamisega ehk kindlasti peaks olema võimalik muuta konkreetseid fonte vastavalt vajadusele aktiivseks ja mitteaktiivseks, nt. liigutades neid operatsioonisüsteemi fontide kataloogi ja rakenduse hallatava fontide kataloogi vahel. Selline vajaduspõhine fontide lülitamine aitaks lahendada ka analüüsi eesmärgi all käsitletud n.n. 500 fondi ja pika valiku kerimise probleemi - aktiivsed oleks ainult konkreetse graafikaprojekti või dokumendi teostamiseks vajalikud fondid. Samuti oleksid fonte kasutavad rakendused kiiremad, kuna neil puuduks vajadus kõigi süsteemi fontide laadimiseks, milleks võib suure süsteemi fontide kataloogi puhul kuluda väga palju aega.

Seoses võimalike takistustega rakenduse arendamisel on meeskond toonud välja ühilduvusprobleemi erinevate Windows’i versioonidega. IT-maailmas kahtlemata väga tavapärane olukord ja probleemi ilmnemisel on tõenäoliselt mõistlik keskenduda ainult paarile viimasele Windows’i versioonile.

Lõpetuseks peatume ka formaalsetel nõuetel. Kodutöö juhendi järgi peaks andmebaasis olema vähemalt 6 andmebaasi tabelit. Meeskonna poolt koostatud analüüsi ja projekti logi põhjal võib järeldada, et plaanitakse kasutada andmebaasi, kuid kahjuks puudub otsene kirjeldus, kas üldse ja kui, siis kuidas, seal fontide nimekirja ning muid tegevustega seotud andmeid hoidma hakatakse. Ülevaatlikkuse huvides oleks võinud andmebaasi skeemi olemasolul lisada ka selle analüüsi juurde.

Kodutöö juhendis on toodud ka nõue, et analüüsi minimaalne sõnade arv peab olema 700, kuid retsenseeritavas analüüsis on ainult 597 sõna. Siiski andis analüüs lahendatavast probleemist ja loodavast rakendusest konkreetse ülevaate.


Fontastic meeskonnale rakenduse arendamisel jõudu soovides

Meeskond: Nocturne No. 20 in C-sharp Minor

Retsensioon prototüübile

Esiteks märkasin kohe, et andmebaas initsialiseeritakse automaatselt selle puudumisel. See on prototüüpi avaldades kahtlemata vajalik funktsionaalsus ja palju meeldivam oli prototüüpi hinnata. Samas, märkasin sellega seoses ka kohe bugi: süsteemi installeeritud fontide nimekiri loetakse andmebaasi loomisel andmebaasi, kuid hiljem süsteemi fonte lisades seda nimekirja andmebaasis ei uuendata. Usun et kindlasti peaks rakendus ka fontide nimekirja vähemalt taaskäivitusel vajadusel uuendama.

MVVM arendusmustrist ei ole kinni peetud, kogu kasutajaliidese kood asub MainWindow codebehindis. Kuna tegu on WPF rakendusega, siis MVVM on tugevalt soovitatav arendusmuster mida kasutada.

Üldine mulje kasutaja seisukohalt rakendusest on hea, rakendus töötab piisavalt kiiresti ning kasutajaliides on arusaadav. Rakendus võiks meeles pidada muudetud Example text-i käivituste vahel. Samuti jääb pisut selgusetuks hetkel tab-ide mõte. Kui tabid on ainult tagide grupeerimiseks, siis võiks kindlasti olla ka võimalus luua tage mis ei ole otseselt ühegi tabiga või on seotud mitme tabiga. Näiteks tagid serif/sans-serif võiks olla nähtavad igas tabis.

Aine seisukohalt tekitab muret rakenduse lihtsus. Juhul kui rakendusele mingit suuremat funktsionaalsust enam juurde ei ole planeeritud, siis usun et vähemalt MVVM mustri kasutamine oleks korralike punktide saamiseks vajalik.

Samas, juba prototüübifaasis on peaaegu kogu planeeritud funktsionaalsus saavutatud, nii et hästi tehtud.

Meeskond: Spooky Scary Skeletons