Hi I am very new to webdesigning, and i know almost nothing about it. Still, I run a website, and I really want a more professional look to my site. I don't feel like leaving the designing of my site to someone else, I've come to the agreement with a web design-firm that I will design my website with photoshop, and they will do the rest of the work. I know they will need specific details on how fast the slidingdoors e.g. should slide. There's probably a whole list of things I haven't thought of, so I was hoping somebody on this forum would be so kind to explain to me what is important to remember when designing in photoshop, and how to help the webdesigner-company better understand how I want my site. In advance, thank you!
Well, for starters, don't use Photoshop for design, it's NOT a web design tool no matter how many ignorant fools and sleazy scam artists claim otherwise. Dicking around drawing goofy pictures of what a website MIGHT look like at ONE resolution and screen size -- or even multiple goofy pictures of multiple sizes and resolutions, is effectively putting the cart before the horse and a completely back-assward approach to design and development. This is made worse by the fact that most of your PSD jockeys don't know enough about HTML, CSS, accessibility or emissive colourspace to be designing but two things. -- In fact, ANYONE who says to start out drawing goofy pictures in a paint program really has no business calling themselves a web designer! Start out in a plain text editor with your content or a reasonable facsimile and put it into a logical document order. You then mark up that content using a RECOMMENDATION doctype (HTML 4.01 Strict or XHTML 1.0 Strict, forget that idiotic halfwit HTML 5 garbage)... The next step being to create your layoutS using CSS, said layoutS (YES, PLURAL) should be elastic (adjusting to differences in default system font size by using EM's for everything you can), semi-fluid (auto-adjusting to the width, with a max-width to prevent long lines from getting too long to follow easily), and responsive (changing the layout by stripping out columns and re-arranging things using 'media queries' to fit the available width)... Then and ONLY then do you have any business going into the paint program to make the graphics you hang on the layout. A really GOOD layout being unobtrusive and not detracting from the actually important part of the page -- THE CONTENT! I've never seen a site that started out as a PSD or other picture format that wasn't an inaccessible train wreck laundry list of how not to build a website. It's just another of those things people do (like HTML/CSS frameworks, JavaScript frameworks, failing to extract one's cranium from 1997's rectum) that's broken methodology and does little more than piss all over the resulting page... no matter how "pretty" the result. If it gets in the way of accessibility and the user getting to what people actually visit websites for, what good is it? Bottom line, Photoshop is NOT a web design tool. Do NOT try to use it as such no matter how many halfwit drooling morons tell you otherwise.
^ Just wondering why you're so against HTML5, I am curious? And when you said plural layouts, what did you mean exactly? Sorry, I am a beginner. Thanks.
An in-depth explanation can be found in the link in my signature, So what's wrong with HTML5? But the short-short version: It re-introduces redundancies 4 STRICT was intentionally trying to remove, introduces all new redundancies with pointless code bloat, then has the giant set of brass to call it "semantics". The loosening of the structural rules is kind of just shrugging their shoulders and saying "people are going to write crappy code, oh well", and generally speaking as a whole it dials the clock back to the worst of pre-strict coding habits; this is hardly a shock given when the WhatWG created it and how even it's original creators admit they were just trying to make it how people were already making code as opposed to trying to introduce a BETTER way of making code -- the core of why it's main target audience is developers who never pulled their heads out of 1997's backside; as I keep saying, HTML 5 is crafted for the people who to this day sleaze out HTML 3.2 and until recently were slapping 4 tranny on it. Today they wrap 5 lip-service around the same outdated outmoded broken methodologies, then slap each-other on the back to celebrate how 'modern' they are. It sure as shine-ola isn't meant for anyone who actually embraced HTML 4 Strict, semantic markup, separation of presentation from content, accessible design, progressive enhancement leading to graceful degradation, or any of the dozen other improvements in development practices of the past sixteen years. The "how it's being done" instead of "doing it better" attitude explaining the whole "living document" asshattery and the fact that even internally they talk about documenting what browser makers are doing instead of telling browser makers AND web developers HOW to do things in a better/cleaner way. The LINK tag has an attribute named "MEDIA", the most common media stack being "SCREEN, PROJECTION, TV" which are all the same basic device; that's what I like to call the 'base layout' which when developing is what I send to browsers that dont know media queries (IE8/lower). Another target/layout would be "PRINT", which you might want to hide things like menus and fancy backgrounds so as not to waste the user's ink. That's another layout. Finally we now have media queries, which allow you to add/remove columns as needed from the layout depending on width, or swap out other elements. That's a whole bunch of different layouts from the same markup. A simple example of which would be by EWI website which is elastic, semi-fluid and responsive. http://www.ewiusb.com Which was developed using the methodologies I advocate (though it is showing it's age already), hence it for starters being 98k in 22 files, MOST of that being content. That's 13k of markup on the home page for 4.3k of plaintext, needing only 20k of CSS in 3 stylesheets for the entire site (which if I wrote it now would only use two stylesheets), and 11k of javascript (which is ENTIRELY the lightbox-type image effect). Despite those really tiny filesizes and only two 'core' stylesheets (that if I wrote it today would be 1 file) that single page has a whole slew of different layouts: "Normal" 96 dpi middle width (aka the "core" layout) http://www.cutcodedown.com/images/ewiUSB/ewiUsbComNormal96.jpg 120 dpi middle width (since it's elastic and semi-fluid, this took no extra code) http://www.cutcodedown.com/images/ewiUSB/ewiUsbComNormal120.jpg 800 wide to show the elastic and semi-fluid in action: http://www.cutcodedown.com/images/ewiUSB/ewiUsbCom800Wide.jpg and how it changes when the page narrows to 640/smaller (actually an EM breakpoint) http://www.cutcodedown.com/images/ewiUSB/ewiUsbCom640wide.jpg ... and how even smaller mobile devices still work: http://www.cutcodedown.com/images/ewiUSB/ewiUsbTinyMobile.jpg The semantic markup as the starting point also means the page is useful without CSS: http://www.cutcodedown.com/images/ewiUSB/ewiUsbComNoCSS.jpg Or even how it works with images off, since a lot of folks on metered connections disable images to save bandwidth: http://www.cutcodedown.com/images/ewiUSB/ewiUsbCom800WideNoImages.jpg Which is nice since that's pretty much what search engines, screen readers, braille readers, and a whole host of other non-CSS user agents (browsers) will "see". That's why semantic markup of the content (or a reasonable facsimile) FIRST is important and why the above process I outlined 'progressively enhances' the page; you take the content, you then mark it up, you then style it for layout, you then style it with presentational images, you then enhance it with javascript -- progressively adding to the page; that way should any of those fancy bits along the way be unavailable/blocked/missing the most important part of the page, the CONTENT is presented to the user in a useful fashion. The term for properly handling a missing bit of technology being "graceful degradation". If you progressively enhance properly, it should gracefully degrade all on it's own without any extra effort. It's also why there's the 'unwritten rule' of JavaScript: "If you can't make the page work without JavaScript FIRST, you probably have no business adding JavaScript to it." Multiple layouts, device neutral, targeting by capabilities and content needs not by device, all from ONE markup!
Keep the layers organized, export colors in .txt file, use slices, use .gif images, think how it will look when accesing from mobile,tablet,desktop pc....