[Web 2.0] Pagina layout

[martijntijn]

Heren en dames,

ik ben al de hele week aan `t breinbreken over de pagina layout van een ASP.NET AJAX pagina. Ik wil een webapplicatie ontwikkelen in ASP.NET met gebruik van AJAX.

tekeningn:
__________________________________________________________________
| Logo of afbeelding |
-------------------------------------------------------------------------------------------------------------------
| Horizontaal ASP.NET menu (met dropdown) |
-------------------------------------------------------------------------------------------------------------------
| Content |
| |
| |
| |
| |
-------------------------------------------------------------------------------------------------------------------
Het is de bedoeling dat het logo en het menu niet veranderen wanneer een andere pagina geladen wordt. Om dit op te lossen wilde ik eerst gebruik maken van een Masterpage. Echter kreeg ik hierbij problemen met clientside scripting (de id`s van de componenten worden verandert).
Daarna geprobeerd met een iFrame, maar hier is het probleem dat deze zich niet in grootte aanpast aan de inhoud.
Als laatste toch nog geprobeerd met een frameset. Maar het dropdownmenu wordt niet voorbij de frameborder getekend. Ook een zwevende Divje werkte hierbij niet

Heeft iemand ervaring met layout design van een Web 2.0 pagina? Tips of suggesties zijn altijd welkom.

[mithras]

Een web2.0 pagina zegt niet zoveel. Web2.0 is gewoon een hype, gebruikt als leuke term voor hippe sites. Die sites maken bijvoorbeeld ook vaak gebruik van ajax features. Maar noem dat dan gewoon bij zn naampje met (bijv) xmlHttpRequest, dan weet iedereen waar je het over hebt

Daarnaast is asp.net een serverside taal, en heeft het niet zoveel te maken met html, css, javascript en (dus) ook ajax dingetjes. Wat is je probleem, wat wil je bereiken? Ja haalt volgens mij gewoon alles door elkaar namelijk

/edit: even ter verduidelijking: wat wil je met dit topic? Is het voldoende als ik gewoon deze html post:

HTML:

<div id="container">
  <img src="header.png">
  <div id="menu"><!-- hier je (suckerfish) menu -->
    </div>
  <div id="content"><!-- hier je content -->
    </div>
</div>

Klaar! Lijkt mij dan, of zie ik iets verkeerd?

[ Voor 25% gewijzigd door mithras op 30-05-2007 14:31 ]

[martijntijn]

Met Web 2.0 en AJAX wilde ik zeggen dat het mogelijk is UpdatePanels te gebruiken en zo dus de content kan veranderen zonder dat het menu ververst.

ASP.NET is server-side, maar wanneer je AJAX en C# gebruikt, wordt er automatisch JavaScript gegenereerd.

Wanneer ik jouw HTML-code zou gebruiken is het niet mogelijk de content te verversen zonder het menu te verversen, behalve door het gebruik van een iFrame, toch?

[Rowanov]

Volgens mij snap je het niet of ben je tenminste hoogst verwarrend

Je hebt een standaard html pagina met een stuk javascript er in. Dat stuk javascript maakt met een xmlHttpRequest een aanvraag bij je php/asp.net pagina die netjes alle data er uit poept. De data wordt teruggegeven aan je javascript en je javascript kan met behulp van het Document Object Model bepaalde elementen in je pagina aanpassen.

De code van mithras is dus prima bruikbaar, alleen moet je de serverside pagina en het javascript nog wel maken

[Mei]

martijntijn schreef op woensdag 30 mei 2007 @ 14:42:
Met Web 2.0 en AJAX wilde ik zeggen dat het mogelijk is UpdatePanels te gebruiken en zo dus de content kan veranderen zonder dat het menu ververst.

Meest crappy manier om over een website te moeten navigeren, net zoals met frames. Doe het dan gewoon op de 'ouderwetse' manier, zodat elke pagina tenminste een vast adres heeft en je door je history kan browsen.

[Verwijderd]

welicht ken je document.getElementById('content').innerHTML = "<b>ouderwets vet!</b>" nog niet?

daarme verander je in javascript de content zonder dat menu ververst

[Mei]

Mei schreef op woensdag 30 mei 2007 @ 15:18:
Doe het dan gewoon op de 'ouderwetse' manier, zodat elke pagina tenminste een vast adres heeft en je door je history kan browsen.

No shit Sherlock. Je leest echt niet he. 't is heel leuk om op die manier je site in elkaar te steken, maar functioneel is anders.

[Verwijderd]

Mei schreef op woensdag 30 mei 2007 @ 16:28:
[...]


No shit Sherlock. Je leest echt niet he. 't is heel leuk om op die manier je site in elkaar te steken, maar functioneel is anders.

Javascript geeft je ook de mogelijkheid om de history van je browser te vullen.

[crisp]

Verwijderd schreef op woensdag 30 mei 2007 @ 16:41:
[...]

Javascript geeft je ook de mogelijkheid om de history van je browser te vullen.

En hoe gaan search-engines je content vinden? En er direct naar linken? Hoe ga je bookmarken? What about accessibility? Screenreaders, andere non-JS capable user agents?

Serieus: gebruik een bepaalde techniek enkel als daar ook een goede reden voor is of omdat het daadwerkelijk iets toevoegd. En dan nog: probeer het als extra te implementeren bovenop een solide basis (basic HTML) die altijd toegankelijk is voor iedereen.

[Arethusa]

In de ASP.NET Futures van 2007 is History and Back Button support ook mogelijk.

http://quickstarts.asp.net/futures/ajax/doc/history.aspx

Maar wellicht is dit licht offtopic.

[Verwijderd]

crisp schreef op woensdag 30 mei 2007 @ 16:45:
[...]

En hoe gaan search-engines je content vinden? En er direct naar linken? Hoe ga je bookmarken? What about accessibility? Screenreaders, andere non-JS capable user agents?

Serieus: gebruik een bepaalde techniek enkel als daar ook een goede reden voor is of omdat het daadwerkelijk iets toevoegd. En dan nog: probeer het als extra te implementeren bovenop een solide basis (basic HTML) die altijd toegankelijk is voor iedereen.

Je kan het #-gedeelte van de URL veranderen om te bookmarken. En natuurlijk moet je een html-basis hebben, waarop je de extra functionaliteit bouwt. Dat moet sowieso. Misschien dat Google het als cloaking ziet als je veel javascript gebruikt... ik weet niets van SEO, maar je kan best de basis-HTML goed hebben, en toch een volledig ajax-based gebeuren er bovenop bouwen. "Javascript uit" betekent dan page reloads, "javascript aan" betekent rewrites.

[alienfruit]

Heb je nog steeds het probleem dat JavaScript niet echt fantastisch wordt ondersteunt door screenreaders. Het accesible maken van die Web 2.0 websites kost ook tijd, het is niet zodat JS+HTML+CSS ervoor zorgt dat je website meteen te gebruiken is met een screenreader. Hetzelfde geld dat een Flash website ook aandacht geniet om het accessible te maken. Het kan wel hoor!

[Genoil]

Ojee, de usability/accesibility politie is weer eens op bezoek hoor. TS zegt toch dat hij een webapplicatie wil maken, niet een website? Dan is je history toch helemaal niet zo relevant, laat staan bookmarken en/of deeplinken en SEO? Om maar niet te spreken van de screenreaders...alsof iedereen blind is!

Verder zou ik nog willen opmerken dat Web 2.0 wel iets meer behelst dan alleen AJAX, of een hype over hippe sites.

[OkkE]

Genoil schreef op donderdag 31 mei 2007 @ 10:46:
Ojee, de usability/accesibility politie is weer eens op bezoek hoor. TS zegt toch dat hij een webapplicatie wil maken, niet een website? Dan is je history toch helemaal niet zo relevant, laat staan bookmarken en/of deeplinken en SEO? Om maar niet te spreken van de screenreaders...alsof iedereen blind is!

Verder zou ik nog willen opmerken dat Web 2.0 wel iets meer behelst dan alleen AJAX, of een hype over hippe sites.

Andersom is het ook weer niet zo dat bij een webapp opeens alles weer wel mag, en er geen rekening gehouden hoeft te worden. Er moet een goede balans zijn, afhankelijk van je doelgroep. Ik vind het echter wel goed dat mensen het melden, zo blijft iedereen zich er tenminste bewust van.

Ik zou het btw erg vervelend vinden als ik niet bepaalde pagina's van een webapp kan bookmarken, perse overal Javascript voor nodig heb, niet via mijn PDA kan, etc.. Het hangt er gewoon ontzettend vanaf wie er mee gaat werken en wat er mee gedaan moet worden.

Zomaar zeggen dat usabillity & accessibility onzin is, vind ik geen goede houding. Zomaar zeggen dat het een must is, gaat ook weer wat ver.

[Garyu]

OkkE schreef op donderdag 31 mei 2007 @ 11:10:
Zomaar zeggen dat usabillity & accessibility onzin is, vind ik geen goede houding. Zomaar zeggen dat het een must is, gaat ook weer wat ver.

Het is absoluut een must. Net zogoed voor webapplicaties als voor websites. Dat wil alleen niet zeggen dat een 'usable' webapplicatie dezelfde guideliens moet volgen als een usable website.

SEO heeft verder weinig met usability en accessibility te maken, al wordt dat nog schijnbaar nogal eens door elkaar gehaald. Back-buttonfunctionaliteit wil je behouden omdat het het meeste gedrukte knopje in je browser is. Haal je die functionaliteit weg, snapt de helft van je gebruiker je applicatie niet meer. Dat heeft niets met SEO te maken.

In een webapplicatie alle pagina's bookmarken lijkt me ook nogal onzinnig. Waarom zou ik stap X in een wizard willen bookmarken? Ik kan in normale applicaties toch ook geen bookmarks zetten?

Nogmaals, usable design is gewoon een must voor webapplicaties. En usable houdt dan natuurlijk wél in dat het ontwerp aangepast is aan het gebruik. Niet dat je een paar accessibility regeltjes voor website design over gaat lopen nemen. Dat is als zeggen dat een fiets aan alle ISO-normen voor auto's moet voldoen.

[OkkE]

Garyu schreef op donderdag 31 mei 2007 @ 11:19:
Het is absoluut een must.

Ik ben het helemaal met je eens.
Mijn reactie ging meer over het wel of niet gebruik van Javascript, AJAX en iFrames.

[JKVA]

Garyu schreef op donderdag 31 mei 2007 @ 11:19:
[...]

Het is absoluut een must. Net zogoed voor webapplicaties als voor websites. Dat wil alleen niet zeggen dat een 'usable' webapplicatie dezelfde guideliens moet volgen als een usable website.

SEO heeft verder weinig met usability en accessibility te maken, al wordt dat nog schijnbaar nogal eens door elkaar gehaald. Back-buttonfunctionaliteit wil je behouden omdat het het meeste gedrukte knopje in je browser is. Haal je die functionaliteit weg, snapt de helft van je gebruiker je applicatie niet meer. Dat heeft niets met SEO te maken.

In een webapplicatie alle pagina's bookmarken lijkt me ook nogal onzinnig. Waarom zou ik stap X in een wizard willen bookmarken? Ik kan in normale applicaties toch ook geen bookmarks zetten?

Nogmaals, usable design is gewoon een must voor webapplicaties. En usable houdt dan natuurlijk wél in dat het ontwerp aangepast is aan het gebruik. Niet dat je een paar accessibility regeltjes voor website design over gaat lopen nemen. Dat is als zeggen dat een fiets aan alle ISO-normen voor auto's moet voldoen.

Helemaal mee eens. Je moet kijken wat de usability regels voor nut hebben voor je specifieke geval, natuurlijk wel rekening houdend met standaarden, maar het moet niet zo zijn dat de standaarden/regels de baas zijn. De wensen van de klant zijn de baas. En als de klant een wizard wil met een strikte flow, dan hoeft van mij op die plek bookmarking niet te werken. SEO is op die plek wat mij betreft ook ondergeschikt.