Episode 27 of The SitePoint Podcast is now available! This week, Kevin Yank (@sentience) has a one-on-one chat with Rachel Andrew, the author of SitePoint’s best-selling CSS book, The CSS Anthology, 3rd Edition.
Listen in your Browser
Play this episode directly in your browser! Just click the orange “play” button below:
A complete transcript of the interview is provided below.
Download this Episode
You can also download this episode as a standalone MP3 file. Here’s the link:
- SitePoint Podcast #27: CSS with Rachel Andrew (MP3, 35.4MB)
Subscribe to the Podcast
The SitePoint Podcast is on iTunes! Add the SitePoint Podcast to your iTunes player. Or, if you don’t use iTunes, you can subscribe to the feed directly.
Interview Transcript
Kevin: September 11th, 2009. On the show today, the author of SitePoint’s newest book, The CSS Anthology, 3rd Edition. This is the SitePoint Podcast #27: CSS with Rachel Andrew.
Kevin: And welcome, Rachel Andrew, to the SitePoint Podcast.
Rachel: Hello.
Kevin: Why don’t you go ahead and introduce yourself to our listeners.
Rachel: I’m a UK web developer and author of several SitePoint books, including The CSS Anthology.
Kevin: I’d say it’s fair to say that you’re actually one of SitePoint’s most prolific authors. You’ve written three editions of The CSS Anthology now. You and I collaborated on Everything You Know About CSS Is Wrong. Is there any I’m missing?
Rachel: There was a book about Dreamweaver.
Kevin: Yes, the Dreamweaver 8 book.
Rachel: Yup, and I did rewrite of the original CSS book that SitePoint did.
Kevin: That’s right, you did the second edition of HTML Utopia. That’s right. So you’ve written far and away more books than anyone else at SitePoint and yet, writing books is not your day job; you are a professional developer. In fact, you run a web development business. So I guess the question I have is, why write books?
Rachel: Well, I was asked this question this last week. I started really because I wrote a couple of articles that people liked and someone from Glasshouse, part of Wrox at the time, at the time said would you write a couple of chapters?
I’m actually from an arts background sort of entirely and so writing is something I quite enjoyed doing, probably unusual for a programmer, really. And so it really just gone from there that I started writing a couple of chapters and then eventually ended up with The CSS Anthology, which was the sort of first full book that I wrote that was just me.
But I had a fairly easy introduction into it and I do enjoy doing it. It’s certainly not my main job, however, I couldn’t do it if I didn’t do another job because everything I write about is really just things that I’ve discovered or little tricks I’ve worked out by doing the job that I do.
Kevin: Do you find that because you’re writing books pretty much constantly, it gives you an excuse to take that time and refresh your skills and stay on top of the news of what’s changing?
Rachel: I think so and particularly, it’s actually in my real job, I do an awful lot more backend development than I do front end. So I obviously do an awful lot of CSS work, as well.
Kevin: We should really get you to write a PHP book.
Rachel: That’s actually what I spend my days doing, is really it’s PHP and that’s what I do. And more and more, you know, as time has gone on I’ve become more interested in the backend and that tends to be what I spend most of my time doing.
Actually, I think if it wasn’t for the writing, I probably wouldn’t keep up to date with CSS as much as I do because, obviously, certainly in terms of new things that are coming up, we can’t always use those, the sort of things that we tend to be building at work which you have to be very robust in, in all sorts of varying browsers and things. So it does give me an excuse to go look into what’s coming up. You know, I wouldn’t really have much reason to look at CSS3, for instance, for most of the stuff we do at work. So that’s quite a nice aspect to it is I get to do a bit research and a bit of playing with things I wouldn’t otherwise look at.
Kevin: You know, I’ll take any excuse to have a chat with you, Rachel, but the reason we’re here talking today obviously is that the third edition of The CSS Anthology is out. And you mentioned that when that was the first book that you tackled all by yourself, you got a fairly gentle introduction to writing, did you say?
Rachel: Yeah. Well, I think, the nice thing about The CSS Anthology, I think, as an author and also as a reader, and the feedback I’ve had is that it’s all those little sections. You know, it’s how do I do this thing and then there’s a solution, which actually as a writer, I think, makes it quite easy to write because you can sit down and say, “Well I’m going to write about this solution now.”
Kevin: Yeah.
Rachel: And in a way often they’ve really written themselves because this is something I’ve done at work and I thought, “Yeah, that would be a great thing to go in that book”, because it’s useful, almost like writing a tutorial really and the way the book is structured is very much like that. It’s individual solutions, you don’t have to read the whole book.
And so in that way, it’s quite nice to write. I think it’s harder to write a book where you’re trying to weave a sort of common thread through it or build something from the start to the end. It is a relatively fast book to write in that way and to read, and sort of consume. You don’t need to feel you’ve got to sit down, devote a huge amount of time to getting through the whole thing.
Kevin: SitePoint has done a few of these anthologies, these problems and solutions books. What are your thoughts on people who might pick up The CSS Anthology, planning to learn CSS? Is that a good way to go about it?
Rachel: You know, I think often it is. I think there are some very basic concepts that you need to get down and I think the HTML Utopia: Designing Without Tables book was quite good for that in that it actually did take you through the very, very basic ideas of CSS. And we don’t do so much of that in the anthology, although there’s a sort of chapter at the beginning that sort of outlines the terms used and things. But once you’ve got that basic understanding, I think doing stuff is just the best way to learn. You know, people often sort of ask me how they can learn, how they can start to do this and I would say you just have to do it. Get the basic ideas down and then start playing. And I think the anthology is very good for that because you can say, how do I style lists, how do style data tables… or whatever it is, and you can just play at that and tweak things, change things in the style sheet. That’s quite a good way to get the grip with how things work.
Kevin: There’s this thing about learning, especially client-side web technologies. I don’t know if it’s the fact that you can view source on any website out there but there’s like – the process that I see so many people take to learning this stuff is they’ll learn the very basics, you know. CSS is contained in a file called .css that you link with a <link> tag and a rule looks roughly like this. And then they’ll go and start playing with other people’s codes, copying and pasting, and trying stuff out. And they’ll get a certain amount of distance along the journey that way and suddenly they’ll want to take a step back and learn it properly. And it seems I could see someone picking up an introductory CSS book like HTML Utopia, reading the first chapter and then just starting to play with a book like The CSS Anthology. And if and when they wanted to learn the in-depth principles of how the cascade works and things like that, you could go back to the tutorial style book. But The CSS Anthology seems uniquely suited, to me, for that learning by example, taking it one problem at a time that so many people seem to go to.
Rachel: Yeah, and I think – and certainly anyone of my sort of generation, I’m starting to feel like an old lady of the web now. And you know, that’s how we learned because there wasn’t anything else.
You know, when I sort of came to this, there were very few sort of real tutors about how to do anything more than very, very basic HTML. And certainly when CSS-P kind of came on the scene – I mean, I was building stuff very early on with that and there wasn’t really anything. You know, there were very few tutorials and things but it was really just the people who were doing it. You’d go and look at what they’d done and try it, and see it broke and fiddle with it. And I think those of us who have got a really very, very deep understanding of this stuff come from that kind of generation where we had to figure it out just by looking at stuff and playing around. I think there’s a lot of stuff out there now and some of it can be quite confusing; you know, where do you start if you want to learn.
You know, I think the anthology filters a lot of that as well. I mean, that was always my idea with this, that I would look at all the different techniques people were coming up with and the different ways to do things, and try and pick the things that will work really robustly across all the browsers you’re likely to encounter without too much hassle. So you know, some of them aren’t the most beautiful, elegant, technically perfect solutions, but they’re the solutions that work the best across all the browsers for people who don’t have hours and hours, and hours to spend tweaking every little thing.
Kevin: You mentioned CSS-P – CSS Positioning – and that’s something that I think this book is especially good at because there are two or three ways of achieving any given CSS layout, and really, which one is best for the job can depend on several constraints. And this book, it’s got a chapter on CSS layout that it really goes, okay, if you have these constraints, this is the best solution. If you have these constraints, that’s the best solution.
Rachel: Yeah, I mean that’s … and a lot of that really comes from doing things at work, you know, and working out which of the things is sort of the most robust. You know, it’s kind of, this is a good place to start if you need to do this kind of layout and obviously there’s going to be exceptions to that, but you need a starting point, particularly when you’re just coming to it and trying to work out which on earth of all these techniques you’ve seen would be best to use.
Kevin: This is the third edition of the book. It’s one of SitePoint’s most popular books which is the reason we wanted a third edition but from the author’s perspective, what justified for you updating this, writing a third edition?
Rachel: Well I think it’s a quite interesting point. When I go back to the very first edition, Netscape 4 was still on the scene, not as a majority browser but still was a browser that enough people, particularly into the universities and things, were using.
Kevin: Yeah, it boggles my mind that SitePoint has published books that covered Netscape 4.
Rachel: I know! I know.
Kevin: It seems so long ago now.
Rachel: Yes, it makes me feel very old. This Third Edition thing is like your children growing up.
And then when we did the last edition, we were talking about IE7 and things. We didn’t really drop support for IE6 in any shape or form, it was still a very common browser. I think at this point, given the lifespan of a book maybe being sort of 18 months or whatever, we’re starting to see IE6 dropping away. Certainly at work, we are able to start saying to clients, “Well, yes, we can do all the bells and whistles. We’re going have to drop some of those for IE6.” So that might be using GIFs instead of transparent PNGs or various techniques. But we were just slightly dropping this. We’re not losing support for IE6. We’re not saying, “If you got IE6, you can’t view our site.” What we’re saying is this sort of top level visual design is not going to be quite as nice because it just doesn’t support those things.
And if you’ve only got 10% of users, say, in IE6, then you probably don’t want to put a huge amount of your development budget into supporting that 10% as long as that 10% have got a decent experience of the site and can view everything.
So I guess that’s the way that I’ve gone to some extent in CSS Anthology. I still very much wanted all the solutions to work in IE6. So where I’ve used things that aren’t supported – a good case in point is the alpha transparency PNG thing; I have explained why it doesn’t work and ways around that. Whether you use some hack to force transparency or whether you do what we often do now at work and drop back to using GIFs because sometimes it’s just a case of changing the background image and using GIFs to remove the need for transparency.
Kevin: I’m curious; we’ve spoken several times about the state of Internet Explorer 6 recently on the podcast. I’m very curious about what the response has been from customers to that kind of situation now. When you’re speaking to a client and you’re making that case for treating IE6 as a downlevel browser effectively, what is the response? Are they receptive to that now?
Rachel: Actually they are and I think it’s purely, to be honest, on financial reasons because usually, you can battle it out and get IE6. Even with things like alpha transparency, which does tend to be a thing which can take quite a lot of time, if you decide to go and hack it with PNG fixes and stuff which then causes all sorts of other problems… if you still say, “Well, we can try and do it or you can scale your design down.” And they’re looking at it and thinking, “Well, we could the design we want, get it working in 90% of browsers exactly as we want and then perhaps scale it back a bit.” And when they look at it in a purely practical and business way, it doesn’t make sense to spend a huge amount of time and it can be on a very complex design. It can be an awful lot of time put into a browser which is going away…
Kevin: Are you in a position of having to quantify that for them? Are you having to say, “Look, if you want it to look this nice in IE6, it’s going to cost you this much extra.”
Rachel: I have taken to actually spelling out what it costs, rather than just wrapping it all into the design. Because for some clients, they might look at their stats and say, “Well, actually we only get 5% of people now.” It just depends on the site.
Something that’s going into a very corporate market may have an awful lot more. But then, those kinds of designs are often an awful lot easier to implement. It tends to be the more cutting edge stuff and things for particularly for a youth market or whether where they really want to go for it and really push the boat out with the design. And often, those markets don’t have very much IE6 because they’re individuals who can upgrade, who do get newer computers and therefore, get newer versions of the operating system and newer browsers. So I think it’s worth actually spelling that out to clients and saying, “We can do it. I’m not saying this is technically impossible.” And we do this with all sorts of things, especially when we talk about the backend. People say, “Can you do this and can you do that?” And you say, “Well, yes, technically, we can do it but this is how long it’s going to take, and is it worth it?”
I think it’s exactly the same with front end design. So, I do try and spell out where money is going when putting together a proposal so it isn’t just all rolled up into some big front end design thing. And we do work with design agencies. I work for a company who works specifically with design agencies doing their web development. So we are in probably a slightly better situation than people who have to pitch to real end clients because we’re talking to designers who do understand a bit of what all this is about and what this means.
Kevin: Well with IE6 fading into the background is a feature of this book, I suppose, the new browser on the scene then is IE8. What’s your impression of IE8 so far?
Rachel: Day to day, I have no problem with IE8, to be honest. I know the various things that the people discover and every browser has bugs. But actually, as a web developer, doing my job, I can usually build something – I work in Firefox, as my main browser. I can test it in Firefox. I can look at it in Safari. I can look at it in Opera. I look at it in IE8 and they will all look the same. I very, very rarely come across a situation where I’ve had a problem that is specific to IE8, which is brilliant because that’s what we all asked for. Of course, you’re going to have bugs and sometimes you come across something in Safari or in Firefox, you think what on earth is that doing?
Kevin: We’ve had the same experience very much. Almost invariably every time we have a problem in IE8, it’s because of something we did for IE7…
Rachel: Yes.
Kevin: …that is now not necessary in IE8. I suppose that’s very much what IE7 was too. It was fixing big painful bugs. IE8 has done that a fair bit too, but is there anything new in IE8 that you find yourself either taking advantage of or wanting to take advantage of because a new release of Safari comes out or Firefox comes out and we’re talking about web fonts, we’re talking about being able to put shadows on things but a new version of Internet Explorer comes out and it seems like we’re talking about, “Oh, I don’t have to deal with that bug anymore.”
Rachel: I think that is the case. I think really it comes down to that people play with Safari and they play with Firefox. They often have these – particularly Safari’s brought in things very early on which are quite interesting to us web developers but actually, we’re probably not using for real sites. We’re not using at work, as it were, because we know that not enough people actually have that browser.
I think the same is true with things that are in IE8 – the CSS tables stuff which of course, exists in other browsers already. We can’t really use it that much or to a great extent in production work at the moment because there are too many people with IE7, and even IE6, knocking around. The sort of work we tend to do – I’m pretty pragmatic about this stuff, it has to work and I will use the method that works well and is non-damaging and I do that. That tends to be where I go with this stuff because these sites are going to be around for a long time. I’m still maintaining sites that I’ve built six years ago. I know these things will be around for a long time and so, we’re trying to build in a very robust way because of that.
I think that the problem with getting excited about new stuff in browsers is then you just get very frustrated and you’re like things aren’t moving on fast enough. I want to be able to use this stuff. So I think it’s balancing up saying yeah, look at all this new cool stuff but also well, I’ve got to do my job.
Kevin: So do you find yourself in the position of when you’re talking about, for example, we’re retiring IE6 then I suppose at that point you’re thinking wow, now we can start using these things that everything apart from IE6 supports. Your cool new features happen when you’re retiring old browsers.
Rachel: Yes, I think they do and for me, it is often just stuff like selectors that we can’t use because of IE6 or that we are currently having to replace with JavaScript if we do use them and that sort of thing. It’s little things like that actually that make the biggest difference, I think. Not needing to stick a class on your first paragraph to be able to make it look different to the others. That’s the stuff that actually day to day you notice when you start saying yeah, it’s okay if IE6 doesn’t have that first paragraph larger.
So I think there are sort of two things. There is the kind of geek in me that likes to look at all the cool new stuff that’s coming out and play with it, and then there’s the person who just has to run a business and do a job. And in that sense, it’s often the little things that make the biggest difference, like when we don’t have to worry about whether something has layout or not, will be lovely.
Kevin: Absolutely. Speaking of has layout and hacks like that, it seems to me that CSS in general… the playing field between browsers seems to be levelling out a bit. Certainly, there is less need for hacks than ever before. Speaking for yourself, are you a CSS hack person or a conditional comment person?
Rachel: It depends on the job. I still maintain that if there are two things that need fixing in IE6 then using * html is perfectly fine because its two little things you put in your style sheet and you’re not having to add anything extra to the document. Where you’ve got a lot of stuff, for instance, if you’re hacking around transparency or something, then yet, I’ll use conditional comments because it means I can get that CSS and the JavaScript and anything else; it’s all out of the way and somewhere separate.
So I think the answer really is it depends. I think most of the stuff that we do… that we’ve done recently, there have been significant amount of IE6 fixes and so, yeah, we have a tendency to put them into something attached to conditional comments. I have a bit of an issue about this sort of making comments parsable thing which has happened because of that. I’m not sure that’s such a great way to go but I think as with a lot of things, you use the best methods that you have available.
Kevin: It’s really a strange thing, I actually find myself feeling okay about it as long as it’s just an Internet Explorer thing.
Rachel: Yes.
Kevin: As soon as it becomes something that other browsers want to do, then you start having a standard for the contents of comments and just feels icky.
Rachel: That feels wrong. And I think also, it’s getting away from the place you want to be, which is that all browsers support the same stuff. If browsers start saying, “Oh, it’s okay that we do this in a weird way because you can get around it with conditional comments,” and so before we know it, we’ve got sort of like 20 style sheets. That’s not somewhere we want to be going and I think this stuff first came on the scene and I was very worried that it was going to be used as an excuse by browsers to say, “Well, it’s okay for us to do this differently or whatever.” And obviously that was something we were trying to get well away from. But that doesn’t seem to have happened and it just tend to being used now by people just to get around browser bugs in IE and that’s kind of okay because, if you’re dealing with a bug, I think whatever methods you have to use just to get around that, that’s probably okay and if you can do it in as clean a way as possible. So it’s not just tripping you up constantly afterwards, well, that’s helpful.
Kevin: I’m interested in discussing how maybe the CSS code that you see in one of your books differs from the code that you actually write day to day in your work. Are there any differences?
Rachel: Not hugely. I think certainly not CSS Anthology because I try to write as much as possible to be practical stuff or could just lift and use.
Kevin: Well see, that it in itself is a constraint that I might not have in the real world when working on my own code. Every piece of code in CSS Anthology as much as possible has to stand alone. Do you have any dependencies when you’re working? Do you have a framework that you start from or are you starting from scratch for every project?
Rachel: I don’t use a framework. I’ve had to use them before because I do a lot of work for design agencies, you have come to across existing stuff or they standardized on something and wanted to use it. I find it took far longer than just sitting down and hammering it out. I think a lot of that is due to the fact that I’ve just been doing this for so long that I’ve got to kind of framework in my head. But I’ve actually I find that what you end up with this, you end up with a lot of stuff to counteract the framework unless it’s been designed specifically for that. I’ve come across companies where they’ve standardized on a framework and their designers know the framework. So they design stuff they think will fit within it grids and whatever, which I guess is one way of doing things and I guess could let you knock stuff out very quickly.
Kevin: So you find it’s a bit limiting and as soon as you want to do something that the framework doesn’t accommodate out of the box, you have to work around it a lot more?
Rachel: Yeah, you have to work around it. I’m not anti-frameworks. If people find that a useful way to work, then that’s cool but I think, yeah, I’d much rather actually take each project as an individual thing and build it in as clean a way as possible. But that’s just me; I’m not particularly religious about all this stuff.
Kevin: Well speaking of religion, what sort of tools do you use? Because developers seem get especially religious about their text editor.
Rachel: I only use what I use for PHP which is Zend. In fact, I’m still an old style Zend Studio user because I’ve never quite managed to get the Eclipse version to install on my Ubuntu box. So, there is a new version out, I really need to try and get this working.
So yes, I’m using old school Zend Studio and I use that for everything. It’s a rubbish CSS editor but I just sort of type. I’ve always been someone who really just needs a glorified Notepad. I just type. I type very fast and very accurately and I don’t use a lot of the tools that are in editors. I like Zend for PHP because I like the fact that its intelligent enough to sort of deal with old PHP well and come up with hints for my own functions and things, which is nice. That’s useful on a big project but for CSS, I just sit down and type.
Kevin: What browser do you usually have opened when you’re developing? What’s the first browser you test in as you’re working?
Rachel: Firefox, and it’s mainly because I work on Ubuntu at work and I have a Mac at home. So I can use Firefox and Web Developer toolbar and things and Firebug I can have that everywhere. And it’s the same thing with Zend as well, I can install that on the Mac and on Ubuntu. So it’s nice to have common tools without worrying which operating system I’m sat in front of.
Kevin: Let’s talk for a minute about CSS3 which you mentioned you had an excuse to keep up with because of you’re writing. What are your thoughts on the new stuff that seems to be coming in CSS3 and how it’s being introduced as opposed to the last wave of stuff they got introduced to browsers? Are they doing a better job of it?
Rachel: I don’t know, I think with all of these stuff, you kind of just have to wait and see how people use it and what people pick up on. I think that there is kind of two bunches of people out there; there is people who just … they just want to know about what works and won’t touch anything until they see other people use it and say, “Look, it works. It works in these browsers.” And I think that’s the point at which new things will get picked up, really is when the people who like to play with new stuff get it, play with it, write about it, and say, “Look, it works in these browsers, you can use this.”
Kevin: Whereas, I’m very much one of those people who get excited by a sexy spec.
Rachel: Yeah, when I have free time, I say I find that sort of almost academically interesting, you know, “What can this do? What will this bit of the spec, what will that introduce if that gets implemented?” I think most people probably really aren’t that interested in things until they can see a real use for it and they can see that it won’t break.
Kevin: So is there anything in CSS3 that passes that litmus test yet?
Rachel: There are sort of bits of it isn’t there but I think that – I mean IE8 is helping obviously with particularly the CSS tables stuff and things. We’re starting to see more stuff become mainstream but it’s probably a bit early really. I guess we’ll get there…
Kevin: It’s almost artificial to discuss CSS3 as a thing because it really is being approached as a bunch of little bits.
Rachel: Yes, I think it’s little bits as they come in. I think people probably wont even be thinking, “It’s CSS3. It’s just a new thing that works in the browser.”
Kevin: The way they’re approaching it now CSS3 will never be done. They’ll just keep adding more bits to it.
Rachel: I think that’s it. I think its more which bits of it can we use and that’s really what I’m interested in because its stuff that can be actually used, even if it can only be used in Firefox, where sometimes you can get away with adding a few little tweaks, particularly for personal stuff or stuff that’s aimed at a particular market, even if only a few people actually see it. I think there’s quite a lot of people doing that sort of thing with their own stuff.
I think it’s very easy to sort of think the timeframes for all this stuff are so long but actually when you look back, when you think it’s not actually that long ago, we were battling with Netscape 4, and thought it would never go away and that we’d never be able to do CSS layouts in a sensible manner.
Kevin: This stuff comes in waves and we’re very much in the midst of a wave crashing over us right now. The browsers are coming thick and fast with new features.
Rachel: Yeah, I think it’s just… it’s people, and I guess people like us, who do write about this stuff, looking and being a bit of a filter for the majority of people who will only do stuff when they see some expert say, “Here it is, you do it like this, and it works in these browsers.” I think that’s very much what I do as an author.
I like to look at stuff and actually say, “Well, you can do this and here is a way around it for browsers that don’t support it…” I think that’s what the book does for a lot of things and particular things that aren’t going to work in IE6.
Kevin: Well you mentioned you code in Zend Studio because you spend a lot of your time in PHP. I wanted to take a few minutes before we wrap this up to talk about Perch. Perch is a CMS product that you are selling, is that right?
Rachel: Yeah, it’s a really little CMS. As a company, we have a big CMS framework that we developed, which a lot of our projects are based upon, which is sort very flexible, but a key thing about it is that it’s template based and it doesn’t sort of force any reliance on a certain markup language and it allows people to use things like microformats and things.
The big problem with a lot of CMS, large and small, is this problem of you get a big text area that you’ve just blab your text into. So you lose the ability to have structured content and of course, with things like microformats, structured data is quite important.
Also, I’m a bit of database geek and I like to store things properly. If something is an event, I want it stored as an event because that might be useful in the future and it means we can use it elsewhere.
Anyway, I mean that was somewhere that we’ve got with work and with our sort of main product, the thing that we build a lot of our big stuff on. But then we were also getting, you know, because we work with design agencies, people who had very, very small products – things they needed to launch in a very small brochure site, but they wanted it to be editable, and obviously, it was a complete overkill for us to do an implementation of our big CMS on these things.
Kevin: Well, yeah and you mentioned when we were discussing CSS frameworks before that often learning the framework and ways around it is more trouble than just doing it yourself. I find that’s true with a lot of CSS. They’re called CMSs, but in most cases, they are full frameworks where you start with the CMS and then you code to the style mandated by the CMS. What I find really attractive and interesting about Perch is you start with your own code.
Rachel: I mean that was the thing, we wanted something to let people build things in the way they already build things. I’m sure if they want to use Dreamweaver, they can just build their pages like they normally do and they don’t have to think about will this work, will I be able to split this up? Because even using something like WordPress, which a lot of people say, oh well we can do that for free with WordPress; it’s quite a lot of work to get to the point where your templates work. And if you’re a designer and not a coder and don’t want to be a coder, that can seem like quite a learning curve to get that going.
So that was the thing with Perch; we wanted something that was very, very simple for people to get up and running, but that also allowed this structured content, that allowed people to get their clients to add contact information as a contact and to be able to not just provide people with a big sort of text block to type into, although they can do that if that’s what they want, but I think a lot of the power is this template idea where you can create just with normal HTML, these templates, which then are used to structure the data.
I think it has been very successful, I think there was a need for it, and people are doing all sorts of interesting things with it. It’s great fun seeing the sites that people build with something and it’s a big departure for us because we’ve just done services.
Kevin: As a product that was developed initially for internal use, I imagine… how long has Perch been around?
Rachel: Some of the concepts came from the big CMS we have so obviously, this is some of the ideas and the way it worked, but actually as its own product, it was developed very quickly because by that point, we knew exactly what it should be. But I mean, yeah, there were concepts in there that go back a very long way.
Kevin: So it wasn’t a case of taking something you had and writing the documentation and polish for it; it was, you took a bunch of ideas and put them together.
Rachel: Yeah, once we realized that that’s what we wanted to do, it was sort of built as a new thing, there’s no sort of legacy, crafty stuff, it’s all PHP5 and built in that way. It’s new in itself, but yeah, I mean the ideas go back a long way. I’ve been building sort of custom content management systems since 2001. So everything we do, it is sort of built on that knowledge and knowing what works and what doesn’t.
Kevin: So Perch – it’s written in PHP clearly, but you don’t have to necessarily know PHP very well in order to implement it.
What’s exciting to me is CMSs these days, they’re either free open source or they cost thousands of dollars and purchase rather unique in that it’s got a very, very… how much does it cost for a license?
Rachel: It’s £35.
Kevin: Well, there you go, yeah, and that buys you for a domain or a site? How does it work?
Rachel: Yeah, it’s on a domain basis, but we thought about this a lot because we wanted to sort of protect what we’ve done, but we don’t make it a pain to use for people. So basically, people set up their domain and they set up a test domain so they don’t have to keep changing and they can switch those at any point. I mean, really obviously we want… you can’t protect things to any great degree, as we all know, things like the PDFs for books and things.
I mean, there’s always going to be a problem with people copying stuff, but we wanted… so that people knew that yes, they did need to pay for a site and hopefully, people will and they won’t try and subvert that. But we don’t want to make an absolute pain because it’s no fun if it’s pain to use something because the protection that’s been put on it when you’ve paid for it legally.
It’s a bit like being made to watch those awful introductions to DVDs that you’ve bought that tell you not to pirate them. You say “Well I bought this, why am I being made to watch this?”
Kevin: But still, it’s nice to have a price on the website because so many commercial CMSs you go to the company, how much does it going to cause me and they go, “Well how much money do you plan to make in using it?”
Rachel: Yes, exactly. We wanted people to know… we wanted it to be a cost that people could absorb into their projects quite easily. If it saves you an hour of time, then really, at most people’s rates, that should be saving you money. We wanted to make enough in it that it was worth us continuing to support it and continuing to develop it because obviously, yes, we could have had an open source project for instance, but we’re really busy web developers and we have to eat, and had we just sort of put it out there, you know, we’ve got things that we’ve built and put out there and actually finding the time to then do any more work on them is a struggle.
Kevin: Like I said, it’s interesting. Just the fact of putting a price tag on it in itself helps it stand out from the crowd because the world isn’t going to take that much notice of yet another open source CMS for PHP; let’s be honest.
Rachel: We are giving people lots of support for that money. That’s the the rub with a product of course is that suddenly you have customers to support.
Kevin: It’s an incredible bargain.
Rachel: Yeah, which is new. I mean, that’s very new for us to have customers rather than clients. We really, as a company, have a fairly small number of clients who we work with for a very long time because we’re working with design agencies, so obviously they’re getting new jobs and we’re doing the development for them.
Kevin: Well, there you have it listener, get in quick before they have to turn up the price to justify the support, yeah.
Rachel: So there’s definitely a whole lot of stuff I could write about going from being a company that does services to being a company that has a product because the two are very, very different and it’s been very interesting, that sort of journey.
Kevin: Well then, we may have to get you on at some point for another conversation along those lines.
Thank you for joining us, Rachel.
Rachel: It’s been good.
Kevin: It’s been an absolute pleasure.
Kevin: And thanks for listening to the SitePoint Podcast. If you have any thoughts or questions about today’s interview, please do get in touch. You can find SitePoint on Twitter @sitepointdotcom and you can find me on Twitter @sentience.
Visit sitepoint.com/podcast to leave a comment on the show and to subscribe to get every show automatically.
We’ll be back next week with another news and commentary show with our usual panel of experts.
The SitePoint Podcast is produced by Carl Longnecker and I’m Kevin Yank. Bye for now.
Theme music by Mike Mella.
Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.
Comments