[WPF] Pro's en cons van chromeless windows?

[Dark Blue]

Hoi,
Voor een applicatie in ontwikkeling ben ik op het moment aan het uitzoeken of ik chromeless, oftewel borderless windows wil gebruiken. Op dit moment gebruikt de applicatie het, en ik wil afwegen of ik het wel wil behouden.

Pro:
• vormgeving van de applicatie wordt nauwelijks beïnvloed door de Windowsversie waar het op draait
• meer ontwerpvrijheid, consistentie in vormgeving schermen
• detail: rounded corners
• geen ruimte verspild aan de borders

Con:
• max, min, en sluitknoppen zelf inbouwen in interface
• max, min en sluitknoppen worden niet gerenderd wanneer de applicatie hangt / crasht
• ik heb geen idee hoe Windows versies voor XP met transparantie omgaan
• de applicatie gaat alleen op Windows draaien, gebruikers herkennen die interface

Ik heb al gezocht naar chromeless windows, maar dan vind ik alleen rants en raves over Google Chrome. Dat is gewoon een grote naam en overschaduwt in de zoekresultaten eigenlijk alle feiten over chromeless, de term die Blend/Visual Studio gebruikt om aan te duiden dat een scherm randloos is. Met borderless kwam ik al meer in de richting, maar dan nog vind ik alleen Visual Studio-tutorials die me aanwijzen waar en hoe ik 'm borderless kan maken.

Ik wil weten waarom je het wel of niet zou moeten doen!
Mijn applicatie gaat draaien op systemen van Windows 2000 tot en met Windows 7, en ik wil weten of ik die vrijheid van chromeless en rounded corners kan nemen, of dat die op verschillende platformen lelijk of onbruikbaar wordt. Ik speel liever op safe, maar wil wel een flitsende applicatie neerzetten.

Wat is jullie mening daarover? Als je kanttekeningen hebt bij de punten hierboven (als mijn aannames mis zijn, of alleen onder bepaalde condities gelden)... reageer gerust ook daarop!

[Gerco]

Dark Blue schreef op maandag 28 september 2009 @ 10:48:
Pro:
• vormgeving van de applicatie wordt nauwelijks beïnvloed door de Windowsversie waar het op draait

Dit zou ik persoonlijk onder Con plaatsen. Gebruikers kiezen niet voor niets een thema en wanneer je applicatie zich daar niet aan houd valt hij uit de toon (al is er met de enorme berg verschillende interfaces op Windows al niet echt van een 'toon' te spreken).

Ik vind persoonlijk apps die zich niet aan mijn settings houden irritant. Mocht je ook slechtziende gebruikers hebben is het nog een stapje erger, die kunnen de app mogelijk helemaal niet gebruiken als de thema settings niet gerespecteerd worden.

[.oisyn]

Dark Blue schreef op maandag 28 september 2009 @ 10:48:
Ik heb al gezocht naar chromeless windows, maar dan vind ik alleen rants en raves over Google Chrome. Dat is gewoon een grote naam en overschaduwt in de zoekresultaten eigenlijk alle feiten over chromeless, de term die Blend/Visual Studio gebruikt om aan te duiden dat een scherm randloos is.

Heb je al geprobeerd te zoeken met "-google" om alle resultaten waar het woord google in voorkomt eruit te filteren?

[roy-t]

Het hangt er natuurlijk af wat voor applicatie je maakt, maar als je überhaupt al afvraagt of je borderless windows wilt gebruiken ga ik er iig van uit dat het past bij je applicatie.

Persoonlijk vind ik programma's die dit doen eigenlijk altijd irritant (zie bijvoorbeeld de Roxio cd brand software), vooral voor ietwat serieuzere programma's vind ik het ook niet gepast.

Voor spelletjes e.d. zie ik het liever fullscreen, en voor presentaties eigenlijk ook.

Wat voor programma ga je eigenlijk maken, en wat wil je voor wilds qua UI doen waardoor je graag randloze schermen wilt gebruiken? Dan is het natuurlijk veel beter te beoordelen. Hoewel, ik bekijk het nu van de user kant, en niet van de programmeer kant.

Als het een programma is met veel apparte schermen zou ik het niet doen, je zou dan bijna je eigen windowing/forms framework moeten maken om niet telkens te hoeven klieren met die kruisjes e.d. Is het een programma met 1 of een paar schermen kan het mogelijk wel, maarja die UI moet dan wel heel gaaf en niet vierkant zijn om het nut te eisen . Ook kun je dan niet andere standaard windows controls gebruiken omdat ze niet meer passen.

Verder wat betreft WPF en windows 2000, volgens mij draait WPF helemaal niet op Windows 2000, dus dat is al een no-go.

[RobIII]

Gerco schreef op maandag 28 september 2009 @ 10:53:
[...]

Dit zou ik persoonlijk onder Con plaatsen. Gebruikers kiezen niet voor niets een thema en wanneer je applicatie zich daar niet aan houd valt hij uit de toon (al is er met de enorme berg verschillende interfaces op Windows al niet echt van een 'toon' te spreken).

Ik vind persoonlijk apps die zich niet aan mijn settings houden irritant. Mocht je ook slechtziende gebruikers hebben is het nog een stapje erger, die kunnen de app mogelijk helemaal niet gebruiken als de thema settings niet gerespecteerd worden.

Met Gerco.
RobIII: Mooi smoeltje

Sure; een mooi gestylede/geskinnde kan heel mooi zijn maar ik heb persoonlijk een hartgrondige hekel aan applicaties die buiten het OS GUI om gaan. Als je het dan toch doet, probeer dan minimaal de window chrome te gebruiken zolang dat mogelijk is en niet mega uit de toon valt (er zijn gevallen waarbij het gewoon echt geen porem is). Maar als het kan, en dat bespeur ik uit je post, houden! Zeker zodra je applicatie wat breder gebruikt gaan worden dan "die 2 baliemedewerkers" dien je rekening te gaan houden met slechtzienden etc. Zaken die het OS normaliter voor je afhandelt zul je dan weer zelf moeten gaan afhandelen (alhoewel ik niet weet in hoeverre WPF dat al (deels) voor je doet/kan doen).

offtopic:
Van 't weekend op zoek geweest naar een goede virusscanner als alternatief voor McAfee die ik al jaren gebruik. Avast bleek wel een goede te zijn, dus maar eens (thank God in een VM voor test-doeleinden) geïnstalleerd. Krijg je zoiets voorgeschoteld:



3 seconden naar gekeken, tanden geknarst en op uninstall gemept. Iemand die serieus denkt dat ik m'n virusscanner als een autoradio ga zitten bedienen heeft het grondig mis Avast. Boeie of ik kan switchen naar een eventuele "non-skinnede" versie; ik heb niet eens de zin noch tijd daar naar op zoek te gaan. Kun je nog zo'n goeie virusscanner zijn/hebben, ik ben dan héééél snel klaar met je

[ Voor 32% gewijzigd door RobIII op 28-09-2009 11:47 ]

[leuk_he]

Volgens mij gaat het relatief veel tijd kosten om een niet standaard gedraagende applicatie de gui goed te laten werken op windows 2000 tot Aero interface. Merk b.v. op hoe lang chomebrowser er over heeft gedaan om full screen te ondersteunen, iets wat wel degelijk gemist werd.

Dat leidt erg af van de hoofd functionaliteit. Flitsend is meer dat alles klopt:
-> buttons die grayed zijn als ze niet werken.
-> Tabs die goed synchroniseren
-> Pop-up hoverhelp die verder gaat dan "push button to enable function"

/Edit: robbIII

[ Voor 3% gewijzigd door leuk_he op 28-09-2009 11:23 ]

[.oisyn]

RobIII schreef op maandag 28 september 2009 @ 11:08:

offtopic:
Van 't weekend op zoek geweest naar een goede virusscanner als alternatief voor McAfee die ik al jaren gebruik. Avast bleek wel een goede te zijn, dus maar eens (thank God in een VM voor test-doeleinden) geïnstalleerd. Krijg je zoiets voorgeschoteld:

[afbeelding]

3 seconden naar gekeken, tanden geknarst en op uninstall gemept. Iemand die serieus denkt dat ik m'n virusscanner als een autoradio ga zitten bedienen heeft het grondig mis Avast.

't Is toch echt your loss, want het is een fantastische gratis virusscanner. En idd, in die 4e seconde had je de optie gevonden om 'm niet als skinned te gebruiken (eerste tabblad onder de program settings, te bereiken met een right click op de tray icon). Daarnaast, die window die je daar post, daar zit je dus *nooit* in. De residential scanner config je met een aparte (unskinned) dialog, en handmatige scans initieer je meestal vanuit explorer.

[ Voor 11% gewijzigd door .oisyn op 28-09-2009 12:26 ]

[roy-t]

Even omdat het misschien wat ondergesneeuwd is in mijn post terwijl het eigenlijk het belangrijkste is:

Mijn applicatie gaat draaien op systemen van Windows 2000 tot en met Windows 7,

WPF draait niet op Windows 2000 . (Zover ik even snel kon vinden).

[Dark Blue]

.oisyn schreef op maandag 28 september 2009 @ 10:53:
[...]

Heb je al geprobeerd te zoeken met "-google" om alle resultaten waar het woord google in voorkomt eruit te filteren?

Nee
Kan ik natuurlijk inderdaad wel even doen. Maar tot dusver levert dit topic me ook al genoeg meningen op

roy-t schreef op maandag 28 september 2009 @ 11:01:
Het hangt er natuurlijk af wat voor applicatie je maakt, maar als je überhaupt al afvraagt of je borderless windows wilt gebruiken ga ik er iig van uit dat het past bij je applicatie.

Persoonlijk vind ik programma's die dit doen eigenlijk altijd irritant (zie bijvoorbeeld de Roxio cd brand software), vooral voor ietwat serieuzere programma's vind ik het ook niet gepast.

Voor spelletjes e.d. zie ik het liever fullscreen, en voor presentaties eigenlijk ook.

Wat voor programma ga je eigenlijk maken, en wat wil je voor wilds qua UI doen waardoor je graag randloze schermen wilt gebruiken?

Ik ben het met je eens; spelletjes en presentaties zien er veel netter uit zonder chrome.
De applicatie waar ik aan werk is heel sec gezegd een invoer-tool. We registreren gegevens, zoals de Belastingdienst een applicatie heeft om je jaarlijkse opgaaf te doen of zoals CenterParcs een stukje software heeft om gezinnen te registreren en huisjes te verhuren. Wat betreft gebruikers en omgeving waarin het gaat draaien kun je nu het beste aan CenterParcs denken.

De huidige keuze voor chromeless heb ik nog niet helemaal kunnen terugvinden, maar tot nu toe is mijn idee nog: het is fancy, en 'gewoon omdat het kan'. We hebben al eenzelfde stukje software onder oudere technologie draaien en deze nieuwe applicatie biedt dus nieuwe features en een fancier look. Nu zit ik dus te wikken: fancy look, chromeless window. Maar volgens mij kun je met een chromed window ook wel een fancy look bereiken én heb je meer gebruiksvriendelijkheid.

Als het een programma is met veel apparte schermen zou ik het niet doen, je zou dan bijna je eigen windowing/forms framework moeten maken om niet telkens te hoeven klieren met die kruisjes e.d. Is het een programma met 1 of een paar schermen kan het mogelijk wel, maarja die UI moet dan wel heel gaaf en niet vierkant zijn om het nut te eisen . Ook kun je dan niet andere standaard windows controls gebruiken omdat ze niet meer passen.

Klopt, er zijn 2 niveaus schermen, en daarvoor zijn nu custom indelingen en kruisjes etc. gemaakt.
Ik ga veel liever uit wat Windows te bieden heeft, maar ik twijfelde: blijf ik dan in het jaar 2009 niet hangen in gewoontes van Windows 95?

Verder wat betreft WPF en windows 2000, volgens mij draait WPF helemaal niet op Windows 2000, dus dat is al een no-go.

Dat zou kunnen. Dan ben ik wat te optimistisch geweest over de platformen, dan is XP gewoon een vereiste. Klinkt sneu, maar daarover hebben andere mensen nagedacht dan ik

Op dit moment zeg ik: terug naar chrome windows.

leuk_he schreef op maandag 28 september 2009 @ 11:20:
Volgens mij gaat het relatief veel tijd kosten om een niet standaard gedraagende applicatie de gui goed te laten werken op windows 2000 tot Aero interface. Merk b.v. op hoe lang chomebrowser er over heeft gedaan om full screen te ondersteunen, iets wat wel degelijk gemist werd.

Dat leidt erg af van de hoofd functionaliteit. Flitsend is meer dat alles klopt:
-> buttons die grayed zijn als ze niet werken.
-> Tabs die goed synchroniseren
-> Pop-up hoverhelp die verder gaat dan "push button to enable function"

/Edit: robbIII

Klopt, die user controls die kloppen. Ik heb GUI Bloopers hier bij de hand en ben erg streng! Dat soort dingen komen er goed in te zitten, maar daarover ga ik me pas echt buigen zodra het main window op z'n plek staat en ingericht kan worden. maar goed dat je ze opmerkt. Ik frustreer me de laatste weken steeds meer over dat soort dingen, bij de meest simpele programma's... tabs tonen terwijl er maar één item is, verkeerd gegroepeerde radiobuttons, groupboxes terwijl er maar één group is... anyway, daar gaat gerust de bijl wel in.

Nu eerst dat mainwindow. Ik vind het argument van gebruiksvriendelijkheid, en denken aan slechtziende mensen ook al een hele goede.

[Woy]

Het ligt er denk vooral een beetje aan hoe het gebruikt word. Zoals je bijvoorbeeld de center parcs aanhaalt, kan ik me voorstellen dat er een medewerker de hele dag met die applicatie werkt, en dus ook niet even snel een andere applicatie opstart. Dan kan ik me voorstellen dat full-screen wel wenselijk is. En aangezien je dan ook niet zoveel met windows/andere applicaties te maken hebt, is het niet zo hinderlijk dat je geen standaard windows feel hebt (Zolang je het natuurlijk maar consequent door de hele applicatie gelijk trekt)

Als er ook interactie van de gebruiker is met andere applicaties, of de applicatie niet perse full-screen draait, zou ik ten alle tijden gewoon de titelbalk + min/max/sluit buttons willen hebben.

Ik ben het met de mensen boven mij eens dat het verschrikkelijk irritant is als een applicatie daar opeens vanaf wijkt.

[ Voor 15% gewijzigd door Woy op 28-09-2009 14:04 ]

[leuk_he]

Dark Blue schreef op maandag 28 september 2009 @ 13:35:
Ik ga veel liever uit wat Windows te bieden heeft, maar ik twijfelde: blijf ik dan in het jaar 2009 niet hangen in gewoontes van Windows 95?

De windows interface is geinspireerd door de CUA die nog standaard met de windows 3.0 SDK in boekvorm werd meegeleverd. Zoveel is daar sinds windows 3.0 eigenlijk niet echt aan veranderd.

Grote voordeel is dat een gebruiker meteen met een applicatie overweg kan omdat die precies als andere applicaties werkt.

[Dark Blue]

Woy schreef op maandag 28 september 2009 @ 14:03:
Het ligt er denk vooral een beetje aan hoe het gebruikt word. Zoals je bijvoorbeeld de center parcs aanhaalt, kan ik me voorstellen dat er een medewerker de hele dag met die applicatie werkt, en dus ook niet even snel een andere applicatie opstart. Dan kan ik me voorstellen dat full-screen wel wenselijk is. En aangezien je dan ook niet zoveel met windows/andere applicaties te maken hebt, is het niet zo hinderlijk dat je geen standaard windows feel hebt (Zolang je het natuurlijk maar consequent door de hele applicatie gelijk trekt)

Als er ook interactie van de gebruiker is met andere applicaties, of de applicatie niet perse full-screen draait, zou ik ten alle tijden gewoon de titelbalk + min/max/sluit buttons willen hebben.

Ik ben het met de mensen boven mij eens dat het verschrikkelijk irritant is als een applicatie daar opeens vanaf wijkt.

Klopt, de applicatie staat de hele dag in beeld. Gebruikers kunnen via knoppen in de interface naar Word toe voor brieven etc. en naar Outlook voor e-mails, er wordt dan gelijk een sjabloon getoond. Het is dus een erg Windows en Office-gerelateerd pakket.

Ik ben helemaal voor het aanhouden van het chrome. Maar dat komt ook omdat ik op Vista werk hier en ik die halftransparante rand er gelikt uit vind zien. Onder XP krijg je al zo'n blauw Teletubbie-ding en als je de Klassieke kleuren aan hebt staan, een grijze rand. De applicatie gaat zelden fullscreen geopend worden, dus je ziet die omlijsting altijd.

Denk ik dan aan de esthetische kant, dan zeg ik: weg die rand. Maar denk ik aan de gebruiksvriendelijkheid en herkenbaarheid, dan laat ik hem liever staan.

[Woy]

Dark Blue schreef op maandag 28 september 2009 @ 14:46:
[...]
Denk ik dan aan de esthetische kant, dan zeg ik: weg die rand. Maar denk ik aan de gebruiksvriendelijkheid en herkenbaarheid, dan laat ik hem liever staan.

Maar aangezien de gebruikers alsnog word/outlook gebruiken zijn ze aan die interface gewend. Ook esthetisch gezien is conformiteit aan de rest van de applicaties IMHO wel wenselijk.

[roy-t]

Voor zo'n app die je nu beschrijft zo ik 100% zeker gewoon randjes overal om heen doen. Het lijkt zo een vrij zakelijk app.

Verder waarom gebruik je eigenlijk WPF? Wil je het later ook in een website gaan tonen? Anders kun je natuurlijk gewoon de 'eis' WPF laten vallen en dan je met WinForms ook Windows 2000 supporten, toch nog 20% userbase erbij in de zakelijke hoek. (Ligt er natuurlijk aan of je de app helemaal moet herschrijven, als dat niet zo is dan blijf je gewoon met WPF werken natuurlijk).

Misschien nog even uitzoeken of Windows 2000 niet supporten een bewuste keuze was? Net als de keuze voor WPF en de keuze voor randloos?

[NC83]

Als je vista draait is alles eigenlijk in WPF gemaakt en alles met border dus zo erg is het niet. Daarnaast heeft WPF ook het voordeel dat het op DX draait en niet GDI, dus altijd al double buffered dus geen blinks tussen refreshes.

Daarnaast kun je een pixel shader gebruiken om de achtergrond van een applicatie er flistend uit te laten zien, bedenk hier wel bij dat je dan een pixel shader moet kunnen draaien. (Op Vista zou dat normaal moeten kunnen, maar XP hoeft niet).

Daarnaast moet ik zeggen dat WPF beter het thema volgt dat de gebruiker kiest dan WinForms.

[ Voor 9% gewijzigd door NC83 op 29-09-2009 00:08 ]

[RobIII]

NC83 schreef op dinsdag 29 september 2009 @ 00:08:
Als je vista draait is alles eigenlijk in WPF gemaakt

Would you care to explain Hoe kom je bij die bewering?

[roy-t]

NC83 schreef op dinsdag 29 september 2009 @ 00:08:
Als je vista draait is alles eigenlijk in WPF gemaakt en alles met border dus zo erg is het niet. Daarnaast heeft WPF ook het voordeel dat het op DX draait en niet GDI, dus altijd al double buffered dus geen blinks tussen refreshes.

WinForms kun je al eeuwen op double buffered modus laten draaien. Gewoon één vinkje voor je form in VS.

Daarnaast moet ik zeggen dat WPF beter het thema volgt dat de gebruiker kiest dan WinForms.

O? Ehm, en op welke manier dan. WinForms neemt de standaard button vorm over, alle standaard kleuren, de standaard menubalk vorm etc... Wat doet WPF meer dan dat?

[Dark Blue]

roy-t schreef op maandag 28 september 2009 @ 16:36:
Voor zo'n app die je nu beschrijft zo ik 100% zeker gewoon randjes overal om heen doen. Het lijkt zo een vrij zakelijk app.

Klopt, dat is mijn koers nu ook.

Verder waarom gebruik je eigenlijk WPF? Wil je het later ook in een website gaan tonen? Anders kun je natuurlijk gewoon de 'eis' WPF laten vallen en dan je met WinForms ook Windows 2000 supporten, toch nog 20% userbase erbij in de zakelijke hoek. (Ligt er natuurlijk aan of je de app helemaal moet herschrijven, als dat niet zo is dan blijf je gewoon met WPF werken natuurlijk).

Voor WPF is lang geleden al gekozen. De applicatie staat nu ook al voor 80% en er zitten 5 man dagelijks fulltime aan te werken, dus terug naar een andere architectuur is geen optie

We willen het ook in een website gaan tonen, ja.

Misschien nog even uitzoeken of Windows 2000 niet supporten een bewuste keuze was? Net als de keuze voor WPF en de keuze voor randloos?

Dat is waarschijnlijk wel een bewuste keuze geweest ja. Mensen die per sé op 2000 willen blijven kunnen ook nog ons huidige pakket gebruiken, alleen over een paar jaar niet meer.
De keuze voor randloos is gemaakt door de ontwerper voor mij, en met wat overleg hier kan ik nog wel achterhalen waarom.

Ik hoef bijvoorbeeld niet dit:


Maar dit is ook iets waar ik niet van sta te springen:

[Woy]

Ik zie het probleem in het laatste scherm niet zo, als een gebruiker nou eenmaal de classic windows look heeft, dan vind ik het netjes dat je daar met je applicatie op aansluit.

Natuurlijk wil je niet bij een gebruiker die de Aero interface gebruikt een dergelijk scherm tonen.

Dan heb ik het natuurlijk over het uiterlijk, en niet specifiek over het getoonde design, want dat oogt zo op het eerste gezicht nogal rommelig. Overigens vind ik inderdaad Nero ook irritant dat het niet in een "gewoon" scherm getoond word.

[Dark Blue]

Woy schreef op dinsdag 29 september 2009 @ 12:48:
Ik zie het probleem in het laatste scherm niet zo, als een gebruiker nou eenmaal de classic windows look heeft, dan vind ik het netjes dat je daar met je applicatie op aansluit.

Natuurlijk wil je niet bij een gebruiker die de Aero interface gebruikt een dergelijk scherm tonen.

Dan heb ik het natuurlijk over het uiterlijk, en niet specifiek over het getoonde design, want dat oogt zo op het eerste gezicht nogal rommelig. Overigens vind ik inderdaad Nero ook irritant dat het niet in een "gewoon" scherm getoond word.

Snelstart is ongeveer het lelijkste en onoverzichtelijkste programma dat ik me kan herinneren, vandaar dat voorbeeld. Natuurlijk ziet dat er in aero-look al een stuk beter uit, mits de controls allemaal standaard zijn en niet door de Snelstart devvers zo gestijld zijn.

Maar wat ik ermee bedoel is dat een saai invoerprogramma er heel onaantrekkelijk uit kan gaan zien, gewoon omdat die klassieke Windows-interface er zo'n gedateerd stempel op drukt.

[kwaakvaak_v2]

maar... waarom zo hameren op een look? Is het niet veel belangrijker dat de gebruiker een inuitieve GUI krijgt, ipv eentje die er ontzettend gelikt uitziet omdat je een fantastische 'flipperkast' theme hebt gemaakt?

Als ik een applicatie maak, waar gebruikers veel data moeten invoeren zorg ik er liever voor dat de schermen logisch opgebouwd zijn, er met cursor keys genavigeerd kan worden ipv enkel met een muis. Functionaliteit staat imho ver boven een fancy gui. Tuurlijkt druist dat in tegen je ontwerpers achtergrond, maar ik kan je nu al voorspellen dat als jij een hele fancy mooie interface ontwerpt waarbij er veel ruimte is voor leuke vormgevingsdetails waardoor je gebruikers twee keer zoveel moeten scrollen en klikken om hun data te zien, ze op zijn zachts gezegd minder blij met je zijn

Denk vanuit de eindgebruiker, niet vanuit de ontwerper. Precies dezelfde denkfout maken programmeurs overigens ook, je kunt altijd zien of een gui gemaakt is door een interaction specialist, graficus of een programmeur. De eerste is meestal goed in elkaar gezet, met een eenduidige interface en goede input flow, de tweede ziet er waanzinnig uit, maar meestal over de top kwa vormgeving en de derde heeft een overvloed aan opties verdeeld over tabbladen met daarop 20 vinkjes en 5 dropdowns en 8 input velden.

[jbdeiman]

@Kwaakvaak_v2
Waarom hameren op een look?
1) Dat staat natuurlijk al goed (een verouderde interface komt tegenwoordig niet goed meer over)
2) De mens is visueel ingesteld

Maargoed, natuurlijk heb je gelijk en is de look niet iets waarop de kwaliteit van een applicatie staat of valt. Het is echter wel degelijk iets waarmee rekening moet worden gehouden, en waarmee je rekening moet houden.
Daarnaast kan je met een goede look ook de verschillende onderdelen op zo'n scherm op een mooie maar tevens intuïtieve manier op het scherm toveren, maar nogmaals: inderdaad de looks zijn niet het key item.

Functionaliteit is punt 1, maar functionaliteit met een fraaie GUI kan ook prima, en daar stap jij nu net overheen. (tenminste zo komt het over). Het lijkt net of in jou mening mooi/ gelikt/ fancy niet hand in hand kan gaan met een intuïtief en functioneel ontwerp en dat is wel een kleine denkfout volgens mij.

Soms kan je met grafische elementen veel meer duidelijk maken dan met alleen een logische/ functionele indeling. Wanneer een programma veel "loze ruimte" kwijt is aan vormgevingsdetails, ben ik het echter wel met je eens. De grafische kant moet niet de bovenhand krijgen, maar kan wel een mooie toevoeging zijn.

Programmeurs zien inderdaad vaak heel veel mogelijkheden en willen die ook allemaal tonen. echter zien ook zij vaak (mijn persoonlijke ervaring uit werken met programmeurs, ben ik overigens zelf ook) wel dat iets onoverzichtelijk is. Het probleem is echter dan wel dat er wel eens iemand moet helpen om te bepalen welke opties evt. weg kunnen, en hoe de boel op een toch weer overzichtelijke manier weergegeven moet worden.

Een team van die 3 mensen (interaction specialist (IS), graficus (GR) en programmeur (PR)) zal in de praktijk ook het meest ideale resultaat opleveren, mits ze goed samen kunnen werken. Ondanks dat het er strak en netjes uit ziet, is het overzichtelijk en werkt het dan prima.
de IS kan een goede "workflow" qua schermen/ benodigde informatie/ knoppen per scherm kunnen maken. De GR kan in samenwerking met de IS een mooie maar toch duidelijke interface maken, en de PR zorgt voornamelijk voor de uitwerking.

[kwaakvaak_v2]

Ik stap er deels overheen idd, stukje ervaring van het nare soort aan mijn kant vrees ik. Te vaak heb ik goede software vergalt zien worden door een designer die kost wat het kost zijn/haar zin door moest drammen over een fancy look.

Aan de andere kant heb ik ook de overgang van een oude green screen (AS/400) applicatie naar een nieuwe java client begeleid bij een toenmalige klant en de meest gehoorde klacht van eind gebruikers was dat het er allemaal wel mooi uit zag en sommige dingen nu duidelijker waren doordat er heldere icons gebruikt waren, maar dat ze wel meer tijd kwijt waren omdat er nu met een muis expliciet vinkjes aangezet moesten worden terwijl voor heen een druk op de tab, gevolgt door een spatie voldoende was. Nu moest de hand van het keyboard (veel data entry mensen typen met 10 vingers ) naar de muis worden verplaatst en dat koste veel tijd (en dus ook tijd van de klant, want de orders werden realtime ingevoerd aan de telefoon)

Vandaar mijn keuze om ook te wijzen op het feit dat een fancy look helemaal niets zegt over de bruikbaarheid (en de meeste eindgebruikers liggen er totaal NIET wakker van hoe iets eruit ziet, als het maar werkt en prettig voor de ogen is kwa contrast gebruik)

[farlane]

jbdeiman schreef op woensdag 30 september 2009 @ 11:14:
1) Dat staat natuurlijk al goed (een verouderde interface komt tegenwoordig niet goed meer over)

Is erg persoonlijk. Ik vind de "oude" interface elementen en kleurstelling erg goed: je ziet vrijwel meteen welk control je geselecteerd hebt en op welke elementen er te klikken valt ( zelfs in de vrij drukke UI van je voorbeeld ). Daar is ook toen echt wel goed over nagedacht.

Dat men daarna vond dat alles blauw,rond,glimmend en half doorschijnend moest worden heeft veel minder met usability te maken.

[beany]

Misschien is het probleem gewoon dat praktisch alle fancy user interfaces niet goed doordacht zijn. Er is niks mis met een mooie user interface(en WPF biedt alle mogelijkheden tot een mooie UI) maar je moet het wel goed weten toe te passen.

Microsoft heeft bewust gekozen om programmeurs/ontwerpers alle mogelijkheden te geven, en ik probeer die dan ook te benutten. Maar ik denk wel heeeel veel na over hoe dingen te presenteren.

Overigens: Visual Studio 2010 is gemaakt met WPF. En dat is toch wel een duidelijke en toch ook mooie UI. Over Blend zijn de meningen overigens verdeeld. Ik vind het wel wat hebben, maar het valt te veel uit de toon.

[Dark Blue]

kwaakvaak_v2 schreef op woensdag 30 september 2009 @ 10:58:
maar... waarom zo hameren op een look? Is het niet veel belangrijker dat de gebruiker een inuitieve GUI krijgt, ipv eentje die er ontzettend gelikt uitziet omdat je een fantastische 'flipperkast' theme hebt gemaakt?

Als ik een applicatie maak, waar gebruikers veel data moeten invoeren zorg ik er liever voor dat de schermen logisch opgebouwd zijn, er met cursor keys genavigeerd kan worden ipv enkel met een muis. Functionaliteit staat imho ver boven een fancy gui. Tuurlijkt druist dat in tegen je ontwerpers achtergrond, maar ik kan je nu al voorspellen dat als jij een hele fancy mooie interface ontwerpt waarbij er veel ruimte is voor leuke vormgevingsdetails waardoor je gebruikers twee keer zoveel moeten scrollen en klikken om hun data te zien, ze op zijn zachts gezegd minder blij met je zijn

Dat ben ik met je eens, maar als je dit gelezen had:

Dark Blue schreef op maandag 28 september 2009 @ 13:35:
Klopt, die user controls die kloppen. Ik heb GUI Bloopers hier bij de hand en ben erg streng! Dat soort dingen komen er goed in te zitten, maar daarover ga ik me pas echt buigen zodra het main window op z'n plek staat en ingericht kan worden. maar goed dat je ze opmerkt. Ik frustreer me de laatste weken steeds meer over dat soort dingen, bij de meest simpele programma's... tabs tonen terwijl er maar één item is, verkeerd gegroepeerde radiobuttons, groupboxes terwijl er maar één group is... anyway, daar gaat gerust de bijl wel in.

Nu eerst dat mainwindow. (...)

Dan wist je dat ik ook bezig ben met de usability. Maar op een heel apart spoor. De grafische schil om het programma heeft geen consequenties voor alle functionaliteit die erin zit. Dus wees gerust, dat ik me in dit topic hier uitsluitend op de look&feel van wel of niet een chromeless window toeleg, betekent niet dat ik geen oog heb voor de functionaliteit en gebruiksvriendelijkheid. Daar daar gaat dit topic niet over

farlane schreef op woensdag 30 september 2009 @ 11:48:
[...]
Is erg persoonlijk. Ik vind de "oude" interface elementen en kleurstelling erg goed: je ziet vrijwel meteen welk control je geselecteerd hebt en op welke elementen er te klikken valt ( zelfs in de vrij drukke UI van je voorbeeld ). Daar is ook toen echt wel goed over nagedacht.

Ja, daarop wil ik met mijn volgende vraag (waarvoor ik geen apart topic wil openen) even op inhaken:

Bijvoorbeeld voor controls die ik nu heb, zoals een Ribbon of de achtergrond van een scherm: daar kun je toch in het programmeren ook gewoon voor aangeven dat ze 'StdWindowBgColor' moeten zijn? Ik weet de precieze namen van die kleuren niet, maar er is zo'n heel lijstje, met 'ButtonHighlightedColor' enzo.
Werkt dat Windows-versie-onafhankelijk?

Dwz. in XP heb je voor alle 3D-items een lichtgrijze kleur, omdat je je Windows kleuren zo hebt ingesteld; heeft in Vista of in 7 dan dat 3D-item nog steeds dezelfde naam? Aangezien je met Vista nu zo'n 'ijsblauwe' of 'lenteroze' gloed in kan stellen vraag ik me af of dat nog wel overeenkomt met de kleurenthema's die je in vorige Windowsversies kon toekennen.

Het liefste zeg ik voor de achtergrond van mijn applicatie namelijk 'pak de WindowStdColor' maar, dan hoef ik me geen zorgen te maken of de kleuren overeenkomen met die in de rest van z'n interface. Als de gebruiker er dan voor heeft gekozen om WindowsStdColor gitzwart te laten zijn, kan hij in mijn applicatie geen tekst lezen, maar als het goed is in de rest van Windows ook niet.

[farlane]

Dat zou inderdaad Windows versie onafhankelijk moeten zijn, neem aan dat WPF ook op die manier werkt. ( Heb ik geen ervaring mee )

[Dark Blue]

farlane schreef op woensdag 30 september 2009 @ 12:12:
Dat zou inderdaad Windows versie onafhankelijk moeten zijn, neem aan dat WPF ook op die manier werkt. ( Heb ik geen ervaring mee )

Ik bedacht me net, dat ik dat gewoon even in Blend kan gaan proberen. Ik weet dan niet hoe het er op een XP (Luna of klassiek) systeem uitziet, ik draai Vista. Edit: ik kan m'n theme terugzetten naar Windows klassiek. Da's al de helft van het werk
_{Ze zeggen ergens dat je je developers nooit de beste systemen moet even, dan gaan ze onrealistische eisen aan de systemen van de gebruikers stellen...}

[ Voor 7% gewijzigd door Dark Blue op 30-09-2009 12:44 ]

[farlane]

Dark Blue schreef op woensdag 30 september 2009 @ 12:37:
_{Ze zeggen ergens dat je je developers nooit de beste systemen moet even, dan gaan ze onrealistische eisen aan de systemen van de gebruikers stellen...}

Bij ons zijn het iha de gebruikers die de eisen stellen


_{Developers moeten echt wel de meest imba systemen hebben trouwens}

[Dark Blue]

code:

        <Rectangle x:Name="rectangle" HorizontalAlignment="Left" Width="100" RenderTransformOrigin="0.5,0.5" Margin="205,135,0,209" Stroke="Black">
            <Rectangle.Fill>
                <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">
                    <GradientStop Color="{DynamicResource {x:Static SystemColors.DesktopColorKey}}" Offset="0"/>
                    <GradientStop Color="{DynamicResource {x:Static SystemColors.InfoColorKey}}" Offset="1"/>
                </LinearGradientBrush>
            </Rectangle.Fill>
            <Rectangle.RenderTransform>
                <TransformGroup>
                    <ScaleTransform/>
                    <SkewTransform/>
                    <RotateTransform/>
                    <TranslateTransform/>
                </TransformGroup>
            </Rectangle.RenderTransform>
        </Rectangle>

Ik heb nu in Blend wel iets in elkaar gefröbeld waarvan ik hoop dat het zowel in XP, Vista als in 7 werkt. Schrik niet, het is gewoon wat geklik geweest . Het is een rectangle die een gradient maakt van je desktopkleur naar je Infocolorkey (ik gok tooltips, 't is geeltint). Ik zou graag die kleurwaardes willen aanspreken. Moet nog gaan uitvinden of het werkt. Iemand die dat weet?

Ik heb inmiddels een MSDN-pagina gevonden, die heel positief aangeeft dat het onder 7, Vista en XP (mits met servicepack) werkt!
http://msdn.microsoft.com...windows.systemcolors.aspx

[ Voor 8% gewijzigd door Dark Blue op 30-09-2009 15:09 ]

[farlane]

GetSysColor ( http://msdn.microsoft.com.../ms724371%28VS.85%29.aspx ) werkt vanaf 2K. 10 tegen 1 is dat de functie waarbij je WFC API uitkomt.

[RobIII]

Als je geel wil moet je gewoon geel nemen. Als de tooltip kleur (infocolordinges) toevallig geel is in jouw theme gaat je design natuurlijk nog op z'n bek bij een andere theme (zoals hoog contrast ofzo) bij iemand anders.

Als je geel/rood/groen/whatever wil moet je gewoon die kleur nemen. Als je een systeemkleur wil moet je een systeemkleur nemen maar dan niet mouwen als 't in een ander theme niet "mooi" is. Als je een systeemkleur neemt die, toevallig, net de kleur is (of dicht bij de kleur ligt) die je wil hebben kies je 'm om de verkeerde reden De (bijv.) InactiveCaption kleur heet niet voor niets InactiveCaption en die pas je dus beter niet toe op een button en de HotTrack kleur pas je niet toe op een titlebar.

[Dark Blue]

RobIII schreef op woensdag 30 september 2009 @ 18:10:
Als je geel wil moet je gewoon geel nemen. Als de tooltip kleur (infocolordinges) toevallig geel is in jouw theme gaat je design natuurlijk nog op z'n bek bij een andere theme (zoals hoog contrast ofzo) bij iemand anders.

Als je geel/rood/groen/whatever wil moet je gewoon die kleur nemen. Als je een systeemkleur wil moet je een systeemkleur nemen maar dan niet mouwen als 't in een ander theme niet "mooi" is. Als je een systeemkleur neemt die, toevallig, net de kleur is (of dicht bij de kleur ligt) die je wil hebben kies je 'm om de verkeerde reden De (bijv.) InactiveCaption kleur heet niet voor niets InactiveCaption en die pas je dus beter niet toe op een button en de HotTrack kleur pas je niet toe op een titlebar.

Ha, nee ik snap je precies. Ik had nu met dat stukje in Blend gewoon twee kleuren genomen waarvan ik meende te weten welk objectje er mee gekleurd hoort te worden. Dat ik de desktop backgroundcolor had gevonden, was wel handig. Ik heb daarna gelijk even in Windows de desktopkleur veranderd, en mijn previewtje in Blend (mits ik 'm even run) verandert on the fly mee.

Ik ben er inderdaad ook op uit om de juiste paneelkleuren ook weer toe te passen op vergelijkbare panelen in mijn interface. Ik kies niet de Tooltip-kleur voor mijn hele interface omdat-ie zo mooi geel is. Ik wil dan een 'WindowBackgroundColor' kiezen of iets met soortgelijke naam. Maar dan moet ik wel weten wélke naam bij welk type paneeltje hoort.
Een lijst die me daar al redelijk bij hielp was deze:
http://msdn.microsoft.com...systemcolors_members.aspx

Maar als ik dan naar die namen kijk denk ik: worden die in XP en lager ook al zo genoemd? Ik heb wel eens met grof geweld voor websites met CSS scrollbars zitten stylen (traumatisch, ik probeer het te vergeten ) en dan heb je 3dButtonHighlight enzo, en niet de namen die in bovenstaand lijstje staan.

Daarom hoop ik de juiste namen te vinden, zodat ik zowel in 7, Vista als in XP één dezelfde kleurcode aanspreek. Maar, Blend is geduldig .