I got curious and started the browser – interesting results, what do you think? and then had the idea to have a look at those service provider’s websites. Now it’s a time where optimizing websites for the web itself is tricky enough and I truly and deeply understand why people wouldn’t optimize their private blog or portfolio page for mobile devices. But, so I thought, for a mobile phone service provider it would be obsolete and the most natural thing to provide a good version for their customers’ phones. Not really though. Only one managed to pass the test, namely T-Mobile.

Well, to all those who are willing to make that effort there are plenty resources out there, technical as well as theoretical, and one of the greatest collections to be posted since quite some time is this article: Grid-Based Design: Six Creative Column Techniques. Following the resources mentioned there you’ll also – like so many times when it comes to articles about professional web design – Khoi Vinh’s page Substraction, where you can find a link to a downloadable pdf-presentation about a fictional case study at the end of the article Oh Yeeaahh!.

Have fun with the resources and switch to grid-based designs already!

Nope, registered users only. Let’s just stop here for a moment. Imagine you’re a bike manufacturer. You bring out a brand new model and do all kinds of marketing, an own mini-site and all that stuff. You really go out heavy. And then you don’t allow people to even download a photo in reasonable quality. Great idea, eh? That for the basic weirdness of that, but now for the more DocBlog-related thing.

We need that pic, so I decided to sign up. I’m used to signing up, why the hell not? It’s just my office mail anyways, so I don’t really care about more newsletters as our spamfilter will take care of that nicely. But the ducati sign-up-process feels more like a murder-trial. There’s 4 pages of forms and they ask you all kind of stuff. They want your address, your full name, information about your currently owned bike, your previously owned bike(s), bla bla bla – basically it seems as they’d prefer you sending in your autobiography.

If you’re through the whole mess, just to top it off, they show you another form, containing the data you already submitted, labelled “billing & shipping address”. All I want is one damn wallpaper and those guys have the guts to ask my biker’s life-story and set up a shopping account for me.

Let’s get more technical here, to keep the documentation-thing going, looking at a few basic principles of (online) communication and comparing them to what Ducati’s doing there.

First rule when trying to publish content: Make it accessible

If you don’t want to publish, don’t put it on the internet. Easy enough. If you want to, make it easy to retrieve. If you really need to get something in return, at least make it as painless as possible.

Golden rule for signup-processes: Keep it short & simple

We’re all used to signing up by now. Everyone signs up for something every other day. Why did we get used to it? Because it got easier. I can get a fully-working Blog on wordpress.com by filling in three form fields. I can get an Amazon-account all of a sudden. I can sign up for ebay in a few simple steps. There’s a limit of the relation between what I’m willing to give and what I get in return. I do enter my credentials at amazon, because I want to buy things. I do enter my shipping-address because I expect to get deliveries. I’d not enter my address on wordpress.com, because there’s just no reason for them to know it.

Another golden rule for signup-processes: Guide the user

We probably don’t recognize it anymore, but most signup-forms are more outlined as guidelines. You see the form and instantly know what you gotta do: There’s the username, there’s the password. Stars indicate a required field and somewhere down there is the submit button. Been there, done that. To make the whole guiding easier forms usually are designed nicely (sounds obvious, but obviously isn’t) and short. If there are more than 3-4 fields at a time one easily already get’s that “uh-oh, that’s gonna take ages” feeling. Not the best start of a user-interaction to make him feel like we’re making him waste precious time, is it?

A rule of signup-etiquette: Don’t annoy the sh*t out of your users

Look at what you want to know, sum it up, make it compact and pack it into one form. If you gotta split it on multiple pages you probably want to add a “page 1 of x” (and try to keep x low, by the way), just to be polite. It’s about creating a predictable dialogue with your visitor and potential-soon-to-be customer. People prefer predictable things, especially if it comes to crucial things like private information.

I guess that’s the most important stuff already. Now for a short glance at the Ducati-way of new user interaction.

Making it Ducati-accessible: Find the content you want. Click download. Find out that you’re not permitted to do so. Click the signup-button. Wait for the page to load (due the server seems not to take this as an important request – at least all the other pages did not take 20+ seconds to load). Form-torture (more details soon). Wait for your activation mail.

More Ducati-like preview: Work yourself through form 1. Form 1 being the form asking for your home address, your birthday, gender and for your approval of the Information pursuant to Article 10 of Act 675/96 under Italian Law. It requires you to scroll down a whole page (on my 22-in widescreen, that is) and read 9px/9px black-on-grey type (black on dark grey with scrollbar for the law-stuff, that is). All fields are required. After choosing your country the page reloads for the State/County/Province, taking another 20+ seconds. Note that by clicking submit you agree to the terms and conditions. Those are linked to. Have fun reading. Find out your username is already taken. Find out your username can be a maximum of 8 characters in length. Page 2. Tell us everything about your motorbike. Please note: If you check you ever owned, or own, a bike this information is mandatory.

Enough details, if you want to experience the whole thing and have a nice example for bad implementation enjoy the party at the Ducati.com Registration Form.

Oh, and by the way I’m still waiting for that confirmation mail. I guess I’ll have to use an ugly low-res version, then.

Sure, CSS styling is a pain. Sometimes it feels like trying to turn a sphere inside-out; You get one thing right and then struggle with another. The key to success is patience and a strict step-by-step workflow.

Apply one rule after the other, add one thing at a time. And then test it. Play around with it. Find various ways to archive what you want and keep in mind how those affect further decisions, surrounding/containing elements and cross-browser issues. Over time you will learn some of those things and you get faster. You start to think in variety rather than focused, in alternatives rather than the obvious solutions. The first attempt might sound like this:

I gave this element a 1em top & bottom padding. How else could i get what I want? Will a margin do? The line-height? Any other attributes to apply that might work? What if I changed it to display:block and apply a height? How about using the parent’s dimensions and fit this one in? Might another value for position can do some magic?

Try them. All of them. Play. Sure, it takes a lot of time, a lot of trial & error. But as you go on practicing this way of thinking you’ll end up thinking like that:

1em padding. Issues: box-model-bug IE. Alternatives: 1em margin (note collapsing), line-height +2em (will center type vert.), block + height (height will be fixed), block + getting containing element to desired height, …

You’ll automate this thinking, get faster and more efficient – at development & troubleshooting. The great thing about being a web designer is that you learn something new in every project. New tricks are found every day by thousands of people, who will gladly share those with the community, giving you more hints and hooks to come up with another thing by yourself.

The start – pretty much the same

All kinds of design should start the same way: Think. Make yourself a plan. What do the costumers/consumers/readers want, what does the client/author want? You are about to archive an information architecture project, so do the implied brainwork. It’s not just a webpage, it’s an important interface to your target group. What’s the target and how to archive it in a way that comforts the costumer? Have a look at this. Have a look at successful sites, similar sites, different sites. Collect ideas. Make a solid concept. Then start the dirty work.

Basics: Web thinking

First of all things depend on your experience in separation of content & design. Everyone who uses InDesign, for example, already knows about this. Basically what you do as a web designer can be compared to setting a document in InDesign only using styles (paragraph styles, character styles, etc.). You try to think as general as possible. It’s not this headline, it’s all headlines sharing this level of importance. Open up one of your multi-page InDesign documents and try to style it with as little styles as possible. Don’t use any inline-styles, only stick to your defined styles palette. That’s what you will have to do as a web designer. Furthermore as a designer you know that grids are a profound tool in information architecture, so get used to use grids. Once again you can start in InDesign: Open that document and set everything on a baseline grid, define columns and follow the grid. Think of how to handle objects that need to or should break the grid. It’s the same deal as in print design, just there’s a huge step between finishing the layout and implementing it. In print we got PDF and solid programs that do the magic of converting a layout into a production-ready file. We don’t have this for the web. WYSIWYG for the web is a lie. Period. Most designers still don’t understand the medium. Forget the old rule about making layouts for the web in photoshop. The medium has evolved over this and the layout software approach is way more appropriate by now. Think in boxes, columns, grids, micro- and macrotypography. We might don’t have single-letter-spacing, nor a library of 2.000 fonts on the web. But as a designer you know that Arial doesn’t necessarily look the same wherever it is used. Font size, rhythms, colors, letter-spacing, whitespace, leading – we got all of it. Don’t limit yourself in the first place. There’s enough variety in web type.

Implementation

Now this is the point where most designers hand over their layouts to coders, or – hopefully not – start their WYSIWYG Editor. That’s fine. But if you want to call yourself a web designer than you have to cross this line. You’ll not get away being a web designer without knowing HTML and CSS. If you don’t want to do this, don’t label yourself what you’re not. That’s as calling yourself a graphics designer whilest all you can do is make clipping paths in photoshop. WYSIWYG doesn’t give you enough control to come up with the designs you’ll want to come up with: Designs that produce reusable parts. As your finished projects increase, your further ones will be accomplished faster – if you know about your HTML & CSS. How flexible you can be is demonstrated by the CSS Zen Garden. Whatever design you see is the same HTML file, just linked with another Style Sheet.

HTML/CSS have nothing to do with programming

Never say programming a web page if what you mean is HTML/CSS coding. It’s wrong. Programmers write applications and use gibberish programming languages you’ll never have to deal with if you don’t want to. They will do all that data handling on the server and those interactive features on the client side, using JavaScript, PHP, ASP, Perl, Phyton, Ruby, whatever. HTML is no programming language. It’s (HyperText) Markup Language. It’s no complicated programming-logic-binary-thinking-stuff, it’s logical and easy to learn. Example:

Here we have a headline

This is a paragraph of text, with a stronger word and an emphasized word, followed by an unordered list:

• List item number one
• List item number two

How does this look like in HTML?

• <h1>Here we have a headline</h1>
  h = headline, 1 = top level. There’s h1 to h6, the higher the number the deeper the level.
• <p>This is a paragraph of text, with a <strong>stronger</strong> word and an <em>emphasized</em> word, followed by an unordered list:</p>
  p = paragraph, strong = a strong word (bold, by default) em = emphasize (italic, by default)
• <ul>
<li>List item number one</li>
<li>List item number two</li>
</ul>
  ul = an unordered list (not numbered, that means)
  li = list item

HTML describes the document and you basically only have to remember some abbreviations. If you are serious about becoming a web designer better start heading towards the right direction: HTML, CSS, handmade. Otherwise you should probably consider doing something else for your profession.

The last years have changed the medium a lot. Not a big surprise in a medium that’s only consistency is change. But there are directions. Let’s take an ultimate crash-course in internet history:

• Started as a very small thing
• Became popular for scientific usage
• Attracted all kinds of specialists as fast & global publication medium
• Attracted “the public” as global, free source of information
• Attracted the advertisin-madmen as “the new medium”
• Attracted the “.com”-hype
• Crashed thy hype by people realizing that money doesn’t come from nowhere
• New technologies, faster connections, lower prices
• Platforms & social networks arose
• The concept of “user generated content” evolved
• The internet as everyone’s personal publishing platform

Basically what the internet is nowadays is an important part of nearly everyone’s life. No business can exist without at least having an e-mail adress, everyone has got an own webpage, students do their master thesis’s researching on WikiPedia, people keep friendships and business connectins alive on the neverending supply of social network sites, phone companies face the enemy VoIP, the music industry is about to get smacked down again after 50 years of self-claimed dictatorship, no newspaper is without an online-version, an so forth. You get the idea.

Through all this blogging, content-generating, web-publishing, … the internet became a huge mess of information. Information of different quality. One can find “advice” and “tutorials” or “how-to’s” on and for everything, the problem is that there’s no guarantee on the quality of those tips and tricks. So the internet tried to invent ways of trust. First of all there are Search Engines, no question google on top. They did a great job until recently, but the bloat of publishing seems also being too much for those lately. It’s not searching anymore, it’s researching – “is this really the information I need?” “Is the source reliable?” “Is the information up to date?” “Are there conflicting opinions/truths out there?” “Is this true at all?” – every one of us is doing the profound journalistical check – recheck – doublecheck routine, on every internet research.

But the internet is supposed to save time, not generate more work. So what to do? Right, trust. In WikiPedia we trust, for example. Many people don’t even hesitate to ask google anymore if they are looking for nothing than plain facts. WikiPedia got it, and you can bet your ass the information there is as reliable as any expert or book around. Then there’s all kinds of networks trying to establish a way of sharing content: Digg, StumbeUpon, Del.ico.us, … it’s all the same: Rather trust what others suggest as being good sources of information than doing a research all by yourself. The internet has became an active medium and it’s users don’t limit themselves to “take what they get”, but they will add what’s missing.

And they will make their own conclusions. I, for example, haven’t ever bought a book on marketing or branding. Because there’s hundreds of them. Even the amazon-feedbacks aren’t enough on this, I don’t want to read through all that to decide which source of information is trustworthy. But I do read blogs. Marketing Blogs. From all over the world, professionals from different parts of marketing, with different thoughts and beliefs about what they do, and with different conclusions about their work. And from those different views I can draw my own conclusions, pick the truths I find working for me and probably buy the book this guy whom’s blog I read for a year now and agree with on most topics suggested. The same thing with webdesign, a far more polarizing topic.

I trust total strangers. I base my future in work on the words of people I’ve never even talked to, nor seen, nor anything else, rather than buying admired books containing “the truth”. Because those people don’t try to proclaim “the one method”, “the final truth”. Those people write about their experiences, what they learned and how things work for them, in their situation. And they don’t hesitate talking about their own failures, critizising “the big ones” or giving out their knowledge, for free, just because they think it makes a difference.

And, for me, it does.

Hm, turned out to be a lot of ranting now. What I wanted to say is way shorter and can be packed in one sentence:

Deliver high quality content and you’ll build lasting relations to high quality consumers.

Now feel free to exchange “content” with “product” and there you go with probably the world’s best, yet most forgotten, marketing strategy.

There’s another point in delivering less, but higher quality content: How many blogs do you read a day? My Abo currently counts 12, personal blogs not included. If every of those blogs published two posts a day I’d not be able to catch up anyways. Abonnements and the pleasure of free RSS Readers make it easy to keep track of high quality blogs. And even if people only post once a month – if high-quality knowledge is shared I’m willing to wait. Are you?

Okay, that’s the basic thought: A user visits the website. PHP recognizes a new session and therefore creates a variable $ajaxAvailable and sets it to false. The first page being displayed to the user only includes one simple AJAX-statement which tries to GET data. If AJAX isn’t available, or JavaScript is disabled, nothing happens. If AJAX is available the PHP-application recognizes the request, therefore sets $ajaxAvailable true for the current session. This way it can act different when displaying pages.

Utilizing Smarty (I guess any other template engine will do as well, I’m just into Smarty) one could send less data if AJAX is available, like so:


{if $ajaxAvailable}
<h1>header</h1>
<p>preview</p>
<a rel="getMore" href="fullarticle.php">full article</a>
{else}
<h1>header</h1>
<p>full article</p>
{endif}


What about the original question, then?

Yeah, ok. Well I was just thinking that most pages would offer AJAX-functionality already on the first page. So this method would either require to load AJAX and non-AJAX contents on first access, or the page needs to be reloaded or other quirky dumb un-usable stuff. But we could get around that if the GET-request we sent to check for AJAX in the first place could then deliver this AJAX-functionality. Like importing a script on the fly. I see that on the first attempt one has to load the non-AJAX stuff anyways (in the case AJAX is not available, that is), but somehow I think this could be useful in some way. But probably I’m just plain wrong.

As life is a google-search for the terms “load javascript dynamically” gives, as a first result, this article: Dynamically Loading External JavaScript Files and, after some more digging around, Javascript includes – yet another way of RPC-ing. Searching and digging are nice.

The big day. A few minutes ago I decided to write this documentation. To show others how I work on this, to keep myself on track showing me that there is progress despite the the lack of results, and last but not least to review this later on and make it better next time.

More reading

I’ve read a hell lot of articles recently and I found something to pick up in every single one. I realized that the perfect solution I am craving for won’t be possible to do. Just today it happened that I got into a lot of articles about two opposing aspects of web design: The macro-like theme of general information architecture side-by-side with the more micro-like aspect of typography. Funny enough those two give quite straight directions, and I am glad about that, since most things turned out to need to be looked into way further.

It’s interesting that most people seem to be on track with the theoretical approach: Typography is the major part of web content design, usability is the most important aspect when designing the interface, web design needs to be cleaned of unnecessary gutter (in ways of content, design and markup), the content istelf should be the most important part of a website and that none of those parts can really work separated from the others.

On the other hand there’s a lot of different approaches when it comes to practice, on how to accomplish those rules. Funny enough it turns out that there’s a lot of experts out there, doing one thing perfectly right and stick to it by all means, yet miserable fail on other requirements and therefore end up with nothing but a big mess. Tough luck.

Questions

So lately I spent most of the time on comparing methods to achieve various things (uhm … what a sentence). For example:

• Should a baseline grid rely on pixel-sized type?
  No good: Some browsers still don’t resize those.
  Good: Makes things a lot easier (mathematics can get tricky with relative units, and there’s no guarantee on how browsers handle things like 0.0625em).
• Should the layout width also be flexible?
  No good: Can get kind of complicated, again we rely on mathematics and relative units. Also there’s the thing with images – how to handle those when the layout can be resized at all?
  Good: If the layout looks good on a small screen, users with a bigger one can adjust the whole thing to their needs – what a nice feature! Also the line-width usually is (or should be) a cleverly planned thing. And if resizing doesn’t resize everything, these typographical things would break and make for a less readable layout.
• Only use safe fonts?
  No good: It’s been a few years that we sticked to Tahoma and Verdana. It’s the 21st century, we really should be able to move on and spice up that boring web-surface a little.
  Good: It’s safe. And easier. If I based my layout on a non-safe font I’d also have to test the substitutes, to at least keep them as good-looking as possible.
• Use a “web-grid” or a “design-grid”?
  Web-grid: The usual stuff – x columns, y pixels each,
  z pixels gutter, somewhat meeting the font requirements.
  Design-grid: Use proportions, directly relate grids to type (therefore make the grid resizeable), try to bring more of the print-typography to the web, pleasing the bored eyes of the casual surfer
• Use images inline or separate them?
  Inline: Pictures will most likely vary in size. Placing them inline will make it kind of difficult to get them to comfort the grid. It will most likely require some server-side action, what breaks the separation-rules

And a lot more questions that are floating around in my head at the moment, waiting to be answered. I really have to set up a briefing to use as a guideline, or I’ll find myself thinking Uhm … how did I decide about that?. Time for decisions.

CSS files bother me since I can think of using CSS. The bigger a CSS ruleset becomes the harder it becomes to keep things separted. If it comes to debugging it can be a real pain to find the one rule inside the nested styles. One major part of that mess has always been my own fault. In the first place I just wrote down the rules, each element got it’s style, period.

Later on I found out (I think while looking at wordpress-themes, that was) that it’s a good idea to divide a CSS file into sections for basic structure, typography and so on. This was the first thing I stuck to. Then I invited my own coding structure, which I couldn’t find anywhere else until now, for whatever reason that is. It looks like this:

So the basic idea is to have all rules, codeblocks and values begin at their own consistent column. Additionally I adopted an idea from 70 Expert Ideas For Better CSS Coding and am sorting the properties alphabetically. Finally I am using constants in a way like this:

Using those I can easily change every notation of a color in the whole css file using a simple search & replace. (Note that the constant-name-comment is written before the semicolon, so the search & replace also works with short notations where the constant may not be the last value in the ruleset, plus there’s a space between the value and the /*-opening comment, this is for better browser compatiblity) Finally I split up the CSS into various files:

• reset.css
  Reset file to cancel browser default values.
• main-layout.css
  Define the dimensions and positions of the main layout elements
• baseline.css
  Rules to keep everything on the baseline grid, with lots of ugly 0.xxxxxx – em-values
• boxes.css
  Rules for other semantic areas within the layout (e.g. side column) are defined here.
• color-typo.css
  Typefaces and colors, nothing else.
• links.css
  Appearance of all links
• toolbox.css
  All kinds of special effects and layout-hacks.

Footnote: One big disadvantage about css frameworks is that they can produce a hell lot of http-requests. I saw frameworks split up in 20+ files, what for my personal bloggy is irrelevant, but any bigger page has a good chance to suffer from that. Keep in mind that every single file has to be fetched from the server (I know caching helps here, but hey – 20times as much requests? come on …). Whilest I see the advantage of keeping single parts split up that’s not an excuse. A simple server-side script that, let’s say once a day, checks if any css-framework files have been updated and, depending on that, builds one complete file from all the single parts will solve this problem without having any disadvantages. Also this script could strip unnecessary comments and whitespace as well as it could gather the data from one central location, making administration of the framework even more easy.

Dann will i allerdings auch schöne eigene ErrorDocuments (zum Beispiel so: 403 – Forbidden), damit das alles a bissl a GESICHT hat. Das Problem kommt erst beim Mischen auf. Subdomains und eigene ErrorDocuments. A erster Blick in die .htaccess:

Nach dem ErrorDocument XXX /errorpage?sc=XXX Muster san die “üblichen” Fehler 400, 401, 404 und 500 (obwohl i net sicher bin, ob’s bei dem was bringt – oba bitte, moi schaun) in ein zentrales PHP-File kanalisiert, das sich dann um Weiteres kümmert. Die nächsten 4 Zeilen fangen eventuelle weitere Fehlercodes ab. Des funktioniert, weil die ErrorDocument – Direktive wichtiger is als die Rewrite-Gschichte, zumindest nach der aktuellen Konfiguration auf dem Server hier.

So weit, so gut. Und funktioniert auch wunderbar. Nur net für Subdomains. Der Grund is, wenn ma ihn daun endlich rausgfunden hat, relativ einfach: Die Serverkonfiguration setzt für jede Subdomain ein eigenes DocumentRoot. Die .htaccess-Direktiven werdn daun zwar übernommen, funktionieren aber net, weil’s im neuen DocRoot die /errorpage.php net gibt. Absolute Pfade (/home/username/www) funktionieren auch net, warum is ma net 100% klar, aber auch net sonderlich wichtig; Es geht jo net.

Und wos tuan?

Die Lösung is zwar einfach, aber a bissl mühsam. Wie auch immer, sie funktioniert. Der Clou: Man richte die Subdomains auf die Hauptdomain, damit sie das gleiche DocRoot verwendet. In der zentralen .htaccess werden die Subdomains dann auf das jeweilige Verzeichnis umgeleitet, und siehe da: Die Subdomains funktionieren, die ErrorDocuments funktionieren, es gibt nur mehr 1 zentrales DocumentRoot (= kein automatisches Erstellen der Default-Dateien in den Subdomain-DocRoots) und überhaupt is alles so, wie i ma des vorstell. Die .htaccess-Direktiven für eine Subdomain test: