Google Font API: egy szebb webért

Rengeteg fontos dolgot jelentett be tegnap a Google. Egy-kettőre én is kitérek ezen a blogon. Az egyik mindjárt egy valóban fontos dolog: a Font API és a hozzá kapcsolódó Google Font Directory. A kiváló minőségű, ingyenesen hozzáférhető és alakítható webes fontkészleteket a Google olyan formában kínálja a netezőknek, hogy azokat tényleg pofon egyszerű beilleszteni bármilyen webfelület sablonjába.

Lassan tehát megszűnhet a web-safe fontok hegemóniája a neten. Nem mintha bajunk lenne az Ariallal vagy a Verdanával, de a minőségi alternatívák megjelenése mindenképpen jót fog tenni a webnek.

A Webisztán postcímeit 10 másodperc alatt alakítottam át Droid Serif betűtípusra. Ehhez mindössze a html-be és a css-be kellett egy-egy sort beszúrni. Ráadásul még IE6-ban is működik a dolog. A fejlettebb böngészőkről nem beszélve. A lényeg itt tényleg az egyszerűség és az akadálymentes működés. Próbáljátok ki!

Az egész csak azért ennyire flott és gördülékeny, mert a Google Font API a háttérben elvégzi a betű konvertálását, formázását. (A magas minőségű fontok egyébként támogatják a CSS3 új funkcióit, így például a szövegforgatást, árnyékolást stb is.)

A Google Font Directory lehet a jövőben az egyik fontos lista, amiben szabadon felhasználható, kiváló minőségű fontok közül válogathatunk. Ehhez persze arra lesz szükség, hogy a világ fontdizájnerei közül a legjobbak beküldjék egy-két jobban sikerült, szabad felhasználásra érett munkájukat.

A minőségi open source fontok publikálása mellett még egy fontos bejelentése volt tegnap ebben a témában a Google-nak: a TypeKittel karöltve megnyitják a WebFont Loader JS-libet (github), így a font betöltődésének módja, renderelése - akár böngészőtípusonként eltérően - alakíthatóvá válik. (Merthogy ugye a Firefox például előbb tölti be a web safe fontokat, és csak utána rendereli újra a letöltött új fontokkal az oldalt, ami nem egy szép megoldás. Ennek orvoslására pl érdemes beizzítani a WebFont Loadert.)

Az már most látszik, hogy a Google tegnaptól fogva határozottan és masszív támogatással, open source megoldásokkal és jól dokumentált API-kkal segíti az új, HTML5+CSS3 alapú világ terjedését.

Ez pedig teljes mellszélességgel támogatandó törekvés.

Címkék: google dizájn api open source font webdizájn
2010.05.20. 10:32. írta: hírbehozó

A Twitter mostmár igazán bikicsunáj

... vagyis Big in Japan. Nézzük csak a japán Softbank média- és telekommunikációs cég tegnapi sajtótájékoztatóján készült képet:

Impresszív Twitter fal...

A Softbank amúgy azt jelentette be, hogy mostantól egy csomó, általuk forgalmazott készülékben előre telepítve lesz a Twitter. Hogy mennyire fontos eseményről beszélünk, jól jelzi, hogy a Twitter társalapítóját, Ev Williamst élőben kapcsolták, aki elmondta, hogy a világ többi részéhez képest is kiemelkedő a Twitter növekedése Japánban.

Ezt támasztják alá a Nielsen adatai is: míg az USÁ-ban 10 százalék körüli a Twitter elterjedtsége, addig Japánban már 12 százalék körüli az elérésük. Egy éve még csak félmillió japán volt rákattanva a státuszfrissítésre. Mostanra viszont 7,5 millióan twittereznek a távol-keleti országban.

Kezdik ostromolni a helyi népszerű közösségi szájtot, a Mixit (kékkel) is: 

Erre fog most rátenni egy jó nagy lapáttal a helyi telekommunikációs nagyágyúnak számító Softbank. Ha már Softbank: ugye ez az a cég, ami pár hónapja jelentékeny összeggel szállt be a Ustream.tv-be.

Szintén a tegnapi rendezvényen jelentették be, hogy a Ustreamnek immár nem csak a japán piac, hanem az egész ázsiai régió célpontja. Vagyis Kínába és akár Indiába is beléphet a magyar fejlesztésű live-streaming szolgáltatás.

Azért tegnap elindították a japánoknak készült iPhone appjaikat is. A Ustream amúgy a Twitterhez hasonlóan siker Japánban. Alig léptek be a piacra, máris a 200 leglátogatottabb szájt között vannak. Ahogy a Ustream társalapítója, Fehér Gyula a múltkori interjúban mondta, "komoly érdeklődés övez minket Japánban és ezt ki is fogjuk aknázni, egy ilyen piacon komolyan lehet növelni egy cég értékét."

A fő riválisuk a helyi piacon a Nico Video (kékkel):

Címkék: japán ázsia twitter ustream
2010.05.19. 20:52. írta: hírbehozó

Google I/O: bejelentések, élőben

20:04 Itt lehet játszani az újcuccokkal: code.google.com/cloudportability

19:58 Akárhogy is nézem, a mai nap legfontosabb bejelentése a nyílt forráskódú,ingyenesen hozzáférhető WebM és VP8 (sdk itt). Vagyis minden adott ahhoz, hogy a közeljövőben emelkedjen a webes videótartalmak színvonala.

19:52 Google App Engine for Business bejelentés (SQL szupporttal). Ez nekünk nem túl érdekes most. Addig is nézzünk ráa Twitterre.

19:47 Nekem is elment egy kicsit a netem, akárcsak az előadóknak. De most újra rákapcsolódok a streamre. Btw, itt a Google mai napi összefoglalója a bejelentésekről, fejleményekről.

19:20 GWT + Spring Roo. Részletek itt.

19:14 Google + VMWare együttműködés... Részletek itt.

19:07 Hopp, feltűnt a Prezi.com is a Google Wave partnerek között!

19:05 Most a Google Wave vezetője beszél. Az a nagy híre, hogy ma megnyitják az egészet. Szóval nem kell meghívó. Sokat javítottak rajta, úgyhogy azt mondja, hogy érdemes újra kipróbálni. + Wave Data API (Eh, lássuk be, a Wave-ből jelen formájában nem lesz semmi.)

Olvasom tovább »
Címkék: google dev konferenciák élő i/o
2010.05.19. 18:01. írta: hírbehozó

A Facebook a mobilszolgáltatókkal karöltve beárazná a webet

Első olvasatra még szimpatikus is lehet az a törekvés, hogy a Facebook 40 országban állapodott meg mobilszolgáltatókkal arról, hogy ingyen biztosítja az alsóbb kategóriás készülékkel rendelkező mobilfelhasználók számára a Facebook elérését.

Magyarországon a T-Mobile-lal állt össze a Facebook. A magyaroknak - már ha t-sek - tehát nincs más dolga, mint a mobiljuk böngészőjébe bepötyögni a 0.facebook.com címet, és ingyen, forgalmi díj kiszámlázása nélkül nézegethetik, hogy mi történik facebookos ismerőseikkel.

A hivatalos magyarázat szerint a Facebook és a partner mobilszolgáltatók csupán  jószolgálati szerepet vállalnak azzal, hogy az alsóbb kategóriás készüléket használó, általában mobilnet-előfizetéssel nem rendelkező fogyasztóknak is biztosítja a Facebookhoz való hozzáférést. Csakhogy.

Csakhogy ezzel a lépéssel nem történt más, mint a mobilszolgáltató a tartalomszolgáltatóval karöltve (esetünkben a Facebookkal) elkezdte beárazni a webet. Az lett itt fű alatt kimondva, hogy a netszolgáltató megmondhatja, hogy mennyibe kerül adott weboldalak elérése az ő hálózatán.

Mi lesz a következő lépés? A T-Mobile extra költséget fog felszámolni, ha a hálózatukon mondjuk a Telenor vagy a Vodafone weboldalait nézegetem? 


Nem a T-Mobile hálózatát használom, úgyhogy bekaphatom.

Lássuk be, csúnya arculcsapása ez a netsemlegesség elvének. A weben minden tartalomnak egyformán hozzáférhetőnek kell lennie. Nincsenek kedvezményezettek, és nincsenek hátrányos helyzetű tartalmak. Az internet alapfilozófiáját kérdőjelezi meg az, aki úgy gondolja, hogy az információhoz való hozzáférést majd ő jól beárazza. Lesznek a drágábban, lesznek az olcsóbban, és lesznek az ingyen megnézhető weboldalak? Na nem!

Ez a törekvés pont annyira alantas és cinikus, mint amikor egyes ISP-k a videóforgalmat vagy a torrentezést próbálják meg korlátozni, arra hivatkozva, hogy nekik az túl nagy adatforgalmat jelent. Az ISP soha és semmilyen körülmények között ne mondja meg, hogy melyek a kívánatos és melyek a szerinte nem kívánatos tartalmak, tartalomtípusok. Nincs joga saját üzleti érdekei szerint árcédulát tenni a webszájtokra, szolgáltatásokra. Nincs joga különbséget tenni bit és bit, információ és információ között. Adatforgalom-arányosan árazzon. És ne aszerint, hogy az az adatcsomag milyen típusú tartalom.

Az internet éppen annak az eszmének köszönhetően jött létre, mely a lehető legdemokratikusabb információhozzáférést szorgalmazza. Ebből soha, semmilyen körülmények között nem szabad engedni. És minden ellentétes törekvést vissza kell verni.

A net nem a Facebooké. És nem a mobilszolgáltatóké. Hanem a miénk.

Without net neutrality, the Internet would start to look like cable TV. A handful of massive companies would control access and distribution of content, deciding what you get to see and how much it costs. Major industries such as health care, finance, retailing and gambling would face huge tariffs for fast, secure Internet use ... Most of the great innovators in the history of the Internet started out in their garages with great ideas and little capital. This is no accident. Network neutrality protections minimized control by the network owners, maximized competition and invited outsiders in to innovate. Net neutrality guaranteed a free and competitive market for Internet content. (Lawrence Lessig & Robert W. McChesney: No Tolls on The Internet)

Címkék: ingyen magyar net neutrality facebook t mobile isp
2010.05.19. 11:18. írta: hírbehozó

"Nagy lépés, ha egy cég rájön arra, hogy problémái vannak" - A Scrum módszerről (2. rész)

Folytatjuk a beszélgetést Bodó Árpád Zsolttal, a Sprint Consulting alapítójával. Az interjú első részében a Scrum szoftverfejlesztési modell működéséről és sajátosságairól esett szó. (Akik nem annyira jártasak a témában, mindenképpen olvassák el az interjú első részét.) Most pedig az agilis módszer gyakorlati megvalósulásával, a gyakori hibákkal, a magyar cégek sajátosságaival, a startupok agilitásával és a gyorsreagálású csapatokkal folytatjuk...

Olvasom tovább »
Címkék: dev interjú szoftverfejlesztés projektmenedzsment scrum produktvitás agilis
2010.05.18. 12:48. írta: hírbehozó

Teszteld, hogy mennyire biztonságosak a Facebook-beállításaid!

Vannak ezek a szájtok, amik kereshetővé teszik a facebookos státuszfrissítéseket. Amik persze amúgy is kereshetők. Bárki eléri őket. Mint az iménti link alatt is látható, sokan nem is sejtik, hogy amiket megosztanak magukról, azok az információk mások számára is elérhetőek.

Ezért a zavarodottságért sokat tesz maga a Facebook is, azzal, hogy nagyon bonyolulttá és körülményessé tették a privacy beállításokat. Persze azzal védekeznek, hogy ők csupán szofisztikálttá, részletesebbé tették a rendszert. De valójában csak elbonyolították azt, mégpedig úgy hogy a felhasználók dönt többségének eszébe se jusson bajlódni ezzel az egésszel. (Hogy miért van így, arról majd máskor írunk.)

Nos, a legegyszerűbb módszer, ha leteszteljük, hogy mennyire biztonságosak a személyes beállításaink. Nekem 6-ból 1 esetben volt nem biztonságos a beállításom. A teszt szerint saját ismerőseim véletlenül megoszthatnak másokkal velem kapcsolatos információkat. Ezt a beállítást itt szerkeszthetjük.

Hozzátenném, hogy engem például nem zavar, ha ismerőseim megosztják az általam Facebookon publikált linkeket. És általában is elmondható az az örök privacy szabály: ne viselkedj úgy a neten, hogy megbánd, ha fény derül rá. Legalábbis közösségi szájtok esetében ez mindenképpen jó tanács. Ettől függetlenül azért nem árt, ha valódi baráti kapcsolataink megmaradnak a privacy burok alatt.

Mert nem csak online közösségi lét, de online magánélet is létezik a világon.

Akit a fent említett Privacy Scannernél is részletesebben érdekel a saját biztonsági szintje, kattintson ide.

Persze csak egy dolog odafigyelni személyes beállításainkra. Ugyanilyen fontos arra is ügyelni, hogy hova klikkelünk...

A fenti videóban említett védelem a Defensio. Érdemes ezt is kipróbálni, márcsak azért is, mert nincs az a tudatos netező, aki ne kattintana legalább egyszer-egyszer gyanús linkekre. Régen az operációs rendszert, majd a böngészőt védtük a támadások ellen. Ma pedig ugyanilyen fontos a közösségi tereink védelme.

Címkék: spam biztonság privacy vírus facebook
2010.05.17. 22:30. írta: hírbehozó

"Megértik és átélik a munkájukat" - a Scrum módszerről (1. rész)

Egyáltalán nem triviális és nem is egyszerű hatékonyan vinni egy projektet, megszervezni a munkát, menedzselni a feladatokat. A szoftverfejlesztés sokszor rapid döntéshozatalt és rugalmas projektszemléletet kíván meg. Az elmúlt években egyre kiforrottabbá váltak az úgynevezett agilis szoftverfejlesztési modellek. Az egyik legnépszerűbb a Scrum. A módszerről az egyik hivatalosan is elismert tanácsadócég, a Sprint Consulting alapítójával, Bodó Árpád Zsolttal beszélgettem jó háromnegyed órát. A beszélgetés első részének leiratát olvashatjátok...

Hogyan mondanád el egyszerű magyarul, hogy miről szól a Scrum?

Egy projekt általában egy ötlettel kezdődik. Először elkezdik címszerűen összeírni, hogy mit is kell tartalmaznia a terméknek ahhoz, hogy az ötlet megvalósuljon. Ezt a terméket leíró listát nevezzük product backlog listának. Majd ha az ötletek összegyűltek, elkezdik kidolgozni a mögöttes tartalmat is - kicsit hasonlóan a követelmény-specifikációkhoz. A szép az egészben az, hogy ahhoz, hogy elindítsuk a projektet, a teljes kép ugyan meg kell, hogy legyen, de a teljes lista (minden részletében kidolgozva) nem kell, hogy rendelkezésre álljon. Ennek az az előnye, hogy egyrészt hamarabb elkezdhetünk fejleszteni, másrészt úgyis meg fognak változni a projekt során a követelmények, és akkor legalább nem kell majd átírogatni a teljes dokumentumot. Hanem... Ami nagyon fontos, hogy ez a lista egy jól meghatározott sorrendbe rendezett lista kell, hogy legyen. A sorrendet pedig a Business Value-nak nevezett paraméter határozza meg, ami azt jelenti, hogy azok a magasabb prioritású elemek, amik a legtöbbet jelentik a termék számára, és ezekkel kezdünk el foglalkozni először. Létrehozzuk a termék vázát és utána feltöltjük a legértékesebb fícsörökkel, minek eredményeként lehet, hogy már el is tudjuk kezdeni értékesíteni a terméket, miközben folyhat tovább a fejlesztési munka.

Nos, tehát aki képviseli és tulajdonolja ezt a listát, őt hívjuk Product Ownernek. Ő mondja el a teljes képet a fejlesztőcsapatnak egy kick-off meeting keretében, hogy mindenkinek a fejében meglegyen, hogy miről szól ez a termék. Ez nagyon fontos. Ezt követően elkezdődnek az iterációk, amiket a Scrumban sprinteknek nevezünk. A product owner és a fejlesztőcsapat összeül, és ennek a listának egy, a tetején lévő részhalmazát, amiről a product owner úgy gondolja, hogy belefér egy sprintbe, odaadja a teamnek, azzal, hogy "Na fiúk, ezt szeretném, ha megcsinálnátok az első iterációban. Vagy legalábbis a lista tetejéből annyit, amennyit tudtok." Nagyon részletesen elmagyarázza nekik ezeket az elemeket, a fejlesztők pedig addig kérdeznek, amíg világos nem lesz számukra minden részletében a feladat. Majd a fejlesztői csapat valamilyen módszer szerint (idő, komplexitás) megbecsli a feladatokat. Ezután a product ownerrel közlik, hogy most ennyi fér bele a "kívánságlistából". Megegyeznek, kezet ráznak. És innentől nevezik ezt a listát sprint backlog listának. Ebben a pillanatban a sprint backlog lista befagy. Kőbe van vésve. Nem lehet sem hozzáadni, sem elvenni belőle úgynevezett storykat, vagyis listaelemeket. Csak és kizárólag közös megegyezéssel (PO és team), de az már kivételkezelést igényel.

A lista elemeit taskokra bontják, amelyek már a teljesség igényével készülnek. Egy story akkor lesz kész, amikor a hozzá tartozó összes task készen van. Az ideális sprint 30 naptári nap. A sprint végén a fejlesztők leszállítják a fícsöröket. Nagyon fontos, hogy a sprint backlog listában nem rétegeket felépítő dobozok vannak, hanem függőleges szoftver funkciók. Azaz ezekben benne van a UI, a backend munka, az adatbázis munka, és minden, ami csak szükséges a fícsör működéséhez. Így a sprint végére a fícsörökhöz többé már nem kell hozzányúlni, és így ragasztjuk a termékhez minden sprintnél az újabb fícsöröket.

Mi lesz az eredmény? Egy káposzta. Nem eredményez egy szép szoftverarchitektúrát, de megvan az ellenszer: a refaktorálás. Míg hagyományos módszereknél nem is biztos, hogy ismerik vagy alkalmazzák, a Scrum esetében szükséges dolog a refactoring. Oké. Azzal azonban nem ér véget a dolog, hogy a team lefejlesztette a bevállalt fícsöröket. Nekik is kell eladniuk azokat a product ownernek. Demózzák:  ezt kérted, és mi így valósítottuk meg. Egyenként végigmennek a lefejlesztett fícsörökön, és a product owner értékel. Majd a végén elfogadja vagy nem fogadja el a leszállított fejlesztéseket.

Szintén fontos elem, hogy minden nap van egy úgynevezett daily scrum, vagy daily standup nevű szeánsz, amikor a team maga (pont az önszervezésből adódóan) megbeszéli, hogy mit csináltak az előző standup óta, mit tervezek csinálni a következő standupig, és van-e valami akadályozó tényező, amire azonnal ugrik is a Scrum Master (SM), akinek feladata, hogy elhárítsa ezeket az akadályokat.

Mi a probléma a waterfall modellel, azokkal a projektvezetési, projektmenedzsmenti modellekkel, amikor linárisan történnek a dolgok egy fejlesztés esetén? Tehát van egy tervezési, fejlesztési, tesztelési szakasz, majd kitelepítik a szoftvert és marad az üzemeltetés a végére... Mi a probléma a hagyományos projektmenedzsmenttel?

A hagyományos projektmenedzsmenttel az a probléma, hogy az 50-es években alakult ki, majd a szoftveripar megjelenésével nem teljesen követte azt Az iparosodás környékén gyárakat, meg üzemeket építettek, akkor találták ki azt a Gantt chartot, amit azóta is használunk például az MS Projectben. Az épülettervezéshez ez volt az ideális, de közben megjelent a szoftveripar és jobb híján ehhez nyúltak, és mai napig használjuk a waterfall modellt, valamint az ezen alapuló módszertanokat. Így hát számos hátránya van a szoftverfejlesztésben, az építkezéshez képest.

Mik ezek?

Mutatok egy ábrát... A waterfall azzal kezdődik, hogy az elején megnézzük, melyek a követelmények, ügyfélnek összefoglaljuk, hogy így értette-e, majd ezek alapján megtervezzük a szoftverterméket és lekódoljuk. Ha kell összeintegráljuk, teszteljük majd installáljuk és átadjuk.

Üzleti oldal és fejlesztő oldal közti kommunikáció hiánya: Az egyik fontos különbség a hagyományos és az agilis módszertan között, hogy a hagyományos módszernél az ügyféllel mindössze két alkalommal találkozunk igazán: a projekt elején és a végén. Egy hosszabb terjedelmű, féléves, másfél éves projekt közben nem találkozunk az ügyféllel, hiszen ő sem igényli, meg mi sem. Jóllehet, mindkét oldalnak szüksége lenne rá, ennek nincsenek tudatában. A végén, amikor átadjuk a terméket, az ügyfél dob egy hátast, hogy ő nem ezt akarta. Akkor jön a vita, a claim-menedzsment, hogy ki hibázott. Elővesszük a követelményspecifikációt és látszik belőle, hogy hát ez van ideírva, csak azt ő máshogy értette, mint mi. Igazából teljesen mindegy, hogy ki értette félre, az biztos, hogy a végén valaki ezért fizetni fog. Vagy mi vállaljuk ezt be, és olyanná alakítjuk a szoftvert, amilyenné ő valójában szerette volna, vagy pedig rajta verjük le, hogy ő írta le, és ezért fog ő fizetni. Ügyfél nem lesz elégedett, további költségek jelentkeznek, és valaki ezt megfizeti.

A másik dolog, hogy az átadáskor nem ér véget rögtön a fejlesztés, nem tudjuk valójában átadni, hisz tovább kell fejleszteni, hogy olyanná alakítsuk, amilyenné az ügyfél valójában szerette volna. Tehát a plusz költségek mellett határidőcsúszással és bevétel kieséssel is számolhatunk.

A harmadik, hogy mivel ez a hagyományos modell fázisokból áll (követelményelemzés, tervezés, kódolás, integráció, tesztelés stb), ha bármelyik egy picit is megcsúszik, az összes utána következőt tolja maga előtt. Ismét határidőcsúszás az eredmény.

Szintén nagy különbség magában a projektcsapat összeállításában van. Egy szoftver rétegekből épül fel: UI, backend, adatbázisréteg, stb. A hagyományos módszertan szerint általában úgy alakítják a fejlesztői csoportokat, hogy a különböző teamek különböző rétegeket fejlesztenek. Ezek jól meghatározott interfészek mentén vannak elvágva.

Agilis szoftverfejlesztésnél ez nem így működik. Itt cross-functional csapatok vannak, "függőleges fejleszésű" fícsöröket, azaz nyomogatható, kész, használható fícsöröket szállítanak a fejlesztőcsapatok... 

Ezeket a problémákat az agilis módszertanok, vagy konkrétan a Scrum hogyan oldja fel, milyen előnyöket nyújtanak?

Nézzük a lehetséges problémákat: Ha követelmény változik, akkor mindig vissza kell térni az elejére, kvázi antigravitációs logika szerint újra engedélyeztetni kell a módosításokat, újra bele kell nyúlni a tervekbe. Ha tehát az ügyfél a projekt elindulása után rájön, hogy változtatnia kell a követelményeken, és ha ez a tervezés ideje alatt történik, akkor szól nekünk, és mi beletesszük a módosításokat. Ha viszont kódolási időszak alatt történik mindez, akkor csak úgy tudjuk beépíteni ezt a változtatást, ha visszanyúlunk a tervezéshez. Integrációkor, vagy teszteléskor, általában már le is szokták hülyézni az ügyfelet, hogy mégis mit gondol, hogy képzeli? Egy tanulmány szerint, ha a projekt elején egy követelmény 1 forintba kerül, akkor annak beépítése a projekt 75%-ánál, már 100 forintos költséget jelent. Tehát minden ilyen változtatás plusz költséget generál, de nagyságrendileg is nagyobb kiadás, mintha az elején derült volna ki.

A hagyományos szoftverfejlesztési módszertan nem tudja kezelni a változtatást: rugalmatlan. Hogy változtatásra miért van szükség? Fejlesztők körében van egy elterjedt axióma, hogy a ügyfél hülye. Valójában az ügyfél azért nem tudja, hogy mit akar, mert abban a pillanatban nem tudhatja, hogy mi várható a piacon, nem tudhatja, hogy hogyan lehetne ebből a legjobb terméket létrehozni. Hiszen nincs a kezében a termék. És csak akkor tudná ezt igazán megmondani, ha már nyomogathatná, használhatná, a terméket, és mondhatná, pl. hogy jobb lenne, ha ez a fícsör másképp nézne ki, ez a gomb kerüljön a másik oldalra, satöbbi. A piac változik, jogszabályok változnak, sokszor ezért is kell neki követelményt változtatnia. Tehát nem mindig az ügyfél felületessége miatt jelentkeznek ezek a problémák.

Ehhez képest az agilis módszertan mit feltételez?

Az ügyféllel nem az elején és a végén találkozunk, hanem az elején, majd pedig minden egyes iteráció, sprint során. Tehát sok lehetősége van arra, hogy beleszóljon és változtasson. Az előbb említett esetben, hogy ha valami nem úgy alakul, ahogy az ügyfél szerette volna, valaki fizetni fog. Scrumnál - mivel időről-időre találkozunk az ügyféllel - időben előjönnek a módosítási igények. Mivel menet közben látja, hogy alakul a termék, egyszerűen és költséghatékonyabban tud változtatni. Ha meg változtat, akkor egyből látni is fogja, hogy ez mivel jár, mennyibe kerül. Tehát kétszer is meg fogja gondolni, hogy mennyit változtat.

Tehát a Scrum fő előnye a kommunikációs részében van, hogy sokkal intenzívebb a kommunikáció a szereplők között?

Inkább a fő eszközének nevezném a kommunikációt. A fő előnyei közül, ha nem konkrét részleteket nézünk, akkor azt emelném ki, hogy abból a pénzből, amit az ügyfél az adott projektre elkölt, a lehető legtöbbet hozzuk ki, a legtöbbet kapja. Ez neki is előny, és nekünk is, hiszen a reputációnk megítélésekor nem lesz mindegy, hogy az ügyfél elégedett vagy sem.  Másik előnye, hogy kockázatot csökkent. Az agilis módszertanok a waterfallhoz képest csípőből kilőnek számos kockázatot. Saját cég esetében ezt éri meg alkalmaznom, mert produktivitást növel és az emberek jobban érdekeltek abban, hogy jól működjön a cég. Ennek feltétele és eszköze a kommunikáció. Kommunikáció ezerrel mind cégen belül, mind ügyféllel. A siker feltétele az is, hogy az ügyfél is agilisan gondolkozzon és megélje azt, hogy tartjuk a kapcsolatot és együttműködünk. Máshogy nem fog működni.

A szerepkörök hogyan változnak meg?

Változnak, mert a hagyományos projekteknél vannak projektmenedzserek, vannak fejlesztők, akik elvégzik a munkát, van az ügyfél, akit valaki képvisel és van business analyst-szerű valaki, aki segít abban, hogy leírja a követelményeket. A teamet meg lebonthatjuk architektúrával, UI-jal, dizájnnal, fejlesztéssel, adatbázissal foglalkozó egyénekre. A Scrumban ezekre a munkákra ugyanúgy szükség van, csak másképp történik a szervezés. Projektmenedzsert a Scrum sem mindig tud nélkülözni, viszont ez a szerepkör 3 részre oszlik. A legnagyobb szerep a product owneré, aki az ügyfelet képviseli. A második maga a scrum team, a fejlesztőcsapat, és a harmadik a scrum master. A scrum mastereknek - akik legtöbbször projektmenedzserekből lesznek - van a legkisebb hatalmuk a projektszervezésben, azonban vétójuk van a módszertan alakulásában...

Történetileg azt látjuk, hogy a menedzseri rétegnek a 20. század eleje óta nagyon fontos szerepe van egy vállalat működtetésében és a projektszervezésben is. Mindenki azon szocializálódik, hogy a menedzser az, aki összeszedi helyettünk, hogy mit mikor kell csinálni, hogyan kell dolgozni. Ezzel szemben azt mondod, hogy nagyon sokat ebből a felelősségből vissza lehet delegálni a csapatnak. Ez a filozófiai váltás a lényeg?

Igen, ez a filozófiai váltás lényege és eszköze az agilis módszertanoknak. Abból ered, hogy a munkát azok tudják legjobban megszervezni, akik ténylegesen elvégzik, ők tudják legjobban maguk közt felosztani. Ami nem jelenti azt, hogy többé nincs szükség menedzserekre. Például most a 120 fős projektemben van 9 Scrum-team, de attól még kell projektmenedzser, mert össze kell fogni az egészet. Ez a váltás nem működik egyik napról a másikra.

Hagyományos felállásban a projektmenedzserek attól félnek, hogy a fejlesztők nem képesek megszervezni maguk a munkájukat. Van egy bizalomhiány a dolgozó emberek felé a megrendelő vagy vezetői oldalról is. Elvárják, hogy legyen ott egy ember, egy menedzser, aki tud határidőt tartani, irányítani stb.

Igen, így van. A Scrum és az agilis módszertanok akkor fognak működni, ha a csapat tényleg képes lesz önszerveződni. Ken Schwaber, a Scrum atyja, azt mondja, hogy mindenki legyen expert. Tudjuk, hogy nem teljesen így van, hiszen ha egy cégben mindenki szuper expert, akkor az a cég anyagilag bedőlne. Egy bizonyos fokú tapasztalati szintre azonban tényleg szükség van ahhoz, hogy a team meg tudja szervezni a saját munkáját. A másik feltétel, hogy lelkes motivált emberek alkossák a csapatot. 

Ha őszintén ránézünk a világ egy tetszőleges cégére, akkor ott nem csak motivált, boldog, a munkájához legjobban értő embereket fogunk találni. Az élet sokszor úgy hozza, hogy az emberek nem mindig érzik úgy, hogy a legtökéletesebb pozícióban dolgoznak. Egy kicsit túl ideális állapotot feltételez a Scrum...

Talán úgy tűnik, hogy túl ideálisat felételez, de ez nem így van. A motiváltságnak öngerjesztő folyamatként kell működnie. Azáltal, hogy hagyjuk, hogy a csapat tagjai maguk oldják meg a saját munkájukat, szabadságot kapnak. Illetve tényleg rájuk van bízva a sprint végén a fícsörök leszállítása, tehát egyben felelősséget is kapnak. Megértik és átélik a munkájukat. Olyan, mint a biciklizés, meg az úszás: nem elég tudni a szabályokat, át kell tudni érezni. Egy Scrum tréningen két nap alatt agymosás folyik. Megértik a folyamatot, megtanulják a módszertant, hisznek benne, de ettől még nem fog egyből 300-400%-on pörögni a termelékenység. Csak ha a team ráérez az egészre.

Amint viszont ez megtörténik, akkor élvezni fogják a munkát. Elismerik őket és egyre motiváltabbak lesznek. Csak egy jó Scrum bevezetés kérdése az egész.  Egy sztori erre: Moszkvában szegezték nekem ugyanezt a kérdést,  hogy gondolom én azt, hogy reggel az emberek majd maguktól felveszik a munkát és el is végzik azt? "Ha nincs ott egy projektmenedzser, aki korbáccsal a kezében kiosztja, majd behajtja rajtuk, akkor az emberek maguktól nem fognak semmit dolgozni."  Hát, ha így állunk hozzá, akkor valóban nem fog működni a Scrum.

Tovább az interjú második részéhez...

Címkék: dev interjú projektmenedzsment scrum agilis szoftverfejlesztés produktvitás
2010.05.17. 15:45. írta: hírbehozó

Jézusom, fizetős lesz a Facebook???

Elképesztő népszerűségnek örvendenek azok a facebookos csoportok, melyek tagjainak az a célja, hogy demonstráljanak a Facebook fizetőssé tétele ellen. Hogy mi?? Fizetős lesz a Facebook???

Hát minden valószínűség szerint. Máskülönben minek csatlakozott volna több mint 22 ezer magyar a "NEM, NEM FOGOK HAVI 1190 FT-OT FIZETNI A FACEBOOKÉRT 2010. AUGUSZTUS 27-TŐL" nevű csoporthoz? 

Honnan veszik magyar polgártársaink, hogy fizetős lesz a Facebook? A legviccesebb az egészben, hogy a csoport oldalán egyetlen forrás szerepel, és ez pedig a Snopes legendavadász oldala, ahol egy hatalmas "FALSE" minősítés áll a híresztelés mellett. Vagyis kacsának minősíti a híresztelést. (Amúgy hivatkoznak is a Facebook egyik vezetőjének áprilisi nyilatkozatára, mely szerint a Facebook továbbra sem tervezi a fizetős tagság bevezetését.) Mint ahogy az Urbanlegends.hu is.

Ebből már sejthető, hogy a magyar facebookos csoport létrehozója csak bolondozik a hiszékenyekkel. Tegyük hozzá, elég nagy sikerrel.

Nem ismerős nekünk valahonnan ez az egész? Dehogynem!

Az iWiW berobbanásának időszakában lett országos hisztéria abból, hogy fizetős lesz a szolgáltatás használata. Hiába írta meg minden hírszájt, hogy kacsa az egész, a városi legenda évekig tartotta magát. Sőt, mikor az iWiW Klubok esetében lehetett prémium tagságot is venni, sokan beigazolódva látták korábbi megérzésüket: "ugye én megmondtam, hogy fizetős lesz az iWiW!!!".

Láthatjuk tehát, hogy a közműként funkcionáló ingyenes webes szolgáltatások esetében mindig jól működik az ilyen városi legendák terjesztése. Biztos vagyok benne, hogy ugyanilyen sikeres tudna lenni egy olyan hoax is, mely azt vetítené előre, hogy napi 10 keresés felett fizetni kell majd a Google keresőjének használatáért.

Amúgy - teszem hozzá - egyáltalán nem lenne ördögtől való, ha a Facebook is bevezetne prémium tagságot. Ugyan miért ne kaphatna több funkciót, személyreszabhatóságot, vagy például extra tárhelyet a képeinek az, aki hajlandó fizetni ezért? 

A Flickr vagy a Vimeo is bevezette a prémium tagságot. Aki nagyobb tárhelyet, gyorsabb fájlfeltöltést szeretne, az havi díjat fizet. Mi ezzel a baj? Semmi. Sőt! Nagyon is helyes és támogatandó modell.

Akik most attól rettegnek, hogy mi lesz velük, ha a Facebook fizetős lesz, valószínűleg nem rettegnek annyira, amikor virtuális ajándékokért, virtuális játékokért rendszeresen fizetnek a Facebookon. Elképesztő bevételei vannak a népszerű facebookos játékok fejlesztőinek. Az emberek önként és dalolva fizetnek 32x32 pixeles ikonokért. Milliószámra! Ugyanők viszont rettegnek attól, ha fizetős lenne a Facebook? Eh.

De hát éppen ők fizetnek az (ingyenes) Facebookért - azzal, hogy virtuális baszokat vásárolnak éjjel-nappal!

Minden épeszű ember számára világos, hogy egy 400 milliós felhasználótáborral rendelkező szolgáltatás alaphasználatát soha nem fogják fizetőssé tenni. Ennél sokkal kisebb, és pénzügyileg ingatagabb szájtok sem teszik meg ezt. Nem hülyék. Viszont a prémium tagság bevezetésén minden sikeres ingyenes webes szolgáltatásnak el kell gondolkodnia.

Címkék: hoax facebook fizetős
2010.05.12. 12:28. írta: hírbehozó

Webdizájnerek tanácsai dizájnoló fejlesztőknek (2. rész)

Múltkor Keve, most pedig Hipra, az Inda-szolgáltatások jelenlegi dizájnere ad pár tippet azoknak a fejlesztőknek, akik munkájuk során dizájnerkedéssel is kell, hogy foglalkozzanak...

Bruce Ediger: The only "intuitive" interface is the nipple. After that it's all learned.

UI-tervezésben azt hiszem a fenti idézet a legfontosabb. Minden felhasználói felületet tanulni kell, ezért intuitivitásról csak előzetes ismeretek birtokában beszélhetünk. Manapság rengeteg UI-t használunk, a mikrohullámú sütőtől kezdve az autók kezelőfelületéig, ezért rengeteg prekoncepciónk van a használati tárgyaink működésével kapcsolatban.

Ugyanilyen előzetes információkkal rendelkezik az is, aki okostelefon appokat használ. Ismerjük és alkalmazzuk az ott jól bevált UI megoldásokat adott problémára, óvatosan bánjunk az új megoldásokkal.

Verzióváltásnál sokszorosan igaz, hogy a jól bevált felhasználói felületet ne módosítsuk radikálisan, apró lépésekben vezessük be az újításokat.

Az ikonhasználatról: rengeteg helyről ingyen le lehet tölteni nagyon szépen kidolgozott ikonokat, ezek nekünk az esetek nagy többségében haszontalanok. A legjobb, ha egyszerű, lényegretörő pixelre igazított vektorgrafikus szimbólumokat használunk. Általános trend, hogy programon belül belül ritkán használunk színes-szagos ikonokat, sokkal célravezetőbb, ha egyszerű, jól felismerhető szimbólumokkal dolgozunk. Itt is igaz hogy a jól bevált, a felhasználók által megszokott ikonokat használjuk (home, like, bookmark, hozzáadás, törlés…), ne akarjuk misztifikálni vagy viccessé az egyes funkciók ikonját. A felhasználóink nem fogják érteni a viccet.

Olvasnivalók:
http://penguinpetes.com/b2evo/index.php?p=482&more=1&c=1&tb=1&pb=1
http://www.uxmag.com/
http://www.lukew.com/ff/entry.asp?156
http://www.deyalexander.com.au/resources/uxd/

Címkék: dev ui geek dizájn usability to how webdizájn gui
2010.05.12. 10:31. írta: hírbehozó

Google, lokalizálj!

Itt a Google Maps új androidos verziója. Az Android Marketben fel is ajánlja letöltésre, csakhát ugye európaiként én nem láthatom az új funkciókat. Pedig van itt egy csomó, engem is érdeklő újítás: bicajos útvonaltervezés, shortcutok, gyors megosztás-funkció. Egyelőre csak az amerikai városokra működnek az új fícsörök, viszont ha az eddigi lokalizációs gyakorlatot vesszük alapul, nem valószínű, hogy mi, európaiak (pláne magyarok) hamar hozzájuthatunk ezekhez az újdonságokhoz.

Sajnos a magyar Maps webes verziójában sem jelent még meg a bicajos fícsör. Pedig Amerikában már március óta elérhető az is. Úgyhogy minimális az esélye annak, hogy a közeljövőben a mobilos verzión is láthatjuk Magyarország bicikliútjait.

Nem mintha nagy kunszt lenne az amúgy szabadon hozzáférhető magyarországi bringautakat, -sávokat és egyéb ajánlott útvonalakat felpakolni a Maps-be...

Csak tudnám, hogy akkor mit csinál annyi ember a zürichi Googleplexben, vagy a londoni (mobilfejlesztésekért felelős) Google irodában.

Láthatósági mellény nélküli másodrendű állampolgárok vagyunk az információs szupersztráda leállósávjában. 

Címkék: mobil google maps lokalizáció android biking
2010.05.11. 21:23. írta: hírbehozó

Három sikerszolgáltatás, ami nem kell a magyaroknak

A látogatottsági és elérési adatokból kiválóan látszik, hogy a magyar internetező nem szokott rá minden olyan közösségi szájtra, melyek amúgy tarolnak a világ különböző piacain. Mi az adekvát válasz, ha online fotómegosztás a téma? A Flickr. És egy zenekar honlapjának hol van a legjobb helye? A MySpace-en. Egy termék bevezetésére, marketingre mi a legjobb kommunikációs csatorna? A Twitter. Lehetne éppen így is, csakhogy idehaza a netezők zöme egyáltalán nem használja ezeket a szolgáltatásokat.

Még mindig a februári Gemius-adatsor a legfrissebb, amihez hozzáférünk. De a tendenciák így is egyértelműek lesznek. Kezdjük mindjárt a fotómegosztással.

Mint látható, a két fotómegosztó elérése 10 százalék alatti. Vagyis csak minden tizedik magyar internetező talál rá ezekre a szolgáltatásokra. A Picasa elérése sajnos nem szerepel az adatsorban, de valószínűleg a Google fotómegosztó szolgáltatásának sincs sokkal nagyobb elérése, mint a két riválisnak.

Vajon az következik ebből, hogy a magyarok nem szeretnek képeket megosztani a weben? Dehogy. Csak éppen erre a célra már régen az iWiW-et vagy a Facebookot használják. Mindkét közösségépítő szájtnak a képmegosztás az egyik legnépszerűbb funkciója. És mint látszik, a fotómegosztó szolgáltatások nem tudtak változtatni ezen a netezői szokáson.

Második példánk a MySpace volt, melyről idehaza is azt szokták mondani, hogy a zenekedvelők, rajongók kedvenc közösségi oldala. Csakugyan? Nézzük!

A grafikonról leolvasható, hogy a MySpace idehaza szintén az 5-10 százalékos sávban található. Vagyis 100-ből átlagban 5-10-en találnak el a szájtra. Akkor hol hallgatnak zenét a magyarok? Hát persze, hogy a YouTube-on! Mégha azt nem is állítanám, hogy a YouTube-ot csak és kizárólag zenehallgatásra használnánk, ám az biztos, hogy ez a legnépszerűbb tartalomtípus.

Rendben. De mi újság a Twitterrel? Hisz a Twittert már a nagyobb hírszájtok is szokták használni élő tudósításaikhoz. És amúgy is, folyton azt halljuk, hogy Amerikában a Google és a Facebook sikeréhez mérhető a "mikroblogolás".

A fenti grafikon szerint a microblogging szolgáltatások is éppen a magyar internetezők 10 százalékát érik el.

Érdekesek ezek az adatok, főleg annak fényében, hogy a mobilgyártók idehaza is előszeretettel teszik készülékeikbe a MySpace, a Flickr vagy a Twitter alkalmazását. Legalábbis múltkor találtunk erre példát.

El tudom képzelni, hogy vannak olyan kampányok idehaza, melyek pont ezt a twitterező, flickrező, myspace-ező 10 százalékot akarják elérni. De nagyon úgy tűnik, hogy ezek az amúgy globálisan sikeres szolgáltatások nem nagyon tudnak jelentősebb mennyiségű magyar netezőt elcsábítani.

Persze vannak azért szép számmal amerikai szolgáltatások, melyek nálunk is extrém népszerűek: a Google keresője, a Facebook vagy a már említett YouTube a magyarok körében is éppen annyira sikeres, mint a tengerentúlon.

Címkék: stat flickr magyar myspace twitter indafotó mommo
2010.05.11. 17:49. írta: hírbehozó

A videó, amit Steve Jobsnak nem fognak megmutatni

via s_teli

Az Android 2.2 nemsokára megérkezik Nexus One-ra, és remélhetőleg nem sokkal utána Dezirére is. Huzzah.

Címkék: mobil flash videó android froyo android 2.2
2010.05.11. 10:28. írta: hírbehozó

A Foursquare az év meglepetése

Azt hiszem, eldöntöttnek vehetjük a korábban felvetett dilemmát arról, hogy vajon melyik lesz a nyerő helyzetmegosztó szolgáltatás... Vagy mégsem? 

Nos, a két hónappal ezelőtti helyzethez képest annyit már kijelenthetünk, hogy a három szolgáltató (Brightkite, Gowalla, Foursquare) közül a Foursquare kerekedett felül. Egyszerűen olyan ütemben növekednek, hogy a másik két riválisnak már nem nagyon van esélye megszorongatni őket.

Hát igen, minden startup-tulajdonos álma ez a kék görbe. A Foursquare-nél tehát épp örülhetnének is, hiszen egyetlen hónap alatt megduplázódott a felhasználói bejelentkezések száma. 40 millió becsekkolás... Ráadásul ennek fele az előző hónapban jött össze. Ebből talán érezhető, hogy mekkora a növekedés üteme...

A képet némiképp árnyalhatja, hogy a Facebook éppen ezen a területen kezdett el mocorogni, és hamarosan ők is jelentkezni fognak valamiféle helyzetalapú szolgáltatással.

A Google viszont feltűnően csöndben van. Ami azért is érdekes, mert ők kezdték el ezt az egészet, a Google Latitude másfél évvel ezelőtti elindításával.

Ezekből a tényekből és híresztelésekből mindjárt több dologra is következtethetünk. Az egyik, hogy a Google akviráláson töri a fejét. És vagy a Foursquare-t vagy a Gowallát akarja megkaparintani, hogy elejét vegye a Facebook még erőteljesebb térnyerésének.

Ezt az eshetőséget kicsit gyengíti, hogy a Foursquare alapítója az a Dennis Crowley, aki korábban már eladott egy Twitter-szerű szolgáltatást (a Dodgeball-t) a Google-nak. A Google viszont egyszerűen kinyírta ezt a karámon belülre édesgetett jószágot. Ez pedig nyilvánvalóan fájdalmas emlék Crowley-nak.

Anno így nyilatkozott az egész Google-sztoriról: 

The whole experience was incredibly frustrating for us - especially as we couldn't convince them that dodgeball was worth engineering resources, leaving us to watch as other startups got to innovate in the mobile + social space.

Az akvizíciós szándék persze a Facebookról is feltételezhető ebben a körben. Bár azt is hozzá kell tenni, hogy a Facebook eddig nem nagyon volt aktív ilyen téren. Plusz, mint fentebb is jeleztem, a hírek szerint a Facebook inkább maga fejleszti le saját helyzetmegosztó szolgáltatását. Úgyhogy ők nem valószínű tettestársak.

A Foursquare másik két nagy szereplőnek, a Microsoftnak és a Twitternek is jól jönne. A Microsoft ugye egyre jobban összefonódik a Facebookkal, és kicsi az esélye annak, hogy a Facebook kárára kezdenének felvásárolni webes szolgáltatásokat.

Maradna tehát a Twitter.

A Twitter társalapítója, Ev Williams amúgy hasonló élettapasztalaton ment át, mint Crowley. Ev először a Blogger.com blogszolgáltatást adta el a Google-nak. Majd gyorsan ott is hagyta a Googleplexet és újabb startupokba kezdett. A Twitter megalapításakor már eszében nem volt könnyen adnia magát a Google-nak.

Elképzelhető az is, hogy Crowley ugyanezen az úton járva - az akvizíciós közeledések ellenére - újabb és újabb kockázati befektetésekből kívánja sikerre vinni a Foursquare-t, és megkerülhetetlen szereplővé szeretne válni, még mielőtt valamelyik cápa fölé úszna. S ebben az esetben - mint ahogy az a Twitterrel is történt - már ő diktálhatja a nagyokkal folyó tárgyalásokat.

Akárhogyan is lesz, az már látszik, hogy az év egyik legnagyobb sikersztorija a Foursquare. És ezt sem gondoltuk volna, mondjuk egy évvel ezelőtt. Márcsak azért sem, mert akkor még ezek a szolgáltatások nem is léteztek.

Címkék: google stat üzlet facebook twitter foursquare gowalla helyzetmegosztó brightkite
2010.05.10. 15:57. írta: hírbehozó

Webdizájnerek tanácsai dizájnoló fejlesztőknek (1. rész)

A múltkori post kommentjeiben felmerült, hogy jó lenne összeszedni pár olyan alapvető dolgot, tippet, tanácsot, ami segítheti a dizájnolásra kényszerülő fejlesztő munkáját. Megkerestem pár webdizájnert, hogy adjanak tanácsot azoknak, akik bár nem webdizájnerként dolgoznak, de az élet hozhatja úgy, hogy mégiscsak hozzá kell nyúlniuk a felhasználói felületekhez, vagy magához a dizájnhoz.

Elsőként Keve, az Inda szolgáltatások korábbi arculattervezője és vezető dizájnere, a The Cook (Csajok és Pasik) társalapítója írta össze tanácsait: 

 
Tervezd meg alaposan!
Az UI tervezés fontosságát nem kell hangsúlyozni. Rajzolj sokat, nézz meg különböző megoldásokat, próbáld minél jobban a felhasználó bőrébe képzelni magad. Nagyon sok jó anyag van wireframe témában (hasznos eszköz, javaslat, esettanulmány) a neten http://wireframes.tumblr.com/  Sok fejlesztő esik abba a hibába, hogy túl sok funkciót, featurát akar beleszuszakolni a felületbe, ettől zavaros lesz. Törekedj egyszerűségre!
 
Tanulj másoktól!
Kész megoldásokból is van galéria, inspirációnak érdemes végigkattintgatni: http://dzineblog.com/2010/03/best-user-interface-design-resources-the-round-up.html
Ha elakadsz egy felületnél, nézd meg mások hogyan oldották meg, sok ötletet adhat.

Ne ess át a ló túlsó oldalára!
Egy alkalmazást nem kell túlrajzolni. Nem kell sok szín, csillivili ikonrengeteg, hatféle font és még sorolhatnánk, az önuralom remek dolog.
 
Színek
Tudom, hogy nehéz elhinni, de a színek tényleg fontosak. A neten sok szinpaletta van, ha egymáshoz passzoló színeket szeretnél www.kuler.com, de más oldalak színeiből is kiindulhatsz. A megfelelő színek alkalmazása későbbiekben a márkakommunikációban is fontos hangsúlyt kaphat, fordíts rá elegendő figyelmet.
 
Ikonok
Az ikonokra is igaz, hogy a kevesebb több. Ha sok ikont kell használni, válassz vmi egyszerű, sematikus fajtát. Ha csak pár kell, akkor lehet részletesebb, de én például kifejeztten nem szeretem ha egy alkalmazásban csudarészletes ikonok vannak. Óvakodjunk, hogy mi magunk ikonokat rajzoljunk, az "egyedi" ikonok sokat ronthatnank az összhatáson.
 
Méretek, ergonómia
Az olvashatóság nagyon fontos, a kis betűkkel lehet ugyan helyet spórolni, de ha kényelmetlen olvasni, akkor nem szívesen használják az emberek. Az aprócska form elemek, a hangyabetűk, eltalálhatatlan linkek engem mindig felbosszantanak. Ha érintőképernyőre tervezel, akkor pedig az emberi ujj méretét nem tudod átugrani, legyen akkora minden(gombok, csúszkák, menük), hogy kényelmes legyen használni, inkább nagyobb, mint kicsi.
 
Igényesség
Amit csinálsz azt csináld jól. Rosszul kivágott képek, pixeles ikonok, homályos betűk leronthatják ismét csak a felhasználói élményt. Az igénytelen kinézet sok embert elriaszthat.
 
Logó
Egy jó logót megcsinálni komplex munka, szakértelmet kíván. Próbálj meg minél egyszerűbb megoldást választani, vmi tipóra kihegyezve, de ha komoly szándékaid vannak, akkor egy minőségi logóra hamar szükség lesz.

 

Címkék: dev ui geek dizájn usability how to webdizájn gui
2010.05.10. 11:01. írta: hírbehozó

Magyar mobilba magyar appokat (is)?

Ma a metróban futottam össze a Samsung egyik hirdetésével. A cég új telefonját, a Montét reklámozza. A pontos reklámszövegre már nem emlékszem, de a lényeg, hogy a gyártó szerint a telefon fő erőssége, hogy segítségével nagyon kényelmes és egyszerű használni a közösségi szájtokat. A magyar reklámon két ajánlott márka, a Twitter és a Facebook szerepel.

Nem csak logókkal, de konkrétan a reklámszövegben is megjelenik a "twitterezés" és a "facebookozás", mint olyan tevékenységek, amiktől vonzónak kellene, hogy legyen egy ilyen telefon. Miért nincsenek magyar közösségi szolgáltatások az ajánlatban? - merült fel bennem a kérdés. Vagy lehet, hogy nincs is mit ajánlgatni? Tisztelet a kivételnek.

Amúgy a Facebook ajánlgatásával semmi baj nincsen, hiszen az egymillió magyar felhasználó már épp elég vonzó egy telefonvásárló magyar számára is. A Twitter nekem kicsit furább választás, hiszen idehaza finoman szólva sincs a legnépszerűbb szolgáltatások között. Pár tízezeres felhasználóbázissal nem egy kirívóan sikeres cucc. De mondjuk ez is belefér.

Tehát mi lehet az oka annak, hogy - az amerikaiak mellett - nincsenek magyar közösségi szájtok promózva ezekben a magyaroknak szánt hirdetésekben? (Korábban valamelyik Nokia-plakáton láttam a Facebook integrációt, mint mindent vivő fícsört. Magyar szolgáltatások ott sem szerepeltek a felsorolásban.)

Elsőre talán azt gondolnánk, hogy nincsenek is érdemleges magyar szájtok. De ha rápillantunk a látogatottsági statisztikákra, azért egy Startlap, egy iWiW, egy Blog.hu, egy Vatera, stb épp beleférhetne abba a kínálatba. Hogy sok kisebb, feltörekvő magyar szolgáltatást ne is említsek.

Az ok talán az - merengtem a hirdetéssel szemezve, míg a metrószerelvény épp átgurult a Duna alatt -, hogy a magyar szolgáltatásoknak nincsen mobilalkalmazás-verziója. (Főleg nincs a Samsung speciális mobil operációs rendszerén futó appjuk. De ez egy speciális történet.)

Oké. Ez tényleg probléma. Valójában érthetetlen is, hogy a magyar online piac nagy játékosai miért nem házalnak a mobilszolgáltatóknák, mobilgyártóknál azért, hogy az ő alkalmazásuk legyen preinstallálva a készülékeken. Lehet, hogy még nem érzik, hogy mennyire fontos lenne ezt meglépni? Nem tudom a választ. Lehet, hogy jobb is.

Aztán azt is megfigyeltem a hirdetésen, hogy a telefon kijelzőjén angolul jelenik meg a Facebook app. Sőt, a honlapon a Twitter helyett a MySpace a másik ajánlott szolgáltatás. Ami, ha lehet, még kesévé érdekes szolgáltatás idehaza. Akkor már a YouTube sokkal inkább...

Itt már világossá vált számomra, hogy valószínűleg a helyzet még egyszerűbb. A mobilgyártó amerikai központjában kimondták a verdiktet, hogy márpedig a Facebook és a Twitter MySpace az amerikai piacon globálisan mindent vivő alkalmazás, és nem merült fel, hogy helyi piacokon esetleg ennél árnyaltabb lehet a helyzet. Azzal együtt sem, hogy közhelynek számít, hogy a magyarok - ideértve a fiatalokat is - milyen rosszul állnak idegennyelv-tudás tekintetében...

Akárhogy is van, a magyar cégek és a magyar telefonforgalmazók közös érdeke lenne, hogy minél több, idehaza népszerű szolgáltatás tudjon megjelenni ezeken az okostelefonokon, és így azok hirdetéseiben is. Semmi baj nincs a globálisan sikeres szolgáltatások nyomatásával. De ha egyszer a fogyasztó igényeinek a kielégítése a cél, akkor nem ártana figyelembe venni, hogy a magyar embernek picit (ha nem is teljesen) mások a fogyasztási szokásai, mint mondjuk egy New Jersey-i vagy tokiói kamaszé.

Címkék: mobil hirdetés magyar samsung piac
2010.05.06. 18:18. írta: hírbehozó