Design webapplicaties

[-FoX-]

Het designen van een website kan nauwelijks vergeleken worden met het designen van een webapplicatie. Logisch daar ze ook een verschillend gebruik in de hand werken. Zo dient er bij het design van een website rekening gehouden te worden met een vorm van 'marketing', zoekmachine optimalisatie, etc. Bij een webapplicatie daarentegen is het erg belangrijk dat de applicatie snel werkt, gebruiksvriendelijk en overzichtelijk is.

Over webdesign kan je erg veel vinden op het internet, daar deze toepassingen publiekelijk toegankelijk zijn. Webapplicaties draaien meestal op interne servers en zijn dan ook maar voor een beperkt publiek toegankelijk.

Als voorbeeld even de taxonomy van een webapplicatie:

• Header: De hoofding zal de applicatie identificeren, waarschijnlijk de naam bevatten en enkele globale acties ter beschikking stellen, zoals 'preferences', 'help', 'logout', ... • Navigate: Meestal horizontale navigatie met de top-level acties van de webapplicatie • Submenu: Contextgevoelige navigatie, afhankelijk in welke context de applicatie zich bevindt • Breadcrumbs: Niet altijd aanwezig, maar toont de hierarchy waarin de gebruiker zich bevindt • Lists: Lijsten die een bepaalde dataset tonen, bevatten ook meestal volgende karakteristieken: - Sortering: de list kan gesorteerd worden volgens kolom - Filter: die het toelaat om kolom data te filteren - Zebra: Even en oneven rijen worden getoond in een andere kleur - Paging: Grote lijsten worden over meerdere pagina's gesplitst - Fixed header: Middelgrote lijsten kunnen scrollbaar zijn • Forms: Laten het toe om data in te geven, volgende componenten vinden we hier terug: - Labels: identificeren een veld - Fields: input velden - Info block: extra text bij een veld dat wordt getoond bij de focus ervan (mini help) - Sections: kleine hoofdingen die een groep velden identificeert - Buttons: Acties die uitgevoerd kunnen worden als navigatie (Cancel, Back, ...) - Action buttons: Acties die een bepaalde state wijzigen; database acties (Save, Delete, ...) • Berichten: Als er zich een bepaalde actie voordoet, zal de gebruiker geïnformeerd worden: - Error: Als er een fout optreedt in de applicatie - Warning: Een waarschuwing naar de gebruiker toe - Info: Een bericht om de gebruiker te informeren • Footer: Bevat meestal copyright informatie, disclaimer, ...

Natuurlijk zijn er daarnaast ook nog een aantal componenten in terug te vinden, zoals

Tree: Hierarchische boomstructuur Tabs: Pagina met meerdere subpagina's die via een tabbed pane opgevraagd kunnen worden Datepicker: Kalendar die de dagen in een maand toont, embedded of via een popup Tooltip: Kan bereikt worden met een simpele acronym, maar rich text tooltips zijn toch custom made Sliders: Sliders kunnen gebruikt worden om specifieke data op een visuele manier voor te stellen Er zijn er vast nog veel meer, maar ik heb er hier enkele toegelicht om een idee te krijgen.

Naast dit alles, moet de webapplicatie een consistente en robuuste look-n-feel met zich meebrengen. Alles dient dan ook goed op elkaar afgestemt te zijn qua kleuren en uiterlijk.

Maar soms gaat het ook volledig mis, waardoor de applicatie zal falen. De gebruiker dient ook dan geïnformeerd te worden met een duidelijke foutboodschap. Denk maar aan de pagina die we hier te zien krijgen als er onderhoud gebeurd aan de servers, of de database op z'n gat gaat.

Waarom dit topic?
Om een discussie te starten rond het design van webapplicaties. Het design van deze webapplicaties heeft een andere aanpak nodig dan het design van traditionele websites, e-commerce, of dergelijke. Op het gebied van technieken, XHTML/CSS, staan we op hetzelfde vlak. Maar er moet wel op een andere manier ontworpen worden.

Als er iemand voorbeelden heeft van wel ontworpen webapplicaties mag je hier screenshots van posten om anderen een idee te geven op welke manier het hoort te zijn.

En als er genoeg animo is, kunnen we misschien wel eens bekijken om een contestje op te zetten.

[JHS]

Ik vraag me af of het per sé zo anders *moet* zijn als traditionele websites . Door de conventies van traditionele websites aan te hangen, kunnen dingen juist duidelijker zijn. Je ziet volgens mij ook dat dat vaak gebeurt. Aan de andere kant kan je je inderdaad afvragen of dat verstandig is, en je jezelf zo niet nogal limiteerd.

Je zegt dat je op het gebied van technieken op hetzelfde vlak staat. Maar je moet denk ik wel bedenken dat je minder gelimiteerd wordt door de noodzaak van bookmarks en unobtrusive javascript (afhankelijk van de doelgroep) en dergelijke. Aan de andere kant kan je je afvragen of je zo niet een deel van de voordelen van een webapp verloren laat gaan.

Met betrekking tot de taxonomy: Ik heb het idee dat dat vooral voorbeelden zijn van manieren om informatie weer te geven. Is het niet leuker / beter om te kijken naar wat de informatie is die je moet weergeven, en dan pas te bekijken hoe je dat kan weergeven ?

[EnsconcE]

Volgens mij moet het niet anders zijn, maar zijn ze anders. Websites zijn voornamelijk informerend van aard terwijl webapplicaties ondersteundend zijn in een werktaak.

[JHS]

EnsconcE: Dat gaat over de funtie, terwijl dit topic volgens mij vooral over het design gaat . Waarom zou dat verschil in functie betekenen dat het design anders móét, zoals gesuggereerd in de TS?

[EnsconcE]

Zoals in de TS gezegd wordt: voor een website moet marketingresearch gedaan worden terwijl dat voor een webapplicatie niet moet gebeuren(of in mindere mate). Als je alleen informeert dan heb eigenlijk alleen een applicatie die geen input toelaat, terwijl een webapplicatie juist input moet toelaten. Dit is een zwart witte houding, want er is een grijs vlak maar dat even hierbuiten gelaten. Als je puur naar websites kijkt dan is het klikken en klaar. Terwijl een webapplicatie toch meer in de functionaliteit voorziet.

Bij en webapplicatie wil je zo weinig mogelijk ruimte aan design spenderen en zoveel mogelijk aan functionaliteit. Terwijl een website zoveel mogelijk grafisch moet zijn en daarbij informerend. Eigenlijk kun je al zeggen dat er geen input nodig is voor een website.

[JHS]

Waarom zou je voor een webapp dat niet doen . Dat is toch ook zeker iets wat je wilt verkopen en een doelgroep heeft? Daarnaast heb je het met je zwart/wit verhouding het nog steeds over de functie van een website, terwijl het gaat om het design. Nu is het wel zo dat het vaak goed is om het design te baseren op de functie, maar dat wil niet zeggen dat een design voor een informerende website anders dient te zijn dan een een interactieve website, in mijn ogen . Als laatste is volgens mij júist het grijze vlak belangrijk. Hoeveel sites zijn er nu die alleen informatie hebben? En hoeveel sites zijn er nou die je alleen ondersteunen bij een taak en geen informatie bieden? Betergezegd, de meeste webapps houden zich volgens mij met informatie bezig .

Waarom zou je zo weinig mogelijk ruimte aan design spenderen bij een webapp? Ondersteunend design is daar volgens mij net zo goed relevant. En ik vraag me al helemaal af waarom een website zo veel mogelijk grafisch moet zijn. Ook daar is het design volgens mij toch echt ondersteunend, en is de 'informerende' functie van een website niet iets wat 'daarbij' komt.

[BalusC]

Om een discussie te starten rond het design van webapplicaties. Het design van deze webapplicaties heeft een andere aanpak nodig dan het design van traditionele websites, e-commerce, of dergelijke. Op het gebied van technieken, XHTML/CSS, staan we op hetzelfde vlak. Maar er moet wel op een andere manier ontworpen worden.

Sja. Ik bouw beroepsmatig webapplicaties voor grote klanten en we volgen gewoon de designrichtlijnen dat de klant ons opgeeft. Ik heb in ieder geval niet eerder beroepsmatig een webapplicatie gebouwd waarbij ik zelf de visuele/functionele vormgeving moet definiëren. Dat wordt in regel door een compleet ander team gedaan dan de programmeurs. De in de topicstart genoemde punten worden volledig door hun in rekening genomen

Als er iemand voorbeelden heeft van wel ontworpen webapplicaties mag je hier screenshots van posten om anderen een idee te geven op welke manier het hoort te zijn.

Ik mag hier geen screenshots posten (intranetwebapplicaties) maar ik kan wel zeggen dat de in de topicstart genoemde lijst vrij compleet is

En als er genoeg animo is, kunnen we misschien wel eens bekijken om een contestje op te zetten.

Ik vraag me hier de nut van af.

[-FoX-]

BalusC schreef op vrijdag 22 december 2006 @ 13:33:
Ik mag hier geen screenshots posten (intranetwebapplicaties) maar ik kan wel zeggen dat de in de topicstart genoemde lijst vrij compleet is
[...]
Ik vraag me hier de nut van af.

Het nut van zo'n contest is enerzijds fun natuurlijk, anderzijds krijg je zo een beter idee hoe verschillende mensen dit aanpakken. Je geeft zelf al aan dat je die screenshots niet mag posten en er is op het web dus ook niet teveel van te vinden. Daarom kan het misschien interessant zijn om te zien welke realisaties er uit komen.

[BalusC]

Je doelt op de 'plaatsing' van de in de lijst genoemde elementen binnen een webapplicatie? Het visuele design (kleurtjes, stijl, enzo) dus compleet daargelaten? Bij wijze van spreken een zwart-witte webapplicatie bouwen dus?

[ Voor 10% gewijzigd door BalusC op 22-12-2006 14:22 ]

[Standeman]

Ik merk regelmatig dat web-applicaties te rijk zijn aan features. Om de een of andere reden zijn web applicaties "tha bomb" en kijkt men niet eens meer naar normale rich clients applicaties in bijv. Swing.

Naar mijn mening leent o.a. Swing zich veel beter om een rijke user-experience te bereiken dan een web-app. Zeker wanneer we naar meer geavenceerde widgets kijken zoals trees en filter-lists. HTML ondersteund deze widgets standaard niet en als je ze nodig hebt moet je gaan klooien met javascript om iets redelijk werkend te krijgen. Tevens vind ik het gehele request / response model van HTTP ook niet echt relaxed om een vloeiende applicatie te bouwen (alhoewel m.b.v Ajax het enorm verbeterd is).

Ik ben nog steeds van mening dat rich clients beter en goedkoper gebouwd kunnen worden wanneer je het niet in een web-app giet. HTML / CSS / Javascript is nu eenmaal niet ontworpen om rich clients mee te bouwen en dat merk je duidelijk!

[-FoX-]

BalusC schreef op vrijdag 22 december 2006 @ 14:20:
Je doelt op de 'plaatsing' van de in de lijst genoemde elementen binnen een webapplicatie? Het visuele design (kleurtjes, stijl, enzo) dus compleet daargelaten? Bij wijze van spreken een zwart-witte webapplicatie bouwen dus?

Nee, want daar is niets aan. Het is net de "kunst" om de applicatie een robuuste look and feel te geven door een stijl toe te passen met de nodige kleurtjes. De webapplicatie moet immers de toon zetten. Zo zal een financiële webapplicatie er anders uitzien dan een medische of boekhouding webapplicatie.

Standeman schreef op vrijdag 22 december 2006 @ 14:50:
Ik merk regelmatig dat web-applicaties te rijk zijn aan features. Om de een of andere reden zijn web applicaties "tha bomb" en kijkt men niet eens meer naar normale rich clients applicaties in bijv. Swing.

Naar mijn mening leent o.a. Swing zich veel beter om een rijke user-experience te bereiken dan een web-app. Zeker wanneer we naar meer geavenceerde widgets kijken zoals trees en filter-lists. HTML ondersteund deze widgets standaard niet en als je ze nodig hebt moet je gaan klooien met javascript om iets redelijk werkend te krijgen. Tevens vind ik het gehele request / response model van HTTP ook niet echt relaxed om een vloeiende applicatie te bouwen (alhoewel m.b.v Ajax het enorm verbeterd is).

Ik ben nog steeds van mening dat rich clients beter en goedkoper gebouwd kunnen worden wanneer je het niet in een web-app giet. HTML / CSS / Javascript is nu eenmaal niet ontworpen om rich clients mee te bouwen en dat merk je duidelijk!

Toch worden deze rijke webapplicaties op een bredere schaal toegepast dan bvb een webstart applicatie. Waarom? Geen idee eigenlijk... Ik denk dat men ervanuitgaat dat een bekende omgeving (het web) voor een gebruiker meer vertrouwd aanvoelt dan een hele nieuwe applicatie. Ook zijn er client-side minder problemen qua installatie en omgeving. Een webapplicatie kan virtueel vanaf iedere werkplek benaderd worden en biedt tevens ook support voor andere devices (mobile, ..)

[t-x-m]

Ben momenteel bezig met een basic systeem voor een klant van ons, facturering, relaties voorraadbeheer en nog wat van dat soort zaakjes.
Kan wel wat screenshots/WIP's plaatsen:screen1, screen2

Geen inhoudelijk commentaar graag want het is nog niet af, gaat even om de interface. Voldoet aardig aan de gestelde punten in de OP

[Standeman]

-FoX- schreef op vrijdag 22 december 2006 @ 14:58:
[...]

Nee, want daar is niets aan. Het is net de "kunst" om de applicatie een robuuste look and feel te geven door een stijl toe te passen met de nodige kleurtjes. De webapplicatie moet immers de toon zetten. Zo zal een financiële webapplicatie er anders uitzien dan een medische of boekhouding webapplicatie.


[...]

Toch worden deze rijke webapplicaties op een bredere schaal toegepast dan bvb een webstart applicatie. Waarom? Geen idee eigenlijk... Ik denk dat men ervanuitgaat dat een bekende omgeving (het web) voor een gebruiker meer vertrouwd aanvoelt dan een hele nieuwe applicatie. Ook zijn er client-side minder problemen qua installatie en omgeving. Een webapplicatie kan virtueel vanaf iedere werkplek benaderd worden en biedt tevens ook support voor andere devices (mobile, ..)

Deployment is inderdaad een stuk lastiger bij gewone client-server applicaties. Hoewel je met web-apps weer het probleem hebt van de verschillende browsers en het niet volledig ondersteunen van de standaarden.
Natuurlijk allemaal problemen waar prima om heen te werken valt als je van te voren even nadenkt over je design en bijv widgets. Op verschillende punten is het gras aan de andere kant toch vaak net iets groener.
Ik zou wel graag een nieuwe versie van HTML zien met een veel grotere verzameling standaard widgets, zodat je deze niet zelf hoeft te implementeren.
Maar opdrachtgevers blijven imo net iets te web minded (als of er niets anders is)

Om trouwens weer wat on topic te komen:

Het bouwen van een web applicatie is inderdaad iets heel anders dan een informatieve / commerciele website.
Een web-app hoeft de doelgroep niet over te halen om gebruikt te worden, de noodzaak tot eye-candy is dus minimaal. Er kunnen eisen gesteld worden aan de doelgroep en er kunnen bijv. ook cursussen gegeven worden mocht het nodig zijn.
Het belangrijkste onderdeel van een web-app (behalve een juiste werking) is usability. Mensen gebruiken het omdat ze een bepaalde taak willen uitvoeren, niet omdat ze het graag willen (kan wel, maar is niet noodzakelijk). Hoe efficienter de taak m.b.v. de web-app gedaan kan worden hoe beter. Daar zal dan ook het zwaarte punt moeten liggen.

Een website is een ander verhaal. Mensen komen vrijwillig en zijn ook net zo snel weer weg (soms binnen 5 seconden). Voor dat je het weet zitten ze al bij de concurrent. Je moet ze direct kunnen boeien om ze vast te houden. Efficientie en usability is daarom niet belangrijkste, eye-candy des te meer.

[ Voor 23% gewijzigd door Standeman op 22-12-2006 15:22 ]

[JHS]

Standeman schreef op vrijdag 22 december 2006 @ 15:08:
(...) Een web-app hoeft de doelgroep niet over te halen om gebruikt te worden, de noodzaak tot eye-candy is dus minimaal. Er kunnen eisen gesteld worden aan de doelgroep en er kunnen bijv. ook cursussen gegeven worden mocht het nodig zijn.

Dat is in het geval van een boel van de webapps waar buzz omheen is juist niet waar .

Ik ben het verder met je eens dat zwaartepunt bij een webapp bij useability ligt in plaats van eyecandy, en bij een statische informatieve site het vaak andersom is . Maar dat wil in mijn ogen nog steeds niet zeggen dat je radicaal anders zou moeten ontwerpen.

Ik vraag me overigens eigenlijk nog steeds een beetje af wat nu precies het doel van dit topic. Ik ben vooral ingegaan op de stelling "Het designen van een website kan nauwelijks vergeleken worden met het designen van een webapplicatie". In mijn ogen hóeft daar niet echt een fundamenteel verschil tussen te zitten. Maar ik denk dat het een stuk interessanter is om te kijken naar hoe mensen design beslissingen nemen voor webapps . (In plaats van gewoon screens neer te zetten .) In deze is overigens de Design Decisions serie van SvN leuk te lezen.

[-FoX-]

Waarom is eyecandy niet toegelaten in webapplicaties? Het hoeft allemaal niet zo droog te zijn hoor, zelfs niet voor webapplicaties. Maar dikwijls hangt dit ook af van de context van de webapplicatie. Financiële webapplicaties zullen er doorgaans ook anders uitzien dan webapplicatie voor het beheren van immo oid.

Mij gaat het eerder om de manier waarop omgesprongen wordt met webapp design. Ik heb al verschillende web projecten gedaan (doorgaans j2ee, maar doet er niet toe) en bij de een krijgen we het design aangeleverd, bij de andere moeten we ze zelf maken, ... de klant is wel tevreden, daar gaat het niet om. Maar de aanpak is wel verschillend tov een gewone website.

Bij een gewone website ligt de nadruk op layout+informatie; bij een webapplicatie op layout+informatie+functionaliteit. En met dat extra facet moet goed omgesprongen worden wil je een deftige webapplicatie bouwen.

[Standeman]

-FoX- schreef op vrijdag 22 december 2006 @ 21:10:
Waarom is eyecandy niet toegelaten in webapplicaties? Het hoeft allemaal niet zo droog te zijn hoor, zelfs niet voor webapplicaties. Maar dikwijls hangt dit ook af van de context van de webapplicatie. Financiële webapplicaties zullen er doorgaans ook anders uitzien dan webapplicatie voor het beheren van immo oid.

Ik bedoel geenzins dat eyecandy verboden is voor webapplicaties, het zwaartepunt ligt gewoon ergens anders. In dat geval is het maar net hoeveel je daarin wilt investeren in iets dat imo marginale toevoeging heeft in het uitvoeren van een bepaalde taak (boekhouden b.v.). Het geld dat geinvesteerd wordt in eyecandy kan dan beter besteed worden aan usability.

Overigens vind ik dat een bepaald niveau van eyecandy wel onderdeel is van usability. Met een spuuglelijke applicatie is het immers ook niet lekker werken.

Mij gaat het eerder om de manier waarop omgesprongen wordt met webapp design. Ik heb al verschillende web projecten gedaan (doorgaans j2ee, maar doet er niet toe) en bij de een krijgen we het design aangeleverd, bij de andere moeten we ze zelf maken, ... de klant is wel tevreden, daar gaat het niet om. Maar de aanpak is wel verschillend tov een gewone website.

Bij een gewone website ligt de nadruk op layout+informatie; bij een webapplicatie op layout+informatie+functionaliteit. En met dat extra facet moet goed omgesprongen worden wil je een deftige webapplicatie bouwen.

Zijn er dan daadwerkelijk verschillen tussen het ontwerpen van een website en een webapplicatie. Want behalve een dikker functioneel ontwerp hoef je alleen rekening te houden met wat meer ruimte om je functionaliteit te kunnen plaatsen op het scherm.
Breadcrums, navigatie en lijsten zou je altijd wel hebben. Tabellen en de genoemde componenten in de OP zullen inderdaad veel meer voorkomen in een webapplicatie.

Als je bijvoorbeeld kijkt naar de frontpage en GoT. Daar zit design technisch gezien vrij weinig verschil (imo). Toch dienen ze allebei een ander doel. De frontpage is voornamelijk informatie voorziening en GoT een discussie forum.
Ik heb geen flauw idee hoe GoT en de frontpage ontwikkeld zijn, maar het lijkt me stug dat het design 2x is gemaakt of dat het bij beide een seperaat traject was.

Ik zie weinig verschil in het grafische ontwerp van een website of een webapplicatie. Uiteraard moet je wel rekening houden dat het doel anders is, maar dat lijkt mij persoonlijk niet de grootste uitdaging.

[htca]

Of er verschillen zijn, ja die zijn er. Ik loop zelf regelmatig tegen het probleem aan.
Afgelopen zomer heb ik een voetbal pool geschreven in PHP. Qua functionaliteit is het allemaal prima, maar het design is voor mijn gevoel ondermaats. Kort gezegd omdat ik er geen kaas van gegeten heb. Zie bijvoorbeel ook de site uit mijn sig, de baby site. Ik ben die nu aan het omzetten, maar "design" technisch vind ik dat veel lastiger dan functioneel.

Je moet het een beetje zien als de relatie "architect" vs. "constructeur". De klant wil een doos (huis/woning/fabriek). Hoe die er uitziet is iets heel anders dan hoe de construtie in elkaar zit.