"Bijkomend voordeel is dat je nog 'mooiere' interfaces kunt maken, alles is vector gebaseerd en stijlen met CSS is een makkie. Dus geen applicatie met 10 kleuren grijs."
Is dat écht een voordeel? In mijn ogen is dat namelijk nog maar de vraag. Ik zelf ben van mening dat dat een
groot nadeel is. Ik zal even trachten uit te leggen waarom ik dat zo zie:
Om even bij het begin te beginnen:
Een applicatie is eigenlijk, tot de basisvorm teruggebracht, niets meer dan een manier om te communicatie tussen de gebruiker en de computer te vergemakkelijken teneinde een of meerdere taken te volbrengen.
Wat deze taken zijn, maakt niet zoveel uit. Op welk besturingssysteem deze applicatie draait, maakt niet zoveel uit. De doelgroep van deze applicatie maakt maar marginaal wat uit. Wat wél uitmaakt, zijn de middelen die deze applicatie inzet (vensters, mogelijkheden) om deze communicatie zo soepel, duidelijk en overzichtelijk mogelijk te laten verlopen.
Er zijn ook verwachtingen, van beide kanten: De applicatie verwacht dat de gebruiker het programma opstart met een reden; de gebruiker wilt immers iets uitvoeren of ondernemen. Daarnaast verwacht de gebruiker dat de applicatie het hem/haar zo makkelijk mogelijk maakt om datgene te doen.
Om deze redenen zijn er enkele regels tot leven geroepen:
Human Interface Guidelines
Die van Apple
Die van Microsoft
Die van Microsoft voor Vista
Deze guidelines beschrijven, onderandere, hoe je applicatie er uit dient te zien op een bepaald platform. Om maar even een voorbeeld te noemen: welke widgets gebruik je wanneer, en vooral: wanneer niet? (met widgets bedoel ik in dit geval: knoppen, menu's, scrollbalken, toolbars, etc.) Hoe zien deze widgets eruit? Hoe functioneren ze ("voelen ze aan")? Op deze manier zien onderdelen er in verschillende programma's hetzelfde eruit en voelen ze ook hetzelfde aan.
Dit zorgt voor
vertrouwen; wanneer een gebruiker één applicatie kent, kent deze gebruiker binnen niet al te lange tijd ook een andere applicatie. Kent de gebruiker meerdere applicaties, dan is de gewenningsperiode helemaal kort: onderdelen zien er namelijk hetzelfde uit. De gebruiker weet hoe een knop eruit ziet, en dat als deze gebruiker in een nieuwe applicatie iets tegenkomt dat er
uitziet als een knop die ingedrukt kan worden, dan kan de gebruiker er van uitgaan dat het ook een knop
is dat ingedrukt kan worden. Dit geldt natuurlijk voor elke widget en voor venster en applicaties in het algemeen.
Dit is gelijk ook de reden waarom gebruikers vaak moeite hebben om "over te stappen" naar een ander besturingssysteem. Oppervlakkig zou dat namelijk helemaal geen problemen op moeten leveren, de meest bekende systemen werken immers gewoon met applicaties, vensters, knoppen en dergelijke! Soms zelfs een hele taakbalk (Zowel Windows, Linux, OS-X als BeOS en anderen hebben iets vergelijkbaars)! Waarom is het dan toch zo'n groot probleem?
Dat komt onder andere doordat alles er anders uitziet, en anders aanvoelt. Afgezien van keyboard shortcuts, andere manieren om de schijf te benaderen en dergelijke, is er een visuele drempel opgeworpen: Widgets zoals knoppen zien er niet uit zoals de gebruiker gewend is dat ze eruit zien, vensters reageren anders (al eens een OS-X venster proberen te maximaliseren terwijl je Windows gewend bent?), etcetera. Dit werpt vervolgens een drempel op, waar de gebruiker éérst overheen dient te komen alvorens alles weer enigzins soepel verloopt.
Nu is het één ding als de baas van een gebruiker dat eist (een Mac op het werk ipv PC), maar het is iets heel anders als een applicatie dat van een gebruiker eist, doordat de ontwikkelaars hun uiterlijk "mooier" vonden dan wat de gebruiker gewend is! Bijna elke applicatie is
niet uniek, zodoende moet je je onderscheiden, maar dan wel in positieve zin! Op het moment dat je als applicatie een drempel als deze neerlegt voor de gebruiker, is de kans groter dat ze naar een alternatief op zoek gaan. Je bent hun taak namelijk
moeilijker aan het maken dan dat het zou hoeven zijn! En het gaat uiteindelijk toch om de gebruikers, anders staat je applicatie maar stof te vergaren in een virtuele lade...
Door de mogelijkheden van
Flash + ActionScript,
HTML + JavaScript lijkt het al snel aantrekkelijk om een "mooi" uiterlijk voor deze widgets te maken. Men lijkt het niet erg te vinden, op websites wordt het immers toch ook geaccepteerd? Wat veel webdesigners helaas niet realiseren is dit: Een webpagina is een
document, géén applicatie, hoe veel je ook met zo'n "applicatie" kunt. Enige widgets nabootsen is in een document aardig geaccepteerd, websites zien er vaker "leuk" uit, en om tabs of knoppen in deze stijl door te trekken is vaak nog niet zo'n heel probleem, mits het er niet teveel zijn. Maar het blijft allemaal
plaatjes en tekst, ook al zit er dan enige interactiviteit in.
EXT JS Online Desktop: deze library appt misschien wel widgets na, maar het is en blijft een document, en dat merk je. Om van de snelheid maar niet te spreken, het blijft DOM manipulatie hé...
Ik ben er volledig van overtuigd dat binnen niet al te lange tijd, grote applicaties gedeployed kunnen worden voor zowel de desktop op verschillende besturingssystemen, als voor op het internet, en ook nog eens tegelijkertijd. Maar voordat de eindgebruiker zoiets écht zal accepteren, dienen deze applicaties ook eruit te zien en aan te voelen als applicaties!
Als je dan persé je interface wilt skinnen, maak dat dan optioneel (zoals Firefox doet: de gebruiker dient eerst zelf verantwoordelijkheid hiervoor op zich te nemen betreffende de bereidheid om de widgets te herleiden naar hun oorspronkelijke vorm teneinde met een nieuwe interface te kunnen werken) en (nog belangrijker!) zorg ervoor dat je interface er op elk systeem
native uitziet en aanvoelt. Dit betekent dat op Windows [zonder skin] de onderdelen er grijs uit horen te zien, op Windows [met skin] de onderdelen er uit horen te zien zoals de skin dit aangeeft, op OS-X de vensters zich horen te gedragen zoals in OS-X, in Linux de onderdelen de iconen van gtk gebruikt etcetera.
Met de meeste huidige mogelijkeden is dit
niet mogelijk (althans, niet terwijl je een applicatie tegelijk wilt deployen op meerdere systemen of via het internet wilt laten draaien). Dit kun je al zien door enkele online Flash en DHTML "applicaties" te openen. Je kunt het zelfs ook locally al uitproberen, door enkele van de volgende programma's te openen: Winamp, Songbird, iTunes, Live Messenger en Quicktime. Hou ze eens naast elkaar, doe er wat mee en het zal je direct opvallen: Elk programma vind zichzelf de "mooiste", probeert zoveel mogelijk "op te vallen" tussen de andere applicaties en al met al is het net alsof je gevangen zit in een kaleidoscope van kleuren en vormen waar je de rest van je leven zult moeten slijten...
Je startte de programma's om iets te doen, weet je nog? Nee, dat ben je vergeten.
Het is een probleem als de omgeving waar een applicatie in ontwikkeld wordt niet strict genoeg is; dit speelt slecht Interface Design in de hand. Microsoft's Visual Basic gaf bijvoorbeeld de mogelijkheid om knoppen een achtergrondkleurtje te geven. Resultaat? Programma's met groene, rode, blauwe, gele, oranje, paarse, rood-wit-gestreepte etc. knoppen. Omgevingen die je een mogelijkheid gaf om je applicatie te "skinnen" maakte het nog een stapje erger: je kon bijvoorbeeld aan de window chrome zitten, en in plaats van een "X" knop een grote, roze, dansense hippo gebruiken rechts bovenin het scherm. Het resultaat was natuurlijk dat gebruikers strontziek werden van die geintjes, en software opzochten dat zich wél gewoon aan de standaarden hield en wél serieus overkwam. Maar ook dat soort applicaties laten wel eens steekjes vallen:
Autodesk 3D Studio Max wel eens geopend? Je krijgt een gigantische lijst eigenschappen, modifiers, knopjes (die gek genoeg icoontjes hebben die allemaal op elkaar lijken) voor je neus waar je maar wijs uit dient te worden.
Screenshot
Office 2003 is flink verbeterd in versie 2007, maar dat is maar goed ook: er zaten dingen in die er nooit in hadden mogen zitten. Zwevende toolbars is al een zonde: veel gebruikers weigerden deze af te sluiten na gebruik, uit vrees dat ze de toolbars "kwijt" zouden raken. En zelfs de menubalk is van een venster af te scheuren, om vervolgens ergens achter een stapel documenten "kwijt" te raken zodat gebruikers hun document niet meer kunnen opslaan zonder CTRL+S.
Screenshot menu aan de linkerkant
Office 2007 blog
Mozilla Firefox is opzich een prachtig product: het doet wat het moet doen. Maar wel eens gekeken naar extensions die een toolbar produceren? Installeer er een paar en het resultaat is een interface waar niemand over nagedacht heeft. Elke toolbar "denkt" dat "hij" het "mooist" is, en het meest op zou moeten vallen. Een gigantische chaos dus.
Screenshot
Er zijn nog veel duidelijkere voorbeelden te bedenken, zie
The Interface Hall of Shame.
Het probleem dat
Adobe Air plaagt, net als alternatieven zoals bijvoorbeeld
Javascript UI Libaries of een bekende:
Java is dat ze geen "link" hebben met het native OS wat uiterlijk en gedrag betreft. Dat ze geen écht native elementen gebruiken is niet zo'n probleem, zolang ze alles maar zo veel mogelijk native eruit laten zien en aan laten voelen. Maar dat doen ze niet. Het resultaat is, wanneer je een applicatie in deze omgevingen maakt, een eindgebruiker die eerst over die drempel heen moet komen alvorens je programma te gebruiken. En waarom zouden ze dan nog? Het maakt ze geen drol uit of je applicatie geschreven is met behulp van Adobe Air, Microsoft .NET, C++ of welke taal/omgeving dan ook. Als je applicatie raar doet, zoeken ze een alternatief dat
niet raar doet.
Het is niet voor niets dat
Java applicaties door de meeste mensen niet echt gewaardeerd worden...
Er is nog een alternatief voor
Adobe Air dat ik (vreemd genoeg, maar dat zal wel aan de crappy marketing department van Mozilla liggen) nog niet naar voren heb zien komen in de reacties op dit nieuwsbericht:
Mozilla XULRunner. Al sinds voordat Netscape de codebase vrijgaf, gebruikt Mozilla een XML-variant voor de interface-elementen (widgets dus), genaamd XUL en XBL. Deze worden gestijld met behulpt van CSS, en het daadwerkelijke programmeren doe je in JavaScript. Op het moment dat je wat krachtigers nodig hebt kun je aan de gang met andere talen zoals C++ en het importeren als een XPCOM component.
De elementen worden misschien wel gestyled via CSS, maar ze zien er wel "native" uit én voelen "native" aan. Met Windows Classic is alles grijs en 3D en heb je een skin dan pakt het gewoon de elementen van je skin! Draai je de applicatie op OS-X, dan ziet het er ook uit als OS-X (zie voor een voorproefje Firefox 3 met de -Proto? Protus? iets dergelijks- skin) en gebruik je Linux dan ziet het eruit als een volwaardig KDE applicatie met bijbehorende icons.
Verdere dingen zijn ook niet zo'n probleem, custom widgets maak je door je eigen XBL bindings te maken, je hebt storage door middel van XML, JSON of SQL-Lite en met XPCOM componenten kun je heel wat leuke dingen doen.
Je hebt dus daadwerkelijk het beste van twee werelden, de simpliciteit en vrijheid van de "web-kant", en de kracht van de "programmeer-kant". Je programma kan je vervolgens door middel van XULRunner deployen op Windows, Linux, OS-X en zelfs via Internet (al moet er dan wel een Gecko browser gebruikt worden). Er zijn veel mogelijkheden ingebouwd, zo ook de Extension Manager, waarmee je add-ons en themes kunt ontwikkelen (zonder de eindgebruiker met een vreemde interface op te zadelen waar ze niet vanaf komen).
En dat scheelt; misschien hou jij wel niet van "20 tinten grijs", maar je eindgebruiker misschien wel. En willen ze een skin, dan kunnen ze die simpelweg downloaden, en het enige wat jij hiervoor hoeft te doen is de Extension Manager aan te zetten en rekening te houden met overlays en skins. Het is voor jou makkelijk, het is cross-platform én het is voor de eindgebruiker practisch niet te ontdekken of je applicatie nou "native" is of niet. En dit zorgt er voor dat ze zich concenteren op wat ze willen
doen. En mits jij je applicatie overzichtelijk hebt opgebouwd, kunnen ze daar ook goed mee uit de voeten ook.
Meer informatie over XUL:
MDC Joy of XUL
MDC XULRunner
MDC XUL Reference
XULPlanet Tutorial
Wat voorbeelden van applicaties die gebruik maken van dit platform:
Mozilla Firefox
Mozilla Thunderbird
Songbird Media Player
Er zijn natuurlijk, net als met
Adobe Air wel wat dingen die nog schorten aan
Mozilla XULRunner. Het debuggen is niet zo pijnloos als het zou moeten zijn (JavaScript Console, DOM Inspector, Venkman Debugger, Chrome List, XPCOM Viewer, dat zijn zo'n beetje de extensies waar je iets aan hebt), het is beginners niet makkelijk gemaakt door relatief weinig sample code, de marketing department lijkt XULRunner compleet onder de mat te schuiven en er is nog geen fatsoenlijke IDE beschikbaar voor XUL.
Dat laatste, daar ben ik al druk mee bezig.
Al met al is
Mozilla XULRunner nog geen platform zoals
Microsoft Visual Studio, maar dat is
Adobe Air ook niet. En er is één groot probleem waar zowel Adobe als Mozilla last van hebben: je dient meerdere talen te kennen. Op z'n minst toch XML(/XBL/XUL/HTML), (Java/Action)Script, CSS en nog wat extra's zoals C++ als dat even kan. Niet ideaal. Het kan dus nog wel enkele jaren duren voordat welke dan ook een volwaardig alternatief voor een "klassiek" platform is.
[Reactie gewijzigd door DiSiLLUSiON op 22 juli 2024 14:04]
Met Air kunnen ontwikkelaars internetapplicaties bouwen met behulp van html, css, Ajax, Adobe Flash en de nieuwe versie van de opensourcetool Flex, die gelijktijdig met Air is uitgebracht. Deze applicaties kunnen offline gebruikt worden, gegevens op de harde schijf benaderen en zijn niet afhankelijk van een browser. Ontwikkelaars kunnen hun huidige ontwikkeltools blijven gebruiken om Air-applicaties te ontwikkelen. Air en Flex voor Windows en de Mac zijn gratis te downloaden, terwijl een Linux-versie van Air later dit jaar wordt verwacht. Ook wil Adobe de Air-software beschikbaar maken voor handhelds en mobieltjes.
/i/1222682691.png?f=fpa)
:strip_exif()/i/1176719296.jpg?f=fpa)
/i/1212391441.png?f=fpa)
/i/1207214991.png?f=fpa)
:strip_exif()/i/1188984376.jpg?f=fpa)
/i/1180595555.png?f=fpa)
:strip_exif()/i/1174302710.gif?f=fpa)
:strip_icc():strip_exif()/u/134697/2nv2uSquare-flat.jpg?f=community){kind=small}
:strip_exif()/u/37197/crop5fa3e681ea163.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/81572/hair.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/90545/novaterrablaicon.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/5294/chillywilly_s.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/54057/icon.jpg?f=community){kind=icon}
:strip_exif()/u/198203/logospenk_2_60maal71.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/109719/Spell_Arcane_TeleportIronForge.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/45265/hekje3d.jpg?f=community){kind=small}
/u/90866/pinguin.png?f=community){kind=small}
/u/90124/RedRobot%2520-%2520Nieuw.png?f=community){kind=small}
:strip_icc():strip_exif()/u/112202/lighthouse.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/11824/crop5eb44c54f2bc5_cropped.jpeg?f=community){kind=small}
/u/14754/avatar_small.png?f=community){kind=avatar}
/u/151149/crop5fde11d32f663_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/175359/honda_icon.jpg?f=community){kind=icon}
:strip_exif()/u/13818/episodebutler_60x60.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/484/crop651fd77412597_cropped.jpg?f=community){kind=small}
