[Disc] Uiterlijk van je pagina

[Ursamajor]

Hoe komen jullie tot het design van je website?

Ik vind het zelf best lastig om een goeie kleurencombinatie te vinden en hoe ik een en ander wil tonen. Navigatie enz...

Meestal kijk ik op sites die ik interessant vind en probeer er zo wat van te leren.

Hoe doen jullie dat? Wat voor programmeertalen gebruiken jullie? Gebruik je frames of juist niet?

TS starts: Ik gebruik voor de hoofdpagina geen frames, heb voor 2 pagina's dat wel gedaan en verder heb ik een zooitje foto pagina's die html zijn (handig met photoshop).
Verder hou ik wat statistieken bij.

[Alex)]

Ik bouw mijn sites volgens de HTML 4.01 Transitional-specificatie, verder mijd ik frames als de pest, hetzelfde voor tabellen. Kleuren bekijk ik in Photoshop: wat staat bij elkaar. Verder probeer ik gewoon wat uit en laat totale leken op designgebied kijken naar mijn resultaat en luister naar hun suggesties, die verwerk ik daarna.

Ik gebruik zoveel mogelijk CSS en attributen waarvoor ze bedoeld zijn: navigatie is niets meer dan een lijst, dus die komt in een <ul>. Teksten komen gewoon in paragrafen, daar misschien een <div> omheen. Dit geldt verder eigenlijk overal voor, go with the flow.

Lees eens wat artikelen op www.alistapart.com, daar leer je zeker veel van

[crisp]

Transitional is bedoelt voor oude documenten die opgelapt worden, strict is de norm...

Tabellen vermijden is onzin; tabulaire date hoort nog steeds in een table

[ Voor 30% gewijzigd door crisp op 06-08-2006 03:09 ]

[Alex)]

O ok, dat wist ik niet. Ik dacht dat Strict voor de pure nerds was (Nee hoor, ik nam aan dat Strict was voor documenten die weinig specifieke tags enzo nodig hadden)

Overigens bedoel ik met tabellen vermijden tabellen vermijden voor de opmaak, dingen zoals een omzettingstabel horen in een... tabel.

[Johnny]

Eerst kijk ik naar wat er voor inhoud op de website moet komen, aan de hand daarvan bedenk ik in welke pagina's dat moet worden opgedeeld, dan een navigatiestructuur en dan ga ik in CorelDraw een soort schets van een pagina proberen te maken met die navigatie en wat inhoud en speel dan wat met de posities, kleuren en lettertypes waarna ik er nog niet echt tevreden over ben en op internet op zoek ga naar wat inspiratie, meestal klik ik dan gewoon wat door de CSSZengarden en bookmark de ontwerpen die 'iets' hebben wat goed past bij mijn project. Dan pas ik mijn eigen ontwerp aan en zet hem om naar HTML en CSS omdat dat makkelijker is dan hem helemaal uittekenen en pruts dan nog wat verder met de lettergroottes, marges enz.

[Rowanov]

Ik laat eerst degene die de opdracht geeft iets in de zin van content oplepelen, zodat ik weet wat het doel van de website wordt. Vervolgens ga ik op google kijken hoe anderen binnen die categorie website het aan hebben gepakt.

Ik denk dat een bezoek aan ZenGarden en CSSBeauty vaak de volgende stap is, waarbij ik ZenGarden in zijn algemeen iets doorblader omdat dat al wat ouder is en CSSBeauty gebruik ik meer voor de laatste nieuwe hypes op gebied van layout even door te bladeren.

Van google, ZenGarden en CSSBeauty pik ik de layout's er uit die ik mooi vind en bij het onderwerp vind passen. Daarbij kan een indeling bijvoorbeeld erge geschikt zijn, maar het kleurenschema totaal niet. Dan neem ik de indeling (verdeling van secties als menu en header etc.) en combineer ik die met een kleurenschema wat bestaat uit kleuren die ik van andere websites heb opgepikt. Voor de gebruikte fonts ongeveer hetzelfde.

Eigenlijk probeer ik dus van mooie pagina's de elementen te pakken waar ik iets aan heb, voordat ik door ga naar de volgende stap. Die volgende stap is het uitwerken van het ontwerp in Photoshop. Daarna klus ik de html (4.01 strict) in elkaar en dan ga ik met een minimale hoeveelheid layout gerelateerde plaatjes, met css de pagina maken zoals ik hem in Photoshop heb geproduceerd.

[rickmans]

Meestal pluk ik ergens een gratis webtemplate vandaan (meestal van oswd.org). De reden hiervoor is dat ik programmeren te leuk vind om mijn tijd te verdoen aan enige vorm van design. Vaak zit ik nog wel even te pielen om de markup van de templates beter te maken, maar qua design waag ik me nagenoeg nergens aan (ook omdat ik het gewoon niet kan ).

[Rekcor]

Ursamajor schreef op zondag 06 augustus 2006 @ 01:52:
Ik vind het zelf best lastig om een goeie kleurencombinatie te vinden en (...)

Check http://www.hypergurl.com/colormatch.php of zoek op: color scheme generator.

[ Voor 15% gewijzigd door Rekcor op 06-08-2006 12:31 ]

[Verwijderd]

Ik bekijk adhv de informatie die op de website moet komen te staan, hoe ik dit het beste kan verwerken in een grafische omgeving. Adhv alle dingen waar ik rekening mee houd (welke dynamische velden, welke functies, etc).

Over het algemeen heb ik niet zo'n problemen met designen, ook al ben ik webscripter. Ik heb een stuk grafische opleiding gedaan (omdat het wel aansloot bij mij, dacht ik), dus ik heb er wel een beetje feeling mee. Als kind ook altijd tekenen, wat raardere dingen in elkaar gooien.

Ik let erg op de doelgroep van de website, als ik een site bouw voor wat saaie ambtenaren van de provincie (NB), dan maak ik geen website met filmpjes. Bouw ik er echter een voor wat leerkrachten dan zal ik eerder complete films/documantaires als video aanbieden.

Ambtenaren zijn saaie informatie gewend, een leerkracht zal graag wat dynamischere informatie krijgen. De doelgroep en de content "soort" goed analyseren, hier kan je meestal wel dingen uit halen voor het grafische ontwerp.

Qua achtergrond gebruik ik altijd Apache/PHP/MySQL (serverside) en HTML/JS/CSS (clientside), dit is dynamisch genoeg om vanalles te kunnen doen. Natuurlijk alles zoveel volgends standaarden bouwen, en niet Internet Explorer only (dat is nl niet de standaard ). Ik probeer geen frames te gebruiken, maar in sommige gevallen is het wel nodig, maar over het algemeen (99%) heeft een website van mij geen frames.

[Verwijderd]

Alex schreef op zondag 06 augustus 2006 @ 03:15:
O ok, dat wist ik niet. Ik dacht dat Strict voor de pure nerds was (Nee hoor, ik nam aan dat Strict was voor documenten die weinig specifieke tags enzo nodig hadden)

Specifiek als in <font> specifiek is?

[messi]

Rowanov schreef op zondag 06 augustus 2006 @ 10:16:
Hier stonden de exacte stappen die ik ook doorloop

Ik werk precies hetzelfde
Alhoewel ik wel regelmatig het schetsboek ter hand neem om snel een overzicht te maken.

[André]

Verwijderd schreef op zondag 06 augustus 2006 @ 21:02:
[...]
Specifiek als in <font> specifiek is?

Ik vermoedt dat hij zaken als align en target bedoeld

offtopic:
welkom terug, lang geleden dat je wat gepost hebt

[Rowanov]

messi schreef op zondag 06 augustus 2006 @ 21:09:
[...]
Ik werk precies hetzelfde
Alhoewel ik wel regelmatig het schetsboek ter hand neem om snel een overzicht te maken.

Dat is inderdaad een goede manier, omdat je de globale opzet dan zeker makkelijker kan uitwerken. Ik kan mij herinneren dat XangdadiX daar ook een grote voorstander prediker van is

[Victor]

Alex schreef op zondag 06 augustus 2006 @ 03:15:
O ok, dat wist ik niet. Ik dacht dat Strict voor de pure nerds was (Nee hoor, ik nam aan dat Strict was voor documenten die weinig specifieke tags enzo nodig hadden)

En dan nog? Strict houdt simpelweg in dat er geen ruimte is voor half werk. Ik begrijp niet hoe men bij het bouwen van een nieuwe site voor een transitional DTD kan kiezen. Alsof je vantevoren al voor jezelf hebt vast gesteld dat je niet de moeite wilt nemen om het goed te doen.

Dat wordt wat als XHTML eindelijk gemeengoed is, en de XML parser errors in het rond gaan vliegen.

[crisp]

King_Louie schreef op zondag 06 augustus 2006 @ 23:50:
[...]
Dat wordt wat als XHTML eindelijk gemeengoed is, en de XML parser errors in het rond gaan vliegen.

When pigs fly Draconian error-handling is nou niet bepaald een pré.
HTML5 \o/

[Victor]

crisp schreef op zondag 06 augustus 2006 @ 23:57:
[...]

When pigs fly Draconian error-handling is nou niet bepaald een pré.

Geef die beesten vleugels dan, want ik vind het prima!

En ik ben persoonlijk wel een voorstander van de strictheid waarmee XML parsers te werk gaan. In iedere andere taal wordt je afgestraft op fouten, dus waarom in een markup taal niet?

[crisp]

King_Louie schreef op maandag 07 augustus 2006 @ 00:09:
[...]

Geef die beesten vleugels dan, want ik vind het prima!

En ik ben persoonlijk wel een voorstander van de strictheid waarmee XML parsers te werk gaan. In iedere andere taal wordt je afgestraft op fouten, dus waarom in een markup taal niet?

Omdat het een markup-taal is en niet een programmeer-taal?
Error-handling is prima te definieëren voor een markup-taal wat de working draft van HTML5 (of WA1) ook bewijst

[Victor]

crisp schreef op maandag 07 augustus 2006 @ 00:14:
[...]

Omdat het een markup-taal is en niet een programmeer-taal?

Waarom moet er onderscheid zijn? Hoe stricter de taal, hoe efficienter de parser te werk kan gaan. Zelfde als met een interpreter of een compiler.

Error-handling is prima te definieëren voor een markup-taal wat de working draft van HTML5 (of WA1) ook bewijst

Ik heb me nog niet echt op de hoogte gehouden van de HTML5 ontwikkelingen, dus ik zou dat document eens rustig door moeten lezen.

[crisp]

King_Louie schreef op maandag 07 augustus 2006 @ 00:39:
[...]

Waarom moet er onderscheid zijn? Hoe stricter de taal, hoe efficienter de parser te werk kan gaan. Zelfde als met een interpreter of een compiler.

Mwa, parsing afbreken en een error tonen, of error gewoon negeren en verder gaan met het volgende token lijkt me niet echt inefficienter.
Binnen markup is het gewoonweg geen ramp als er een tag of attribuut genegeerd wordt - zolang je maar geen guesses gaat doen en probeert de fout te 'verbeteren'. Bij een programmeertaal heeft een klein foutje vaak grote gevolgen, binnen markup doorgaans niet.

[Victor]

crisp schreef op maandag 07 augustus 2006 @ 00:46:
[...]

Mwa, parsing afbreken en een error tonen, of error gewoon negeren en verder gaan met het volgende token lijkt me niet echt inefficienter.
Binnen markup is het gewoonweg geen ramp als er een tag of attribuut genegeerd wordt - zolang je maar geen guesses gaat doen en probeert de fout te 'verbeteren'. Bij een programmeertaal heeft een klein foutje vaak grote gevolgen, binnen markup doorgaans niet.

Nee, het is op zich geen probleem om de fout over te slaan, maar een parser kan veel compacter (en dus efficienter) zijn als er minder rekening gehouden hoeft te worden met de vreemde constructies die sommige "developers" soms weten te bedenken.

De huidige strictheid van XML dwingt men om na te denken over de gebruikte code, en voedt daarmee in feite de developer op. Ik kan dat enkel als een positieve ontwikkeling zien

[crisp]

King_Louie schreef op maandag 07 augustus 2006 @ 00:54:
[...]

Nee, het is op zich geen probleem om de fout over te slaan, maar een parser kan veel compacter (en dus efficienter) zijn als er minder rekening gehouden hoeft te worden met de vreemde constructies die sommige "developers" soms weten te bedenken.

De huidige strictheid van XML dwingt men om na te denken over de gebruikte code, en voedt daarmee in feite de developer op. Ik kan dat enkel als een positieve ontwikkeling zien

En tegen welke prijs? In een ideale wereld zou ik je gelijk geven, maar daar leven we niet in.
De strictheid van XML dwingt je ook om alleen gebruik te maken van XML-based tools, en elke externe input moet dan ook gevalideerd worden.
Verder brengt het nog meer nadelen met zich mee: werken met document fragments is bijna onmogelijk (innerHTML, document.write()), namespace hell, het feit dat bepaalde markup regels niet in een XML-format beschreven kunnen worden (wat XHTML op bepaalde punten juist minder 'strict' maakt dan HTML), en last but not least: er is tenminste nog 1 veelgebruikte browser die er niets mee aankan waardoor je je zorgvuldig samengestelde document uiteindelijk gewoon als (invalid) HTML over de lijn moet sturen.

[Victor]

crisp schreef op maandag 07 augustus 2006 @ 01:08:
[...]

En tegen welke prijs? In een ideale wereld zou ik je gelijk geven, maar daar leven we niet in.
De strictheid van XML dwingt je ook om alleen gebruik te maken van XML-based tools, en elke externe input moet dan ook gevalideerd worden.

Vertel mij wat, ik heb laatst een berg content op kunnen schonen juist om deze reden. Niet bepaald een feest. Zeker niet als je ook nog eens alle named character entities kan vervangen door hun numerieke equivalenten omdat Safari de moeite niet neemt om daadwerkelijk de DTD te raadplegen, maar alleen de content-type header gebruikt om te bepalen wat voor content nu eigenlijk gestuurd wordt.

Verder brengt het nog meer nadelen met zich mee: werken met document fragments is bijna onmogelijk (innerHTML, document.write()), namespace hell, het feit dat bepaalde markup regels niet in een XML-format beschreven kunnen worden (wat XHTML op bepaalde punten juist minder 'strict' maakt dan HTML),

Ik kan prima zonder innerHTML en write() en namespaces zijn een groot voordeel wat mij betreft. Daar zie ik eerlijk gezegd niet zoveel problemen.

en last but not least: er is tenminste nog 1 veelgebruikte browser die er niets mee aankan waardoor je je zorgvuldig samengestelde document uiteindelijk gewoon als (invalid) HTML over de lijn moet sturen.

Zoals je al zei: when pigs fly

Ik heb het ook niet over de huidige situatie, enkel hoe ik het graag zou zien. En die droomwereld heeft voorlopig slechts één naam, en dat is Gecko.

[Blaise]

Rekcor schreef op zondag 06 augustus 2006 @ 12:31:
[...]


Check http://www.hypergurl.com/colormatch.php of zoek op: color scheme generator.

http://www.colourlovers.com/ is ook een goede daarvoor.

[Verwijderd]

Het is belangrijk om te weten wie je tegenover heb zitten. Je bespreekt wat degene graag in zijn site wilt hebben.

Met als de hoofdvragen:

• Zakelijk
• Portfolio/Persoonlijk

Vervolgens bespreek je de kleur, lettertype, foto's, navigatie en tijdens dit intake gesprek kun je al goed aanvoelen welke kant je op moet gaan met je design.
Het is ook een stukje creativiteit en motivatie die je mee moet hebben. Kleuren combineren is een kwestie van aanvoelen. Alle kleuren kun je combineren, mits je de goede verhouding/contrast toepast. Laat je inspireren door andere websites of boeken waarin websites gepubliseerd staan.