Aaargh! De nieuwe website van

Aaargh! De nieuwe website van Studio Brussel!

Ik ga niet discussiëren over het uitzicht, da’s een kwestie van persoonlijke smaak. Ik veronderstel dat het heel geslaagd is als het de bedoeling was om een website voor Super GB of Aldi te maken, maar bon.

Van de manier waarop. Het begint al hiermee:

<html><head> <title>Stubru</title></head>
<frameset rows=”0,*” frameborder=”0″ border=”0″ framespacing=”0″>
<frame src=”empty.html” name=”topEmpty” frameborder=”0″ marginheight=”0″ marginwidth=”0″ noresize scrolling=”no”>
<frame src=”/stubru_master/home/index.html” name=”content” frameborder=”0″ marginheight=”0″ marginwidth=”0″ noresize scrolling=”yes”>
</frameset>
</html>

Frames. Bovenaan een frame van 0 pixels hoog met een lege html-file erin. En waarom? Ik zie er geen enkele reden voor.

Voor zover ik verder kan zien van URLs zit het wel snor, ze hebben waarschijnlijk een CMS (in JSP geschreven) dat ofwel statische pagina’s aanmaakt, ofwel de server (Apache/1.3.20 (Unix) mod_jk/1.1.0 mod_perl/1.21 trouwens, ‘t is te hopen dat ze binnenkort 1.3.27 installeren) doet geloven dat er pagina’s staan. Wellicht het eerste, en wellicht zitten de gegevens ergens in XML in en worden ze ge-xsl-d naar de server, zodat zaken als http://www.stubru.be/stubru_master/muziek/albums/nickcave_nocturama/index.html blijkbaar echt bestaande pagina’s zijn en niet dynamisch gegenereerd.

De structuur is overal redelijk gelijklopend:


  • detailpagina’s, bvb. Hysterie ten huize Osbourne of Nick Cave – Nocturama bestaan uit een titel, en dan een aantal secties (combinaties van “gewone tekst” met daarin gentitle, itemsubtitle, gensubtitle, picturetable, een detail_balk.gif voor scheiding, …).
    Worden statisch gegenereerd naar /stubru_master/onderdeel/subonderdeel/detailpagina/index.htm
     

  • overzichten, bvb. Albumbesprekingen of Cultuur & Lifestyle Nieuws, waarschijnlijk gewoon automatische lijsten van de detailpagina’s die eronder liggen waarvoor geldt dat vandaar tussen embargo- en expiratiedatum valt.
    Statisch gegenereerd naar /stubru_master/onderdeel/subonderdeel/overzicht/index.html
     

  • onderdeel-home pages, bvb. Agenda of Muziek. Telkens een aantal kadertjes met één itempje van een onderdeel van de paginalijsten onder dat deel van de site (bvb. één bepaald album uit de albumbesprekingen op de muziekpagina), of met een lijst van items (bvb. het popnieuws-kader op muziek). Blijkbaar kunnen in de kaders ook andere dingen gestoken worden, zoals op de “wedstrijden”-pagina waar op dit ogenblik een link naar een mailform, één naar de kalender en één naar een programma staat.
    Gegenereerd naar /stubru_master/onderdeel/home/index.html
     

  • De algemene home page bevat kadertjes van telkens één item van de verschillende onderdeel-home  pages.

Dingen die dan toch dynamisch-achtig moeten zijn, Now on air bijvoorbeeld, worden met javascript ge-included. De .js-files daarvan (een hoop document.writeln’s na elkaar) worden blijkbaar automatisch gegenereerd, op iets linuxachtigs (alleen <lf>, geen <cr><lf>). Ik zie nergens een teken van dingen die écht dynamisch zijn, behalve op de forum-pagina.

De forumpagina’s geven dan weer een idee van hoe de data in de database zit. Zo ziet de XML er bijvoorbeeld uit, en zo ziet de XSL er uit. Ze gebruiken daar bij de VRT blijkbaar Stylus Studio van eXcelon, en de ontwikkelaars, of toch alvast Steven Rombaut, werkt vanaf een windows-computer (voor hem staan die files blijkbaar op h:\Projecten\TV-Websites\tv1\xsl\productie\). Echt veel controle is er niet: je kan als je dat zou willen op de ene forumpagina (bvb. gastenboek) gemakkelijk de XSL van een ander forum (bvb. ultimatum) plakken door gewoon vanachter in de url bvb. xsl=forum/gastenboek/messages.xsl door xsl=forum/ultimatum/messages.xsl te vervangen, niet dat dat een probleem zou zijn trouwens, je kan daar niet echt veel mis mee doen. Er is ook geen controle op XSL van andere onderdelen door elkaar gebruiken (/poll/nieuwesite/pollresult.xsl op forum bvb.), dat geeft alleen syntaxfouten.

Wat minder slim is, is dat je gewoon door een ander ID mee te geven op pagina’s als http://stubru.be/forum/ultimatum/showSubArticles.jsp?id=2652, je op andere forums terechtkomt, zelfs dingen die helemaal niets met Studio Brussel te maken hebben–Welkom op het gastenboek van ketnet! of Klopt het dat er op de bodem van de zee tussen de verschillende continenten telefoonkabels liggen? (van Jongens en Wetenschap op radio 1) bijvoorbeeld.

Het forum zelf is trouwens ook niet veel soeps: gewoon “post message” en het wordt bovenaan de lijst gezet, niets geen threads of zo.

Ook niet goed, vind ik toch, is dat je vanop een URL als http://www.stubru.be/stubru_master/cult_life/film_dvd/faithless/index.html niet gewoon het laatste stuk kan laten wegvallen en http://www.stubru.be/stubru_master/cult_life/ over kunt houden om een paar niveaus naar boven te gaan. Als je dat doet geeft het een vieze “You don’t have permission to access /stubru_master/cult_life/ on this server”-fout, terwijl het toch helemaal niet moeilijk kan zijn om ook in die directory een link te zetten naar de “home pagina” van die sectie, die zich trouwens altijd in de /home/-directory bevindt: http://www.stubru.be/stubru_master/cult_life/home.

De chat is een java-applet, jIRC van JPilot Software. Helaas is het security certificate verlopen of nog niet geldig, maar bon, daar gaan we maar over lezen zeker? Minder leuk is dat ik een javascript-foutboodschap kreeg toen ik naar de chat-pagina ging, syntax error op lijn 2. Vreemd. Alhoewel, dat zal wel die certificate-fout geweest zijn.

Er zit een generisch mailformulier in (http://stubru.be/mailer/index.jsp). Er wordt gewoon een parameter “destination” meegeven aan om te zeggen naar wie het formulier gestuurd moet worden, voor zover ik zie zit daar ook geen validatie op. De code “ma1” is De Maxx, “woo” is Wim Oosterlinck, “rep” is Republica, enzoverder. Je kan ook willekeurig iets invullen, het ding klaagt enkel als je zo’n formulier dan ook echt verstuurt: “Destination invalid”.

Validatie op het formulier zelf zit ook niet te complex in mekaar: enkel e-mailadres is verplicht, en daar wordt gechecked op minimum één karakter + “@” + minimum één karakter + minimum twee karakters. Niets geen lijst van topleveldomeinen of zo. Vul je ” @ .  ” in, krijg je bij het verzenden een foutboodschap (Missing local name). Vul je per abuis een verkeerd e-mailadres in, dan krijg je een lakonieke boodschap “Sorry, je hebt je emailadres niet correct ingevuld”, en een history.back()-link onderaan, maar die wist wel de data van het formulier uit bij mij. Weird.

De printknop die op veel pagina’s staat, toont de inhoud gewoon met een andere XSL, zonder navigatie en dergelijke. Simpel en doeltreffend.

FAQ en Help zouden volgens mij even goed in één kunnen zitten: bij help staat op dit ogenblik één vraag: “Hulp bij on line beluisteren van Studio Brussel”, en bij FAQ een paar vragen, zoals “Hoe kan ik de webcam(s) bekijken?”–verwarrend. En ik zie ook nergens een onmiddellijke link om een vraag te stellen vanop die pagina, stom.

Het programmaschema is praktisch zeker niet dynamisch gemaakt maar manueel in mekaar gebokst. Ik herinner mij dat ik er ooit zo één gemaakt heb voor de website van Radio 3, en dat was moeilijk of onmogelijk om proper te krijgen als het automatisch te genereren zou geweest zijn. En stukken html als dit:

<td width=”30″>…</td>
<td colspan=”5″ rowspan=”2″>…</td>
<td width=”77″ rowspan=”2″>…</td>

zien er mij te arbitratir uit om automatisch aangemaakt te zijn. Dus: programmaschema is ook iets in het gewone CMS.

De programma’s zelf zullen wel in een eigen database zitten, voor de “now on air” bovenaan elke pagina. Blijkbaar wordt van elk programma bijgehouden de naam, wanneer het uitgezonden wordt, een beeldje (ook weer voorzienbaar: Roos Van Acker, Wim Oosterlinck, de pipo van Republica, telkens ‘/html/stubru_web/layout/images/noa_pres_’+programmacode+’.gif’), en een baseline (“De eerste echte black, urban radioshow van Vlaanderen, met Karoline Kamosi!” bijvoorbeeld).

Over die programmacodes: er zijn er blijkbaar 36, van “all” (All Areas) tot “woo” (Wim Oosterlinck). En echt gesofisticeerd is het ook weer niet–niet dat dat moet natuurlijk, simpel is vaak het best. Zo is er “ss1” Studio Sonic (maa – don), “ss2” Studio Sonic (vrij – zat) en “ss3” Studio Sonic (zondag). Wel een beetje dom dat voor dit laatste voorbeeld er dus voor alles drie keer dezelfde “support-files” (gifs, mailforms, playlistdingen, …) moesten gemaakt worden.

Playlists zitten redelijk straightforward in mekaar. Per programma worden één of meer playlists bijgehouden, wellicht telkens met volgorde, artiest (meestal in hoofdletters, en niet al te lang van maximum aantal tekens, witness “D.A.F. (DEUTSCH AMERIKANISCHE FREUNDS”), titel en platenmaatschappij. Ik kan mij moeilijk inbeelden dat daar een relationele database zal achter zitten, het zal wel één platte tabel zijn. Anders zou niet zowel “virgin” als “Virgin” als “VIRGIN” in de lijst van platenmaatschappijen zitten. Wellicht komen die gegevens ergens elders uit.

Wel spijtig dat lang niet alle playlists ingevuld zijn. En ze zouden toch minstens daar waar niets ingevuld staat, de naam uit deze dropdown mogen halen. Alhoewel, heel erg vreemd dat daar plots ergens </opto> in plaats van </option> in staat, zou die ook manueel aangemaakt zijn? En in de link naar de playlist van Que Pasa staat een incosistentie (/playlist/que_pasa/overzicht.html ipv. wat bij alle anderen staat /playlist/naam/programmacode_overzicht.html), net zoals bij Rock Bottom (/playlist/rbo/overzicht.html ipv. /playlist/rbo/rbo_overzicht.html). In ieder geval, twaalf van de zesendertig playlists ingevuld: gene vetten.

Dus. Even kijken wat er in zit als functies:


  • CMS, genereert statische pagina’s in XML, met XSL omgevormd tot html

  • mail-mij-systeem, bijzonder eenvoudig

  • poll-systeem, heel eenvoudig

  • forumtoepassing, men kan niet eenvoudiger

  • simpele playlistdatabase (als dat al niet in het CMS wordt gepleurd)

  • simpele programmadatabase

Ik maak zoiets achter mijn uren voor géén geld, en op het werk krijgen wij zoiets in pakweg een week of twee van nul af aan in de lucht. Ik vraag mij ernstig af hoeveel ze ervoor betaald hebben.

Ik hoop echt van ganser harte dat ze het intern hebben laten maken, dat ze er nog heel veel zelf aan kunnen (laten) verbeteren, want als professionele internetfirma zou ik dit in het jaar 2003 niet durven afleveren.

Misschien stel ik eens één van deze dagen een volledige krititek op, en dan neem ik er direkt gebruiksvriendelijkheid en look in mee, stuur ik dat op, en is het dan alleen nog hopen op een bestelling. Ha!

8 reacties op “Aaargh! De nieuwe website van”

  1. Maar er is een forum waarop je je frustratie kwijt kan… de website poll. Alleen, hij werkt ook niet! Misschien dat iemand nattigheid voelde 🙂

    Error: 500
    Location: /poll/nieuwesite/vote.jsp
    Internal Servlet Error: null

    Root cause: null

  2. Eum, wat denk je dat het on-line CMS van Xavier is? Een stuk complexer dan wat ik zie op de site van stubru in ieder geval. En ja, als we op voorhand weten hoe het er precies moet uitzien, en we moeten niets anders doen, dan lukt dit in twee weken. Als we uitgaan van drie vaste niveaus in een vaste boom, vier types pagina’s, geen speciale dingen voor zover ik er zie, alleen een web-interface, geen versiebeheer, niet meertalig, geen workflow, wat zou er zo enorm ondoenbaar aan zijn?

    Allez dan, laat maar vallen dan van die “op het werk” als het u onrealistisch lijkt.

    Ik zal het dan herfraseren: ik ken mensen, bijvoorbeeld bij ons op het werk, bijvoorbeeld op een goeie dag ook ik ben ik wel zeker (al zal het lang niet proper geprogrammeerd zijn, geef ik grif toe), die iets dergelijks, althans voor zover ik zie wat er van zichtbaar is, op een week of twee van nul af aan kunnen nabootsen.

    Zo beter? 🙂

  3. Ik kuis uw rommel in ieder geval niet op Michel! Maar in iedere geval lijkt me dat een goed ding voor Michel om te doen. Kritiek spuien op websites – dat doe je toch graag – en dan sturen naar de mensen en zeggen dat wij dat beter kunnen!

Reacties zijn gesloten.