Improvement is fun! 0 16.07.2010
It is clear to us that regardless of the number of changes we make, we see the need for more. Improvement is fun. One or two improvements uncover the need for other improvements.
John Smith, COO, Ross Controls
Reinvent vs Reuse 3 21.05.2010
[There's] a famous fault in software engineers to instinctively favour reinvention over reuse, not just because they are unfamiliar with what came before, but because they misunderstand why it came before.
Ovaj citat mi je pao na pamet kada sam razmišljao o emailu. Email je servis Interneta koji je toliko dugo sa nama i koji ima toliko istorije da dosta ljudi koji programiraju aplikacije koje se oslanjanju na njega ne razumeju gomilu stvari vezanih za email i povezane standarda, kao ni razloge zašto su te stvari tu i zašto rade baš na način na koji rade.
Takve stvari ja u svojoj glavi imam markirane kao “legacy”. Ukoliko je to nešto toliko pustlo korenje da je sada standard i da je gotovo nepromenljivo, prihvati i guraj bez obzira koliko shakovano sve izgledalo i koliko “bolje” može da se uradi.
Praćenje kretanja korisnika kroz stranice 5 27.07.2009
Jutros nešto razmišljam o podršci i praćenju korisnika – ne bi li bilo lepo znati koje je stranice korisnik prethodno posetio (i kako je došao do njih) pre nego što vas je kontaktirao za pomoć? Iz toga bi se dosta dalo zaključiti: koliko posetioci stvarno obraćaju pažnju na dokumentaciju, da li prvo pretražuju ili odmah klikaju na Contact dugme itd.
I tako nažvrljam na papiru sledeće:
posete -< otvorene stranice
Svaka poseta može da ima niz otvorenih stranica. Dovoljno jednostavno samo po sebi, ali nedovoljno ukoliko se ne prati sa koje stranice je korisnik došao na koju stranicu. Davno smo prerasli browsere sa jednim prozorom i doba kada su se korisnici linearno kretali kroz sajt. Ponašanje današnjih korisnika više liči na drvo sa gomilom račvanja nego na flat listu stranica koje su posetili.
I tu je problem – kako pratiti koje stranice otvaraju koje stranice?
Prva stvar koja mi je pala na pamet je jednostavno kačenje ID-ja trenutno otvorene stranice na sve linkove na stranici (jedna linija JavaScripta bi sasvim lako nakačila ove vrednosti):
http://www.activecollab.com/contact?from=123
gde je from vrednost ID trenutno otvorene stranice u logu. Najveći problem kod ovog pristupa je što se “prljaju” URL-ovi sa podacima koji bi generalno trebalo da se prenose u pozadini.
Takođe ne znam kako botovi pretraživača tretiraju ovakve URL-ove. Da li smatraju stranicu drugačijom kada je GET parametar drugačiji? U kojoj situaciji ignorišu određene GET parametre? Kada liče na hash? Ima li neko više informacija o ovome?
Očigledno “prljanje” bi se dalo rešiti JavaScriptom tako što se presreće klik događaj svakog linka i pre same redirekcije kači ID trenutno otvorene stranice. Ovo ne bi radilo kada posetilac otvara linkovanu stranicu u novom tabu jer se tada preskače klik događaj. Otvaranje stranica u novom tabu je dosta čest slučaj, posebno kada se traže neke informacije bez da se jasno zna gde se iste nalaze (nakon pretrage foruma npr – posetilac će isklikati sve top teme u novim tabovima i tražiti odgovor na svoj upit u njima).
Druga opcija je da se oslonimo na browser da nam kaže odakle je korisnik došao. Ovo je nepraktično zato što nije potpuno rešenje (neki korisnici isključu prosleđivanje referrer informacija) i što bi onda na osnovu referer stranice morali da kopamo po logu i tražimo tačan ID prethodne stranice. Deluje kao nepotreban korak pošto taj info već ionako imamo na prethodnoj stranici.
Treća opcija koja mi je pala na pamet je da se jednostavno svim linkovima doda rel=”nofollow”, a struktura sajta ponudi kao sitemap. Ovo je naravno jako glupo pošto bi pretraživač video gomilu stranica na koje ni jedna druga stranica “zvanično” ne linkuje i verovatno bi im dobrano oborio vrednost.
I tako ne dođoh ni do kakvog zaključka… Cela ova priča je samo razmišljanje naglas. Zakucam tako ponekad sa problemom koji mi deluje interesantno iako i nemam stvarnu potrebu za rešavanjem istog. Zanimljivo je ipak, kao vežba za vijuge ako ništa više 
Šta smo naučili iz bete 0 14.05.2009
Pre nešto manje od dve nedelje objavili smo activeCollab 2. U pitanju je verzija na kojoj se dosta drugo radilo, sa nizom značajnih unapređenja.
Pored niza sitnih i krupnih unapređenja, ima i stvari (mogućnost sistema da prima emailove npr) koje iz korena menjaju kako ljudi koriste sistem. Takva verzija ne može da prođe bez bete. Manje, bug fix verzije sa sitnijim unapređenjima mogu da idu (samo paziš šta radiš i kontrolišeš se da se ne zaneseš previše sa dodavanjem novih stvari), ali nešto sa dosta izmena ne ide.
Prošle godine, u slično vreme je išla activeCollab 1.1 beta i to je bio prvi put da smo imali testiranje tog tipa i te veličine. Beta je bila javna tako da su svi koji su imali licence mogli da skinu novu verziju i testiraju je. To se pokazalo kao dobar pristup tako da smo na isti način išli i sa betom za verziju 2. Ono što je bila greška je to što smo za 1.1 bete dodavali nove mogućnosti.
Kada se tokom bete dodaju nove mogućnosti, svi testovi padaju u vodu – na ovaj način u sistemu se uvek nalaze stvari koje su nove i nestabilne. Naučeni greškom, activeCollab 2 beta je lansirana tek kada smo imali sve mogućnosti koje smo želeli da predstavimo. Svrha bete nije da timu da još vremena da nabaca još koju novu mogućnost, već da mu omogući da ispegla ono što ima i postara se da je sistem stabilan.
Pristup da se mogućnosti kompletiraju pre bete, pa zatim peglaju bez dodavanja novih, ima još jednu dobru stranu: tačno se zna kada je verzija gotova – kada se stabilizuje. Ukoliko se nove mogućnosti dodaju tokom bete, konačni set mogućnosti je uvek otvoren pa se jako lako zaneti, dodati previše novih stvari i celo “testiranje” produžiti za još koji mesec. Na kraju stvarno završite sa više mogućnosti, ali su one nestabilne i prava su noćna mora za podržavanje.
Zato sa betama treba pažljivo:
- Napravite sve mogućnosti koje želite da finalna verzija ima i onda ih peglajte, bez dodavanja novih mogućnosti.
- Pažljivo odabrate datum kada želite da vidite finalnu verziju, ali ga nipošto nemojte objaviti. Ako to uradite, velika je verovatnoća da ćete požuriti sa betom usled pritiska od strane korisnika, a samim tim i izbaciti manje stabilan proizvod. Ovo se uvek vrati kao bumerang u vidu značajno više posla oko podrške.
- Što se podrške tiče, tretirajte betu kao i bilo koju drugu stabilnu verziju. Izvlačenje na fazon: “Beta je, i treba da ima greške. Strpi se do sledeće verzije” će za rezultat imati da će se ljudi opeći i neće želeti sledeći put da pomognu.
- Opustite se i uživajte u procesu. Pritisak uvek za rezultat ima greške i uglavnom je kontra-produktivan. Umesto da šizite i gurate oštre rokove, opustite se i polako sa korisnicima privedite betu kraju. Na kraju ćete izbaciti stabilan proizvod bez da osedite u procesu.
U poređenju sa prethodnom beta koja je bila dosta napeta, verzija 2 se desila polako i na kraju smo stvarno zavriši sa znatno boljim proizvodom za koji nije trebalo toliko podrške kada je početna navala prošla. Sada se već radi na narednoj verziji pa se opet nadamo skoroj beti.
PS: Tekst sa istom temom i savetima, ali malo drugačijim sadržajem je prekjuče objavljen na A51 blogu.
Da li su sva “pravila” bitna? 2 25.03.2009
I juče i danas se na pomalo čudan način povukle pitanje pravila koja aplikacija nameće korisniku.
Konkretno, juče sam veći deo dana proveo radeći na dokumentaciji. Svaki članak se sastoji od naslova i sadržaja. U takvim situacijama aplikacije uglavnom zahtevaju od korisnika da unesu obe vrednosti pre nego što prihvate izmene. To je nametnuto pravilo koje korisnik mora da poštuje kako bi mogao da koristi sistem.
Naša aplikacija nije toliko stroga pa zahteva samo naslov što mi se, kao korisniku, pokazalo jako zgodnim. Umesto da završavam stranicu po stranicu, prvo sam kreirao niz stranica na kojima treba da radim prostim unošenjem naslova pa tek onda počeo da unosim sadržaj. Na taj način sam imao celu strukturu pred sobom i tačno znao šta treba da radim i kako napredujem. Da je aplikacija od mene zahtevala i unos sadržaja, pitanje je da li bih tako radio.
Jutros je osvanuo komentar na jednu temu gde se korisnici pitaju zašto jedan element u activeCollabu zahteva minimalno 3 slova dugačak naslov. Razmišljajući o tome šta i kako da odgovorim čoveku, zapitao sam se li su uošte ta pravila i bitna? Zašto sistem jednostavno ne bi puštao korisnika da ne unese vrednost?
Na primer, ako korisnik ubaci zadatak bez opisa, sistem može da stavi opis na neku podrazumevanu vrednost. Kada korisnik naknadno vidi unos, može da upotpuni podatke ako želi ili ostavi tako kako je ako mu to nije bitno…
Prijavi problema kao na slici ništa ne nedostaje, iako je kratak opis izostavljen. Sve što treba je tu:
Kasnije, kada se detaljno pozabavi problemom, Goran može uzeti i izmeniti “[NO SUMMARY]” u “Nakon instalacije modula, keš se ne osveži što može praviti probleme pri učitavanju stilova” ili šta god da nađe kao stvaran uzrok problema.
Da sumiram, pitanje je da li su sva pravila koja ubacujemo u svoje aplikacije dobra? Da li bismo olakšali ili otežali korisniku time što bismo umesto forsiranog unosa omogućili da ostavi polje praznim? Koja su mesta u aplikaciji gde po inerciji dodajemo pravila koja nužno i ne pomažu i bez kojih se može?