Oct
7
2007

FOWA 2007: Golden rules for web app development

Pa sem nazaj… FOWA je bila zanimiva, zabavna in predvsem koristna. Ker je you.go že precej natančno povzel predavanja, bom sam izluščil tiste ključne misli, ki so ostale zapisane na disku. Objava bo delno v angleščini, delno v materinščini… upam, da to koga ne moti. :)

Ako spletne aplikacije zgolj uporabljate, pa objavo raje preskočite in si poglejte tole.


“When hiring a new employee, these are the most important things to consider: personality fit, ability to learn, taste, passion for space and familiarity with technologies. If you have doubts about someone, let it pass.”

Dober sodelavec ni nujno tisti z največ znanja. Pogosto boste naleteli na izjemno sposobne ljudi, ki preprosto niso team playerji. Taki ne sodijo v kolektiv. Veliko bolj zadovoljni boste z nekom, ki ima npr. zgolj osnovno znanje v določenem programskem jeziku, a je pri delu strasten, kooperativen in se z veseljem uči novih stvari. Spremljanje strani, kot so TechCrunch, Slashdot, Read/WriteWeb, SitePoint ali Walleywag je že dober znak. Ako se vam pri potencialnem kandidatu pojavi samo kanček dvoma, je to zadosten razlog, da počakate na primernejšo osebo. Najslabše in najdražje je zaposliti napačnega človeka.


“If you can’t build your core features in 4 months, than don’t do it. Don’t over-develop and don’t be afraid to remove features.”

Začnite z eno glavno funkcionalnostjo aplikacije. Če je to nemogoče zgraditi v 4 mesecih (do 3 programerji), je vaša ideja preobsežna. Premislite, kaj je bistvo aplikacije, vse ostalo pa prestavite na kasnejši čas. To, kar aplikacija počne, morate znati opisati v ENEM STAVKU! Razvoj naj poteka v smeri uporabniških potreb. Tudi do lastnih idej morate vzpostaviti kritično distanco, saj pogosto niso tisto, kar si vaši uporabniki resnično želijo. Flickr je bil sprva aplikacija za on-line chat, pa poglejte, kje je danes.


“Approach VC with a company, not with a plan. Approach early.”

Dobro premislite, če VC dejansko potrebujete. V velikanski prednosti boste, če se držite dveh pravil.
1) Pristopite kot podjetje, pa četudi samo z enim zaposlenim, beta verzijo aplikacije in v rdečih številkah. Jemali vas bodo veliko bolj resno, kot nekoga, ki ima samo načrt. Ideas are a dime a dozen. Dobra ideja je zgolj multiplikator (npr. x2, x500), izvedba pa je tista, ki postavi vašemu produktu resnično vrednost. Na svetu je veliko pametnih ljudi, zato je skoraj gotovo, da ima “vašo” idejo tudi nekdo drug. Nima pa izvedbe in ta dejansko šteje. Dobra ideja in dobra izvedba sta, seveda, recept za uspeh.
2) Pristopite takrat, ko kapitala še ne potrebujete - preden vam teče voda v grlo. Tako boste dobili veliko boljše pogoje, saj ste bolj fleksibilni.


“Utility computing - outsource complexity and only focus on what you do best.”

S prevodom termina “utility computing” se niti ne bom ukvarjal, povedal bom samo bistvo. Če bi zidali hiše, kot gradimo aplikacije, bi imela vsaka hiša svojo elektrarno. Zato se trendi pomikajo v drugo, racionalnejšo smer - pustite, da drugi delajo stvari namesto vas in se osredotočite na tisto, kar naredi vašo hišo posebno. Outsource-ajte vse, kar se da in uporabite “pay as you go” model. Izogibajte se nakupu ultra zmogljivih strežnikov, ki predstavljajo velik strošek, da ne omenjamo vzdrževanja. Procesorsko moč in RAM raje najemajte in plačajte toliko, kot dejansko porabite. Če vam uspe, boste preprosto najeli dodatne strežnike in širšo pipo. Če vam res uspe, lahko začnete premišljevati o nakupu lastne strojne opreme in kolokaciji. Do takrat pa so to nepotrebne komplikacije, ki vas utegnejo stati časa, ki ga najverjetneje nimate na pretek. Enako seveda velja za obstoječe programske rešitve - če se npr. ukvarjate z izmenjavo datotek, uporabite Amazon S3, če potrebujete koledar, uporabite Google Calendar.


“After launch, monitor the website 24/7 and reply to blog posts. It’s a very efficient form of marketing.”

Če boste po “splavitvi” spletne aplikacije pokazali odzivnost na blogih, ki pišejo o vas, boste s tem dosegli več stvari. Verjetno najpomembnejša je t.i. človeški faktor, saj boste (potencialnim) uporabnikom dali občutek, da za aplikacijo stoji ekipa, ki ji ni vseeno. Redno odgovarjajte na e-maile in ohranite osebni ton v komunikaciji. Zahvalite se uporabnikom, ki izpostavijo napake, še posebej pa bodite pozorni na tiste, ki predlagajo rešitve ali vam dajejo nasvete pri reševanju težav. Če je le mogoče, jih nagradite, pa četudi le s posebnim statusom v njihovem profilu, ki je viden ostalim uporabnikom. Spremljajte registracije novih uporabnikov - večkrat ste tako lahko opozorjeni na npr. prihajajoči “TechCrunch” efekt, če se registrira uporabnik z @techcrunch.com domeno. Morda gre za minute, a je vseeno dovolj, da zavrtite nekaj telefonov in postavite ekipo v stanje pripravljenosti.


“When building a community, keep the following things in mind: reward your top users, use guidelines rather than rules, keep emotions out of decisions and don’t play the blame game if you mess up.”

Precej razumljivo samo po sebi. Izpostavil bi le zadnji stavek… Priznajte svoje napake. Motiti se je človeško in vaši uporabniki se zavedajo, da je za vsako spletno aplikacijo le skupina ljudi. Včasih gre kaj narobe, ne glede na to, kako pazljivi in natančni ste.


“Don’t punish your regular users to make an extra buck with ads.”

Če je oglaševanje na strani vaš edini vir dohodka, je to seveda brezpredmetno. V nasprotnem primeru pa raje dobro premislite, če se prikazovanje oglasov vašim zvestim uporabnikom res izplača. Raziskave namreč kažejo, da je profil uporabnikov, ki največkrat kliknejo na oglas, precej specifičen. Za oglase so bolj dovzetni uporabniki, ki niso vaši redni obiskovalci (recimo, da so vašo strani našli na iskalniku) in uporabljajo Internet Explorer. Če je le mogoče, oglase skrijte pred vašimi rednimi obiskovalci (tistimi, ki naslov strani vpišejo direktno v naslovno vrstico), uporabljajo naprednejše brskalnike (npr. Firefox) ali alternativne operacijske sisteme (npr. Linux). Vaš finančni izkupiček bo sicer malo manjši, a poželi boste splošno odobravanje tistih, ki vašo aplikacijo dejansko uporabljajo.


“After you launch a new feature, do nothing except bug fixes for 14 days. Keep it as it is.”
Odpor proti spremembam je v človeški naravi, zato uporabnikom pustite čas, da se teh sprememb navadijo. Pritožbe bodo vedno prisotne in največjo napako boste naredili, če boste popustili pritiskom glasne manjšine in začeli z nepremišljenim spreminjanjem aplikacije, da bo le ustrezala njihovim pričakovanjem. Če se pritožbe po 14 dneh še kaj vrstijo, potem premislite, če morda res niste naredili kaj narobe. Hrošče, seveda, popravljajte sproti. In vedno si vzemite čas, da se uporabnikom, ki te hrošče odkrijejo, osebno zahvalite.


“Develop a website as it’s only going to be used by disabled users. You will greatly improve usability for non-disabled users as well.”

Mislim, da tu ni kaj dodati. Če bo lahko (napol) slepa oseba z uporabo Windows Narrator-ja našla potrebne informacije, potem ste lahko skoraj prepričani, da enako velja za običajne uporabnike.


“When developing mobile applications, don’t increase the font, just use bold text. Keep in mind that BlackBerry has CSS turned off by default.”

Vsak brskalnik na mobilnih telefonih je razred zase, zato se držite tega pravila: 176 pixlov širine in 10k prenosa na posamezno stran.


“When optimizing, focus on frontend first. Backend (database) improvements are difficult and often not very significant.”

Pogosto je razlog za počasno nalaganje strani v predstavitveni plasti, se pravi v strukturi HTML, CSS in Javascript datotek. Za analizo si namestite Firebug, nato pa še YSlow, ki spletno stran analizira in sam predlaga spremembe, ki jo utegnejo pohitriti. Glede na to, da je spreminjane strukture frontend-a neprimerno lažje, hitrejše in varnejše kot optimiziranje poslovne logike in poizvedb na podatkovni bazi, se je priporočljivo najprej lotiti tega. Več si lahko preberete tukaj.


“Cache expensive database queries with Memcached.”

Memcached omogoča, da najbolj zahtevne poizvedbe shranite v RAM in se tako izognete branju diska. Seveda ne bo šlo brez spreminjanja delov kode, a razlike so velikanske.


“If Chuck Norris can wear pink, any man can.”

:)

Ostalo je še ogromno stvari, ki jih nisem omenil. Predvsem gre za vsebine petkovih delavnic, ki bi si zaslužile svojo objavo. O teh morda kdaj drugič ali na bolj oseben način, recimo ob skodelici kave… za tiste, ki jih zanima.

Objavil: besso...         Kategorije: Cruisin', Tech        

Brez komentarjev »

RSS feed za komentarje na to objavo. TrackBack URI

Komentiraj objavo

Èe želiš komentirati, moraš biti prijavljen.




Creative Commons License

p4b.nu is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 2.5 Slovenia License.

Mashin' it BrandNu style | We also Twitter | Contacts, inquiries and DJ bookings via contact [at] p4b.nu
Design by Ozren :: template by #kruh :: developed and hosted by APPoteka
Inspired by WordPress - Code is poetry
Entries and comments feeds Valid XHTML and CSS ^Top^