Smashing Magazine has one of the most useful articles on Design and Presentation. It is full of practical advise from top designers:
We’ve asked five questions. One single text line would have sufficed.
- 1 aspect of design you give the highest priority to.
- 1 most useful CSS-technique you use very often.
- 1 font you use in your projects very often.
- 1 design-related book you highly recommend to read.
- 1 design magazine you read on a daily/weekly basis (online or offline).
In the end we’ve received more answers than we expected. The results - over 80 CSS-based tips, design ideas, suggestions, fonts, design-related books and online-magazines - are listed below. It’s interesting to know, how designers work their magic. It’s interesting to know what you can actually learn from them.
Personally I find the first two more interesting, but I’ll take a look at some of the design resources suggested. Read the whole article!
Greg Beaver has posted 10 rules for running an open source project:
1) If you must criticize, criticize with a gentle and humble tone: I can’t emphasize the importance of this rule too much. It takes courage to approach an open source project and to suggest that these people who have been around doing this for much longer should change something, especially since chances are the bug report/suggestion/whatever will sound stupid if the user is an outsider. In addition, users who are derided have been known to go to extraordinary lengths to “get back” at the project that shunned them, even if no shunning was intended. If you have to mark a bug as bogus, I’ve found it is not only nice but necessary to apologize for the inconvenience, and to provide a complete explanation. If you can’t provide one, re-examine your assumptions: maybe there is some merit to the bogus report. In my experience, nobody complains if you bump a bug to a feature request and pop it to the next release cycle. If you have to say RTFM, don’t. Just post a link to the manual page and a brief sentence describing the technical details of the solution the user needs to use, without implying anything about the user’s intelligence, preferrably[sic] without any emotional content. You never know, this user may turn out to be your most valued developer a year or two down the line
I cannot agree more. I have seen several instances where the casual disregard of a bug reporter has caused very hurt feelings. If you want to be important part of an open source project, or any project really, all of his rules are very important. Read the whole thing.