GhoUl

Ennek az írásnak az ötlete már jó ideje motoszkál bennem. Mindig is érdekelt a programozás – magas szinten. Azaz érdekelt, hogyan lehet nagy rendszereket tervezni, érdekelt, hogy ezek a rendszerek hogyan használhatóak az egyszerű felhasználó szemében. Érdekelt, hogyan lehet megcsinálni, de valahogy sosem csináltam meg. Egyszer ki kéne próbálni, de erre a közeljövőben ismételten nem lesz időm.

Ez persze nem akadályozott meg abban, hogy utánaolvasgassak a témának. Illetve azon oldalak ajánlásait kövessem, akikre már amúgy is feliratkoztam. Így találtam rá az Ars Technica cikksorozatára, ami a fejlesztési eszközöket, nyelveket, APIkat veszi górcső alá. Korábban már volt szerencsém az Ars Technicahoz, ők képesek voltak korábban például a Leopardot tizenegynéhány oldalban elemezni, elvárásokkal, hiányokkal és hasonló dolgokkal. Szerintem tanulságos volt, ezért érdemesnek láttam a cikksorozatba is belekóstolni.

Az írás alapvető példája, mint mondtam, az volt, hogy összevesse a lehetőségeket. Előrebocsátom, hogy az ő írásuk is (az enyém meg pláne) az Apple megoldását preferálja a Microsoftéval szemben, ezért aki ebből flamet csinálna, az inkább most hagyja abba. Annak semmi értelme sincs (mondom ezt én ).

Na, ideje belevágni a témába. A vonatkozott cikksorozat engem leginkább egy vonatkozásban fogott meg: a második részben feszegette azt, hogy a Microsoft APIk mennyire nem kifinomultak – valószínűleg ez lehet az oka, hogy szerte a cégen belül is a “kerék újra feltalálása” a divat. Ezt talán a mellékelt kép is szemlélteti (a kép eredeti változata a http://arstechnica.com/articles/culture/microsoft-learn-from-apple-II.media/vista.png címen érhető el).

A helyzet rossz. Nagyon. A képen szereplő ablakok a Visual Studio 2005 kivételével az aktuálisan elérhető legfrissebb változatok. Érdemes megfigyelni, hogy vannak alkalmazások menüvel és menü nélkül (utóbbi esetben szalaggal vagy rejtett menüvel). További érdekesség, hogy az Office család szereplő tagjainál alapvető eltérések vannak szerkezetben (szalag nézet a Wordben, hagyományos nézet a Visioban, és az Outlook mindig is egyedi volt). Másik érdekesség az előre-hátra nyilak az Intézőben, az Internet Exporerben és a Windows Media Playerben. Pontosabban a mellette levő lefele nyíl, ami a listát jelenítené meg: minő véletlen, ebből is van háromféle változat.

Biztos, hogy van még különbség, de ezek felderítését az unatkozó olvasókra bízom.

Azzal semmi bajom sincs, hogy a Vistában a felület máshogy néz ki, mint korábban. Lehet vitatkozni rajta, hogy jobb lett vagy rosszabb, mint a korábbi, én nem teszem meg, mert csak képernyőképeken láttam a rendszert. De ez így katasztrófa. Az Ars Technica sorozatában még mondott egy érdekes példát: a Vista kezdeti változatában azért voltak gondok a hangkártyadriverekkel, mert a Microsoft a fejlesztés végső szakaszában módosította a hangrendszert. Az ok: leültek multimédiában érintett emberekkel, és azok jelezték, hogy a lejátszóprogramok feleslegesen terhelik a gépet, ha pollozzák a hangbuffer állapotát, jobb lenne, ha az értesítené őket, hogy fogyóban az adat. Felmerül a kérdés: ez miért nem került a cég multimédiás programjának, a Windows Media Player fejlesztésekor? Például mert nem használja a saját APIt?

Ezzel szemben OSX-en az Apple szinte minden programja (nem állítom, hogy minden, mert azért az sem lenne igaz) egy közös megjelenítési APIt használ, és ez az API elérhető a fejlesztők számára is. Ezen felül elérhető még [[http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/|Apple Human Interface Guidelines]] című dokumentum is, ami egyfajta szakácskönyvet ad a fejlesztők kezébe, hogy az Apple milyen elvek szerint építi fel a programjait (többé-kevésbé). Eredmény: ha jön egy programozó, aki OSXre szeretne szoftvert írni, megnézi ezt a dokumentációt, és ez alapján tervezi meg a felhasználói felületet, és a beépített APIt felhasználva valósítja meg. Következmény: a 3rd party programok is hasonlóak lesznek a beépítettekhez. Ez a Microsoftos káosznál elérhetetlen állapot…

Persze a dolog messze nem ilyen egyértelmű: a http://www.neopoleon.com/home/blogs/neo/archive/2008/03/17/29941.aspx oldalon például a szerző azt részletezi, hogy miért nem szereti az OSX APIjait. Ez érthető is. Ahogy az Ars Technicas cikk harmadik részében szerepel, az Apple által erőltetett Objective-C nyelv alapvetően különbözik a megszokott objektum-orientált nyelvektől, csak OSX-en lehet használni, az XCode nevű program semmi különöset nem nyújt egy Visual Studiohoz képest, sőt, az extrák tekintetében le is van maradva. Szintén ebben a cikkben szerepel, hogy OSX-en meg hiányolja a .NET bizonyos részeit vagy éppen az Office 2007-et. Más szóval a helyzet messze nem egyértelmű, érdemes a továbbiakban is figyelni a témát, milyen változások lesznek.

Frissítés: Az Ars Technica cikksorozatára való hivatkozásokat pótolom.

• [[http://arstechnica.com/articles/culture/what-microsoft-could-learn-from-apple.ars|Áttekintés, történelem]]
• [[http://arstechnica.com/articles/culture/microsoft-learn-from-apple-II.ars|A Microsoft megoldásainak összegzése]]
• [[http://arstechnica.com/articles/culture/microsoft-learn-from-apple-III.ars|Az Apple APIk ismertetése]]

A hétvégén volt szerencsém pár érdekes kompatibilitási problémával Microsofttal kapcsolatban. Pontosabban van, amiről olvastam, van, amit találtam. Az egyik az Internet Explorer sikeres, szabványos tesztjeivel foglalkozik. Korábbi írásomban már írtam arról, hogy az Internet Explorer 8 már képes átmenni az ACID2 teszten. Azóta annyi változott, hogy a kompatibilis módhoz mégsem kell módosítani az oldalakat. Hurrá.

Na, mindegy, amiről beszélni akartam, hogy megjelent az ACID3 teszt is (abból kiindulva, hogy most már minden böngésző átmegy a korábbin, legalább a fejlesztői változatok). Az új teszt szép, csili-vili, a Webkit motor közel van hozzá, hogy átmenjen (90% felett van, utolsó információm 92%, de azóta nőhetett), Firefox béta 70%-on (na, ez meg valószínűleg nem fog sokat nőni a 3-as verzió kiadásáig, mert állítólag architekturális változások szükségesek), Opera hasonló eredménnyel zár.

Ami nem meglepő, hogy az IE lenn van: az IE 7-es verziója kemény 12%-ot ér el. Ami viszont meglepőbb, hogy az 5.5-ös ezt felülmúlja: 14%. Hát igen, az IE is fejlődik (mielőtt valaki nekem támadna, a 8-as verzió majdnem 50%-ot javítva 17%-on tart…). A részletes eredmények elérhetőek a http://www.anomalousanomaly.com/2008/03/06/acid-3/ címen. Természetesen nem hivatalos link, de amit ellenőrizni tudtam, az egyezik. A szerző állítása szerint megpróbálja követni az eredményeket.

A másik érdekes kompatibilitási dolog, amivel szembesültem, az a csodálatos Powerpoint 2007 formátumai. Egyik szakirányos tárgyunkon csapatmunkában kell házi feladatot beadni, aminek része volt, hogy egy prezentációt kell előállítani. Srác gépén Office 2007 van (az enyémen meg nincs MS Office, de állítólag a Keynote kompatibilis).

Na, haver kiválaszt egy mintát, összerak egy kezdeti változatot, átküldi. ppt-ben, nem az új formátumban. Megnézem, jónak tűnik. Elkezdem szerkeszteni. Eljutok odáig, hogy az egyik címsor szövegét módosítanám. Duplaklikk, feltűnik, hogy a kurzor nem változott szövegkijelölőre, még egy dupla klikk, aztán rájövök, hogy ez nem fog menni. Az eszement Powerpoint 2007 képként exportálta a címsort.

Erre őszintén egyetlen értelmes magyarázatot tudok elképzelni: valami elvont betűtípust használ (értsd: olyan betűtípust, amit először az Office 2007 telepít, korábban teljesen ismeretlen volt). De biztosan ez a megoldás efféle problémák kezelésére? A megszokott megoldás, hogy a betűtípusra hivatkozunk, és ha a célhelyen nincs meg, nyomunk valami figyelmeztetést, esetleg helyettesítjük, miért nem jó? Az ok, hogy pdf-stílusban nem lehet beágyazni a fontot a fájlba, ha ezt a ppt-specifikáció nem támogatja. De a másikat miért nem lehet csinálni. Esetleg miért nem lehet figyelmeztetni, hogy hé, öcsisajt, ezt nem tudom exportálni.

Mindenesetre az egyetlen értelmes konklúzió: egy újabb MS Office termék, aminek a kompatibilitási adataiban nem lehet bízni (vagy még inkább csak egyszerűen MS termék). De ez a képként exportáljuk a címsort még a visszamenő kompatibilitást is ellövi (2003-as vagy korábbi verziókkal). Bár lassan azt hiszem, hogy már ezt is megszoktuk. De ez van. Vannak dolgok, amiben a Microsoft soha nem volt túl erős. Igaz, neki nem is kell törődnie másokkal, bőven elég, ha az van, amit ő akar. Hisz a többség azt csinálja, amit ő akar, a kisebbség meg igazán alkalmazkodhat.

A weben már a Microsoft felismerte, hogy egyre többen használják a nyílt szabványon alapuló böngészőket (Magyarországon a Firefox részesedése 40% körüli), ami szükségessé teszi az interoperabilitást. Amit meglehetősen nehéz lesz elérni. Vajon eljön az a Kánaán, amikor ez meglesz a levelezőszerverek, levelezőkliensek, irodai programcsomagok, netán az operációs rendszerek (desktopok, vagy egyebek, ízlés szerint helyettesítendő a megfelelő fogalommal) világában? Reméljük.

Annak idején foglalkoztam egy-két bejegyzés erejéig az Internet Explorer 7-es verziójával ([[IE 7 a láthatáron]] és [[IE7 - avagy sok hűhó semmiért]]), és az volt a véleményem, hogy igen, jó, hogy foglalkoznak vele, hogy könnyebb legyen, de nem léptek eleget. Az előző designnál például háromféle css-t kellett kiszolgálnom: egyet az ie6 és korábbi változatainak, egyet az ie7-nek és egyet a böngészőknek (értsd: minden másnak, Firefox, Opera, Konqueror, Safari, sőt még a Lynx számára is tökéletes volt a kimenet).

Úgy néz ki, hogy a következő IE-ben ez teljesen másképp lesz.

Hiszen nagy hangsúlyt fektetnek a szabványkövetésre, hiszen ha beraksz egy meta taget, átmegy az Acid2-n (mintha az olyan sokat számítana). Tény, most még a Firefox stabil változata sem megy át, de sajnos ez nem sokat számít. Mindennek ellenére a Firefox gyakorlatilag ugyanannyira szabványkövető, mint a Safari, az Opera vagy a Konqueror. Van, amit az egyik tud, van, amit a másik. Kár összevetni. Elkészült azóta az Acid3 teszt is, ez olyan szempontból jó mérő, hogy ezen még senki sem megy át. Közel sem. A normális böngészők 60% körül teljesítenek.

Persze ez sem sokat jelent. A felhasználók számára az számít, hogy mit csináltak a honlapkészítők (nem akartam a webdesigner, esetleg webdizájner kifejezéseket használni), illetve az hogy jelenik meg kedvenc böngészőjükben (miután a felhasználók nézőpontját próbálom követni, szokásomtól eltérően az IE-t is idesorolom). A honlapkészítők számára meg az számít, hogy mit rakhatnak egy oldalra, mert működik, illetve mit nem. Ez is elég egyértelmű.

De térjünk vissza az eredeti témára. Ez a meta tages megoldás érdekes. Ha a szabványok oldaláról nézem, akkor a “Hogy is van ez?” kérdés az, ami először felmerül. Ez azt jelenti, hogy az úgy változat alapból nem kompatibilis, de kompatibilissé tehető? Ennek mi értelme van? Legyen kompatibilis és kész.

Persze ha kicsit józanabbul szemlélem a dolgokat, és megpróbálom beleélni magam a fejlesztők helyébe, valamilyen szinten a döntés jogos is, hiszen ki tudja, hány helyen, akár nem is nyilvánosan, hanem a belső, hálózati intraneten vannak olyan oldalak, ami a szabványokról semmit sem hallottak. És ezekről is gondoskodni kellene. Ugyanakkor ezzel a logikával fennáll a veszély, hogy a végén egy böngésző belsejében kénytelenek kismillió böngészőmotort integrálni.

Ez utóbbi az asztali gépeken nem probléma (most már noteszgépeken sem), de mondjuk a PDA-kon, mobiltelefonokon ez nem egy használható megoldás. Legalábbis szerintem. Hiszen a sok motor sok memóriát eszik, amikor betöltődik, meg hasonló problémák lehetnek. Persze nehéz jobb megoldást javasolni, de ez így nekem nem tetszik.

Hiszek benne, hogy inkább nagyobbat kellene lépni, vagy esetleg hagyni az egészet a fenébe, és ha a Microsoft saját böngészőt akar, akkor kövesse az Apple példáját, és vegye valamelyik hozzáférhető böngészőmotort, mint például a Geckot vagy a Webkitet. Bár lehet, hogy furcsán néznének rá utána. Ami egyébként ugyanolyan rossz, mint a Microsoft jelenlegi ügyködése a nyílt forrással kapcsolatban.

Mindenesetre a helyzet érdekes, a megoldás még nyitott, nekem nincs kedvem negyedik kinézetet is kiszolgálni az új Explorer számára, de ha tényleg úgy működik, ahogy remélik, és a 8-as verzió “szuperkompatibilis” módja már a többi böngészővel összevetve is normális lesz (értsd: csak egy-két dologban vannak különbségek, de van egy nagy-nagy közös metszet, amiből bárki gazdálkodhat), akkor részemről örülni fogok neki, és örömmel kiteszem azt a plusz taget a kódba. Oly sokat nem számít úgysem.

További olvasnivaló a témáról angolul az IEBlogon és A List Aparton, érdemes megnézni ezeket a vélemények miatt is. Én sok mindent tőlük szedtem. Tanulságos.
Frissítés: a Webkit böngésző fejlesztőinek véleménye is linkelve.

• Internet Explorer 8 and Acid2: A Milestone, IEBlog
• Compatibility and IE8, IEBlog
• From Switches to Targets: A Standardista’s Journey, A List Apart
• Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8, A List Apart
• Versioning, Compatibility, Standards, Surfin’ Safari Blog

Egy érdekes podcast-ra bukkantam a neten, annyira elborult, hogy érdemes megosztani a nagyérdeművel. A címe is magáért beszél: Microsoft Mambo No. 5.

A videót érdemes megtekinteni…