Beginnen met een site
Ik heb nu kennis van HTML, PHP en Photoshop. De site die ik wil bouwen moet hebben:
- nieuwssysteem met reacties en rss
- fotoalbum, voor de fotoverslagen
- competitiesysteem: wanneer je wedstrijden met resultaten invult, moet de stand zichzelf bijwerken
- sidebars, zoals ik die nu ook heb, moeten wederkeren
Ik zou het erg op prijs stellen als iemand mij een goede 'strategie' zou kunnen vertellen, waarmee je de basis creërt. Hoe kun je het beste beginnen?
Ik zal eens wat proberen, heel erg bedankt!
edit: extra stukje verhaal
en bedenk van te voren of je jouw site in meerdere talen wilt, dan kun je je database van te voren beter inrichten voor meerdere talen. Achteraf gezien is dat vrij moeilijk aangezien je al je data moet gaan kopieëren in verschillende tabellen. Het kan een boel gezeik schelen zulk soort dingen van te voren te bedenken.
Gewijzigd op 01/01/1970 01:00:00 door Robin de Vries
Leer CSS (Zonder tabellen/hacks)
Leer PHP
Leer Mysql (of pgsql)
Duurt effe, maar ik vindt persoonlijk dat je altijd validated code moet hebben!
dan heb je een grotere kans dat browsers zoals IE het ondersteunen
Gewijzigd op 01/01/1970 01:00:00 door Robin de Vries
Allemaal goed en wel, maar op 46 jarige leeftijd een hele klus!!!
Ik hoop toch tegen het einde van het jaar een simpele site te kunnen bouwen maar dan wel zonder lay in photoshop. Die is pas voor volgend jaar aan de beurt. Eerst was het simpel met dreamweaver, maar nu met het omschakelen met DIV'S is het weer een heel stuk moeilijker. Voordeel: Je leert idd code te schrijven net als met php.
In de praktijk bij mij gaat het als volgt:
Nadat het design is goedgekeurd door de opdrachtgever, wordt gecodeerd. Dat wil zeggen, eerst de XHTML, CSS en in zekere zin Javascript. Zorgen dat je alle contenttypes hebt uitgewerkt.
Vervolgens wordt de boel dynamisch gemaakt (d.m.v. PHP ofc.) en het CMS (indien vereist) ook geimplementeerd. Meestal heb ik alles al in mijn hoofd zitten, hoe het moet - maar voor de wat meer complexe systemen werk ik het eerst uit op papier. Het databasemodel is ERG belangrijk, ik adviseer je om hier extra aandacht aan te besteden.
Door deze volgorde is het ook mogelijk het XHTML/CSS te laten doen door iemand anders (ik werk vaak samen met een designer die dit werk uit handen neemt, scheelt mij weer tijd).
Gebruik trouwens een editor die fijn is om te gebruiken. Ik ben zelf groot fan van notepad++, maar hier op het werk gebruik ik bijvoorbeeld Eclipse wat eigenlijk ook wel relaxed is (ook vereist i.v.m. SVN en workspaces...). Neem ook een standaard mappen structuur voor je website aan - zo wordt je 'workspace' een stuk overzichtelijker. Ik heb bijv. afb, img, css, js, php, inc, swf en beheer.
Patrick Niezen schreef op 07.03.2008 10:17:
Er zijn nog wel meer praktijken, zo heb ik er heel wat gezien waarbij het design zo'n beetje als allerlaatste klaar was. En dat waren toch projecten van vele miljoenen euro's waar al snel een man of 50 - 60 aan werkte.In de praktijk bij mij gaat het als volgt:
Een design is maar een design, de presentatie van je systeem. Zolang het systeem niet veranderd, denk daarbij aan de workflow, kun je zo het ene design vervangen door het andere design. Een design hoeft alleen maar de data te presenteren die door het systeem wordt opgelepeld. Niets meer en niets minder.
Zorg eerst maar eens dat je de requirements op papier krijgt, dat is vele malen lastiger en vele malen belangrijker. En ja, die kun je ook helder krijgen door een design uit te werken, maar use case diagrammen zijn hier ook voor uitgevonden.
pgFrank schreef op 07.03.2008 10:28:
Een design is maar een design, de presentatie van je systeem.
Ik denk dat ik vergeten ben te zeggen dat ik naast mijn werk ook freelancer ben in m'n vrije tijd en dat de websites die vanuit freelance worden ontwikkeld relatief klein zijn. Voor deze websites is het niet nodig een dermate projectvorm aan te nemen dat alles nauwkeurig moet worden uitgewerkt en de scheiding tussen verschillende lagen/tiers is ook (meestal) niet nodig.
Dit is echter mijn situatie tijdens het freelancen. Op het werk hier komt wat pgFrank zegt min of meer wel aan de orde - de presentatielaag staat los van de business logic. Ik denk dat je voor jezelf moet uitmaken wat nodig is en hoe je het gaat aanpakken. Elke situatie/project is immers anders :-)
Edit: typefout...
Gewijzigd op 01/01/1970 01:00:00 door Patrick Niezen
Daarna ga ik het coderen.
en dan de pagina's maken
Patrick Niezen schreef op 07.03.2008 10:17:
Goeiemorgen,
Gebruik trouwens een editor die fijn is om te gebruiken. Ik ben zelf groot fan van notepad++, maar hier op het werk gebruik ik bijvoorbeeld Eclipse wat eigenlijk ook wel relaxed is (ook vereist i.v.m. SVN en workspaces...). Neem ook een standaard mappen structuur voor je website aan - zo wordt je 'workspace' een stuk overzichtelijker. Ik heb bijv. afb, img, css, js, php, inc, swf en beheer.
Gebruik trouwens een editor die fijn is om te gebruiken. Ik ben zelf groot fan van notepad++, maar hier op het werk gebruik ik bijvoorbeeld Eclipse wat eigenlijk ook wel relaxed is (ook vereist i.v.m. SVN en workspaces...). Neem ook een standaard mappen structuur voor je website aan - zo wordt je 'workspace' een stuk overzichtelijker. Ik heb bijv. afb, img, css, js, php, inc, swf en beheer.
Dat van die editor is zeker waar. Sinds ik ben overgestapt van Dreamweaver naar PHPdesigner (die eigen functies ook recursief in geïnclude pagina's ook meeneemt) wil ik niet anders meer.
Maar voor je mappen vraag ik me wel af waarvoor je de onderstaande hebt. Beetje dubbel lijkt me?
- afb => afbeeldingen?
- img => images?
Daarnaast ook de php en inc mappen. Omdat je JS en CSS (zoals het hoort!) keurig scheid al, zal in zowel de php en inc map een stuk php komen te staan, of niet?
@TS.
Als je echt goed aan een website bezig wil, dan zal je vantevoeren moeten bedenken welke functionaliteiten deze moet hebben. Wat voor pagina's en typen data wil je aan je bezoeker geven? (Dat soort dingen hou je namlijk ook rekening mee in je layout)
Daarnaast zal je ook moeten bepalen wat je doelgroep is (bijv. leeftijd, met welk doel komen ze op je website) en ook moeten onderzoeken wat de meest geschikte kleuren zijn voor het onderwerp.
Al deze zaken doe je al voordat je aan de website gaat beginnen. (Soms heeft een opdrachtgever dit al gedaan voor je) Zonder dat je hier rekening mee houdt kan je eigenlijk noooit een echt goede website maken.
Robert_Deiman schreef op 07.03.2008 11:03:
Maar voor je mappen vraag ik me wel af waarvoor je de onderstaande hebt. Beetje dubbel lijkt me?
- afb => afbeeldingen?
- img => images?
Daarnaast ook de php en inc mappen. Omdat je JS en CSS (zoals het hoort!) keurig scheid al, zal in zowel de php en inc map een stuk php komen te staan, of niet?
- afb => afbeeldingen?
- img => images?
Daarnaast ook de php en inc mappen. Omdat je JS en CSS (zoals het hoort!) keurig scheid al, zal in zowel de php en inc map een stuk php komen te staan, of niet?
Ik gebruik img voor de standaard vaste afbeeldingen die voor de layout van de website zijn (bijvoorbeeld logo's, backgrounds van elementen, etc) en ik gebruik afb als opslagplaats voor geuploade afbeeldingen, die weer onderverdeeld zijn in submappen.
Voorbeeld:
Een nieuwsbericht kan een afbeelding hebben. Nieuwsbericht met id=274 kan dan eventueel een afbeelding bevatten in afb/nieuws/274.* (* = .jpg, .png of .gif). Het is zeg maar een georganiseerde dump voor geuploade afbeeldingen.
De inc-map bevat pagina's die worden geinclude die content hebben. De PHP-map bevat functie libraries voor bepaalde taken (zo bevat bijv. fotoalbum.php de volledige functies voor een fotoalbum-module).
Ik moet zeggen dat ik hier niet 100% tevreden mee ben (de inc en php map), het heeft prima gewerkt in het verleden maar ik blijf verbeteren (ooit PHP-code van jezelf gezien van 4 maanden+ geleden :P dat is gewoon scary!).
pgFrank schreef op 07.03.2008 10:28:
Er zijn nog wel meer praktijken, zo heb ik er heel wat gezien waarbij het design zo'n beetje als allerlaatste klaar was. En dat waren toch projecten van vele miljoenen euro's waar al snel een man of 50 - 60 aan werkte.
Een design is maar een design, de presentatie van je systeem. Zolang het systeem niet veranderd, denk daarbij aan de workflow, kun je zo het ene design vervangen door het andere design. Een design hoeft alleen maar de data te presenteren die door het systeem wordt opgelepeld. Niets meer en niets minder
Een design is maar een design, de presentatie van je systeem. Zolang het systeem niet veranderd, denk daarbij aan de workflow, kun je zo het ene design vervangen door het andere design. Een design hoeft alleen maar de data te presenteren die door het systeem wordt opgelepeld. Niets meer en niets minder
Hier ben ik het totaal niet mee eens. Een design is maar een design is een zeer slechte manier van denken. Een design is zeker zo belangrijk als de techniek die erachter zit.
Voordat je met een website begint moet je eigenlijk al precies op papier hebben wat de klant wilt en wat je wilt bereiken en hoe je het gaat opbouwen, om het maar simpel te zeggen. Over dit proces kan al een hele tijd in gaan zitten. Hierna begin je met het ontwerp en dit werk je net zo lang uit tot beide partijen tevreden zijn. Pas hierna ga je met de techniek aan de gang, dus eerst xhtml en daarna scripten en wat er nog meer nodig is.
Er wordt gewerkt met use cases om te achterhalen hoe de workflow eruit moet komen te zien, de requirements worden opgesteld en men gaat de techniek uitwerken. Dat er ondertussen ook aan de layout wordt gewerkt, leuk en aardig, maar dat is niet meer dan XSLT en CSS. Dat heeft niks met de achterliggende techniek te maken, dat weet jij zelf ook wel.
Het aanpassen van het design is niet meer dan een ander stylesheet en eventueel een andere XSLT om de xHTML aan te maken. De techniek verandert daar echt niet van.
Wat wel vaak gebeurt is dat er vantevoren wordt bepaald welke mogelijkheden de site moet hebben en welke onderdelen die moet bevatten. Aan de hand van de opgestelde vereisten van de website kan je zowel de achterliggende techniek beginnen, als in elk geval de basis opzet voor het design. Dit kan gewoon gelijktijdig, en in principe maakt het niet uit welke eerst wordt gedaan.
Dat de lay-out niets met de achterliggende techniek heeft te maken, onderstreept dit alleen maar. Als het één niets met het ander te maken heeft, geldt dat andersom ook (heeft het ander dus ook niet met het één te maken). Enig punt van aandacht is hierbij wel, dat sommige functionaliteit er vanuit het achterliggende systeem, soms wat anders terug komt dan in de lay-out was bedacht.
Denk bijvoorbeeld aan een bezoekersteller/ statistieken, waar het achterliggende systeem meer gegevens terugstuurt, bijv totaal aantal, aantal per dag, gemiddeld per dag) waar in het design alleen rekening was gehouden met een teller. Kan zo even geen goed voorbeeld bedenken, maar dit is denk ik ook wel duidelijk.
In dat geval moet of de lay-out, of het systeem aangepast (in het geval van het systeem, vaak een kwestie van een paar variabelen veranderen) worden. Daarom is het belangrijk eerst duidelijk te hebben wat er precies op de site komt, en waar. (is het in een kleine ruimte, hou je er met het systeem al rekening mee dat er niet teveel aan data terug mag komen bijvoorbeeld)
Robert_Deiman schreef op 08.03.2008 08:02:
(is het in een kleine ruimte, hou je er met het systeem al rekening mee dat er niet teveel aan data terug mag komen bijvoorbeeld)
Tot op zekere hoogte klopt dat, maar wanneer ik bv. de voornaam niet wil weergeven, maar alleen de voorletters, dan hoef ik dat alleen maar in de weergave aan te passen en niet in de techniek. Het zal me een rotzorg zijn er ergens onder water een paar bits teveel aan data wordt opgehaald, op een andere pagina heb ik deze data wel nodig. Door nu dezelfde techniek meerdere keren te gebruiken, ben ik veel sneller (en dus goedkoper!) klaar.
Maar voor de rest heb je wel gelijk, je kan wel prima aan het werk als je niet de precieze layout kent, maar het is wel handig.
Ik dacht dat je bedoelde dat een design niet belangrijk was. En dat vind ik heel belangrijk. Want met gebruisvriendelijkheid scoort een website of project. Is dit niet het geval dan zal de techniek dit niet compenseren