best practise in webdesign

[Alwinonline]

Hoi allemaal,

Ik ben me recentelijk wat gaan verdiepen in HTML en php/mysql om een beetje de tijd te doden en omdat ik het altijd erg interessant heb gevonden. Nu merk ik dat veel van de tutorials die er zijn (php.net/w3schools etc) erg duidelijk zijn in het omschrijven en uitleggen van hoe bepaalde functies en attributen werken alleen heb je nergens pagina's met duidelijke uitleg over best practices in webdesing. Als ik zo rondlees op GoT zie ik regelmatig dingen gepost worden door mensen waar ik zelf het idee bij heb dat het er goed en netjes uitziet alleen zie ik al heel snel het commentaar van professionele/andere webdesigners komen dat dit neit volgens de best practise is etc.

Nou vroeg ik mij af hoe mensen hier bij komen en of zij dit allemaal uit praktijk ervaring halen of zjin er websites voor die ik niet kan vinden met google? Aan de hand van een praktijk probleem waar ik zelf tegenaan loop wil ik graag de discussie starten namelijk het Width attribuut in css. ik heb me helemaal suf gezocht naar hoe dit in de praktijk het beste toegepast kan worden maar omdat er zoveel zoekresultaten uit verschillende jaartallen zijn zie ik door de bomen het bos niet meer. "fixed-width"degsins, liquid designs, ik snap het even niet meer.

Ik begrijp dat het natuurlijk ook een groot deel persoons gebonden is en afhankelijk is van wat soort website je wil maken maar toch zou ik het handig vinden om een soort best practise lijst te hebben aan de hand waarvan ik kan verder oefenen.

[Bosmonster]

Valideer je html met een strict of html5-doctype en je zult al snel dingen zien die anders horen.

Daarnaast zijn een redelijke maatstaf voor nette code ook de accessibility guidelines. Een nederlandse uitleg hierover kun je vinden op bijvoorbeeld http://www.webrichtlijnen.nl

Verder is het een kwestie van ervaring opdoen en open te staan voor verbeteringen. Er is niet 1 document dat je exact uitlegt hoe je moet werken.

[m0nk]

Liep ik ook tegen aan. Heb zelf veel gehad aan http://www.barelyfitz.com...training/css/positioning/

Gaat overigens meer over divs en posities. Maar daar kan je heel wat mee experimenteren, ook met widths.

[Matis]

Kijk ook eens door dit topic heen: WEB FAQ - input gevraagd

Hierin hebben een aantal grootmeesters hun zegje gedaan over de do's and dont's binnen webdevelopment.

[jbdeiman]

Hoi Alwin,

Het is altijd lastig om hier een bepaalde richtlijn voor te volgen, immers de ene persoon is de andere niet en daarbij heeft niet iedereen de resolutie waarop jij werkt.

Het lastige bijvoorbeeld van een liquid layout is eigenlijk dat je in je creativiteit voor wat betreft het gebruiken van bepaalde achtergrondjes erg wordt beperkt. Het moet er natuurlijk op een breedbeeld met verhouding 16:9 net zo goed uit zien als op 4:3. Dat is nog prima te doen, het instellen van een crossbrowser liquid lay-out waarbij het altijd goed gaat, ongeacht verhoudingen van het scherm, en waarbij alle onderdelen bereikbaar zijn is lastiger, je moet met heel veel dingen rekening houden.
Het gevaar met een lay-out die je vastzet op een bepaalde breedte is weer dat je al gauw een saaie pagina krijgt, doordat er vaak een kleine resolutie wordt genomen in een browser scherm, kan het er op een groot scherm/ grote viewport van de browser heel saai uitzien, omdat buiten de pagina zelf niets is ontworpen.

Zoals je al merkt hebben beiden hun nadelen (voordelen zijn er ook maar die ken je vast). Er is niet 1 bepaalde manier die altijd goed is, het is ook afhankelijk van het type pagina wat je aan het ontwerpen bent.

Het width attribuut kan je ook niet 1 passend antwoord op geven, probeer er wel rekening mee te houden dat je regellengte niet te lang is, dus dat je hele lange tekstregels krijgt. Verder is het aan te raden om een menu (bjivoorbeeld) vast te zetten qua breedte en je content indien gewenst variabel te houden qua breedte. Het menu is een bepaald onderdeel die niet te groot moet worden, de bediening is iets wat eenvoudig moet zijn en waarvoor je niet teveel (loze) ruimte in moet nemen.

Wat wel een best practice is, maar dat gebeurt eigenlijk altijd:
Je website draait om de content, niet om het menu, dat is een hulpmiddel. Reserveer ook meer breedte voor je content dan voor je menu.

[ Voor 8% gewijzigd door jbdeiman op 12-01-2011 13:45 ]

[OkkE]

Alwinonline schreef op woensdag 12 januari 2011 @ 12:43:
Nou vroeg ik mij af hoe mensen hier bij komen en of zij dit allemaal uit praktijk ervaring halen of zjin er websites voor die ik niet kan vinden met google?

Er zijn een groot aantal blogs en websites van professionals etc, waar vaak nuttige info op te vinden is. Verder veel discussies volgen, zowel op GoT als op andere plekken. Je leert het dan vanzelf. Natuurlijk helpt zelf doen ook enorm.

Aan de hand van een praktijk probleem waar ik zelf tegenaan loop wil ik graag de discussie starten namelijk het Width attribuut in css. ik heb me helemaal suf gezocht naar hoe dit in de praktijk het beste toegepast kan worden maar omdat er zoveel zoekresultaten uit verschillende jaartallen zijn zie ik door de bomen het bos niet meer. "fixed-width"degsins, liquid designs, ik snap het even niet meer.

Ik vind "width" eigenlijk een van de weinig waar niet echt best-practice voor is. Anders gezegd, het is meer een persoonlijke keuze als sommige andere dingen (zoals navigatie die je in een UL stopt). Enige tip m.b.t. width: zorg dat de regels tekst niet te lang zijn. Bijvoorbeeld 50em.

Er zijn grofweg eigenlijk 3 technieken, die ook weer gecombineerd kunnen worden.

• Fixed-width
  Vaste waardes voor "width". Door alles in pixels te zetten kun je vrij goed inschatten hoe de site er overal uit ziet.
• Liquid
  Waardes staan in % (percentages). Elk vlak neemt een % van het scherm in. Meer flexibiliteit, maar wel lastiger om de website overal goed te houden. Je wil niet op een 27" een tekstvlak van 70% (dat is te breed), maar op een 1024x768 scherm bijv. wel.
• Responsive
  Aan de hand van CSS media-queries wordt een CSS ingeladen die past bij de resolutie, zo kan je zorgen dat op een 1024x768 scherm er één dunne sidebar (van 320px) is, terwijl dit op een 27" twee sidebars zijn (van bijv 400px) zijn.

[mcDavid]

Zolang de broncode (HTML) van je website, en ook de output van de browser met CSS uitgeschakeld, allebei goed te volgen is, dan zit je al een behoorlijk end in de goede richting.

[Alwinonline]

Iedreen hierboven bedankt voor de informatieve links en reacties. ik ben nu hard door aan het lezen en moet zeggen dat:
http://www.barelyfitz.com...training/css/positioning/

echt een uitkomst is voor mij als beginner. mbt de width vreesde ik al een beetje wat jullie bevestigen en zal ik dus iets moeten zoeken wat bij mij en een aantal standaard resoluties die veel gebruikt worden goed werkt. Ik ga mij zeker meer verdiepen in HTML/CSS alleen merk ik wel dat dit toch een iets zwaardere pil is dan dat het in eerste instantie leek (althans als je het goed wilt doen )

nogmaals iedereen bedankt!

[OkkE]

Alwinonline schreef op woensdag 12 januari 2011 @ 15:47:
... echt een uitkomst is voor mij als beginner. mbt de width vreesde ik al een beetje wat jullie bevestigen en zal ik dus iets moeten zoeken wat bij mij en een aantal standaard resoluties die veel gebruikt worden goed werkt. ...

Neem 960px width, oftewel 960 grid, dat vind ik een veilige en mooie oplossing - zeker voor beginners.

[mcDavid]

OkkE schreef op woensdag 12 januari 2011 @ 15:53:
[...]

Neem 960px width, oftewel 960 grid, dat vind ik een veilige en mooie oplossing - zeker voor beginners.

Ligt er heel erg aan watvoor website het betreft. Vaak hou ik gewoon 760 aan omdat ik dat mooier vind.

[Bosmonster]

mcDavid schreef op woensdag 12 januari 2011 @ 19:17:
[...]

Ligt er heel erg aan watvoor website het betreft. Vaak hou ik gewoon 760 aan omdat ik dat mooier vind.

Maar wat jij mooier vindt heeft weinig te maken met wat best practice is.

[m0nk]

Yw. Erg handige link die ik nog steeds gebruik.
Ben ook pas begonnen met css/html en wat mij erg helpt (naast het eindeloos blijven proberen) is ook code bekijken van bestaande websites met layouts. Bijv: http://developerscorner.nl/csshunter/phpsite/homepage.php

Heel simpel, maar dat is ook precies wat ik nodig heb/had..

[Alwinonline]

hehe ja die truc heb ik ook al meerdere malen toegepast, probleem waar ik nu veel tegen aanloop is het goed gescheiden houden van php en html. als ik hier op google kom ik meteen uit bij een CMS maar dat wil ik niet. Ik ben nu aan het proberen de php html als output te geven en dat te gebruiken maar dit is vooralsnog behoorlijk lastig.

[Bosmonster]

Gewoon een template engine gebruiken zoals Smarty of Twig gebruiken.

[Davio]

Bosmonster schreef op donderdag 13 januari 2011 @ 15:26:
Gewoon een template engine gebruiken zoals Smarty of Twig gebruiken.

Dat zou ik niet automatisch doen; zeker voor een kleine site haal je dan meer rompeslomp op je nek dan je nodig hebt.

Tuurlijk kan een template engine handig zijn, ik zou het niet te pas en te onpas van stal halen.

[moozzuzz]

Zelf gebruik ik iets als

PHP:

/*  Print een statische tekst via file-functions met errorhandling
    Let op: $text bevat een array met waarden die ge-eval-ed moeten worden!
*/
function printStatic($page,$text)
{
    if ( is_numeric(strpos($page, '.txt'))==true ) 
        $tmpl_loc = $page;
    else
        $tmpl_loc = './0static/'.$page.'.txt';
    if ( ($tmpl_file = @file($tmpl_loc)) == FALSE)
        $tmpl_file = @file("./0static/error/404.txt");
    $thefile = @implode("", $tmpl_file);
    $thefile = addslashes($thefile);
    $statementstr = "\$to_print=\"".$thefile."\";";
    eval($statementstr);
    if (func_num_args()>=3)
    {
        echo stripslashes($to_print);
        return true;
    }
    else
        return stripslashes($to_print);
}

Er bestaat wellicht wel een mooiere oplossing die even eenvoudig is maar die ben ik nog niet tegengekomen =^)

[OkkE]

Voor kleine (hobby) projecten is denk ik een template engine wat overbodig, daarnaast is PHP van zichzelf al een redelijke template engine natuurlijk. Gewoon een "inc.header.php" en "inc.footer.php", en de content en sidebar etc via <?php print $myContent; ?> plaatsen.

Waar die content dan vandaan komt, een database, xml file of text file, dat doet er niet heel veel toe.