104. Give us your money
Published on: December 12, 2007 by Paul Boag
On this week's show: Paul shares 10 tips for getting designs signed off. Marcus looks at how to present to a prospective client and Michael Slater introduces us to Ruby on Rails.
News and events | Marcus: How to present to a prospective client | Paul: 10 tips for design sign off | Michael Slater talks about Ruby on Rails | Question of the week
Housekeeping
All change
I have a bit of housekeeping news before we go any further with the show. I am changing things around a bit with my podcasting line up. After a chat with Dan Oliver from .net magazine we have decided that I will no longer be doing their show. They have some great plans for it in the future but it just didn't make sense for me to keep doing two very similar shows. Before people start emailing, no we haven't had a falling out and I still love Dan very much... if only I wasn't already married.
The good news is that this allows me to introduce some more guests onto this show and bring in a bit more discussion. In order to accommodate this we will be having just one feature section each week instead of my bit and Marcus bit. Some weeks I will do it and other weeks it will be Marcus.
The final aspect of all of this is that we are going to start recording the show together rather than over skype. This should deal with the audio problems we have been having as well as making for a much better dynamic.
Christmas giving
I thought it might be nice to use the mighty power of the Boagworld listeners to raise a bit of money this Christmas and wondered if you might all be so kind as to help.
We have been doing this show for well over 2 years and have never charged or done much in the way of advertising. We are therefore wondering if just this once you would dip your hands into your pockets and give a bit of cash.
I want to raise some money for a charity I have been personally supporting for a while. A friend I grew up with now runs a school and orphanage in a very rural part of India. The kids they work with have far from the best background and the school is the only hope they have of breaking out of their circumstances.
I wont emotionally blackmail you with sob stories (because I know you are hardened cynical geeks) but simply ask that you give me some cash in return for the two years of free shows I have given you.
Because I am unorganised and only thought of this a couple of days ago we are going to simply use my paypal account to collect donations. I will then pass the money on to the charity. So to give a donation just use the bottom below (be warned its not the most intuitive system ever but you are all clever chaps. I am sure you will work it out).
Give to the Boagworld Christmas Appeal
News and events
24 ways is back
My first story of the day is actually 12 days late because it is the re-launch of 24 ways. In case you haven't come across 24 ways before I should explain that it is an advent calendar for web designers.
Each day in December leading up to Christmas they publish an article written by some of the leading lights in web design (oh yes, and me). The articles are somewhat random but also incredibly practical and hands on. Articles range from creating a never-ending background to working with online maps.
But don't panic that you have missed the first half of advent. You can access all of the previous days. In fact you can even access the last 2 years of articles. Ample to keep you amused while we are away over Christmas.
Tips for development and design
If 24 ways isn't enough to quench your thirst for knowledge then let's throw two more articles into the mix both of which provide some top tips.
The first is for all you developers out there. The guys at Blue Flavor have shared their top 10 tips for a successful development project. The article includes great advice like, always create a functional spec and talk to your clients. Interestingly one of the suggestions is to use a version control system. This is also a tip in our second article which is aimed instead at designers.
Jina Bolton has written an interesting article for Think Vitamin entitled "creating sexy stylesheets". Like the blue flavor article this one lists 10 tips. However this time they are for producing better stylesheets. Now, although I would argue that nothing makes CSS sexy this is still a very useful list. The tips for organising your CSS file and building your own framework are particularly good.
So if you are into top 10 lists then you should be happy this week whether you are a designer or a developer.
The state of HTML email
Talking of Think Vitamin articles, our next story starts with another of their features, this time on ensuring your HTML emails look great and get delivered. This article is a follow up to a previous post before the world of HTML email went to hell in a hand basket. This post looks at the state of HTML emails and provides some solid advice about how to go about building them using at least some CSS.
Unfortunately CSS support for HTML email is patchy at best. On the upside the guys over at the Web standards group are coming to the rescue with the new Email Standards Project. These guys work with email client developers and the design community to improve web standards support and accessibility in email and they are already off to a flying start. In particular I love their name and shame approach on the homepage which lists the email clients and shows their level of support for standards. Its definitely worth checking out if you work with HTML emails as it also lists which CSS properties are supported by which clients.
Help with your min and max widths
Last up is a useful little tool that Leigh (one of the designers at Headscape) found recently. I have no idea how long it has been online so this might be old news to many of you. The tool is called the Jello Mould Generator and is designed to help fix the minimum and maximum width of a fluid website.
If like us you work a lot with fluid sites, you will know that in order to stop the design completely screwing up at small browser sizes it is necessary to set a minimum width for the site. Equally a maximum width needs to be set to stop ridiculously long line lengths at higher resolutions. The problem is that getting min and max width to work can be fiddly and involves a lot of unnecessary maths. That is where the Jello Mould Generator comes in. It does all of those calculations for you. You simply enter the minimum and maximum width you want and it does the rest.
One less headache to deal with. All we need now is a generator to fix IE 6.
Marcus' bit: How to present to a prospective client
I have been thinking about the presentation part of pitching this week because we were due to give one on Friday without writing a proposal beforehand. In the end, we decided to pull out of it for a number of reasons but I thought I would look into the process of presenting here anyway.
Requirements
If the original brief didn't spell out what is expected of you at the presentation then make sure you ask beforehand. The critical element is how much time you have. It seems that panels are providing less and less time these days – which is frustrating!
The usual formula is that you get an hour; half of which should be a presentation of your ideas followed by 30 minutes of questions. This isn't that much time, particularly for a big project that covers all aspect of web design and production. Don't be afraid to ask for more time, though it is very rare that you will be granted any.
Ask if there any areas that a) they particularly want you to cover and b) if there are any areas of your proposal that were weak.
Ask who will be attending. The main reason for this is to see if the decision maker(s) will be present but it's also good to know if you're presenting to 3 or 30 people!
To PowerPoint or not
Giving a presentation using PowerPoint (or Keynote) seems to have a bit of a bad name for some reason. I think it's because a lot of people produce boring, badly designed PowerPoint presentation that usually include inappropriate and awful looking clip art.
I really like using PowerPoint because it provides a strong graphical background to my narrative. But, particularly for a design agency, it must look great. Here's a few PP rules that I try to abide by:
- Use a set of templates (the new PP07 templates are excellent)
- But, preferably use a set of company branded templates
- Don't use too many words – the words are not there for you, the presenter, to parrot back to the audience!
- Mix it up – one slide may include 5 or 6 bullet points, so make the next one include a couple of images instead. Showing appropriate video is also very powerful.
- Create navigational tools – we try to encourage our audiences to question us along the way. This can lead to the presentation going off track. Creating a menu page with links back to it from all pages allows you to move to different parts of the presentation easily.
Who should be there
Generally speaking, I think two is the ideal number. Though I have done many presentations on my own (and been successful), I always feel having two people to bounce ideas around with and have a bit of banter with, works well. You are not only trying to sell your ideas and expertise but also yourselves. One of the main things in the panels minds will be – "can I work with these people?"
Having more than two people at a presentation often looks like you're wheeling people out just to demonstrate that they exist! Paul, Chris and I tend to do most of this type of work for Headscape which does leave a bit of a technical hole in our knowledge. We have often included our technical lead as a third person for large tech based presentations but they have nearly always complained of not getting a word in!
Differentiation
Sometimes, especially if you think you are an outsider, it's worth taking a few risks. I remember Paul starting off a presentation once with line (backed up on screen) – "Headscape is not a usability consultancy". This was in response to the clients request to engage a usability consultancy. The thrust of Paul's argument was that we are a lot more than that.
This really worked. We were the outside choice but they ended up hiring us. Basically, this differentiated us from the crowd. It showed that we are prepared to take risks and think, dare I say it, outside of the box.
Tell the truth
Panels often want to nail down price and timescales. This is fine, discuss it, but don't give anything daft away just because you want to win.
Don't panic…
If you go into a presentation thinking ‘we must win this' then, chances are, you won't. Relax and be yourself. If you're not hitting it off with the panel then so be it. You have to remember that quite often you will be making up the numbers in a tendering process. This is massively frustrating but, unfortunately, part of it. If it's not going well, concentrate on your offering and try to demonstrate your professionalism rather than your personality.
Finally, be on your toes, watch people's reactions and pay attention to what they say and try to react accordingly.
Paul's corner: 10 tips for design sign off
In the news segment I mentioned a site called 24 ways which post articles on web design over the Christmas period. Well, I was asked to contribute to the site so I wrote an article entitled 10 tips for design sign off. Although some of the tips have been covered on the show I thought generally it would make a good segment for the show.
The problem is that getting design sign off can be one of the most challenging parts of the web design process. It can prove time consuming, demoralizing and if you are not careful can lead to a dissatisfied client. What is more you can end up with a design that you are ashamed to include in your portfolio.
How then can you ensure that the design you produce is the one that gets built? How can you get the client to sign off on your design? (10 tips for design sign off)
Ask the expert: Michael Slater talks about Ruby on Rails
My name is Michael Slater. Paul invited me to submit a short piece about Ruby on Rails, and I'm really excited to have this chance to speak to the Boagworld listeners. I've enjoyed the show for a long time and I'm glad to have a chance to contribute something back.
I’m an entrepreneur and web developer in Northern California, near the small town of Sebastopol. I’ve been developing with Rails for the past 18 months, after several years working of personally with PHP and managing teams building Java projects.
I've become convinced that many web developers would be more productive, produce better sites, and have more fun if they used Ruby on Rails instead of their current technology. It's a strong statement, but I think it holds up.
Rails is at the heart of many leading web applications, such as Basecamp, Blinksale, 43Things, Odeo, Revolution Health, Twitter. Both developers and entrepreneurs love the speed at which they can build applications and incrementally develop them.
There's also an increasing use of Rails at established companies. Yellowpages.com in the U.S. is now a Rails site. eBay, Amazon, and AOL all now have Rails projects, and ThoughtWorks, a large global IT consultancy, is doing many enterprise applications in Rails.
Rails has a vibrant, friendly developer community, and almost everything you need, from development tools to web, application, and database servers, is open-source. And there's a big demand for freelancers and employees with Rails skills. So there's a lot to be said for the platform.
Rails is not a panacea, and there are definitely applications for which there are better solutions. But for the vast majority of new web sites being built today, it is very well suited.
The ideal Rails application has these three characteristics:
- First, it is a database-backed web site, or a web service, that is large enough that you can justify the overhead of a powerful framework
- Second, it has needs unusual enough that they aren't well met by a typical CMS
- And, third, it is a new application, so you can start fresh with the database and software architecture
This is what I think of as the "sweet spot" for Rails applications, and it's a pretty large spot. I believe that for most of these applications, the site can be built substantially more quickly using Rails that with PHP, .NET, or Java. But this is only true if the team is as comfortable with Rails as they are with their current technology, which is not the case for most developers today.
If you’re an experienced user of any particular technology that does the job for you, switching to another technology involves a transition that, in the near term, will destroy your productivity.
But if you're planning to keep building web sites for some time, and you're building sites of significant complexity, this short-term investment of your time will pay off handsomely.
So my bottom-line premise is this: for most web developers, Ruby on Rails skills will be a critical part of your toolbox if you want to be competitive.
In the few minutes we have here, I have to ask you to take a lot on faith. You can get more details at our web site, LearningRails.com.
Let's assume for now that I've convinced you it's worth at least a few more minutes of your time to learn about Rails. What is it, really?
There’s two separate parts to Ruby on Rails: the Ruby language, and the Rails framework.
Rails is a web application framework, written in the Ruby language. All Rails applications are written in Ruby.
Ruby is a modern, object-oriented language. It is what is called a dynamic language, which means a variety of things. Ruby is interpreted dynamically, so there is no compilation. Variables don't need to be assigned a particular type but are dynamically assigned a type when they’re used. And a program can generate code dynamically, modifying itself as it executes.
Ruby is a wonderfully clean language to read and write, and because the language can be easily extended, Rails is able to create, with Ruby, a sort of special-purpose language for building web applications. While Ruby and Rails are separate things, they complement and depend on each other in subtle ways.
If all this talk about modern object-oriented programming scared you off, don't worry. Learning the parts of Ruby that you need to know to use Rails is not difficult. To do development work on the framework itself requires some advanced Ruby skills, but to start building applications using the framework you only need to know a limited subset of Ruby’s capabilities. If you've done a little PHP programming, or written some JavaScript code, you can learn what you need to develop Rails sites.
If you're a PHP developer and you want to avoid learning a new language, you could use a framework such as CakePHP, which brings many Rails concepts to PHP. But learning a powerful framework, whether it is written in Ruby or in PHP, is actually a lot harder than learning the basics of programming in Ruby. Why not make the modest incremental investment of learning Ruby? You'll be rewarded with a cleaner framework and, if I dare say so, a better language.
Rails is a big body of related software. It is both broad and deep, providing a wide range of capabilities and delivering a lot of depth in many of them.
Rails organizes each application around a model-view-controller structure for your application. MVC is a well-established pattern for organizing software projects and has proven to be a great match for web applications.
Rails includes powerful facilities for working with your database, using a library called Active Record. It includes a capable system for creating pages (views, in the MVC world) with templates and ajax. And it includes a built-in testing framework.
There's also a plug-in system, a great tool for automating deployment, called Capistrano, and a variety of other tools for documentation and other development tasks that come from the Ruby world.
Rails tries hard to provide reasonable defaults for almost everything. Following a philosophy called convention over configuration, Rails almost entirely eliminates beasts like XML configuration files (have you ever seen a Java web application?). If you follow the Rails conventions, an amazing amount of stuff just works, and the amount of code it takes to accomplish many common tasks is much less than with most other languages and frameworks.
You may have heard about how easy Rails makes it to build web applications, yet found upon looking into it that it didn't seem so easy. The complexity of Rails can make it hard to learn for a beginner. It takes months of development to become familiar with all, or even most, of Rails. But you can get started by first learning just enough to build a basic Rails site. As you begin working with it, you’ll pick up new skills and knowledge as you need it. Once you're up to speed, you'll be more productive than ever.
If I've managed to capture your interest in this brief piece, check out the Learning Rails podcast at LearningRails.com.
Question of the week
What tips do you have for getting designs signed off?
Comments
Comments are for the discussion of this post. If you have other questions / comments then post them to the forum or send me an email
Post by Stuart on December 12, 2007 7:44 PM
Post by Paul Boag on December 12, 2007 9:55 PM
Post by Charlie on December 13, 2007 5:42 PM
Post by Ryan Behrman on December 15, 2007 1:21 AM
Post by Ryan Behrman on December 15, 2007 1:23 AM
Post by purelocke on December 15, 2007 6:13 AM
Post by Brian Morris on December 16, 2007 12:25 AM
Post by design directory on December 26, 2007 9:39 AM
Post by www.r10.net küresel ısınmaya hayır seo yarışması on December 27, 2007 6:43 PM