In this article I’m talking about The Ugly Prototyper a concept idea for a prototyping functionality.

When I start a web project sometimes I need to think about the size of the element on a page.
You are saying “never heard about photoshop/fireworks/flair builder/other prototyping software?” yes, I’ve done my homework, tryed lot of them and discovered that none give me the possibility to input a percent of the father element and get a new object of the proper size.

Practically we have to rely only on us eyes to decide if the logo (or content area) is big enough.
We put elements on page, size them and only then mathematically calculate their encumbrance (when this happens).
It’s a trials and errors method.
I don’t like at all.

If you are designing with a content-driven method you have to decide the right priority of the page elements, I think that a good starting point is to say:”the content area cannot be less than the 33% of the page, the header must be no bigger than 25%, ads will be 25%”, visually see it, modify and then (only then) start with the real prototyping and design.

So I developed my tool.
I made it in few nightly hours, sorry, it lacks of functionality and usability.
You have to reload a page if you change the working area size after creating some child and a lots of others problem.
In my excuse: this is not a release!
The Ugly Prototyper is on line just to be showed to my friends and to gather opinions

Italiano:
In questo articolo parlo di The Ugly Prototyper, un concept per uno strumento di prototipizzazione.

Ho provato diversi software per la prototipizzazione delle pagine web (e più genericamente delle interfacce) e non ho trovato nessuno che mi fornisse la possibilità di inserire una percentuale ed ottenere in cambio un oggetto della dimensione giusta.
Lo trovo strano, perchè in questo modo per il posizionamento contiamo solo sul nostro occhio che potrebbe non essere abbastanza allenato.
Penso che in fase di progettazione, specie se usiamo un approccio content-driven, sarebbe un buon punto di partenza poter decidere che l’header non debba essere più grande del 25%, i contenuti non più piccoli del 33% visualizzandone gli ingombri per poi partire con la prototipizzazione ed il design reali.

Nessuno me lo faceva e così ho creato il mio tool.
è stato sviluppato in poche ore notturne, quindi ha parecchi problemi, tra cui che non ha un sacco di funzionalità comode e necessarie, che bisogna ricaricare la pagina se si cambiano le dimensioni dell’area di lavoro dopo aver già creato almeno un oggetto ed un sacco di altre cose.

A mia discolpa posso dire che questa non è una release (e forse non ci sarà mai una release).
The Ugly Prototyper è messa on line per farsi vedere dagli interessati e raccogliere qualche opinione.

• Una faccia della medaglia
• L’altra faccia della medaglia

è diventata un’estensione per wordpress.
La pagina che la descrive e permette lo scaricamento si chiama: bSEM – Un grassetto per domarli tutti.

L’idea è esaurientemente spiegata nei due post e nella pagina dedicata, quindi non la riassumerò nuovamente.

Vorrei però ribadire qualche punto saliente e l’importanza dell’estensione.
Il nostro modo di vivere il testo scritto è cambiato profondamente.
Mentre la pagina stampata era un media fisso, immutabile nel tempo fruire i contenuti scritti sul web (e sui computer in generale) ci permette di cambiare l’aspetto del testo al cambiare delle nostre esigenze.

Le nostre necessità cambiano tra il momento in cui apriamo la pagina ed il momento in cui effettivamente incameriamo le informazioni
Quindi è giusto che anche la pagina, per aiutarci, cambi con noi.
L’estensione si occupa di rendere coerente l’uso del grassetto con il tipo di lettura che stiamo facendo.

Ho scritto anche troppo.
L’estensione è attiva su questo blog.
L’estensione è scaricabile a questo indirizzo: bsem.lghinelli.it
L’estensione è per wordpress, ma è integrabile con qualsiasi pagina, basta includere il js, i css e seguire le regole.

Per il momento in attesa che wordpress accetti di ospitare l’estensione nella directory dei plugin per segnalare i bug e proporre modifiche avete a disposizione:

• i commenti di questo post
• email: info@lghinelli.it
• wave: lghinelli@googlewave.com

Posso sognare di implementare una feature?
In un mondo bello, bello in modo assurdo (cit.) l’estensione assegnerebbe i bSEM alle parole/frasi più significative in base alla provenienza dell’utente offrendo non solo una lettura più facile, ma anche personalizzata.
Ok, ho esagerato, ma io nel web semantico ci spero molto.

In occidente ogni giorno
decine di lemuri
vengono maltrattati senza ragione
questo post è dedicato alla difesa
di questi sciacalli.

Si, c’è un errore. Un problema banale di coerenza nel testo: un’anafora che non funziona come dovrebbe. Talmente banale che non vi sorprenderà sapere che non vincerete un premio per averlo scoperto. Quello che dovrebbe sorprendervi è invece la facilità e la precisione con la quale appena letta la parola “sciacalli” siete tornati a leggere la parola “lemuri”. Se tutto è andato come dovrebbe, non avete riletto il testo per ricercare la parola sbagliata, ma siete direttamente saltati alla sua posizione.

Nella frase che segue invece tutto è coerente dal punto di vista semantico:

In occidente ogni giorno
decine di lemuri italiani
vengono maltrattati senza ragione.
La stessa sorte spetta agli
sciacalli francesi.
Un’altra categoria a rischio sono i falchi turchi.

Nessun problema semantico in questo caso, eppure anche qui c’è qualcosa che non va. Questa volta si tratta di coerenza grafica: nelle prime due frasi i nomi di animali (lemuri e sciacalli) sono in grassetto e la loro provenienza (italiani, francesi) è in corsivo. Nella terza questo codice è ribaltato.

Dietro a questi due esempi sta buona parte della progettazione dell’estensione che avete incontrato in un post precedente: «Una faccia della medaglia» e che serve a tenere insieme in una pagina web i grassetti che servono ad aiutare la lettura (scelti dal redattore) e i grassetti che servono ad ancorare il lettore alle parole chiave di un testo (scelti dal SEM) distinguendoli da un punto di vista grafico e temporale. I grassetti di lettura servono a comprendere meglio il testo, i grassetti SEM servono invece a individuare le parole chiave del testo durante una prima lettura rapida, per capire se il contenuto ci interessa o no.
C’è una descrizione più precisa nel post originale a cui vi rimando.

Quello che faremo è invece condividere alcune delle riflessioni sulla User Experience che hanno animato la fase di design dell’estensione e che potrebbero servire a dare qualche indicazione sul design di applicazioni web più in generale. Cosa c’entrino lemuri, sciacalli e falchi lo capirete a breve.

Se avete letto il post precedente capirete di cosa parliamo. Se non l’avete fatto siete ancora in tempo per farlo.

Fatto? Bene.

La versione che vedete ora (anche in questo post) è solo l’ultima di una serie di prove, in gergo iterazioni che abbiamo testato per decidere quale fosse la maniera migliore di distinguere graficamente (come) e temporalmente (quanto) ha richiesto lo scambio di un buon numero di mail.
Se vi capitasse di sviluppare qualcosa di simile sappiate che un modo sbagliato di ragionare è quello di considerare ogni elemento separatamente:

1. Decidiamo quale sia lo stile migliore da attribuire al grassetto SEM « acceso » per renderlo rapidamente reperibile a una prima lettura;
2. Poi quale sia lo stile migliore da attribuire al grassetto SEM « spento » per renderlo leggibile a una seconda lettura;
3. Infine decidere dopo quanto tempo il grassetto SEM deve spegnersi;

É quello che abbiamo fatto in un primo momento, rendendoci poi conto che le nostre soluzioni non potevano funzionare. Ripercorriamo le fasi del design.

Fase 1: grassetti evidenziati, e testo normale

In un primo momento i grassetti SEM accesi erano evidenziati in rosso: così e quando si disattivavano apparivano come testo normale: cosi.
Soluzione che soddisfaceva pienamente il nostro desiderio di fornire il miglior layout alle due fasi della lettura:
massima leggibilità nella prima, minima distrazione nella seconda.

Il problema è però che per quanto riguarda l’Esperienza dell’Utente queste due fasi di lettura non sono affatto indipendenti: l’utente coglie informazioni di un certo tipo nella prima lettura che poi utilizzerà nella seconda, ma non vive una pausa tra le due. Inoltre, come i due esempi di lemuri sciacalli e falchi ci hanno dimostrato, quando leggiamo un testo non ci interessiamo solo al suo contenuto semantico, ma ci serviamo anche della sua posizione e del suo aspetto di superficie: usiamo degli indici spaziali e grafici per identificare un contenuto con l’aspetto che questo ha all’interno della pagina, in modo da poterlo ritrovare quando diventerà per noi interessante. Il primo esempio ci ha dimostrato quanto possa essere preciso questo meccanismo, e spiega ad esempio perchè fatichiamo cosi tanto a leggere dei pdf a monitor: ogni volta che facciamo uno scroll perdiamo quegli indici spaziali la cui stabilità costituisce la struttura di superficie del testo che è fondamentale alla sua comprensione.

Da questo punto di vista la nostra soluzione poneva due problemi:

1. Il primo problema riguarda l’evidenziazione dei grassetti SEM, che catturavano troppo la nostra attenzione: Lo sfondo rendeva molto “grafici” i grassetti e portava a dare poca attenzione al testo. Proprio perchè diamo molta importanza alla struttura di superficie del testo in questo caso gli occhi rimbalzavano sui blocchi rossi senza fermarsi sul loro contenuto. Per capire quale sia la struttura di superficie del vostro testo e quali elementi attirino maggiormente l’attenzione potete testare la vostra interfaccia con delle tecniche di eye tracking.
   Un modo low cost per averne comunque un’idea approssimativa è quello di sfocare (con Photoshop) un’immagine della vostra pagina e vedere quali sono le strutture che restano salienti. Molto probabilmente l’occhio seguirà queste strutture.
2. Il secondo problema che avevamo riguardava il passaggio dal grassetto evidenziato al testo normale. Anche in questo caso il problema era dato dal fatto che la struttura con cui l’utente diventava familiare durante la prima lettura scompariva nella seconda. E questo perchè avevamo considerato la prima e la seconda lettura come due eventi indipendenti, mentre in realtà sono strettamente collegati: giustamente l’evidenziazione creava una struttura visiva di superficie (delle etichette rosse) che doveva servire a scorrere il testo a una prima lettura. Ma avevamo dimenticato che aiutare la prima lettura significa fornire le basi per la seconda!
   Nel nostro caso la differenza grafica tra grassetti SEM attivi e non attivi era troppo grande, e l’utente non aveva alcun modo di servirsi nella seconda lettura di quegli indici grafici che aveva incontrato nella prima.

La prima soluzione è stata quella di sostituire le evidenziazioni con dei dei grassetti normali. Non abbiamo scelto di adottare un’evidenziazione meno forte perchè l’evidenziazione rappresenta un problema in sè: crea degli spigoli. E siccome i nostri occhi sono attirati dalle strutture salienti e discontinue come gli spigoli, c’erano molte meno probabilità che gli occhi cadessero anche sulle parole che si trovano prima o dopo il grassetto. E questo era un male perchè il grassetto dovrebbe si attirare lo sguardo sulla parola importante, ma all’interno di una frase che dovrebbe comunque essere percepita per intero, anche se rapidamente.

Come seconda soluzione cosa abbiamo deciso di trasformare i grassetti disattivi in grassetti più “magri”, graficamente vicini al testo normale, ma ancora distinguibili. Questo per evitare il problema di coerenza visto nel secondo esempio di lemuri, sciacalli e falchi: leggo dei grassetti molto marcati, imparo a distinguerli semanticamente dal testo normale finchè ad un tratto la distinzione scompare e le caratteristiche grafiche che avevo imparato a distinguere si fondono con il testo normale. Rendendoli meno intensi, ma ancora distinguibili dal testo standard, introduciamo non una forte variazione grafica, ma una modulazione che permette all’utente di passare alla seconda lettura mantenendo però gli indici grafici e spaziali che aveva appreso nella prima.

Fase 2: Gestione del tempo
In una seconda fase ci siamo invece occupati del tempo. Per quanto tempo i grassetti SEM devono restare attivi ? In un primo momento avevamo deciso di far sparire l’evidenziazione dopo un numero di secondi pari a quello delle parole evidenziate presenti nella pagina. Ad esempio: 20 parole, 20 secondi. Un ottimo criterio quantitativo, ma che si basa su un’interpretazione sbagliata delle azioni e delle intenzioni dell’utente. Questo criterio funziona solo se l’utente durante la prima lettura arriva direttamente in fondo alla pagina subito dopo averla aperta. Ci eravamo dimenticati una possibilità: quella che la pagina fosse aperta, ma letta solo dopo un certo tempo. Una possibilità resa molto probabile dall’uso dei TAB.

Quante volte vi capita di aprire un nuovo tab e poi leggere la pagina molto tempo più tardi?. Nel tempo che passa tra l’apertura del tab e l’effettiva lettura della pagina le nostre evidenziazioni sarebbero sparite, e ci saremmo ritrovati con un gran numero di utenti che non le avrebbe mai viste.
La soluzione adottata in questo caso è stata quella di far cominciare il conto alla rovescia solo dopo un periodo di attività del mouse sulla pagine, il che ci garantisce che l’utente stia scorrendo la pagina quando inizia il conteggio.

Queste modifiche ci lasciano con l’estensione WordPress che verrà ufficialmente rilasciata nei prossimi giorni (siamo ancora in trattativa per l’esclusiva con Wired). Ci lasciano anche qualche saggio insegnamento sul webdesign: volete costruire una buona User Experience? Prendetevi cura della coerenza e della continuità:

1. Gestite in maniera coerente gli indici grafici e spaziali che servono all’utente per orientarsi nella semantica del testo. Fate attenzione alla struttura di superficie della vostra pagina.
2. Prendete in considerazione che l’utente vive anche al di fuori della vostra pagina. Chiedetevi sempre da dove venga, cosa voglia fare quando agisce in un certo modo, dove vorrebbe andare poi;
3. Rendeveti conto che non esiste una sola categoria di utenti, ma che il nostro design deve cercare di soddisfarne il più possibile. Non ci sono solo diverse versioni di browser, ma diverse pratiche d’uso del browser: ad esempio c’è chi legge tutto subito e chi apre tab che leggerà solo in seguito. Pensateci, se progettate un’applicazione che evolve nel tempo.

Alcuni di voi si staranno ancora chiedendo il senso degli esempi su lemuri, sciacalli e falchi in apertura di post. Ci sono tre risposte:

la prima è che se avessimo voluto inserirli solo per spiegare l’importanza di indici non semantici e della coerenza superficiale saremmo stati costretti a introdurli con « ora leggete questa frase ». Voi avreste capito che c’era qualcosa sotto e l’esempio non avrebbe funzionato cosi bene (mica bello farsi fregare cosi in un post in cui si scrive di User Experience).

La seconda ragione è che certe volte la curiosità di capire dove il post andrà a parare può motivare la lettura più di un buon riassunto.

La terza è che è molto divertente iniziare un post scrivendo di lemuri, sciacalli e falchi.

Claudio è stato completo e chiaro (ma del resto ne ero sicuro), spero che la lettura sia stata per voi interessante tanto quanto lo è stato per noi il processo che ci ha portato qua.
Mi limito solo a ringraziare di nuovo anche le altre persone che hanno collaborato all’idea:

dplastino che mi ha spiegato tutto quello che dovevo sapere sul dove e come posizionare correttamente i grassetti per entrambi i tipi di lettura.

Diego (formaldeide) Ricci che per primo ha notato che per gli spider <span class=”qualcosa”> non ha lo stesso peso di <strong>è

I SEM dicono che i grassetti devono aiutare a catturare l’utente e quindi devono formare un “sommario” del testo che fermi il lettore sulla pagina, la mia analogica professoressa di italiano, a suo tempo, mi diceva che il grassetto deve fornire un appiglio visivo a quelle parti del testo che sono anche semanticamente rilevanti.
Le due cose anche se si assomigliano non sono affatto equivalenti, chi scrive di mestiere distingue immediatamente un testo ottimizzato per “fermare” il lettore da uno scritto per la lettura approfondita, il lettore passivo invece probabilmente non riesce a razionalizzare la differenza, ma la sente come un retrogusto.

Al momento siamo costretti ad una scelta, un testo deve essere ottimizzato in un modo o nell’altro, abbiamo solo un tag <strong> e dobbiamo conviverci.

Siccome entrambi i tipi di lettura sono utili al nostro scopo di divulgazione/marketing dover scegliere quale adottare oltre ad essere insulso (perchè rinunciamo ad una cosa in cambio di un’altra di pari valore) ci porta anche ad effettuare una scelta “artigianale” di quale tipo di lettura sia la più adatta per il nostro testo.
Definisco questa scelta artigianale perchè si basa su variabili non conoscibili tramite strumenti tecnici, ma solo sulla percezione che supponiamo il lettore avrà del testo, ponendo quindi l’effettiva efficacia dell’articolo al di  fuori del nostro controllo.

Le soluzioni sono due, continuare ad usare la sensibilità del nostro editor per decidere che stile usare oppure non accettare nessun compromesso e distinguere nettamente le due cose.
Un’aspetto per gli analogici grassetti del professore d’italiano ed un’altro per il digitalissimo sommario del SEM.

Il problema è che in questo modo molta parte del testo risulterà evidenziata, come può dirvi chiunque “tutto importante = niente importante” e questo non ci piace per niente.
Ci viene però in aiuto il fatto che i due tipi di lettura sono temporalmente non contemporanei, il grassetto SEM compie il grosso del suo scopo nei primi secondi, nel tempo di scorrere la pagina da cima a fondo per decidere se vale la pena leggere tutto, poi passa in secondo piano.
Questo ci suggerisce che il primo tipo di grassetto non è necessariamente permanente sul testo, ma che può scomparire dopo un tempo congruo alla valutazione del testo stesso.

Quindi con due intonacate di javascript e qualche pennellata di css potremmo ottenere un nuovo strumento che funzioni all’incirca così:

• evidenziazione di tutti i tag “SEM” della pagina
• calcolo della durata dell’evidenziazione (in sperimentazione 1 secondo per ogni tag)
• scomparsa dell’evidenziazione “SEM” dopo un periodo di inattività del mouse pari alla durata dell’evidenziazione

A riprova che il web non è più il “one man show” di qualche anno fa vi informo che anche questa semplice idea è estremamente interdisciplinare, infatti la mia idea iniziale non avrebbe raggiunto un livello soddisfacenze senza:

dplastino che mi ha spiegato tutto quello che dovevo sapere sul dove e come posizionare correttamente i grassetti per entrambi i tipi di lettura.

Claudio Vandi che ha rivisto l’intera idea in un’ottica di usabilità ed UX oltre ad aver fornito una tonnellata di altri spunti e nuove idee.

Diego (formaldeide) Ricci che per primo ha notato che per gli spider <span class=”qualcosa”> non ha lo stesso peso di <strong>

Se notate qualche “movimento” strano sulla pagina è perchè sto già sperimentando l’estensione cercando il giusto equilibrio tra i vari parametri da tenere in considerazione in vista della prima release.

In un mondo perfetto avremmo un ottimo supporto ai caratteri anche nei browser, ma così non è, quindi ci teniamo la nostra manciata di font sempre uguali (qualcuno ha detto verdana?) e tiriamo avanti sopravvivendo al dispiacere di non poter godere di opere come quelle che per esempio ci elenca quotidianamente typojungle.
Siamo costretti a questo dal fatto che ogni computer può visualizzare solo i font che ha installati.

Alla terribile ingiustizia che chi può si gode l’Helvetica mentre gli altri si beccano l’Arial purtroppo non c’è rimedio (tranne flash naturalmente), ma per piccoli pezzetti di testo, tipicamente i titoli si può supplire sostituendo la scritta in html con un analogo in flash (o un’immagine).

sIFR fa la scelta di utilizzare il javascript per sostituire l’elemento indicato e tutti i suoi figli con un filmato in flash delle stesse dimensioni (quasi).
sIFR3 risulta abbastanza semplice da aggiungere ad una pagina i passi riassunti brutalmente sono solo 4:

1. Avere il file .swf: non richiede quasi preparazione, infatti basta aprire il .fla fornito nel pacchetto, cancellare il testo, impostare il font che si vuole utilizzare e pubblicare il filmato.
2. includere nella pagina il css sifr.css:

   1

3. includere nella pagina i file sifr.js e sifr-confg.js:

   1 2	<script src="/path/to/sifr.js" type="text/javascript"><!--mce:0--></script> <script src="/path/to/sifr-config.js" type="text/javascript"><!--mce:1--></script>

4. inserire nel sifr-config.js i filmati da attivare, dove attivarli e le impostazioni da usare (color, background ed altre amenità “simil css”.
   Una minima configurazione comprende:

   1 2 3

   var strangeFont = { src: "/path/to/strangefont.swf" } //il path è relativo alla pagina che carica il filmato sIFR.activate(strangeFont); // ci deve essere un solo "activate" per ogni sIFR, ma è possibile la sintassi sIFR.activate(font1,font2,font3,...,fontN) sIFR.replace(strangeFont, {selector: 'h1'}); // .className per le classi #idValue per gli id

Probabilmente seguendo questi 4 step la pagina ora fa un po’ schifo, le cose migliorano molto dopo aver scoperto che sIFR.replace() consente una sintassi css-like ed infatti:

1

sIFR.replace(strangeFont, {selector:'h1', css:['.sIFR-root{color:#ff0000; font-size:10px}']}

trasforma tutti gli <h1> della pagina in un bel colore rosso puro e corpo 10. Attenzione, non ho scritto il codice del colore a 6 cifre in quanto masochista, ma perchè flash non riconosce l’abbreviazione a 3 cifre come fanno i css.

Altre cose a cui fare stare attenti:

• se lo sfondo non è uniforme sIFR.replace() ci consente l’opzione transparent:true
• a sIFR.replace() possono essere aggiunti tutti gli stili che vogliamo, quindi è perfettamente valida la sintassi css['sIFR-root{...}','.class{...}'] purchè i selettori siano tutti figli dell’elemento da sostituire. è comunque da tenere presente che questo sistema non è perfetto e quindi utilizzarlo può far venire mal di testa ed insoddisfazione. Molto meglio è utilizzare diversi sIFR.replace() con i selettori ordinati dal più particolare al più generale. Per esempio

  1 2 3 4

  sIFR.replace('ul#main li.selected'); sIFR.replace('ul#main li'); sIFR.replace('li.selected'); sIFR.replace('li');

  In questo modo si dovrebbero avere meno mal di testa, ma non è vero, solo l’esperienza fa passare questo tipo di malesseri.

• sIFR calcola l’ingombro del filmato flash in base all’ingombro che ha l’oggetto che deve sostituire, può capitare che il js di sIFR si esegua prima che l’ingombro venga assegnato (es. Safari carica in parallelo css e js) provocando uno strano aspetto alla pagina. Per verificare che il problema sia questo basta ridimensionare la finestra del browser, se va tutto a posto la questione è proprio questa.
  Per risolvere questo problema bisogna applicare qualche hack che ritardi l’esecuzione del js fino al momento giusto
• evitare di sostituire i link. sIFR non può sostituire direttamente i tag <a> quindi bisogna applicarlo ad un elemento padre. A mio parere il gioco non vale la candela

In conclusione sIFR è sicuramente uno script ottimamente programmato a partire da un’idea intelligente, ma a me non piace.
Per quanto io sia un amante della tipografia sostituire del testo con altri oggetti non è una soluzione è un hack per aggirare il problema e come tutti gli hack non conduce ad un risultato perfetto.
Naturalmente a piccole dosi può produrre un risultato ottimo, ma il confine è così sottile che la differenza tra usarlo ed abusarlo è troppo facile da superare.

Per quel che riguarda gli altri sistemi di embedding dei font ancora non li ho provati e tantomeno messi in produzione.
Non ho intenzione di provare Cufon perchè il testo sostituito non è selezionabile (in quanto immagine) e questo mi sembra un grosso sgarbo nei confronti dell’utente.

Typekit invece che cos’è? questo di bradcolbow.com è un mirabile riassunto, quello che penso io è che potrebbe essere un buon sistema, vedremo.

Non ho nulla contro il plugin il cui funzionamento è ineccepibile, ma si basa su un parametro che varia a seconda del browser rendendo necessario interpretare i risultati solo dopo aver sniffato il browser del navigatore.

Mousewheel infatti all’attivazione dell’evento “rotella girata” restituisce una variabile delta contenente un signed int che ci dice di quanto è stata spostata la rotella e ce ne indica il verso grazie al segno.

Su firefox uno spostamento della rotella verso l’utente (per me giù) è positivo ed uno spostamento nell’altro verso (su) è negativo. In opera esattamente il contrario.

Ho scoperto ora il problema ed aggiornerò il post con la mia soluzione (quando l’avro almeno pensata) e con altre indicazioni sul comportamento negli altri browser.

“hey js dammi un oggetto di tipo jquery che eventualmente contiene parameters”

Che è ben diverso da “hey js trasformami parameters in un oggetto jquery e ridammelo“.

quindi se a questo codice html:

<div><p>Lorem ipsum bla bla bla</p></div>

applicchiamo il jqueroso:

var tmp = $(‘span’);

l’espressione if ($tmp) {//stuffs} risulterà sempre eseguita perchè tmp è un  oggetto jquery (un array) di lunghezza nulla, quindi un sistema per rendere efficace l’espressione potrebbe essere:

if ($tmp.length>0) {//better stuffs}

Ci sono tanti altri sistemi, ad esempio prima di scoprire questo effettuavo il controllo sui valori di altri attributi con $(tmp).attr(), ma questo è più compatto e funziona sempre (dovrebbe).