About this site's lack of design: Yes, it's supposed to look this way — I'm helping create a new sandbox theme for WordPress (see it on GitHub).

Dan Rubin's SuperfluousBanter

Suffering from chronic idiocy since 1977

Archive for January, 2004


Friday Update

Friday, January 30th, 2004

It appears a lit­tle clar­ity is needed: the book cover posted pre­vi­ously was an exper­i­ment, both in design, and to test reac­tion on a num­ber of lev­els, though we have had ideas for such a book on the table for quite a while (any inter­ested pub­lish­ers should drop us a line — we’ll do lunch).

The new agency, to be unveiled soon, will be self-publishing a series of PDF’s, of var­i­ous lengths and top­ics. The first is near­ing com­ple­tion, and will be pub­lished early next week. More details will emerge soon (regard­ing both the pub­lish­ing and the new agency), but rest assured the PDF series will be well designed :-)

Also on the list today: Lis­ta­matic, Russ Weakley’s ter­rific col­lec­tion of clean CSS list styles, has a new addi­tion. The nav­i­ga­tion cur­rently used on this site (as of the 2003 redesign) is now avail­able via Lis­ta­matic, in an easy to re-use dis­tilled format.

And keep your eyes on Dave Shea’s upcom­ing entry into the mar­ket, Bright Cre­ative — I’ll place the first bet that his will be an agency to watch for quite a while.



How To Design User Interfaces

Wednesday, January 28th, 2004

Note: the image below was posted as a bit of an exper­i­ment, with tongue firmly planted in cheek, fol­low­ing a brief Pho­to­shop skir­mish between Didier and me. While no one has com­plained, I have one thing to say just in case: Zeld­man, please don’t kill us ;-)

How To Design User Interfaces




Syntax, Semantics and Pragmatics in Hypertext Documents

Wednesday, January 28th, 2004

What are we talk­ing about? Seman­tics is a topic that has been much dis­cussed
last year and still remains an impor­tant issue (although it’s becom­ing
some­what of a buzz­word. Hype or real­ity?). This post is not aimed at dis­cussing
the value or impor­tance of seman­tics as such, but rather its gen­eral frame­work
and its appli­ca­tion to hyper­text doc­u­ments and web sites in general.


Semi­otics is com­monly known as the gen­eral sci­ence of signs. Semi­otics is com­posed
of three aspects: a syn­tac­ti­cal aspect (syn­tax or syn­tac­tics), a seman­tic aspect
(seman­tics) and a prag­matic aspect (pragmatics).

Syn­tac­tics (Syntax)

Dif­fer­ent forms of data exchange are con­sti­tuted of signs or com­bi­na­tion of
signs (lan­guage, code, non-verbal signs — among oth­ers). Syn­tax defines
a set of rules to be applied when exhang­ing data, thus “the rela­tion­ship
of signs to what they stand for”. Break­ing these rules results in a syn­tac­ti­cal
dis­tur­bance. An exam­ple of this type of dis­tur­bance in human data pro­cess­ing
are spelling errors.

For exam­ple, using an ele­ment spelled <stronk> instead of
<strong>. But also ommit­ing a clos­ing tag on empty ele­ments
such as <img>. The related DTD
(Doc­u­ment Type Def­i­n­i­tion) or more recently a Schema
con­tains the rules that define the cor­rect spelling or appli­ca­tion of (the signs
that con­sti­tute) an ele­ment (note: in XML the num­ber of ele­ments are unlimited).


Seman­tics applies to the mean­ing of data. When exchang­ing data sender and receiver
will have to assign the same mean­ing to par­tic­u­lar (com­bi­na­tions of) signs,
thus “the rela­tion of signs to the objects to which the signs are applic­a­ble”.
If this con­di­tion is not respected a seman­tic dis­tur­bance will occur. An exam­ple
of the above men­tioned dis­tur­bance is a dis­cus­sion between two indi­vid­u­als not
being able to under­stand each other.

The mean­ing (or con­text) of spe­cific ele­ments is what we com­monly refer to
as the seman­tic value of code. There­for the use of <p> ele­ments
is jus­ti­fied in the con­text of a para­graph and like­wise <hn>
n{1,6} ele­ments are used to rep­re­sent head­ers in a doc­u­ment. Fur­ther­more ele­ments
have to be nested cor­rectly. For exam­ple — in a (X)HTML doc­u­ment —
an <h1> ele­ment can not con­tain a para­graph. The DTD or Schema
explicitely con­tains nest­ing rules. How­ever it can not eval­u­ate if the con­text
of a par­tic­u­lar ele­ment is seman­ti­cally cor­rect. Cur­rent val­ida­tors check a
doc­u­ment for syn­tac­ti­cal errors, but remain lim­ited in their apti­tude to dis­cern
issues related to seman­tics. The ques­tion remains if it’s tech­ni­cally
pos­si­ble to build an analy­sis tool spit­ting out sug­ges­tions regard­ing the seman­tic
value of a doc­u­ment. Dan Ceder­holm started
a prac­ti­cal ini­tia­tive known as Sim­ple­Quiz
— dis­cussing the seman­tic value of ele­ments in hyper­text documents.


This aspect describes the effect a par­tic­u­lar sig­nal has on the behav­iour
of the receiver, thus the “rela­tion of signs to (human) inter­preters”.
If the effect is dif­fer­ent from the senders ini­tial inten­tion a prag­matic dis­tur­bance
occurs. A suit­able exam­ple are speed delim­iter signs found on most roads, with
var­i­ous applic­a­ble val­ues. No spelling errors have been made and the data is
cor­rectly inter­preted by both sender and receiver — yet some dri­vers ignore
this sig­nal by speeding.

Prag­mat­ics relate to some extend to usabil­ity. How will a user (receiver) act
or react to a given con­di­tion, sit­u­a­tion or sig­nal (sender). It’s become
best prac­tice to avoid under­lin­ing reg­u­lar text in doc­u­ments (empha­sis), and
reserve this prac­tice exclu­sively for hyper­links. Abstract­ing from con­text,
syn­tax nor seman­tics for­bid the above men­tioned prac­tice. How­ever, under­lin­ing
text that is not a hyper­link (or ommit­ing to under­line a hyper­link) results
in a prag­matic dis­tur­bance — users expect a hyper­link to be under­lined
(and vice versa).




Design and Usability: Part 3

Sunday, January 25th, 2004

If the two words design and usabil­ity are men­tioned together
you can be sure that user test­ing will fol­low within a few sen­tences
or para­graphs — at most. But what about the steps taken before throw­ing
your design to the lions? Start­ing a web project implies col­lect­ing and defin­ing
nonex­clu­sive fac­tors that will influ­ence how things will look, feel, com­mu­ni­cate
and function.

You Don’t Start With Usabil­ity Testing

I’m not talk­ing about user test­ing (or user needs specif­i­cally), but
rather generic top­ics that influ­ence the level of inter­ac­tiv­ity, func­tion­al­ity
and even­tu­ally usabil­ity. (Un)fortunately there’s no golden rule or set
of axioms which can be fol­lowed or imple­mented dur­ing the devel­op­ment of any
given web site or user inter­face — each project has dif­fer­ent require­ments
(on all lev­els). For exam­ple: a news site is not an online shop and a weblog
is not a search portal.

Not hav­ing a pre­for­mat­ted or stan­dard­ized list of (all) ele­ments and details
to imple­ment at your dis­posal dur­ing the design phase, does not mean the entire
process should be unstruc­tured. I think a col­lec­tion of global denom­i­na­tors
can help struc­ture the process and make sure the design fits the pur­pose of
the web site (goals). Before I men­tion some of these generic fac­tors which guide
and direct (to a cer­tain degree) a design process, let’s look a bit closer
at how such a process would apply in practice:

Structure, Guidance and Direction


How Design and Usabil­ity Relate

As depicted above — generic fac­tors orig­i­nate from exter­nal
enti­ties and vari­ables (i.e. the world). I don’t think many projects
would end up being suc­cess­ful if inter­nal fac­tors and pref­er­ences were to be
taken into account exclu­sively. Design and usabil­ity flow from a sen­si­ble and
bal­anced mix­ture of both inter­nal and exter­nal infor­ma­tion. Draw­ing from my
own expe­ri­ence, dis­cus­sions and projects with Dan, an aca­d­e­mic arti­cle enti­tled
Is Beau­ti­ful Is Usable
” by authors N. Tractin­sky, A.S. Katz, D. Ikar
and com­ments
made by Andrei
(who cur­rently works for Adobe
and has worked on the inter­faces for Adobe Pho­to­shop, Adobe Illus­tra­tor,
and Adobe InDe­sign), I’ve come to the con­clu­sion that indeed “the
per­ceived aes­thetic qual­ity of an object or sub­ject is intrin­si­cally locked
with how users expe­ri­ence func­tion­al­ity and usabil­ity” (adapted from a
pre­vi­ously made by Andrei). But I disgress…

Dude, What About Your Generic Factors?

I’m con­fi­dent that every designer worth his salt has already come up
with a few generic fac­tors that influ­ence design and usabil­ity deci­sions. Design
and usabil­ity are even­tu­ally about com­mu­ni­ca­tion and inter­ac­tion (HCI).
Below I’ve summed up some of the fac­tors that could be taken into account
start­ing a project:

Above I’ve tried to answer four ques­tions: Why? Who? What? and How? These
generic fac­tors will enable the def­i­n­i­tion of how design and usabil­ity will
be imple­mented through­out the project. Does this mean we’ll get it right
from the start? Not likely. We’ve merely estab­lished a hypoth­e­sis —
we think or assume it might work out as planned. It’s at this
point that you throw your design to the lions (the beta testers or an exter­nal
pool of users). The lat­ter is a process of trial and error — dis­cern­ing
and adapt­ing ele­ments that did not work as expected (back to the design phase
and pro­to­type) and keep­ing ele­ments that have a pos­i­tive or intended effect.

This Is Not an Exact Science

Nat­u­rally I’ve abstracted some ele­ments or steps in the process. Fur­ther­more
design and usabil­ity are not exact sci­ences. Thus 1 + 1 often does not equal
2; it’s more along the line of 1 + 1 equals some­thing you didn’t
. Feel­ings, opin­ions and per­cep­tions play an impor­tant (if not deci­sive)
role, but they’re sub­jec­tive (dif­fi­cult to struc­ture). The best thing
we can do is work towards an effec­tive out­come. An out­come that is unfor­tu­nately
con­sti­tuted of fac­tors, ele­ments and dri­vers of which most are (partly or com­pletely)

So what’s your take on the sub­ject? What fac­tors do you take into account?
Did I miss any? Where do you put the empha­sis: aes­thetic qual­ity or func­tion­al­ity
— or is there no trade-off nec­es­sary (both being intrin­si­cally linked)?



Zlog Interview Online

Friday, January 16th, 2004

After much delay (which I take com­plete credit for caus­ing), Ronan has posted his inter­view with yours truly.

An extra bonus for those of you who have never seen me in per­son: the inter­view is accom­pa­nied by a photo…

As the opin­ions expressed in the arti­cle are now a few months old, some may not accu­rately reflect my stand on cer­tain top­ics, but rather than have Ronan re-edit the inter­view, I’ll instead let them remain as-is — it’s inter­est­ing to read how my thought process has changed due to projects I’ve worked on, and dis­cus­sions I’ve had since I first answered the inter­view questions.

Feel free to post your thoughts, ques­tions, or crit­i­cisms in the com­ments of this post — since it’s a pub­lic inter­view, I don’t mind mak­ing the dis­cus­sion pub­lic as well.