Welkom bij TheHotSeat, pseudoniem voor een Gentse freelance webontwikkelaar. Maar bovenal een blog over webdesign, webontwikkeling en (digitale) vormgeving
Een dynamisch schuifregister in code
28 Jan 2009•In een vorige blogpost kon je lezen over het hoe en waarom van een schuifregister. In dit artikel vatten we de koe bij de horens en gebruiken we CSS en jQuery om een dynamisch schuifregister te maken. Voor wie op hete kolen zit: dit is het resultaat en hier vind je een iets stijlvollere variant.
In den beginne was er HTML
We starten met een eenvoudige htmlpagina: een artikel met daaronder lezersreacties. Als je de bron van die webpagina bekijkt, dan zie je dat ik de plaatsen waarnaar het register moet verwijzen heb aangeduid met een id en een class. In dit geval gaat het om twee h1-tags, maar je zou evengoed een combinatie van andere htmltags kunnen gebruiken:
<h1 id="artikel" class="registerknop">Zwart gat</h1>
<h1 id="reacties" class="registerknop">Reacties</h1>
jQuery maakt het wat pittiger
jQuery maakt voor elk element met de class ‘registerknop’ een aanduiding in het schuifregister. Hoe dat in zijn werk gaat kan je hieronder meevolgen. Tussen de code vind je heel wat uitleg, maar ook straks kom ik er nog even op terug.
$(document).ready(function(){
//bereken de paginahoogte
var pageHeight = $('body').height();
//bereken de hoogte van het browservenster
var windowHeight = $(window).height();
//lengte schuifbalk tov de paginahoogte
//de pijltjes van de scrollbar nemen ongeveer 41 pixels in beslag
var scrollBreuk = (windowHeight-41)/pageHeight;
//voor elk element dat de class registerknop meekreeg
$('.registerknop').each(function(i) {
//als het het eerste element betreft
if(i == 0) {
//maak een htmllijst aan
$('body').prepend('<ul id="schuifregister"></ul>');
}
//wat is de id van dit element
var id = $(this).attr('id');
//de positie van dit element vanaf de top van de pagina
var yPos = $(this).offset().top;
//waar de schuifbalk moet zijn om het element te zien
//Math.round zorgt voor een afgerond getal zonder decimalen
//de +3 zorgt voor een net iets hogere scrollbarpositie op Mac (is mooier)
var scrollPos = Math.round(yPos * scrollBreuk) + 3;
//voeg een list item aan de lijst toe voor het huidige element
//accesskey is de eerste letter van de id
$('#schuifregister').append('<li><a accesskey="' + id[0] + '" href="#' + id + '">' + id + '</a></li>');
//plaats het nieuwste list item op de juiste schuifbalkpositie
$('#schuifregister li:last-child').css('top', scrollPos + 'px');
});
});
Zoals je kan zien zoeken we eerst de hoogte van de schuifbalk ten opzichte van de browservensterhoogte. We trekken 41 pixels af van de hoogte van het browservenster omdat dat de ruimte is die de pijltjes van de schuifbalk zelf innemen op een Mac:
Die ingenomen hoogte varieert trouwens een beetje op Windows én de plaatsing is anders. Om goed te zijn zou je die waarde (41) dus moeten laten afhangen van het besturingssysteem van de gebruiker, maar zover heb ik het in dit voorbeeld niet gedreven. (Het kan dus zijn dat dit schuifregister niet helemaal accuraat werkt op Windows computers!)
Soit, terug naar het stukje code van hierboven: nadat we enkele vaste waarden in variabelen hebben opgeslagen, gaat het script op zoek naar elk html element met registerknop als class. Als zo’n element gevonden wordt dan wordt een htmllijst aangemaakt (ul) waarin per registerknop een list item (li) verschijnt. De htmllijst is makkelijk vorm te geven met CSS en kan ontelbaar veel list items bevatten. Zoals je kan zien in het stukje code kan je het schuifregister ook via accesskeys bedienen. (De code hiervoor is weliswaar niet waterdicht.)
De plaatsing van elk list item wordt in het voorlaatste regeltje code afgehandeld.
Plaatsing en vormgeving met CSS
Hoewel we jQuery gebruiken om de plaatsing van elk list item via CSS in te stellen, is de belangrijkste opmaak toch wel apart in een stylesheet terug te vinden. De CSS die nodig is om het schuifregister vorm te geven heb ik telkens in de head sectie van de htmlpagina geplaatst:
ul#schuifregister {
list-style: none;
}
ul#schuifregister li {
position: fixed;
font-size: .9em;
right: 0;
background: url(pijl.png) no-repeat center right;
padding-right: 15px;
text-transform: capitalize;
}
Het meest opmerkelijke stukje is hier het instellen van de fixed position. Hierdoor blijft elk list item mooi in positie staan als de schuifbalk schuift.
De andere CSS-code die ik in een externe stylesheet heb geplaatst is niet zo belangrijk voor het schuifregister op zich maar zorgt voor de opmaak van de rest van de pagina-elementen. We mogen onszelf nu trouwens wel al eens op de borst kloppen: dit is ons resultaat.
Meeschalen met het browservenster
Het komt aardig in de buurt maar mist nog iets: als de gebruiker het browservenster kleiner of groter maakt, dan klopt de aanduiding van het schuifregister niet meer. Maar met behulp van een vleugje jQuery kunnen we dit makkelijk oplossen: we gieten onze code in een functie toonRegister() die we uitvoeren wanneer het venster geschaald wordt.
Belangrijk is dat we hierbij telkens eerst het schuifregister ook verwijderen om na verloop van tijd geen honderden schuifregisters te zien. Ik schreef hier de welluidende functie verbergRegister() voor:
$(document).ready(function(){
//voer de functie toonRegister() uit als de pagina geladen is
toonRegister();
//als het browservenster geschaald wordt
$(window).resize(function(){
verbergRegister();
toonRegister();
});
//de code van hierboven in een functie gestopt
function toonRegister() {
var pageHeight = $('body').height();
var windowHeight = $(window).height();
var scrollBreuk = (windowHeight-41)/pageHeight;
(...)
}
function verbergRegister() {
//verwijder de htmllijst en hiermee het volledige schuifregister
$('#schuifregister').remove();
}
});
Dit is het resultaat. Schaal gerust je browservenster eens door de rechterbenedenhoek vast te nemen en te verslepen. Je zal zien dat de plaatsing van de aanduidingen in het schuifregister telkens mee aangepast wordt aan de nieuwe afmetingen van het venster. Nice!
Een vleugje finesse
Eigen aan blogs en dynamische websites is dat je als ontwerper niet kan voorzien hoe lang de teksten zullen zijn die je klant op zijn website plaatst. Nu lijkt het een beetje onnozel om een schuifregister te hebben op een pagina waar niet gescrold moet worden (deze bijvoorbeeld). Wat meer is: de aanduidingen zijn niet meer helemaal juist. Daarom heb ik nog een bijkomende controle toegevoegd in het stukje javascriptcode die er voor zorgt dat het schuifregister niet getoond wordt wanneer alle belangrijke elementen duidelijk zichtbaar zijn op de pagina:
function toonRegister() {
(...)
//als alles mooi zichtbaar is dan moet er geen schuifregister te zien zijn
if($('.registerknop:last').offset().top > windowHeight) {
$('.registerknop').each(function(i) {
(...)
});
}
Het resultaat
Dit is het resultaat van het experiment. Bekijk ook deze iets stijlvollere variant. In de broncode vind je nog eens alle code op een rijtje.
Het is een makkelijk aanpasbaar en stijlbaar schuifregister geworden. De gebruiker kan bovendien heel snel doorheen de pagina navigeren met behulp van accesskeys.
Ik ben benieuwd naar jullie bevindingen. Vind je zo’n schuifregister duidelijk en gebruiksvriendelijk? Of denk je dat het net verwarrend werkt?
Categorieën: Ontwerp, Ontwikkeling, jQuery, Webomgeving,
Het schuifregister: de scrollbar als leidraad
13 Jan 2009•Elke dag opnieuw word ik via mijn RSS-lezer overstelpt door interessante artikels en blogs op het internet. De meeste daarvan skim ik heel snel en oppervlakkig. Maar als ik een artikel echt aandachtig wil lezen, dan maakt mijn oog eerst even een snelle sprong naar de schuifbalk. Die geeft me een idee over de lengte van het artikel. Het is de lengte van de tekst en mijn beschikbare vrije tijd die me helpen beslissen of ik het artikel meteen ga lezen of zal bookmarken onder ‘interessant’ om er later op terug te komen.
Geen goede waardemeter
Maar uit de hoogte van de schuifbalk is niet altijd even makkelijk af te leiden uit hoeveel tekst een blogpost bestaat. Een schuifbalk laat je scrollen tot het einde van een webpagina en dat is doorgaans een stukje verder dan het einde van de blogpost. Denk maar aan die blogs waar lezersreacties te zien zijn onderaan elke blogpost. Hoe meer reacties, hoe onjuister de verhouding tussen de lengte van de blogpost en de hoogte van de scrollbar.
Een schuifbalk moet schuiven
De schuifbalk is dus op zich geen goede waardemeter voor de lengte van de tekst. Geen verwijt aan het adres van de scrollbalk natuurlijk want die is in de eerste plaats ontworpen om te scrollen, en daar is ze ook verdomd goed in. In het licht van gebruiksvriendelijkheid en goed ontwerp zou het trouwens verkeerd zijn om de schuifbalk andere functies te gaan toedichten. Dat zou enkel leiden tot verwarring.
Mag het iets meer zijn?
Maar dat wil niet zeggen dat we haar huidige vorm en functie niet mogen versterken. In de Chrome browser heeft Google een vernuftig idee geïmplementeerd: als je een zoekactie start dan toont Chrome je aan de hand van markeringen in zijn schuifbalk waar die zoekterm voorkomt op de huidige pagina.
Het werkt verbazend intuïtief en de schuifbalk wordt er zeker niet minder gebruiksvriendelijk op. De gele streepjes versterken enkel de oorspronkelijke functie van de schuifbalk: navigeren naar een onzichtbaar stuk van de huidige webpagina. Waar je vroeger in het ongewisse verschoof, weet je nu perfect waar je het balkje naar toe moet schuiven.
Webdesigners
Als webdesigners hebben we natuurlijk - en gelukkig maar - geen controle over de schuifbalk zelf, maar Google Chrome heeft me wel aan het denken gezet. Ik ben heus niet de enige die graag het overzicht behoudt wanneer ik op een website kom en ik kan me inbeelden dat veel mensen gebruik maken van de schuifbalk om te zien hoe lang een tekst is vooraleer ze die beginnen te lezen. Of om snel een overzicht te krijgen van de volledige webpagina.
Digitaal duimregister
Misschien kunnen we net naast de schuifbalk markeringen aanbrengen die aanduiden waar zich de kernelementen van een webpagina bevinden: de blogpost en de reacties, of de hoofdstukken van een verhaal. Hieronder vind je een hele eenvoudige schets van het idee - een soort van online duimregister.
Door de schuifbalk te verplaatsen naar de markeringen kom je meteen op het juiste stuk van de webpagina terecht. De markeringen zelf zijn uiteraard altijd onbeweeglijk en zichtbaar, het maakt niet uit of je je bovenaan of onderaan de webpagina bevindt.
Over de technische uitwerking heb ik nog niet nagedacht maar als het mogelijk is, dan zal dat waarschijnlijk via een combinatie van absolute positionering en javascript zijn. Ik ben er wel van overtuigd dat dit schuifregister een hulp kan zijn voor vele online lezers. Vooral zij die op zoek zijn naar het soort van overzicht dat van nature wel vaker aanwezig is in de traditionele gedrukte media: boeken, kranten en tijdschriften.
Categorieën: Ontwerp, Opinies, Webomgeving,
Hoe kunnen we online identiteitscontrole gebruiksvriendelijker maken?
17 Dec 2008•Het online amalgaam van registratie en identiteitscontrole is sinds jaar en dag één grote knoeiboel. Elke website heeft zijn eigen variant op het systeem van persoonlijke identificatie en het aantal gebruikersnamen en wachtwoorden dat ik ondertussen moet onthouden is niet meer op de handen van een gemiddeld Belgisch gezin te tellen. Toen ik enkele weken terug een doordeweekse internetgebruiker versuft zag kijken naar haar scherm tijdens het registreren voor een Gmail e-mailadres kreeg ik alleen maar een bevestiging van het gevoel van verwarring.
Hoe kunnen we online identiteitscontrole gebruiksvriendelijker maken?
De situatie nu
Elke website volgt momenteel een eigen logica, de één al gestroomlijnder dan de ander. Die verschillen tussen websites onderling maken het er natuurlijk niet makkelijker op. De ene site laat je een herinneringsvraag invullen, de andere verwacht dat je klikt op een activeringslink in een e-mail, weer andere laten je inloggen via je e-mailadres en nog andere verwachten gewoon een gebruikersnaam en wachtwoord…
Gelukkig snellen de browsers ons te hulp tijdens het inloggen. Ze gaan heel vaak de gebruikersnaam en het wachtwoord per website gaan opslaan. En als de browser die onthoudt dan hoef ik het niet meer te doen! Dat is handig.
OpenID: een stap in de goeie richting
Enkele jaren geleden is OpenID in het leven geroepen. Dat was een grote stap voorwaarts want je hoeft nu maar 1 gebruikersnaam en wachtwoord meer te onthouden waarmee je inlogt in je OpenID identiteit. En met die OpenID identiteit kan je je dan aanmelden op alle websites die OpenID ondersteunen. Eén gebruikersnaam en wachtwoord voor heel veel websites dus.
Het nadeel is de vaak onduidelijke doorverwijzing van de website waar je wil inloggen naar de OpenID website. Het haalt je ook een beetje weg uit de navigatielogica en algemene look and feel van de website waarop je wil inloggen en kan in die zin verwarrend werken. En hoewel de lijst dag na dag groeit, zijn er nog altijd niet zoveel websites die OpenID ondersteunen.
Je identiteit koppelen aan de browser?
Waarom hangen we dan geen identiteit vast aan een browsersessie? Via een knop in de browser kan je jezelf aanmelden en sites kunnen dan gebruik maken van die browseridentiteit als je ze de toestemming geeft. Een simpele ‘Log in’ knop is dan voldoende op websites. Die knop stuurt een signaal naar de browser die reageert met de vraag of je je identiteit wil gebruiken op deze website. Jij geeft dan je toestemming waarop de browser de nodige informatie uit je browserprofiel doorstuurt naar de site.
Het voordeel: je beheert je profiel centraal op 1 plaats (lokaal op je computer of op een server zoals die van OpenID). Je hoeft dus geen 30 sites af te lopen wanneer je e-mailadres wijzigt. Maar ook aanmelden en registeren gebeurt altijd op dezelfde manier: via de browser. Het lijkt me een eenvoudig maar perfect realiseerbaar idee dat het proces van online identiteitscontrole toch een pak gestroomlijnder kan maken. Of stel ik het me een beetje te simplistisch voor?
Update: de Flock browser blijkt sinds kort via een extensie de mogelijkheid aan te bieden om via de browser zelf in te loggen op je OpenID identiteit. Die identiteit kan je dan gebruiken op alle sites die OpenID ondersteunen (zonder dat je dus doorverwezen wordt naar de site van je OpenID provider). Hoewel de grafische gebruikersinterface van de Flock extensie er nogal onhandig uitziet (Check deze video op de Flock blog maar even), is dit natuurlijk wel een hele grote stap in de goede richting.
Categorieën: Opinies, Webomgeving,
Een handvol uitstekende concertposters
8 Dec 2008•Aesthetic Apparatus is al jarenlang een van mijn favorieten wanneer het op vormgeving, typografie en zeefdrukwerk aankomt. Vooral tussen hun concertposters zitten enkele pareltjes.
Nu hebben ze blijkbaar ook een reeks gigantisch grote affiches ontworpen voor het Belgische Stella Artois. De affiches werden opgehangen in de Londense metro. Hier is een voorsmaakje.
Tientallen meer voorbeelden van affiches en ander grafisch werk vind je op de website van het Amerikaanse Aesthetic Apparatus. Ongetwijfeld een grote inspiratiebron voor velen.
Categorieën: Ontwerp, Typografie,
Zend Framework en jQuery formuliervalidering
2 Dec 2008•Hoewel ik voldoende vertrouwd ben met php en javascript, voel ik me in de eerste plaats een ontwerper. Dat is ongetwijfeld de reden waarom ik zo hou van frameworks want als ik toch de programmeerkant opga dan laten ze me toe om snel robuuste code te schrijven. Sinds enkele maanden ben ik voor een klant intensief bezig met het Zend Framework voor php en jQuery voor javascript.
Het project waaraan ik werk maakt uitvoerig gebruik van HTML-formulieren (via Zend_Form) en dus is het valideren van de gegevens die een eindgebruiker invult een noodzaak. Een voorbeeldje van formuliervalidering vind je hieronder. Als de gebruiker op de ‘Aanmelden’ knop klikt zonder een paswoord in te vullen, dan wordt het formulier niet verzonden maar verschijnt er een boodschap op het scherm. Het paswoordveld is immers verplicht in te vullen.
Het Zend Framework zorgt voor goede validering aan de serverkant, maar ik twijfelde over hoe ik de validering zou aanpakken aan de clientkant.
Javascript en php
De meest voor de hand liggende oplossing is natuurlijk het schrijven van javascriptfuncties die de formuliervalidering aan de clientkant voor hun rekening nemen. Maar ik hou er niet van om twee keer code te schrijven met hetzelfde einddoel: één keer in php en één keer in javascript. In een project dat in de maanden na lancering ongetwijfeld nog heel wat aanpassingen zal ondergaan lijkt het me niet aangewezen om telkens zowel de php-code als de javascriptcode te moeten wijzigen wanneer er iets verandert aan een formulier.
Laat Zend_Form de validering maar doen!
Ik heb er dan maar voor gekozen om alles wat betreft formuliervalidering te laten afhandelen door het Zend Framework. Dankzij een jQuery ajax oproep naar de Zend_Form isValidPartial() functie ben ik toch in staat om een gebruiksvriendelijke en snelle validering per formulierveld op het scherm van de gebruiker te tonen.
In de indexAction() van mijn controller regelt het onderstaande stukje code de server-side validering. Niets nieuws voor wie ooit al eens Zend_Form heeft gebruikt. De isValid() functie checkt de input en geeft een foutmelding weer op het scherm van de gebruiker als die ongeldige gegevens in het formulier heeft ingebracht. Pas wanneer alle input geldig is wordt het formulier echt verzonden en de database geüpdatet.
if($this->_request->isPost()) {
$formData = $this->_request->getPost();
if($form->isValid($formData)) {
//update database
} else {
$form->populate($formData);
}
}
Het nadeel van bovenstaande code is dat de validering pas gebeurt nadat het formulier wordt verzonden. De gebruiker moet dus wachten op een paginavernieuwing alvorens te weten of zijn ingevulde gegevens geldig of ongeldig waren. ‘So nineties!’, hoor ik je roepen. Dat komt inderdaad niet overeen met de snelle responstijd die een gebruiker vandaag verwacht van een webapplicatie.
jQuery to the rescue!
jQuery zal er voor zorgen dat de ingevulde gegevens van elk veld gevalideerd worden op de server net na het invullen van het veld via een Ajax oproep. Zo weet de gebruiker meteen of het veld goed ingevuld is of niet, en dat zonder te moeten wachten op een paginavernieuwing.
jQuery roept daarvoor telkens een tweede action aan in mijn Zend Framework controller. Ik heb die validateformpartial genoemd:
public function validateformpartialAction() {
if($this->_request->isPost()) {
$formData = $this->_request->getPost();
if($form->isValidPartial($formData)) {
//update database
$this->view->result = true;
} else {
//geeft foutief ingevulde velden weer met hun foutmelding
$this->view->messages = $form->getMessages();
$this->view->result = false;
}
}
}
Het verschil zit in de aangeroepen functie: isValidPartial() laat toe om enkel het doorgegeven stukje formdata te valideren. Heb je dus een formulier dat uit 5 velden bestaat en je wil maar 1 veld valideren dan kan dat via isValidPartial(). getMessages() geeft de fouten weer per veld. (Meer informatie over getMessages vind je in de Zend Framework handleiding.)
Belangrijk is wel dat je via je javascript functie enkel json (of xml) terugkrijgt van die Zend Framework action. Je moet dus Zend_Layout en Zend_View uitschakelen voor die ene action. Dat kan makkelijk in de initAction() van je controller dankzij de AjaxContext helper:
$ajaxContext = $this->_helper->getHelper('AjaxContext');
$ajaxContext->addActionContext('validateformpartial','json')->initContext();
Alles wat je in de validateformpartialAction() als variabele aan de view meegeeft (via $this->view->variableName) wordt dan meteen door die functie als json geretourneerd. Dat maakt het makkelijk om die variabelen in jQuery op te vangen en er iets mee te doen. Zo kan je bijvoorbeeld via jQuery per veld tonen welke fout de gebruiker gemaakt heeft tijdens het invullen van het formulier.
Ter vervollediging is hier de jQuery ajax functie die de waarde van het ingevulde formulierveld doorstuurt naar de validateformpartialAction van daarnet uit de Zend Framework controller:
$.ajax({
type: "POST",
//dataString is een string in dit formaat: &naam=johnny&beroep=bouwvakker
//je geeft dus de value van alle ingevulde formuliervelden die je wil valideren mee
data: $dataString,
//baseUrl bevat het pad naar je webapplicatie
url: baseUrl + "/controllernaam/validateformpartial",
dataType: "json",
//showSpinner toont een grafisch element dat de gebruiker er op wijst dat er iets aan het gebeuren is
beforeSend: function(){ showSpinner(); },
//handleResponse verwerkt de teruggekregen json data en toont de gebruiker het resultaat van de validering
//hideSpinner() verbergt het grafische element
success: function(json){ handleResponse(json); hideSpinner(); },
});
That’s it. Door de vele requests naar de server is het misschien niet de meest aangewezen manier om formuliervalidering te doen voor grootschalige webapplicaties, maar voor het project waar ik aan werk is het zeker voldoende. Het systeem zal zelfs op hoogdagen nooit door meer dan 100 gebruikers tegelijk gebruikt worden.
Het grote voordeel is dat de formvalidering overgelaten wordt aan Zend_Form. Eén regeltje wijzigen in je Form class is dus voldoende om zowel je formulier, de ajaxvalidering als de php validering up-to-date te brengen. Geen dubbel javascript valideringswerk dus. Het maakt mijn applicatie een stuk makkelijker te onderhouden.
Categorieën: Ontwikkeling, jQuery, PHP, Zend Framework,
Een masker per slimme filter in Photoshop
25 Nov 2008•Photoshop CS3 maakt 1 filtermasker aan per slim object, ongeacht het aantal filters dat je er op toepast. In deze blogpost demonstreer ik een techniek die je toelaat om een filtermasker te creëren per filter. En dat zonder lagen te hoeven kopiëren of samenvoegen. Het voordeel is grandioos: nu kan je filters toepassen met de flexibiliteit van aanpassingslagen.
Het probleem
Eerst even een schets van het probleem aan de hand van een foto die ik nam op een zomeravond in Québec:
Omdat ik vond dat de keien vooraan teveel aandacht opeisten, heb ik ze onscherp gemaakt. Zo creërde ik ook meteen een groter gevoel van scherptediepte.
Het onscherp maken deed ik vrij eenvoudig via de filter Gaussiaans vervagen (Eng: Gaussian blur). En door die als een slimme filter toe te passen kan ik ten allen tijde terugkeren naar mijn oorspronkelijke scherpe keien, mocht ik me achteraf bedenken. Tegelijk kan ik met zwart op het filtermasker schilderen boven het huisje, de berg en de wolken om die delen van mijn foto perfect scherp te houden.
Uitstekend dus! De lagenpalet van mijn foto zie je hieronder. Let op het filtermasker; het zwarte stuk zorgt er voor dat de filter Gaussiaans vervagen niet zichtbaar is op die plaats van de foto.
Ik hou van het contrast tussen het warme kunstlicht en de koele tinten van de omgeving. Om de aandacht van de kijker nog meer op dat kleurenspel te richten wilde ik graag een vignet aan de foto toevoegen. Dat is een vrij populair effect dat de hoeken van de foto donkerder maakt.
Een vignettering kan je snel verkrijgen via het menu ‘Filter > Vervorm > Lenscorrectie’ (‘Filter > Distort > Lens correction’). Alleen zit ik nu natuurlijk met het probleem dat het filtermasker van daarnet niet alleen de vervagingsfilter bovenaan onzichtbaar maakt, maar ook het vignet. De afbeelding hieronder toont wat er aan de hand is:
Zoals je ziet creërt Photoshop 1 filtermasker per slim object en niet per slimme filter. In het ongewenste resultaat zie je enkel een vignet in de onderste hoeken van de foto:
De oplossing
Er is gelukkig een mouw aan te passen. Volg deze werkwijze als je meerdere slimme filters wil toepassen, elk met hun eigen filtermasker:
Stap 1: Pas je eerste filter toe
Zet je laag om naar een slim object en pas je eerste filter toe. In mijn bovenstaande voorbeeld is dat de filter Gaussiaans vervagen. Gebruik het filtermasker indien nodig.
Stap 2: Dubbelklik op het slim object in de lagenpalet
Photoshop opent nu het referentiebestand waarnaar het slim object verwijst.
Stap 3: Zet de laag van dat referentiebestand om naar een slim object
Dat kan via ‘Laag > Slimme objecten > Omzetten in slim object’ (‘Layer > Smart objects > Convert to smart object’). Je werkt nu dus met een slim object in een slim object!
Stap 4: Pas je tweede filter toe op dit slim object
In het geval van mijn voorbeeld is dat de vignettering. Indien nodig kan je het filtermasker gebruiken om ook deze filter lokaal onzichtbaar te maken.
Stap 5: Bewaar en sluit het referentiebestand
Je zal zien dat je bewerking hierna ook doorgevoerd wordt in het oorspronkelijke bronbestand. En de tweede filter is niet meer onderhevig aan het filtermasker van de eerste filter. In mijn voorbeeld levert dat zoals je hieronder ziet een echt vignet op. De vier hoeken zijn nu donkerder:
Je kan de bovenstaande stappen indien nodig enkele keren herhalen om meerdere slimme filters toe te passen, elk met hun eigen filtermasker. De truck bestaat er dus gewoon uit om telkens een slim object binnenin een slim object te gaan maken. Het lijkt in het begin wat ingewikkeld maar laat je zeker niet afschrikken, het is helemaal niet zo moeilijk als het lijkt.
één klein nadeel misschien
Het nadeel aan de bovenstaande werkwijze is dat het niet evident is om ook nog maanden later te weten wat er juist met de foto is gebeurd. Dan moet je er aan denken te dubbelklikken op het slimme object in de lagenpalet om dan in het referentiebestand te zien dat er ook nog een tweede filter is toegepast op de foto. Maar je zou natuurlijk de naamgeving van het slim object zo kunnen aanpassen dat je weet dat er een tweede slim object in vervat zit. Ik denk dan aan iets als ‘foto huis SO in SO’.
En in Photoshop CS4?
Ik heb de kans nog niet gekregen om Photoshop CS4 uit te testen omdat ik wacht om mijn geld boven te halen tot de Nederlandstalige versie op de markt komt. Ik weet dan ook niet of Photoshop CS4 standaard een filtermasker per slimme filter aanmaakt (laat zeker iets weten als jij het al eens hebt kunnen testen! Update: Viero laat in een reactie weten dat ook CS4 geen masker per filter aanmaakt!). Maar als dat niet zo is, dan kan je ook in CS4 ongetwijfeld gebruik maken van deze techniek.
Gebruik je zelf een andere manier om een filtermasker te bekomen per slimme filter of heb je bemerkingen bij deze werkwijze? Dan hoor ik het uiteraard heel graag van je!
Categorieën: Photoshop,
Waarom ik koos voor ExpressionEngine als cms voor mezelf en mijn klanten
10 Nov 2008•In een vorige blogpost had ik het over de reden waarom ik destijds gestopt ben met het ontwikkelen van mijn eigen handgecodeerd contentmanagementsysteem (cms) voor klanten. Vandaag wil ik je vertellen waarom ik uiteindelijk voor ExpressonEngine heb gekozen als vervangend cms.
Ontwerpen in alle vrijheid
ExpressionEngine laat me websites ontwerpen in alle vrijheid. Het systeem is zo flexibel dat het me de vrijheid geeft te ontwerpen en coderen op exact dezelfde manier waarop ik het altijd al heb gedaan. En dat is heel belangrijk voor mij. Pas wanneer de front-end perfect werkt zoals ik het wil, begin ik met de implementatie van ExpressionEngine als back-end. Het cms legt me dankzij het ingenieuze gebruik van templates, velden en tags geen enkele beperking op op het vlak van vormgeving of technische functionaliteit.
Krachtig genoeg voor de meeste websites
ExpressionEngine is heel krachtig en aanpasbaar zodat 95% van de websites die ik ontwikkel uitgewerkt kunnen worden met ExpressionEngine als back-end. Geen enkele websitestructuur bleek tot nu toe niet te passen in het EE plaatje. Daarenboven laat ExpressionEngine me toe om veel sneller de meestgevraagde websitefuncties (ik denk aan contactformulieren, weblogs of fotogalerijen) aan mijn klanten aan te bieden, én is het uiterst zoekmachinevriendelijk.
Eenvoudig aan te leren
ExpressionEngine werkt heel intuïtief en was voor mezelf heel eenvoudig om aan te leren. Ik lieg niet wanneer ik je vertel dat ik in één dag in staat was om een eenvoudige bestaande website gebruiksklaar en updatebaar te maken via ExpressionEngine. Hoewel de broncode van EE vrij beschikbaar en aanpasbaar is, is het cms niet gratis te gebruiken in een commerciële omgeving. Dat hoeft in mijn ogen niet meteen een nadeel te zijn: als wederdienst kan je rekenen op hun uitstekende uitgebreide documentatie en de technische ondersteuning die je als EE klant krijgt is tot nu toe ongelooflijk snel en to the point gebleken.
Gebruiksvriendelijk voor mijn klanten
Op het eerste zicht leek de back-end mij klantonvriendelijk en dat is en was dan ook het grootste minpunt aan Expression Engine. Het is vaak wat zoeken naar de meest banale opties en onderdelen. Maar gelukkig kan je het cms vrij goed aanpassen via een uitgebreid rechtensysteem zodat mijn klanten toch op een overzichtelijke en duidelijke manier hun weg vinden in het updategedeelte van hun websites. Dit is essentieel in mijn ogen. Ik wilde een cms dat ook voor computerleken eenvoudig te gebruiken is.
Ik kan nog een tijdje doorgaan maar de bovenstaande punten zijn voor mij de meest belangrijke. Ter informatie geef ik je nog een lijstje mee van andere contentmanagementsystemen die ik meer of minder uitgebreid heb getest: CMS Made Simple, Modx, Wordpress, Joomla!, Textpattern, Plone en Drupal. Om één of meerdere van bovenstaande redenen hebben deze het echter niet gehaald.
Categorieën: ExpressionEngine, Opinies, Webomgeving,
Over 
TheHotSeat is Thomas Byttebier, freelance webdesigner en user interface designer.
Op deze website blog ik over alles wat met webdesign en digitale vormgeving te maken heeft. Meer informatie over mij. @bytte op Twitter.
RSS Feed TheHotSeatLaatste blog posts
- Responsive web design
- Designer meetup Gent part 2
- Mobile first ontwerpen
- Sleepstreet: mijn eerste responsive ontwerp
- Ontwerpen zonder bladspiegel
Laatste reacties
- Maartje op Links op Twitter
- Stuart op Responsive web design
- Ton van Leest op Responsive web design
- Jeroen op Responsive web design
- Mindmap maken op Designer meetup Gent…
Categorieën
Alle • ExpressionEngine • iPhone • Transistor • Marketing • SEO • Ontwerp • Typografie • Ontwikkeling • jQuery • PHP • Zend Framework • Opinies • Overige • Photoshop • Webomgeving