March 25, 201511 yr Hello everybody, I'm a newbie Web Designer and I'm just wondering what's size I should use in Photoshop to do a single page mockup. Currently I'm setting it at 1600 by 1968 px. Thanks, Maxine Edited March 25, 201511 yr by Maxine
March 25, 201511 yr That will be ok, just bear in mind that it's getting very common to design in the browser, mostly because of responsive design. Almost all websites should be responsive. I still get some projects in photoshop though that I use as style guide but not set in stone, done this way your sizes should work fine.
March 25, 201511 yr Hello everybody, I'm a newbie Web Designer and I'm just wondering what's size I should use in Photoshop to do a single page mockup. Currently I'm setting it at 1600 by 1968 px. Thanks, Maxine Check out some grid systems, like http://unsemantic.com/ for example, grab the photoshop file https://github.com/nathansmith/unsemantic/wiki/psd-grid-for-unsemantic and build it based on that, using this grid, once you learn how to use it you will find it simpler and faster to design and develop websites.
March 25, 201511 yr Author Thank you for the answer I'm not skilled/quick enough with html/css to design in the browser just yet. Also I'm familiar with grid system generally making my own, but thank for the link I will have a look.
March 25, 201511 yr I am actually against designing in the browser because it is much harder to account for UX issues on the fly. My process is wireframes first, then conversion to mockups in Illustrator (desktop and mobile versions [tablet as well if the design needs it]) and then conversion to HTML/CSS. When designing in the browser I see far too many have the "good enough" syndrome where they don't push the design and UX because it is already coded and they want to move on to other things in the code. Yes it is harder to design for user interaction but those should be fleshed out in it's basic form in the wirefram stage and if needs be created in an isolated envirement (say codepen) and shown to the client for approval or have a design created for stages and then animated using the many tools out there to animate graphics without coding (https://facebook.github.io/origami/). Too many things get lost/forgotten/uncared for when designing in the browser.
March 26, 201511 yr I am actually against designing in the browser because it is much harder to account for UX issues on the fly. My process is wireframes first, then conversion to mockups in Illustrator (desktop and mobile versions [tablet as well if the design needs it]) and then conversion to HTML/CSS. When designing in the browser I see far too many have the "good enough" syndrome where they don't push the design and UX because it is already coded and they want to move on to other things in the code. Yes it is harder to design for user interaction but those should be fleshed out in it's basic form in the wirefram stage and if needs be created in an isolated envirement (say codepen) and shown to the client for approval or have a design created for stages and then animated using the many tools out there to animate graphics without coding (https://facebook.github.io/origami/). Too many things get lost/forgotten/uncared for when designing in the browser. The way I've seen it done is a developer sits with a designer and first they callaborate and sketch things on a whiteboard or peice of paper, then code out a prototype in the browser or somewhere like codepen. They prototype all the components so to speak. This was on a very large project with two very senior devs/ designers so it probably won't work on a small project. I've seen a few of the guys doing talks at conferences metion that they also work in this manner - This is how they work at Sky. I am also lead to believe the BBC develop in a similar way. I've never actually tried this approach myself but it must have some legs if some of the large media organisations and top devs are pushing it. i couldn't see this being a beneficial approach for a sole designer / freelancer, but more for larger teams working in an agile, continous delivery envieoment. If you watch Chris Coyiers course on CSS-TRICKS where he runs through the entire design build process for his site, he designed purely in the browser and I'm sure you can agree the UX on CSS-TRICKS is good. All that said I guess it all depends on what works best for you as a sole developer. A few articles on the subject: My thoughts don't necessarily match whats in these, but I think they are worth reading. http://www.the-haystack.com/2014/12/23/some-thoughts-on-designing-in-the-browser/ http://webdesign.tutsplus.com/articles/my-thoughts-on-designing-in-the-browser-vs-designing-in-photoshop--cms-23405 http://blog.teamtreehouse.com/responsive-web-design-in-the-browser-part-1-kill-photoshop Edited March 26, 201511 yr by rbrtsmith
March 26, 201511 yr Actually the UX is average at best, especially for tablet size. If he actually wire frames it out I'm sure I could be much better. Edited March 26, 201511 yr by cibgraphics
March 26, 201511 yr While CSS-TRICKS isn't the greatest peice of design in the world it is still far better than average at best. What aspects are bad exactly and how could they be improved? Looking for specifics rather than just should have wireframed. Edited March 26, 201511 yr by rbrtsmith
March 26, 201511 yr While CSS-TRICKS isn't the greatest peice of design in the world it is still far better than average at best. What aspects are bad exactly and how could they be improved? Looking for specifics rather than just should have wireframed. Not sure why you are hung up on this, but ok Font actually reduces in size for tablet/mobile making it harder to read. The font on the footer is horrible and hard to read. Menu is hard to click on (due to small font size) on tablet/mobile Search bar doesn't have a submit button (bad UX to force users to use enter button) The only thing that I listed that could be forgiven is thesearch bar button missing, but in reality, there should be one. The small font size for tablet/mobile is just plain stupid. But like I said, the site isn't bad... just average. Edited March 26, 201511 yr by cibgraphics
March 27, 201511 yr You made some good points there, thanks for pointing them out I asked you to clarify because people are very often quick to point something is bad but without stating exactly why and what to do to remidy the bad aspects. As for the search, I think that's sort of ok - only because the site's target audience are developers who should know to hit enter on a form. Otherwise yes there should be a button. The font size is reduced too much I agree, but often it's good for very large fonts such as headlines to reduce on smaller screens, and smaller fonts less so. - Example of a site that does this really well http://thewebahead.net/ I wouldn't go as far as saying it's stupid, it's just a little bit too small, I hate mobile sites with big text that break the line every two words or so, that is also horrible to read. The link I posted, I think gets a good balance. I regularly read CSS-TRICKS on my mobile and it's ok, even with my terrible eyesight, but yes it could be a bit better. The buttons I agree totally they should be taller. and yes the font in the footer isn't great, the contrasting colors could be better also improving readability By the way the screencast he did was for CSS-TRICKS V10, which I think is better than this version he has. I recommend watching through it to see and understand his workflow, aside from the problems we talked about Chris is one of the most revered devs in the industry it's good to see how one of the top guys works. I'm not convinced the outlined problems are directly due to Chris designing in the browser, it's more likely that it's down to his own personal preferences, which I agree are a little skewed on the areas you pointed out. It's pretty easy to notice and fix those issues as you are building out and testing the modules. The whole design in the browser term is slightly incorrect though, rough sketches are made and ideas toyed with before you jump into the browser. The big problem with photoshop is that it's static, yes you can show a mobile version too, but what about tablet, what about a large tablet and all the possible in-between sizes. Then the client rings and says I'm changing the companys brand color to blue. That's a quick job in the browser if you are using Sass. A pretty big job in PS. To summarise -- there's very good designers and developers who are in each camp. I don't think there's a right and a wrong way to do it. It's down to what works best for your teams workflow, skills and expertise (Probably preferences too). The debates been going on for a few years now, and these discussions, debates and people exploring new workflows helps us as an industry advance. Edited March 27, 201511 yr by rbrtsmith
March 27, 201511 yr @@robbydesigns I've seen that too, I think that's when studios are working on a low budget or don't value the input of a great designer. But this isn't because of designs being done in the browser, there are plenty of seriously talented designers around who design in the browser, and likewise those who don't. I agree that the design in the browser idea though can give people the wrong idea about how the actual process should work. Like I've stated it is not 100% in the browser, even if the terminology suggests this. Edited March 27, 201511 yr by rbrtsmith
Create an account or sign in to comment