Related
I have general question how to start developing my skills in web designing.
What is best place to start and what technique to use.
I have some knowledge of html and css, so far I have been building sites with already done all html and css. I would just use it and maybe do a smaller changes.
I want to be able to make html and css out of image that artistic guy produces.
http://w3schools.com/ has some great tutorials and you can play around with stuff right their on their pages.
A lot of the really "artsy" sites are produced in another program first, usually Adobe Photoshop or Adobe Illustrator, and then 'sliced' into HTML div's. NetTuts has a handful of tutorial on how these that show the complete start-to-finish. Here's a few I found real quick:
Design and Code a Slick Website from Scratch – Part I
How to Design and Code a Flexible Website
New Plus Tutorial: Convert a Beautiful PSD to HTML and CSS
Coding a Beautiful Website From Scratch: Plus Tutorial
(the last 2 I think you have to be a paying member for)
Here's a great web resource to check out for HTML/CSS: http://htmldog.com/
Also, do a Google search for "psd slicing." This is the process of taking an image of a website layout (a.k.a. mockup) and turning into valid HTML/CSS. You'll find a lot of screen casts and tutorials that will walk you through the entire process.
Start by getting a book and look at some tutorials. Google will help you there. Once you've got a decent idea of what's going on, look at a site, and try to duplicate what it looks like. If you're curious as to how something works or can't figure it out, look at the source (preferably with firebug) :D
Good luck
As others have said, getting a good book on HTML/CSS will certainly help.
Also read up on Web Standards - I think its really important to start learning these principles from the beginning as it will help you write valid HTML/CSS... and avoid writing invalid code.
I highly suggest the book "CSS Mastery". It's got a green cover with a pink binding...I think they've recently released a new version actually. Amazing book for beginning and advanced. I consider it my CSS bible.
I highly recommend w3schools.com and the Head First HTML with CSS & XHTML. I like most of the book in the head first series, in fact. They take a fun very visual approach to learning & I am a visual learner. Lots of things to practice & hints to help remember things.
If you don't feel totally confident then definitely pick up Head First HTML. Aside from that there are a few websites I would recommend:
A List Apart,
Stop Design
and as others mentioned the W3 website.
Working with a designer often means that they will produce mockups using Photoshop and you will in tern work off those. As that is the case having a working knowledge of Photoshop will be very useful for you. You don't have to be a wizard but some basic knowledge will enable you to do things like create image sprites from the mockup and get information relating to the width, height, color, etc of the different components in the design. As far as getting up to speed quickly there are many books on the subject, the Photoshop One on One books are a pretty good series and there are video tutorials available at Lynda.com.
I started on just looking at youtube. A really simple book for learning to code css and html is get coding. It's for kids, but it's a great start. I started there about a year ago, and now I've developed multiple websites for a couple of businesses. And I'm only twelve!
Question asked a couple minutes ago gave me this idea... If you were to teach someone HTML today, it would be significantly more difficult than a couple years ago.
For example, the <font> tag is simple, straightforward, and easy to understand. But it's now slated for the chopping block in future versions of HTML. I couldn't imagine trying to learn HTML today the "right" way with CSS and style:-type markup.
So where's the line? Should someone learn tags that are easy to understand but deprecated? Or should you insist on "getting" CSS and validation-passing styling from day one?
Learn the correct and valid way. It will reduce the bad habits and in the long run you will have to learn less.
I disagree. I think HTML is simpler today. You look at modern, clean HTML and that's what you see: clean, HTML, with minimal markup.
Presentation wise, it's nothing to shout at. But CSS fixes that.
CSS makes it even better. Simple changes have dramatic effect. Those dramatic effects lead to quick satisfaction and feedback. It also lets folks make sweeping changes, that affect "everything" rather than having to run through and propagate those changes.
That makes "mistakes" cheap to fix, which, again, leads to quicker success, and faster confidence.
Are there a lot of tricks of the trade in CSS and HTML? You bet. But most folks don't need that right level of expertise right away.
So, IMHO, HTML is a much better animal today than in the "old days".
It would depend on the situation. I can see possible cases where I may want to teach someone as little as possible. Say they have to learn a litle htnl in order to to edit some content on a page every so often, and I know this person to be someone who won't bother to learn more than he or she needs to.
However if I were teaching someone who was serious about learning definitely I would definitely try to have them learn the right way. I learned too many bad habits of my own and am still having to learn the "proper" way of doing things. I feel responsible for anyone I teach, and would like to spare them that hassle.
And learning to do things properly is really not that hard and it's a heck of a lot harder than unlearning the wrong way and bad habits.
HTML has been trending away from style-markup and toward semantic markup for many years now. There are lots of good reasons for this; I don't think you asked this question to get a separation-of-style-and-content lecture :)
In terms of learning HTML, I think people learning HTML can understand the simple lessons about how tags turn into webpages using elements like <p> and <ul>. When they inevitably get the "ew its ugly! how do I fix it!" itch, introducing CSS via the style attribute is not the worst thing in the world, as long as people eventually learn to style elements from an external stylesheet.
I certainly learned HTML in the days of table-based layouts and font tags, so maybe I am underestimating their usefulness as teaching tools. But I think driving home the point that HTML isn't layout early will pay dividends later.
Actually, I think the OLD way is harder for a new person. Perhaps you don't see it that way because you're used to thinking in old patterns. It's like this almost-retired DOS/QuickBasic programmer I work with sometimes might say: "Programming is so much easier to understand when all you have is one file and you just read down the file from top to bottom." Most people would agree it's not best to learn programming by starting with QuickBasic.
So why is the NEW way easier?
Because it separates concerns. Content and presentation are neatly broken into separate places.
You can start by teaching basic markup with <h1>, <p>, <b>, <div> and all of the basic tags. Give them a chance to understand the basics by creating HTML that Mosaic can display just as easily as IE8 (OK... bad example probably... you probably have to enable some sort of compatibility mode in IE8 for that ;-)
Once content has been mastered, move on to presentation. Show them how they can edit a separate file (the CSS file) and change the presentation of the entire document (or website) without ever touching the original file.
Now THAT'S simplicity.
Definitely do not teach outdated methods. You used to teach in just one step, HTML with styling tags.
Now, just teach in 2 steps. First teach a few basic semantic tags such as headers, paragraphs, and lists, then teach them how to make a stylesheet to style those. Then move on to more tags and more advanced styling from there.
how would you handle a client who wants you to implement a website layout that looks horrible and is wrong in many many ways, when they absolutely think it is great, really "different" and cool and since you are a programmer, you don't know anything about design.
i have tried arguing, reasoning and not caring, but it pains me physically to think that i should put that online... any tips or experiences would be great! thanks.
update: things are even a bit more complicated, since it is not just any client but a business partner with a great business idea, that i want to be part of...
Craigslist.com is one of the most visited websites on the planet. Yet its UI is appalling by most modern aesthetics.
This isn't a technical issue, but a business issue. You need to sit down with your business partner and put forward your point of view convincingly. If you're going to work with her in the long term, then you both need to find a way of resolving issues and coming to a compromise. Look at this dispute as a warning sign about the business relationship.
I've some experience with what you describe. I usually try to convince them their design is not as good as they think. Things like usability, navigational structure can help you in the argument. I've noticed that showing some heatmaps of how people look at websites can have a nice result. "I never looked at it that way"
If they however insist on the bad design, you have roughly 3 options:
Politely tell them to find somebody else to create the ugly site for them.
Make them sign a document that states that you strongly advised against the design and that they cannot hold you responsible if they get bad results or comments
Bow your head and build it.
Option 1 can hurt your reputation just as bad as option 3.
Option 2 sometimes convinces the client that they might be wrong after all as it is now written on an official looking piece of paper they have to sign. But a least ensures you can work with a clear conscience; you warned them, they wanted it anyway.
Good luck :)
He who pays the piper calls the tune.
Depends how much the coin matters.
Managing difficult clients is something you need to come to terms with, as a freelancer, or any sort of sufficiently experience professional.
If you don't like the design, you can have a simple thought: Do I need this client? If not, drop them. If you do, then just accept that you don't always get things your way, and deal with it.
If you don't want your name attached to the work, you can easily come to that compromise.
Sometimes you need to make moral choices about clients as well; in this case you just have a subjective art choice; I think it is easy enough :)
I have had some cases as you describe. Just keep in mind that you are creating something for your client, it's the client that will work everyday with the application and it's the client that need to be happy with it, not you :)
There have been a lot of answers that boil down to:
Just do it for the $$$
Do a mock up of something better
Run a usability test
Run like hell (but politely)
All of these assume that:
The design really is bad
You are objectivly approaching this project
Please don't hear what I'm not saying: I am not saying your premise is wrong.
First, I am saying its worth considering that it may not be that bad. There are a lot of very successful sites out there that drive designers nuts. If it doesn't satisfy a need, it won't matter how well its done.
If you want to be a part of this than you need to look at the business plan first, and see if its valid, and if the site will fulfill it. If either one of those is a no-go, than fix those problems first.
Second, ask your associate if (s)he's considered other designs. Ask for the sites they used to come up with what they want, and ask what else they've considered.
If they give you something, look at what makes those good/bad and see if between the two of you you can come to a better design.
If they can't, then tell them that with some work there may be something better and work together to create 3 or 4 mock ups. Then whip out the usabilty test. Even if you've done them before, I highly recommend reading what Jakob Nielsen has to say about it over at http://www.useit.com/alertbox/
Since this seems to be a business partner, just doing it for the money and/or running like hell doesn't seem to be an option. Working through this with a little more give and take may help, but if you can't come to an agreement, then you probably ought to leave.
Ask users that match targeted audience
Why don't you create a mockup of a particular part of this app/site and try asking a few people that represent the persona of the product. The targeted audience. Give them two possible choices and let users decide what will make business value instead of you or the client.
Be careful since the first thing I would do when coming to such a website is to look who's the webmaster that produced that site. And then if I would see your logo below it wouldn't impress me. It's not for your good reputation.
So as a professional in that area, I would try to discuss the design with your client, offering him your knowledge about good website design, since that may be also part of the service you're offering.
If you really need the money, just do what he wants and take the cash. Avoid your name appearing on the site anywhere.
If you have other work lined up, tell the client you think he would be better off with a different designer that can meet his needs and say goodbye.
My experience of this kind of client tells me they are a royal pain the arse, with endless tweaks and adjustments to the design. Get out while you can.
Do it. In your own time do your own version - as you want it to be great, which you do as you have a stake in it (you want to be part of it). Show them the better idea. Make them buy into it by making them feel part of it, not that you have done it behind thier back. the idea just came to me and I done it. If they don't like it tough – you could never have won. However they might just be impressed at your effort and/or initiative.
I'd say do it but put nothing identifying you or your company on it, and keep it the hell away from your portfolio. Also have very explicit conditions around ongoing support for it.
Maybe you could bring in a third party, someone whose opinion on design and suggestions for improvement your business partner would respect -- maybe a graphic designer or a web usability expert. That way, you might be able to salvage this business opportunity without alienating your business partner.
I agree with others. If you don't need the work than politely decline. If you do, release what the client wants and make them pay for every tweak after launch once they realise the design sucks.
Perform usability tests. Create a mockup that's fairly close and get people involved from the target audience. If they are a designer then they should understand that this is a sensible approach. Be careful to introduce it as best in both your interests.
The key is to get independent feedback. That keeps you sweet with your business partner and you also get a good design.
If it's a bad design and it's being pushed, then it's someone's "baby" and you can't touch it.
It won't matter how good your alternative is. It won't matter if you can point to the exact same site in, "Web Pages that Suck." It won't matter if senior executives quietly say, "Wow - I really like the alternative - it makes us look Fortune 500!" It won't matter if you bring surveys, focus groups, or if Jesus, Himself, shines the light of truth on your alternative and blesses it: you'll be branded as a, "non-team player," and the cruddy site will STILL be posted.
Then, in 18 months, after you're gone and the three people who were hired to replace you EVENTUALLY cough up a site with minor, almost embarrassing, changes that actually make the site resemble an ad for adult incontinence products, you can come back to this post and say, "Hey - thanks. You... were right."
I want to add an Link to my question:
Storing Password in Databases in plain text vs Customer Needs
In some cases it is the same issue. There are customer needs that are not acceptable. the answer provided in that question maybe help you find a way around that problem.
I think I've worked with this person before, when a university website was being designed by committee. We had two people come up with designs, and the initial vote went 12 to 1 ... the one who was ahead was done by a professor of commercial art, who couldn't care less if you didn't like his design. The other one, though ... she had to come out and defend every little aspect of her design. The revote was 1 to 12, as I refused to change my vote.
Luckily, three of the people from the graphics department came up with a new design, and presented it at the next meeting, and everyone agreed it was better, so we were able to torpedo the blinking splash screen and George Washington's hair design.
Anyway, the point is -- you have to find out why she prefers her design, and then come up with something that takes each of those points, but doesn't suck. Unfortunately, it might take someone with design experience to manage to put it all together -- but if you're planning this to be a business venture, it might be worth spending some money on.
Here's my suggestions:
Why is the design bad? Make sure you understand why before you get into this conversation. Remember, there is some business goal behind having a website. Understand that, and use it as your point. If you don't know what the goal is, ask. If they don't know what the goal is, help them figure it out.
Offer alternatives. Point out the positives and negatives, and help them understand what the tradeoffs are.
Mockups and tests. If you can, mock up the alternative, and let them see the differences. Get potential users to try them out if possible. If not, at least have the customer use the mocked-up website as an actual customer, trying to fulfill an actual scenario.
Good design is the design that will meet the stated business goals of the customer (assuming that this is a business website).
Also, understand what your job is. Is your job to help them solve a business problem, or to implement a specific solution they have in mind? Understanding their expectations of you may help significantly.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Soon I will need to give a presentation on my honours project for the engineering faculty and a large group of engineering and technology students at my university. While all the the people attending will be technical-minded, not all of them will be programmers and most will be from other engineering disciplines.
I have given presentations before, and I am confident speaking to a crowd, but I realize now all the presentations I have given before have been to fellow CS/SE majors and teaching staff. I wonder if my presentation style assumes that I am presenting to other software geeks, so they will know what I am talking about and I can put on a more interactive demo involving the audience.
My honours project isn't terribly complex or theoretical, I have a prototype C# Winforms app but it is designed to be extensible and operate with different data sources (ODBC or WS) in the future, and some research to how it could be extended with a rule engine and DSL and turned into a marketable product. The organization that is testing my prototype is saving tens of thousands of dollars a year by automating a critical business function.
I had planned to show off how extensible it was by some live coding and UML-style diagrams. I really enjoy doing demos and live coding but I don't know if that kind of presentation will be as accessible to non-programmers, and I am worried if I get too geeky and technical I may alienate the audience and judges.
What are the effective techniques you have found to present software projects in a way that is also interesting to non-programmers
When I was working on my doctorate, the faculty gave us this rule for seminars - and it has proved very useful since:
Tell 'em what you're gonna tell 'em. (E.g., brief introductory problem
description and results abstract)
Tell 'em. (E.g. technical details comprising the bulk of the time)
Tell 'em what you told 'em. (E.g. brief summary and conclusions)
Open the floor for questions.
In your position, I would take about 10-20% of your allotted time to do #1 in a largely non-technical way. So you might describe the business function your code automates, why that's important, what things were like before and after applying your solution, how it's saving money, that kind of thing.
Then I'd launch into a highly technical discussion aimed at the CS/SE crowd. Even if the rest of the folks don't understand it and their eyes glaze over, your introduction at least will have given them a sense of what it's all about, and they might recognize a bit here or there.
For the third part, I'd briefly recap the problem and describe how you solved it in non-technical language, and then do your live-coding extensibility whiz-bang demo. Even if the non-CS/SE folks don't understand the demo, they'll see eye candy flying by and your professional peers and faculty all nodding and smiling, so they'll think it's cool.
I once attended a seminar by a guy who won the Nobel Prize for applying chaos theory to chemical systems. He applied this approach, so even though all the non-theoreticians like my fellow organic chemists and I were all completely out of our depth, the fact that the theoreticians were all excited left us feeling like it was a great seminar even though we didn't have a clue about what he'd said.
To appeal to both audiences, I sometimes give the technical explanation and then follow it up with my "in English, please" explanation. CSI and other dramas with science in them do this all the time, to good effect.
In other words, [insert plain english explanation here].
Lets attack this as a refactoring problem.
ie Instead of adding more to your presentation, Is there a way in which you can take stuff out?
For example I don't think showing off that your demo App can use multiple data sources is essential, much less grants for you to program right there during the presentation.
I know it took care in the design of your app to reach that point, but still most people are more interested in the OUTPUTS not the INPUTS of an app. And even more in the BENEFITS of said app.
Some guiding points:
Make the presentation about them. If the audience has felt the pain that your program solves, remind them of that pain. If they are other researches like yourself then ask them to put themselves in the shoes of the organization you helped.
Compare the old way vs the new way of doing things. Why is the new way more efficient? Will it lead to more sales? will it reduce inventory? or save money? Will someone lose his/her job because your solution makes his task irrelevant. Note: When making technological presentations I've observed is important to address what happens to the people that was doing the task previously. Fortunately most of the time people don't lose their jobs, in most cases the same people can manage a much larger volume of work thanks to
Technology.
Show results. What are the real results your demo company has observed?
Use meaningful visuals. If you could make some animations that explain your algorithm even better.
Tell your point at the beginning and the end. Most people will forget what happened in the middle so make sure to tell the most important thing at the beginning and the of your talk.
Practice, Practice. Yeah it sounds ridiculous but do your whole presentation in front of a mirror or video recorded at least twice. The more the better.
Don't give one of the most important presentations of your life without a rehearsal.
Breath and be positive you will do fine :-D
PS: My suggestions are derived from this webpage. It has guided me several times:
6 Stimuli to reach the old brain
You're already working on knowing your audience, which I think is awesome, you just need to take it a step further, and ask yourself, if I were x person in the audience, what would I get out of this presentation.
I'd question the validity and how much effort should go into the technical/coding demo, if the group you're presenting to is never likely to use your specific implementation. It may be more important to portray how you approached the extensibility, so that you garner ideas within the peers on how they can approach it in the future, as well as hit on points throughout that are important to all of your audience members, and maybe shortcut the demo a bit to just show that, yes, indeed it does work.
I don't know about you, but personally I've always got more value out of these types of presentations based around how the project appeals to everyone, how you are managing to save tens of thousands of dollars per year for this company, theoretically why other companies might want to use it as well, what is the market and other factors, what were the giant technological hurtles you had to overcome, even if it's a simple project, there were things you must have thought about ahead of time to avoid and prevent you from getting backed into a corner.
I think if you're a really good presenter, and the purpose of the presentation is to be broad and appealing to the entire group, and not a talk on the chaos theory and application to chemical systems, which has that stated purpose, you should appeal to the lowest common denominator of the audience, and the entire audience can be entertained and appreciate what you have achieved at every step along the way, and to do this, they don't necessarily have to understand every step taken either.
I've been in the same situation
(presenting a software engineering/image processing/recognition project in an EE faculty competition).
Start with the issue (the problem)
Then the background (a BIT of technical background)
The solution:
Start with block-charts (all engineers read those)
Then explain the technologies and how briefly - how complicated the implementation was
(don't underestimate the complicated part - otherwise you may make your work seem to simple to engineers from other fields - they won't appreciate your effort)
Results:
Show short visual examples (try to make them intriguing)
(short code examples can go here)
Short user interface demo
Show impressive graphs
Bibliography, thanks, possible future improvements/research
Questions (if the forum is large, tell them in advance that the time for questions will be at the end)
General advice:
Practice presenting (over and over)
Leave 45-60 seconds per slide
No more than 5 points per slide
1 line per point
Add jokes
No animations except for demonstrating complicated issues faster
Use clear fonts (Ariel or Calibri for regular text, 1 different font for titles)
Use high contrast colors
(bright on black or dark on white if you must - no dark on dark or bright or bright)
Well first of all, I would suggest talking to your faculty advisers about what they expect from your presentation. If there's any question about how you should balance technical details understandable to only CS people versus more general concepts understandable to the larger audience, I think it would really help to get input from those who will be evaluating you.
One thing I really like to see from a presentation is a "take home message". What is the one thing you want everyone in that audience to remember long after they've left the room? Tell them the take-home message at the very beginning. Tell them you will spend the rest of the presentation explaining why they should care and why they should believe you. Even if people get lost in some of the technicalities, if you at least drive home that one message, you've delivered one thing to a lot of people.
Another suggestion: don't forget about format. Presentation slides should be readable from anywhere in the auditorium/lecture hall. Don't overwhelm people with too much text on one slide. Keep bullets short and easy to scan. Do you want people spend their time reading your slides or do you want them to listen to what you have to say? Don't use acronyms, but if you must, explain what they mean--and put the definitions on your slides--unless you are sure they are common knowledge. If people are sitting there wondering what the heck that acronym means, they aren't listening.
As to whether you should show actual code or do live coding, my gut feeling is that you shouldn't unless it's absolutely critical to the point you're making. If your project were actually about some coding construct (e.g., if you had invented the concept of an "extension method"), okay, it would make sense to get into some actual code. But it sounds like the significance of what you've done is definitely up a level from that. You might want to show how little code it takes to, say, hook up a different data source, but I wouldn't actually get into walking through the code itself unless you feel you can't make your point otherwise. One thing I probably would like to see if I were in the audience is a demo of your code in action. Show me what is does, and tell me why that's cool.
I hope it goes well!
Here is my advice:
Be clear who your audience is and what your message is - Are you trying to impress six faculty members who are marking your project, or proving you can entertain the whole audience.
Have a Contents page early on - that way the audience know what to expect.
Put the geek stuff in an appendix to your main presentation. That way you can dip into it ,for questions, but you will not loose the main point of your talk.
Make sure your presentation flows and tells a story - limit slide numbers and don't clutter them e.g. project goals,possible uses, design challenges, software choice, what you did (limit techie), results (demo), results and limitations, next steps, questions.
Have a Conclusions page at the end -- make sure you circle back and cross refer to your original contents page.
Leave 15-20% of your time for questions. This will reveal what the audience is interested in, and allow you to display a deeper understanding of the topic i.e. only do live coding if they ask for it.
Rehearse out loud even if you feel stupid doing it.
Good luck.
A few tips
Use a common technical language. only use terms that the hearing will recognize.
It links what you expose yourself, with examples recognizable by the audience.
you can also read these great articles.
11 Top Tips for a Successful Technical Presentation
Tips for a Successful Technical Presentation
Bye.
Mix and match some topic everybody know. It has helped me to theme slides with images ranging from the Divine Comedy to the Simpsons I don't know how formal is your presentation but it's a common constructivist technique to hook on something your audiente already know to show your point.
I once attended a presentation of Larry Wall where he explained Perl 6 features using examples from golf mixed with the Lord of the Ring.
What I do is to talk analogies, try to convert to real world the terms you are explaining.
BTW, Why are you talking about software tech aspects to non tech people?? You have to target the content to your audience first. Who is your main audience?? The techies or non techies, choose one.
Regards,
I'd be inclined to not use code (unless you actually have to), and use some form of generic (and straightforward) pseudocode.
Also, if you are doing the talk with prompt cards, put 'Breathe!' at the top of the cards. It helped me...
Focus on the user interface (aka how it makes their lives easier) and how it is different from similar products (why they should listen.)
I think Simon Peyton Jones gives excellent talks. See the How to give a good research talk section on this page. In particular, check out the video of his talk about the subject linked to in that section. You can find other videos out there of his talks on Haskell, functional programming, etc. to see how he practices what he preaches.
Please listen to the following podcast : Manager Tools - Presentation basic
It will cover all the basics you need to do effective presentations.
Now when doing project presentations do the following:
Create a High Level Architecture model ... see this model you can probably do better (note: the model image is from my blog.).
Create a High level requirement list
Create a application workflow process diagram (once again pretty colors, arrows and blocks). This model will show how a user is expected to work with the application in order to solve its main task.
In order the present the application first show them the requirement list and talk about them, then the high level architecture and finally the application workflow process diagram which can be followed by a live demo.
The most important rule is to present at a fairly high level with lots of diagrams and models to show what you are talking about.
While designing my site I am constantly faced with the issue of whether its ok to TAKE ideas and designs from other sites. In some cases there is no distinction in certain aspects. Is there anything ethically wrong with this? Is this expected in the design programming community?
Depends on how much you 'steal'.
Code
If you're ripping off the whole design, then its a bit dodgy. If you like (for example) the Stack Overflow concept of voting up stuff, then steal the concept and use it in a different manner. If you want to know how say the orange highlighting of the up-voted items works, then look at the code. But don't do both and steal both the concept and the design, you'll just create a clone.
Due to the way different web browsers treat CSS and the like, there are often only a very few limited ways to do a particular thing (3-column layouts, etc.). It seems fair enough to blatantly copy in these cases where there is a common way of doing things. Where its something unique, and there's many ways of doing it, it seems a bit more off to blatantly copy.
Graphics
Ripping off graphics - not so okay. Images have been around a lot longer than code so copyright law, etc. probably suits them better. If nothing else you have to contend with possible watermarks or other metadata to identify the original source. It's very easy to check for image stealing, less so for code within a larger block.
I'm a coder, not a designer so what I tend to do is borrow graphics that I like just while mocking up my web-app for internal use. Does that seem fair? I'll change them for newly-designed or paid-for ones before going live. At least that's the idea, though it could be far too easy to forget and use them by accident.
That's the way it works in the newspaper world (well it used to, not sure now with the advent of this there Internet thang): You download as many graphics as you can bother waiting to come over your 57.6k modem; you only pay for the ones you actually publish.
Oh, this is a hard question.
On the one hand stealing is wrong, on the other hand you are obliged to save you employer money by solving a task quickly.
My only advice is:
If it feels wrong in your gut, you probably stole too much.
I think most designers and developers draw a distinction between 'creative inspiration' derived from someone else's work and blatant plagiarism.
I wouldn't think twice about peeking under the hood to see how someone had done a particularly nifty javascript effect, or implemented a tricky piece of css elegantly, but I'd find it distasteful to blatantly cut and paste that same code for use in my own development.
I'm not learning anything by just grabbing and reusing - although I think it's fairly standard to have the same code to hand as a rough scaffold from which to explore my own way of implementation. I think that's the way a lot of people work.
I am a web developer, not a designer. As such, I have a sense of taste, but not the ability to come up with something wholly on my own. As a matter of ethics, everything commercial or with the expectation of serious traffic that I do, I will hire a designer. They need to eat too, and there is something wrong with making money off of others work and not compensating them for it.
If it is small, personal, or an internal throwaway type thing, I will rip off things like color scheme and/or layout. Technically you could say this is stealing, but I think of it more as "imitation being the sincerest form of flattery" thing. I don't feel that bad about it since there isn't really any money to be made in it.
I think its ok to steal ideas, but not to steal code.
This is how a lot of design is accomplished. Except it's obscured by lots of lifts, not a single wholesale lift.
Stealing resources (graphics, code) is not really OK if they're not specifically marked as free/open/creative-commons/etc. Stealing design and layout is a bit sketchy if you're just xeroxing the same layout using your own code -- using someone else's design as a starting point is one thing, but don't just recreate their design verbatim. Stealing snippets of code for specific bits of functionality is fine (IMHO) since even if you grabbed a reference manual to learn it from scratch you'd end up with the same thing. (Think: javascript for changing an button image on mouse-hover)
Having said all that, imitation is the sincerest form of flattery. Don't steal resources, but using other sites as "influence" should be OK. Or, if in doubt, ask the owner of the site you intend to use as reference/influence.
It's almost like everyone answering this question forgot what it was like to work with web pages between 1995 and 2002 or so. Stealing was a way of life for tons of designers during that period. The key was, and still is, to take only what you need, and to make sure that you understand it well enough to make it from scratch the next time. Who knows, you might improve something in the process.
There's an old saying I was once told: Good designers create. Great designers steal.
That said however, you should never blatantly rip off code if you can avoid it. Look at it, understand it, rewrite it (or improve it, if possible; even if it's only something like using what you find are better variable names) but never just copy and paste. Same goes for layouts; take the layout and modify it to suit your needs - it might end up looking similar (look at all of the Basecamp-style clones out there as far as UI goes) and that's no big deal at all; plenty of sites look similar. The key is to go into the situation looking for inspiration and not some code to yoink. If you can use the code as-is or with little modification then you really have no problems, but it shouldn't be your intention to find someone else's code and rip it off.
It's a sliding scale. Borrowing just an idea is one thing, if you're incorporating it into the rest of your existing design, not just wholesale copying an idea. Snagging a idea for a design element is fine, copying a whole design exactly is not. As you borrow more and more of a design, it gets into the not acceptable category. Copying directly is also another factor. If you see something you like and reimplement it for yourself, that is typically fine. But doing a direct copy of code, images, or css not so much.
For the most part, ideas are fine to take and implement. If people couldn't take existing ideas and expand them or re-implement them, we'd never have gotten out of the dark ages.
If you feel the need to steal code because you can't code HTML/CSS well or don't have an eye for design, steal from a place that explicitly permits you to use their design/code, like OSWD. In general, stealing HTML is fine, but ripping off CSS wholesale is a no-no. Just because you can easily view the CSS source doesn't mean that it's ok to just copy and paste it.
Don't steal graphics, period. Especially things like photos and logos and icons. If you need that sort of thing, purchase stock photography or take your own photos.
When in doubt, ask the owner of the site.
Stealing code or designs is immoral and in some cases illegal.
Taking inspiration or copying functionality is less of a problem. For example, at some point in time someone realized that putting a "Forgot Password?" link next to all login forms is a good idea, now everyone does it. It's not theft it's just replicating a good idea.
I'm not a web developer, but I might have some insight that will help as well. My team has created several applications that have served as the starting point for other applications delivered to various customers.
The successful derivatives were those in which the developers took the time to learn the architecture and why things were the way they were. They then took the more crusty parts and rewrote them and in general expanded and improved the architecture.
Invariably, when a team simply took the existing project and tried to 'brand it' or copy it for a customer without actually figuring out the systems, they either created poor implementations of the extensions or had the project fail outright.
I realize this is a bit off the main topic of the ethical issues address by others here just fine, but my bottom line is that pure theft usually costs you more time than it saves.