Nieuw GoT Design - (X)HTML feedback

[crisp]

Zoals velen van jullie wel zullen weten komt er een nieuw design voor GoT; inmiddels zijn we daarmee in een vrij vergevorderd stadium beland, en zijn er ook previews in (x)html formaat beschikbaar, te weten:

forum listing: http://crew.tweakers.net/crisp/newlayout/index.html
topic listing: http://crew.tweakers.net/crisp/newlayout/list_topics.html
message listing: http://crew.tweakers.net/crisp/newlayout/list_messages.html
message listing met mod-functionaliteit: http://crew.tweakers.net/...ut/list_messages_mod.html

dit is echt nog beta-beta-beta-versie 0.001 maar laat wel mooi zien waar we naar toe willen. Dat het niet valideerd heeft z'n redenen; de iframe wordt nog vervangen, de rest is over het algemeen RML. Validatie vind ik echter niet het belangrijkst; dat is meer iets voor diegenen die nog nooit van IRL hebben gehoord

wat ik graag zou willen is feedback vanuit de meer professionele hoek (dus niet het standaard LA-gezeur): voldoet dit aan usability eisen? is het intuitief genoeg? kan de code/structuur nog geoptimaliseerd/verbeterd worden?

kortom: is dit GoT-waardig?

[ Voor 9% gewijzigd door crisp op 13-03-2004 17:45 ]

[Verwijderd]

wat mij opvalt is dat bij
de message listing, er nogal wat "loze" ruimte zit tussen het "informatie over de user" en het "dit is wat de user kwijt wil" gedeelte zit als hij ingeklapt is.
mogelijk reg datum kleiner maken door maand niet voluit te schrijven ofzo? (gezien dat zo op het oog de enigste bron is waardoor het user gedeelte zo breed moet.

had ook even naar de source gekeken.
maar door het gebrek aan enters er niet veel wijs uit geworden.

gebruik hier overgenst mozilla 1.6,

voor de rest ziet het er goed uit vind ik. werkt iig intinu-dinges.

[ Voor 40% gewijzigd door Verwijderd op 07-03-2004 03:38 ]

[Verwijderd]

Zoals al wel vaker is gezegd volgens mij, maar dan nog maar een keer in dit topic:
De rode titel is niet zo mooi. Arial Black is mooi, maar niet ook nog eens bold

Zoals je het nu hebt: Arial Black, Bold


Zo vind ik het mooier: Arial Black, Normaal


(edit: anders maak ff een poll )

De punten die je voor een subforum hebt staan (bijvoorbeeld voor Stuffis Generalis) zijn nog behoorlijk kaal, daar zou je nog even naar kunnen kijken.

Verder vind ik het niet zo mooi dat in de index, de cellen groter/kleiner worden nadat je een categorie uitvouwt. Dus dat: Forum, Topics, Posts, Last post en Moderators geen vaste positie hebben

(IE only) Ik heb hier problemen met in/uit klappen van menu's, zie afbeelding:



(IE only) En als ik over de titel van de categorie (bv. General Chat) beweeg met de muis, dan valt het lijntje erboven weg. Zie afbeelding:



Verder nog een kleine opmerking: De verborgen tekst onderaan (parsetime etc.) zouden eigenlijk gecentreerd moeten staan.

De source ziet er goed uit, evenals de CSS. Petje af, je hebt goed werk geleverd

[ Voor 4% gewijzigd door Verwijderd op 07-03-2004 03:59 ]

[w0w]

kortom: is dit GoT-waardig?

Ja

Merge, bij de mod-functionaliteiten, hoe werkt die? Is die er nu ook al? Wat moet ik me voorstellen bij het samensmelten van meerdere topics?
Verder vind ik het vooral fijn dat het paars/donkerpaars weg is, en het lijkt zo al een stuk meer op www.tweakers.net, zodat het waarschijnlijk minder gezien zal worden als 2 compleet andere sites.
De 'msn-icq-homepage-icoontjes zitten nu ook onder je icoon, stuk logischer
Ik zie een dubbele ondertitel oid?;

code:

crisp
Template Hoer
BOFH

Toch denk ik dat het niet verstandig is de 'New Topic' naast de 'Post Reply' knop te zetten. Regelmatig zie ik complete topics die bedoelt zijn als post. Die 'New Topic' knop zou eigenlijk alleen maar beschikbaar moeten zijn in de subfora (SG, PMG, VB enz enz)
Voor de rest; Toppie

edit;

wat ik graag zou willen is feedback vanuit de meer professionele hoek (dus niet het standaard LA-gezeur): voldoet dit aan usability eisen? is het intuitief genoeg? kan de code/structuur nog geoptimaliseerd/verbeterd worden?

Hmm, negeer mijn post dan maar

[ Voor 62% gewijzigd door w0w op 07-03-2004 03:58 ]

[LauPro]

Wat ik heb gedaan met een forum is alles in een lijst zetten (bekijk de bron van dit topic maar eens.) Technisch gezien is dat imo een betere oplossing dan posts in div's plaatsen, je hebt namelijk een lijst met posts.

En bovendien ziet het er in Links heel leesbaar uit. Het forum is dus 'normaal' te bezoeken in een text-based browser. Waarschijnlijk ook meteen goed op pda's. Want nu alles in div's staat wordt het 1 grote brei als je er naar gaat kijken.

[ Voor 5% gewijzigd door LauPro op 07-03-2004 04:17 ]

[bolleh]

ik vind het nogal "groot"
dat wil zeggen het deel dat er eigenlijk niet toe doet, dus de knoppen boven, de ruimte van je naam, horizontaal en verticaal, die knopjes van edit/quote etc. het neemt allemaal zoveel ruimte in, het belangrijkste is toch de message, en niet dat je verzuipt in alle knopjes en randjes en dingetjes eromheen

verder ook bij de usericon, we zijn in het gelukkige bezit van een forum dat godzijdank een usericon biedt van 60*60 pixels, niet groter niet kleiner. en dan doe je die knopjes eronder toch breder laten zijn, t vormt gewoon niet echt een geheel

bijv bij forum listing neemt de hele pagina op mijn 1024*768 scherm meer ruimte in dan IE kan laten zien terwijl ik maar 4 links zie waar ik me ECHT voor interesseer, waar het om draait, de 4 subfora.

verder zit er geen duidelijke scheiding tussen "topics posts last pot moderators", dat lijkt niet zo boeiend maar als je dan die nummertjes daar beneden ziet alles met dezelfde kleur/achtergrond, dan verzuipen je ogen nogal snel


verder nog een "echte" bug(of feature? ) als je over zon button bovenaan hovered en je dat rolldown menuutje krijgt verdwijnt de banner en minder opvallend: de search.


verder nice job, kleurenschema is leuk, hoewel die paarse gloed toch al een aantal jaar elke dag op je netvlies geprint wordt en nog steeds niet verveelt

[Verwijderd]

(Anne vraagt zich af of er ook documenten zijn in dit stadium met leesbare broncode)

Ik wil iig alvast opmerken dat jullie alle META met het HTTP-EQUIV kunnen droppen in het voordeel van een server-side afhandeling. Het blijft \xml:lang="nl"\ en niet \"nl_NL"\ oid.

Ook ben ik van mening dat als je graag TARGET wilt gebruiken je niet met een XHTML1.0 Strict Doctype moet komen aanzetten. En dit soort dingen:

code:

  ....net/admin/admin.php?data%5Bstep%5D=2&action=lookup_user&data%5Bsearch%5D=use

(uit de validator) is natuurlijk het ergste en dat kun je niet met een of ander smoesje van de hand doen. Voor een ampersand dien je gewoon een entiteit te gebruiken, zo simpel is het.

Edit: het was blijkbaar nog erger. Meerdere ID attributen in hetzelfde document met dezelfde waarde. Deze is ook nog wel leuk:

code:

</li>&nbsp;<li>

En ik vraag me echt af waarom jullie CENTER gebruikt hebben. En een SPAN na het HTML element etc.

[ Voor 18% gewijzigd door Verwijderd op 07-03-2004 08:58 ]

[dawuss]

Eerste indruk is goed. Vooral qua layout en intuitiviteit zit het goed inelkaar. Op de code is hierboven al genoeg gal gespuwd. Wat voor mij zeker telt is dat het er hier gewoon goed uit lijkt te zien, op een paar kleine dingen na:


Hier vind ik dat er veel te weinig ruimte zit tussen de datum laatste topicstart, en de namen van de moderators. Dat maakt het erg onoverzichtelijk.

Minder belangrijk, maar toch de moeite waard om het te vermelden:

Hier is imo ook weer een te kleine marge aangehouden. Hier veroorzaakt het weliswaar geen onleesbare stukken tekst, maar ik vind het toch minder mooi.

Hoop dat jullie hier wat aan hebben

Edit: O ja, deze screenshots zijn genomen met een Mozilla Firefox nightly

[ Voor 6% gewijzigd door dawuss op 07-03-2004 09:48 . Reden: browservermelding ]

[NaZGuLL]

Als jullie toch de boel aan het opfrissen zijn, denk dan ook even aan de kleur opmaak. Al dat bruin en rood, spontane flashbacks naar de 70s, krijg ik ervan.
Het blijft zo een beetje een muffig geheel.

[coubertin119]

Anne, die <span /> na de <html /> is omdat die stats pas na het parsen toegevoegd kunnen worden, zodoende staan ze buiten de eigenlijke pagina.

[B-Force]

Ik sluit me aan bij de tekst hierboven, wat betreft de grote knoppen bovenin. Het gaat uiteindelijk om de topics / fora, en ik denk dat je er dan ook voor moet kiezen om zoveel mogelijk van deze dingen te laten zien, ipv allerlei leuke features die bijna niemand gebruikt...

Verder vind ik het mooier als het geheel gecentreerd is, maar dat is dnek ik een persoonlijke mening...

[djc]

coubertin119 schreef op 07 maart 2004 @ 10:05:
Anne, die <span /> na de <html /> is omdat die stats pas na het parsen toegevoegd kunnen worden, zodoende staan ze buiten de eigenlijke pagina.

Een enkele str_replace() op de server en ze staan er toch voor, is dat nou zoveel moeite?

[ Voor 4% gewijzigd door djc op 07-03-2004 10:15 ]

[Verwijderd]

Anne denkt dat ze dan beter een SGML/XML comment kunnen gebruiken.

[Verwijderd]

begint allemaal wel heel erg te lijken op fok.nl ziet er niet uit.

[Ibex]

Vooreerst in de topiclisting:



Hier vind ik dus dat de plaats tussen de mod-namen en de tijd zeer klein is, evenals de plaats tussen de mod-namen en de rechterrand. Bovendien merk ik nogal rare onderbrekingen in de rechter forumrand._{(maar dat was dus al deels gzegd}

Een postlisting:



Hier denk ik dat nogal veel ruimte word verloren tussen de naam van de poster+icoon en hte begin van het bericht. Bovendien had ik de icoontjes die onder het icoon can crisp staan liever op de oude plaats gezien naas "edit" en "quote" e.d.

Dan buiten de schreenshots gerekend; ik vind de text onder de "edit" en "quote" knop nogal raar, eens je ze gebruikt hebt zijn die onderschriften toch vrij waardeloos denk ik.
Ook snap ik niet echt waarom er 2 ondertittels lijken te zijn bij crisp; zowel "template hoer" als "bofh".

Ohja, de kleuren vind ik niet echt zo mooi, ik hou nogal van het huidige kleur. Zal er een mogelijkheid voorzien worden om de oude kleurtinten in te stellen op de nieuwe template?

En nu ik eventjes de nieuwe reply's hierboven lees kan ik me bij het feit aansluiten dat het mooier is wanneer de layout gecentreerd staat. Ik werk op een browsergrootte tussen de 1024*768 en 800*600 ergens, en hier valt het niet zo op, maar wanneer ik mijn borwser de volle 1280*1024 geef is het niet echt mooi meer.

Screenshots zijn genomen met Firefox 0.8 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8)

[ Voor 35% gewijzigd door Ibex op 07-03-2004 10:39 ]

[Ramon]

ik erger me aan die horizontale bruine streep bovenaan, is het niet mogelijk die wit te maken? daarnaast ziet er erg goed uit verder. Is het misschien mogelijk nog een paar posts toe te voegen aan list_messages.html? dan kunnen we nog een betere indruk krijgen misschien?

[dawuss]

Een beetje offtopic, maar ik vraag me af of er, net als op de frontpage, ook een "grey" style komt, die exact hetzelfde is als deze bruine, maar dan dus grijs

[Verwijderd]

Waarschijnlijk wel. Ze houden iig de mogelijkheid open voor alternatieve style sheets.

[chem]

Bij OS X, Camino (gecko browser met mozilla NB als core) ziet het eea er niet zo fleks uit:
http://www.xs4all.nl/~mir...ges%20nieuwe%20layout.jpg

In Safari gaat het meeste goed, maar sommige niet...
http://www.xs4all.nl/~mir...ist_messages%20safari.jpg

en de mod voor Safari is wat vreemder
http://www.xs4all.nl/~mir...messages_mod%20safari.jpg

[Rafe]

Ibex schreef op 07 maart 2004 @ 10:26:
Ook snap ik niet echt waarom er 2 ondertittels lijken te zijn bij crisp; zowel "template hoer" als "bofh".

"Templatehoer" is crisp zijn titel, dus zou je dit nu op GoT draaien zou daar "Moderator W&G" staan. "BOFH" is de ondertitel die iedereen kan invullen

Ohja, de kleuren vind ik niet echt zo mooi, ik hou nogal van het huidige kleur. Zal er een mogelijkheid voorzien worden om de oude kleurtinten in te stellen op de nieuwe template?

Pas de stylesheet aan naar je wensen. Maar de oude vertrouwde GoT template zal voorlopig nog wel even beschikbaar blijven voor iedereen als je het niks vindt

En nu ik eventjes de nieuwe reply's hierboven lees kan ik me bij het feit aansluiten dat het mooier is wanneer de layout gecentreerd staat. Ik werk op een browsergrootte tussen de 1024*768 en 800*600 ergens, en hier valt het niet zo op, maar wanneer ik mijn borwser de volle 1280*1024 geef is het niet echt mooi meer.

D'r komt een pref om de hele layout te centreren als ik het me goed herinner.

Verwijderd schreef op 07 maart 2004 @ 10:23:
begint allemaal wel heel erg te lijken op fok.nl ziet er niet uit.

't Is eigk meer de bedoeling dat het op www.tweakers.net gaat lijken. Maar als je het zo lelijk vindt, geef dan tips waar het volgens jou beter kan

_{Maar dit valt allemaal onder het standaard LA-gezeur waar crisp het over had denk ik}

[ Voor 16% gewijzigd door Rafe op 07-03-2004 11:09 ]

[simon]

Rafe schreef op 07 maart 2004 @ 11:06:

D'r komt een pref om de hele layout te centreren als ik het me goed herinner.

Is er ook een 'screen' van hoe dit er uit zou kunnen gaan zien?

[Ibex]

Rafe schreef op 07 maart 2004 @ 11:06:
[...]

_{Maar dit valt allemaal onder het standaard LA-gezeur waar crisp het over had denk ik}

Idd, maar ik dacht dat dit wel zou kunnen bij de niet LA-commentaar die ik heb gegeven

Owja, had ik al gezegd dat ik het in feite bestwel GoT-waardig vind?

offtopic:
wtf is LA-geleuter in feite

[ Voor 20% gewijzigd door Ibex op 07-03-2004 11:25 ]

[F97]

Als ik in Opera 7.23 op de pagina http://allcrispy.com/got/newlayout/index.html bvb General Chat inklap, dan schuift alles een pixel of tien/twintig naar rechts.

Ik heb nu even geen tijd voor screenshost maar als je die wil, doe ik het straks wel even.

edit:

http://users.pandora.be/deceuninck/t/a.gif
http://users.pandora.be/deceuninck/t/b.gif

Zie je het verschil?

[ Voor 21% gewijzigd door F97 op 07-03-2004 12:58 . Reden: screenshots toegevoegd ]

[flexje]

Op zich een strak layoutje, alleen een paar puntjes waar jullie nog naar kunnen kijken:

- Red titel lettertype veranderen naar Arial Black wat een voorganger al aangaf.
- De QuickSearch op een ander plek zetten, onderaan bijvoorbeeld of links uitlijnen + de dropdownbox aan de rechterkant van de textbox neerzetten ofzo.
- "Bekijk bericht" & "Verstuur bericht" knoppen wat kleiner maken...

Voor de rest vind ik em

[Johnny]

Op de forumindex is de rode teks, zoals al eerder gezegd iets te vet.

De tekst onder de edit/quote staat een beetje in de weg, of moet kleiner en dichter tegen de afbeeldingen.

Dat de contact-icoontjes nu onder het icon staan lijkt me een beetje vervelend omdat iedere post dan altijd een bepaalde lengte krijgt, ookal staat er een regel tekst in, bij lange topics ga je het verschil, met scrollen, zeker merken.

Het huisje en profile icoon zijn allebei nog even lelijk.

De topic-report/bookmarks/todo icoontjes zouden wel een rollover effect mogen hebben, omdat ze nu toch een beetje slecht zichtbaar zijn.

De formulieren, zoals het quick-reply veld zouden ook nog wel wat styling mogen hebben.

[Rafe]

Ibex schreef op 07 maart 2004 @ 11:21:
[...]

Idd, maar ik dacht dat dit wel zou kunnen bij de niet LA-commentaar die ik heb gegeven

offtopic:
wtf is LA-geleuter in feite

De mening van de simpele user die iets te zeggen heeft als "ik vindt de rood-zwarte balk te groot". crisp zit hier denk ik meer te wachten op tips/opmerkingen over de meer technische zaken die te maken hebben met de CSS/HTML code, zoals Verwijderd in "Nieuw GoT Design - (X)HTML feedback"

offtopic:
Nu ik het toch over die post hebt: de templateparser zet alles zo op een rij, afaik is de code in de template 'source' wel mooi leesbaar.

Simon: voorzover ik weet niet. Maar je zou even Photoshop er bij kunnen pakken en het dan centreren

[quakerix]

The page cannot be displayed
There are too many people accessing the Web site at this time.

Please try the following:

Click the Refresh button, or try again later.

Open the allcrispy.com home page, and then look for links to the information you want.
HTTP 403.9 - Access Forbidden: Too many users are connected
Internet Information Services

Technical Information (for support personnel)


Background:
This error can occur if the Web server is busy and cannot process your request due to heavy traffic.

More information:
Microsoft Support

Die server is erg druk bezig ?

edit: het werkt weer ziet er mooi uit !! Dat in rood dik gedrukt Gather of the Tweakers.net - Forum index kan idd. van mij apart in 'normal'

[ Voor 24% gewijzigd door quakerix op 07-03-2004 11:55 ]

[Thijsmans]

Dat komt door 65.000 f5-ende GoTters

Verwijderd schreef op 07 maart 2004 @ 03:42:
Zoals al wel vaker is gezegd volgens mij, maar dan nog maar een keer in dit topic:
De rode titel is niet zo mooi. Arial Black is mooi, maar niet ook nog eens bold

Zoals je het nu hebt: Arial Black, Bold
[afbeelding]

Zo vind ik het mooier: Arial Black, Normaal
[afbeelding]

(edit: anders maak ff een poll )

Tsja, dat zal wel een mening zijn. Ik vind het bold wel mooier. Zonder bold valt het ook een beetje buiten de T.net-layout.


Zelf ervaar ik het als vervelend dat de menu's bovenaan open blijven staan als je er vanaf hovert via een link. Dat is btw ook zo op T.net

Dan het knopje voor de username waarmee je de volgende tekst laat verschijnen:

Berichten: 29
Reg. datum: 17 januari 2004

Gelukkig standaard verborgen, maar ik vraag me af wat het nut is van deze feature Maar ja, het doet geen kwaad


Verder: strak en netjes

[Ramon]

als ik de stylesheet uitzet, dan vallen me een paar dingen op die volgens mij niet helemaal kloppen. Bijvoorbeeld dat de banner niet bovenaan staat, en als ik op 'spring voorbij navigatie', dan springt ie ook voorbij de topicnaam. Er is imho veels te veel loze ruimte tussen de posters naam en het eigenlijke bericht. Daarnaast is het misschien ook een goed idee om naast H1 voor 'Gathering of Tweakers' ook H2 t/m H6 te gebruiken voor subheaders, zoals bijvoorbeeld de posters' naam?

[ Voor 4% gewijzigd door Ramon op 07-03-2004 12:09 ]

[m33p]

Je webserver ligt er uit of iets dergelijks op het moment?

[GGS_206]

m33p schreef op 07 maart 2004 @ 12:10:
Je webserver ligt er uit of iets dergelijks op het moment?

Doet het wel hoor, die laatste link in de topicstart doet het niet, die andere 2 wel

[Korakal]

Prammenhanger schreef op 07 maart 2004 @ 12:08:
Zelf ervaar ik het als vervelend dat de menu's bovenaan open blijven staan als je er vanaf hovert via een link. Dat is btw ook zo op T.net

Eensch, daar was ik net ook mee aan het prutsen Wat mij betreft mag het menu'tje weer dicht als je eraf gaat met je muis. Je bent namelijk ook je quicksearch panel kwijt als je menu openstaat, door bijv per ongeluk eroverheen te zijn gemuisd.

Verder viel me nog wat anders op:

Waarom staan deze niet uitgelijnd boven elkaar? Op de huidige FP is dat wel, dus qua vulling zou het moeten passen.
Komt het wellicht omdat er nog vulling is of blijft dit scheef t.o.v. elkaar staan?

Verder kan ik me in een aantal dingetjes die hier al zijn aangedragen ook wel vinden maar die hoef ik niet te herhalen

[edit]

Er schoot me nog wat over 'usability' te binnen waar ik mijn twijfels over heb of het alleen voor mijzelf geldt of voor meer mensen:
de quote/edit/delete message knoppen had ik een paar keer per ongeluk de tekst eronder te pakken ipv de knop zelf. Blijkbaar ga ik intuïtief ervanuit dat de tekst eronder ook clickbaar is. Ik zeg dus niet dat het anders moet, maar wel dat je er misschien nog over moet nadenken

[ / ]

Voor de rest: kanniewachten

[ Voor 26% gewijzigd door Korakal op 07-03-2004 12:24 ]

[chem]

crisp schreef op 07 maart 2004 @ 03:02:
wat ik graag zou willen is feedback vanuit de meer professionele hoek (dus niet het standaard LA-gezeur): voldoet dit aan usability eisen? is het intuitief genoeg? kan de code/structuur nog geoptimaliseerd/verbeterd worden?

kortom: is dit GoT-waardig?

hallo!

Ik zie allemaal reacties over gemiereneuk (enorm LA waardig materiaal), en weinig concrete en beargumenteerde feedback.

gezeur over "het lijkt op fok", "ik vind die streep niet mooi" of "in browser X mis ik bij Y een paar pixels" is echt kansloos geneuzel...

Jammer dat het toch weer vervalt in een LA discussie.

Stom genoeg heb ik zelf ook zo'n reactie geplaatst, maar goed.

[chem]

Om toch een reactie in de goede richting te geven...
het menu: de searchbox verdwijnt soms, wat erg vreemde effecten geeft (het voelt niet natuurlijk aan). Daarbij missen er pulldowns bij sommige opties, wat het idee geeft dat het niet werkt oid... ?
Onder AT kan nog een "My AT", "AT zonder filter" bv.
Ook mis ik een pulldown onder de g.t.n. tekst in het menu, wat bij t.net wel opties geeft.
Al met al is dat wat inconsistent.

Ik neem aan dat er weer Accesskeys zijn gedefinieerd. Is het mogelijk om uit te vinden welke dit zijn voor de gebruiker? Bv onderstrepen?
BBEdit heeft in het Zoekvenster belachelijk veel opties, en toont standaard niet de shortcuts totdat je de apple-toets (ctrl-achtig) indrukt, en vv verschijnen ze. Intuitief en toch overzichtelijk.

Het 'berichten' tellertje zou imho beter de link naar de posthistory kunnen zijn.
Sowieso zijn de items in het uitklapmenu niet aanklikbaar, wat erg precies mikken betekent. Dit geldt ook voor edit/quote/delete linkjes etc.

Bij Mozilla is het met ctrl-click in een TD mogelijk de content in 1x te selecteren, wat niet meer kan met divjes. Nu hoef je niet van mij alles in table's te gooien, maar het was wel heel makkelijk

De interactie van verplaatstopic-pulldown bij verkeerde opties is goed

De verwijder/verplaats is ook netjes

Bovenaan wel new topic, onderaan niet. Wat is hier de gedachte achter?

---

Bij base_grey hebben we bij nogal wat onderdelen bovenaan ruimte gereserveerd voor meer informatie, wat vooral voor beginners makkelijk is. Wordt hier nog rekening mee gehouden?
crisp: kijk maar eens naar http://www.xs4all.nl/~mirenmer/base_grey%20uitleg.jpg

[Verwijderd]

chem schreef op 07 maart 2004 @ 12:17:
[...]

hallo!

Ik zie allemaal reacties over gemiereneuk (enorm LA waardig materiaal), en weinig concrete en beargumenteerde feedback.

gezeur over "het lijkt op fok", "ik vind die streep niet mooi" of "in browser X mis ik bij Y een paar pixels" is echt kansloos geneuzel...

Jammer dat het toch weer vervalt in een LA discussie.

Stom genoeg heb ik zelf ook zo'n reactie geplaatst, maar goed.

Het kan aan mij liggen, maar is het voor jullie niet belangrijk om te weten hoe de xbrowser compatibility is?... Lijkt me dus zeker geen LA spul...

[coubertin119]

Die paar kleine foutjes boeien niet, het gaat 'em nu over de bruikbaarheid, over de code en over de structuur. Geneuzel over die paar kleine dingen kan later nog wel.

Vooral de list_messages is overzichtelijk, de index mist nog wel iets ondefinieerbaars.

[ Voor 23% gewijzigd door coubertin119 op 07-03-2004 12:51 ]

[crisp]

mogguh

ik ben nu even bezig de HTML wat leesbaarder te maken; ik heb daar vannacht niet zo bij nagedacht dat dit erg moeilijk te bekijken is zo
Verder ga ik het even op de crewservert zetten, want mijn IIS trekt het niet zo...

[André]

In de stylesheet regel de media toevoegen:

HTML:

<link rel="stylesheet" href="css/tweakers_192.css" title="default" />

<link rel="stylesheet" href="css/tweakers_192.css" title="default" media="screen" />
<link rel="stylesheet" href="css/tweakers_192.css" title="default" media="print" />

• In sommige TD's staat een style tag, kan die niet beter vervangen worden door een class?
• Direct na de body staat een <div id="layout"> die als ik het goed zie aan het einde van de body ophoud. Ik weet niet waarvoor die gebruikt word maar die lijkt me overbodig want je kunt daarvoor de body gebruiken.
• De rode titel van Arial Black Bold naar Arial Bold.
• Als je met de muis van het pulldownmenu afgaat dan direct sluiten.
• Vervang de quicksearch pulldown door een DHTML pulldown zodat je die niet hoeft laten te verdwijnen.
• Als laatste: ik heb ooit een tooltje gehad die in HTML pagina's alle gelijke classes enzo een andere naam gaf van maar 1 of 2 letters. Daardoor kun je een groot aantal bytes wegkrijgen. Ook <td style="text-align:center"> kan worden verkleind naar <td class="c">. Met de zeer grote aantal bezoekers is elk byteje dat weg kan winst.

[Not Pingu]

(op het gevaar af dat dit als niet technisch genoeg wordt gezien)

Ik kan goed begrijpen dat jullie de stijl van het forum gelijk willen trekken met die van de frontpage, maar imho heeft de frontpage wat meer balans wat kleur betreft. ook is de FP uit zichzelf wat kleurrijker doordat er doorgaans veel plaatjes op te zien zijn.
Op GoT loop je het gevaar dat het er ontzettend saai en leeg uit gaat zien.

Mijn suggestie: verander de kleurstellingen een beetje: wat feller en kleurrijker misschien, dat helpt ten eerste om FP en GoT te onderscheiden en maakt het aantrekkelijker om te gebruiken.

[Verwijderd]

André schreef op 07 maart 2004 @ 13:17:
In de stylesheet regel de media toevoegen:

HTML:

<link rel="stylesheet" href="css/tweakers_192.css" title="default" />
<link rel="stylesheet" href="css/tweakers_192.css" title="default" media="screen" />
<link rel="stylesheet" href="css/tweakers_192.css" title="default" media="print" />

• In sommige TD's staat een style tag, kan die niet beter vervangen worden door een class?

Waarschijnlijk wel ja. Maar het is nog in ontwikkeling.

• Direct na de body staat een <div id="layout"> die als ik het goed zie aan het einde van de body ophoud. Ik weet niet waarvoor die gebruikt word maar die lijkt me overbodig want je kunt daarvoor de body gebruiken.

Laatste keer dat ik er tests mee heb uitgevord gaf dat problemen in bepaalde browsers. Het is er voor compatibility, en het gaf een eenvoudigere mogelijkheid om te switchen tussen centreren en niet.

• De rode titel van Arial Black Bold naar Arial Bold.

In het design stond er Arial Black, dus daar kwam Arial Black. Als dat anders moet, is dat zo aangepast, en het heeft wat mij betreft niets met techniek of accessibility van doen. Dat soort opmerkingen mag in het LA topic wmb.

• Als je met de muis van het pulldownmenu afgaat dan direct sluiten.

Niet iedereen is even behendig met de muis. Het is er voor accessibility.

• Vervang de quicksearch pulldown door een DHTML pulldown zodat je die niet hoeft laten te verdwijnen.

Dat is visueel wel leuk en aardig, maar liever niet. Het gaat om een keuzeformulier, laten we alsjeblieft standaard invoerelementen gebruiken. Anders kun je zonder javascipt het forum niet goed gebruiken.

• Als laatste: ik heb ooit een tooltje gehad die in HTML pagina's alle gelijke classes enzo een andere naam gaf van maar 1 of 2 letters. Daardoor kun je een groot aantal bytes wegkrijgen. Ook <td style="text-align:center"> kan worden verkleind naar <td class="c">. Met de zeer grote aantal bezoekers is elk byteje dat weg kan winst.

Klopt, maar dit zijn development versies. Die moeten leesbaar zijn voor de developer. Dat kan altijd nog gestript worden.

[ Voor 7% gewijzigd door Verwijderd op 07-03-2004 13:27 ]

[Verwijderd]

Verwijderd schreef op 07 maart 2004 @ 08:56:
(Anne vraagt zich af of er ook documenten zijn in dit stadium met leesbare broncode)

Geen idee, ik heb nog wel wat plain HTML templates, maar daar is inmiddels het een en ander aan verbouwd, dus dat is niet echt representatief meer. Ook ging het n beetje te veel in de richting van standaarden en accassibility, heb ik me laten vertellen...

Ik wil iig alvast opmerken dat jullie alle META met het HTTP-EQUIV kunnen droppen in het voordeel van een server-side afhandeling. Het blijft \xml:lang="nl"\ en niet \"nl_NL"\ oid.

Dat is een kleine aanpassing die zo is gemaakt. De testserver waar het in eerste instantie op stond deed dit niet helemaal correct. Waar dat nl_NL vandaan komt is mij ook een raadsel.

Ook ben ik van mening dat als je graag TARGET wilt gebruiken je niet met een XHTML1.0 Strict Doctype moet komen aanzetten. En dit soort dingen:

code:

  ....net/admin/admin.php?data%5Bstep%5D=2&action=lookup_user&data%5Bsearch%5D=use

(uit de validator) is natuurlijk het ergste en dat kun je niet met een of ander smoesje van de hand doen. Voor een ampersand dien je gewoon een entiteit te gebruiken, zo simpel is het.

Inderdaad.

Edit: het was blijkbaar nog erger. Meerdere ID attributen in hetzelfde document met dezelfde waarde. Deze is ook nog wel leuk:

code:

</li>&nbsp;<li>

En ik vraag me echt af waarom jullie CENTER gebruikt hebben. En een SPAN na het HTML element etc.

Die laatste zooi is niet aan te passen in de templates. Het hoort er gewoon helemaal niet te staan, en als het er staat, dan moet het in comment-tags. Die center tag is er vanwege de huidige templates, en hoort inderdaad in de prullenbak. Meerdere dezelfde id's mogen inderdaad niet, geen idee waarom het wel zo is.

[ Voor 7% gewijzigd door Verwijderd op 07-03-2004 13:34 ]

[Osiris]

chem schreef op 07 maart 2004 @ 12:30:
het menu: de searchbox verdwijnt soms, wat erg vreemde effecten geeft (het voelt niet natuurlijk aan).

In Opera verdwijnt zowel de banner als de searchbox als je over een menu-item heenbeweegt

[kleautviool]

Waarom gebruiken jullie in het dropdown-menutje linksonderaan op http://allcrispy.com/got/newlayout/index.html geen optgroup. Dat staat wat duidelijker (en mooier) dan allemaal options .

Ik mis eigenlijk ook lijnen tussen de verschillende td's op de voorpagina. Het ziet er nu zo als 1 geheel uit. In het eerste oogopslag is dit imho niet echt duidelijk.

Zie deze screenshot. Die tabel die breder is dan de rest staat niet zo mooi

Verder eigenlijks niks te zeuren, ziet er strak uit!

[Clay]

eerst hulde dan schieten:

in "div#header p" staat de breadcrumb naar het topic toe. Nou is een breadcrumb niet echt een list, maar de <img />'s die je gebruikt kan je imo door de CSS laten doen, gewoon de link een padding-left geven, en die arrow als bgimage ervoor. Ik ben sowieso van mening dat de <img /> alleen praktisch is voor afbeeldingen in je content, en niet voor dit soort dingen. Bovendien maakt het het skinnen makkelijker Dit zou evt ook voor quote, view en andere buttons kunnen. Het zou ook flink wat html code schelen als al die image tags weggewerkt zouden worden

in "div#header div.title" staat de werkelijke title achter een nbsp; zonder tag erbij. (Ik neem aan dat alles wat er voor zit dan float?) Doe die nbsp aub weg en maakt van die title een echte header? Is dat overigens een unieke class ? ik zie em nergens terug komen namelijk...

moet pageCounter geen list bevatten?

HTML:

<a name="contentstart"></a>

Ik dacht dat die dingen overbodig zijn. Iig in alle fatsoenlijke browsers die ik ken kan je ook naar ID's springen met een anchor. Al moet ik wel ff toegeven dat ik dat nou net niet in lynx heb getest, en dat zal zo'n beetje de enige app zijn waar je het echt nodig gaat hebben...

HTML:

<div class="subtitle">BOFH</div>

Misschien header van maken? Er zitten imo sowieso weinig header tags in, en die zijn toch wel handig

En misschien kijk ik verkeerd, maar het ziet er heel erg naar uit dat de homepage link in .post .userdata niet wordt gesloten...

werkt dit ooit (en waar is het voor nodig?):

code:

try{ document.domain='tweakers.net' }catch(e){}

[ Voor 25% gewijzigd door Clay op 07-03-2004 14:00 ]

[chem]

kleautviool schreef op 07 maart 2004 @ 13:49:
Waarom gebruiken jullie in het dropdown-menutje linksonderaan op http://allcrispy.com/got/newlayout/index.html geen optgroup. Dat staat wat duidelijker (en mooier) dan allemaal options .

omdat die lijst zo door React wordt uitgepoept. En dat is weer zo, omdat niet alle browsers een optgroup begrijpen.

[Verwijderd]

Clay schreef op 07 maart 2004 @ 13:50:
in "div#header p" staat de breadcrumb naar het topic toe. Nou is een breadcrumb niet echt een list, maar de <img />'s die je gebruikt kan je imo door de CSS laten doen, gewoon de link een padding-left geven, en die arrow als bgimage ervoor. Ik ben sowieso van mening dat de <img /> alleen praktisch is voor afbeeldingen in je content, en niet voor dit soort dingen. Bovendien maakt het het skinnen makkelijker Dit zou evt ook voor quote, view en andere buttons kunnen. Het zou ook flink wat html code schelen als al die image tags weggewerkt zouden worden

Eens, eens, eens. Maar hey, sommige dingen moesten per se op een bepaalde manier, en met plaatjes, het designers verhaal.

in "div#header div.title" staat de werkelijke title achter een nbsp; zonder tag erbij. (Ik neem aan dat alles wat er voor zit dan float?) Doe die nbsp aub weg en maakt van die title een echte header? Is dat overigens een unieke class ? ik zie em nergens terug komen namelijk...

Het was oorspronkelijk ook een h1, geen idee waarom dat nu anders is.

moet pageCounter geen list bevatten?

Eigenlijk wel, helaas zijn er alleen geen inline list elementen. Een tekortkoming van HTML.

HTML:

<a name="contentstart"></a>

Ik dacht dat die dingen overbodig zijn. Iig in alle fatsoenlijke browsers die ik ken kan je ook naar ID's springen met een anchor. Al moet ik wel ff toegeven dat ik dat nou net niet in lynx heb getest, en dat zal zo'n beetje de enige app zijn waar je het echt nodig gaat hebben...

Lynx doet dat helemaal prima, ook als je een willekeurig element een id geeft en dan naar #id linkt. <a name is ranzig, en helemaal als je het element leeg laat, want dan werkt het niet altijd even lekker.

HTML:

<div class="subtitle">BOFH</div>

Misschien header van maken? Er zitten imo sowieso weinig header tags in, en die zijn toch wel handig

Ik denk toch eerder een <p> ofzo. Dit zijn zaken die vaak niets zeggen over de content die volgt.

werkt dit ooit (en waar is het voor nodig?):

code:

try{ document.domain='tweakers.net' }catch(e){}

Ik heb werkelijk geen idee, je zou eigenlijk nooit aan document.domain moeten hoeven komen.

[ Voor 6% gewijzigd door Verwijderd op 07-03-2004 14:02 ]

[Verwijderd]

chem schreef op 07 maart 2004 @ 13:57:

omdat die lijst zo door React wordt uitgepoept. En dat is weer zo, omdat niet alle browsers een optgroup begrijpen.

Waar je wat mij betreft verder maling aan moet hebben, als ze geen optgroup begrijpen laten ze alleen de fora zien. En dat is op zich goed genoeg, ale content is bereikbaar.

[Clay]

Eens, eens, eens. Maar hey, sommige dingen moesten per se op een bepaalde manier, en met plaatjes, het designers verhaal.

jah, ik bedoel ook niet dat je helemaal geen plaatjes moet gebruiken maar dat je de plaatjes van je interface ook met css zet, en niet met een img tag. Niet alleen de tilende bg vlakken, maar ook buttons etc.

[Verwijderd]

Wat ik wel jammer vind, is dat er tegenwoordig nog steeds niet gebruik wordt gemaakt van de processorkracht bij een client zelf.

Ik zie in de source nog steeds de postings gerenderd in de source staan. Waarom output je de postings niet als een js array, en bouw je dynamisch je postings op? De voordelen zijn namelijk best enorm, de mogelijkheden zijn al lang en breed beschikbaar en krachtig, en de processorkracht bij clients is overkill.

[Verwijderd]

Verwijderd schreef op 07 maart 2004 @ 14:05:
Wat ik wel jammer vind, is dat er tegenwoordig nog steeds niet gebruik wordt gemaakt van de processorkracht bij een client zelf.

Ik zie in de source nog steeds de postings gerenderd in de source staan. Waarom output je de postings niet als een js array, en bouw je dynamisch je postings op? De voordelen zijn namelijk best enorm, de mogelijkheden zijn al lang en breed beschikbaar en krachtig, en de processorkracht bij clients is overkill.

Accessibility. Browsers als Lynx behoren ook tot het doel, in verband met de doelgroep van GoT. Het wordt ongetwijfeld gewaardeerd als iemand onder linux zonder grafische shell topics kan lezen.

[chem]

Verwijderd schreef op 07 maart 2004 @ 14:03:
[...]

Waar je wat mij betreft verder maling aan moet hebben, als ze geen optgroup begrijpen laten ze alleen de fora zien. En dat is op zich goed genoeg, ale content is bereikbaar.

Bijkomend nadeel is dat je niet naar een optgroup kan navigeren (een categorie dus).

[Verwijderd]

Waarom het design veranderen.

GOT is al jaren lang het mooiste lelijke forum wat er bestaat, en heeft bij menig tweaker het hart veroverd.

Daarnaast snap ik ook niet helemaal waarom het forum bij de layout van Tweakers.net getrokken moet worden.

Tweakers.net = "ook" mainstream, terwijl GOT toch juist het intulectueele kindje is wat erachter draait.

[Verwijderd]

Verwijderd schreef op 07 maart 2004 @ 14:08:
[...]

Accessibility. Browsers als Lynx behoren ook tot het doel, in verband met de doelgroep van GoT. Het wordt ongetwijfeld gewaardeerd als iemand onder linux zonder grafische shell topics kan lezen.

Vandaar

Ik ben overigens wel benieuwd hoe de stap naar CSS layouted design is bevallen. Maar nog belangrijker:

- tov tables hoeveel extra tijd heeft het gekost
- wat waren pijnpunten
- welke zaken kwam je tegen die zeer complex of niet mogelijk waren met css
- als je nu een wijziging wilt maken in je layout loop je tegen problemen aan omdat zaken zijn genest in relative/absolute blocks?

Kortom, een review van het productie gedeelte Ik ben zelf nu al een behoorlijke tijd bezig met het omzetten van een CMS backend interface naar CSS layouted, en het kost zoveel tijd.

[ Voor 52% gewijzigd door Verwijderd op 07-03-2004 14:16 ]

[Verwijderd]

chem schreef op 07 maart 2004 @ 14:09:

Bijkomend nadeel is dat je niet naar een optgroup kan navigeren (een categorie dus).

Kun je kijken hoe vaak het wordt gebruikt? Je kunt er vanaf de index nog wel gewoon komen. We hebben het hier over prutsbrowsers die het niet ondersteunen.

[chem]

Verwijderd schreef op 07 maart 2004 @ 14:11:
Waarom het design veranderen.

GOT is al jaren lang het mooiste lelijke forum wat er bestaat, en heeft bij menig tweaker het hart veroverd.

Daarnaast snap ik ook niet helemaal waarom het forum bij de layout van Tweakers.net getrokken moet worden.

Tweakers.net = "ook" mainstream, terwijl GOT toch juist het intulectueele kindje is wat erachter draait.

lees de fucking startpost eens.

[Grijze Vos]

over usability dan:

New topics hebben niks met huidige topics te maken. Dus die knop mag(moet) weg.
(Ja, geen hoogwaardige reply oid, maar zeker niet onbelangrijk. Structuur gaat boven alles in fora.)

[Fietsbel]

Verwijderd schreef op 07 maart 2004 @ 14:11:
Waarom het design veranderen.

GOT is al jaren lang het mooiste lelijke forum wat er bestaat, en heeft bij menig tweaker het hart veroverd.

Daarnaast snap ik ook niet helemaal waarom het forum bij de layout van Tweakers.net getrokken moet worden.

Tweakers.net = "ook" mainstream, terwijl GOT toch juist het intulectueele kindje is wat erachter draait.

Ik denk dat je het beste voor zulke posts in het volgende topic kan wezen: Betreft: nieuwe design en daar de discussie te voeren ipv hier waar puur het techische gedeelte aan te pas komt.

[Verwijderd]

Grijze Vos schreef op 07 maart 2004 @ 14:13:
over usability dan:

New topics hebben niks met huidige topics te maken. Dus die knop mag(moet) weg.
(Ja, geen hoogwaardige reply oid, maar zeker niet onbelangrijk. Structuur gaat boven alles in fora.)

Houd je er ook rekening mee dat bijna alle fora het zo doen? Als je het weghaalt omdat het dan beter te gebruiken is, sla je dan niet de plank helemaal mis? Je moet óók rekening houden met zaken die zijn ingeburgerd.

[Genoil]

Clay schreef op 07 maart 2004 @ 13:50:
eerst hulde dan schieten:

in "div#header p" staat de breadcrumb naar het topic toe. Nou is een breadcrumb niet echt een list, maar de <img />'s die je gebruikt kan je imo door de CSS laten doen, gewoon de link een padding-left geven, en die arrow als bgimage ervoor. Ik ben sowieso van mening dat de <img /> alleen praktisch is voor afbeeldingen in je content, en niet voor dit soort dingen. Bovendien maakt het het skinnen makkelijker Dit zou evt ook voor quote, view en andere buttons kunnen. Het zou ook flink wat html code schelen als al die image tags weggewerkt zouden worden

Op zich heb je helemaal gelijk, maar als IE6 user met de cache-instelling op "every-visit" (waarvan er in /14 wel meer moeten rondlopen), ga je last krijgen van knipperende background-images, ook al zijn er geen pseudoclasses gedefineerd.

Dus ook al is een A met background-image semantisch veel correcter, je gaat je er een hoop gezanik mee op de hals halen, en ik heb zo het idee dat de bouwers hiermee rekening hebben gehouden. Erg goed!

Natuurlijk kun je ook mijn 13373 f1x B) gebruiken, maar ik geef toe dat dat wel een beetje teveel van het goede is

[Grijze Vos]

Verwijderd schreef op 07 maart 2004 @ 14:16:
[...]

Houd je er ook rekening mee dat bijna alle fora het zo doen? Als je het weghaalt omdat het dan beter te gebruiken is, sla je dan niet de plank helemaal mis? Je moet óók rekening houden met zaken die zijn ingeburgerd.

Ik schop graag tegen de geordende veste.
Maar even serieus, ik run 2 (in vergelijking met dit forum) kleine fora. In totaal ongeveer 300 users. Heb nog nooit iemand horen klagen over de afwezigheid van die knop. Lijkt me dat ik daar wel iets van had gehoord, als dat zo 'ingeburgerd' was. Kheb die knop ook nooit gebruikt op andere fora.

[Verwijderd]

Genoil schreef op 07 maart 2004 @ 14:16:

Op zich heb je helemaal gelijk, maar als IE6 user met de cache-instelling op "every-visit" (waarvan er in /14 wel meer moeten rondlopen), ga je last krijgen van knipperende background-images, ook al zijn er geen pseudoclasses gedefineerd.

Dus ook al is een A met background-image semantisch veel correcter, je gaat je er een hoop gezanik mee op de hals halen, en ik heb zo het idee dat de bouwers hiermee rekening hebben gehouden. Erg goed!

Ik zou het toch lekker op de correcte manier hebben gedaan. Het is wellicht een beetje storend, maar dat zijn wel meer dingen. Het maakt het forum niet onbruikbaar.
Het uiteindelijke doel is volledig correcte markup, dat betekent niet alleen dat het ongeschonden door de validator komt, dat betekent vooral dat het semantisch correct is.

[Genoil]

Verwijderd schreef op 07 maart 2004 @ 14:20:
[...]

Ik zou het toch lekker op de correcte manier hebben gedaan.

Zodat je op elk zeik-topic a la "bah de pijltjes knipperen" kunt zeggen:"ja dat weten we, maar het is wel semantisch correct!"

[André]

Genoil schreef op 07 maart 2004 @ 14:30:
[...]


Zodat je op elk zeik-topic a la "bah de pijltjes knipperen" kunt zeggen:"ja dat weten we, maar het is wel semantisch correct!"

Maar dat knipperen was toch alleen bij het animeren van objecten met background plaatjes? Of is dat ook bij het scrollen?

[Mx. Alba]

Het schijnt dat sommige browsers (IE op Mac ofzo) buggen op een xml tag voor de doctype definitie... Ze laten dan alleen een lege pagina zien.

[Genoil]

André schreef op 07 maart 2004 @ 14:33:
[...]

Maar dat knipperen was toch alleen bij het animeren van objecten met background plaatjes? Of is dat ook bij het scrollen?

Je krijgt het bij elke anchor met een background-image, wanneer je er overheen hovert of er op klikt, ook al heb je geen aparte :hover en :active states gedefineerd.

Een workaround is wellicht om de background-image in de th te zetten, en een "onzichtbare" anchor eroverheen te leggen.

[crisp]

Verwijderd schreef op 07 maart 2004 @ 14:20:
[...]

Ik zou het toch lekker op de correcte manier hebben gedaan. Het is wellicht een beetje storend, maar dat zijn wel meer dingen. Het maakt het forum niet onbruikbaar.
Het uiteindelijke doel is volledig correcte markup, dat betekent niet alleen dat het ongeschonden door de validator komt, dat betekent vooral dat het semantisch correct is.

Toevoeging: waarbij telkens weer afwegingen gemaakt moeten worden; browser-compatibiliteit is hierbij de grootste faktor. De reden bijvoorbeeld dat ik weinig headers gebruik is puur omdat IE daar zo gigantisch mee bugt.

Ik ga nu even de previews op de crewserver zetten, want mijn webserver trekt het niet (is ook geen productieserver); daarna ga ik er even voor zitten om op alle opmerkingen inhoudelijk in te kunnen gaan

[Verwijderd]

Mx. Alba schreef op 07 maart 2004 @ 14:35:
Het schijnt dat sommige browsers (IE op Mac ofzo) buggen op een xml tag voor de doctype definitie... Ze laten dan alleen een lege pagina zien.

Indeed. Ik stel voor om "<!-- -->" ipv dat ding daar neer te zetten, is nog korter ook!

[Verwijderd]

Ik zou heel die XML declaration weglaten. Quirks mode is niet volgens de standaarden.

[Verwijderd]

Ik denk dat het beter is voor de layout in IE6. En IE6 kent geen standaarden hoor, dus zo'n probleem is het niet.

Edit, het viel me nog op dat er totaal niks gedaan is aan posts. In plaats van leuk het P element te gebruiken zie ik allemaal dubbele BR'etjes in de broncode staan

[ Voor 45% gewijzigd door Verwijderd op 07-03-2004 14:51 ]

[terabyte]

Verwijderd schreef op 07 maart 2004 @ 14:05:
Ik zie in de source nog steeds de postings gerenderd in de source staan. Waarom output je de postings niet als een js array, en bouw je dynamisch je postings op? De voordelen zijn namelijk best enorm, de mogelijkheden zijn al lang en breed beschikbaar en krachtig, en de processorkracht bij clients is overkill.

Dan moet je rekening houden met de browser en platform van de client.
En dat is moelijk, omdat er nog steeds een veelgebruikte browser is die zich niet aan de standaard houdt. Dan moet je worarounds verzinnen waardoor je code bloated wordt.
Bloated heeft tot gevolg dat het teveel troep bevat, waardoor de code groter wordt en dus onnodig langzamer wordt gerenderd.

Maargoed, blijkbaar heb ik een totaal andere kijk hierop dan jij, aangezien ik altijd zoveel mogelijk op de server probeer te genereren en vervolgens correcte (X)HTML en CSS naar de client stuur.
Verder hebben browsers die zich dan wel aan de standaard houden geen last van de eventuele workarounds voor andere browsers.

Clean & Simple.

[crisp]

even naar crewserver geupload en leesbaar gemaakt; ik zal gaandeweg ook wat opmerkingen al gaan verwerken; bedenk dat dit WIP is en nog geenszins definitief:

http://crew.tweakers.net/crisp/newlayout/index.html
http://crew.tweakers.net/crisp/newlayout/list_messages.html
http://crew.tweakers.net/...ut/list_messages_mod.html

[Verwijderd]

Verwijderd schreef op 07 maart 2004 @ 14:49:
Ik denk dat het beter is voor de layout in IE6. En IE6 kent geen standaarden hoor, dus zo'n probleem is het niet.

In strict mode moet het prima gaan hoor. Gewoon een beetje handig omgaan met het boxmodel, want dat is gewoonlijks het grootste probleem. Bepaalde technieken hebben in alle boxmodels hetzelfde effect.

[André]

Over mijn eerder opmerking om die pulldown voor de zoekmachine te veranderen in een DHTML dingetje: Deze pulldown is niet cruciaal voor de navigatie in textbrowsers dus het kan best een DHTML iets worden.

[terabyte]

André schreef op 07 maart 2004 @ 14:52:
Over mijn eerder opmerking om die pulldown voor de zoekmachine te veranderen in een DHTML dingetje: Deze pulldown is niet cruciaal voor de navigatie in textbrowsers dus het kan best een DHTML iets worden.

Maar het werkt toch goed zoals het nu is?

edit:
Het is natuurlijk niet de bedoeling om features te gebruiken omdat je zoveel mogelijk features wilt gebruiken... (en dat misschien ten koste van browsercompatibiliteit) Zoals ik net al zei: Clean & Simple, dat is waar je in eerste instantie van moet uitgaan. Extra (overbodige) frut komt later wel.

Oh, ik zie het al: je bent een DHTML lover...

[ Voor 29% gewijzigd door terabyte op 07-03-2004 14:57 ]

[André]

Ik zie trouwens ook een form staan (formsubmit) met een aantal hidden fields: "Never trust user input".

[crisp]

Verwijderd schreef op 07 maart 2004 @ 14:49:
Ik denk dat het beter is voor de layout in IE6. En IE6 kent geen standaarden hoor, dus zo'n probleem is het niet.

Edit, het viel me nog op dat er totaal niks gedaan is aan posts. In plaats van leuk het P element te gebruiken zie ik allemaal dubbele BR'etjes in de broncode staan

Anne: net als je voorgaande posts geef je af op zaken die buiten de templates vallen; de meeste dingen die niet valideren of semantisch niet correct zijn komen uit React zelf en daar heb ik geen enkele invloed op...

André schreef op 07 maart 2004 @ 14:52:
Over mijn eerder opmerking om die pulldown voor de zoekmachine te veranderen in een DHTML dingetje: Deze pulldown is niet cruciaal voor de navigatie in textbrowsers dus het kan best een DHTML iets worden.

Dat is een afweging die ik nog aan het maken ben; veel browsers hebben er geen probleem mee om een div over de select te laten vallen; enkel IE kan dat niet.
De Iframe ga ik ook nog vervangen, en het wel of niet verbergen van de banner en/of de quicksearch wil ik nog gaan optimaliseren (afhankelijk maken van de gebruikte browser).

André schreef op 07 maart 2004 @ 14:58:
Ik zie trouwens ook een form staan (formsubmit) met een aantal hidden fields: "Never trust user input".

Dat wordt serverside wel gevalideerd verder hoor

[ Voor 10% gewijzigd door crisp op 07-03-2004 15:00 ]

[Verwijderd]

André schreef op 07 maart 2004 @ 14:58:
Ik zie trouwens ook een form staan (formsubmit) met een aantal hidden fields: "Never trust user input".

Ik vraag me af wat je hiermee bedoelt.

[André]

Verwijderd schreef op 07 maart 2004 @ 15:00:
[...]

Ik vraag me af wat je hiermee bedoelt.

Dat die waardes te veranderen zijn door de user. En crisp zegt dat ze serverside toch wel gevalideerd worden, dan hoeven ze er ook niet in te staan toch.

[alienfruit]

Ik vind de pagina er mooi en wat verzorgder voorkomen dan de huidige pagina. Enig probleem wat ik had toen ik de pagina openende zijn de kleuren, ik vind deze wat minder rustgevend dan het huidige blauw. Waarschijnlijk willen jullie het rode/bruine kleurcombi gebruiken omdat dit ook op de frontpage wordt gebruikt.

Naar mijn mening maakt bruin/rood niet zoveel uit op een frontpage omdat hier niet zo snel veel lappen tekst hoeft te lezen, wat wel het geval is op het forum. Dus het zou leuk zijn als er een manier was om een soort kleurcombinatie te kiezen "Warm Grey" en bijv. "Cold Blue"

Trouwens wordt het forum weer gecentreerd? Het lijkt er namelijk niet op

Verder vind ik het er allemaal mooi uitzien, beter dan Topique

[ Voor 8% gewijzigd door alienfruit op 07-03-2004 15:05 ]

[Verwijderd]

André schreef op 07 maart 2004 @ 15:02:

Dat die waardes te veranderen zijn door de user. En crisp zegt dat ze serverside toch wel gevalideerd worden, dan hoeven ze er ook niet in te staan toch.

Sommige dingen staan er juist vanwege een bepaalde beveiliging. Het reactid bijvoorbeeld.

[Verwijderd]

edit:
Probleem is dus dat ik het REACT systeem niet ken, is zeker erg lastig om aan te gaan passen, nietwaar?

Het zal wel teveel bytes kosten om extra attributen toe te voegen die er alleen zijn voor extra semantiek, zoals SCOPE op het TH element bijvoorbeeld, nietwaar?

Over bytes gesproken, ik neem aan dat de URI's relatief worden uiteindelijk?

Theoretisch is het ook mogelijk om alle event attributen in het JS element zelf te hebben, probleem is alleen dat het vele meer code kan zijn (of juist veel minder). Is hier al naar gekeken?

code:

<legend>quicksearch</legend>

Eigenlijk moet je dat met een hoofdletter doen in de code zelf...

IPV in de de TH de breedte e.d. te bepalen kun je ook het COL element gebruiken, al over gedacht, gehad?

OMG, je kunt ook padding e.d. gebruiken in het OPTION element. Momenteel lijkt het me trouwens beter om OPTGROUP te gebruiken voor de algemen dingen, niet (forum selecteren)?

Voor auto-detect e.d. lijkt het me ook handig om LINK elementen te gebruiken waarin je verwijst naar auto-detectie. Eventueel zou je daar zelfs elk apart forum in kunnen opnemen (rel="section"), maar ik vrees weer voor het aantal bytes etc.

code:

<br style="clear:both" />

Waarom niet dit zetten op #signature{clear:both}?

De code voor quick reply kan ook veel beter. Ten eerste is FIELDSET een block-level element, dus zijn die extra DIVs niet meer nodig (om alle type=hidden bijvoorbeeld). Dan kun je dus ook gelijk die hele definitie lijst vervangen voor een LABEL(!) en een TEXTAREA, uitlijnen, klaar.

Wordt vervolgd...

[ Voor 6% gewijzigd door Verwijderd op 07-03-2004 15:05 ]

[André]

Verwijderd schreef op 07 maart 2004 @ 15:03:
[...]

Sommige dingen staan er juist vanwege een bepaalde beveiliging. Het reactid bijvoorbeeld.

reactid kan ik me voorstellen, de rest is overbodig.

[crisp]

Inhoudelijk dan

-Arial Black: is een design keuze geweest, en heb ik daarom precies zo overgenomen. Ik doe geen design, enkel de uitwerking...

-wegvallende lijntjes bij in-uitklappen enzo: post bij dat soort zaken ook even je browser+versie; vaak zijn het gewoon renderbugs waar ik niet altijd omheen kan. In de door mij geteste browsers ben ik dit soort dingen nog niet tegengekomen, ik gebruik trouwens deze browsers:

IE6 SP1
IE5.5 SP2
Mozilla 1.5 20031007
Opera 7.23
Konqueror 3.2
FireBird 1.6b 20040102
FireFox 1.6 20040206

-inmiddels heb ik de table-layout voor de index op fixed gezet; het verschuiven bij in en uitklappen is hiermee ondervangen

-bepaalde inline styles ga ik nog vervangen door classes; dit is zoals gezegd WIP

[Verwijderd]

terabyte schreef op 07 maart 2004 @ 14:49:
Dan moet je rekening houden met de browser en platform van de client.
En dat is moelijk, omdat er nog steeds een veelgebruikte browser is die zich niet aan de standaard houdt. Dan moet je worarounds verzinnen waardoor je code bloated wordt.
Bloated heeft tot gevolg dat het teveel troep bevat, waardoor de code groter wordt en dus onnodig langzamer wordt gerenderd.

Cheetah gaf al het enige en correcte antwoord op mijn vraag, text browsers ondersteunen het niet, ik wist alleen niet de ze ook compatible wilden zijn voor bijv. Lynx.

Voor de rest slaat je opmerking over "een veelgebruikte browser die zich niet aan de standaarden houdt" kant nog wal. De mogelijkheid van js arrays renderen naar markup kan momenteel elke js enabled browser, daar hebben standaarden niets mee te maken.

Het feit dat IE6 zich niet altijd aan de standaarden houdt heeft ook te maken met de leeftijd van de browser. Bloated code heeft trouwens niets te maken met de browser, maar met de persoon die die code maakt (of in de professionele tak, met het tijdsbestek en druk waarin die code moet worden gemaakt).

Maargoed, blijkbaar heb ik een totaal andere kijk hierop dan jij, aangezien ik altijd zoveel mogelijk op de server probeer te genereren en vervolgens correcte (X)HTML en CSS naar de client stuur.
Verder hebben browsers die zich dan wel aan de standaard houden geen last van de eventuele workarounds voor andere browsers.

Dat kan, iedereen heeft zijn eigen "stijl". Ik probeer juist zo weinig mogelijk op de server te genereren indien dit mogelijk is. Je verminderd onnodige load, betrekt je clients bij het renderen, verminderd dataverbruik drastisch en de snelheid wordt tevens verhoogd.

Mocht got geen Lynx willen ondersteunen dan zal de creatie van js arrays waarschijnlijk de beste oplossing zijn geweest. Volgens mij werkte Topix vroeger ook via dit principe.

Ik ben nu bijna 3 maanden bezig met het compleet heropbouwen van een content management systeem (vorige versie zijn screenshots van gepost op got) naar compleet css layouted en xhtml valid, maar wel met in het achterhoofd gehouden dat de client mogelijkheden heeft om de code zelf op te bouwen.

Dwz dat er compleet nieuwe componenten zijn ontwikkeld, geheel xhtml en css layout based (treeview, favorites systeem, formulieren volgens SPI methodieken, menu's, etc). maar waarbij de client zelf alleen de data ontvangt. De browser zelf zorgt ervoor dat het geheel aan data naar een presenteerbare laag wordt geparsed. De snelheid is behoorlijk gestegen kan ik zeggen, en het is nog bij lange na niet geoptimaliseerd. Al met al het grootste en meest complexe project wat ik in tijden heb gedaan, waarbij +/- 1200 bestanden moeten worden aangepast voor alleen al de cms administratie kant.

[Bosmonster]

Het eerste dat mij opvalt is dat alle tekstgroottes toegenomen zijn. Er past ineens een stuk minder op het scherm Je gebruikt dan ook nog eens heel erg veel bold.

Verder vind ik uit usability-oogpunt het contrast van de message-tekst veel te laag. Deze is ineens licht-bruin op wit. Volgens mij was dit in de originele ontwerpen ook gewoon zwart.

Ook wordt er nu nogal veel ruimte weggegooid met de enorme linker-balk. Imho is al ietsje beter:

[Verwijderd]

Hoe gaat het forum eigenlijk om met bijv. lomp geplaatste afbeeldingen Dat zou net die dingen die je bij toeval tegenkomt. Bijvoorbeeld een user die opeens een enorme wallpaper plaatst

Je zou bijvoorbeeld kunnen denken aan een systeem om deze images automatisch te downsizen Dus <img onload="if(this.width > 800 || this.height > 600){this.width=800};this.onclick='open in new window'".... bijv. You catch my drift

[crisp]

alienfruit schreef op 07 maart 2004 @ 15:03:
Ik vind de pagina er mooi en wat verzorgder voorkomen dan de huidige pagina. Enig probleem wat ik had toen ik de pagina openende zijn de kleuren, ik vind deze wat minder rustgevend dan het huidige blauw. Waarschijnlijk willen jullie het rode/bruine kleurcombi gebruiken omdat dit ook op de frontpage wordt gebruikt.

Naar mijn mening maakt bruin/rood niet zoveel uit op een frontpage omdat hier niet zo snel veel lappen tekst hoeft te lezen, wat wel het geval is op het forum. Dus het zou leuk zijn als er een manier was om een soort kleurcombinatie te kiezen "Warm Grey" en bijv. "Cold Blue"

Trouwens wordt het forum weer gecentreerd? Het lijkt er namelijk niet op

Verder vind ik het er allemaal mooi uitzien, beter dan Topique

Houd it soort dingen liever in het LA topic; kleurenkeuze is inderdaad bepaald aan de hand van de default kleurstelling van de FP, later zullen we daar wel (als abbo-feature) extra styles en een mogelijkheid tot centreren aan toevoegen. Je loopt een beetje op de zaken vooruit op deze manier...

Verwijderd schreef op 07 maart 2004 @ 15:04:

edit:
Probleem is dus dat ik het REACT systeem niet ken, is zeker erg lastig om aan te gaan passen, nietwaar?

Het zal wel teveel bytes kosten om extra attributen toe te voegen die er alleen zijn voor extra semantiek, zoals SCOPE op het TH element bijvoorbeeld, nietwaar?

ik ga daar in een later stadium nog wel over praten met Parse; sommige dingen zoals de forum-dropdown ga ik zelf nog een functie voor schrijven; het heeft wel prioriteit maar atm nog niet de hoogste.

Over bytes gesproken, ik neem aan dat de URI's relatief worden uiteindelijk?

Veel URI's komen absoluut uit React rollen; relatieve URI's zijn erg lastig binnen React vanwege de structuur mbt de templates, enkel voor plaatjes, scriptfiles en CSS kunnen relatieve URL's worden gebruikt.

Theoretisch is het ook mogelijk om alle event attributen in het JS element zelf te hebben, probleem is alleen dat het vele meer code kan zijn (of juist veel minder). Is hier al naar gekeken?

code:

<legend>quicksearch</legend>

Eigenlijk moet je dat met een hoofdletter doen in de code zelf...

Hoe bedoel je met een hoofdletter??? waarom zou dat moeten?

IPV in de de TH de breedte e.d. te bepalen kun je ook het COL element gebruiken, al over gedacht, gehad?

heb ik aan gedacht en ook geprobeert; het bugte echter teveel in verschillende browsers.

OMG, je kunt ook padding e.d. gebruiken in het OPTION element. Momenteel lijkt het me trouwens beter om OPTGROUP te gebruiken voor de algemen dingen, niet (forum selecteren)?

OPTGROUP wordt door o.a. IE5.5 niet ondersteund en die browser wil ik nog wel meenemen, ook padding in options gaat niet in alle browsers goed.

Voor auto-detect e.d. lijkt het me ook handig om LINK elementen te gebruiken waarin je verwijst naar auto-detectie. Eventueel zou je daar zelfs elk apart forum in kunnen opnemen (rel="section"), maar ik vrees weer voor het aantal bytes etc.

Ook dat zijn dingen waar ik pas later naar wil kijken.

code:

<br style="clear:both" />

Waarom niet dit zetten op #signature{clear:both}?

Niet elke post heeft een signature, vandaar los

De code voor quick reply kan ook veel beter. Ten eerste is FIELDSET een block-level element, dus zijn die extra DIVs niet meer nodig (om alle type=hidden bijvoorbeeld). Dan kun je dus ook gelijk die hele definitie lijst vervangen voor een LABEL(!) en een TEXTAREA, uitlijnen, klaar.

true, en ga ik nog naar kijken; sommige dingen heb ik even quick-n-dirty gedaan om het overzichtelijk te houden; tweaken kan altijd nog

Net als de opzet van de messages; daarvoor heb ik vrij veel div's gebruikt omdat dat voor nu even makkelijker was dan het gebruik van bijvoorbeeld een list die gewoon lastiger te stylen is.

Wordt vervolgd...

bedankt zover voor je input appreciate it

[Verwijderd]

Verwijderd schreef op 07 maart 2004 @ 15:11:
Ik ben nu bijna 3 maanden bezig met het compleet heropbouwen van een content management systeem (vorige versie zijn screenshots van gepost op got) naar compleet css layouted en xhtml valid, maar wel met in het achterhoofd gehouden dat de client mogelijkheden heeft om de code zelf op te bouwen.

offtopic:
Heel fijn, maar zoals je al zegt; dat is een CMS. Hoeveel mensen zullen dit CMS gaan gebruiken en weet je van deze mensen ook dat zij Lynx o.i.d. gebruiken? Ik neem aan dat je ze adviseert een bepaalde browser te gebruiken of in ieder geval de mogelijkheden met ze doorneemt. Iets wat bij GoT niet het geval is. Vrij logisch dus dat alles server side wordt gedaan. Daarnaast heeft GoT de meest gruwelijke sponsors, dus waarom zouden ze dit niet aan die kant doen?

Verder vind ik 't allemaal heel leuk wat er gebeurt met de layout van GoT, maar tegelijkertijd ook ietwat overbodig. De snelheid en overzichtelijkheid van de huidige/oude en tevens vertrouwde 'templates' vind ik persoonlijk 'geweldig'. Is het niet zo dat er alleen maar meer problemen ontstaan door die nieuwe templates? Of voegt het, naast een aantal nieuwe kleurtjes en idem stijlen, nog iets anders toe, wat ik dan gemist heb (op beide manieren inderdaad) ? Leuk dat veel mensen hun (kostbare?) tijd hierin steken, maar ik persoonlijk blijf voor het oude GoT

[Verwijderd]

Verwijderd schreef op 07 maart 2004 @ 15:04:
Het zal wel teveel bytes kosten om extra attributen toe te voegen die er alleen zijn voor extra semantiek, zoals SCOPE op het TH element bijvoorbeeld, nietwaar?

Ik was er zelf nog niet aan toegekomen, maar ja, correcte tabellen zijn belangrijk, en ik zou die zaken waarschijnlijk nog wel hebben toegevoegd.

Over bytes gesproken, ik neem aan dat de URI's relatief worden uiteindelijk?

Als het kan dan moet het zeker gebeuren ja.

IPV in de de TH de breedte e.d. te bepalen kun je ook het COL element gebruiken, al over gedacht, gehad?

Dat zijn dingen die de meeste browsers uit zichzelf toch al heel aardig doen, breedte van kolommem bepalen. Ik zou er pas aan rommelen als het ergens problemen oplevert.

OMG, je kunt ook padding e.d. gebruiken in het OPTION element. Momenteel lijkt het me trouwens beter om OPTGROUP te gebruiken voor de algemen dingen, niet (forum selecteren)?

Optgroup elementen zijn daarvoor zeer geschikt ja.

Voor auto-detect e.d. lijkt het me ook handig om LINK elementen te gebruiken waarin je verwijst naar auto-detectie. Eventueel zou je daar zelfs elk apart forum in kunnen opnemen (rel="section"), maar ik vrees weer voor het aantal bytes etc.

Eens, maar ik was er nog niet aan toegekomen toen crisp het van mij overnam. Het komt er waarschijnlijk nog wel in?

De code voor quick reply kan ook veel beter. Ten eerste is FIELDSET een block-level element, dus zijn die extra DIVs niet meer nodig (om alle type=hidden bijvoorbeeld). Dan kun je dus ook gelijk die hele definitie lijst vervangen voor een LABEL(!) en een TEXTAREA, uitlijnen, klaar.

Div's ben ik het mee eens, die zijn niet nodig. Maar de dl vind ik wel correct. Ook al is er maar 1 item, stel dat er bij elke reply een soort titel kan komen (dat zie je weleens op andere fora), dan zou je voor de textarea dt/dd een dt/dd set maken mer de label en het invoerelement voor die titel. Ook als er maar 1 invulitem is, vind ik het niet erg om een dl ervoor te gebruiken. In de moderator versie van de footer met invoerelementen zijn er dus wél al meerdere invoer elementen op zo'n manier bijgeplaatst.

Wordt vervolgd...

[terabyte]

Verwijderd schreef op 07 maart 2004 @ 15:11:
[...]

Voor de rest slaat je opmerking over "een veelgebruikte browser die zich niet aan de standaarden houdt" kant nog wal.

Kant nogch wal? Bekijk de (eenvoudige) website van Quanta Plus eens met IE. Mijn uitspraak is correct en slaat dus kant en wal.

Dat kan, iedereen heeft zijn eigen "stijl". Ik probeer juist zo weinig mogelijk op de server te genereren indien dit mogelijk is. Je verminderd onnodige load, betrekt je clients bij het renderen, verminderd dataverbruik drastisch en de snelheid wordt tevens verhoogd.

Welke onnodige load? Of je nu gegevens uit de database in een JavaScript array plakt of direct in HTML tags, zoveel maakt het niet uit.
Als je je output HTML gzipped, valt de output grootte ook nog eens mee.

Op de server JS arrays vullen en dat op de client laten renderen levert dus helemaal geen snelheidswinst op.

Mocht got geen Lynx willen ondersteunen dan zal de creatie van js arrays waarschijnlijk de beste oplossing zijn geweest. Volgens mij werkte Topix vroeger ook via dit principe.

JS arrays zijn ook niet alles... Ik bedoel, als ik op Fok! kom met m'n Konq. dan wordt m'n browser steeds trager bij een toenemend aantal topics in een lijst.
Maar bij enorme HTML pagina's er is absoluut geen probleem.
Waarom moeilijk doen met JS array's als het ook gewoon in HTML kan? (En dat levert nog minder compatibiliteitsproblemen op ook).

[ Voor 7% gewijzigd door terabyte op 07-03-2004 15:34 ]

[crisp]

Bosmonster schreef op 07 maart 2004 @ 15:13:
Het eerste dat mij opvalt is dat alle tekstgroottes toegenomen zijn. Er past ineens een stuk minder op het scherm Je gebruikt dan ook nog eens heel erg veel bold.

Verder vind ik uit usability-oogpunt het contrast van de message-tekst veel te laag. Deze is ineens licht-bruin op wit. Volgens mij was dit in de originele ontwerpen ook gewoon zwart.

Ook wordt er nu nogal veel ruimte weggegooid met de enorme linker-balk. Imho is al ietsje beter:

[afbeelding]

Bossie
Ik heb enkel zoveel mogelijk naar het design van Pelle gewerkt; als we onder de crew kunnen afspreken dat we de statussen zo kort mogelijk houden mag van mij die linkerbalk ook wel wat kleiner. De messagetext mag van mij ook wel zwart, maar in de PSD was het ook bruinachtig dus heb ik dat vooralsnog aangehouden. Probleem was dat door de fontsmoothing ik niet overal goed kon bepalen wat nou exact de kleur moest zijn.
Anyway: dat soort dingen zijn snel te wijzigen

[Verwijderd]

klein puntje waar jullie op zich niet zo veel aan kunnen doen, maar misschien wel even nog naar moeten kijken; is het verschil wanneer ClearType in of uitgeschakeld is. Wanneer het is ingeschakeld wordt alles heel erg mooi geantialiased, maar mensen zonder XP / TFT kijken er dan toch iets anders tegen aan....

Verder vindt ik dat de usability heel erg is toegenomen ten opzichte van nu, de felle kleurcontrasten tussen de posts in vindt ik niet echt prettig.

Ik zag trouwens in de screendump dat er geen andere background color wordt gebruikt bij opeen volgende posts, dat is misschien ook weer niet helemaal handig omdat het overzicht dan een beetje verloren gaat....

Komen er trouwens ook andere kleur smilies? Geel op paars is matig, maar geel op grijs is denk ik ook erg storend. De smilies trekken op die manier toch wel erg veel aandacht, hetgeen niet de bedoeling is (denk ik)

offtopic:
Ik weet dat het eigenlijk niets met dit topic te maken heeft, maar ik vindt die henk rechtsboven in echt foeilelijk......

[ Voor 8% gewijzigd door Verwijderd op 07-03-2004 15:47 ]

[crisp]

Verwijderd schreef op 07 maart 2004 @ 15:17:
Hoe gaat het forum eigenlijk om met bijv. lomp geplaatste afbeeldingen Dat zou net die dingen die je bij toeval tegenkomt. Bijvoorbeeld een user die opeens een enorme wallpaper plaatst

Je zou bijvoorbeeld kunnen denken aan een systeem om deze images automatisch te downsizen Dus 800 || this.height > 600){this.width=800};this.onclick='open in new window'".... bijv. You catch my drift

Daar ben ik nog over aan het nadenken; ik neig wel naar een stukje javascript om dat soort dingen te ondervangen. Daarnaast zijn grote code-blokken nog een probleem waar ik ook nog een nette oplossing voor wil verzinnen; het liefst wil ik layoutverneuking gewoon uitbannen, en ik sta daar niet alleen in

Je vroeg ook nog wat over hoeveel tijd zoiets nou kost in vergelijking met bijvoorbeeld een recht-toe-recht-aan table-design: wel, dat kost ontzettend veel meer tijd; je loopt echt tegen de meest vreemde browserbugs en onhebbelijkheden/onmogelijkheden van verschillende browsers aan. Iedereen die hier in W&G roept dat je geen tables moet gebruiken voor layout zou het zelf eens moeten gaan proberen, dan piep je wel anders

[crisp]

Verwijderd schreef op 07 maart 2004 @ 15:45:
klein puntje waar jullie op zich niet zo veel aan kunnen doen, maar misschien wel even nog naar moeten kijken; is het verschil wanneer ClearType in of uitgeschakeld is. Wanneer het is ingeschakeld wordt alles heel erg mooi geantialiased, maar mensen zonder XP / TFT kijken er dan toch iets anders tegen aan....

Ik heb geen XP en ook (nog) geen TFT, dus dat kan ik niet checken; ik vind in ieder geval dat zo'n afweging niet bij de webdesigner hoort; dat is een voorkeur van de user, en als het daardoor minder bruikbaar wordt dan heeft diezelfde gebruiker blijkbaar de verkeerde keuze gemaakt

Verder vindt ik dat de usability heel erg is toegenomen ten opzichte van nu, de felle kleurcontrasten tussen de posts in vindt ik niet echt prettig.

Ik zag trouwens in de screendump dat er geen andere background color wordt gebruikt bij opeen volgende posts, dat is misschien ook weer niet helemaal handig omdat het overzicht dan een beetje verloren gaat....

Ik denk dat dat in de praktijk best wel mee gaat vallen

Komen er trouwens ook andere kleur smilies? Geel op paars is matig, maar geel op grijs is denk ik ook erg storend. De smilies trekken op die manier toch wel erg veel aandacht, hetgeen niet de bedoeling is (denk ik)

offtopic:
Ik weet dat het eigenlijk niets met dit topic te maken heeft, maar ik vindt die henk rechtsboven in echt foeilelijk......

Ik denk niet dat er andere smilies komen; zeker niet op korte termijn.
En Henk, hoe lelijk ook, hoort er gewoon bij; ik ben ergens blij dat hij nog niet helemaal weg is, en verder vind ik 'm zo niet echt lelijk ofzo. Dat is gewoon een kwestie van smaak, maar daar gaat dit topic verder niet over

[Verwijderd]

code:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15" />

Kan nu weg neem ik aan? Evenals de XML Prolog, welke een SGML/XML comment moet worden mocht IE6 in quirks mode gaan.

Verder vraag ik me af of het gebruik van H1 klopt. Bijvoorbeeld in het topic. Is eigenlijk "Final forum design - eindelijk af!" de belangrijkste titel van de pagina, zoals terug te zien in het TITLE element. Theoretisch hoort H1 daar op te lijken. Het hoort iig niet in een DIV zoals het nu zit. Dat is gewoon pure evil als je het mij vraagt. Als het echt te moeilijk wordt met H1 etc. moet dat een H2 worden (en dat is dan de bottom-line zeg maar ).

Verder vind ik dat alle HEIGTH en WIDTH attributen moeten verdwijnen. Erg overbodig met de huidige browsers. Het BORDER attribuut is natuurlijk helemaal uit den boze, ik vraag me af wie er met die geniale ingeving kwam?

code:

<div class="icon"><a href="http://gathering.tweakers.net/forum/update_message/29//">
[img]"images/icons/edit.gif"[/img]
</a><br />EDIT</div>

Ik stel voor: \alt=""\. Dit is onzin in een textbrowser. Geld uiteraard ook voor alle andere gevallen mocht dit meer voorkomen.

Ook dingen als \alt="icon"\ maken het lezen alleen meer onaangenamer.

[ Voor 10% gewijzigd door Verwijderd op 07-03-2004 15:52 ]

[Verwijderd]

Is er al aan 'overflow:auto;' gedacht om "layoutverneuking" door lange URI's, code blokken, etc. te voorkomen?

[Verwijderd]

terabyte schreef op 07 maart 2004 @ 15:28:
[...]

Kant nogch wal? Bekijk de (eenvoudige) website van Quanta Plus eens met IE. Mijn uitspraak is correct en slaat dus kant en wal.

Ik zie hier niets wat een probleem zou moeten opleveren in IE6, blijf ik dus bij mijn punt, het ligt echt aan de ontwikkelaar. De meeste professionele developers hier krijgen het voor elkaar om zonder gerotzooi layouts te bakken die ook in een verouderde IE6 werken. De mogelijkheden zijn er dus wel, maar bepaalde developers zijn shortminded als het op standaarden aankomt. Volgens mij werkte de table based layout van het got forum ook prima op de browser IE6.

Welke onnodige load? Of je nu gegevens uit de database in een JavaScript array plakt of direct in HTML tags, zoveel maakt het niet uit.
Als je je output HTML gzipped, valt de output grootte ook nog eens mee.

Op de server JS arrays vullen en dat op de client laten renderen levert dus helemaal geen snelheidswinst op.

Op het moment dat jij bijv. een topiclijst met 150 postings serverside renderd zal de parser de hele template inlezen, parsen en het resultaat daarvan door de webserver laten verzenden. Er is nogal een groot verschil tussen het verzenden van 10kb aan rauwe gegevens of 50kb aan gegevens incl. markup.

JS arrays zijn ook niet alles... Ik bedoel, als ik op Fok! kom met m'n Konq. dan wordt m'n browser steeds trager bij een toenemend aantal topics in een lijst.
Maar bij enorme HTML pagina's er is absoluut geen probleem.
Waarom moeilijk doen met JS array's als het ook gewoon in HTML kan? (En dat levert nog minder compatibiliteitsproblemen op ook).

Dat het traag werkt is gewoon een kwestie van de persoon die het heeft ontwikkeld. Er zijn vele manieren om iets te parsen, en hierbij ook heel slechte implementaties en heel snelle implementaties. Je hebt dan ws gewoon een slechte implementatie te pakken.

Compatibiliteitsproblemen, noem ze eens dan. Je roept wel maar geeft geen voorbeelden. Behalve missende support van text based browsers.

[ Voor 3% gewijzigd door Verwijderd op 07-03-2004 15:56 ]

[crisp]

Verwijderd schreef op 07 maart 2004 @ 15:51:

code:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15" />

Kan nu weg neem ik aan? Evenals de XML Prolog, welke een SGML/XML comment moet worden mocht IE6 in quirks mode gaan.

ja, kan weg; op zich heb ik zoveel mogelijk om boxmodel issues heen gewerkt waardoor strict/quirks in IE niet zoveel uit zou moeten maken.

Verder vraag ik me af of het gebruik van H1 klopt. Bijvoorbeeld in het topic. Is eigenlijk "Final forum design - eindelijk af!" de belangrijkste titel van de pagina, zoals terug te zien in het TITLE element. Theoretisch hoort H1 daar op te lijken. Het hoort iig niet in een DIV zoals het nu zit. Dat is gewoon pure evil als je het mij vraagt. Als het echt te moeilijk wordt met H1 etc. moet dat een H2 worden (en dat is dan de bottom-line zeg maar ).

Dat was ook een H1, maar IE bugt bijhoorlijk bij het gebruik daarvan - allerlei vage bijverschijnselen zoals het verdwijnen van text, extra margins die niet weg te krijgen zijn etcetera. Daarom heb ik er een div van gemaakt.

Verder vind ik dat alle HEIGTH en WIDTH attributen moeten verdwijnen. Erg overbodig met de huidige browsers. Het BORDER attribuut is natuurlijk helemaal uit den boze, ik vraag me af wie er met die geniale ingeving kwam?
[...]
Ik stel voor: \alt=""\. Dit is onzin in een textbrowser. Geld uiteraard ook voor alle andere gevallen mocht dit meer voorkomen.

Dat is grotendeels nog te wijten aan copy-paste vanuit de bestaande templates. Het weglaten van width en height op images ben ik niet voor; je krijgt dan bij het renderen toch vaak een heel onrustig verspringend beeld. Ik wil dat soort dingen uiteindelijk naar CSS verhuizen, maar dan moet ik wel kijken of ik zoveel mogelijk dezelfde afmetingen kan gebruiken voor icons.

Ook dingen als \alt="icon"\ maken het lezen alleen meer onaangenamer.

ik geloof niet dat ik ergens echt zulke onzinnige alt-attributen heb gebruikt

Verwijderd schreef op 07 maart 2004 @ 15:54:
Is er al aan 'overflow:auto;' gedacht om "layoutverneuking" door lange URI's, code blokken, etc. te voorkomen?

jazeker, maar op zich ben ik niet zo voorstander van scrollbars in het design. Voor codeblokken wil ik dat nog wel gaan doen, maar te grote plaatjes wil ik gewoon dynamisch gaan resizen, en als iemand het in z'n hoofd haalt een woord of URL te posten die langer is dan 550 pixels dan heeft 'ie gewoon pech en kap ik 'm gewoon af

[ Voor 6% gewijzigd door crisp op 07-03-2004 16:04 ]

[crisp]

Verwijderd schreef op 07 maart 2004 @ 15:55:
[...]

Ik ben groot tegenstander van het gebruik van JS om clientside je markup aan te maken, en wel om de volgende redenen:

-Het vergt toch extra tijd voor de client om het uit te voeren; welliswaar misschien maar zo'n 10% van de complete laadtijd, maar toch. Zeker op wat oudere PC's ga je het toch merken, en zal je gauw zo'n 3 seconden je CPU-load naar 100% zien schieten. Als je vervolgens meerdere pagina's inlaadt, dan 'hangt' je PC al gauw enkele seconden; dit is niet uit de lucht gegrepen, want ik zie regelmatig dit soort klachten mbt o.a. de huidige frontpage, het fok-forum en vroeger ook over GoT.
-layout verminking doordat mensen oudere JS-jes in hun cache hebben staan. Is natuurlijk simpel op te lossen met een ctrl-F5 maar je moet de mensen de kost geven die daar niet aan denken of ueberhaupt niet weten dat dat vaak een oplossing is en vervolgens eerst gaan klagen. Is natuurlijk te ondervangen door een versienummer of timestamp op te nemen in je JS-bestandsnaam, maar dat is weer extra werk voor de developper (en wij zijn lui)
-veel mensen vertrouwen JS nog niet en zetten het uit (ja, die mensen bestaan); vervolgens zien die mensen geen site en gaan weg.
-veel issues mbt virusscanners die nog een schepje bovenop deze paranoia gooien (Norton anyone?) waardoor sites met veel javascript ongelovelijk traag worden omdat alles on the fly eerst door een virusscanner heenmoet.
-moeilijk onderhoudbaar en dus ook veel risico op bugs.

[Verwijderd]

Dat was ook een H1, maar IE bugt bijhoorlijk bij het gebruik daarvan - allerlei vage bijverschijnselen zoals het verdwijnen van text, extra margins die niet weg te krijgen zijn etcetera. Daarom heb ik er een div van gemaakt.

Raar, nooit gemerkt. 'padding' heb je ook verwijdert hoop ik?

Het weglaten van width en height op images ben ik niet voor; je krijgt dan bij het renderen toch vaak een heel onrustig verspringend beeld.

Is dat nog steeds zo? Zeker als die dingen gecached zijn dan weet de browser het al.

ik geloof niet dat ik ergens echt zulke onzinnige alt-attributen heb gebruikt

Ja