[alg] Design principles webapp

[Verwijderd]

Misschien beetje vage topic titel maar ik vroeg me onlangs het volgende af:

Ik merk dat als ik een webapplicatie (CMS bijvoorbeeld) bouw, ik tijdens het maken van het back-end allerlei verschillende trucen uit de kast haal om data zo eenvoudig mogelijk te laten bewerken. Bijvoorbeeld een blog, zou ik een overzicht tonen van alle records met een link naar een overzicht van alle comments per blog. Nu is dit natuurlijk een eenvoudige 1:N relatie, maar op dit moment ben ik een behoorlijk veel complexer back-end aan het bouwen voor een custom site. Hierin komen bijvoorbeeld heel veel verschillende n:m relaties voor, tijdens het denken over "hoe te implementeren" bedacht ik me een aantal verschillende manieren, welke dat zijn doet er niet zo toe en verschilt ook weer per relatie. Wat ik me toen ben af gaan vragen, het lijkt me dat voor dit soort app's (voor zover ik hier over mag spreken bij PHP ) een bepaald aantal "standaard" manieren zijn van data-presentatie en manipulatie. Hoe ga je om met 1:n, hoe ga je om met n:m etc.

Hoe doen jullie dit? Hebben jullie een vaste plek voor naslag hierover? Leren jullie alleen van eerder gemaakte fouten (zoals ik)? Hoe gaat dat...

Mijn gevoel is namelijk dat mijn logica in mn apps soms niet intiutief genoeg is, dat wil zeggen, ik begrijp het zelf nog wel, maar vermoed soms dat de gebruiker zich een beetje gaat afvragen hoe het nou allemaal precies werkt.

Bedankt voor het delen van jullie visie.

[Defector]

Dit is ook waar ik soms mee worstel. Ik ben daarom benieuwd wat hier uitkomt.

Ik heb zelf geen echte standaard aanpak ik doe wat me het beste lijkt per situatie.
Daarom wil ik soms nog wel is hele lappen code herschrijven omdat ik er later wel
is anders tegenaan wil kijken daarom zou het voor mij ook handig zijn als er een richtlijn
of standaard zou zijn.

[orf]

Ik onderscheid eigenlijk twee manieren:
Een applicatie-like interface, met een toolbar, contextmenu's, dubbelklikken, etc
En een web-like interface, met links, delete icons per record, standaard formuliertjes, etc.

Beide manieren hebben voor- en nadelen; een web-like interface is laagdrempelig, maar kan bij intensief gebruik minder vriendelijk zijn; een applicatie-like interface kent moeilijkheden in een browser.

Ik vind in ieder geval dat je gebruiker niet moet merken hoe je dingen op lost in je datamodel; omdat je toevallig een koppeltabel gebruikt voor sommige relaties, moet je gebruiker niet losse records invoeren bij een koppeling (dan kun je ook phpMyAdmin laten gebruiken)

Wij gebruiken ons eigen cms. Dit is gebaseerd op modules; een module heeft elementen. Elementen zijn formulierelementen met een eigen opslagmogelijkheid; zo kun je een checkbox gebruiken voor simpele data, maar ook koppelen aan een andere tabel met een n:m relatie. De interface is door dit cms altijd consistent en eenvoudig uit te leggen.

[xtra]

Pas was ik wat webbased CRM-systemen aan het bekijken en bij de meeste had ik inderdaad het idee dat het PHPMyAdmin met een eigen skin was ;-)

Bij de complexere zaken probeer ik altijd even alle tabellen uit m'n hoofd te zetten en me voor te stellen hoe een interface er in de ideale situatie uit kan zien. Ook ga ik op zoek naar vergelijkbare situaties in (vooral, omdat die vaak wat vriendelijker zijn) desktopapplicaties.

Uiteindelijk krijg je wel wat modelletjes die breed inzetbaar zijn waarbij het nogal uitmaakt of je moet kiezen uit 5 of 500 mogelijkheden.

Inmiddels ben ik zelfs weer een beetje terug bij de old school webapplicatie waarbij ik dan (afhankelijk van de browser) bepaalde extra pagina's vervang door een ajax-oplossing. De uitdaging daarin is dan weer om geen pagina's meer te maken maar beschrijvingen van functionaliteit die je zowel in een pagina als in een ajax 'popup' kunt tonen.

Verder maakt het natuurlijk uit of een applicatie door 100 mensen 1 keer wordt gebruikt of door 1 mens 100 keer. In het eerste geval moet het supersimpel en in het tweede geval super efficiënt.

[Verwijderd]

xtra schreef op dinsdag 19 juni 2007 @ 21:56:

Verder maakt het natuurlijk uit of een applicatie door 100 mensen 1 keer wordt gebruikt of door 1 mens 100 keer. In het eerste geval moet het supersimpel en in het tweede geval super efficiënt.

Dit is een mooie zin, die ik zeker eens zal meenemen in een offerte

[Verwijderd]

Leuk, er is wat feedback op mn uitgangspunt om een soort van discussie hierover te starten.

@Orf, ik begrijp het verschil tussen applicatie-like en web-like interfaces. Vaak is het voor mij echter geen optie om "online" de eerste te gebruiken, het kan natuurlijk allemaal wel, maar wordt vaak wel erg veel client-side code om de gewenste functionaliteit te verkrijgen. Helemaal eens over je statement over het datamodel, dit is eigenlijk de "soul-reason" dat ik hier de vraag heb neergelegd. Soms heb je bijvoorbeeld lastige relaties (n:m) waarbij het echt noodzakelijk is dat de gebruiker elke relatie aan elkaar relateert (oftewel zelf samenstelt), natuurlijk vrij lastig om op een efficiente en eenvoudige manier te presenteren.

@Xtra, je laatste zin, ook al geciteerd door Cheatag is echt een schot in de roos volgens mij. "Gelukkig" heb ik hier met het tweede geval te maken, dus effiicentie is key. Maar hoe op een toch zo gebruiksvriendelijk mogelijke manier te presenteren.

Ik heb nog geen concrete uitspraken gezien van mensen hoe ze nou precies in specifieke gevallen hun ontwerp maken voor een formulier/"interface in het algemeen". Zijn er mensen die hier bij gebruik maken van voor mij nog onbekende standaarden. Zijn deze er uberhaubt en zouden deze er indien dit niet het geval is, eigenlijk niet moeten zijn? Hoe meer je toe kan naar een standaard, algemeen geaccepteerde manier van "presenteren" waardoor de transitie van programma geschreven door X naar programma geschreven door Y zo eenvoudig mogelijk kan verlopen. Ik noem als voorbeeld een registratieformulier voor een website (nothing fancy), er zijn tientallen verschillende methodes die ik sinds m'n carriere op internet heb zien voorbij komen, sommige super, sommige totaal ongebruiksvriendelijk.

[Janoz]

Deze discussie hoort meer in SE&A dan in PRG...

[Hydra]

Zelf heb ik gemerkt dat redeneren puur vanuit de backend meestal er toe leidt dat je op den duur een GUI krijgt die duidelijk vanuit dat standpunt ontwikkeld is, maar voor een gebruiker vaak niet intuitief is. Wat wij dus over het algemeen doen is redeneren vanuit taken. Wat moet een gebruiker doen, en hoe kan dat zo intuitief weergegeven worden.

Dan bouwen we dus een eerste prototype. Prototype 0 is vaak gewoon een screen in Visio welke een beetje de buttons e.d. weergeeft. Proto 1 is een HTML site waar mensen naar kunnen kijken/door heen kunnen klikken maar welke alles simuleert, etc. In samenspraak met de klant wordt dan, vanuit de gebruiker geredeneerd, gekeken hoe het er uit gaat zien. Daarna wordt in het ontwikkeltraject die functionaliteit technisch aangesloten op de backend. Natuurlijk moet dit compatible zijn en zul je een klant moeten sturen, maar dit leidt over het algemeen tot snellere en betere resultaten dan een GUI die juist gebaseerd is op de backend, omdat je dan aan het eind superveel changerequests gaat krijgen omdat de klant het zaakje niet lekker vindt werken.

[Verwijderd]

Als ik je goed begrijp vraag je je af hoe je de data representeert richting de klant. Ik ga er van uit dat je bekend bent met design patterns als ActiveRecord voor je modellen. Het is inderdaad altijd de vraag hoe je je User Interface moet bouwen.

Laat ik een eenvoudig voorbeeld noemen van twee objecten; Book en Category. Even voor het gemak gaan we er van uit dat een Book behoort tot een Category. Hoe je de gebruikers interface weergeeft is afhankelijk van twee dingen; het aantal Books en het aantal Categories.

Denk aan het toevoegen van een Book. Wanneer er slechts 5 Categories zijn is het mogelijk om bij het toevoegen van het boek uit een dropdown menu de juiste Category te kiezen. Wanneer je echter honderden Categories hebt is het wellicht verstandig om de gebruiker eerst naar een Category te laten gaan waaraan hij een Book kan toevoegen. Dit zijn gewoon subjectieve keuzes die je moet maken en het is voor een groot gedeelte gewoon ervaring. Bewerk je modules constant aan de vragen en problemen die klanten ervaren.

Hydra schreef op woensdag 20 juni 2007 @ 13:46:
Zelf heb ik gemerkt dat redeneren puur vanuit de backend meestal er toe leidt dat je op den duur een GUI krijgt die duidelijk vanuit dat standpunt ontwikkeld is, maar voor een gebruiker vaak niet intuitief is. Wat wij dus over het algemeen doen is redeneren vanuit taken. Wat moet een gebruiker doen, en hoe kan dat zo intuitief weergegeven worden.

Mijn ervaring is dat mensen die hiermee ervaring hebben wat meer ervaring zouden moeten opdoen met het structureren van je code. Voor je ActiveRecord modellen maakt het namelijk geen drol uit hoe je de User Interface weergeeft.
Redeneren vanuit taken is goed maar je ActiveRecord modellen worden er niet anders van, hoogstens je Actions die de taken implementeren. Ik geef zelf ook de voorkeur aan een (niet zo strikte) Use Case aanpak. Nadeel hiervan is echter dat het uitvoeren van een taak (Book toevoegen), niets zegt over de daadwerkelijke implementatie van de schermen.

[xtra]

Verwijderd schreef op donderdag 21 juni 2007 @ 11:55:
...
Denk aan het toevoegen van een Book. Wanneer er slechts 5 Categories zijn is het mogelijk om bij het toevoegen van het boek uit een dropdown menu de juiste Category te kiezen. Wanneer je echter honderden Categories hebt is het wellicht verstandig om de gebruiker eerst naar een Category te laten gaan waaraan hij een Book kan toevoegen..
...

Dit kun je dan in de interface wel weer laten afhangen van de taak. Als je veel zaken moet invoeren onder één categorie kan dat prima vanuit de categorie. Moet je iedere keer een andere categorie invullen dan kun je je beter richten op de ideale zoekfunctie voor categoriën. Voor de gevordere gebruiker kan dat eventueel het intikken van de beginletters of zelfs code 12 zijn.