This is a website mockup I designed for my friends car shop. I know some basic html/css and the only other site I've coded is my portfolio site which was extremely basic. I'm having some structural difficulties with this. I'm not really sure how to handle the logo since it's overlapping the gray texture in the header with the social icons. I was making a separate wrapper for the header and content, including the logo and navigation in a <div id="nav"> but how do you get an element in a block level element to overlap a separate block level element? I would really appreciate and help/suggestion you guys have to offer.
That's okay. I made this design and now I'm trying to code it lol. Unfortunately my design abilities far exceed my coding knowledge, which is why I'm trying to get better at web design and I figured working with a friend would be a good opportunity to "practice".
I can extend the logo outside of the parent with that technique? Don't block level elements expand with their content, though? so wouldn't that just make the parent taller and still line up the top of the logo at the top of the parent which is at the bottom of the header div? Sorry if that's confusing. I'm a "peon" as my account says, so I'm not very good with the terminology.
First step for me would be figuring out what the elements are, pretending their visual appearance did not exist... of course, starting from a goofy picture before you have semantic layout of meaningful content is broken thinking -- hence my total distaste for PSD jockeys and the useless crap they vomit up and have the cojones to call a 'design' when they lack any sort of knowledge about markup, CSS or accessibility. Every page should have a H1, and that H1 should typically be the same across pages since EVERYTHING on the page is a subsection of it -- your H1 should have meaningful text in it, even if you're going to use a image/logo instead... Which in this case, I'd use something like: <h1> Miltner & Sons <span>Auto Care</span> <small> <span>-</span> 631-261-0007 </small> </h1> Code (markup): The span with the hyphen in it is there for CSS off appearance. With CSS on I'd use text-indent to slide the hyphen off the screen, style the text as close to that logo element as possible, then use that span as a image replacement hook, absolute positioned over the text with the image/logo as it's background. A negative bottom margin on the H1 could then be used to remove it's flow so that the menu and social links can be placed. The menu is then a simple UL, and I'd probably use a UL for the social icons just in case you someday want to add more of them. I'd probably axe the nearly invisible and far, far below accessibility contrasts text next to the social icons. People know what those are now, so there's no reason for that text to waste time/space on the page. The banner image below that is just a content IMG ...though those three dots indicate it's a image rotator, something I loathe on websites as a total waste of bandwidth and space that does nothing to actually tell people about the business... much less how they do NOT work well with dynamic layouts, which is all anyone should be making in this century. But that's mostly the flawed stupid photoshop jockey approach of drawing a goof assed picture of a website saddling you with "not viable for web deployment" concepts that can be entirely explained as "but I can do it in photoshop" idiocy. What should be done is writing up meaningful content, marking that content up semantically, enhancing that content and markup using CSS to make your screen layouts (yes, that's plural -- don't forget the new media queries) as well as any other targets you want like PRINT or HANDHELD, and THEN you bring in the artist to make graphics you hang on the layout. Bitter pill for the art *** designers to swallow, but people do not visit websites for the goofy graphics you hang on them; they visit for the CONTENT. Starting out with a goofy drawing of what you want a website to look like usually results in a piss poor broken inaccessible train wreck that is little more than artist preying on the ignorance of people who don't know any better. All flash, no substance. Like a lot of sites, I suspect the 'about' or 'services' page should actually be the home page, instead of wasting visitors time on some useless splash page with nothing but "gee ain't it neat" animated effects. Get the meaningful information (like services) as the first thing visitors land on, instead of some pointless images and their associated javascript bloat.
There's actually a lot of really helpful information in that post, so I thank you for that. You're right about most of what you said, but the main objective of your comment didn't have to be to fire away at "PSD Jockeys" and how bad everyone is at web design. I'm actually a Print Designer, so I'm obviously a bit out of touch when it comes to the best practices of web design and usability. That is why I came here in an attempt to get better at them. You seem to be the kind of person that has the knowledge and willingness to spread it, which is what I'm looking for. I'm at work right now, but I'd like to serve-up some questions I have for you when I get a chance if you're willing to answer them.
Come up with some questions, feel free to fire away -- and don't take my comments personally -- I'm a New Englander, we're insulting as a matter of habit. When I tell people "throw it out and start over from scratch" what I'm really saying is "Yah cahn't geht theyah frum heeyah..." I also come from a print background, and am something of an artist -- and much of what I just said was a bitter pill to swallow when I started doing websites seriously about a decade ago; that really all the fancy extra bits and doo-dads get in the way of delivering a useful message to the end user; AND more importantly, a lot of what you can do be it for print, or in photoshop, runs entirely contrary to designing a practical accessible website. When thinking in photoshop you're thinking in pixels, when thinking for print you're thinking picas, inches and mm - and in doing so you think of a fixed sized canvas. Accessible websites are the exact opposite! They need to be dynamic width (semi-fluid at the very least), in modern terms you have to think "how can this layout adjust the number of columns as the width narrows to tablet or handheld size?" -- fixed width and fixed height elements are the antithesis of accessible design. Fixing the width just means it's too big for netbooks and too small for modern desktops... fixing the height means the auto-wrap for text probably breaks and if you bother using dynamic fonts it just blows out of it's containers... Even simple things like font sizes -- you declare your fonts in PX, you're pissing all over accessibility unless they are massively large (16-20px or even larger depending on the face) and content fonts (your normal flow paragraphs) should NEVER be in PX. %/EM is there so that your content text will automatically adjust to the users preferences instead of them having to dive for the zoom just to use your site. With print it's easy -- you know what size it's being printed at... the only thing we know for sure about the Internet is we don't know who will come. With the plethora of screen sizes, resolutions, and default font preferences it's an entirely different world of building things; treating it like print is just the road to failure -- and that includes drawing a pretty picture of a website instead of making semantic markup that's usefull with CSS off and then progressively enhancing it with CSS to create things like the layout. That's the point of HTML -- to say what things are in a device and target neutral manner. Plays to the point of CSS, saying what things look like for specific targets... What drawing a pretty picture before you have either of those has to do with making a website is anyone's guess; It's an impractical approach that for some unfathomable reason has taken over web development. You look at the major successes of the Internet, and they're not exactly a visual tour de force -- google, amazon, e-bay, facebook, slashdot; Do you really think they hired some photoshop jockey to make their sites? HAH. Sure, the stuff the artists who have the cojones to call themselves "designers" is often way more attractive and flashy -- but if the end result is useless at delivering the information people came to the website for, what good is it? That's why the graphics heavy websites are usually reserved for designer's personal websites, small businesses who've been led down the garden path because they don't know any better, or massive brick and mortars for whom a website is an afterthought. Best practices for web design are simple -- content first, semantic markup (numbered heading tags for headings, logical heading orders, paragraphs for paragraphs, lists for lists, etc, etc... think grammar!), dynamic layout to adjust to many possible resolutions (within reason), dynamic fonts that auto-adjust to user preferences, color contrasts that meet accessibility minimums (no grey on grey or blue on red), and no images/design concepts that shoe-horn you into a fixed width or fixed height. You start out with a minimum accessible base (HTML around content text and content images), and progressively enhance it with layout (CSS), presentational images for that layout (CSS background images), and then enhance the functionality as desired with javascript (which should be used with an eyedropper, not a fork-lift)... It's called progressive enhancement. ... and if you build with progressive enhancement, you get graceful degradation should the fancier technologies be missing, unavailable, or even intentionally blocked. Images and Javascript often fall into the latter category being slow, bandwidth consuming (especially for people on metered connections like our friends in Canada), or outright not trusted. A LOT of people don't trust javascript to just run; just look at all the folks who've downloaded the 'noscript' plugins for Firefox or Chrome... or people who use the built-in per-site script blocking in Opera. If I have time later today I'll toss together a quick example based on your image to at least show how I'd deal with that -- though it won't address the deeper underlying issues with that design.
... and here's how I'd code that: http://www.cutcodedown.com/for_others/ambivalentSoul/template.html As with all my examples the directory: http://www.cutcodedown.com/for_others/ambivalentSoul/ ...is wide open for easy access to the bits and pieces. Valid XHTML 1.0 Strict, would be valid CSS (as if there even is such a thing with 3 on the table) if not for some browser specific properties - oh noes, not that (Actually had a big argument recently with someone over using 'zoom' -- my response being "why is zoom wrong but -moz or -webkit is ok?") Tested working in the latest flavors each of Opera, Safari, Chrome and Firefox, along with testing IE 5.5, 6, 7, 8 and 9. Yes, it works just FINE in IE 5.5; and it took little or no extra effort to do it either! ...once you learn a few rules, you stop writing code that's broken It also gracefully degrades images off with CSS on, CSS off with images on, and both off. Again, graceful degradation through the power of progressive enhancement. As much text as possible is left as %/em, though a LOT of the design elements pretty much dictate using PX (boo!). I made it a 100% min-height layout as I was unclear if that was the intent or not... and I opened it up semi-fluid. 95% width gives a nice bit of padding at intermediate resolutions, 768 min-width (which is fed as width to IE6/earlier) is the narrowest we can go without the layout falling apart (which is where I'd have a media query trigger to change to a narrower layout for tablets/mobile), and the EM max-width means users of 120dpi or larger default fonts get a larger width to go hand in hand with their larger default fonts. I didn't do a perfect match of your images or fonts -- the fancy fonts I'd probably skip as a waste of bandwidth, or use webfonts for (I didn't recognize the one you are using)... the images I just belted out placeholders quick and easy for. I'm out the door right now, but I'll try to remember to come back and give you a section-by-section breakdown of the HTML and CSS so you can learn from the techniques I'm presenting... which will probably take me longer to write than the page did
Wow. I've already learned a ridiculous amount from your example by just poking around with Firebug. Now I get what you mean by giving the header a negative margin. I can't believe I didn't think of that. Goes to show I've got a ways to go before thinking like a true web designer. On the contrary, there are still quite a few things I don't understand lol. I'm going to try to replicate this best I can and I'll send any questions I have your way. Obviously you can get to them at your leisure. I'm very grateful for the time you're already put into helping me.