Know your users. Determine who is your target audience and do some research on typical monitor size/resolution/CPU speed etc information which is all available on the web. Use that as your guide for your minimum browser/minimum screen resolution and design your web site for that level of compatibility.
When using elements that may introduce compatibility issues either through versions or different browser types: test, test, test. Every web developer should have both NS and IE installed and preferably a tool that scans your code for compatibility issues. I know Dreamweaver is nice like this and tells me what will break under what software. There are also guides on the web that will tell you which HTML is supported under what browser.
It takes quite some time and a lot of research to put together a set of references that can help you NOT cause grief to your users, but it's a one-off investment in time and well worth it.
Not only that, it's all available on the web for free. I bought a HTML 4 book because it's handy to have a ready reference and it was a good book at a bargain price. The other stuff changes so much that I just link to the web pages and use them as I need them.
Once again I have to disagree. I work in this field and it IS done that way.
I'm sure you've never seen the general public asked for input on interface features, but that's because that's not the way representative users are chosen. Just because you've never seen it done, doesn't mean it doesn't happen!
Granted, Apple did the wrong thing with their new OS, if the reports are true, but how can you think that they are representative of the whole software development community?
I know that a lot of organisations who develop software in house have quite sophisticated and well-used usability labs because I've read the case studies based on their real life work.
I also participate in special interest groups and a mailing list for usability specialists who also share their experiences with collaborative interface design (amongst other usability issues). But they don't do it with the general public, they do it with a group of people who are representative of the system's users.
Once again, these are mostly individual companies who develop their own software in-house. Never make the mistake of thinking that commercial software developers are representative of software development standards in general: they are not.
Having said that, though, I have also read a great deal of information on the usability studies that places like IBM, Sun, and even Microsoft have conducted and are still conducting to this day. It does happen and there is a great deal of literature to show that it does.
"Nobody in the traditional HI research community seems to be interested in a collaborative approach. The ordinary user only enters the picture when they fetch someone off the street and use her as a guinea pig for their usability studies."
I'm sorry but I have to take exception to the above statements. They are both wrong.
HI/CHI/Usability research and practice is ALL about the collaborative approach, however the concentration is on collaboration between developers and USERS, and not with their peers and there lies the small difference between the two. There is plenty of research on iterative and collaborative interface design and an awful lot of it in practice where usability specialists work. In fact, I would say that your most compatible allies for the collaborative approach to design are likely to come from the usability lab: it is the most preferred and most recommended approach.
"Best practice" in usability engineering is to bring the user in as early as possible/practical in the *design* phase. In fact some practitioners recommend that users participate in the feasibility stage, ie before the project is even approved.
What you have described is the common misconception of developers who think of usability as a final test of the interface after it's been fully or almost fully developed. This is the *least* effective time to test the interface since much time and money have already gone into the interface and there will be the highest amount of resistance to suggested changes, regardless of their validity.
I've never seen so much unfounded righteous indignation!
It will be interesting to read Mr Nielsen's response to this. I am quite amused at the tone of the messages in this and other threads regarding his patents.
Despite a lack of detailed knowledge of the patents owned (what a hysterical response to a set of extremely short descriptions!) and an even deeper lack of knowledge of Nielsen's intentions in patenting his discoveries and enforcing those patents, everyone is quick to cast him as a money-grubbing anti-opensource, anti-internet devil.
How about asking a question and then waiting for the response before you toss the boiling oil?
Is it possible that he might have patented his and his colleagues' hard work in order to prevent others from making money off their ideas? Is it inconceivable that he might simply be protecting them in order to gain credit where it's due? And has he said anywhere that he would restrict the use of his patented ideas? Not that I have seen....
Jakob will no doubt correct me if I am wrong, but I always thought it was because monitors flicker and strobe and do nasty things to your eyes, so you never want to stare at them constantly. Well not if you want to concentrate anyway. For the reading of text, this exercise can be extremely uncomfortable and for the non-geeks who haven't trained their eyes to ignore the noise, reading things on a computer screen is something to avoid. Secondly, it comes down to the reason why people are using the web. If they are searching for information, a user will scan each page to determine if it has the information they're looking for. They don't have the time or the inclination to read a bunch of stuff that's not what they want. People are generally in a hurry on the web, because of cost considerations but also because of all the noise (same word different context) or crap that you have to wade through to get to the information you're really looking for. Flick
Slashdot Mirror
When using elements that may introduce compatibility issues either through versions or different browser types: test, test, test. Every web developer should have both NS and IE installed and preferably a tool that scans your code for compatibility issues. I know Dreamweaver is nice like this and tells me what will break under what software. There are also guides on the web that will tell you which HTML is supported under what browser.
It takes quite some time and a lot of research to put together a set of references that can help you NOT cause grief to your users, but it's a one-off investment in time and well worth it.
Not only that, it's all available on the web for free. I bought a HTML 4 book because it's handy to have a ready reference and it was a good book at a bargain price. The other stuff changes so much that I just link to the web pages and use them as I need them.
I'm sure you've never seen the general public asked for input on interface features, but that's because that's not the way representative users are chosen. Just because you've never seen it done, doesn't mean it doesn't happen!
Granted, Apple did the wrong thing with their new OS, if the reports are true, but how can you think that they are representative of the whole software development community?
I know that a lot of organisations who develop software in house have quite sophisticated and well-used usability labs because I've read the case studies based on their real life work.
I also participate in special interest groups and a mailing list for usability specialists who also share their experiences with collaborative interface design (amongst other usability issues). But they don't do it with the general public, they do it with a group of people who are representative of the system's users.
Once again, these are mostly individual companies who develop their own software in-house. Never make the mistake of thinking that commercial software developers are representative of software development standards in general: they are not.
Having said that, though, I have also read a great deal of information on the usability studies that places like IBM, Sun, and even Microsoft have conducted and are still conducting to this day. It does happen and there is a great deal of literature to show that it does.
HI/CHI/Usability research and practice is ALL about the collaborative approach, however the concentration is on collaboration between developers and USERS, and not with their peers and there lies the small difference between the two. There is plenty of research on iterative and collaborative interface design and an awful lot of it in practice where usability specialists work. In fact, I would say that your most compatible allies for the collaborative approach to design are likely to come from the usability lab: it is the most preferred and most recommended approach.
"Best practice" in usability engineering is to bring the user in as early as possible/practical in the *design* phase. In fact some practitioners recommend that users participate in the feasibility stage, ie before the project is even approved.
What you have described is the common misconception of developers who think of usability as a final test of the interface after it's been fully or almost fully developed. This is the *least* effective time to test the interface since much time and money have already gone into the interface and there will be the highest amount of resistance to suggested changes, regardless of their validity.
It will be interesting to read Mr Nielsen's response to this. I am quite amused at the tone of the messages in this and other threads regarding his patents.
Despite a lack of detailed knowledge of the patents owned (what a hysterical response to a set of extremely short descriptions!) and an even deeper lack of knowledge of Nielsen's intentions in patenting his discoveries and enforcing those patents, everyone is quick to cast him as a money-grubbing anti-opensource, anti-internet devil.
How about asking a question and then waiting for the response before you toss the boiling oil?
Is it possible that he might have patented his and his colleagues' hard work in order to prevent others from making money off their ideas? Is it inconceivable that he might simply be protecting them in order to gain credit where it's due? And has he said anywhere that he would restrict the use of his patented ideas? Not that I have seen....
Jakob will no doubt correct me if I am wrong, but I always thought it was because monitors flicker and strobe and do nasty things to your eyes, so you never want to stare at them constantly. Well not if you want to concentrate anyway. For the reading of text, this exercise can be extremely uncomfortable and for the non-geeks who haven't trained their eyes to ignore the noise, reading things on a computer screen is something to avoid. Secondly, it comes down to the reason why people are using the web. If they are searching for information, a user will scan each page to determine if it has the information they're looking for. They don't have the time or the inclination to read a bunch of stuff that's not what they want. People are generally in a hurry on the web, because of cost considerations but also because of all the noise (same word different context) or crap that you have to wade through to get to the information you're really looking for. Flick