osp blog

A conversation with Chris Lilley

Almost a year ago at the Libre Graphics Meeting 2008, OSP sat down with Chris Lilley on a small patch of grass in front of the Technical University in Wroclaw, Poland. Warmed up by the early May sun, we talked about the way standards are made, how 'specs' influence the work of designers, programmers and managers and how this process is opening up to voices from outside the W3C.

Chris Lilley (top row, right) on the 2008 W3C team photo.

Chris Lilley is trained as a biochemist, and specialised in the application of biological computing. He has been involved with the World Wide Web Consortium since the 1990's, headed the Scalable Vector Graphics (SVG) working group and currently looks after two W3C activity areas: graphics, including PNG, CGM, graphical quality, and fonts, including font formats, delivery, and availability of font software.

Download: chris_lilley_osp.odt

Femke Snelting (FS): I would like to ask you about the way standards are made... I think there's a relation between the way Free, Libre and Open Source Software works, and how standards work. But I am particularly interested in your announcement in your talk today that you want to make the process of defining the SVG standard a public process?

Chris Lilley (CL): Right. So, there's a famous quote that says that standards are like sausages. Your enjoyment of them is improved by not knowing how they're made ((“Laws are like sausages. It's better not to see them being made.” Otto von Bismarck, 1815 - 1898)). And to some extent, depending on the standards body and depending on what you're trying to standardize, the process can be very messy. If you were to describe W3C as a business proposition, it has got to fail. You're taking companies who all have commercial interests, who are competing and you're putting them in the same room and getting them to talk together and agree on something. Oddly, sometimes that works! You can sell them the idea that growing the market is more important and is going to get them more money.

The other way... is that you just make sure that you get the managers to sign, so that their engineers can come and discuss standards, and then you get the engineers to talk and the managers are out of the way. Engineers are much more forthcoming, because they are more interested in sharing stuff because engineers like to share what they're doing, and talk on a technical level. The worst thing is to get the managers involved, and even worse is to get lawyers involved. W3C does actually have all those three in the process. “Shall we do this work or not” is a managerial level that's handled by the W3C advisory committee, and that's where some people say “No, don't work on that area” or “We have patents” or “This is a bad idea” or whatever. But often it goes through and then the engineers basically talk about it.

Occasionally there will be patents disclosed, so the W3C also has a process for that. The first things are done are the 'charters'. The charter says what the group is going to work on a broad scope. As soon as you've got your first draft, that further defines the scope, but it also triggers what it's called an exclusion opportunity, which basically gives the companies I think ninety days to either declare that they have a specific patent and say what it's number is and say that they exclude it, or not. And if they don't, they've just given a royalty-free license to whatever is needed to implement that spec. The interesting thing is that if they give the royalty-free license they don't have to say which patents they're licensing. Other standards organizations build up a patent portfolio, and they list all these patents and they say what you have to license. W3C doesn't do that, unless they've excluded it which means you have to work around it or something like that. Based on what the spec says, all the patents that have been given, are given. The engineers don't have to care. That's the nice thing. The engineers can just work away, and unless someone waves a red flag, you just get on with it, and at the end of the day, it's a royalty-free specification.

FS: But if you look at the SVG standard, you could say that it's been quite a bumpy road ((http://ospublish.constantvzw.org/news/whos-afraid-of-adobe-not-me-says-the-mozilla-foundation)) ... What kind of work do you need to do to make a successful standard?

CL: Firstly, you need to agree on what you're building, which isn't always firm and sometimes it can change. For example, when SVG was started the idea was that it would be just static graphics. And also that it would be animated using scripts, because with dynamic HTML and whatever, this was '98, we were like: “OK, we're going to use scripting to do this.” But when we put it out for a first round of feedback, people were like “No! No, this is not good enough. We want to have something declarative. We don't want to have to write a script every time we want something to move or change color.” Some of the feedback, from Macromedia for example was like “No, we don't think it should have this facility,” but it quickly became clear why they were saying that and what technology they would rather use instead for anything that moved or did anything useful... We basically said “That's not a technical comment, that's a marketing comment, and thank you very much.”

FS: Wait a second. How do you make a clear distinction between marketing and technical comments?

CL: People can make proposals that say “We shouldn't work on this, we shouldn't work on that”, but they're evaluated at a technical level. If it's “Don't do it like that because it's going to break as follows, here I demonstrate it” then that's fine. If they're like “Don't do it because that competes with my proprietary product” then it's like “Thanks for the information, but we don't actually care.” It's not our problem to care about that. It's your problem to care about that.

Part of it is sharing with the working group and getting the group to work together, which requires constant effort, but it's no different from any sort of managerial or trust company type thing. There's this sort of encouragement in it that at the end of the day you're making the world a better place. You're building a new thing and people will use it and whatever. And that is quite motivating. You need the motivation because it takes a lot longer than you think. You build the first spec and it looks pretty good and you publish it and you smooth it out a bit, put it out for comments and you get a ton of comments back. People say “If you combine this with this with this then that's not going to work.” And you go “Is anyone really going to do that?” But you still have to say what happens. The computer still has to know what happens even if they do that.
Ninety percent of the work is after the first draft, and it's really polishing it down. In the W3C process, once you get to a certain level, you take it to what is euphemistically called the 'last call'. This is a term we got from the IETF ((The Internet Engineering Task Force, http://www.ietf.org/)). It actually means 'first call' because you never have just one. It's basically a formal round of comments. You log every single comment that's been made, you respond to them all, people can make an official objection if you haven't responded to the comment correctly etcetera. Then you publish a list of what changes you've made as a basis of that.

FS: What part of the SVG standardization process would you like to make public?

CL: The part that I just said has always been public. W3C publishes specifications on a regular basis, and these are always public and are freely available. The comments are made in public and responded to in public. What hasn't been public has been the internal discussions of the group. Sometimes it can take a long time if you've got a lot of comments to process or if there's a lot of argumentation in the group: people not agreeing on the direction to go, it can take a while. From the outside it looks like nothing is happening. Some people like to follow this at a very detailed level, and blog about it, and blablabla. Overtime, more and more working groups have become public. The SVG group just recently got re-charted and it's now a public group. All of its minutes are public. We meet for ninety minutes twice a week on a telephone call. There's an IRC log of that and the minutes are published from that, and that's all public now ((Scalable Vector Graphics (SVG) Feedback Page: http://www.w3.org/Graphics/SVG/feedback.html))

FS: Could you describe such a ninety minute meeting for us?

CL: There are two chairs. I used to be the chair for eight years or so, and then I stepped down. We've got two new chairs. One of them is Erik Dahlström from Opera, and one of them is Andrew Emmons from Bitflash. Both are SVG implementing companies. Opera on the desktop and mobile, and Bitflash is just on mobile. They will set out an agenda ahead of time and say “We will talk about the following issues.” We have an issue tracker, we have an action tracker which is also now public. They will be going through the actions of people saying “I'm done” and discussing whether they're actually done or not. Particular issues will be listed on the agenda to talk about and to have to agree on, and then if we agree on it and you have to change the spec as a result, someone will get an action to change that back to the spec. The spec is held into CVS so anyone in the working group can edit it and there is a commit log of changes. When anyone accidentally broke something or trampled onto someone else's edit, or whatever -which does happen- or if it came as the result of a public comment, then there will be a response back saying we have changed the spec in the following way... “Is this acceptable? Does this answer your comment?”

FS: How many people do take part in such a meeting?

CL: In the working group itself there are about 20 members and about 8 or so who regularly turn up, every week for years. You know, you lose some people over time. They get all enthusiastic and after 2 years, when you are not done, they go off and do something else, which is human nature. But there have been people who have been going forever. That's what you need actually in a spec, you need a lot of stamina to see it through. It is a long term process. Even when you are done, you are not done because you've got errata, you've got revisions, you've got requests for new functionalities to make it into the next version and so on.

FS: On the one hand you could say every setting of a standard is a violent process, some organisation forcing a standard upon others, but the process you describe is entirely based on consensus.

CL: There's another good quote. Tim Berners Lee was asked why W3C works by consensus, rather than by voting and he said: “W3C is a consensus-based organisation because I say so, damn it” ((“Consensus is a core value of W3C. To promote consensus, the W3C process requires Chairs to ensure that groups consider all legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public).” General Policies for W3C Groups: http://www.w3.org/2005/10/Process-20051014/policies#Consensus)) That's the Inventor of the Web, you know... (laughs) If you have something in a spec because 51% of the people thought it was a good idea, you don't end up with a design, you end up with a bureaucratic type decision thing. So yes, the idea is to work by consensus. But consensus is defined as: 'no articulated dissent' so someone can say “abstain” or whatever and that's fine. But we don't really do it on a voting basis, because if you do it like that, then you get people trying to make voting blocks and convince other people to vote their way... it is much better when it is done on the basis of a technical discussion, I mean... you either convince people or you don't.

FS: If you read about why this kind of work is done... you find different arguments. From enhancing global markets to: 'in this way, we will create a better world for everyone'. In Tim Berners-Lee's statements, these two are often mixed. If you for example look at the DIN standards, they are unambiguously put into the world as to help and support business. With Web Standards and SVG, what is your position?

CL: Yes. So, basically... the story we tell depends on who we are telling it to and who is listening and why we want to convince them. Which I hope is not as duplicitous as it may sound. Basically, if you try to convince a manager that you want 20% time of an engineer for the coming two years, you are telling them things to convince them. Which is not untrue necessarily, but that is the focus they want. If you are talking to designers, you are telling them how that is going to help them when this thing becomes a spec, and the fact that they can use this on multiple platforms, and whatever.

Remember: when the web came out, to exchange any document other than plain text was extremely difficult. It meant exchanging word processor formats, and you had to know on what platform you were on and in what version. The idea that you might get interoperability, and that the Mac and the PC could exchange characters that were outside ASCII was just pie in the sky stuff. When we started, the whole interoperability and cross-platform thing was pretty novel and an untested idea essentially. Now it has become pretty much solid.

We have got a lot of focus on disabled accessibility, and also internationalization which is if you like another type of accessibility. It would be very easy for an organisation like W3C, which is essentially funded by companies joining it, and therefore they come from technological countries... it would be very easy to focus on only those countries and then produce specifications that are completely unusable in other areas of the world. Which still does sometimes happen. This is one of the useful things of the W3C. There is the internationalization review, and an accessibility review and nowadays also a mobile accessible review to make sure it does not just work on desktops.

Some organisations make standards basically so they can make money. Some of the ISO ((“International Standards for Business, Government and Society” International Organization for Standardization (ISO), http://www.iso.org)) standards, in particular the MPEG group, their business model is that you contribute an engineer for a couple of years, you make a patent portfolio and you make a killing off licensing it. That is pretty much to keep out the people who were not involved in the standards process. Now, W3C takes quite an opposite view. The Royalty free license ((“Overview and Summary of W3C Patent Policy” http://www.w3.org/2004/02/05-patentsummary.html)) for example, explicitly says: royalty free to all. Not just the companies who were involved in making it, not just companies, but anyone. Individuals. Open Source Projects. So, the funding model of the W3C is that members pay money, and that pays our salaries, basically. We have a staff of 60 odd or so, and that's where our salaries come from, which actually makes us quite different from a lot of other organisations. IETF is completely volunteer based so you don't know how long something is going to take. It might be quick, it might be 20 years, you don't know. ISO is a national body largely, but the national bodies are in practice companies who represent that nation. But in W3C, it's companies who are paying to be members. And therefore, when it started there was this idea of secrecy. Basically, giving them something for their money. That's the trick, to make them believe they are getting something for their money. A lot of the ideas for W3C came from the X Consortium ((“The purpose of the X Consortium was to foster the development, evolution, and maintenance of the X Window System, a comprehensive set of vendor-neutral, system-architecture neutral, network-transparent windowing and user interface standards.” http://www.x.org/wiki/XConsortium)) actually, it is the same people who did it originally. And there, what the meat was... was the code. They would develop the code and give it to the members of the X Consortium three months before the public got it and that was their business benefit.
So that is actually where our 'three month rule' comes from. Each working group can work for three months but then they have to go public, have to publish. 'The heartbeat rule', we call it now. If you miss several heartbeats then you're dead. But at the same time if you're making a spec and you're growing the market then there's a need for it to be implemented. There's an implementation page where you encourage people to implement, you report back on the implementations, you make a test suite, you show that every feature in the spec that there's a test for... at least two implementations pass it. You're not showing that everyone can use it at that stage. You're showing that someone can read the spec and implement it. If you've been talking to a group of people for four years, you have a shared understanding with them and it could be that the spec isn't understandable without that. The implementation phase lets you find out that people can actually implement it just by reading the spec. And often there are changes and clarifications made at that point.

Obviously one of the good ways to get something implemented is to have Open Source people do it and often they're much more motivated to do it. For them it's cool when it is new, “If you give me this new feature it's great we'll do it” rather than: “Well that doesn't quite fit into our product plans until the next quarter” and all that sort of stuff. Up until now, there hasn't really been a good way for the open source people to get involved. They can comment on specs but they're not involved in the discussions. That's something we're trying to change by opening up the groups, to make it easier for an open source group to contribute on an ongoing basis if they want to. Right from the beginning part, to the end where you're polishing the tiny details in the corner.

FS: I think the story of web fonts shows how an involvement of the Open Source people could have made a difference.

CL: When web fonts were first designed, essentially you had Adobe and Apple pushing one way, Bitstream pushing the other way, both wanting W3C to make their format the one and only official web format, which is why you ended up with a mechanism to point to fonts without saying what format was required. And than you had the Netscape 4, which pointed off to a Bitstream format, and you had IE4 which pointed off to this Embedded Open Type (EOT) format. If you were a web designer, you had to have two different tools, one of which only worked on a Mac, and one of which only worked on PC, and make two different fonts for the same thing. Basically people wouldn't bother.

As Hakon ((Håkon Wium Lie proposed Cascading Style Sheets (CSS) in 1994. http://www.w3.org/People/howcome/)) mentioned the only people who do actually use that right now really, are countries where the local language is not well provided for by the Operating Systems. Even now, things like WindowsXP and MacOSX don't fully support some of the Indian languages. But they can get it into web pages by using these embedded fonts. Actually the other case where it has been used a lot, is SVG, not so much on the desktop though it does get used there but on mobiles. On the desktop you've typically got 10 or 20 fonts and you got a reasonable coverage. On a mobile phone, depending on how high or low ended it is, you might have a single font, and no bold, and it might even be a pixel-based font. And if you want to start doing text that skews and swirls, you just can't do that with a pixel-based based font. So you need to download the font with the content, or even put the font right there in the content just so that they can see something.

FS: I don't know how to talk about this, but... envisioning a standard before having any concrete sense of how it could be used and how it could change the way people work... means you also need to imagine how a standard might change, once people start implementing it?

CL: I wouldn't say that we have no idea of how it's going to work. It's more a case that there are obvious choices you can make, and then not so obvious choices. When work is started, there's always an idea of how it would fit in with a lot of things and what it could be used for. It's more the case that you later find that there are other things that you didn't think of that you can also use it for. Usually it is defined for a particular purpose and than find that it can also do these other things.

Pierre Huyghebaert (PH): Isn't it so that sometimes, in that way, something that is completely marginal, becomes the most important?

CL: It can happen, yes.

Nicolas Malevé (NM): For me, SVG is a good example of that. As I understood it, it was planned to be a format for the web. And as I see it today, it's more used on the desktop. I see that on the Linux desktop, for theming, most internals are using SVG. We are using Inkscape for SVG to make prints. On the other hand, browsers are really behind.

CL: Browsers are getting there. Safari has got reasonably good support. Opera has got very good support. It really has increased a lot in the last couple of years. Mozilla Firefox less so. It's getting there. They've been at it for longer, but it also seems to be going slower. The browsers are getting there. The implementations which I showed a couple of days ago, those were mobile implementations. I was showing them on a PC, but they were specially built demos. Because they're mobile, it tends to move faster.

NM: But you still have this problem that Internet Explorer is a slow adopter.

CL: Yes, Internet Explorer has not adopted a lot of things. It's been very slow to do CSS. It hasn't yet done XHTML, although it has shipped with an XML parser since IE4. It hasn't done SVG. Now they've got their own thing... Silverlight. It has been very hard to get Microsoft on board and getting them doing things. Microsoft were involved in the early part of SVG but getting things into IE has always been difficult. What amazes me to some extent, is the fact that it's still used by about 60-70% of people. You look at what IE can do, and you look at what all the other browsers can do, and you wonder why. The thing is... it is still a break and some technologies don't get used because people want to make sure that everyone can see them. So they go down to the lowest common denominator. Or they double-implement. Implement something for all the other browsers, and implement something separate for IE, and than have to maintain two different things in parallel, and tracking revisions and whatever. It's a nightmare. It's a huge economic cost because one browser doesn't implement the right web stuff.

[laughing, sighing]

NM: My question would be: what could you give us as a kind of advice? How could we push this adoption where we are working? Even if it only is the people of Firefox to adopt SVG?

CL: Bear in mind that Firefox has this thing of Trunk builds and Branch builds and so on. For example when Firefox 3 came out, well the Beta is there. Suddenly there's a big jump in the SVG stuff because all the Firefox 2 was on the same branch as 1.5, and the SVG was basically frozen at that point. The development was ongoing but you only saw it when 3 came out. There were a bunch of improvements there. The main missing features are the animation and the web fonts and both of those are being worked on. It's interesting because both of those were on Acid 3. Often I see an acceleration of interest in getting something done because there's a good test.

The Acid Test ((The Acid 3 test: http://acid3.acidtests.org is comprehensive in comparison to more detailed, but fragmented SVG tests: http://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_Overview#W3C_Scalable_Vector_Graphics_.28SVG.29_Test_Suite_Overview)) is interesting because it's a single test for a huge slew of things all at once. One person can look at it, and it's either right or it's wrong, whereas the tests that W3C normally produces are very much like unit tests. You test one thing and there's like five hundred of them. And you have to go through, one after another. There's a certain type of person who can sit through five hundred test on four browsers without getting bored but most people don't. There's a need for this sort of aggregative test. The whole thing is all one. If anything is wrong, it breaks. That's what Acid is designed to do. If you get one thing wrong, everything is all over the place. Acid 3 was a submission-based process and like a competition, the SVG working group was there, and put in several proposals for what should be in Acid 3, many of which were actually adopted. So there's SVG stuff in Acid 3.

FS: So... who started the Acid Test?

CL: Todd Fahrner designed the original Acid 1 test, which was meant to exercise the tricky bits of the box-model in CSS. It ended like a sort Mondrian diagram ((“Acid Test Gallery” http://moonbase.rydia.net/mental/writings/box-acid-test/)), red squares, and blue lines and stuff. But there was a big scope for the whole thing to fall apart into a train wreck if you got anything wrong. The thing is, a lot of web documents are pretty simple. They got paragraphs, and headings and stuff. They weren't exercising very much the model. Once you got tables in there, they were doing it a little bit more. But it was really when you had stuff floated to one side, and things going around or whatever, and that had something floated as well. It was in that sort of case where it was all breaking, where people wouldn't get interoperability.

FS: It was... The Web Standards Project ((“The Web Standards Project is a grassroots coalition fighting for standards which ensure simple, affordable access to web technologies for all” http://www.webstandards.org/)) who proposed this?

CL: Yes, that's right.

FS: It didn't come from a standards body.

CL: No, it didn't come from W3C. The same for Acid 2, Håkon Wium Lie was involved in that one. He didn't blow his own trumpet this morning, but he was very much involved there. Acid 3 was Ian Hickson, who put that together. It's a bit different because a lot of it is DOM scripting stuff. It does something, and then it inquires in the DOM to see if it has been done correctly, and it puts that value back as a visual representation so you can see. It's all very good because apparently it motivates the implementors to do something. It's also marketable. You can have a blog posting saying we do 80% of Acid Test. The public can understand that. The people who are interested can go “Oh, that's good”.

FS: It becomes a mark of quality.

CL: Yes, it's marketing. It's like processor speed in PCs and things. There are so much technology in computers, so than what do you market it on? Well it's got that clock speed and it's got this much memory. OK, great, cool. This one is better than that one because this one's got 4 gigs and that one's got 2 gigs. It's a lot of other things as well, but that's something that the public can in general look at and say “That one is better”.

When I mentioned the W3C process, I was talking about the engineers, managers. I didn't talk about the lawyers, but we do have a process for that as well. We have a patent advisory group conformed. If someone has made a claim, and it's disputed then we can have lawyers talking among themselves. What we really don't have in that is designers, end-users, artists. The trick is to find out how to represent them.

The CSS working group tried to do that. They brought in a number of designers, Jeff Veen ((Jeff Veen was a designer at Wired magazine, in those days. http://adaptivepath.com/aboutus/veen.php)) and these sort of people were involved early on. The trouble is that you're speaking a different language, you're not speaking their language. When you're having weekly calls... Reading a spec is not bedtime reading, and if you're arguing over the fine details of a sentence... (laughing) well, it will put you to sleep straight away. Some of the designers are like: “I don't care about this. I only want to use it. Here's what I want to be able to do. Make it that I can do that, but get back to me when it's done.”

NM: That's why the idea of the Acid Test is a nice breed between the spec and the designer. When I was seeing the test this morning, I was thinking that it could be a really interesting work to do, not to really implement it but to think about with the students. How would you conceive a visual test? I think that this could be a really nice workshop to do in a university or in a design academy...

FS: It's the kind of reverse-reverse engineering of a standard which could help you understand it on different levels. You have to imagine how wild you can go with something. I talk about standards, and read them -not before going to bed- because I think that it's interesting to see that while they're quite pragmatic in how they're put together, but they have an effect on the practice of, for example, designers. Something that I have been following with interest is the concept of separating form and content has become extremely influential in design, especially in web design. Trained as a pre-web designer, I'm sometimes a bit shocked by the ease with which this separation is made.

CL: That's interesting. Usually people say that it's hard or impossible, that you can't ever do it. The fact that you're saying that it's easy or that it comes naturally is interesting to me.

FS: It has been appropriated by designers as something they want. That's why it's interesting to look at the Web Standards Project where designers really fight for a separation of content and form. I think that this is somehow making the work of designers quite... boring. Could you talk a bit about how this is done?

CL: It's a continuum. You can't say that something is exactly form or exactly presentation because there are gradations. If you take a table, you've already decided that you want to display the material in a tabular way. If it's a real table, you should be able to transpose it. If you take the rows and columns, and the numbers in the middle then it should still work. If you've got 'sales' here and if you've got 'regions' there, then you should still be able to transpose that table. If you're just flipping it 90 degrees then you are using it as a layout grid, and not as a table. That's one obvious thing. Even then, deciding to display it as a tabular thing means that it probably came from a much bigger dataset, and you've just chosen to sum all of the sales data over one year. Another one: you have again the sales data, you could have it as pie chart, but you could also have it as a bar chart, you could have it in various other ways. You can imagine that what you would do is ship some XML that has that data, and then you would have a script or something which would turn it into an SVG pie chart. And you could have a bar chart, or you could also say show me only February. That interaction is one of the things that one can do, and arguably you're giving it a different presentational form.

It's still very much a gradation. It's how much re-styleability remains. You can't ever have complete separation. If I'm describing a company, and [1] I want to do a marketing brochure, and [2] I want to do an annual report for the shareholders, and [3] I want to do an internal document for the engineering team. I can't have the same content all over those three and just put styling on it. The type of thing I'm doing is going to vary for those audiences, as will the presentation. There's a limit. You can't say: here's the überdocument, and it can be styled to be anything. It can't be. The trick is to not mingle the style of the presentation when you don't need to. When you do need to, you're already halfway down the gradient. Keep them as far apart as you can, delay it as late as possible. At some point they have to be combined. A design will have to go into the crafting of the wording, how much wording, what voice is used, how it's going to fit with the graphics and so on. You can't just slap random things together and call it design, it looks like a train wreck. It's a case of deferment. It's not ever a case of complete separation. It's a case of deferring it and not tripping yourself up.

Just simple things like bolds and italics and whatever. Putting those in as emphasis and whatever because you might choose to have your emphasized words done differently. You might have a different font, you might have a different way of doing it, you might use letter-spacing, etc. Whereas if you tag that in as italics then you've only got italics, right? It's a simple example but at the end of the day you're going to have to decide how that is displayed. You mentioned print. In print no one sees the intermediate result. You see ink on paper. If I have some Greek in there and if I've done that by actually typing in Latin letters on the keyboard and putting a Greek font on it and out comes Greek, nobody knows. If it's a book that's being translated, there might be some problems. The more you're shipping the electronic version around, the more it actually matters that you put in the Greek letters as Greek because you will want to revise it. It matters that you have flowing text rather than text that has been hand-ragged because when you put in the revisions you're going to have to re-rag the entire thing or you can just say re-flow and fix it up later. Things like that.

PH: The idea of time, and the question of delay is interesting. Not how, but when you enter to fine-tune things manually. As a designer of books, you're always facing the question: when to edit, what, and on what level. For example, we saw this morning ((Andy Fitsimon: Publican, the new Open Source publishing tool-chain (LGM 2008)http://media.river-valley.tv/conferences/lgm2008/quicktime/0201-Andy_Fitzsimon.html)) that the idea of having multiple skins is really entering the publishing business, as an idea of creativity. But that's not the point, or not the complete point. When is it possible to enter the process? That's something that I think we have to develop, to think about.

NM: The other day there was a presentation by Michael Dominic Kostrzewa ((Michael Dominic Kostrzewa. Programmers hell: working with the UI designer (LGM 2008))) that shocked me. He is now working for Nokia, after working for Novell and he was explaining how designers and programmers were fighting each other instead of fighting the 'real villain', as he said, who were the managers. What was really interesting was how this division between content and style was also recouping a kind of political or socio-organizational divide within companies where you need to assign roles, borders, responsibilities to different people. What was really frightening from the talk was that you understood that this division was encouraging people not to try and learn from each other's practice. At some point, the designer would come to the programmer and say: “In the spec, this is supposed to be like this and I don't want to hear anything about what kind of technical problems you face.”

PH: Designers as lawyers!

NM: Yes... and the programmer would say: “OK, we respect the spec, but then we don't expect anything else from us.” This kind of behaviour in the end, blocks a lot of exchange, instead of making a more creative approach possible.

CL: I read about (and this is before skinning became more common) designers doing some multimedia things at Microsoft. You had designers and then there were coders. Each of them hated the other ones. The coders thought the designers were idiots who lived in lofts and had found objects in their ears. The designers thought that the programmers were a bunch of socially inept nerds who had no clue and never got out in sunlight and slept in their offices. And since they had that dynamic, they would never explain to each other (...)

(policeman arrives)

POLICEMAN: Do you speak English?

PH: Yes.

POLICEMAN: You must go from this place because there's a conference.

CL: Yes, we know. We are part of this conference (shows LGM badge).

POLICEMAN: We had a phone call that here's a picnic. I don't really see a picnic...

PH: We're doing an interview.

POLICEMAN: It looks like a picnic, and professors are getting nervous. You must go sit somewhere else. Sorry, it is the rules.

Have a nice day!

Transcription: Ivan + Femke