[C# winforms workflow]User interface implementatie

[D4Skunk]

Momenteel heb ik bij enkele klanten een zeer flexibele ui draaien. De schermen/dropdowns etc worden volledig dynamisch opgebouwd adhv de meta-gegevens van de database. (link oude blog). Het grote voordeel is dus dat ALLE functionaliteit voor de klanten strikt gescheiden blijft van het framework. Menu zit in een aparte dll (=plugin) specifiek voor elke klant. Bij wijziging van functionalitiet (bv exporteer grid naar excel) kan ik deze dus bij al m'n klanten zonder veel poeha implementeren.

Wat is nu het grote probleem : het ontbreken van een workflow engine om bv een nieuwe verzekering toe te voegen; als gebruikers in verschillende tabellen iets moeten wijzigen, loopt men het risico iets te vergeten (concreet : nieuwe blog).
Nu sta ik voor een paar punten waar ik graag jullie mening over zou hebben :

Momenteel werk ik met een soort module die een propertybag aanmaakt adhv de metagegevens in de db, die ik rechtstreeks kan gebruiken in een propertygrid (met dropdowns, nullable types,...
Ik zeg dus gewoon : die tabel, dat veld, en de rest gebeurt automatisch. Het grote voordeel is natuurlijk de flexibiliteit van zo'n systeem.... Write once, use everywhere...
Doordat de interface steeds uniform is, ontstaat er bij de gebruikers geen verwarring...

Ik dacht dus zo'n soortgelijk systeem te ontwerpen met wizards, gestuurd door XML-files voor de bedrijfsprocessen. Maar nu kom ik bij het volgende probleem :Wat moet er gebeuren wanneer een gebruiker meerdere records moet aanmaken voor een bepaald gedeelte.... (vb order/orderlijnen)
A. per orderlijn nieuwe wizard opstarten
B. per orderlijn een knop voorzien "nog een orderlijn toevoegen" naast de "Next" knop
C. de gebruikers een grid geven waar ze naar hartelust orderlijnen kunnen ingeven
D. Geen wizard gebruiken, en links een Pane voorzien waarop men in realtime ziet wat er al gebeurd is, en wat niet (links zou men dan verzekerde, order en orderdetails te zien krijgen in een html-achtige opmaak, waar men dan terug kan op klikken om naar de desbetreffende geg te gaan..)

A lijkt me al direct niet aan te raden
Ik twijfel eigenlijk vooral tussen een combinatie van B en C, of D.
D zou zeker en vast het minste werk met zich meebrengen...

Ik wil sowiezo de onafhankelijkheid bewaren, dus kom alsjeblieft niet af met "programmeer gewoon een paar wizard forms...", want dan moet ik bij wijziging van de structuur van de db dlls gaan hercompileren, en dat wil ik nou net niet

Een tweede vraag : bestaat er al zo'n gelijkaardig systeem ? ik ben het nog nergens tegengekomen (geen vgl met access e.d.; deze tonen de gebruikers nl niet rechtstreeks de relaties van de gegevens, of er komt programmeerwerk bij kijken).

Alle input is welkom...

[The Lord]

Microsoft heeft binnen hun "Patterns & Practices" program een modulair UI beschikbaar gesteld als 'application block'. De exacte naam kan ik me nu niet herinneren. Even zoeken op de MSDN en 'Patterns & Practices' sites dus.

En de link hier natuurlijk even posten voor mede Tweakers.

[ Voor 9% gewijzigd door The Lord op 03-06-2004 23:17 ]

[GrimaceODespair]

Het meest interessante is natuurlijk D Voor de andere opties valt natuurlijk ook allemaal wat te zeggen, en ik denk dat de keuze dan ook persoonlijk zal zijn (tenzij iemand het misschien met wat HCI kan onderbouwen?).

Mocht ik het moeten doen, dan zou ik voor B gaan. Dan heb je geen gezeik met dat grid (C), niet te veel extra werk (D) en is het niet ongebruiksvriendelijk (A).

[D4Skunk]

[quote]The Lord schreef op 03 juni 2004 @ 23:17:
Microsoft heeft binnen hun "Patterns & Practices" program een modulair UI beschikbaar gesteld als 'application block'. De exacte naam kan ik me nu niet herinneren. Even zoeken op de MSDN en 'Patterns & Practices' sites dus.
quote]

Waarschijnlijk deze : User Interface Process (UIP) Application Block - Version 2.0

Ga deze even bestuderen...

[MaxxRide]

Ik zou voor D gaan, alleen ik weet niet of je ook zaken wil checken (een order zonder orderlijn, heeft dat zin/ mag dat?).

Mensen zijn zo gewend aan aan de linkerkant een explorer dat dat geen probleem oplevert. Die wizard ervaren mensen toch vaak als onoverzichtelijk (stel je bedenkt je later en wilt de naam in de order veranderen, wat doe je dan? Druk je op "terug" en laat je alle al ingevoerde data staan of moet dit achteraf?).

[D4Skunk]

Ok, ik weet dat dit al een oud topic is, maar ik wil jullie niet van het antwoord ontzien. Mocht er in de toekomst iemand met gelijkaardige problemen zitten, kan hij/zij in de toekomst hier misschien inspiratie op doen.

Na het doc van M$ Microsoft bestudeerd te hebben, heb ik een paar testcases ontwikkeld mbt tot de "wizards/overzichten"
Na dit voor te leggen aan de gebruikers, bleek dit uiteindelijk absoluut NIET duidelijk te zijn. Terug naar af dus....
Ik was hier al een tijdje over aan het aanmodderen, toen ik in outlook xp enkele mails aan het checken was, en toen 'viel mijn frank' (=eureka voor niet-Belgen) : een eenvoudige task list is het simpelste, gezien het ook om eenvoudige workflows gaat.

Een voorbeeld (bij deze klant wordt de applicatie gebruikt voor wagenparkbeheer):
Wanneer een user een Wagen toevoegt, komt er automatisch in zijn takenlijst :
- [Wagen ??????] ingeven opties
- [Wagen ??????] ingeven contract
Waarbij de vraagtekens natuurlijk vervangen worden door relevante gegevens

Bij het klikken op één van die lijnen komt de gebruiker automatisch op de respectievelijke gegevens terecht, wannier hij bv op de eerste v/d hierbovengenoemde lijnen zou klikken, krijgt hij automatisch bovenaan in het scherm enkel de wagen ?????? te zien, en daaronder het optie-grid.

Deze functionaliteit is vervolgens uitgebreid, en biedt nu ook de volgende mogelijkheid:
Gebruikers kunnen zelf tabellen, een record of gefilterde records markeren als todo, en hier hun eigen omschrijving aan geven.

NU NOG VLUG DIT IDEE PATENTEREN

Alweer niet onbelangrijk : er zit geen custom code in het hoofdprogramma, alle client-specific code zit in de dll.
Hiervoor heb ik de plugin-structuur een beetje aangepast, met 2 extra zaken :
- in de plugin-dll kan (moet dus niet) er een functie TRIGGER geïmplementeerd worden, die triggert bij insert/update/delete
- in de plugin-base-class is de interface voorzien om taken toe te voegen.

[shameless plug]

Tot slot een screenshot van het programma in actie, hier gebruikt voor wagenparkbeheer. (Ben er best wel trots op )

Opm: weerspeigelt niet originele kleuren; het gele is de 'windows-grijs-benadering' van het GIF-formaat in M$ Microsoft Paint


(Clickable)
[/shameless plug]

Tot slot nog 1 belangrijk voordeel :
Bij het ingeven van gegevens ontbreken er soms nog documenten, waardoor niet alles kan ingegeven worden... Gezien het feit dat de taken opgeslagen worden, maakt dit dus niks meer uit.

Zo zie je maar, het probleem van de meeste ICT-ers is ook op mij van toepassing : de oplossing veel te ver gaan zoeken. Mocht ik deze oplossing direct geïmplementeerd hebben, had deze mij dagen werk uitgespaard...

Modbreak:
Het bedrijf waar Steve Ballmer CEO is heet Microsoft en kort je af met MS. Termen zoals bijvoorbeeld M$ en Mickeysoft zijn enkel kinderachtige verbasteringen en voegen niets toe. Laat dit dus achterwege vooraan

[ Voor 18% gewijzigd door gorgi_19 op 13-08-2004 13:05 ]