things we learned

lessons from working in the design and web development business

July 5, 2012
by Tom
0 comments

Client-Work, CMS and versioning…?

Hello fellow webworkers out there, this is a question I’ve had for a while now (and still have not found *the* answer).

How do you establish a versioned workflow for a typical client-website-job, a website which is driven by a cms like TYPO3 or Drupal and is hosted on a server that’s in the client’s responsibility or on a typical hosting environment?

Things to consider:

  • Editors on the client’s side will add or remove contents, either directly via the cms or directly on the server.
  • Several people are used to work on templates or css/js files – through laziness or comfortability via ssh/sftp
  • If I’d establish a local development server, how would I make sure that the environment (software versions and capabilities, charsets etc) mirrors the client’s server? What if I need to mirror several clients’ environments?
  • (…) My best guess at the moment is using GIT, and having at least local versioning on my local machine. But in terms of team-work and syncronizing this is far from being useful. The biggest throwback is how the files are “synced” with the server; as long as users will connect and change directly via ssh or sftp, all versioning attempts are futile.

Please share your insights in the comments, I’m really stuck right now.

July 4, 2012
by Oliver Beckenhaub
0 comments

Google recommends responsive design!

Why? Because…

  • Using a single URL for a piece of content makes it easier for your users to interact with, share, and link to your content, and a single URL for the content helps Google’s algorithms assign the indexing properties for the content.
  • No redirection is needed for users to get to the device-optimized view, which reduces loading time. Also, user-agent-based redirection is error-prone and can degrade your site’s user experience (see “Pitfalls when detecting user-agents” section for details).
  • Responsive web design saves resources for both your site and Google’s crawlers. For responsive web design pages, any Googlebot user-agents needs to crawl your pages once, as opposed to crawling multiple times with different user-agents, to retrieve your content. This improvement in crawling efficiency can indirectly help Google index more of the site’s contents and keep it appropriately fresh.

Read full article on the Google Developer Page

The challenges of responsive web design go way beyond media queries and screen widths. In this article we look at some of the key issues you need to explore when embarking on a complicated web project, considering if, how and why the project should be made responsive. […]

[…] the most important thing right now is to make sure you ask the right questions at the start of each project, make the right choices, and jump into experimentation yourself with a maximum amount of pragmatism. If you find a good idea to make all of these challenges smoother, please write about it and share your discoveries on the web!

Rudy Rigot: http://dev.opera.com/articles/view/responsive-web-design-a-project-management-perspective/

December 2, 2011
by Oliver Beckenhaub
Comments Off on Andy Budd about the “Designer-Pricing-Discussion”

Andy Budd about the “Designer-Pricing-Discussion”

Andy Budd hold a little Speech this morning on Twitter about Designers & Pricing. Some very wise words for all Designers! I just put together all his tweets in one little post, so it’s easier to remind and get his points. You definitely should follow him on Twitter!

The one thing holding the design industry back is designers themselves. If agencies continuously under quote to win work, we’ll always be seen as a commodity expense and struggle to deliver quality. Designers love what they do so much, they’re often willing to compromise on price just for the creative challenge. We think that clients have the power because they have the money. However money is everywhere. Creativity is in short supply. The truth is, it’s us designer that have the real power. We just don’t know it. This isn’t a case of price fixing. It’s a case of designers acting professionally and not quoting less time than they know it should take. Don’t give your work away for free. You’re better than that. Designers have all the power. They just need to be willing to use it. If you don’t like the terms, walk away. Designers, you do realise that you’re allowed to negotiate? If you’re clients are only buying based on price, are you sure they’re the right clients for you? Price sensitive clients usually aren’t the best. For the majority of clients, price is just one issue, and rarely the most important one. If you’re willing to give it up on the first date, don’t be surprised if you get a certain reputation. Indeed I have, based on 7 years of running a business and many discussiosn with other designers and agencies. Designers should always be pushing for more, rather than settling for second best. Clients are able to negotiate on price when their is a glut of undifferentiated options on the market.

The solution. Be different and set yourself apart from the competition.

Update Dec 3, 2011: Andy Budd has now written a blog post about it. “Why Designers are holding themselves back”.

November 27, 2011
by Tom
0 comments

Make #grid.js play nicely with wraps

Fueled by Jon Tan’s talk at the Beyond Tellerrand conference, I tested the hashgrid.js for my “About me” page.

While trying to get the baselinegrid play along with relative values instead of the fixed pixel values, I noted a strange behaviour.

I wanted the grid to work only on my wrapping element (in my case the body-tag which I had set up with a width in CSS) and not on the whole document. I figured that, because the grid uses position:absolute to place itself, I only needed to apply position:relative to the css-rules for my body-tag in order to get the grid being “aware” of my desired wrapper. And yes, now the grid sat “inside” my wrap and was not spread over the whole document as by default.

But: As soon as I wanted to display the grid (by toggling with the “g”,”f” and “h” keys), I noticed that the vertical grids were not shown at all, reason being that they all had inline-css which stated display:none, which I found out after a while by inspecting the generated source code with Firebug. Hmmm.

Looking into the hashgrid.js code I found the reason. On line 248ff:

	function showOverlay() {
		overlay.show();
		overlayVert.css({width: overlay.width()});
		// hide any vertical blocks that aren't at the top of the viewport
		overlayVert.children('.vert').each(function () {
			$(this).css('display','inline-block');
			if ($(this).offset().top > 0 ) {
				$(this).hide();
			}
		});
	}

Inside the if-statement is checked, if the current vertical grid container has an offset().top of “0”, ie it is at the top of the page. If not, it will be hidden (thus the display:none; gets applied as inline-css for that container).
Now, if the grid is not working on the whole document, but on a wrapping-container, chances are, that the offset().top value is anything but zero. Instead of checking against a fixed value, it should check against the offset().top value of it’s parent element:

	function showOverlay() {
		overlay.show();
		overlayVert.css({width: overlay.width()});
		// hide any vertical blocks that aren't at the top of the viewport
		overlayVert.children('.vert').each(function () {
			$(this).css('display','inline-block');
                        /*if ($(this).offset().top > 0 ) { */
                        /*better: check for parent elements-top: */
			if ($(this).offset().top > $(this).parent().offset().top ) {
				$(this).hide();
			}
		});
	}

With this small change I got the hashgrid.js working with my “wrap”, as you can test on the “About me” page, and it still works, if applied as “out of the box”, on the whole document.

November 24, 2011
by Tom
0 comments

How jQuery Selectors work

Only recently, triggered by the discussion on why IDs are slower than classes when accessing through CSS-selectory, I wondered, if jQuery was actually slower on class-based selectors.

I think yes, because there’s a native JS-function DOM-method document.getElementByID and I read somewhere that jQuery will use that if it is has to deal with something like $('#myID').doSomething(); whereas it’ll use some jQuery-internal magic with $('.myClass').doSomething(); which in theory should reduce performance a bit.

So where does this lead?
Should I bloat up my HTML markup with classes for usage in CSS and IDs for jQuery?
Will the markup-overhead eventually eat up the performance-gain?

I don’t know. I don’t even know if this matters if you’re not building the next Facebook.
If you do, I would like to hear in the comment-section.

But at least I found a resource where the jQuery-Selector-magic is explained:

http://www.wordsbyf.at/2011/11/23/selectors-selectoring/

via: @MadeMyDay

November 24, 2011
by Tom
0 comments

Beyond Tellerrand 2011 Talks

For quick reference, we’ll put up all the links to the talks held at #btconf as we (@webrocker & @beckenhaub) find them.

This post will be updated a lot I guess, so please come back later.

But first things first: Many thanks to Marc Thiele (@marcthiele) for make all this happen!

Speakers and talks


Heiko Behrens (@hbehrens):
Mobile Apps With Javascript – There’s More Than Web


Jon Tan (@jontangerine):
Welcome To A Brave New World Of Web Type


Steph Hay (@steph_hay):
Who Cares About Content?


Chris Heilmann (@codepo8):
Breaking The Barriers – Moving Browsers And The Web Forward (Slides | Audio)
Watch the talk on vimeo


Tomas Caspers (@tcaspers):
How To Sneak Accesability In Your Project Without Anybody Noticing It


Simon Collison (@colly):
Notes From The Edge


Steph Troeth (@sniffles):
Cheat your way with UX (+ Problem Solving Infographic)
Watch the talk on vimeo


Aaron Gustafson (@AaronGustafson):
Crafting Rich Experiences with Progressive Enhancement
Watch the talk on vimeo


Vitaly Friedman (@smashingmag):
The Invisible Side of Design

Not linked yet


Naomi Atkinson (@naomisusi):
Going Beyond


Seb Lee-Delisle (@seb_ly):
CreativeJS – Beauty in the Browser
See the live coding examples from the talk


Yves Peters (@baldcondensed):
Trajan in movie posters: the rise and fall of the Roman Empire


Dan Rubin (@danrubin):
Hands-on Prototyping with HTML & CSS
Watch the talk on Vimeo


Des Traynor (@destraynor):
Creating Dashboards & Data Visualisations that Resonate


Jake Archibald (@jaffathecake):
Reusable Code, for good or for awesome!
Watch the talk on Vimeo

Bonus:

Not a conference talk, but…
Workingdraft Podcast 48 by @DerSchepp (and lots of others) with @naomisusi:
workingdraft 48

youtube direct gebabbel

Photgraphs of speakers courtesy (cc) stn1978 / Stefan Nitzsche

November 16, 2011
by Tom
0 comments

LESS is more, more or less

(Updated: please see update at the end of this post)

Inspired by the recent article “Less” on “Stuff & Nonsense” by Andy Clarke (@malarkey), I finally jumped the wagon and had my first round with the CSS-pre-processor Less.

My usecase is a rather large website that changes it’s colour-scheme to complement the look of the corresponding print-magazine, which is published roughly every two to three months.

I have a rather simple colour-scheme, with a solid basecolour and three variants that are basically results of overlaying the base with different transparent whites (50%, 80%,90%), along with some solid white, black and grey (not discussed here):

Lighten Up!

So my firstmost interest in Less was with it’s colour-functions, esp. the lighten() function seemed to me like a very good idea:

Color functions
LESS provides a variety of functions which transform colors. Colors are first converted to the HSL color-space, and then manipulated at the channel level […]
lighten(@color, 10%); // return a color which is 10% lighter than @color
[…]

So, assuming (and not quite understanding how the HSB (Hue|Saturation|Brightness) Colourspace works), that this is exactly what I needed, I eagerly wrote my first set of rules:

@base : #4d4962;
@c50 : lighten(@base,50%);
@c80 : lighten(@base,80%);
@c90 : lighten(@base,90%);

I thought, if I add a 90% white layer over my basecolour in Photoshop, (resulting in #ececee), “lightening” my basecolour in Less by 90% would do the same (and likewise for the other two values).

What I expected (coming from photoshop) was:

.base {#4d4962}
.c50 {a4a2af}
.c80 {dadadf}
.c90 {ececee}

Boy, was I wrong. What finally ended up in the compiled css-file was:

.base {#4d4962}
.c50 {#d1cfdb}
.c80 {#ffffff}
.c90 {#ffffff}

So you’re thinking, wtf? – Welcome to the club.

To cut a long story short, after comparing the “Less” values (again, in photoshop) with the declarations and the basecolour in HSB-mode (250°|26%|38%), I observed that the new “B” Value (remember, brightness) apparently gets computed by taking the B-value of the basecolour and add the value from the lighten() function.

If the result of that operation is greater than 100, the resulting colour is white.

So if you try to make a colour, say, by 35% lighter, and the colour has a “B”-value that’s already at 70%, you’ll end up with 105% aka white. What I expected was something like “if the colour is at 70%, and I’ll make it 30% lighter, that’ll be 30% of 70%, i.e. 23%, so the result will be 93%, i.e. slightly darker than white (o.k., bad example, but I hope you get the drift…)

I am still unsure if this is the correct behaviour and/or if the description on the Less page is misleading.

You Spin Me Right Round Baby Right Round Like A Record Baby Round Round

Another thing that puzzles me is the spin() function. Here, the “hue” value is modified, or “rotated” around the HSB/L cone by the value given in the function.

In @malarkey’s article, at one point he writes:

@col : #468DB6; // Base colour
@comp : spin(@col, 180); // Complementary colour

Without getting to deep into colour-theory, a Complementary Colour is the colour that sits opposite to the basecolour on the colour-circle, and is used often to contrast and enhance the basecolour.
So computing that colour via Less seems like a good idea, but again, there’s some hair in the soup…

This time, the “rotation” affects the “Hue” value only, and again the resulting colour is not exactly what one would expect.

Using photoshop’s “invert” function, the Complementary Colour of my basecolour
#4d4962 (250°|26%|38% in HSB)
should be
#b2b69d (70°|14%|71% in HSB).
Using spin(@base,180), Less will give me
#5e6249
which equals to (70°|26%|38%) in HSB.

Note how only the first value differs from the basecolour’s HSB-code and how the resulting colour is not what is desired.

So the conclusion for me is not to rely on the colour-functions of Less, if I need to create visually harmonic schemes.
I’m totally at loss about the “lighten” thing, since simulating a transparent white overlay to get the resulting colour seems not to work with Less, I have no idea how to circumvent the photoshop-route…

What do you think?

Update

I have made some more tests, and there is one huge difference between the HSB colorspace (what Photoshop offers in it’s colorpick menu) and the HSL colorspace (which is used internally in Less), and it took me a while to spot it: Photoshop says that #4D4962 is 250|26|38 in HSB. After I found a way to debug the HSL-values in Less, I was surprised to see 250|15|34 in HSL. So no wonder that the HSB values put into HSL will not result in the expected color. :-/

October 24, 2011
by Tom
0 comments

Design Professionalism

Oh boy, is this spot-on or what?

Design Professionalism – The designer’s guide to taking back your profession

In this read by Andy Rutledge (@andyrutledge) you’ll find reasons and ideas on why most designer’s (professional) life tends to be on the frustrating side and what to do about that.

[…] So we make do, and satisfaction suffers. We then build the habit of making do and taking what we can get, and soon we find it easy to equate getting projects (at whatever cost to our integrity) with attaining success. In this manner we craft a career of compromised integrity, which of course inevitably leads to ongoing dissatisfaction. It should not be so. […]

Mind you, chances are that you’ve made plenty of the “mistakes” he describes, at least I’ve been there more than once. It hurts to read about your own shortcomings, it infuriates at times because it is written in such a no-bullshit, no-compromises way.

Many times my initial inner response was like “yes, but…” – but in this “but” you’ll find all the answers and petty excuses why your job sucks today.

It kindled the flame that has almost been put out by the day-to-day frustration of working “to get by”, of dealing with “difficult customers” (yes, not clients), it tickled my pride of doing the work I do, of my academicaly education, my progression and the now 16 years of fiddling with the web.

Stop being a merchant, start being a professional!

October 21, 2011
by Tom
0 comments

Quality Is Not An Option

A brief musing on why creative and passionate people tend to be the ones not getting paid.

In the magic triangle of project management are three sides that will influence each other:

  • Time
  • Money
  • Quality

If you have no time and want quality, you need to raise money.
If you have no time and not so much money, do not expect quality.
If you don’t have money but a lot of time, you may still get quality.

Here’s the problem for people who are passionate in their field:

How can quality be a resource that’s negotiable like the other two, time and money?

For most the answer is: It’s not.

We cannot create low-quality work, just because there’s not enough time (in comparison to the budget).

We will always try to deliver the best work we can, because this is why we do the work in the first place.

If we are faced with a low-budget project (or better: a project with a not-so-healthy time/money relation), suddenly there will be a voice in our head saying “damn, if this will not bring money, then at least this should be something I can be proud of and put in my portfolio, so let’s file this under ‘promotional investment’”, and off we go, working overtime and underpaid – again.

The outcome: Even if this project will end up in the portfolio (and/or gets recognized by the client’s peers, for all the awesomeness we created), sooner or later the price paid gets public (and the odds are that it’ll be the client who was asked), and we’ll have a hard time raising a realistic budget for the next job. And so on, and so forth.

Welcome to Catch 22.

Any Conclusion? – Leave us a comment.

Illustration: wondertom