propstm.net » Design

How to use RGBA + Examples

Matt — Wed, 09 Dec 2009 18:14:13 +0000

Today I wanted to talk about RGBA color a bit. Before I launch off into the post I first want to note that this will not work in all browsers. As RGBA is something for CSS3 you may want to check this chart to see if your browser of choice is supported. RGB color is a way of displaying color other than using hex values. With the CSS3 specification designers and developers get to take RGB one step further and define an alpha or transparency value. RGBA is a great new way that CSS3 deals with transparency.

Here’s a quick example of defining a value to red in both hexidecimal values and RGB

em { color: #ff0000 }           /* #rrggbb */
em { color: rgb(255,0,0) }

There are several sites that already use RGBA to create some very interesting and dynamic effects.  24ways.org uses RGBA to create a layered overlapping effect.  Other examples such as Sam Brown's site uses RGBA to once again create a level of depth, and after glancing at the CSS Sam uses RGBA to change the alpha value of many of his various textual elements.  In addition Dan Cedarholm, who writes at simplebits.com, and who spoke about RGBA as well as other CSS3 features in his talk on Progressive Enrichment using CSS3 at FOWA last November, uses RGBA for some of the textual elements on his site as well.

Below is a small bit of code i put together just to show how RGBA can be used. The page changes background color and alpha value when you mouseover the paragraph.

This is a sample paragraph that shows how RGBA works. This is a sample paragraph that shows how RGBA works. This is a sample paragraph that shows how RGBA works.

From my standpoint, the thing that I really like is the fact that by replacing a normal hex value with RGBA, I define a color just the same, however I’m also given the alpha value which seems as though it could be a jumping point to many great new uses. I think I may be doing a few more posts in this style, so let me know what you think. Hopefully this sort example helps, and don’t be afraid to leave a comment or reach out to me on Twitter.

Why Client Revisions Shouldn’t Be Allowed

Matt — Mon, 07 Dec 2009 12:00:27 +0000

This past week The Oatmeal had a post called How A Web Design Goes Straight To Hell. The post got quite popular, getting on Digg and became a trending topic on Twitter. After reading the comic and finding it quite amusing, one thing went off in my head; that post makes one thing obvious to me, client revisions are bad. Normally these revision occur after you’ve delivered the product to the client and they want to make “tweaks”. I’ll say I HATE that!

If you are doing your job correctly as a designer you a developing a creative brief for the client outlining a solution, or solutions to their problems. By the time deliverables reach the client they should meet all requirements of the creative brief. If the client is paying a designer to create something because the client cannot. The client needs to know that the end product will meet the creative brief and that the designer’s work is in the best interest of the customer.

Client revisions should not be needed if the project is planned correctly and all requirements of the client are addressed when the designer creates the end product.

Learning from Failure at ThemeForest

Matt — Sun, 29 Nov 2009 23:47:10 +0000

Last Friday I submitted my first theme to ThemeForest.net. Last Friday my theme was denied by ThemeForest.net. Being entirely realistic my theme would either be approved or denied. Considering this was my first try at the process of theme submission for ThemeForest I had more going against me, than for me. Failure would undoubtedly be a learning process.

When I found out I’d been denied, here is what I first saw:

“Thanks so much for taking the time to submit this template. Unfortunately, due to our current quality standards, your template has been declined. Here are a few improvements you might consider making before resubmitting:

1.This template is not aesthetic ready for TF and it will be very hard to be improved and get accepted. It required many improvements in term of design, visual hierarchy, typography, layout and its aesthetic quality.
2. You need to provide a more decent help file: http://blog.themeforest.net/site-news/building-better-template-documentation/
3. You need to provide the new wordpress GPL license within the download.”

That information from the email helped me greatly. ThemeForest has content about how to create proper documentation, and also information about proper licensing for WordPress. Had I not been denied, I would not know about those resources.

Failure allowed me to look for constructive criticism.

After I was denied I tweeted about it. By tweeting about it I found out people were intrigued. People wanted to know not only why I was denied, but what I had submitted people asked for screenshots. After sending off some screenshots and talking with a few folks the suggestions started coming back to me. Why did I code it for WP? Why not just a template? A template was honestly something that was something I didn’t even think of. I’d helped develop with a similar static version of the theme for a friend about a year ago. The reason I’d done it in WordPress is because the static version was clumsy, & my buddy liked it, but he had trouble updating his portfolio. Choosing WordPress, I was able to modify the static version and allow users to easily add or modify their portfolio using the easy to manipulate WordPress backend.

After looking at my work, being honest with myself, and thinking of my reasons, I concluded one thing; The portfolio theme I created works, but it is NOT for the TF WordPress section.

Drawing conclusions from my failure

First off, ThemeForest is a tough site to get into. There is a level of quality which your work must have in order to be accepted. Everyday work just wont cut it. Second, document the hell out of your work. If you work gets accepted, other people will look at your work, and the WILL WONDER “What the heck was this guy thinking?” Documentation helps answer anyone’s questions, and hopefully save you as the developer from answering those questions after the fact. Third, this is all a learning process. I’ve learned what NOT to do, now next time I can only work to improve.

Future of Web Design 09 – Drawing Conclusions

Matt — Wed, 18 Nov 2009 13:30:07 +0000

I had a great time today at Future of Web Design. There were a bunch of great speakers, great conversation, and great visuals. I was very pleased with the content presented and will surely take more than a few things away and use these gems with my work. Now i’d like to draw conclusions. I’m not going to review each individual speaker’s content, but instead I’d like to just outline the themes, concepts, and quotes which stuck out to me*.

From Dan Cederholm’s talk on Progressive Enhancement with CSS3:

None of it matters if it’s not there. – Make stuff beautiful for Safari and FF users, if people in IE can’t see it, it doesn’t matter.
Also from Dan’s talk I think i’ve come to the conclusion that transforms in CSS3 are amazing, if used in moderation.

From Daniel Burka’s talk on Feedback:

Feedback isn’t always easy to get.
Read between the lines, users who complain don’t usually want a solution but are simply helping you to identify a possible problem.
Negative feedback = Passion!

From Mike Kus’ 3-D Thinking Talk:

Design happens at any time.
Ban boring trends.
“Progress and innovation in design requires exploration”.

From Elliot Jay Stocks’ Designing for Modern Web:

Visually appealing is better User Experience.
Good design on the web is Important!
The nicer something looks, the longer visitors stay, and the more stuff visitors will read.
“Validation is irrelevant.”
Validation does not equal conformity to web standards.
Plan for degradation.

From Joshua Davis’ Keynote on the topic of “Space”:

“Clients are the problem.”
“If M.C. Escher was alive, he’d be a f**kin’ programmer.”
Drastic changes are not required for drastic results.
Through not knowing, trying will ALWAYS cause you to learn.
If you don’t ask, the answer is always “no”.
“If I’m not making mistakes, I’m not learning.”

*Stuck with me, and the ones I had notes from in my notebook.

The least important part of designing a WordPress Theme.

Matt — Wed, 11 Nov 2009 13:15:28 +0000

The least important part of designing a WordPress Theme is the header. There I’ve said it. It is the least important part for three reasons:

- It is the first thing anyone will see on your site. The header is also the thing that everyone sees on your site.
- Since designers know the header is the first thing everyone sees, they normally have preconceived ideas of how a header will look or fit in with the design.
- Because the header is first and foremost, that means you need to be spending all of your other time on the other parts of the site which should look as amazing as your preconceived header because a truly engaged reader should want to look at each part of your site, not just the content but the layout and design of the site that the content lives in.