I attended 11 presentations, 3 of which I liked the best and will discuss here.

‘Contextual jQuery’ by Doug Neiner

Doug discussed writing code contextually rather than declaring as a better, more efficient way of writing jQuery. Some examples:

• Delegate events instead of the traditional $(selector).click()
• Using traversing, for example: .closest() instead of .parent()
• Use functions, so you don’t repeat code
• Don’t make your JS dependent on edits in your HTML
• Use as few selectors as possible in document ready

The main advantage of coding contextually is that the code is much easier to manage en makes better use of the available resources. Apart from that, the size of the code is often smaller because code can be re-used.

A tip for making better use of resources is loading script parts when they’re needed: users usually don’t use a page in full, so there’s no reason the load all code initially. For example, the script for a contact form can be loaded only when a user focus on a form field. As long as he or she hasn’t, you can expect the form doesn’t need to be send.

Doug also talked about how we don’t always need to pick the fastest option perfomance-wise: the decision between a fast (and harder to maintain) and a slower (but easier to maintain) method is completely dependant on the situation. When something needs to be executed at load is usually best to go for fast in order to have a quick a pageload as possible. But when a code snippet needs to be executed after a click, it’s probably better to go with the solution that’s easier to maintain – these type of scripts usually don’t need to be performed several times over, so the few extra miliseconds shouldn’t be a problem.

You can view Doug’s presentation.

‘Web vs. Apps’ by Dion Almaer & Ben Galbraith

Dion and Ben was by far the most entertaining as they’re good story-tellers. They talked about the pros and cons of webapps vs native apps. They provided examples from their own experience in working for clients like Wal-Mart.

What I got out of the presentation is there’s pros and cons to both webapps and native apps, and that the decision mainly depends on the specific target audience and project goals. Also, Dion and Ben believe that both can co-exist, especially when the overlapping parts can be maintained in the same development environment, for example with PhoneGap or similar software.

An obvious advantage native apps have over webapps is that they currently have much more possibilities in terms of device usuage. They can for example use the devices camera or address book, something that’s not (yet?) possible with webapps.

‘jQuery Mobile’ by Todd Parker

Together with the Filament Group, Todd Parker works on the jQuery Mobile project. He talked about the state of the project and their future plans.

Personally I haven’t had much experience with jQuery Mobile, I thought it was simply a template based platform for easier mobile development. As it turned out, jQuery Mobile is much more than that – it includes many handy tools for mobile development such as ajaxifying links in combination with smooth transitions.

Todd’s talk wasn’t just interesting because of everything I learned about jQuery Mobile but also because of the insight he shared on developing and testing websites for mobile devices. I’ve been working on several responsive websites recently, so I did a fair share of testing on mobile devices. Most of it on the iPhone 3 and 4, as I figured they’d cover most of the mobile usuage as for example Android browsers are quite similar to iOs browsers. After attending various keynotes it became clear to me that Android browsers are much more different from Safari on iOs than I’d realized. Todd told us they in fact test on 40 different devices and operating systems! While that might be slightly overdoing it when it comes to testing mobile websites, it does make sense at least to test on a Windows Phone, Blackberry, iPhone and Android phone. And then there’s the various versions of operating systems and browsers… Serious testing for mobile is a time-consuming activity.

In conclusion

I’ve learned a lot on the jQuery event in Oxford, and there’s a variety of things I intend to find out more about. Finally, I feel reassured that I am going in the right direction in terms of webdevelopment.

The guru for this session was Ruben Bos of Mangrove although he immediatly denied being a “guru”. At Mangrove he worked on apps like Txxi, BOVAG and Ministry of Defense. He explained UX-design-techniques and best practices, largely based on lessons learned from years of web development. He talked about sketchboarding, a technique used by Adaptive Path, and how it helps to discover better and faster UX solutions.

The Workshop

Ruben handed out the creative brief of the “Kroket-app”. The concept of the app: Order a Kroket, a typical Dutch snack, and it will be brought to you wherever you are. The target audience is lazy people that are very hungry, or drunk. The primary goal of the app? Sell more Krokets!

I teamed up with Saul Mora and Koos Looijesteijn. We started writing the user-stories for the Kroket-app on post-its and prioritised them by putting them on the wall. The user story “As a hungry/drunk person, I want Krokets easy and quick” was our top one, followed by “I want many Krokets”.

Sketchboarding

Next up was defining the structure of the app. On a big piece of paper, the sketchboard, we wrote down the requirements of the app and the type of screens a user would encounter in the first version of our app. It would consist of only two screens: the order-screen and the confirmation-screen. Of course we had all kinds of ideas to make the app better, but “the client” wants to launch fast so we’re saving the advanced features for a next release

Ruben dealt out paper-templates with 6 screens on it and we had to sketch 6 versions of each screen. This exercise enables everyone in the team to think about the UX of the app and (hopefully) forces new insights into the UI-elements used in the app. After 30 minutes of sketching each team compared and discussed their sketches (± 18 screens per team!) and chose the best elements of each for the final version of our order-screen. This same method was applied to the confirmation-screen and when we were finished every team presented their version of the Kroket-app.

Our app would be built with the drunk user in mind, so our homescreen would start with 1 big Kroket and by swiping you would add more Krokets to your order. Your location would be determined by using your GPS and there would be one big order button. When you click it the confirmation-screen comes up and you’d see a map of the location your Kroket is in. The price of the order would also be there including the message to pay upon delivery.

It was really fun to see what each of the 10 teams came up with. Some of the original ideas:

• Show the calories of the Krokets and compare it to the amount of energy (“10 Krokets equals climbing half way up the eiffeltower”)
• Choose your type of meat by playing a shooting-game, shooting the animal you want to eat
• Build an elegant version of the Kroket-app (Croquet-app) with exotic meats and sauses
• If you’re on a boat Captain Kroket would deliver your Krokets by jetski

The winners of the workshop, a version of the Kroket-app inspired by Clear, received an app-sketchbook. Luckily he brought more, so everyone got one

Then of course it was time for Krokets… or was it?! No! We had pizza, but that’s okay, next time we’ll just get drunk and order Krokets with our own Kroket-app.

This question was asked by @bartjanverhoef, VI-Company’s creative-director, after a discussion about Joni Korpi’s awesome Golden Grid System (GGS) not having a PS template to start with.

Problem?

“If I’m to use a percentual grid, how do I make a grid template for it in Photoshop?”

TLDR; Downloads

The answer is very straightforward. The way I did it was by taking a familiar fixed-width (f.e.: 960PX which would have 8 columns in GGS) and started converting the different percentages of the gutter, the margin and a single column to pixels.

I threw the calculations in a spreadsheet (available in the downloads section). You can change the variables (cells with a blue background color) and watch the magic happen. Make sure you always have a round number for your column width (and preferably a number that stays even when divided by 2, or you’ll have to work with half a pixel in PS to center something in a column).

The Downloads:

• GGS template + spreadsheet V1 (.zip, ±231KB)
• Golden Grid System by Joni Korpi
• GuideGuide (download this PS plugin, it’ll save you a lot of time)

Explanation

So, how did I do it and how can you use this technique to convert your own ‘percentual’ grids to PS pixel friendly grid templates?

First off, we have to know the min-width and max-width. For the min-width, I took 320PX. In my design, I always make sure that everything in 320PX mode has a width of either 50% or 100% (2 or 4 columns) so all items still have enough width on smaller screens.

For a max-width, I used 1680PX. This is the width in the GGS where the layout transforms into a 16 column grid. Knowing this, I gave my PS document a width of 2000PX.

The list

We need to determine the pixel widths of the following items in order to make our grid:

• gutter
• margin (left and right of the body)
• 1 column

After we’ve calculated these three items, we can fill in the table Joni gave us in his CSS comments. For a width of 320PX, GGS uses a 4 column layout:
# Margin 1 2 3 4 Margin
% 5.55555 25 50 75 100 5.55555

Step 1 – gutter

The gutter is calculated in EMs, so we need to know what 1EM in PX is, and because Joni kept the browser standard, it’s 16 pixels.

Now we know that 1EM equals 16PX. The gutter is 1.5EM:
16 * 1.5 = 24PX

*Gutter width = 24PX*

Step 2 – margin

The full width is 100% (320PX) so the margin should be 5.55555% of 320PX. In order to do this, we need to know what 1% in PX is (rocket science stuff):
320 / 100 = 3.2PX

1% equals 3.2PX. Now all we need to do is multiply 3.2PX times the margin (5.55555%):
3.2 * 5.55555 = 17,77776PX

*Margin width = 17,77776PX*

Step 3 – one column

In order to calculate one column, we have to take the full-width and scrape of the left- and right-margin:
320 – (17,77776*2) = 284,44448

*284,44448* is the width of 4 columns (100%). But we only need one (25%):
284,44448 * 0.25 = 71,11112

*One column width = 71,11112PX*

Other sizes

Once I made these calculations for 320PX, I threw them in a spreadsheet and found out that on the standard widths 320, 480, 768, 954 and 1680 – the column width is a number with decimals. We want to work with full pixels, so I started experimenting with the width (adding or subtracting 2PXs to/from the initial width and checking if the column width would give me a full number). The widths that work best are:

• 324 (4 columns)
• 478 (4 columns)
• 774 (8 columns)
• 972 (8 columns)
• 1692 (16 columns)

Outro

The best thing about this approach is that, even though you need to do some calculations from the start, you won’t take any risks in figuring out if your design would work on a particular device or width (like you would have to do with Elliot Jay Stocks PSD template). Call me a pixel-f!@#er, but that’s the way uh hu uh hu I like it !

I’d like to thank Joni Korpi for sharing his totally rad Golden Grid System, it’s awesome and thanks for inspiring me to write this article!

I’ve been using this GGS PS template for a while now, and I must say it’s made my hard knock designers life a tad easier. If you have a similar experience and want to share the love, you can e-mail me @olaf@vicompany.nl

Enjoy, and if you share this: thanks!

Back in January I read a tweet by designer Regina Casaleggio who said:

I fully agree, issues like these – and many others – ask for a different approach to address the specific needs and context of the web today, and to communicate the solutions we as designers come up with to our clients.

I bookmarked Regina’s tweet because it seemed like a good starting point to discuss the design process I’ve adopted over the past few years, a process I believe provides some good solutions to these questions.

The waterfall

Like many agencies, up untill about 2 years ago we used to work in a traditional waterfall method at VI Company: gather specs, get sign-off, design all the screens, get sign-off, build the site, get sign-off and finally: launch the site.

While this approach wasn’t ALL wrong ALL the time there were problems we kept running into. For example: the scope of a project would change after we’ve locked all the designs with the client and were busy building the site. Taking (part of) the project back to the drawing board at that point proved to be really difficult each time it occurred.

Or how about finding out in the dev phase that the actual site in a browser (or to add to the drama: in various browsers) behaves differently than expected in the design phase, but since those pixel-perfect designs were approved and signed off by the client, and the designer responsible was already busy working on a different project, changing aspects of the interface meant renegotiating with the client as well as screwing up said designers planning?

I could go on giving examples of the problems we ran into working this way but I’m sure you catch my drift: there had to be a better way.

Along came Scrum

Early 2010, software dev Ivo van Halen joined our team. Ivo was an enthusiastic Scrum supporter with quite some experience in working in scrum teams with other software devs and web programmers. He introduced Scrum in our company and our programmers and front-end developers pretty much adopted it straight away.

For those of you who don’t know Scrum: it is an iterative methodology for agile software development, wherein teams work in short iterations (typically 2 weeks) to create small portions of a product, allowing for renewing views and change after each iteration.

For designers used to working in a traditional waterfall process, crunching out complete, pixel-perfect designs over a stretch of time and handing over the finalized work to a developer, Scrum seems undo-able. It wasn’t any different for me. In fact, I’ve never much liked methodologies all together: I used to think that if only I’d be left alone for a while I would come up with the best design solutions – any methodology would only get in the way of my creative process. Realizing this, and writing it down now is actually a bit embarrassing but yes, I was that designer at one point.

Agile design

Scrum really became a thing for us over the course of 2010, and since it worked so well for everything dev we began experimenting with design in Scrum. It didn’t work out too well right way: it asked for a different approach in planning projects, and truthfully, us designers were stuck in the comfort zone of working the way we always had.

Trial and error got us a long way though and today I honestly can’t imagine not working in a scrum team alongside my teammates who are simultaneously working on all the other parts of a given website while I am designing.

Our process as a whole on a given project is pretty much textbook scrum-development: There’s a scrum-master and a product-owner, we write user-stories, plan which user-stories we’ll tackle in a 2-week sprint, draft todo’s, estimate their impact and get to work. During the sprint we’ll have a team stand-up each morning where we share some details on what each of us is working in, things we’re running into, etc. We finalize each sprint with a demonstration of our work to each other and the client.

Our initial sprint

Sprint 0 – an existing concept in Scrum that we’ve customized and expanded for ourselves – is where the magic happens in order for design in a Scrum setting to work for us.

Our Sprint 0 typically consists of one or two weeks – varying on the complexity of a given project – of working together on drafting and planning the basics of the project we’ll be building. Usually at this point we’ll only have a rough, conceptual idea of what we’re gonna design and build: we’ve sat down with the clients a few times and I’d have written a creative brief addressing the projects goals and our creative concept.

At this point we work together to simultaneously draft the initial set of user stories, (rough) wireframes and smart use-cases, going back and forth to create the outlines of the site we will be building. At the end of this sprint 0, the whole team will have a good idea of what we will be building in terms of functionality, complexity, etcetera.

Advantages

From there on, we can pretty much start to build stuff right away, working on various aspects of a site each with our own specific tasks but always together – bouncing of ideas and tackling (possible) problems along the way much faster as we are actively sharing knowledge from different fields of expertise, rather than working on a project from within our own cocoons, handing over our work once our contribution is finalized.

This way of working fully iterative with a complete team brings us various serious advantages. There is, as I’ve just mentioned, the obvious advantage of sharing knowledge and thus being able to come up with better solutions. Then there’s the advantage of being able to adapt to changing scopes quickly and easily: we can edit user stories as we go, our clients know beforehand that adding using stories will either mean removing others, or delaying the project and adding budget – something you’ll need to have covered when working agile – and adapt to the change almost immediately in the next sprint.

Apart from internal advantages there are various advantages for us working with clients too.

What hit me when I read Regina’s tweet back in January was that now, instead of presenting a full set of psd’s covering the entire site – a not so realistic representation of how a site will actually look and behave – we’re giving a far more realistic view of the final site by demoing the small bits we’re building each two weeks. In fact, since the client will have access to the development area from very early on, they can start using and testing it themselves, within their own setting, getting a actual feel for how type will render, how interactions will be, how the site will behave on different platforms and so on.

No need to say how much easier it is for both to design and develop responsive sites and preparing the client as to how it will actually behave on various devices. There’s no doubt we’d have a much harder time adapting to the specific needs and challenges responsive design brings us, both internally as in communicating with clients.

Disadvantages

Design in Scrum however isn’t JUST sunshine and rainbows. There’s some downsides I should address as well.

Reading all the above you’ve probably wondered how any client would allow us to just get to work, crafting their site each sprint at a time without having seen at least some visual representation of we’ll deliver in the end. And the truth is: no client to date has. This means that we do design a few screens beforehand, usually right after sprint 0, wherein the visual hierarchy as well as the look & feel of the site are addressed. In doing so, there’s the risk of either limiting yourself too much later on or not meeting expectations set at that point later on. Finding the right balance here is really hard and we still struggle with it sometimes.

Another issue we occasionally run into is that since we’re often working on the same stuff simultaneously instead of one after another – handing over deliverables to each other as we finish our work – is that it can be quite some work editing HTML and CSS to facilitate the final design of a page or specific element , instead of marking everything up from a final design right away.

That said: the advantages of including design in the Scrum process outweigh the disadvantages for us without a doubt. And as a designer who once believed that the design of a site was best served by him being left alone to work his magic, I am truly happy to add that Scrum taught me to be more humble as a designer and a better team-player.

Vorige week maandag, 30 januari (inderdaad, eerder dan gepland – Scrum werkt!) zijn we verhuisd naar ons prachtige nieuwe kantoor in het Groot Handelsgebouw.

Een goed begin…

Nadat we die maandag ’s middags onze belangrijkste spullen – onze computers natuurlijk… – uitgepakt en geïnstalleerd hadden, waren we klaar om aan de slag te gaan. En toen viel de stroom uit in Rotterdam en omgeving. Balen! Gelukkig hadden we de volgende morgen een herkansing en konden we dinsdagmorgen alsnog echt aan de slag in ons nieuwe kantoor.

Wat een ruimte!

Ondertussen zijn we bijna 2 weken verder en we zitten hier heerlijk. Een aantal van onze relaties is ondertussen al langsgeweest en we zijn blij met alle positieve reacties. Ook niet vervelend is dat het voor hen een stuk makkelijker te vinden was .

Afronding

Op dit moment zijn we tussen de bedrijven door ook nog druk bezig alle details op orde te krijgen, waaronder bijvoorbeeld de maatwerk kasten die op het moment van schrijven geplaatst worden:

Dubbel feest!

Niet alleen zijn we net verhuisd, binnenkort bestaan we ook nog eens 5 jaar. Voldoende reden voor een feestje dachten we! Volgende week donderdag vieren we deze mijlpalen samen met klanten en relaties.

Foto’s van ons kantoor als het volgende week helemaal af is vind je hier binnenkort, hou onze twitter in de gaten!

Lijkt het je leuk om ook eens te komen kijken naar het resultaat? Gezellig, de koffie staat klaar!

In a nutshell: I come from a small town near Nijmegen, but have been living in Rotterdam since 2007 in order to study Communication & Multimedia Design (CMD) at the University of Applied Sciences Rotterdam.

After receiving my diploma this year – I decided to place a shot on Dribbble asking if someone could help me find a job. Bart-Jan replied within the hour and that’s how I ended up at VI-Company. What can I say, I’m a lucky guy!

When I was about 14 years old, I started experimenting with Adobe software: Flash MX at first, Photoshop and Illustrator followed not long after. Finding a study was rather easy, I decided to leave Nijmegen behind and move in with my dad (who already lived in Rotterdam) in order to study CMD. Since then, I’ve moved twice – now I live with my brother in a nice, roomy apartment where we’ve managed not to kill each other (yet).

Every Mon- and Friday I practice Wing Chun Kungfu at Wu Dae Rotterdam. It helps me to sober up after an intense weekend and to calm down after a week of inspiring projects. After my training I usually eat quark but I love spicy and Italian food. Oh, I also play the (electric) guitar from time to time.

Next to web design I (screen) print my own illustrations on paper and/or fabric. I’ve been screen printing for about a year now at Mesh Print Club, you can check out my designs and prints on my website.

I’m writing this on my second day at VI Company and I can honestly say that I’m starting to like it here (already). My colleagues are professional and speak their mind, I can learn a great bunch from ’m! Thanks for the opportunity, I’m looking forward on the teamwork and ALL the projects!

Sincerely,
Olaf

What happened?

The year started with Laurens joining our team as a front-end developer. On Februari 21^st the first VI-baby was born! This year Tim & Ivo went to the SDN Meeting, DevDays and OpenAgile. Bart-Jan & Jan Paul went to Now We Are Talking and won the CorelCup. Mendelt joined the team, Ivo and Laurens got married, not to each other by the way.

The Design & Front-end Team went to the Graphic Design Museum. We teamed-up with Supersteil for Voetbalfest 2011 and… lost every game. The whole team went to Oktoberfest and in November Veronique became our office manager.

Any new projects?

Of course! We launched four online annual reports. We launched a couple of sites for ING and made a site for BOB Detachering. We also launched a mini-site promoting our annual reports. And we re-launced our own new site last March and re-relaunched it in November.

Looking ahead

2012 started with Olaf Muller joining the team and in Februari we’ll be moving to a bigger office in the Groothandelsgebouw. We’ve got a few new projects in the works so stay tuned!

Psssst, we’re still looking for new team-members!

While it usually worked out well, I do recall a few instances of banging my head against the wall because I dug myself a deep coding hole from which I was scrambling to get back out of…

A year in which I learned a lot of new things went by, after which Laurens joined our team as a second front-end developer. We soon started to see the potential of working together on some of the tough challenges that came on our path.

It’s all a matter of perspective

You might feel that two front-end developers working on the same problem is ineffective, only one person can operate the computer you’re coding on right? And it’s true, it càn be ineffective: there have been moments where it felt like one of us was just watching the other person type. But most of the time we managed to crack these so called “hard nuts” much faster because the other one brings in a new perspective to solving the issues at hand.

Getting to the solution faster isn’t the only upside of pair-coding to us – I dare to say that we both improved a lot at our job in a relatively short period of time, because when we are pair-coding it’s often like a peer review where we’re quick to point out mistakes or oddities in each others code, thereby preventing our code from getting too messy or inefficient.

Maybe we should throw it all away?

There have been numerous times going over an older piece of code, seriously wondering if we wouldn’t be better off rewriting it from scratch. And sometimes we did, too. It might feel a bit odd to throw away code that’s “working fine”, but it feels great when you decide to revise your code and you manage to come up with something that’s so much better instead.

Obviously, rewriting code from scratch isn’t always a viable option, so revising small bits of code when you get the chance will suffice in many cases. Do strife to update your code or tell your team mates how to achieve better results when you spot something that could be handled better.

Involving team members

Since Laurens and I are both front-end developers, working together on front-end issues was obvious. However, I recently discovered just how much you can learn from working on front-end issues with a programmer as well. In my case Ivo or Mendelt.

Since they both are damn fine C# developers, they offer a whole new way to look at projects using languages like JavaScript. I’ve done some pair-coding on a few different projects with them, and often found that I was learning (and soon applying) so much from the way they were handling code. It would probably have taken quite a while longer to figure out all those things on my own. Instead I learned many new and neat tricks from working on these projects with them for a couple of hours.

Get off your island

I hope I have given you a small insight in how efficient and beneficial pair-coding can be when trying to solve tough coding problems. I encourage you to get off your island and give pair-coding a shot! You might find it just as big of a revelation as I did when I first started working together more closely with Laurens, Ivo & Mendelt.

September 2011 was het zo ver. Met 8 personen op 140m² werd toch wel erg druk en zeker nu het al 10 personen zijn. Dus: verhuizen? En waarheen?

Een brainstorm sessie met het team gaf ons een aantal COA’s:

• Rotterdam. En Rotterdams.
• Nieuwe boost / Energie
• 1 februari 2012 operationeel
• Wow-factor
• Laten zien waar we voor staan. Kwaliteit en het behalen van doelen.
• Agile werken stimuleren.
• Bereikbaarheid voor klanten en onszelf.
• Professionele en zakelijke uitstraling met een eigen creatieve insteek.
• Mogelijkheid verder te groeien tot 16 personen. (300 m²)

Met deze lijst zijn Kees, Bart-Jan en ik op kantorenjacht gegaan. Zo hebben we gekeken bij de Maastoren (te hoog en te zakelijk), Central Post (te groot), Millennium toren (geen Wow-factor), Weena (niet creatief), en nog vele andere locaties. Totdat we het Groothandelsgebouw bezochten. In eerste instantie was het even wennen maar we hadden er al gauw een goed gevoel over.

Oktober 2011

We bekeken enkele ruimtes in het Groothandelsgebouw die voor ons interessant waren. Toen we een ruimte vonden die aan de eisen voldeed, zijn we voor een derde keer met het gehele team gaan kijken. Na enige opmerkingen en vragen was iedereen positief over de ruimte. Hierna begonnen de onderhandelingen en uiteindelijk was het rond. Per 1 december kregen we de sleutel van unit E4.166. De ruimte heeft uitzicht op Rotterdam CS en bevindt zich aan de noordkant (dus niet te warm in de zomer).

November 2011

De eerste plannen en planningen worden gemaakt. Wie wordt onze architect? Wat gaan verbouwen? Welke kleur? Welke? Wat? Waar?

Via referenties op internet kwamen we in contact met Jamie van Lede van ORIGINS en hebben we een kennismakingsgesprek gehad. Jamie kon ons direct al goed helpen waarna onze officiële samenwerking werd gestart. Jamie en ik hebben samen een begroting opgesteld waarna in een brainstorm sessie met Jamie onze ideeën en wensen werden omgezet in concepten.

Stukje van de briefing:

Wensen

We werken in scrum teams, wat betekent dat we in (wisselende) project teams samenwerken. We moeten tenminste drie afzonderlijke werkgroepen hebben met werkplekken, scrumboards en ruimte voor ophangen/uitleggen van usecases, wireframes, ontwerpen e.d.

Om af en toe in afzondering te kunnen werken (alleen of met z’n 2-en) hebben we behoefte aan een kleine aparte ruimte. Daar moeten we in elk geval over een zitplek en (aansluiting voor) pc/laptop beschikken.

Ook voor het ontvangen van klanten en vergaderen hebben we een aparte ruimte nodig, die aan zo’n 6-8 personen ruimte biedt. In die ruimte presenteren we ook ons werk, dat doen we – afhankelijke van de context van de opdracht – met behulp van pc, tablet, mobiele apparatuur en groot scherm.

Naast werk- en vergaderruimte hebben we behoefte aan een plek om gezamenlijk te lunchen en/of met meer mensen tegelijk te kunnen zitten (voor intern overleg en/of incidenteel grotere overleggen). Daarbij hoort ook een (volwaardige) keuken.

Tot slot willen we ruimte hebben voor ontspanning, met onze tafelvoetbaltafel, natuurlijk.

Voor de ruimtes geldt dat ze niet allemaal apart gerealiseerd hoeven te worden, het mogen zeker enkele multifunctionele ruimtes zijn.

Sfeer en inrichting

We zijn erg gecharmeerd van open ruimtes, het gebruik van hout, glas, lichte kleuren en speelse details.
Voor ons kantoor zijn we op zoek naar een soortgelijke balans die aansluit bij ons werk en karakter: enerzijds willen we een professionele, ‘opgeruimde’ omgeving die er perfect op toegerust is om te werken volgens de scrummethodiek, anderzijds willen we een creatieve, inspirerende omgeving waarin aandacht is besteed aan details en waar zowel onze klanten als wijzelf ‘van onder de indruk’ kunnen zijn.
Een aantal dingen die we hier ook belangrijk bij vinden:

• daglicht en goede verlichting
• open
• branding
• planten

December 2011

De concepten worden daadwerkelijk omgezet in werkzaamheden. Aangezien we onze organisatie zoveel mogelijk volgens Agile methodes leiden kon de verhuizing niet uitblijven. De verbouwing loopt momenteel in tweewekelijkse sprints waardoor we op tijd zien of we daadwerkelijk op schema zitten.

Afspraken worden gemaakt met de aannemer voor het verplaatsen van wanden, de schilder komt langs, voorstellen voor vloeren worden gemaakt en een keuze voor bureaus. Door de sprint worden onze keuzes binnen enkele dagen beslist zodat we snel kunnen schakelen.

1 februari komt steeds dichter bij!

Wordt vervolgd…

Open Spaces, tracks, interesting speakers, lots of fun, food and activity: On November 3^rd Ivo and I went to Agile Open Holland 2011, a 2-day event held in Dieren.

Here at VI Company, we’ve been working with Agile methods for about a year and a half now and are really excited about it. So needless to say we were looking forward to AgileOpen, where we could share experiences with other agile enthusiasts!

OMG we’re newbies!

Upon arrival in Dieren we were asked to form a line in order of experience with Agile working – to our astonishment some of the attendees had up to 15 years experience! Needless to say we realized we came to the right place to learn more about the subject.

After introductions, Sander Hoogendoorn – who we’ve seen several times on SDN events and DevDays – did a keynote about the proliferation of Agile and how Agile basically is a big box where we can take best-practices out of. In other words: Agile fluffiness.

After Sander’s keynote there was some time for coffee and getting to know some of the other attendees. The rest of the day was divided into OpenSpaces. After an introduction on what OpenSpaces is about, everyone suggested topics and these were planned into sessions throughout the day.

OpenSpaces

The OpenSpaces were really interesting, not in the last place because of the diversity of people attending. Being scrum masters in a small, flexible organization ourselves, we were shocked to learn how slow and inefficient some – bigger – companies are in dealing with scrum. Contrary, we realized how reasonably well we are doing ourselves.

The OpenSpaces we attended:

• Agile Adaption Outside the Team – In which we discussed how to organize an organization according to scrum in it’s entirety – as opposed to just the development team. In conclusion: it’s hard, but in time we figure it’s certainly possible.
• The big scrum master game – A game in which we we were asked questions about being a scrum master, in order to test our knowledge.
• Kanban – We’d heard some things about it, but didn’t quite know what it was. In short: very interesting, do check it out here: getkanban.com

After a long day of discussing Agile, Lean, Scrum en Kanban, we left the venue to visit Polysport in Dieren – an activity center nicely located in a natural environment with tennis courts, in- and outdoor activities and a nice bar (Hertog-Jan draft!) After a good meal we took on some of the indoor activities. We did fairly well climbing, curling and shooting bow-and-arrow. Afterwards we relaxed at the bar where we had a great time with the other attendees sharing ideas until 2:30 in the morning.

The next day we continued OpenSpaces, mostly outside due to the beautiful weather, which went even better than the first day since people got to know each other a bit better. In these OpenSpaces we discussed 360 feedback and doing so in combination with PlanningPoker (Ivo wrote a blog post on that topic). We also attended an interesting session on Retrospective and the various ways that can be done.

Agile Open 2011 was a blast: we learned a lot and are really inspired to further improve our stand-ups, planning sessions and retrospectives!

We like to think that we build pretty awesome websites. We spend much time creating websites with great content that work on many browsers and devices and that are of course beautiful to look at. But all this effort is lost when a page takes too long to load. People will leave when you make them wait.

Studies done by Amazon indicate that they lost 1% of sales for every additional 100ms of load time. Google found that adding .5 seconds load time to their search results page resulted in 20% less pageviews.

There are many causes of poor website performance like slow web-servers, slow database-servers or lack of caching. In this article I want to focus on the last part of the chain: getting the web-page from the server to the visitors browser.

A web page consists of multiple parts. The page itself (html), css files, javascript files, images, perhaps webfonts and more. All these files need to be transferred to the visitors browser in order to display the page. Transferring these files can be sped up in three ways;

• reduce the number of files per page
• make the files smaller
• send more files at once.

We use several strategies to achieve this:

Combine files

Setting up and closing connections to a webserver takes some time. It makes sense to combine files to limit the number of connections that need to be set up and closed to load a single page. We often use css-sprites to combine many small images into one big image. This reduces the amount of files sent to the browser.

Compression

We configure our servers to compress files. This reduces the size of files sent at the cost of a little bit of overhead compressing files on the server. Large files compress better than small files so it’s a good idea to combine files and use compression.

Use client side caching and cache invalidation

Usually a lot of static files are reused on many pages within a site. Logo-images, webfonts and css-files are often displayed on all pages. By setting several headers along with your pages you can instruct browsers to remember these files between page views. This dramatically reduces the amount of files a browser needs to load.

The biggest problem with client side caching is cache invalidation. Browsers won’t know when files on the web-server have changed. They will happily keep using old versions of files when a new version of the site is deployed. This obviously can cause problems.

There are two ways around this problem and they both involve changing the url’s to files using a version number.

The easiest way to do this is to add a request string after your url’s. For example instead of using the url http://myserver.com/img/logo.gif you can use http://myserver/img/logo.gif?v=12 and make the version number configurable. When you deploy a new version of the site you can increment the version number. The browser will now see a reference to the url http://myserver/img/logo.gif?v=13 and refresh it’s cache because it thinks this is a different file.

This works well for files referenced from dynamically created websites but it doesn’t work so well for images referenced from css files for example. We don’t create our css files dynamically on the server so we can’t update version numbers dynamically. We add version numbers to the paths of our static files.

When you look at the source of some of our web-pages you will see paths like http://myserver.com/v12/css/main.css. By making all references to files inside css relative to the location of the css files the version numbers are automatically included. So an image referenced from main.css like ../img/logo.gif will resolve to http://myserver.com/v12/img/logo.gif.

Serve static content from somewhere else

Web browsers limit the number of simultaneous requests they make to the same server. This can slow down your website. A modern web page typically consists of more than 10 to 40 separate files but most browsers will only do around 5 to 10 requests to one server at the same time. The way to speed this up is to serve different files from different servers.

Another advantage is that this will make requests smaller. Most websites store small packages of data called cookies in the users browser. These cookies are then sent back to the server with every request. But servers only use cookies when handling requests to dynamic content. By storing static files on a different server you reduce the amount of data browsers send to your server and less data equals more speed.

Using more than one server is overkill for most websites. But you can use a separate domain name for your static files at no extra cost. If you use http://myserver.com to host your website you can host your static content from http://static.myserver.com that points to the same server.

Use the tools wisely

These are just some of the tricks we used to speed-up our sites. Of course you shouldn’t just blindly use these or the many other tips you can find online. You can optimize your css all you want but if your data takes 10 seconds to load your users won’t notice those milliseconds. Performance optimization is a process. Measure, find a bottleneck, remove the bottleneck, rinse and repeat.

Some tools that might be of help: YSlow and Google Page Speed

Hi there! Since VI Company is growing quite fast, it is time for someone to take care of the internal processes and daily matters. And that’s where I come in. I’m Veronique, the new office manager.

I started working at VI Company last week. Tim and Kees are very professional, enthusiastic and motivated and the same goes for everyone here. Working in an environment like that feels really good.

So what about me? I am an office manager with great interest in human resource management and people management. Until a couple of years ago I didn’t think of becoming an office manager. I wanted to do something creative and Internet was ‘The future’, so I studied Communication & Multimedia Design.

After my graduation I started working at a marketing-communications firm. A year later I switched jobs and became a service manager at a large internet firm. After two years I discovered that I like to take care of internal processes best so that’s when I became an office manager. To make sure everybody is able to do what they are best at is the most important goal in my job. The biggest reward for me professionally is a smooth and successful running business with happy and motivated colleagues and clients.

There are more changes in my life besides starting at VI Company. I bought my first house 3 months ago and after a lot of remodeling and decorating I hope to be able to move in before the end of the year. The little time I have left besides working, cooking and cleaning I love to spend listening to music (I cannot live without Spotify), read books about psychology and human behavior, spending time with my friends and family, work-out, and do girly things like shopping.

I have no doubt I’ll have a great time working at VI Company and I look forward to doing the best I can.

Bye!

During the open space session at the Agile Open Holland I participated in an open space session about “the assessment process in agile”. During this session I explained how we apply 360-feedback at VI Company. The other participants were very enthusiastic about our method, except for one thing: their organizations are a lot bigger than ours and they need measurable competences. We asked the question “what are agile competences?”. To answer this question we held a brainstorm session about agile competences and ranked them. According to our ranking these are the most important agile competences:

1. Communicating (short, clear, honest)
2. Thinking outside the box
3. Receiving feedback
4. Being flexible
5. Giving feedback
6. Pro-active
7. Drive to improve
8. Estimation
9. Sharing information
10. Vision (the whole picture)

After we made this list, we had the idea to combine with our “old” 360 method. We call it: “360 poker”!

By taking the following steps you too can play 360 poker:

• Sit together with your team
• Spin a bottle, pen or golf club to decide who will be assessed first
• Call the first competence: Communicating. Every team member picks a coin (1 for bad, 21 for master) and puts it in the middle of the table
• The person that places the highest and the person that places lowest coin give an explanation. After the explanation people can adjust their coin and the average is picked
• Continue for the next competence until all competences are “estimated”
• Continue to the next person

The results of the 360 meeting are now measurable. This way the method can be used within companies where competences are mandatory.

I hope this will help you in your 360 meetings. If you use our method (or a different method) let us know in the comments!

The first automatic build we created was done with Cruise Control. About a year later we decided to change to TeamCity. This article explains why we chose TeamCity, and how you can create an automatic build with TeamCity yourself.

We’ll asume you’ve got TeamCity installed. Should you need help with the installation, check out the following articles.

From CruiseControl for TeamCity

As stated, we created our first build early 2010, using Cruise Control. The main reason for choosing Cruise Control was that I had worked with this tool before at my former employer. At same time busy migrating from classic ASP to ASP.NET 4.0 ánd adapting Scrum, something “known” was very welcome. A couple of problems occurred from day 1 of using Cruise Control, configuring the builds was horrible and there were a lot of strange file-access-right problems. Time to reconsider!

After comparing a couple of programs we choose TeamCity as our new build environment. It follows the KISS principle really strictly, has a really basic and easy-to-use interface. A big plus for TeamCity was that we were already using other programs from its manufacturer Jetbrains: ReSharper, dotTrace and dotCover with great satisfaction.

Improving

When we finished our first couple of build configurations in TeamCity, a single build contained ten(!!) build steps. Last summer Mendelt joined our company for a couple of months. He had a lot of experience with MS Build, which he used to reduce the build to five steps. He combined a couple of steps in the MS build file, making it a lot easier to configure a build. Within TeamCity you can directly call a MS build file. In combination with the package “MSBuildextensionpack”, you can almost do everything you can do on a Windows machine from within MS build.

Our build now contains the following steps:

• Source-code checkout. We use Mercurial as source control system, in TeamCity it is important to choose the checkout option “automatically on server” , and make sure that your checkout directory is not the same directory as the “VCS clone” directory
• Calling the MS Build configuration file, with the “build” parameter. This section of the MS Build file compiles the solution and takes care of the transformation of the web.config file
• Unit Tests, using NUnit
• Calling the MS Build configuration file, with the “DeployAcceptance” parameter . All files are copied to the correct IIS folder
• Database synchronization, we run database synchronization scripts via SQL Compare by Redgate

Should one of the steps fails, the next one won’t be executed. You can download a Windows tray application that notifies you of a build failure (for example when one of your front-end-developers breaks the build, because he/she forgot to check-in some images).

Running multiple builds

With the free version of TeamCity you are allowed to run twenty different build configurations. A maximum of three build agents can run these builds. When you’ve got more than one team developing software at the same time it’s recommended to run the maximum of three agents, otherwise teams have to wait for each other (builds are put in a queue when another build is busy). You can also configure which agent runs a particular build. For more information about running multiple agents check out the following article by Steven Smith . If you want to run more agents or builds, you can switch to the paid version of TeamCity. You can buy an extra agent for 263 euro or buy the whole Enterprise Server version for 1759 euro.

Embrace change

One of the things I learned while setting up an automatic build environment is that you should never be afraid to start over (like we did we the conversion from CC to TC) and keep improving. For example, at the moment we are busy with the automation of the production deployments and the content deployments.

Conclusion

Nowadays there’s no excuse not to have an automatic build. The investment to setup an environment repays itself really quickly! Right now me or one of my colleagues can create a new build within five minutes, giving us an acceptance environment where customer, product owner or team members can track progress at all times.

My advice would be to start with one project and see what happens over the course of 6 months of using TeamCity. I bet you’ll never want to work without an automatic build again.

Download

We’ve attached our own MSbuild file so you can easily get started. Let us know how it works out for you!

Example MSbuild

The turn-out was huge, over 500 designers showed up for a day of Type, Design, Sun, Surf, Music & Film. It started with a one-on-one interview between special guest Gerard Unger and Wim Crouwel, two of Holland’s iconic graphic/typographic designers. The interview ended with mr. Crouwel writing a message for the audience:

“Keep your radar turning to register all that is happening, but find your own direction”. 
 
 

Corel Cup 3.0

Next up was the the only official Dutch design soccer competition, The Corel Cup 3.0! Its motto is: It isn’t about winning, it’s about style! We decided to join the competition and after some exhilarating games the dust settled and it was clear: we won the Corel Cup! (lacking style, mind you!)

Typeshorts

After a little cooling down we saw Yves Peters‘ talk “Trajan In Movie Posters”. I’ve been reading Yves’ blog for some years now in which he reviews movie-poster-typography and it was fun to hear him talk about the rise and fall of Trajan as the go-to Hollywood-font. Dave Crossland gave the next (short) talk about open-source fonts. After him Typefreaks invited everybody to take part in a fun quiz about typography.

Eclectic musical-programme

On the main stage we saw performances by Blinde vlek, Electric Mustafa and John Dear Mowing Club.

Other talks

OK Parking told a sad story about giraffes and invited the crowd to a dance like a zombie to the tune of Thriller.Strange Attractors performed with Yves Peters (drums) and Peter Verheul (guitar). The told an amusing story about the legendary type-designer (and Jazz-drummer) Ed Benguiat. They all wore fake moustaches, eyebrows and wore NY Yankees caps. Good stuff!

In conclusion, design and type-wise the festival didn’t meet our expectations, but we had a great time. Hopefully the festival will return next year!

Related blog-posts:

Now We Are Talking Festival Overwhelming Success (Font Feed)

Now we are talking (Dave the designer)

Muziek en design samen op Now We Are Talking Festival (3voor12)

Now we are talking Festival (26 plus zeichen)

I noticed there wasn’t a website yet, so in about 6 hours I designed and built one. The site gathered 1023 views by 404 visitors in 4 days. I used webfonts by Typekit (Chunk & League Gothic), fitText, backStretch and html5boilerplate to make it responsive.
Responsive meaning that the website is fluid and will adjust to whatever screen-size it’s displayed on, as shown on this image:

This year Supersteil & VI Company teamed-up for Voetbalfest 2011 and… lost every game. We had fun though!

The waiter is just telling you about today’s main courses. A lover of seafood, you decide to go for the grilled scallops, that come with pancetta, chevenne onions and roasted garlic foam. Sounds good right?

But you know what sounds even better? Remember that time you grilled scallops at home, and went for bacon instead of pancetta? That was pretty good right? So you ask the waiter to replace the pancetta with bacon. And in fact, while you’re at it, you ask to leave out the onions and roasted garlic foam; you’ve got a business meeting later so you don’t want to be smelling too bad. So instead, you ask the waiter to just serve some fries with it, you love fries after all.

To your astonishment, the waiter refuses your request. So what do you do? That’s right; you tell him that you are the customer, and that he should just pass on your requests to the kitchen. After some discussion, the waiter decides not to make a scene out of it in front of the other customers in the restaurant and so he writes down your order and takes it to the kitchen.

After a little while and a few more glasses of wine, the waiter is back with your main course. After a few bites, you start to wonder what all the fuss is about with this restaurant; not only is the waiter a pigheaded idiot, the food isn’t that great at all! You figure you could’ve easily done just as well yourself. Disappointed, you leave the restaurant after finishing your meal and paying the bill – no tip for these guys of course!

And so this relates to design how?

You probably got where I was going with this story rather quickly right? It’s quite obvious that a good meal is the result of balancing ingredients, textures, flavors, composition and so on. And finding this balance isn’t a matter of being lucky; the restaurant’s chef is an experienced cook who’s spent years learning how to cook really well, and perfecting the dishes he prepares. So when asking the chef to change his dish based on your suggestions, thereby ignoring the balance of all elements that make the dish, you can’t quite expect to get a star chef worthy meal. No big surprise there.

And hopefully by now, you also understand why I’ve told you this story about the restaurant. Design in many ways is just like cooking, and like with great food, great design is the result of balancing ingredients, textures, flavors, composition and so on. Changing elements affects the whole – for better or for worse.

N.B. the story is fictional, but the dish described is real: I took it from the menu of Fouqet – my favorite restaurant here in The Hague. If you like great fresh and seasonal food, do pay them a visit!

This article was also published on bartjanverhoef.com, the personal site of Bart-Jan. More of his writings on design and related topics can be found there as well.

Sprinters?

In short, a Sprinter allows you to respond to price increases and decreases of underlying value. you can find more information and video’s about them on the ING Sprinter site we launched for ING a little while ago.

The competition

The Sprinter competition is a great way to get acquainted with ING’s Sprinters. With a (fictitious) investment capital of € 25.000,- users have access to an extremely realistic, real-time practice environment.

The competition starts on June 27^th, but those of you who can’t wait can already start practicing since last Friday.

A virtual stock market as close to the real thing as possible

So what makes this competition different from others you ask? A few highlights:

• Real-time stock data
  Stock data is received and processed by us from ING’s dealing room in under 150 milliseconds.
• Transaction confirmations by SMS
  Next to email notifications, users (can choose to) receive order confirmation by SMS. Handy if you’d like to know when a limit order is executed!
• Real-time return processing
  Fictious or not; every user gets attached to their € 25.000,- in no time, and can’t wait to see what happens to it. So it’s a good thing the return processing is real-time as well.
• Week and month rankings
  Every week, the winner of that week is a awarded an iPad2. DFT (De Financiële Telegraaf) , the coming month’s sponsor, is sending this month’s overall winner on a trip to Hong Kong! 2^nd place wins an iMac and 3^rd place wins an iPhone4.

Sponsorship

This month, DFT sponsors the Sprinter competition, which is why you will find its look & feel fitting in with the DFT brand. In order to facilitate editorial customization like this. We’ve made it easy to change the ’skin‘ accordingly.

The launch

While Ivo enjoyed a short trip to Sweden after finalizing all the programming behind the competition, the rest of us celebrated its launch last Monday with a champagne breakfast, while watching the first transactions being processed when the markets opened at 09:00am.

Give it a go!

Feel like giving the competition a go yourself, and maybe win some awesome prices?

Lets go!

It is however necessary for everyone involved to be on the same page when it comes to the concept of what a website (that’s what we make here, but I’m sure this’ll go for other media as well) will be like and why that is.

‘Liking it’ vs. ‘Getting it’

It’s not really that difficult to show concept proofs – in our case usually images saved from photoshop files, representing screens or specific interaction states – to clients and ask them if they ‘like’ them or not, hoping for signoff so that the project can move on.

There is however a big gap between ‘liking it’ and ‘getting it’. I consider it our job to make sure that clients – and everyone else playing a role in a project – ‘get it’ when it comes to what we are going to build. If for example a client isn’t sure on why certain colors are used, why interactions are designed the way they are or how all of these things relate to the goals of their project, naturally, they will judge the work according to their personal preferences; which might not benefit to the success of the project. So it’s key for a client to understand how a concept relates to the project and it’s goals in order to give a go or not.

“show, don’t tell”

Some believe that if a concept needs to be explained, it’s not a good concept. As for our line of work, we strongly disagree. Mostly because of the ‘liking’ vs. ‘getting’ thing. The problem is that, while we as web folks may immediately understand why certain colors or typefaces are used within the context of a project, this often isn’t clear to people who work outside of the creative industry. Hence, it’s up to us to explain the decisions we make and how they relate to the project.

“That wasn’t the version we wanted!”

Sounds pretty good and straightforward so far, right? And theoretically speaking, it is. But, in practice it can prove quite hard to ensure all work presented is properly explained. In our case, most of the initial concept presentations are done in person. In this setting, we have the most control over the way we present the work and communicate its context and such. This usually works pretty well, but is time–consuming (and thus expensive). So when we’ve reworked just a few pages, present a 2^nd round of iterations or just can’t physically meet with a client for some other reason, we will send them the files, accompanied by a written explanation, often via Basecamp or sometimes via email.

And this is where problems often occur: presenting this way is not only inconsistent and lacking in context – causing clients to get lost in where different files fit in the project, which version they’ve finally gave their ‘go’ to, etc – what’s worse is that the much needed explanation often isn’t properly understood since no immediate interaction is possible, or it doesn’t get read at all (don’t we all prefer just skipping the boring text and look at the pictures?).

The result of this all is a variety of (possible) problems. A few examples:

• it’s unclear what (and why) exactly is presented
• it’s unclear how what’s presented relates to previous versions
• it’s unclear how what’s presented relates to other parts of the project
• the explanation is unclear, misunderstood, not understood at all or even not read at all
• no proper or immediate way for clients to give feedback or ask questions

Again, none of this is the clients fault or responsibility: it’s up to us to ensure we communicate our work in such a manner that it’s clear for all involved what it’s for, what it will be like once it’s ‘real’ (coded, printed, or whatever else it’s for), how it will benefit to the goals of the project, and so on.

So what’s the solution then?

I wish I had a simple answer to that question. For one, I could argue that we should always present concepts in a face-to-face meeting, but the truth is, I know that’s sometimes just not possible. And apart from that, while meeting in person is probably the best way to explain and discuss concepts, that doesn’t mean that there aren’t any downsides to that too (I might get into that in another post).

Now, we have been gathering ideas about this, and are working in-house to come up with a better way of presenting and communicating our concept work to our clients. I can’t yet disclose our ideas just yet, but I promise we’ll share them with you soon.

For now, we’re very curious to hear from you how you go about communicating concepts, your experience with any of the problems we’ve mentioned, oher problems you ran into, or maybe even the solution you have for preventing any of the problems to occur.

The reason for Aaron Gustafson to write this article was based on a solution offered by Eric Meyer, who published a way to use CSS to include the web address behind the text-link when a page was printed. This solution creates a new problem though, because this method really decreases the readability of a text that contains a lot and/or long links.

The solution Aaron came up with to counter this problem was using JavaScript to create an ordered list containing all hyperlinks of an article at the bottom of the page. He then proceeds to connect the links of the ordered list to the links in the article by using a sup-tag to add numbers to the links, so they can be treated as footnotes.

After reading Gustafsonʼs article I decided to implement this method for the 2010 annual report of STOP AIDS NOW!. The article dates back to 2005 and Aaron used JavaScript combined with the jsUtilities package to achieve the desired result. I decided to simplify the code for myself and I rewrote the function using jQuery, which makes the code a lot more compact.

The function uses two variables; container and target. The container variable is used to declare the elements that contains the links you want to be shown as a footnote in the page. The target variable defines to which element the list containing the web addresses should be added. All HTML-tags appended to the page by the script has the class printOnly so we can hide these element via CSS

Below: The jQuery function to create a list of hyperlinks on a printed page.

function footnoteLinks(container, target) {

	// only append list if there are any links
	if($(container + " a").length != 0){
		// append header and list to the target
		$(target).append("<h2 class='printOnly'>Links</h2>");
		$(target).append("<ol id='printlinks' class='printOnly'></ol>");
	}	

	var myArr = []; // to store all the links
	var thisLink;   // to store each link individually
	var num = 1; // to keep count

	// loop trough all the links inside container
	$(container + " a").each(function(){
		thisLink = $(this).attr("href");
		// if current link is not already in the list, add current link to the list
		if($.inArray(thisLink, myArr) == -1){
			$(this).after("<sup class='printOnly'>" + num + "</sup>");
			$("ol#printlinks").append("<li>" + thisLink + "</li>");
			myArr.push(thisLink);
			num++;
		}else{
			$(this).after("<sup class='printOnly'>" + parseInt($.inArray(thisLink, myArr) + 1) + "</sup>");
		}
	});
}

To call the function

footnoteLinks("section#content", "body");
// For example get all links from content section and append to body

Don’t forget the little piece of CSS to hide the print elements on the screen.

.printOnly{
    display:none;
}

You can see the result of this script by printing this particular page and feel free to use the script on your own site. If you do, it would be nice to leave a comment below.

DevDays is on of the bigger Microsoft conventions about software development and architecture, offering a broad range of topics on various platforms such as Azure, desktop/client, SQL Server, Visual Studio, .Net and Windows phone 7.

For us, these 2 days were a great opportunity to gather new ideas, think out the box, check the level of our skillset, and last but not least: enjoy great lunches, accompanied by cute DevDays lunch-girls .

Day 1 began with the Microsoft DevDays Keynote, giving an overview of what developers have accomplished in the field of webdevelopment and cloud technology over the past few years.

The best part for me was Scott Hanselman showing how development tools and coding like ASP classic have evolved to the tools and technology we use today.

The keynote got us really excited about 2 days of learning. In which we had plenty of choice: 5 slots each day, with around 10 different sessions in each slot!

We visited a few sessions that were interesting to the both of us, like MVC 3 101 by Scott Hanselman. ASPN.NET MVC is a powerful, pattern-based tool for building dynamic websites in an agile manner. It contains a lot of functionalities that speed up development time in various way.

Ivo mostly focussed on the sessions about .Net development and optimization and effective usage of code and architecture. What stood out for him was the session Declarative Refactoring in C#, in which Chris Eargle spoke about using C# in it’s full potential, using functionality where it belongs and improving (future) code-readability.

I was personally mostly into the SQL sessions: while most developer conventions are about .Net development, DevDays offered a few seminars focussed solely on databases, database technique, database development and so on. Apart from these sessions, the MVC 3 and Razor sessions sparked my interest.

Of the SQL sessions I visited I enjoyed Full text Search in SQL Server 2008 and Denali and SQL Server Performance: Query Plans the best. The full text search session pretty much confirmed that the way we develop and use various techniques are ‘right’, so to speak. Which is obviously a great feeling to have during such a session . Of course there’s still enough left to learn, and new tools to discover, such as the new SQL Denali.

Something else being discussed was IFilters, a technique that makes it possible to search for file attributes within varbinary-saved objects, using full text search. This for example makes it possible to extract the GPS location from a binary-saved photo (shot with a Windows 7 phone or iPhone) in a database.

Another recommendation is the SQL Server Performance session. This session focused on optimizing and improving queries and the underlying functionalities like JOINS, nested and merged loops, Index Lookups, etcetera. Something we’ve been working on ourselves in recent projects. The session also covered in detail how a query is executed in SQL Server.

We attended our last session together: How Smart Use Cases Can Drive Web Development, by Sander Hoogendoorn, a great speaker who’s sessions we’ve attended before on SDN events. It was an inspiring final session and we will definitely start using smart use cases ourselves soon!

During the DevDays there were a lot of outsourcers looking for developers, offering all kinds of freebies such as ice-cream, t-shirts, the possibility to win a vacation, and so on. We really enjoyed these, although, since we were were wearing badges with our personal details on it, like everyone at the conference, we do hope our spam filter will be able to block all of the offers we are about to receive!

Happy coding!

This weekend I came across an amazing time-lapse video shot by Terje Sorgjerd, a landscape photographer from Norway.

I used to ask questions and receive useful answers on Stackoverflow (and votes at the same time), but the last couple of months I don’t get a lot of answers to my questions. Questions get no views, answers and votes. When I answer someone else’s question, it tends to get only one vote. This makes it impossible to get new badges. In my opinion Stackoverflow is only useful at this moment when you have a problem that is already answered on the website.

I get the impression that people aren’t voting, viewing and answering questions anymore because the amount of questions seems to be “overflowing”. I guess the website is outgrowing itself. It has to change some things to not become a victim of it’s own success.

People use the site because they get answers. People answer questions because they want to help people and get reputation and badges. If there are too many questions, people won’t vote for questions and answers because they get “pushed away” from the site really fast. If answers don’t get up-votes, people stop posting answers, because they don’t get reputation and badges. If question aren’t answered people stop asking questions and go elsewhere with their problems.

Am I the only one experiencing this problem? Or am I using the site in a wrong way? What could be done to get rid of the “overflowing” problem?

Sticky navigations, facet menu’s, sliding panes, responsive layouts: just a few examples of interactive elements that are part of modern websites and thus part of our toolbox. For a designer, it can be hard preparing these – sometimes complex – interactions in detail through static designs, let alone presenting them to our collegues and clients and expecting them to ‘get’ the interactions.

Over the years we’ve worked on a variety of projects that have grown, and still grow, in size and complexity. One thing I’ve learned along the way is that – while growing complexity in interactions do ask more time, preperation and attention to detail – there is no such thing as designing 100% of an interactive website.

Chartwell is a family that explores the use of OpenType to interpret and visualize data. The font format is highly portable and can be used in most applications that support ligatures. The data also remains editable allowing for easy updates.

Create pie-charts, bar-graphs and line-graphs through the magic of ligatures! Too bad it only works in Firefox 4 because of the ligatures, but interesting none the less.

B.T.W. This is posted on april 1^st, but it’s no joke

Mixes created and designed, by designers. Designers.MX is about discovering new music. Music that drives our favorite designers, and allowing them to create a unique cover design for each of their individual playlists. A daily music and design masterpiece.

“If you’re anything like us, you love music as much as design. We’re asking some of the industry’s top designers to let us in on one of their secrets…what music fuels their creativity.”

We arrived at 9:50 and tried to access the conference center, but there was a big bald security guy who said that parking at the conference terrain was not allowed and he gave us a route description for a parking place and shuttle bus that would drive us to the conference terrain.

We shred the route map in a thousand pieces, drove to the nearby Praxis and walked back to the conference terrain, because otherwise we would be late. The security guy could not appreciate this at all! “Didn’t I gave you a route map 5 minutes ago!” he asked. “Yes you did” we answered. “Didn’t you read it?”, “No we didn’t” we answered. At that very moment his head turned red like a tomato, he ran to his car and was about the send five really big dogs after us! We ran faster than we ever did and made it to the door, just before the dogs would do the same thing to us as what we did to the route map. A really warm welcome!

So after the easy trip to the conference we attended two sessions named “One man, a whiteboard and three markers”. It were two awesome hours, where we talked about architecture, design patterns, dependency injection and lots more. A lot of the solutions discussed during this session are already part of our development framework, but I also learned a lot of awesome tricks to improve our work. The speaker, Sander Hoogendoorn, is always really inspiring. I would recommend any developer, project manager or database developer to go to one of his speaking gigs.

Our third session after the really good lunch was about Use Cases. This session was also really good and we learned new stuff again. After this third session we took the backdoor to avoid the guard with his dogs and went back to Rotterdam to launch the new VI Company website. Overall an awesome day with lots of new insights!

What’s new?

Quite a lot, actually! Our previous site was a one-page site, where we didn’t show our work. On our new site we showcase four projects and will expand these this year with Travelchooser, the annual report for Aidsfonds and a nice project for ING.

We now also have a blog where we can talk about what we do, what inspires us and whatever else we want to share. The blog is a customisation of WordPress, a semantic personal publishing platform with a focus on aesthetics, web standards, and usability. We chose to use existing software – in stead of building it ourselves – because of development speed (we are still looking for an extra back-end developer!) and the ease of adjusting WordPress to our wishes.

We also added an about-page, where we try to give a clear view of who we are and what we stand for. Here you’ll also find our manifest and the profile-pages of the team.

Technical skill

We built the site using HTML5, CSS3 and jQuery. This way we were able to implement our corporate identity in detail and create an experience layer that contributes to a nice user experience. We used the HTML5 Boilerplate as starting-point and added our own scripting. We also optimized the site so it is still usable on smaller screens, i.e. the navigation of the slider on the homepage will move inside the slider when you narrow your browser-screen. We also made a (very) simple mobile landing page, which will also be updated this year.

Design

Our logo is bold and recognizable. This is now also reflected in the design of our site. The slash-symbol from the logo is used as a divider for the navigation and also to highlight certain part of the User Interface, for example: the share-button near the end of this article.

Typography plays an important part in all our design and our own site is no different. We used Typekit to serve our fonts. Typekit is a service which allows us to use certain fonts on our site, which enables us use our typefaces on the web. The body-text is set in FF Tisa, designed by Mitja Miklavčič. In our print-work we use Gotham Bold, designed by Hoefler & Frere-Jones, for headings. Gotham is not (yet) available as webfont, so we decided to use Proxima Nova, designed by Mark Simonson.

What now?

We’re not finished yet! As you can read on our about-page (in Dutch), we think websites are a process. That means that we plan to update our site many times this year and of course we will blog about it here. Do you want to stay up-to-date on all things VI Company? Then you should follow us on Facebook and Twitter!

Let me start of by saying that there is absolutely nothing wrong with using jQuery plugins to achieve the level of interaction you are looking for in a website. I do however, ask you to stop and think for a second why it might be beneficial to you (and your business) to learn and write your own code.

Like I mentioned earlier, I was solely relying on plugins to achieve JavaScript interaction a year and a half ago. This was working out fine for me, until I started running into problems because the level of interaction I needed for some projects could not be (completely) covered by plugins I could find on the web.

Hence the need to learn to write my own code arose. And boy, am I glad it did. In little than a year I went from: “I am not sure there is a plugin to do that” to: “Sure that’s possible, I’ll write my own code to make it work”.

Small victories

Like most things in life, it was a bit tricky for someone with little programming/scripting experience to get used to writing my own code, but I took joy in the small victories. I remember the excitement of simply fading in and out parts of a page or building a very basic jQuery tab menu.

These small victories fueled my desire to learn more and write my own code. With the help of excellent resources like the jQuery docs and websites like Stack Overflow I was quickly building more and more  websites with complex interactivity, without having to hope there was a plugin on the web that sort of did what I wanted it to do.

Achieve what you want

With a little practice and determination you will soon be able to achieve exactly what you had in mind when starting a project by writing your own code.

Exit small victories, enter big victories. The more used you get to writing your own code, the bigger your victories will become. The level interaction you will be able to achieve will only continue to grow and soon enough you will be creating tons of complex websites, that you probably would not have thought you would a while ago.

Don’t reinvent the wheel

Yeah yeah, you’ve heard it a million times before, and you know why? Because its true!

There are tons of great jQuery plugins floating around the web which can help you achieve amazing effects. So if there is a plugin that does exactly what you want it to do, save yourself some time and use it!

Meanwhile it might be a good idea to try and figure out how and why a plugin works the way it does, and learn something from it. This way you might be able to use the things you learn in your own code.

Get your hands dirty!

That’s right, if you feel inclined to start writing your own code, do it! The jQuery team did an amazing job and learning to write your own code is easier than you might think. Also, the web is a wonderful place full of people and resources that are more than capable of getting you started.

Look around, ask around and you will soon be creating your own small victories.

There are a lot of tools “out there” to help you fix problems quicker. In this series I will discuss a couple of free tools which can help you out big time with figuring out problems.

In this article I will talk about a tool called Fiddler.

Fiddler is a web debugging tool that sniffs al your web traffic. In the screenshot at the right, you can see the basic interface of the program. You can see that it not only sniffs my webbrowser, but all the programs that connect to the internet (like CCNet and Spotify). Fiddler also tells you what’s happening in the webpages you have loaded (like iGoogle).

I mainly use this tool for gathering the following information:

• Does my website return the right response (200,30x,401, 500(never!) etc.)
• Is the header of my XML response valid
• Is my web service returning the right response
• Is my Windows app calling the twitter api correctly?

This tool can help you find “stupid” mistakes like invalid XML headers or 401 responses quick (and make you rock!). So download Fiddler and start using it.