Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Imagine somebody today, March 1 2011, has never written a webpage and would like to know what they should read to start building web pages today. They don't care about backwards compatibility, but want to build with web standards so that they will be portable amongst as many browsers as possible (Yes I'm saying I do not care if my web pages don't work with IE 4-8, Opera, Netscape, Mozilla, etc, I really don't care, because I've never used them, and that's likely true about those who will use the tools I'm building).
This person has zero biases or bad habits because they've never done it before. They're also hyperactive, so if they have to read 200 pages as to "why to use web standards" or "why web standards are better than "the old way"", they'll get discouraged and distracted and throw the book away, and go swimming. Speaking of which, my hair is wet.
They're looking for references that are engaging and concise. They're not stupid, this person is a real-live engineer who has done a tiny bit of development, a decade or two worth of systems administration, and even built a successful company or two. They just didn't go to college because they really aren't book learners, and are better at applied hands-on learning than at absorbing mounds of useless data in order to get to the two or three things they really need.
Given all of that data about the individual, and I know it's a lot about that individual (this individual is me, of course), what books or resources would you recommend?
(Zeldman's books are out because I already threw them away and then went swimming today.)
Some good resources to start:
Mozilla Developer Network: For HTML, CSS, Javascript, & DOM.
Dive into HTML5: For learning all about HTML5
JSfiddle: For fiddling around without having to build a whole page every time.
HTML Validator: For making sure the HTML you write is valid.
CSS3 Preview: Run-down of some of the new features of CSS3.
Official HTML5 spec: For when you need all the detail straight from the source.
jQuery: Arguably the best framework for making writing javascript for websites easier.
A List Apart: "For people who make websites". Definitely not for starting out, but good to read regularly.
Firebug: If you're using Firefox, this is a must-have.
Developer Tools: built in to Chrome & Safari (essentially firebug for webkit)
Also, do not use W3 Schools. Please see W3 Fools for a long list of reasons why. W3 Schools will often come up at the top of search results, but please resist the temptation to use it.
For someone that has never coded a webpage make sure you dont get sucked into the hype of HTML5 and CSS3 just yet. Although they have great features they all assume quiet a bit of knowledge of previous versions and all of the 'previews' will show you snippets related to enhanced interactivity rather than supported structural elements.
Stick to learning CSS2.1 and HTML4.01/XHTML which will give you a good grounding on which you can apply the new stuff later.
Im sure people will give this answer some negative feedback but if you need a JS snippet at the start of your code to enable the new HTML5 elements in one of the main stream browsers then it should be used for commercial purposes just yet.
I self-taught myself web design and development, and I have a background in engineering. You are comfortable with computers, so you are in good shape. To get started, I took a few online courses from http://www.hwg.org/. The courses are self-paced but moderated, and you get a lot of hands-on experience right away and you get an online community to help you bounce ideas around.
I took the HTML course, almost all the CSS courses and some JavaScript. Once you get some basic experience and learn the fundamentals, you can decide how much of the other stuff you need, for example, PHP/MySQL, or whether you need some design courses to make things pretty.
I would say, you need to put in about 80 hours of practice to master the basics, so give yourself a month of self-learning to get to that point. The reason to get to that point is that you will be fluent enough to ask good questions that will get you to a higher level.
About books, go to your local library and skim through a few books, find one that you like, buy it, skim through it and skip the parts that don't appeal to you.
Finally, if you really want to learn how to build web pages, get a good text editor and hand-code your HTML and CSS. In the long run, hand-coding is more efficient and you save quite a bit of money by not buying expensive tools like Dreamweaver. However, keep in mind that tools like Dreamweaver are often used by professionals and they serve a good purpose in production environments typically found in commercial web design firms. I actually use Dreamweaver in code view where I hand code my pages, but I have a few other editors that I use depending on the project.
Best wishes as you venture forth into a new and exciting field, and remember to have fun!
for html5: Dive into HTML5
for css3: http://www.css3.info/preview/
and if you want to use javascript it would be good to use jquery: http://jquery.com/
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Which syntax and features should I use if I wanted to write a webpage that could be correctly parsed by any device realistically still in use?
By currently in use I mean also devices whose usage is not statistically meaningful to be included on browser usage statistics, but still reasonable enough to be used in the real world without being too much of a stretch: e.g. A screen reader, a Point-Of-Sale/Kiosk Device, an Internet appliance like a smart TV or a console.
I've recently been assigned to develop an HTML landing page requiring support for - hear me out - the ancient Microsoft Internet Explorer 6. Yes, you read that right.
Long story short, it was in the requirements for a public administration project that was in a legal limbo for a long time, and reworking these requirements would be more problematic than developing it and be done with it. At least according to my boss. Besides, it shouldn't be that much different than writing a current-day HTML newsletter.
But it got me thinking - what's the oldest browser (as in, the one with the oldest HTML standard support available) that I could realistically find in the wild?
I'm not talking about relevance or caniuse-level-of-support numbers, just something that for some more-or-less realistic reasons (excluding "here's a Windows 3.1 VM getting to the internet" retro challenges) people would still be using to get online. Also some security requirements (mostly updated SSL/TLS) cut off quite a bit of older devices, mostly games consoles like the Dreamcast, PS2 w/Network Access Disk and the PSP, or the original Nintendo DS, so those are also excluded.
Other than the aforementioned IE6.0, I can think of Opera Mini browser (which version?) for some legacy mobile phones, or maybe some kind of internet appliance still using the Netfront runtime (IIRC The Playstation 3 still uses a pre-webkit version of it).
Any suggestion?
preword - apologies this became a bit of a rant, I will try and tidy it up later and focus it more. I also understand you may have to listen to your boss so this has become me ranting on your behalf to your boss. I hope you can use some of it to construct a strong argument with your boss to get the spec changed. It also doesn't answer the question as it is titled. Probably worth a few down votes but I enjoyed having a rant!
Given the comment the OP asked this answer is applicable to that.
What are the oldest browser standards I need to support for accessibility?
The WebAIM annual survey is a great place to get this information.
Under the section 'Browsers' we can see that 2.1% of respondents still use IE 6,7 or 8.
Unfortunately they do not indicate what split of those who use IE6 but I would imagine it would be less than 0.1% overall as very few sites still operate on IE6 correctly.
I personally develop to IE9 standards, so use ES5 for JavaScript (or compile to ES5), HTML 5.0 features and CSS3 non-experimental features.
The reason for this is that those who do use IE8 and below tend to be screen reader users due to compatibility with the software they own. They also tend to use a very specific set of websites due to the fact that most websites just will not work for them.
Many people would argue that you must include everyone, and in an ideal world you should. However you also have to consider that your goal in accessibility is to provide the best experience possible for the widest number of people. This is not possible using IE8 and below as you lose a lot of the HTML5 standards that are useful for accessibility (particular form related attributes, navigating by regions such as <main>, <nav> etc.).
So what about the people stuck on IE6-8 then?
As stated they tend to be screen reader users. The beauty of this is that as long as you develop valid HTML, user correct WAI-ARIA attributes etc. (basically go for AAA WCAG 2.1 rating or as close as possible, at least AA rating) then in IE6-8 the site will still function reasonably well and be usable, even if not perfect.
CSS is where your main struggle will be, making a site work in IE6 is just horrible if you still want to follow best practices (try styling a button for example to make the font size large enough and colour contrast AAA rated). Also how do you then make it responsive for mobile users without hundreds of hacks?
So what if you have to support older browsers.
You can provide a separate version of the site (shock, horror, gasp).
Use user agent sniffing to redirect people to a separate, stripped back, text only with minimal styling version of the site. Be sure to include a link to the main site and indicate that this is a version of the site designed for older browsers.
This requires careful planning as you have to ensure that the same information is maintained on both sites and that features introduced are replicated across both sites.
This is why nobody does this and isn't something I would recommend at all. The amount of things to consider, the limitations on features you can introduce and the chance of updating one version and not the other (even with a Content Management System) is very high. Making just one of those mistakes is likely to cause you more problems than not implementing this at all.
Conclusion
HTML5 introduces many great features for accessibility.
Regions for navigation are one of the biggest wins.
By designing to older standards you will likely end up with a site that is less accessible.
For example, a lot of WAI-ARIA attributes don't work in modern browsers, never mind in older browsers. Trying to fall back to using WAI-ARIA attributes is not going to work.
What about an accessible and easy to use layout? IE6 was the days of tables for layouts because CSS was so limited with positioning. (want a sticky navigation bar? Good luck implementing that!)
To provide 'best effort' I would use a HTML5 shim to at least fix the layout for things like IE7 and IE8, IE6 just isn't feasible.
Another argument is security. How on earth are you meant to write secure JavaScript that is IE6 compatible. Heck try finding a single piece of information alive on the internet today on 'how do i fix this problem in IE6'. Perhaps your solution here is to just not use JavaScript at all. (and yes someone will argue progressive enhancement allows you to use JavaScript, but then you have JavaScript errors which would then mean you fail WCAG under 'Robust').
Oh and did you know that you can't even use <style>*{position:relative}</style><table><input></table> as that will crash the browser?
As a final thought on this rant part, Windows 98 will run IE9 and NVDA. So we cannot make the argument that people may not have the financial resources to upgrade as NVDA is free. We could argue they do not have the technical knowledge on how to upgrade, at which point all I could say is write an article on the site on how to upgrade and redirect people there maybe? It gets a bit silly at that point as to where you draw the line.
How to win the argument with your boss / help them get the spec changed
Your boss is in a bad position but probably doesn't have the 'firepower' they need to persuade the spec to be changed easily.
Here is a simple way for them to win the argument:
WCAG 2.1 AA is the minimum legal standard that we can build this site to without risking getting sued.
This is impossible while maintaining compatibility with IE6 and without compromising on accessibility features.
The cost of getting accessibility wrong, coupled with the additional development cost associated with trying to develop to such an old standard makes this infeasible.
Couple that with the likelihood of developing a application with massive security flaws that could make the site vulnerable I would highly recommend we change the minimum requirements to IE8.
tl;dr
The oldest browser you realistically need to worry about is Internet Explorer 9. Even then you are being generous with your compatibility requirements. Do not try and develop a site that works in every browser ever encountered since 2001 (yes IE6 was 2001), you will break things for more people trying to accommodate people who do not want to upgrade (Windows 98 will run IE9 and NVDA).
Do not attempt to support IE8 and below as you will actually end up making decisions that will negatively impact accessibility.
If you can create a HTML5 valid and CSS3 valid website that is WCAG 2.1 AA standards compliant then you are already more accessible than 99% of websites in the world.
You're not asking the right question.
Users of what I build may be different than the users of what you build. To one audience, it may not matter if the site only loads on current browsers. To another audience, it may be the only thing that matters.
Additionally, some sites outright require newer browser features to function... no web-based fallbacks are available. Also, there are current browsers that don't support much of anything (i.e. Safari, Lynx, etc.) so it's not necessarily a matter of age... but capability.
The question you should be asking is, how do you make the decision of what to support and what not to support. Short of pointing you at your analytics and logs, this isn't a technical question, but a business question.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
It's well-known among teachers that some people can program and some can't. They just don't have mindset for that. In a nut-shell, I want to ask if the same is true about web-design.
I have a friend who is a good designer in general and can produce reasonably good-looking sites with WYSIWYG editor like Dreamweaver. But, since we're starting a common project, I'd like someone who can 'get hands dirty': work with html and css code directly. For many reasons, I'm sure you understand.
Now I'm thinking to incite him to learn, but not sure what're the chances of success.
So, do you also need some 'programming abilities' to profess css and html, or it's just a matter of training for regular designer?
I would especially like to hear particular experience from web designers.
PS I intentionally leave out JavaScript, let's keep it simple
The best web designers I have worked with know a small amount of html but don't use it when they are designing the sites. They do their work in PhotoShop (a minority will use GIMP). The reality is that I would rather they concentrate on laying out eye catching websites instead of trying to code it and lay the site out on the fly.
A web designer is absolutely not the same person as a front end web developer. That person has a skillset aimed towards converting the designers work into a set of working html/css templates.
Let me be clear that I am not saying that there is no cross-over between the two skillsets, but rather that very few people will be excellent at both design and development. If you are willing to settle for less than stellar results, at least be sure you go into the project with your eyes open.
Not at all. HTML is not a programming language, it's a markup language.
It shouldn't take you long to figure it out; I did it when I was 12. I personally think you need to be a better, how do I put it... artist to design websites than a programmer.
Of course websites nowadays are a lot more interactive, and for that you'll need some sort of server scripting (PHP, ASP, etc) and Javascript - and these are real programming languages.
A web designer who can't hand code HTML/CSS is not a web designer. The lack of such skills shows more of an aptitude problem(wanting to improve one's self). the graphic designer + front end developer combo doesn't always work well, because chances are the developer doesn't have the eye for the details in the design, such as margin, line-height, text kerning etc etc. Also it's hard to convert the interactive elements as well.
edit: this topic has been debated within the web design community on and off for a while now. You may find some interesting links in the blog post I wrote regarding this issue.
you are much better to know how to code a website HTML / CSS / Javascript before you go saying your amazing with a WYSIWYG editor. Sure you can use software to create a nice looking site but when it comes down to it how do you solve cross browser issues? How do you add dynamic content (even without server side) a WYSIWYG editor is just like designing a website in powerpoint or word but a lot more smarts. Though without the backing knowledge you are not going to go far.
As for learning plain HTML / CSS is fairly simple its an easy markup to get the understanding of. But then with that comes more, learning how to SEO plain HTML for example. There is always more to a site than HTML / CSS for it to be successfull.
This seems like a life question; I suspect it is true about almost anything. I think it can be hard to guage someone's aptitude for programming without seeing them actually try to program for awhile, however. Many people need to struggle with it for awhile before an "AHA!" moment is reached.
Nevertheless, I don't think design skills and abaility to work with CSS and HTML necessarily correlate to an aptitude for programming, per se. Of course, the two are not mutually exclusive,
It is not important for the designer to be able to program/markup/code in HTML or CSS. However, it is important for the designer to be aware of the current constraints imposed by HTML/CSS. With things becoming more dynamic, it is also important for the designer to understand how things are going to interact with each other. For example, you cannot become a real architect, without being aware of the constraints imposed by civil engineering.
But that's it. It is not important for a good designer to even know Dreamweaver or Photoshop or some other software :)
I am a university teacher, and I have also written both computer programs and HTML. Although I teach math, I understand the point about teaching computer programming. Although it might seem like there is no gray area between being able to program and not, I would say that writing in a markup language is one. You shouldn't divide the world into "cans" and "can'ts" with a question like this.
If he's a generally bright guy, yes you should encourage him to learn HTML and CSS. I wouldn't propagandize it as the thing that real men do or the greatest thing since sliced bread. Rather my argument would be to have a more complete perspective of what, after all, he's already been doing. Just as a racecar driver shouldn't necessarily need to pick up a wrench, but knowing what to do with one is useful for a deeper understanding. If you offer your friend a positive sell, the worst that can happen is that he'll say no and not take your advice. And who knows, he might even like it.
A lot of people either can't program or just wouldn't enjoy it, but don't mind writing in markup all that much. Most research mathematicians these days write their papers directly in a markup language, TeX/LaTeX, that in some ways looks a lot like HTML. Some mathematicians also like to write computer programs, but most of them don't. If they did like it, there is a good chance that they would have ended up in Silicon Valley. In fact in my profession, the whole question of can or can't write markup, or can or can't write programs, is stale. We're long used to a continuous range of abilities.
In my opinion, you can't have enough knowledge about this sort of stuff when doing any type of computer design or software implementation.
The more you know about the underlying technology, the better you will be at working with the high-level frameworks and constraints you live in.
Even if you work only in Photoshop in order to design a website, having the knowledge about what works and what will be more difficult in HTML/CSS/Whatever will give you an edge when designing that website over someone who doesn't know those details.
Of course, with knowledge comes constraints, which might be bad in and of themselves. Some of the best new technologies out there was built by people who didn't know that almost everyone else thought that what they tried to do was impossible.
But I still hold that more knowledge = Good Thing™
Web site creation especially a commercial website involves a LOT of different skill sets.
Back-end requires:
System Administration, Database Administration,
Web Applications development (anytime a website becomes interactive) requires server side programming skills and knowing various tools like (PHP, Java, ASP, Perl, C, C#, pick-flavour-of-the-month-server-side-language) and client side programming requires knowledge of browser behaviours mark-up languages and browser-side layout systems (HTML, javascript, CSS...)
Web Design requires artistic visual skills and related tools (Graphics programs)
Web Content requires language skills (Knowing how to proof read, translate, etc.).
Site Optimization requires knowledge of how to make sites appeal to various readers and audiences (both human and robotic)
A professional website involves several folks working in-tandem to bring all of the above together in various quantities.
If you are going to pursue something as a career, you need to know a bit about all aspects of that space and then follow in on what really excites you. So if someone is good at creating visually appealing content they should simply plan the content, and collaborate with someone to "program" their vision into the site.
Learning tools, and knowing about various components, is good as it tells you the boundaries and the playing field scope, but you don't need to know all of it to achieve professional competence in one specialization.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
We are in the process of starting a new company website and the question was brought to use or not a Content Management Solution. What will be the factors to consider to be able to debate between this two options.
Both of them have pros/cons, but I am sure that there has to be a few people out there that will have an external point of view to this situation. i will appreciate your opinion.
Thanks.
First lets consider the options:
No CMS - No Tools: you have a very good developer with a strong HTML background, some server side expertise and plenty of time on his/her hands.
No CMS but a light weight tool: You have a person or two who are comfortable with the basics of HTML, you site is mostly static and it is already built, but you need to update - you can consider any number of tools from (yes it is true) DreamWeaver, Aptana, Visual Studio WebExpres)
You have a small to medium web team and you have a medium for large site that is mostly content. I have found this to be the bulk of all projects that I have every seen. May times thes types of engagements end up with a large enterprise system becasue they incorrectly understood the two or three of the main factors that should drive an Enterprise CMS (read costs more that $250 and way more than free). Open source blogging engines like WordPress are very powerful and extensible. Add in a free editorial tool like LiveWriter and you have a lot if distributed editorial power, cheap, and it takes care of lots of things like Standards and SEO because it is just build solidliy in that respect. Plus there are a lot of people who can help you out. And it is very extensible.
Enterprise CMS:
Three factors should guide your decisions regarding CMS:
Large distributed editorial team that requires rigorous (usually complex) editorial workflows.
The site design and operation has been deemed secondary to some other functioanlity provided byt the CMS (simple SarBox Compliance, easy support for localizing the site to many languages)
In house experience with the product that has been positive and has proven ROI - but be clear, having purchased licenses is no reason to deploy. I have seen far too many cases where a large scale CMS was purchased (licensed) only to find it would not suit the true needs of the project. In some cases the clients were wise and moved on. In others they stuck to their purchase and to this day live in a world of hurt.
Start simple and grow - The average website had a half-life of 3 years. Make a series of small mistakes that you can easily correct through fast itteration. Only go for the big stuff when you are sure.
Instant smell that you are buying more than you need - you can't find out the price of the product until a sales person visits you and you can't get demo bits of the system untl you attend their traning session. By the time you get done with that, you could have an awsome site up and be buying everyone at your firm some nice libations.
For a company website, if you write your own, you're probably going to be reinventing a lot of what a CMS already gives you. The content on your site will most likely change frequently, and the company will probably want non-developers to maintain the content. With your own implementation, you'll have to provide management pages for non-devs to upload new content (text, images, docs, etc.), so it might make sense to just look at existing CMS frameworks.
The downside of a CMS is that you might have to work around styling issues to give the site the exact look-and-feel you're going for. Usually a good HTML/CSS developer can style any page in any way you want, so this isn't too big of a concern.
I think differently. A company website should be unique, personal, I thus I would avoid using a CMS.
Maybe you want a huge enterprise website, in this case a CMS will be better for you, but I'd rather write my simple content management than using a bloated, new hardware dependent website.
Oh, and the users will notice the difference in speed surfing through your hand-written website.
There are 3 points I think are important:
Personalization. CMSs can be
customized, but it's much worse to
style some pre-made html than
styling a pre-styled (since you
thought how you'd like it to be)
html.
Speed.
Web Standards - Accessibility - Unobtrusive JavaScript
Most CMS's are very extensible. You have a framework to start with, and from there you can add whatever you want. Also since practically all CMS's have modules/components/plugins from their community, you can immediately add to the core with even more features for exactly what you need.
Andy's right, too. You can layer the design on top of the the CMS, and it's very easy to extend the front end even more with all the great JS libraries out there - which will be largely CMS & language agnostic, so if you ever migrate from one CMS to another you can still keep a large portion of that code, too.
In short, modern CMS's are mature, easy to set up, highly extensible and customizeable so ... Don't reinvent the wheel unless you have some very strong, specific, compelling reason to do so.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Most of the time I worked as an application developer at backend side. I worked on enterprise web projects but never touched on user interface, design issues.
Good looking web sites and user interfaces always impress me.
And nowadays I am trying to develop public web site I know CSS, HTML but stuck with web design / user interface issues. I don't want to use a template or steal someone's web design.
How can a developer / programmer learn to design good web sites / user interfaces, What tools should I use and learn? or is desinging good web user interfaces a god's gift?
Looks like you hit on a hot topic. As a web/graphic designer myself, I think the best way to improve your ability in that regard is to look at a lot of good designs; meaning, actively seek them out.
As pixeline says, there's not a lot of objective knowledge to be learned (though there is some). It's more about improving your aesthetic eye. If you look at high quality designs all the time, then your tastes will become more refined and your web designs will naturally conform to your acclimated aesthetics.
For instance, I work at an indie metal label, so from time to time I'm called upon to work on band sites, album designs, magazine ads, sticker/clothing/merch designs, etc. So I'm always flipping through metal magazines and looking at ads designed by other people, or admiring the merch designs of other bands, or checking out the sites of other labels.
This not only serves as a source of inspiration when I'm stuck, helps me to gauge my own abilities and find areas for improvement, but it also helps me track the ever-changing trends and fashions in my particular sphere of design. As we all know, fashion is fickle, and people's tastes are always changing. A good designer knows how to stay just ahead of the curve all the time. This means that your designs don't deviate too drastically from accepted aesthetics (otherwise your designs will be rejected by audiences), but you also don't want to employ design elements that are overused and played out.
If you can ride the knife's edge and innovate enough to stand out, but not so much that the audience is unable to accept it, then you will have mastered the art of web design. A good designer can identify emerging trends and capitalize on them, while making it their own by adding their own twist to it.
If you're just starting to venture into web/graphic design, don't be afraid to emulate others and steal good ideas. Don't plagiarize, and give credit where credit is due, but just as making copies of famous drawings/paintings is an essential training technique in figure drawing & painting, so too is emulating quality designs an effective tool in learning graphic design.
Sites like Best Web Gallery and Screenalicious are excellent places to immerse oneself in quality designs and layouts. I would highly recommend scanning through these sites in your free time to flood your mind with examples of good aesthetics.
EDIT: I also want to emphasize that talent is not as much of a factor as most people would think. More often, interest is what people confuse as "talent." If you truly have an interest in something, you will be motivated to immerse yourself in it and practice it. This in turn leads to better ability, and if started at a young age builds confidence, which leads to an ability gap, which leads to more confidence and more interest, which in turn leads to more practice...
I consider myself a decent graphic designer (you can check out my portfolio via my profile link) and an alright artist. And people often comment on how talented I am, but they don't realize that I have literally spent thousands of hours honing my craft. While other kids were out playing with their friends, I was in my room drawing. That's the only reason I excelled in drawing. And when I first started building websites, they looked just as hideous as most teenagers' Myspace pages. So don't get discouraged when you see the work of "talented" designers. They all started from humble beginnings as well.
Please read Don't make me think
There is not much to be learned as "objective" content, except for : use a grid !
http://dev.opera.com/articles/view/grid-design-basics-grids-for-web-page-l/
See the human eye recognize as "beauty" things like balance, symmetry, contrast, color tones. Work on these fundamentals, and then... practice, experiments, iterate.
Seth Godin recently posted a page of resoures for people who want to improve their design skills.
The Smashing Magazine website also has a lot of relevant articles.
The best way to learn is to start doing and soliciting feedback. The key is making sure that your site is as simple, intuitive and easy to use, yet providing a very rich content and feature set.
This post makes a very powerful demonstration of what good UI design means. http://stuffthathappens.com/blog/2008/03/05/simplicity/
A List Apart is a great web-based magazine on design and development of web content. It publishes twice a month, usually with two new articles, and is a magazine type format; it's a good complement to some of the books that others here have mentioned.
You can learn principles of good web design, you can know all the tools, but really it's like graphics design, you need some talent. Unless you have it, you'll end up with very correct, but dull design.
these sites offer good content :
http://css-tricks.com/
http://net.tutsplus.com/
http://blog.themeforest.net/
See Why is good UI design so hard for some Developers?
It's got tons of great info about this
I found this site a while back and bookmarked it in hopes that my wife might be interested in web design some day...
66 Links To Learn The Webdesign Basics
http://www.divitodesign.com/2008/08/66-links-to-learn-the-webdesign-basics/
Its broken down into these categories:
General
Programs
HTML
CSS
Design
Site Structure
Tutorial Sites
Colors
Resources
Stock Images
Search Engines
Inspiration
Fonts / Typography
Usability and Accessibility
Blogging
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a development process question.
Background: I work for a modest sized website where, historically, the designers created mockups/screenshots of what they wanted pages and components to look like, and the engineering team (myself included) turned them into html/css.
This works relatively well from a code cleanliness perspective, and helps significantly when it comes to writing javascript. It has fails, however, in helping to maintain consistency from one page/component to another. On one page, a header font might be 12px and on another 11px, largely because its a complicated site with lots to keep track of (and we've cycled through 4 designers.) We have only a few truly universal styles, and they only get used when the engineers recognizes the style - not when the designer tells them to.
Our most recent designer is a relatively capable HTML/CSS coder. We thought we might have him create mockups in HTML/CSS and hand us off the code for quick integration. Our hope was that the designer would be better at being consistent in his style and that it might save us some development time up front.
What we've discovered is that our designer is not quite as good as CSS as we had hoped and that his code is often slightly bloated and incompatible with what we need to do. Also, his style of coding is fundamentally different from the rest of the engineering team and isn't jiving terribly well with our established coding practices.
Question: How do you do the hand off from design to engineering? I know I've heard of companies that let their design team do all of the template coding, but I'm curious how that works. Does the design team actually incorporate members of the engineering team in those scenarios?
As we're structured right now, there's not a chance in hell we'd let our designer write the final templates and check them into SVN, even if he was a proficient HTML wiz. There's too much in the templates that requires knowledge of our codebase and of potential performance issues.
How do we get this process working? Is it a pipe dream?
Specifically - personally - since I come from a web-dev, small-shop background I do the CSS work and slicing the PSD (typically) myself. But then I like to think I'm well rounded like that :)
Generally, the best experience I've had of this was a largish company with very defined groups of developers including the design team who produced the gfx, the apps team who did the vast bulk of server-side coding and app architecture, and the UE (user experience) team who sewed the two together, producing XSLT/JSP/HTML markup in general, and the CSS and JS for the client-side.
There was a very structured process of:
userstory ->
"wireframe" (documents) ->
design (PSD) ->
"flat" markup (DHTML only) ->
integrated markup (with web-app)
Where "wireframe" would be close to a spec for UE, produced with UML or maybe visio. I have heard the term applied to step 4 which I think fits better, but this is what it was referred to as there.
Whilst this works well for the question at hand, I found it had other problems built in. It was very hard to work across teams, and because of the timescales the design team rarely involved UE in decision making (which put UE in some awkward positions), the apps team and design could be working at cross-purposes, and there wasn't a lot of scope to learn in these boxed in teams.
My suspicion (and I think ideal scenario) is that the developers on a project would each be capable of working with, say, 80% of the technology involved (be it CSS, SQL, whatever) to spread the decision control and risk, but each domain would have one (more?) "czar" who could act as authority and oversight within the domain. Actually producing those designs is to my mind a strange and magical skill in it's own right so I see no real overlap with developers there, but I think a pool of artists and project teams of cross-skilled programmers would be very powerful.
Apols for the long-windedness. I could go on at considerable length on this, I've spent a lot of time thinking about it.
btw, it seems like you could do with some serious web-devs there, (no offence). Having problems to "maintain consistency from one page/component to another" screams failure to grok CSS
In my experience, unless you limit your design severely, you need real coding skills to build a web page with interaction. Let me elaborate some. If you have built your pages very modular (think of GUI toolkit widgets) you can give your designer a handful of them, he can build the basic structure like playing toy blocks with a nice finishing paint.
Often, modularization alone is not enough for desired interactivity. So, some blocks needs their interactions to be designed carefully as well (like animation, fluid layout to accommodate indeterminate content, customized behaviour via extra javascript, caching to eliminate redundant requests and speeding up things) or ability to accommodate minor presentation variations, which brings us to the realm of programming, where you calculate dimensions, enable/disable parts, keep track of time, preload stuff, invalidate preloaded stuff and so on.
Enter HTML/CSS/JS. They are more of a product of evolution than intelligent design. You cannot always declare your intent and be done with it. You need attributes declared in your html, stupid hacks in CSS combined with extra markup, ridiculous amounts of js to smooth rough edges, duplicate rendering code on the server side. These tool were never meant to build applications.
I don't think one can achieve a complete separation of design and application development in these tools at hand. The effort required is too high to justify the marginal returns.
If you end up heavily modifying designer's code (which is othen the case if he is not one of the developers also), there is no point in making him suffer trying to express his intent using the wrong tools, nor developers breaking the design while modifying it and consequently fixing it. I don't even mention user experience.
In my opinion, no small internet businesses who want to ship a product in a reasonable time should spend their scarce resources to go against the grain. Let people do what they do best in collaboration if necessary. If you can't divide design process at an arbitrary satisfying point, you may as well not bother to separate at all. Pipelining works well for machines whose goal is determined to the last detail and not changing. I can't say the same for humans building and designing things be it software or hardware.
Where I work it's basically the same. Designers create mock-ups and specifications of the UI design, right down to the pixel, and the developer creates HTML/CSS/code out of that.
The reason I say code, is that we use UI frameworks (namely, GWT), and as much as we would want to, code and CSS styles are still very coupled. I do not believe there exists one UI framework in which code can be completely decoupled from the UI design.
So I guess for now it's still entirely the developers job. Though I would like to hear about organization which are able to hand off some of the work to designers.
The problem with handoffs is that the idea and implementation of one group is not going to match the abilities and implementation of the next group. Just by their nature handoffs are going to be wrought with problems. So what is an alternative to the ubiquitous handoff scenario? I think that integrating the user experience (UX) into an agile and iterative development process makes sure that what is really important occurs:
The customer's needs are researched then validated.
Early and continuous collaborating between usability experts, designers and programmers.
The actual process works by having everyone collaborate with the customer up-front on their needs. Then the design is researched and prototyped in the iteration before coding begins. Thus when coding is occurring, the next set of designs are being worked on. Programmers should be looking forward at what designers are doing and the designers look back to be sure programmers are on target. Once a design is coded, it goes to the customer for acceptance, by that time the programmers are working on the next set of interfaces.
Jeff Patton did a podcast on Agile UX recently that goes into some of the implementation concepts and common problems.
There is a whole group on Yahoo dedicated to agile usability (which mostly involves interface design).
For the CSS inconsistencies... I'd just suggest making a style guide then trying to stick to it. Have someone be in charge of "design consistency" that way the can spank anyone inventing yet another way to display the user.
At my company, my ideal work flow doesn't work very often, but sometimes it does. I löve when this happens: The engineers write the webapp and output semantic html with only minimal CSS. then you have the designers do the CSS.
I like it when it goes this way, because:
It is easy for me to write semantic
HTML.
I am not very good at coming up
with a good design for my semantic
html.
It is entirely possible to do
the CSS without asking me questions.
The markup just speaks for itself.
However, this rarely works. Because:
The CSS has to be modified whenever the HTML changes and the designers' time is sparse.
Moreover, our designers don't enjoy styling my markup, and fighting for their time is not pleasant.
Our designers often want to change the markup. Mostly because they believe some layouts cannot be done without changing the markup or because they believe that it's the only way to make IE obey. They are technically not able to change the markup, though.
I have my doubts about many of their cases. Many times they claim IE incompatibility, I strongly doubt they really know IE that well. There are neat CSS hacks to make IE obey without resorting to
<br clear="all">
So, sadly, usually this ideal is a little off for me.
A separate designer - developer workflow is the best way to go. Designing a website and coding it are altogether different jobs. There are issues of cross browser compatability, CSS, XHTML, apart from coding standards to deal with.
You could also opt for outsourcing your HTML to a specialized PSD to HTML conversion expert like us (ButterflyHTML). It may work out cost effective in the long run