Leon Vosmeijer

Wanneer je je statistieken baseerd op cookies zijn je statistieken alles behalve compleet. Wat gebeurd er nu als ik ,elke keer wanneer m'n browser start, standaard mijn cookies verwijder (wat ik dus doe). Dan zou het betekenen dat jou statistieken helemaal niet kloppen. De reden dat Google Analytics cookies gebruikt is om de load te verminderen en om die reden is de data opgeslagen in cookies dus simpelweg helemaal niet waardevol. De gegevens zijn tenslotte al bekend bij Google...

Technisch verhaal: Cookies worden door heel veel websites (Lees: programmeurs van heel veel websites) op een compleet verkeerde manier gebruikt. Als jij op basis van cookies statistieken genereerd, dan kloppen je statistieken voor geen meter. Het gebruik van cookies kan je zelf zo goed als geheel uitsluiten. Ontopic: trek er niet te zwaar aan. Er was toen ook onwijze ophef over de regel die in 2002 is opgezet voor het plaatsen van de tekst. Eenmaal ingevoerd wordt er op geen enkele wijze gecontroleerd of dit ook daadwerkelijk gebeurd op de websites die cookies gebruiken.

Hallo Matthias, Voorop gesteld dat ik persoonlijk echt een ontzettende hekel heb aan intro's op websites, is een oplossing voor dit probleem het gebruik van cookies inderdaad. Let er alleen wel op dat cookies bij de gebruiker op de computer worden achter gelaten. Deze gebruikers kunnen dus ook deze cookies weer verwijderen, wat de gebruikers weer vrolijk terug brengt op de homepage. Ook wanneer dezelfde gebruikers met een andere browser de website bekijken, komen ze gewoon weer op de homepage uit, omdat de cookie niet beschikbaar is in de browser. Laat staan wanneer een gebruiker een ander systeem gebruikt... Even ruimer denken: Is het van belang dat de gebruiker voorafgaand aan de bestelling hun gegevens achter laten of is het van belang deze gegevens te hebben wanneer de gebruiker de bestelling daadwerkelijk gedaan heeft? Voor mij persoonlijk zou het een ontzettende drempel zijn om eerst m'n gegevens achter te laten en vervolgens pas verder te gaan met de website. Ik zou dit dus ook automatisch niet doen.

Ik denk dat ik begrijp wat je bedoeld, maar dat het verkeerd verwoord is... Zorg ervoor dat er geen image HTML tags in de header tags geplaatst worden. Dit is voor de meeste zoekmachines niet te lezen. Headers kunnen dus wel voorzien worden van een image, mits de juiste techniek hiervoor gebruikt worden, waardoor de search engines er geen last van hebben. PS: JS is hiervoor de minst geschikte oplossing.

Ik denk dat ik begrijp wat je bedoeld, maar dat het verkeerd verwoord is... Zorg ervoor dat er geen image HTML tags in de header tags geplaatst worden. Dit is voor de meeste zoekmachines niet te lezen. Headers kunnen dus wel voorzien worden van een image, mits de juiste techniek hiervoor gebruikt worden, waardoor de search engines er geen last van hebben.

Hoewel ik geen voorstander ben van Flash apps (I.v.m. usability, accessability etc.) is de uitwerking van de website vrij aardig. Ik vind het niet vervelend om naar de website te kijken. Merk hierbij wel op dat ik echt een leek ben op het gebied van design. Vanuit technisch oogpunt vind ik de afwerking van de boxjes (Zie afbeelding hieronder) slordig. Dit is wellicht nog wel op te lossen. Ook de outlines op links vind ik persoonlijk heel lelijk. Dit verschilt echter van persoon tot persoon. Toevoeging: De mogelijkheid om een Shirt in je winkelwagen te plaatsen, wordt overal weergegeven. Toch is het niet mogelijk het in de winkelwagen te plaatsen, wanneer niet alle 'stappen' zijn voltooid. Waarom dan "In winkelwagen" overal weergeven?

Grappig eigenlijk dat een goede oplossing meestal direct onder je neus ligt, zonder dat je het doorhebt.

Aangezien de PSP wel degelijk iets gedaan heeft zou ik verwachten dat ze daarvoor gewoon hun commissie / percentage krijgen. Wat zeggen de voorwaarden van de PSP zelf? Inderdaad. De PSP heeft gedaan waarvoor de PSP is ingeschakeld. De werking van de webwinkel en de PSP (Ogone in dit geval gok ik) zijn twee losstaande onderdelen. De PSP verwerkt online betalingen en verder niks. De PSP heeft er dus niks mee te maken wanneer een product retour gestuurd wordt.

Was dat sommetje wel zo simpel? ;) Ongeacht of het sommetje wel of niet goed opgeschreven is, ben ik wel op zoek naar dit soort reacties van de 'gemiddelde' internet gebruiker. Bedankt Manon!

Ik ben meer op zoek naar een gebruiksvriendelijk oplossing. Wat dat betreft heb ik liever de 'minder technische mensen' die de post bekijken [edited]

Het nadeel van deze oplossing is alleen dat de meeste bots tegenwoordig ook kijken naar de stylesheets - de bots worden immers ook vrolijk geupdate met de nieuwste technieken - en een display:none of een visibility:hidden ook zien en die secties overslaan... Toch vind ik het zelf ook een chique oplossing

Iedere webdeveloper heeft er ooit wel eens mee te maken gehad: online (spam)bots. Bij het ontwikkelen van web projecten moet er tegenwoordig rekening worden gehouden met de mogelijkheid dat bots* open formulieren volgooien met berichten. Er zijn tegenwoordig al een aantal projecten die dit proberen tegen te gaan. Een goed voorbeeld van zo'n project is een captcha. Een reactie test (doorgaans met behulp van een dynamische gegenereerde image) om te controleren of de gebruiker daadwerkelijk een mens is. De problemen met dit soort projecten is dat de implementatie van dit soort methoden ervoor zorgt dat de usability en de accessability van de web applicatie hier dramatisch mee wordt aangetast. Voor een geoptimaliseerde website is dit dus dodelijk. Ik zou graag jullie graag willen vragen aan te geven welke methoden (het liefst met voorbeelden) jullie het beste vinden of het best vinden werken. Wellicht dat er goede en gebruiksvriendelijk vormen van captcha beschikbaar zijn. *: voor de niet-technici onder ons: geautomatiseerde software, welke alle websites in de wereld proberen (!) af te gaan om daar hun boodschap (veelal internet addressen voor indexering of verkoop) achter te laten

Het laten ontwikkelen van een compleet forum is flink wat werk. Een forum is de absolute koploper die de statement "Je kan het zo gek maken als je wilt" onderstreept! Mocht je een forum willen laten ontwikkelen, zal je van te voren echt precies moeten uitzoeken welke functionaliteiten je in je forum wilt hebben. Het beste is dan ook om een totaal prijs af te spreken met de ontwikkelaar, maar geloof me... dit gaat niet goedkoop worden.

Wat ik ervan begrepen heb is dat de totaalprijs van de bestelling in een hidden input field werd gezet midden in de HTML. Dit is een vrij grove fout. Om die reden vind ik ook, dat niet de studenten het 'misgelopen' geld moeten terugbetalen, maar de ontwikkelaars van de betalingsmodule dit moeten doen. Even voor de record: Dit is mijn mening. Ik weet zelf ook wel dat de ontwikkelaars zichzelf beschermen na oplevering. Ik doe dat zelf tenslotte ook! Geen van beide komen van mij, maar ik ben eht er wel mee eens dat de tool in dit geval vrij irrelevant was. Dit was geen configuratie- of infrastructureel probleem, maar gewoon een brak geprogrammeerde shopping cart. Dat has geen Nessus eruit gehaald, auto of gewoon. Het onderwerp van dit topic is "Laat hackers je betalingssysteem testen". Als Melchior vervolgens verwijst naar een bedrijf die dit actief doet, is het juist wel relevant.

Ondertussen moeten ook andere facturen uitgeschreven kunnen worden inderdaad. Dat zal in het voorbeeld dus zijn: 20090002 20090003 etc etc etc Deelfactuur voor 20090003 zouden dus zijn: 20090003-01 20090003-02 etc Als ik nu kijk naar Artikel 35a van de wet op de omzetbelasting (alhier) staat er hetvolgende: Opeenvolgend nummer, met één of meer reeksen. Volgens mij is het voorbeeld dus gewoon correct of sla ik nu compleet de plank mis?

Ik merk op dat m'n post niet geheel duidelijk is. Ik bedoel betalingen in termijnen van 1 en dezelfde klant, voor 1 uitgevoerd project.

Goedemiddag HL'ers, Ik ben op dit moment bezig met de ontwikkeling van een systeem, waarin facturen e.d. bijgehouden kunnen worden (Voordat er mensen komen die roepen dat dit al bestaat... daar gaat deze post niet over!). Nu ben ik op het punt aangekomen waar ik de functionaliteit voor deelfacturen aan het ontwikkelen ben. De bedoeling is om dit op de volgende manier te doen (uitgaand van factuurnummer: 20090001): Deelfactuur Factuurnummer Bedrag Uitgifte datum 1 20090001-01 129.00 16-10-2009 2 20090001-02 129.00 01-11-2009 3 20090001-03 129.00 15-11-2009 Ik wil graag weten of dit een logische manier is van uitgeven en (eventueel) hoe anders te doen. Jullie eigen ervaringen zijn natuurlijk welkom! Groeten, Leon

Hallo Karen, Ik ben het met seb eens over de technische- en grafische werking. Zoals seb schreef, is het creëren van mooie URL's een begin voor het SEO gebeuren. Ik ben echter bang dat er wel flink wat meer aangepast mag/moet worden aan de website, voordat deze goed geïndexeerd kan gaan worden door de SE's. - Optimalisatie XHTML/CSS en de structuur van de website - Ervoor zorgen dat je website enkel vanaf 1 (sub)domeinnaam te bereiken is, bijvoorbeeld alleen via: www.petspassion.nl. Wanneer mensen 'petspassion.nl' invoeren, ze automatisch naar 'www.petspassion.nl' gaan. - Linkbuilding Groeten, Leon

Hm dus een paar honderd links van verschillende sites maar eenzelfde IP zorgt volgens jou voor geen problemen ? Ik denk er anders over maar meningen kunnen verschillen ;D Dave Leuk voorbeeld om dit even goed neer te zetten zijn de websites van de NPO (Die websites die allemaal die moeilijk irritante balk hebben bovenaan de website, zoals: www.nederland1.nl). Alle websites (inclusief subprojecten, kleine projecten en projecten die nooit het daglicht zullen zien) draaien op hetzelfde platform en maken gebruik van deze proxy. Hoewel de proxy meerdere IP adressen beslaat, zijn er toch een groot aantal die via hetzelfde IP adres verbinding met jou (en dus ook met een botje) maakt.... Ook deze websites worden correct geïndexeerd door dezelfde websites op dezelfde platformen. Tikkie offtopic: ik vind startpagina en de dochters stom

Bij shared hosting platformen is er geen enkel probleem met SEO bij google. Natuurlijk wordt er rekening mee gehouden, maar dit zal geen groot effect hebben op de genoemde platformen... Seb kwam net met dit topic naar me toe en ik moet zeggen dat ik er eigenlijk wel behoorlijk in geïnteresseerd ben. Natuurlijk heeft google al enige tijd geleden de SEO 'handleiding' (Lees: richtlijnen) uitgebracht waarin wordt uitgelegd hoe je ervoor kan zorgen dat een website het beste geïndexeerd wordt. Toch wordt er nergens echt uitgelegd waarom en hoe de resultaten tot stand komen. Tijdens mijn (vlugge) zoektocht door google en de dev blogs, kwam ik echter wel weer het filmpje uit 2007 van Matt Cutt (Software engineer bij Google) tegen: Hierin verteld Matt dat Google zelf ook de resultaten van een bepaalde pagina 'manipuleert', zodat de gebruikers van Google de beste resultaten te zien krijgen.

Bedankt voor de info. Ik was hiervan nog niet op de hoogte.

@Aljona Je hebt niet per se een PSP nodig om iDEAL te koppelen aan je webshop. Dit kan je gerust direct via je eigen bank aanvragen (Toch biedt niet elke bank dit aan). Edit: Ik had de reactie van Joorit K over het hoofd gezien. Voor wilcor zelf: Het komt bij mij over dat je op zoek bent naar een alles-in-een oplossing. Hiervoor heb je zelf al ogone genoemd. Een goed alternatief voor Ogone is het voormalige TripleDeal (Heet tegenwoordig Docdata Payments). Hoewel ik niet zeker weet of Docdata Payments dezelfde interface aanbiedt als het voormalige TripleDeal, kon ik bij TripleDeal online aangeven (via een webinterface op hun systeem) welke betalingsmethode(n) weergegeven moesten worden per bezoeker en per land. Je hoeft op die manier maar 1 omgeving te integreren in je eigen omgeving, waar je vervolgens alles kan aanpassen. Let wel op: ik heb met het 'oude' TripleDeal gewerkt. Ik weet niet of Datadoc Payments exact hetzelfde aanbied. Mocht je toch informatie aanvragen bij Datadoc Payments of het daadwerkelijk gaan gebruiken, zou je mij dan even op de hoogte kunnen brengen van hun handelen?