Beste opzet voor een online gallery / webshop met limited ed

[maestrodesigns]

Beste devschuurders,

Ik zit met een bomen - bos probleempje. Ik heb uiteraard wel een en ander aan speurwerk gedaan, maar ik merk dat ik toch te lang uit het wereldje ben... Ik kan niet meer goed genoeg beoordelen of iets wel of niet aan de vraag gaat voldoen.

Wat heb ik nodig:

Een strakke (less is more), robuuste website die functioneert als online 'gallery' waar (o.a.) limited edition kunstreproducties worden aangeboden.

Wat moet het kunnen:

• functioneren als online gallery en mooie plaatjes laten zien van de werken (met een kleine toelichting als oproepbare optie)
• functioneren als volwaardige webshop inc.koppeling met betaalsysteem etc.
• liefst een koppeling leggen met het systeem van de leverancier (degene die de boel gaat drukken)
• counters bijhouden van de hoeveelheid werken die nog beschikbaar zijn en timers van hoelang een werk nog in de verkoop is
• integratie en/of koppeling met social media / instagram / behance / etc.

Technische eisen:

• het moet correct functioneren in elke browser
• het moet er goed uitzien op elk device
• het moet goed performen
• in lijn met het vorige punt: zo clean mogelijk qua code
• de content moet aangepast en beheerd kunnen worden door iemand zonder programmeerkennis

Waar ben ik tot nog toe op uitgekomen:

Wordpress als basis (ik heb hier persoonlijk de meeste ervaring mee en vindt het wel lekker overzichtelijk / eenvoudig mee te werken)
Woocommerce plugin voor het webshop deel (evt inc. Mollie plugin om iDeal e.d. te koppelen) - hier heb ik nog geen enkele ervaring mee, ik baseer me volledig op wat ik gehoord en gelezen heb
Shopkeeper thema (van getbowtied) als basis voor de look en feel - wederom geen ervaring, maar ziet er solide uit en voldoet in basis redelijk aan de vraag

Daarmee ben ik er uiteraard nog niet en ik heb mijn twijfels of het alles gaat kunnen wat ik wil en performen naar wens. Is Wordpress überhaupt de juiste keuze als uitgangspunt?

Uiteindelijk neem ik voor dit hele verhaal een webdesigner (-bureau) in de arm (nog even zoeken naar de juiste specialist), maar ik wil graag eerst helder voor ogen hebben wat ik wil en wat er mogelijk is.

Kunnen jullie mij wellicht verder helpen met wat tips en sturing in de juiste richting? Alvast hartelijk dank!

[JJ93]

Gezien wat het allemaal moet kunnen moet er vrij veel custom code worden geschreven. Kan niet allemaal zomaar met Wordpress en wat plugins. Ook gezien je eis zo clean mogelijk code, en qua design less is more zou ik eerder denken aan een website die van de grond af aan wordt gebouwd met Laravel bijvoorbeeld. Je kunt dan precies laten bouwen wat je wilt.

[Tjolk]

Je noemt performance en zo clean mogelijk qua code, en vervolgens Wordpress en Woocommerce. Dat zijn dingen die haaks op elkaar staan naar mijn mening. Wordpress is één en al spaghetticode en wat ik van Woocommerce heb gezien, is het niet veel beter.

Begrijp me niet verkeerd: ik ben niet anti-Wordpress. Verre van. Het is zeer gebruikersvriendelijk en relatief gemakkelijk naar je hand te zetten. Ik heb er aardig wat websites mee gemaakt. Het is echter wel van belang dat je naast de kracht van Wordpress, óók de beperkingen ziet. Wil je een simpele website voor een blog, wat foto's, nieuws en wat presentatie, eventueel contactformulier, dan is Wordpress helemaal prima.
Wil je meer, dan krijg je vaak al plugin-op-plugin-op-plugin. Dat werkt enerzijds vertragend, anderzijds kom je dan gegarandeerd in de problemen met updates. Wordpress brengt zeer regelmatig updates uit (iets wat ook echt nodig is vanwege beveiliging) en dan moeten de plugins vaak ook bijgewerkt worden. Of er is simpelweg een update van een plugin zelf, los van Wordpress-updates. En als je dan diverse plugins hebt die samenwerken en van elkaar afhankelijk zijn, waarbij plugin X wel bijgewerkt is maar Y nog niet, dan snap je hoop ik wel waar dat fout kan gaan.

Voor wat jij voor ogen hebt, moet je heel veel functionaliteit toevoegen aan Wordpress die er standaard niet is. Je noemt al Woocommerce, maar ook die heeft bijvoorbeeld geen koppeling met jouw leverancier. Ook moet je nadenken over aantallen: heb je enig zicht op het aantal producten dat je in de site wil presenteren en hoeveel orders je verwacht? Dat gaat ook flinke impact hebben op de performance.

Je bent dan ook beter af met iets wat op maat gemaakt is. JJ93 noemt al Laravel als voorbeeld. Prima framework om mee aan de slag te gaan, maar eigenlijk maakt dat an sich niet heel veel uit. CodeIgniter 3 of Yii kan net zo goed, veel relevanter is waar degene die het gaat maken ervaring mee heeft. Als je een goede developer vind die ervaring heeft met CodeIgniter zou ik diegene niet afwijzen omdat jijzelf een ander framework in gedachten hebt. Het framework is een stuk gereedschap van de developer, net als een hamer dat is voor een timmerman. Dat framework ga jij verder in de praktijk niet heel veel van merken, als beheerder is relevant wat er op het scherm komt en welke tools je voorhanden hebt.

Ook noem je dat het "correct moet functioneren op elk device en in elke browser". Nu weet ik vrij zeker dat je Internet Explorer 5 niet zo interessant vind en de eerste iPhone ook niet. Maar vind je Opera Mini bijvoorbeeld wel relevant? En welke oudere IE versies wil je ondersteunen? Denk daar eens over na. Als je dit gaat uitbesteden zal de webdesigner je hierin ook wel adviseren als het goed is, maar het is wel handig dat je vast een beeld vormt van je markt en hoe die naar je website komt.

Voordeel van custom werk is dat het helemaal op maat is: je krijgt wat je nodig hebt, en hebt geen last van wat je niet nodig hebt. Zeker in het kader van performance en cleane code is dat van belang. Nadeel is dat het wel meer tijd en meer geld gaat kosten dan een standaard CMS uit de kast pakken en daar wat plugins tegenaan gooien. Hetgeen je hebt voorgesteld is prima mogelijk met Wordpress/Woocommerce, maar je gaat wel tegen de eerder genoemde problemen aanlopen. Wat dat betreft is het aan jou om een afweging te maken v.w.b. het budget. Je kunt zomaar het dubbele kwijt zijn aan maatwerk t.o.v. Wordpress/Woocommerce.

Je kunt er bijvoorbeeld ook voor kiezen om met een kleine investering te beginnen. Denk aan Wordpress met een gallery (zit er standaard in), en als ze klikken op bestellen, ze doorsturen naar een contactformulier. Dat vraagt meer handwerk, zowel voor het verwerken van de bestelling, de facturatie en het bijhouden van de voorraad op de site. Maar dan kun je met nog geen € 1000,- klaar zijn (minder ook nog wel mocht je willen). Op termijn als je wat geld gaat genereren en je meer orders te verwerken krijgt, kun je dan alsnog de stap maken naar een op maat gemaakt systeem. Heel Woocommerce en handenvol andere plugins laat je dan links liggen, je maakt dan in één keer de stap van "aanwezig en handwerk" naar een goed geautomatiseerd systeem. Onder aan de streep ben je dan natuurlijk duurder uit, maar het maakt de eerste investering een stuk minder risicovol, want kleiner.

offtopic:
Hmm, wilde korte reactie schrijven. Niet gelukt.

[xleeuwx]

Ger schreef op woensdag 10 februari 2016 @ 10:45:
Je noemt performance en zo clean mogelijk qua code, en vervolgens Wordpress en Woocommerce. Dat zijn dingen die haaks op elkaar staan naar mijn mening. Wordpress is één en al spaghetticode en wat ik van Woocommerce heb gezien, is het niet veel beter.

Begrijp me niet verkeerd: ik ben niet anti-Wordpress. Verre van. Het is zeer gebruikersvriendelijk en relatief gemakkelijk naar je hand te zetten. Ik heb er aardig wat websites mee gemaakt. Het is echter wel van belang dat je naast de kracht van Wordpress, óók de beperkingen ziet. Wil je een simpele website voor een blog, wat foto's, nieuws en wat presentatie, eventueel contactformulier, dan is Wordpress helemaal prima.
Wil je meer, dan krijg je vaak al plugin-op-plugin-op-plugin. Dat werkt enerzijds vertragend, anderzijds kom je dan gegarandeerd in de problemen met updates. Wordpress brengt zeer regelmatig updates uit (iets wat ook echt nodig is vanwege beveiliging) en dan moeten de plugins vaak ook bijgewerkt worden. Of er is simpelweg een update van een plugin zelf, los van Wordpress-updates. En als je dan diverse plugins hebt die samenwerken en van elkaar afhankelijk zijn, waarbij plugin X wel bijgewerkt is maar Y nog niet, dan snap je hoop ik wel waar dat fout kan gaan.
[...]

Dat Wordpress per definitie traag is wil ik niet zeggen, dit is afhankelijk hoe de plugins die je gaat gebruiken zijn geschreven. Daarnaast heb ik Wordpress websites al 2 jaar draaien zonder er naar om te hoeven kijken (kwa update's en plugin updates). Daarnaast kan je met caching een TTFB van 80ms hebben (eerste response van server).

Neemt niet weg dat ik voor de eisen zoals hierboven inderdaad naar een andere framework als Wordpress neig omdat dit gewoonweg te veel maatwerk wordt in WP. En zou inderdaad voor Laravel (OctoberCMS) gaan, maar dit is meer omdat het een persoonlijke voorkeur betreft. CodeIgniter of Yii kan net ook maar heb ik dan minder ervaring mee dus zal ik het niet zo snel aan een klant verkopen.

Afhankelijk van wat je budget is zou ik niet alleen een backend developer zoeken maar ook een frontend / designer, ik zie dat je in je eisen namelijk niet alleen koppelingen met API's zijn maar ook frontend skills nodig zijn JavaScript.

Zoals Ger terecht zegt is dit alles een beste investering en als ik dit project aan zou nemen zou ik het niet onder de € 2500 ,- doen (inv. design en API koppelingen). En als dit een probleem is dan zou ik voor een oplossing kiezen die wat meer handwerk verricht.

[maestrodesigns]

Hartelijk dank voor de reacties zover!

Ik had al een licht vermoeden dat ik qua eisen en wensen richting een ander framework en meer maatwerk zou gaan. Wat me vooral weerhield van deze stap / overweging was het (persoonlijke) gebrek aan kennis en ervaring op dit gebied.

JJ93 schreef op dinsdag 09 februari 2016 @ 15:34:
Gezien wat het allemaal moet kunnen moet er vrij veel custom code worden geschreven. Kan niet allemaal zomaar met Wordpress en wat plugins. Ook gezien je eis zo clean mogelijk code, en qua design less is more zou ik eerder denken aan een website die van de grond af aan wordt gebouwd met Laravel bijvoorbeeld. Je kunt dan precies laten bouwen wat je wilt.

Goed punt. Waar ik echter wat huiverig voor ben is het opzetten van een webshop component van de grond af. Hoe garandeer ik zo optimaal mogelijk de veiligheid van mijn kopers? Zowel hun betalingsgegevens als persoonsgegevens. Dat is toch het voordeel van bestaande producten: daar heeft een heel team mensen (i.c.m. een bak gebruikerservaring) nagedacht over hoe ze die veiligheid kunnen waarborgen.

Ger schreef op woensdag 10 februari 2016 @ 10:45:
Je noemt performance en zo clean mogelijk qua code, en vervolgens Wordpress en Woocommerce. Dat zijn dingen die haaks op elkaar staan naar mijn mening. Wordpress is één en al spaghetticode en wat ik van Woocommerce heb gezien, is het niet veel beter.

Ja, daar heb je een goed punt, dit is ook zeker een issue met het gebruik van thema's, plugin's e.d. Je gebruikt over het algemeen maar 20% o.i.d. van de totale functionaliteit, de rest is overbodige ballast. De reden voor het gebruik van de bijvoorbeeld Woocommerce is, zoals ik hierboven beschrijf, het feit dat ik graag gebruik maak van een uitgebreid geteste, relatief veilige omgeving voor betalingen en klantgegevens.

Begrijp me niet verkeerd: ik ben niet anti-Wordpress. Verre van. Het is zeer gebruikersvriendelijk en relatief gemakkelijk naar je hand te zetten. Ik heb er aardig wat websites mee gemaakt. Het is echter wel van belang dat je naast de kracht van Wordpress, óók de beperkingen ziet. Wil je een simpele website voor een blog, wat foto's, nieuws en wat presentatie, eventueel contactformulier, dan is Wordpress helemaal prima.
Wil je meer, dan krijg je vaak al plugin-op-plugin-op-plugin. Dat werkt enerzijds vertragend, anderzijds kom je dan gegarandeerd in de problemen met updates. Wordpress brengt zeer regelmatig updates uit (iets wat ook echt nodig is vanwege beveiliging) en dan moeten de plugins vaak ook bijgewerkt worden. Of er is simpelweg een update van een plugin zelf, los van Wordpress-updates. En als je dan diverse plugins hebt die samenwerken en van elkaar afhankelijk zijn, waarbij plugin X wel bijgewerkt is maar Y nog niet, dan snap je hoop ik wel waar dat fout kan gaan.

Bovenstaand is inderdaad de reden waarom ik over het algemeen naar Wordpress (o.i.d.) neig. Beheer en onderhoud van dergelijke sites is relatief eenvoudig en niet al te arbeidsintensief. Tot nog toe heb ik nooit met al te veel plugins te maken gehad; dus dan vallen de genoemde issues met updates ook wel mee. Ik snap echter zeer zeker je punt aangezien in in de werksfeer ook veel met software, plugins en onderlinge compatibiliteit te maken heb. Kort samengevat een drama af en toe.

Voor wat jij voor ogen hebt, moet je heel veel functionaliteit toevoegen aan Wordpress die er standaard niet is. Je noemt al Woocommerce, maar ook die heeft bijvoorbeeld geen koppeling met jouw leverancier. Ook moet je nadenken over aantallen: heb je enig zicht op het aantal producten dat je in de site wil presenteren en hoeveel orders je verwacht? Dat gaat ook flinke impact hebben op de performance

Correct. Uiteraard zou je dit stap voor stap uit kunnen bouwen en heb je in ieder geval een startpunt om een en ander te lanceren. Het vervelende is dan wel dat je met een beetje pech halverwege het traject je volledige site om zal moeten gooien.
De hoeveelheid producten (een stuk of 4-5 per maand) en aantal orders zullen initieel nog wel meevallen, maar in combinatie met een hoge eis qua beeldkwaliteit zal performance zeker een rol spelen.

Je bent dan ook beter af met iets wat op maat gemaakt is. JJ93 noemt al Laravel als voorbeeld. Prima framework om mee aan de slag te gaan, maar eigenlijk maakt dat an sich niet heel veel uit. CodeIgniter 3 of Yii kan net zo goed, veel relevanter is waar degene die het gaat maken ervaring mee heeft. Als je een goede developer vind die ervaring heeft met CodeIgniter zou ik diegene niet afwijzen omdat jijzelf een ander framework in gedachten hebt. Het framework is een stuk gereedschap van de developer, net als een hamer dat is voor een timmerman. Dat framework ga jij verder in de praktijk niet heel veel van merken, als beheerder is relevant wat er op het scherm komt en welke tools je voorhanden hebt.

Zoals ik al aangaf heb ik te weinig kennis van dergelijke frameworks om hier een oordeel over te vellen. Hoeft niet erg te zijn, daar huur je namelijk iemand voor in, maar ik wil wel duidelijk een beeld hebben van wat ik dan wil en hoe het werkt (mede i.v.m. veiligheid e.d.).

Ook noem je dat het "correct moet functioneren op elk device en in elke browser". Nu weet ik vrij zeker dat je Internet Explorer 5 niet zo interessant vind en de eerste iPhone ook niet. Maar vind je Opera Mini bijvoorbeeld wel relevant? En welke oudere IE versies wil je ondersteunen? Denk daar eens over na. Als je dit gaat uitbesteden zal de webdesigner je hierin ook wel adviseren als het goed is, maar het is wel handig dat je vast een beeld vormt van je markt en hoe die naar je website komt.

Sja, misschien kan ik deze eis wel enigszins afzwakken inderdaad. De meest gebruikte browsers (IE, Firefox, Chrome, Safari en evt Opera) en 1 a 2 versies (max) terug moet initieel voldoende zijn. Mobile devices zijn wel essentieel aangezien een groot deel van de doelgroep via een tablet of smartphone op de site uit zal komen.

Voordeel van custom werk is dat het helemaal op maat is: je krijgt wat je nodig hebt, en hebt geen last van wat je niet nodig hebt. Zeker in het kader van performance en cleane code is dat van belang. Nadeel is dat het wel meer tijd en meer geld gaat kosten dan een standaard CMS uit de kast pakken en daar wat plugins tegenaan gooien. Hetgeen je hebt voorgesteld is prima mogelijk met Wordpress/Woocommerce, maar je gaat wel tegen de eerder genoemde problemen aanlopen. Wat dat betreft is het aan jou om een afweging te maken v.w.b. het budget. Je kunt zomaar het dubbele kwijt zijn aan maatwerk t.o.v. Wordpress/Woocommerce.

De kosten zijn niet eens mijn grootste struikelblok. Eerder de mogelijke risico's (omdat ik niet exact weet waar mogelijke lekken of risico's zitten) en het feit dat ik voor onderhoud en updates e.d. voor een groot deel afhankelijk ben van de bouwer. Dit kan vervelend zijn als dit een eenmanszaakje is en ik tijdens zijn of haar vakantie of als hij of zij ziek is tegen een major problem aanloop. Niet iedere websitebouwer kan overweg met een door iemand anders opgebouwd platform.

Je kunt er bijvoorbeeld ook voor kiezen om met een kleine investering te beginnen. Denk aan Wordpress met een gallery (zit er standaard in), en als ze klikken op bestellen, ze doorsturen naar een contactformulier. Dat vraagt meer handwerk, zowel voor het verwerken van de bestelling, de facturatie en het bijhouden van de voorraad op de site. Maar dan kun je met nog geen € 1000,- klaar zijn (minder ook nog wel mocht je willen). Op termijn als je wat geld gaat genereren en je meer orders te verwerken krijgt, kun je dan alsnog de stap maken naar een op maat gemaakt systeem. Heel Woocommerce en handenvol andere plugins laat je dan links liggen, je maakt dan in één keer de stap van "aanwezig en handwerk" naar een goed geautomatiseerd systeem. Onder aan de streep ben je dan natuurlijk duurder uit, maar het maakt de eerste investering een stuk minder risicovol, want kleiner.

offtopic:
Hmm, wilde korte reactie schrijven. Niet gelukt.

xleeuwx schreef op woensdag 10 februari 2016 @ 11:06:
[...]


Dat Wordpress per definitie traag is wil ik niet zeggen, dit is afhankelijk hoe de plugins die je gaat gebruiken zijn geschreven. Daarnaast heb ik Wordpress websites al 2 jaar draaien zonder er naar om te hoeven kijken (kwa update's en plugin updates). Daarnaast kan je met caching een TTFB van 80ms hebben (eerste response van server).

Neemt niet weg dat ik voor de eisen zoals hierboven inderdaad naar een andere framework als Wordpress neig omdat dit gewoonweg te veel maatwerk wordt in WP. En zou inderdaad voor Laravel (OctoberCMS) gaan, maar dit is meer omdat het een persoonlijke voorkeur betreft. CodeIgniter of Yii kan net ook maar heb ik dan minder ervaring mee dus zal ik het niet zo snel aan een klant verkopen.

Afhankelijk van wat je budget is zou ik niet alleen een backend developer zoeken maar ook een frontend / designer, ik zie dat je in je eisen namelijk niet alleen koppelingen met API's zijn maar ook frontend skills nodig zijn JavaScript.

Zoals Ger terecht zegt is dit alles een beste investering en als ik dit project aan zou nemen zou ik het niet onder de € 2500 ,- doen (inv. design en API koppelingen). En als dit een probleem is dan zou ik voor een oplossing kiezen die wat meer handwerk verricht.

Nogmaals dank voor de reacties, er zitten hele fijne pointers in waar ik mee verder kan.

Ik ga er nog eens hard over nadenken en me alvast wat verdiepen en de do's en don't en can's en cannot's van bijv. Lavarel. Heb ik weer wat te doen om me van het weekend van de straat te houden.

Ik zit op het moment ook te overwegen om initieel voor een bestaand e-commerce platform te kiezen. Daarmee heb ik volgens mij de meeste ingewikkelde zaken en risico's redelijk afgedekt. Om vervolgens in een later stadium voor meer eigen identiteit en custom handige functionaliteiten te gaan. Grootste nadeel van dat soort platforms zijn de relatief hoge maandelijkse kosten.

[xleeuwx]

maestrodesigns schreef op woensdag 10 februari 2016 @ 17:25:Goed punt. Waar ik echter wat huiverig voor ben is het opzetten van een webshop component van de grond af. Hoe garandeer ik zo optimaal mogelijk de veiligheid van mijn kopers? Zowel hun betalingsgegevens als persoonsgegevens. Dat is toch het voordeel van bestaande producten: daar heeft een heel team mensen (i.c.m. een bak gebruikerservaring) nagedacht over hoe ze die veiligheid kunnen waarborgen.

Dit valt juist denk ik wel mee, als je als voorbeeld OctoberCMS pakt (gebasseerd op Laravel -> Symfony 2), heb je ook al een hoop plugins wat je kunt gebruiken maar met de voordeel dat je in de backend gewoon Laravel kunt gebruiken. Daarnaast kan je tests schrijven zodat je zeker weet dat het systeem doet wat het moet doen.

https://octobercms.com/plugin/feegleweb-octoshop

maestrodesigns schreef op woensdag 10 februari 2016 @ 17:25:
De kosten zijn niet eens mijn grootste struikelblok. Eerder de mogelijke risico's (omdat ik niet exact weet waar mogelijke lekken of risico's zitten) en het feit dat ik voor onderhoud en updates e.d. voor een groot deel afhankelijk ben van de bouwer. Dit kan vervelend zijn als dit een eenmanszaakje is en ik tijdens zijn of haar vakantie of als hij of zij ziek is tegen een major problem aanloop. Niet iedere websitebouwer kan overweg met een door iemand anders opgebouwd platform.

Doordat er Laravel gebruikt wordt kunnen er al heel veel ontwikkelaars mee overweg. Daarnaast moet je afdwingen dat de code volgens de PHP-FIG standaard wordt geprogrammeerd.

Dit alles zal in het begin misschien iets extra kosten maar hier zul je later alleen maar van genieten ( je kunt elke ontwikkelaar inhuren, extra functionaliteit er bij is niet veel werk dus kost minder).

Verder is het onzin dat een eenmanzaak mindere maten beschikbaar is als een ontwikkelbureau, vaak is het tegendeel juist waar. Je krijgt daar namelijk ook maar iemand die het voor je doet en als die op vakantie is ben je alsnog de lul of als hij bijvoorbeeld van baan wisselt kost alles 2 a 3 keer zo duur omdat niemand weet hoe de code in elkaar zit .

[ Voor 8% gewijzigd door xleeuwx op 10-02-2016 19:36 . Reden: opschonen teksts :| ]

[Tjolk]

maestrodesigns schreef op woensdag 10 februari 2016 @ 17:25:
Goed punt. Waar ik echter wat huiverig voor ben is het opzetten van een webshop component van de grond af. Hoe garandeer ik zo optimaal mogelijk de veiligheid van mijn kopers? Zowel hun betalingsgegevens als persoonsgegevens.

Dat is in principe onafhankelijk van het framework. De opslag van persoonsgegevens gebeurt in een database, en dat is vrijwel altijd plain text (m.u.v. het wachtwoord en eventuele specifieke andere velden). Dat maakt ook niet uit, zolang je de database maar goed beveiligt. Dat is enerzijds natuurlijk een taak van je hostingbedrijf, anderzijds een kwestie van een goed wachtwoord, juiste rechten, etc.
Natuurlijk moet je er in de applicatie ook voor zorgen dat gebruiker X niet bij de gegevens van gebruiker Y kan, tenzij gebruiker X vanwege zijn rol (bijvoorbeeld beheerder) wel die rechten heeft. Zo'n beetje ieder veel gebruikt framework heeft hier standaard methoden voor om te implementeren voorbeeldje van Laravel. Dat moet ook wel, want 9 van de 10 webapplicaties hebben gebruikersmanagement nodig, al is het maar om onderscheid te maken tussen technisch beheer en content beheer.

Zoals ik al aangaf heb ik te weinig kennis van dergelijke frameworks om hier een oordeel over te vellen. Hoeft niet erg te zijn, daar huur je namelijk iemand voor in, maar ik wil wel duidelijk een beeld hebben van wat ik dan wil en hoe het werkt (mede i.v.m. veiligheid e.d.).

Door de bank genomen kun je wel aannamen dat ieder framework wat nog steeds onderhouden wordt, open source is en al een paar jaar op de markt is, veilig is opgezet. Er wordt door duizenden developers mee gewerkt, dus als zij ergens tegenaan lopen dan komt dat vanzelf boven drijven. Geen garantie natuurlijk dat er nooit iets fout zit, maar dat geldt eigenlijk altijd. Het is niet voor niets dat ook grote jongens als Apple, Facebook en Adobe nog af en toe in het nieuws komen met beveiligingslekken.

Wat je ook niet moet vergeten: een framework als Laravel, CI, Yii, etc. is alleen maar een fundament. Nadat je het hebt geïnstalleerd heb je nog helemaal niets, behalve wat tools die het leven van de developer een stuk gemakkelijker te maken. De developer moet zelf een database model maken, code schrijven die tegen de database aanpraat, controllers en views maken, etc. Daarvoor kan hij vaak putten uit bestaande code, maar hij is degene die de keuzes moet maken en dus ook degene die bepaalt hoe veilig, snel, flexibel en degelijk de applicatie wordt. Je kunt met al deze frameworks fantastische applicaties bouwen maar ook gegarandeerde rampen, terwijl het voor de buitenstaander gelijkwaardig is.

In die zin blijf ik bij mijn eerdere opmerking: het gebruikte framework is ondergeschikt aan de kwaliteit van de developer. Ga niet eisen dat hij gebruik maakt van framework X; als hij al jaren met framework Y of Z werkt zal hij daar betere applicaties mee maken. En jij als klant zal in de praktijk toch niets merken van het gebruikte framework.

Sja, misschien kan ik deze eis wel enigszins afzwakken inderdaad. De meest gebruikte browsers (IE, Firefox, Chrome, Safari en evt Opera) en 1 a 2 versies (max) terug moet initieel voldoende zijn. Mobile devices zijn wel essentieel aangezien een groot deel van de doelgroep via een tablet of smartphone op de site uit zal komen.

Niet om lullig te doen, maar ik mis hier bijvoorbeeld Edge, een compleet nieuwe browser die tegenwoordig wel de standaard is in Windows en inmiddels een stuk meer gebruikt van Opera. En IE 9 (=2 versies terug) wordt nog maar nauwelijks gebruikt, dat zie je met name nog bij gesloten overheids/banksystemen. Terwijl juist oudere IE versies vaak een bottleneck zijn, en niet de zoveelste browser die op Webkit/Blink is gebaseerd (zoals Opera bijvoorbeeld).

De kosten zijn niet eens mijn grootste struikelblok. Eerder de mogelijke risico's (omdat ik niet exact weet waar mogelijke lekken of risico's zitten) en het feit dat ik voor onderhoud en updates e.d. voor een groot deel afhankelijk ben van de bouwer. Dit kan vervelend zijn als dit een eenmanszaakje is en ik tijdens zijn of haar vakantie of als hij of zij ziek is tegen een major problem aanloop. Niet iedere websitebouwer kan overweg met een door iemand anders opgebouwd platform.

Dat geldt eigenlijk altijd, onafhankelijk van een eenpitter of een bureau. Een eenpitter is vaak meer gedreven/betrokken, zals xleeuwx al aangeeft, maar wel een single point of failiure: als hij onder een bus komt is het ook gedaan. Iemand die bij een development bureau werkt trekt echter om 17:00 uur de deur achter zich dicht en smijt zijn telefoon in een lade als hij op vakantie gaat. En zeker als die persoon veel maatwerk heeft geleverd - net hetgeen waar het grootste risico op fouten zit - dan moet een collega ook heel veel tijd investeren voordat het is opgelost.

Bottom line is wel: als je een goede developer hebt, documenteert hij zijn code goed, zowel inline als in een document. Maar ook dat is heel erg afhankelijk van de persoon/het bedrijf. Maar als jij eist dat het goed gedocumenteerd is dan is het vaak wel redelijk overdraagbaar.

[xleeuwx]

Kan natuurlijk ook altijd een code review laten doen door een ander bedrijf. En kan als voorwaarde stellen dat de code gemaakt in het bezit van jou komt. Dit soort dingen willen nog wel eens een probleem zijn na de aflevering van de software.

[Boelie-Boelie]

Wanneer je met een wensenlijstje aankomt bij een developer, zul je vaak horen dat in principe van alles kan, maar dit of dat duurt langer/korter, is ingewikkelder/eenvoudig, duurder/goedkoper. In dit topic zie ik maar weinig nadruk op de vraag of die eisen überhaupt nodig zijn voor je bedrijfsdoelen, of op die manier moeten worden ingevuld (loop je momenteel tegen logistieke problemen aan waardoor je die eisen stelt?) en wat voor prioriteit het heeft (kan het ook in fasen?).

Veel projecten met een focus op allerlei technische features eindigen met zaken die ook door een procesverandering opgelost hadden kunnen worden, die teveel tijd/geld kosten voor wat het oplevert, die geen echt probleem oplossen, die opgedeeld hadden kunnen worden in afzonderlijke oplossingen per onderdeel, waar in een latere fase een oplossing verzonnen had kunnen worden, etc. En het is vaak pas later klaar dan je had gewild, want 'o ja dit en dat moet er nog bij'.

Als je nog geen ervaring in e-commerce hebt, zou ik eerst eens proberen met - zoals je zelf zegt - een bestaand platform (Shopify misschien?) en kijken of dat van de grond komt. Denk je na een jaar 'loopt lekker' en je hebt het gevoel dat je huidige oplossing te beperkt is, kun je altijd nog eentje laten bouwen. Bijkomend voordeel is dat je na dat jaar beter weet wat belangrijk is aan een webshop. En je hebt een indicatie voor je budget (geen nut om veel te investeren bij kleine aantallen).

Want zodra een webshop er staat, begint het werk pas: zorgen dat er genoeg kopers (blijven) komen om de investering in je nieuwe initiatief te rechtvaardigen. Daar gaat een hoop tijd (en misschien wel geld) in zitten.

[maestrodesigns]

xleeuwx schreef op woensdag 10 februari 2016 @ 19:34:
[...]

Dit valt juist denk ik wel mee, als je als voorbeeld OctoberCMS pakt (gebasseerd op Laravel -> Symfony 2), heb je ook al een hoop plugins wat je kunt gebruiken maar met de voordeel dat je in de backend gewoon Laravel kunt gebruiken. Daarnaast kan je tests schrijven zodat je zeker weet dat het systeem doet wat het moet doen.

https://octobercms.com/plugin/feegleweb-octoshop


[...]

Doordat er Laravel gebruikt wordt kunnen er al heel veel ontwikkelaars mee overweg. Daarnaast moet je afdwingen dat de code volgens de PHP-FIG standaard wordt geprogrammeerd.

Dit alles zal in het begin misschien iets extra kosten maar hier zul je later alleen maar van genieten ( je kunt elke ontwikkelaar inhuren, extra functionaliteit er bij is niet veel werk dus kost minder).

Verder is het onzin dat een eenmanzaak mindere maten beschikbaar is als een ontwikkelbureau, vaak is het tegendeel juist waar. Je krijgt daar namelijk ook maar iemand die het voor je doet en als die op vakantie is ben je alsnog de lul of als hij bijvoorbeeld van baan wisselt kost alles 2 a 3 keer zo duur omdat niemand weet hoe de code in elkaar zit .

Ik ben me ondertussen een beetje aan het inlezen over OctoerCMS, octoshop en aanverwante producten. Sowieso interessant leesvoer.

'Afdwingen' van standaarden is wel een goeie en ook wel iets waarvoor ik bereid ben te betalen. Op de lange termijn leveren dergelijke investeringen bijna altijd wel meerwaarde.

Ten slotte hebben jullie uiteraard een punt wat betreft de eenpitters tegenover ontwikkelbureaus; je krijgt zelden de garantie dat er een heel team aan specialisten klaar staat die elkaar zonder probleem kunnen vervangen. Belangrijkste blijft dat je een klik moet hebben met de persoon / partij denk ik.

Ger schreef op donderdag 11 februari 2016 @ 09:15:
[...]

Wederom een paar goede punten die ik zeker ter harte zal nemen. En je hebt gelijk, alles valt of staat bij de kwaliteit van de developer. Daar ligt ook gelijk de grootste uitdaging. Het is straks aan mij om bij het aanvangen van dit project een keuze en een eerste inschatting te maken van de persoon / personen die mij hiermee kunnen helpen. Daarin helpt de feedback die ik hier heb ontvangen al een heel eind. Ik heb een hoop pointers gekregen waarmee ik weer wat verdere research kan doen en waarmee ik uiteindelijk voor mezelf een beter beeld kan vormen van wat ik nu eigenlijk wil.

xleeuwx schreef op donderdag 11 februari 2016 @ 14:46:
Kan natuurlijk ook altijd een code review laten doen door een ander bedrijf. En kan als voorwaarde stellen dat de code gemaakt in het bezit van jou komt. Dit soort dingen willen nog wel eens een probleem zijn na de aflevering van de software.

Ook wel een goed punt om in acht te nemen. Ik ga initieel altijd uit van de welwillendheid en betrokkenheid van de developer, maar tegelijkertijd kun je potentiële problemen altijd beter voorkomen door heldere afspraken te maken.

Boelie-Boelie schreef op donderdag 11 februari 2016 @ 15:21:
Wanneer je met een wensenlijstje aankomt bij een developer, zul je vaak horen dat in principe van alles kan, maar dit of dat duurt langer/korter, is ingewikkelder/eenvoudig, duurder/goedkoper. In dit topic zie ik maar weinig nadruk op de vraag of die eisen überhaupt nodig zijn voor je bedrijfsdoelen, of op die manier moeten worden ingevuld (loop je momenteel tegen logistieke problemen aan waardoor je die eisen stelt?) en wat voor prioriteit het heeft (kan het ook in fasen?).

Veel projecten met een focus op allerlei technische features eindigen met zaken die ook door een procesverandering opgelost hadden kunnen worden, die teveel tijd/geld kosten voor wat het oplevert, die geen echt probleem oplossen, die opgedeeld hadden kunnen worden in afzonderlijke oplossingen per onderdeel, waar in een latere fase een oplossing verzonnen had kunnen worden, etc. En het is vaak pas later klaar dan je had gewild, want 'o ja dit en dat moet er nog bij'.

Deze vragen heb ik mezelf ook al gesteld. Ik ben er van overtuigd dat alle eisen / wensen van meerwaarde kunnen zijn voor het eindresultaat. Vandaar dat ik de belangrijke beslissingen, zoals de keuze van het gebruikte framework, probeer te baseren op het volledige eisenpakket. Uiteraard zit er een bepaalde prioritering achter het wensenlijstje en zal ik vast her en der keuzes moeten maken voor optie A of optie B op naar een optimaal eindresultaat te komen. Ik realiseer me ook dat de beginsituatie niet overeen zal komen met de gewenste eindsituatie. Sowieso ben ik groot voorstander van opbouwen in fasen. Hiermee kun je eerst zorgen voor een stabiele basis waarin de 'essentials' worden meegenomen om vervolgens stap voor stap uit te breiden met gewenste extra functionaliteiten.

Als je nog geen ervaring in e-commerce hebt, zou ik eerst eens proberen met - zoals je zelf zegt - een bestaand platform (Shopify misschien?) en kijken of dat van de grond komt. Denk je na een jaar 'loopt lekker' en je hebt het gevoel dat je huidige oplossing te beperkt is, kun je altijd nog eentje laten bouwen. Bijkomend voordeel is dat je na dat jaar beter weet wat belangrijk is aan een webshop. En je hebt een indicatie voor je budget (geen nut om veel te investeren bij kleine aantallen).

Want zodra een webshop er staat, begint het werk pas: zorgen dat er genoeg kopers (blijven) komen om de investering in je nieuwe initiatief te rechtvaardigen. Daar gaat een hoop tijd (en misschien wel geld) in zitten.

Deze optie zit ik ook nog steeds serieus te overwegen. Ik heb inderdaad nog niet al te veel ervaring op dit gebied en het maakt een aantal zaken enorm eenvoudig. Enige nadeel is het gemis van een aantal zeer gewenste functionaliteiten, maar dat is een kwestie van de diverse aanbieders vragen naar de mogelijkheden en vervolgens alles even rustig naast elkaar zetten en een kleine 'business case' maken.

Ik denk dat ik voorlopig weer een eind verder kan komen. (wederom) Hartelijk dank voor de diverse reacties. Als ik zo ver ben zal ik zeker even een oproepje plaatsen in het V&A forum.

[ Voor 17% gewijzigd door maestrodesigns op 15-02-2016 19:51 ]