Talk:Responsive web design

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Internet  
WikiProject icon This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
 
WikiProject Human Computer Interaction (Rated Low-importance)
WikiProject icon This article is within the scope of WikiProject Human Computer Interaction, a collaborative effort to improve the coverage of Human Computer Interaction on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.
 

Photo of Marcotte[edit]

In response to LittleBenW deleting the photo that I posted, with the comment that a photo of Marcotte belongs on a Marcotte article and not on the responsive web design article: I will point out that the theory of relativity article has a picture of Albert Einstein, and the gravity article has a picture of Sir Isaac Newton. If those pictures are appropriate on those articles, then a picture of Marcotte on the responsive web design article is certainly appropriate. Clarissa Peterson (talk) 03:43, 26 August 2012 (UTC)

  • I can't see a picture of Albert Einstein in the theory of relativity article, though there is a picture of a Russian postage stamp issued to honor him. Has a stamp to honor Marcotte been released?
  • Sir Isaac Newton and Nobel-prize-winning Albert Einstein are in a completely different league as to notability. The term AJAX was coined by Jesse James Garrett in 2005, but that does not make him notable enough to add his photo to the AJAX article—and adding his photo to the AJAX article would not improve anybody's understanding of AJAX. RWD is even newer than AJAX. Notability takes longer than that. Coining a name for something that already exists is not as notable as creating a genre from zero. Even creating a genre from zero (as, for example, DJ Kool Herc is credited with doing for Hip hop) does not earn a photo on the Hip hop page.
  • Feel free to propose a Marcotte page if you wish. But maybe such a photo would not add useful information even to a Marcotte page, if there were one—his face is too small to be recognizable. LittleBen (talk) 04:07, 26 August 2012 (UTC)
  • I have made the point that the photo does not add any information to Wikipedia users' understanding of RWD, the face is too small to be recognizable, and that you are free to create an article on him and add his photo to that. LittleBen (talk) 04:37, 26 August 2012 (UTC)

Regarding your note that I am free to create an article on Marcotte: I do not intend to do so. I am not very experienced on Wikipedia, and do not feel confident in my judgement as to whether a subject would meet the standard for notability. Clarissa Peterson (talk) 05:12, 26 August 2012 (UTC)

  • If an article on Marcotte would not meet the standard for notability, then a photo (which does not even show his face clearly) would not make the cut. Wikipedia is not a fan club. You can get help with creating an article (on Marcotte); you can create an article in the sandbox area of your user page, and ask for advice and help from experienced editors. I will ask for a third opinion. I can't see any connection between Responsive Web Design and "Robot Monster", which is about all that is visible in the picture. His tiny book on RWD is currently ranked #223,168 on Amazon, way below other books on the topic.
  • Your breaking the article into sections does improve the article. LittleBen (talk) 06:54, 26 August 2012 (UTC)

Thank you for offering the links for help with creating an article page. However, I prefer to limit my involvement at this time to making edits rather than creating pages, until I am more experienced with Wikipedia. You may notice that many newer editors do the same. Thank you also for being willing to ask for a third opinion.

  • There are no photos of the people who named the strategies "Mobile first", "Progressive enhancement" or "Unobtrusive Javascript" some ten years ago, so I don't think it's appropriate to add photos of individuals related to RWD either. The WP:3O page is currently broken, so I'll get a third opinion when it's fixed. Other books on RWD are surely 250 or 500 pages long, not 140 pages. LittleBen (talk) 07:25, 26 August 2012 (UTC)

The book that comes up first when I search for "responsive design" on Amazon is Responsive Web Site Design, Quick Guide How To Get Your Site Ready For Every Device And Browser and it is listed as 50 pages. The one after that is 324 pages. The Smashing book is only 150. Not every book is long, and not every long book is good. Having read Marcotte's book, I think I would describe it as concise, rather than "tiny." Clarissa Peterson (talk) 07:47, 26 August 2012 (UTC)

  • Both Frain and Kadlic books are similarly priced, but double the size. The Gillenwater "Stunning CSS3" book, dated 2010, is even more substantial. LittleBen (talk) 07:57, 26 August 2012 (UTC)
Searchtool-80%.png Response to third opinion request:
As the images on Wikipedia serve the illustration purposes, I see no point in the article that may be illustrated by the photograph of any person. Furthermore, the photograph creates a undue weight issue, as it overly emphasizes the role of Ethan Marcotte (who merely named the concept), while more weight should be given to the technical point of article. If illustration is deemed necessary, a map image (or video of resizing browser window) would be ways more appropriate here.— Dmitrij D. Czarkoff (talk) 09:47, 26 August 2012 (UTC)

Changes to Content of Article[edit]

You added: "This is in contrast to other approaches which call for the creation of ... separate designs for various screen sizes". In fact RWD calls for separate designs for different screen widths, so this is factually wrong. For this reason, RWD is more expensive than a simple design without media queries. LittleBen (talk) 08:06, 26 August 2012 (UTC)

I am going to change the wording to say

  • RWD: "in which an adaptive design is crafted (using one set of code) to provide..."
  • other approaches: "separate sites or designs with separate sets of code"

Feel free to change that wording on the page if you disagree.

You have not expressed any specific objections to the numerous other changes I made, so I'm going to put those back in. I have no problem with you making changes to anything I add or edit, but removing all of my edits at once is not appropriate. Even if you think some of it is wrong, there is certainly some of it which is not wrong. Clarissa Peterson (talk) 08:22, 26 August 2012 (UTC)

  • If you look at "Page View statistics" on the history tab, you will see that this article has received 38274 page views in the past month—whereas Wikipedia:Manual of Style got only 35087 page views (and was ranked #3120 on Wikipedia). I think this is because the many people who visit this RWD page want to learn about the technology, and find useful references, not because they want to see pretty pictures of individuals and dumbed-down explanations that are technically wrong. At about the end of January, I asked for a stub article on RWD that had been deleted to be undeleted, I have greatly fleshed it out with useful material, and enough people seem to think that it is useful in its present form to have made it very popular.
  • Adding section headings was an improvement, the photo is to get a third opinion, but reorganizing it and adding factual errors is not an improvement, sorry. LittleBen (talk) 08:25, 26 August 2012 (UTC)

Just because a lot of people visit the page doesn't mean that it was perfect and could not use any improvement.

I made a lot of additions that I think you will find are useful, like adding wikipedia links to several phrases that weren't linked before. There were also a few factual inaccuracies that I fixed. For example, the term was actually coined at An Event Apart, not in the subsequent article by Marcotte. Clarissa Peterson (talk) 08:31, 26 August 2012 (UTC)

  • Quote: "I made a lot of additions that I think you will find are useful, like adding wikipedia links to several phrases that weren't linked before".
  • Feel free to add links to Wikipedia articles that define terms.
  • Quote: The term was actually coined at An Event Apart, not in the subsequent article by Marcotte.
  • You should add dated references that justify any such claims.
  • Do you know Marcotte personally? If so, be aware of WP:COI.
  • People who view technical articles are more interested in learning the technology rather than the history, that's why I don't think changing the order is an improvement.
  • RWD means using media queries to present different layouts to different devices. So saying that NOT having to prepare different designs for different devices is an advantage of RWD is completely wrong—it's the exact opposite. LittleBen (talk) 08:49, 26 August 2012 (UTC)

I do not know Marcotte personally. I do admire his work, and I've read his book and many of his articles.

As background, I have been a web designer/developer for 10 years, and have done a lot of responsive design. I also have recently taught a workshop on RWD and I have other speaking engagements coming up, so that shows that I am respected by my peers for my knowledge on the subject. I understand that considering myself knowledgeable in a subject doesn't give me any greater right to edit a page than anyone else, but it should at least tell you that I am not just randomly making things up to put on the page. I am simply trying to use my knowledge and experience to make the page better by improving the language and going into more detail about the different parts of RWD.

That said, I make mistakes like everybody else, and if you feel like I have made any errors in my edits to the article, please tell me what they are. But it is unfair to discount my opinions entirely.

Telling me where I should have added a reference is helpful, and I will do that. And I would appreciate any other specific direction as to what I can do better. Clarissa Peterson (talk) 09:05, 26 August 2012 (UTC)

I don't think we disagree on the process, I think we're just using different words to describe it. Clarissa Peterson (talk) 09:14, 26 August 2012 (UTC)

  • My background is engineer/tech. writer, and translator—I have also taught IT and web (SEO, analytics, Internet research) related subjects. By adding the section headings you have shown that I am no good at graphic design ;-) But I think that the organization of the article is basically OK—it's primarily about what RWD is, not primarily about the history of the RWD name and Marcotte.
  • I have already explained that most people want to quickly get to the technical essence rather than have to wade through photos and discussions about "popularity" first. That's surely why WP:MOS is not as popular—it's difficult to find what one is looking for.
  • Eight layouts is eight different designs. The phrase "same code" is surely so vague as to be meaningless. LittleBen (talk) 09:33, 26 August 2012 (UTC)

I wouldn't think that everyone going to a page wants a technical description. I often look something up on Wikipedia when I hear an unfamiliar term on TV or in a book. If it's technical/scientific, I expect that the first paragraph will say what it is in words I can understand. I expect that the rest of the page might be beyond my understanding, but at least the first paragraph needs to be for everybody. People are curious about things, they don't want to know everything, they just want to know what it is. I think that's an important part of what Wikipedia does. You can find out what anything is.

If you know of statistics that show people are only looking for technical descriptions, I would be happy to be corrected. Clarissa Peterson (talk) 09:41, 26 August 2012 (UTC)

  • You write, "Element sizes are expressed in percentages of EMs," but the head of the article (and the Marcotte article) say (relative units like) percentages or Ems". To a Tech. Writer, a mistake like that is awesome. LittleBen (talk) 10:04, 26 August 2012 (UTC)

Yes, that's a typo that I put "of" instead of "or". Thank you for proofreading. I would have caught it on the next read through. But sometimes a mistake is up on the page for a little bit. I already said I'm not perfect. Clarissa Peterson (talk) 10:12, 26 August 2012 (UTC)

Also, I think you're in a different country. It's the middle of the night where I am, or actually it's pretty much morning and I've been working on this all night instead of sleeping, so my brain is a little fried. But I want to get this resolved. I didn't think making edits would be such an issue or I never would have bothered. Clarissa Peterson (talk) 10:16, 26 August 2012 (UTC)

  • Your definition of flexible images only presents Marcotte's viewpoint, and says nothing about techniques for resizing huge images designed for large-screen desktop PCs or Retina displays (or presenting alternative images) to suit dumb small-screen mobiles and low bandwidths (see ref. 9). This is perhaps the biggest obstacle to RWD, and Marcotte didn't solve it.
  • People coming to this page want to see what RWD designs look like. So it is not appropriate to remove the link to representative RWD sites chosen by Marcotte.
  • A third opinion—that an image is not appropriate—has been added above. Do you want to appeal this further?
  • Quote: "I think you're in a different country. It's the middle of the night where I am, or actually it's pretty much morning and I've been working on this all night instead of sleeping, so my brain is a little fried. But I want to get this resolved. I didn't think making edits would be such an issue or I never would have bothered".
  • Your health should come first, get some sleep. If you think that your editing sprint has taken a lot of time, then imagine the amount of time I have spent researching and polishing the article. Don't be discouraged. But it's better to do a little at a time—it makes it easier for other people to check—and discuss far-reaching changes on the talk page first. Because if there are too many radical changes that seem undesirable then it is simpler to revert them all. LittleBen (talk) 10:28, 26 August 2012 (UTC)

Before I saw the third opinion I had added an image at the top that shows the responsive Boston Globe site. I changed the image of Marcotte to one where he has CSS on the screen behind him, and moved it down the page, and it's a smaller thumbnail (like the original photo I chose). Are you okay with the Marcotte photo down the page and smaller, or do you still feel strongly that it should be removed?

I see your point about having a link to representative RWD sites, but the link you had on there was almost a year old. RWD has matured so much in the past year I don't think the list would still be representative. Can we try to find a different list to use instead?

I feel like the order of the three elements should have media queries last, because you have to implement it in that order. I have never seen it described in any other order. Do you have a reason for choosing the order you did? Clarissa Peterson (talk) 10:52, 26 August 2012 (UTC)

  • I'll fix your Multiple references to the same footnote. You should get some sleep. Feel free to find other lists of responsive sites——I think .net mag. has some every month, but possibly they're not on the website.
  • Quote: I feel like the order of the three elements should have media queries last, because you have to implement it in that order. I have never seen it described in any other order. Do you have a reason for choosing the order you did?
  • As I said, consistency: that's the order in which it's described at the top of the article.
  • Time-sequence-of-events (or actions) is one criteria that tech. writers use to put stuff in a logical order: the browser runs the media query first to choose the appropriate layout. HTH (Hope This Helps). LittleBen (talk) 11:07, 26 August 2012 (UTC)
  • I don't think a photo is appropriate. Otherwise every new amateur band and fashion label would want to have photos of their members or directors advertised on Wikipedia. Wikipedia is more about enriching everybody by sharing ideas than promoting individuals' agendas. A photo on the page of a really notable individual is different. LittleBen (talk) 11:47, 26 August 2012 (UTC)

I would note that image from this edit is a perfect illustration, though I would suggest to make thumbnail larger, so that the the screen content may be identified as the same page without following the link. — Dmitrij D. Czarkoff (talk) 11:23, 26 August 2012 (UTC)

  • Thanks for giving a 3rd opinion. We seem to agree that photos of individuals, however small, don't belong. I'd personally rather see a list of representative sites that demonstrate what RWD is, rather than a thumbnail of a single RWD site (which I think Marcotte may have been involved with). A link to the Boston Globe site ("see RWD for yourself") would also seem more helpful to me than a link to the Wikipedia article on the Boston Globe. LittleBen (talk) 11:47, 26 August 2012 (UTC)
    • I'm pretty sure that linking to Boston Globe would be a bit excessive per WP:ELNO #13 and WP:EXAMPLEFARM. Image showing single site on different devices (specifically including older devices, Apple Newton in this case) helps to understand the concept; the link to any RWD-enabled site helps ways less, as most readers would see the site from a single device, and I doubt that they would experiment with resizing the browser window to see the effect. — Dmitrij D. Czarkoff (talk) 12:00, 26 August 2012 (UTC)
  • Thanks again for your comments. LittleBen (talk) 12:09, 26 August 2012 (UTC)

I've added a link to a list of responsive site examples from 2012. Is putting it under external links the most appropriate way to do it? Now that there's a recent list, is it okay to take out the 2011 list?

I know I didn't say anything retina images, but neither did you. Marcotte didn't address retina images in his definition of responsive design originally, because at that point in time Apple had not yet come out with the retina displays. So that's an area where everybody has been playing catch-up. There is not consensus on a solution yet; there are multiple avenues to address the issue. I can write something up about retina eventually, unless you want to do it. I think the RWD page could easily have 5x as much information if we hit on all the different issues. Another area that needs to be discussed is responsive workflow. Clarissa Peterson (talk) 12:17, 26 August 2012 (UTC)

I strongly feel that the bulleted list format is the best way to display the list to increase readability and comprehension, since they are multi-sentence definitions. Clarissa Peterson (talk) 12:24, 26 August 2012 (UTC)

  • Quote: Is it okay to take out the 2011 list? I strongly feel that the bulleted list format is the best way to display the ("Elements") list.
  • I like the 2011 list because it shows both small-screen and big-screen views so is more intuitive (as per 3O reviewer's comment). It's a fact that the sites were chosen by Marcotte, and this was published less than a year ago, so I think that it should stay in the history section. Other "examples of RWD" sites (other than the one you added) also show both small-screen and big-screen views.
  • I like the bulleted list format too, but am not sure if it's used much in intros. I feel that the ”As a result” in the intro. is important.
  • As mentioned above, one way of avoiding the serving of large (desktop-sized or retina-sized) image files to dumb mobiles over low-bandwidth connections is covered in ref. 10. LittleBen (talk) 12:44, 26 August 2012 (UTC)
  • Funnily enough, one very popular tech. page on Wikipedia is HTTP 404. People are surely trying to find out the meaning of this technical term, rather than looking for the picture and history of who invented the term. ;-) LittleBen (talk) 13:21, 26 August 2012 (UTC)
  • A brief and simple page (like the present RWD page) where everything is "above the fold" and one can find answers quickly is surely preferable to a humongous page which takes ages to read (if you have the patience), and requires reams of paper to print out (like MoS).
  • The Web design article gets a lot of page views (popular keyword) but is poorly written. I've touched up a few pieces of it, but it's too long and rambling for me. I think it covers work flow, or has links to articles that talk about it. LittleBen (talk) 13:29, 26 August 2012 (UTC)

"Brief and simple" is not always preferable; it really depends on the communication goals of the page. If you have a lot of information to convey, a long page may be necessary. It's not expected that everybody will read the whole page. The key to making your page successful is to have a straightforward introduction section that can stand alone for those people who do not desire additional information, followed by a table of contents that reflects a well-planned document structure using accurate and descriptive headings. Many times I have visited an incredibly long page on Wikipedia to find a specific piece of information, and yet had no trouble getting to the right place via the table of contents. That is preferable to a brief and simple page that may have omitted the information I was looking for in order to save space. Clarissa Peterson (talk) 22:17, 27 August 2012 (UTC)

  • Jakob Nielsen coined the phrase above the fold. He discovered that the majority of web users take only about 15 sec.—looking at only what is visible on screen (without scrolling) [this is what he means by "above the fold"]—to decide whether a site or page is relevant to what they are searching for, or not. You can easily measure this (time to bounce) using Google Analytics or the like. That's why several short and simple focused pages on different topics can be much more effective for SEO than a single humongous page that tries to cram in every topic under the sun, and include everything but the kitchen sink. LittleBen (talk) 03:02, 28 August 2012 (UTC)

What you are saying about above the fold is not a contradiction to what I'm saying. Nielsen said that users spend 80% of their time looking at material above the fold: Scrolling and Attention. That is a lot, but there is still 20% of the time they are looking at information below the fold, which is not an insubstantial number. That's why it makes sense that the most important content is at the top of the page, yet the page can have additional information further down that users can easily navigate to via the table of contents. The users who want more in-depth information are the ones spending the extra 20% of time.

Also, the goal of writing and editing content on Wikipedia pages is not to increase SEO, it's to provide comprehensive information on a topic. So I think that for Wikipedia, UX guidelines should be given greater weight than SEO guidelines, when considering how to organize content on a page. Clarissa Peterson (talk) 20:53, 28 August 2012 (UTC)

  • Quote: What you are saying about above the fold is not a contradiction to what I'm saying.
  • What I said was that most people look only above the fold, and only for about 15 sec., in deciding whether to stay or move on. If you use analytics, you will find that 50-70% of people who visit a web page bounce within about 15 sec.—they do not stick around to look at what is below the fold. The nice picture (like you added at the top)—and the subheadings that were your idea—will surely result in more pageviews and probably also more people reading more of the page, though Wikipedia doesn't seem to have "average time on page" (or %bounce) stats. that analytics would give. As you can see, pageviews are up from a peak of over 1,750 to a peak of over 2,000—so I think the eye candy made a difference. I might do some work on the humongous "Progressive Enhancement" article, which has a lot of out-of-date stuff, and really deserves better. Supporting "tapping" rather than just "clicking"—and adding "hover" effects for desktops that support it—are forms of progressive enhancement. But I'm swamped with other stuff at the moment, so it may have to wait a while. LittleBen (talk) 03:10, 29 August 2012 (UTC)
  • Quote: the goal of writing and editing content on Wikipedia pages is not to increase SEO.
  • I have answered that at Wikipedia talk:Article titles#Google Insights. I'd summarize my reply to "SEO is irrelevant" as, "if people don't read what you've written, then you've wasted your time writing it". Improving the user experience, improving the writing and focus of the content, and making it easy to see an overview of the contents "above the fold" are likely to greatly improve SEO.
  • PS: If you don't mind, I'll abbreviate some of the top of the talk page by commenting it out in the HTML. Nothing will be changed, it will just not be visible to the average user. The talk page is getting so long as to be intimidating. LittleBen (talk) 03:48, 29 August 2012 (UTC)

I fleshed out the info on responsive advertising to go into more detail. You may have additional viewpoints to add. I am going to try to add to other sections of the page when I have time.

It's okay with me if you comment out some of the talk page. I don't know how that is usually done, is there a note that content has been removed so that people can know it's there?

I wasn't saying that SEO is irrelevent. I was saying that for Wikipedia, writing good and useful information should be higher priority than following SEO guidelines that may be contrary to user experience guidelines. Again, I don't think we disagree. This page is already one of the top results in Google for "responsive design" so I don't think it's necessary to put a lot of effort into optimizing for search engines. Good user experience frequently results in good search engine placement. Clarissa Peterson (talk) 20:09, 29 August 2012 (UTC)

  • You can see in the HTML which parts of this talk page are commented out (much of the very long discussion on the Marcotte image) via the History tab.
  • You added far too much detail about ad pricing models, copied from the references. It's better just to link to detailed, off-tangent articles, and let people check them out if they are interested—rather than force people to wade through a lot of detail that is about advertisements rather than RWD (most of the article is theorizing about how ads might be handled in future). I think I have seen a Google developer article on ads and RWD; will try to find it and add it in.
  • Wow, 50% jump to 2,500 pageviews. LittleBen (talk) 03:42, 30 August 2012 (UTC)

Little Ben is clearly trying to be manipulative. This is not Reality TV, so "ratings" are not what we are after. Also suspect that he (or his buddies) are playing around here. This whole article reads like an ad for a couple of book authors and some dubious blobs of Javascript (e.g. jQuery, Modernizr). And this after he deleted my "talk". I suspect Little Ben works for this Marcotte guy's publisher.

It's clear that my changes *explain* the related concepts far better than plugs for jQuery and the like. And pixels are *not* absolute units. The revert-er of *that* change should have followed the link. Clearly accuracy had no impact on the revised ratings.

As the "third opinion" said, Little Ben needs to stop reverting my changes wholesale. This is not his own personal playground. — Preceding unsigned comment added by 75.186.15.4 (talk) 18:18, 21 September 2012 (UTC)

Edit warring[edit]

Respond if you must, but please do not delete discussion entries--was not unsigned either (see above). The bot signed it for me. Thanks!

As now explained twice, the section that you deleted is called "Related Concepts" and describes how Media query support (required for a RWD design) and maybe HTML5 support are tested for, and how support can be added (by "polyfills") to browsers that don't support them like IE8 (see Ref. 5). If you still can't understand this then you would be well advised to stop vandalizing the page, and revert-warring, or your IP will be blocked. LittleBen (talk) 10:04, 7 September 2012 (UTC)

I'm not "revert warring". I asked you to take it to the talk page. Now that you are here, see that I did your work for you by rewriting the paragraph to link to appropriate Wiki articles. You clearly do not understand topics like feature detection, feature testing, cross-browser scripting, browser detection, etc. and that topics like "polyfills" are too specific for the "related concept" section. Please leave that section to somebody who does.

And certainly the links to jQuery Mobile, etc. were out of place. Those are dubious JS libraries and have nothing specific to do with this topic. If you like, you can link to a general "Javascript Libraries" page.

If you continue to Spam this page with confused (and confusing) non-technical nonsense, then you will be banned. How do you like that? -David Mark 75.186.15.4 (talk) 14:28, 7 September 2012 (UTC)

I created this page essentially from nothing back at the end of January. You might like to look at the page ratings at the bottom of the page (which reflect the ratings before you started editing it). You might also like to look at the pageview statistics on the history page. It should be obvious that a lot of people do not consider the page to be rubbish. Your opinion that jQuery Mobile is a "dubious JS library" and that "polyfills" are too specific would not make any sense to anybody who is even slightly knowledgeable about the web. LittleBen (talk) 17:22, 7 September 2012 (UTC)

Your opinion that jQuery Mobile is a "dubious JS library" and that "polyfills" are too specific would not make any sense to anybody who is even slightly knowledgeable about the web.

This is simply false. jQuery Mobile is counterproductive to mobile development. This is evinced by its requirement for the jQuery library (250 kB+ unobfuscated) along with the jQuery Mobile library itself (230 kB+ unobfuscated). Sending 400 kB+ of script to a mobile device, let along a desktop device, is lunacy.
Polyfills are troubling as well because they are inherently naïve in design. They provide poor browser support as they rely on very specific host implementations; they are also often written sloppily, with a very limited subset of browsers in mind. Consequently they are unsuitable for reference, which David correctly pointed out.
As someone who has successfully written a comprehensive DOM library and can support dozens of browsers, I hereby rest my case. Mkmcdonald (talk) 20:18, 21 September 2012 (UTC)
WP:OWN still applies. If you don't want your additions edited, then get a blog instead. Andy Dingley (talk) 17:55, 7 September 2012 (UTC)
Searchtool-80%.png Response to third opinion request:
Hi. First off, nothing here could be considered vandalism or spam, so please stop throwing around unfounded accusations. I think there is room in the article for coverage of feature probing techniques, the use of libraries like jQuery, and the polyfil techniques that either approach might use. David/75.186.15.4, try to avoid editorializing against the use of libraries. There are advantages and disadvantages to each approach, neither one is "right" or "wrong". That said, I think most of the IP's additions have been constructive and have improved the article, so they should not be reverted. The bias against the use of libraries can be balanced by adding objective facts on the advantages and disadvantages, and very selectively editing statements of opinion. On an unrelated style note, section headers should be upper case first letter only, not every word. Hope this helps, and remember, focus on the content instead of making accusations.Gigs (talk) 18:10, 7 September 2012 (UTC)

His comment that jQuery Mobile is a "dubious JS library" shows that he has very little subject knowledge, yet he is making insulting comments like "Please leave that section to somebody who does", edit warring, and repeating threats like "If you continue to Spam this page with confused (and confusing) non-technical nonsense, then you will be banned". He surely needs educating that such behavior is not acceptable. LittleBen (talk) 18:20, 7 September 2012 (UTC)

It seems to me that you are both knowledgeable in this area. You both got off on the wrong foot, he called your content nonsense, you called his edits vandalism. Please try to get over the personal issues so that you can both concentrate on the content. Gigs (talk) 18:30, 7 September 2012 (UTC)
  • Thanks. I'll try, but I don't think that he is capable of discussing it—I had to explain the basics to him a couple of times; he didn't understand. LittleBen (talk) 18:38, 7 September 2012 (UTC)
  • Before all the rubbish was added to the page, the page ratings were Trustworthy: 3.5, Objective: 4.5, Complete: 4.0, Well written: 4.5
  • The rambling rubbish that was added has caused the page ratings to plummet to Trustworthy: 3, Objective: 1.0, Complete: 4.0, Well written: 2.0   Wikipedia readers are obviously pretty knowledgeable ;-)
  • Now that I've fixed the problems, let's see the ratings skyrocket (if he doesn't mess with it again). LittleBen (talk) 11:23, 11 September 2012 (UTC)
  • Trustworthy: 5.0, Objective: 5.0, Complete: 5.0, Well written: 5.0, as of 19 Sept. Thank you, kind people! LittleBen (talk) 03:24, 20 September 2012 (UTC)

Nobody cares about your manipulations (see comments above). You bulk-reverted a lot of good information, simply because you either did not understand it (seems likely) or you are trying to treat this page like an infomercial. Anybody can massage "ratings" and then claim that they validate invalid opinions.

He appears to be at it again. I monitored the ratings for the first hour or so after adding my useful information back in to the article. About an hour later, it appears "Little Ben" noticed the changes as a tsunami of negative ratings poured in all at once. He'll try to use that "feedback" to "prove" that his edits are preferable (which is laughable as they don't say much of anything compared to mine). — Preceding unsigned comment added by 75.186.15.4 (talk) 20:50, 21 September 2012 (UTC)

I really think "Little Ben" is a disingenuous contributor. One thing is for sure, he doesn't know much of anything about Web design (responsive in particular). It's certainly not about downloading JS libraries. — Preceding unsigned comment added by 75.186.15.4 (talk) 18:22, 21 September 2012 (UTC)

Propagation of Misinformation[edit]

As someone who has seen misinformation, especially on Wikipedia, virally infect the Web/JavaScript community, I hereby urge any participating members to be wary of edits referencing third-party APIs as magic bullets. Responsive Web Design is perfectly easy to enable without third-party APIs. It has existed in the form of liquid layouts well before CSS 3 became abuzz. Also, the predilection towards name-dropping is worrisome. As I mentioned earlier, Responsive Web Design is a strategy that has evolved over the past decade or so. No one single human deserves credit for it: the community that fostered it does.

The History section appears to be one cohesive marketing pitch. I would scrap all of it, save for the first sentence. Commentary on how the technology existed long before the moniker was coined (as with AJAX) would be an adequate replacement. The current state, which borders on false attribution, is biased. Mkmcdonald (talk) 20:44, 21 September 2012 (UTC)

  • I would disagree that Responsive Web Design is the same thing as liquid or fluid layouts. They have similar goals, but there are additional features in RWD that weren't available before. AIUI, the single, crucial difference is that RWD involves a server-based, or HTTP-based,[note 1] selection of different transmitted content to the client. Fluid layout did not require this: fluid layouts instead used a single description of the styling, annotated this with a mix of absolute and relative units together with a specification for floating behaviour, then allowed the client's rendering engine to make its best attempt at it. Fluid layouts did specify a linear, logical order for content units (HTML documents are still serial files), but they no longer attempted to enforce a rigid two-dimensional grid of relative[note 2] positions. Andy Dingley (talk) 09:28, 23 September 2012 (UTC)

It's not *just* liquid (AKA fluid) layouts, but that's one big part of it. According to the article (and ostensibly the book that it is based on), the other parts are "use EM's" (even for images, which doesn't make a lot of sense to me) and "use media queries" (which were predated by "handheld" media style sheets).

Finally, anything that requires the server to guess about client capabilities (e.g. to send different content to the client) is going to require browser sniffing (and on the server side to boot). That's nothing new (and certainly nothing good). If "RWD" recommends such strategies, it is yet another indication that it is a dubious amalgamation of extant techniques (both good and bad). There were "solutions" at the turn of the century that tried to send smaller images, black and white images, alternate scripts and style sheets, etc. to small screen devices by sniffing the optional and arbitrary UA header.

Further reading:

https://gist.github.com/3768460

And, contrary to Little Ben's opinion, I have a lot of experience in these matters. I use these techniques, but I don't write about them in blogs.

Notes
  1. ^ This may be done, and was done under CSS2, by using @media selectors on a linked external stylesheet, the client device then choosing whether to request different stylesheets, or not, by HTTP.
  2. ^ "relative" in the traditional geometric sense, rather than necessarily implying the CSS positioning mode.

Pixels as absolute units[edit]

Opinions (and references) please. Append you comments, please don't edit or delete those of others. Andy Dingley (talk) 19:58, 22 September 2012 (UTC)

Somewhere in a vast section of unhelpful snarking below, LittleBenW posted the following source for pixels as being an absolute unit.
I would note that this is still only a draft recommendation, however pixels have been considered an absolute unit in the W3C CSS trail as far back as anything I can see. Andy Dingley (talk) 09:17, 23 September 2012 (UTC)
Pixels are relative units insofar as they rely upon screen resolution. This is measured via the “dpi” (dots per inch) measurement. 72 dpi indicates 72 “dots” (hitherto pixels) per inch. Likewise 96 dpi indicates 96 dots per inch. See: Pixel Density/Pixels Per Inch. This is a widely known metric in the printing industry. Mkmcdonald (talk) 13:09, 23 September 2012 (UTC)
We're not doing printing, we're rendering to a video board. A video device built of pixels.
Note that the W3C (generally considered to know something about web issues) consider pixels to be absolute. Andy Dingley (talk) 14:11, 23 September 2012 (UTC)
  • Pixels are dots; pixel density in dpi (dots per inch) is a completely different unit. Neither is measured as a ratio or percentage, so neither is relative. But your relatives may disagree.
  • Relative units are also known as dimensionless units. LittleBen (talk) 16:34, 23 September 2012 (UTC)

You are misinterpreting the W3C's page, which is aimed at browser developers. See your own Wikibook (cited), for an explanation of why pixels have been considered relative units in CSS for as far back as I can remember. I was surprised to see the wording in the specs and it appears they flip-flopped on their definition at some point. Ask anyone who uses CSS (as opposed to people who program browsers to apply CSS).

https://www.google.com/search?q=CSS+"pixels+are+relative+units"

See what I mean? Over a decade of CSS developers (and usability experts) explaining how pixels are relative, not absolute units. The semantics change in the specification is irrelevant (and clearly being misinterpreted here). Just goes to show that laymen shouldn't try to interpret technical specifications. ;) — Preceding unsigned comment added by 75.186.15.4 (talk) 18:39, 24 September 2012 (UTC)

  • I have cited the W3C and the UN to show that pixels are absolute (fixed) units: neither the web developer nor the browser user can change the physical size of a pixel, it is fixed by the device. The Em and Ex are relative units (measured relative to the font size)—the web developer or the browser user can change their physical size by varying the size of the font. LittleBen (talk) 13:42, 8 October 2012 (UTC)

Verifiability, Relative Units, Pixels, and Propagation of Misinformation[edit]

  • Back on 11th Sept. User:Ondrejsv reverted claims that pixels are relative units. The Wikipedia rule on Verifiability say that any claims you make must be supported by reliable references. Most educated people know that relative measurements are in percentage or ratio units. Probably you haven't heard of the W3C (Sec. 5.2) or the United Nations, but—as you can see—they say that pixels (px) are absolute or fixed units, not relative. Pixels are relative if you have a relative called Mr. Pixel or Ms. Pixel, but that would still not be a universally-true theory of relativity ;-). Also be sure to read Wikipedia rules on no original opinions and WP:NPOV.
  • The writing of the additions can best be described as "highly-opinionated pseudoscientific technospeak gobbledegook". There are no Wikilinks to explain terms that you pull out of the sky, and no references to support your opinion (or your confusion). For example:
  • "It is often preferable to use CSS background images that can be switched by media queries and/or handheld style sheets, which can also ensure that layouts don't break (e.g. images displaying outside of their boxes)" does not cite any references.
  • The "Confusion and Unobtrusive Javascript" section does not cite any references. Why don't you try to add such confusion to the Unobtrusive Javascript article? You say that "With regard to scripting, progressive enhancement is generally preferred over graceful degradation; however, the strategies are not mutually exclusive", but do not provide any references to support this claim.
  • "A JavaScript library is not required to use, and may in fact inhibit, feature detection and testing" does not cite any references. You have removed references to jQuery, JQuery Mobile, and Modernizr without giving any reasons or references that support your viewpoint.
  • Wikipedia is not about your personal dislikes—something like (for example), "(I dislike) every major DOM library because each API listed is either poorly designed or a complete waste of time" is not a neutral POV that is supported by reliable references, and so is not acceptable on Wikipedia. Likewise, "I like Internet Explorer".
  • A tutorial on "Conditional comments in Internet Explorer" surely does not belong in an article on Responsive Web Design. Wikipedia is not a tutorial, and not an indiscriminate collection of unrelated information.
  • "Many older and lesser mobile devices do not support media queries, but a significant number support "handheld" media style sheets (and have since the early part of the century)": again doesn't provide any references showing that browsers of most mobile phones supported "handheld" media style sheets in year 2000.
  • The claim that RESS and SASS “techniques are hobbled by browser sniffing” is not supported by any references. A Google reference in this section explains that, “Javascript can be used to display different ad variants on a page”, but you comment that, “unfortunately, this approach requires browser sniffing at some point and is therefore impractical”—without giving any references that show this and prove Google to be stupid.
  • You are welcome to parade your total ignorance for a few days, to give you time to find reliable references that support your views, and to give people time to have a laugh (even though it's not April 1st), and then everything that is opinionated pseudoscientific technospeak gobbledegook, devoid of any supporting references or Wikilinks, will be reverted. LittleBen (talk) 10:20, 23 September 2012 (UTC)
You seem content to widely generalise to support your points. Such assertions as “[most educated people agree with me]” have no basis in reality.
I refuted the claim of pixels being absolute units earlier. Any one that is sceptical of the unit’s relativity can find many more links from the print industry and beyond via search engines. What *is* absolute, is that the pixel’s size is dependent upon the input device.
Your call for more references is being received, but I must stress that your partisan tactics are counterproductive. Earlier I did, in fact, provide evidence as to why jQuery Mobile, and by proxy jQuery, are unsuitable for mobile or low-powered devices. The giant mass of script can overload the client and cause the browser to become unresponsive or crash. More powerful devices will have their batteries drained and performance slashed. A logical conclusion is that mobile devices should receive a minimal amount of script. This is advocated by the W3C, specifically, here:

Even where a device does support scripting, do not use it unless there is no other way of accomplishing your objectives. Scripting increases power consumption and so decreases battery life

For more, see: W3C Mobile Web Best Practices.
Furthermore I would like to notify viewers of this page that this snippet:

Wikipedia is not about your personal dislikes—something like (for example), "(I dislike) every major DOM library because each API listed is either poorly designed or a complete waste of time"

has been taken out of context from a personal Web profile of mine in what appears to be an attempt at character assassination. Again, I urge participating members to be wary. There is clearly an agenda behind some activity here.
Finally, I will comment on the thought the Google is a source of poor JavaScript. It is true that Google has a predilection towards poor, often lazy JavaScript. Testing various Google Web services in less capable browsers can easily lead one to the conclusion that they are poorly written. Also note how Google often “deprecates” browsers at will. Another point to note is Google’s constant attacks on JavaScript. First, Google Web Toolkit: a compiler for Java to create JavaScript; second, Google Dart: an alternative to JavaScript that only Google supports. I would not lend credence to a company that heavily relies upon Java-to-JavaScript compilation just to deliver JavaScript for its Web services. Mkmcdonald (talk) 13:54, 23 September 2012 (UTC)
  • What about CoffeeScript? Do you prefer BeerScript? LittleBen (talk) 15:31, 23 September 2012 (UTC)

Let's be civil[edit]

OK guys. I have come here because a third opinion was requested at WP:3O. I have a number of things to say:

  1. I think this might not be appropriate for 3O, so I have left a message at Wikipedia talk:WikiProject Internet#Relative units in the context of responsive web design to see if anyone there wants to help out.
  2. Please be WP:CIVIL to each other. When one person is dissmissive of the other it just encourages them to be be dissmissive in return and then you just find it harder to agree.
  3. I have not read any of the sources cited, but I am hoping that someone at WikiProject Internet will.
  4. From my ignorant perspective either of you could be correct. I suspect that you will find some people who consider pixels to be absolute units and others who consider inches and cm to be absolute, in which case pixels are relative. It may be the case that you want to just tell it like it is: "Important body X describes pixels as absolute units. Well-used manual Y describes inches as absolute and conders pixels to be relative."

Yaris678 (talk) 11:59, 25 September 2012 (UTC)

Browser sniffing, what is it?[edit]

For the sake of avoiding argument, can we agree a definition of this?

Does it require (as a defining condition) any or all of the following:

  • Executable code
  • Executable code that executes on the client
  • Executable code that executes on the server

Responding to:

  • Discernible differences in the client
  • Differences in the client that express varying capacities or features (presence or absence)
  • Differences in the client that express attributes as a scalar value (i.e. window size)
  • Differences in the client's identity of a device, platform, or browser (where this otherwise arbitrary identity is used as a basis for further judgements, based on implied abilities).

We don't need to agree a definition as to whether browser sniffing is good or bad, although we appear to agree on this.

Otherwise I see future ping-pong wars over whether some aspects of contemporary RWD are seen as sniffing (and thus implicitly bad) or are outside the definition of sniffing (and thus might be good). Andy Dingley (talk) 15:57, 8 October 2012 (UTC)

  • Browser sniffing is described in Wikipedia and is Wikilinked in the article. In essence it's a way of asking the browser to tell you its name and major version. A browser can lie about this. And even if you knew that a particular version of a particular browser did not support a particular feature at a certain point in time, this does not mean (or did not used to mean) that there won't (wouldn't) be an update with the same version number that fixes (fixed) the problem later on. So it's unreliable. LittleBen (talk) 16:26, 8 October 2012 (UTC)
WP isn't a reliable source.
I take it from this comment that you would thus not describe techniques of "RWD" as browser sniffing, nor rule them out on that basis, if a server-side operation is performed to test the client's abilities or scalar attributes, and serve varying content on that basis. Andy Dingley (talk) 16:46, 8 October 2012 (UTC)
  • Quote: WP isn't a reliable source: true, but it's not always wrong either.
  • As the article explains, if you have to support slow circuits and low-end mobile phones (and such conditions still exist in poorer countries), then browser sniffing "guestimation" or device detection (using up-to-date device databases) can be the simplest way. Simple "browser sniffing" has mostly been replaced by "(mobile) device detection". (List of HTTP header fields shows "User-Agent", which includes OS info., and "X-Wap-Profile" for mobile devices—more info. than just the browser version). The two comments like “X techniques are hobbled by browser sniffing” were opinionated, unsubstantiated, and factually incorrect (pure rubbish). With faster devices that support client-side JavaScript, that can be used to test support for features. However, server-side feature detection is also possible, as linked to from the RESS references.
  • Javascript-based web analytics like Google Analytics can give statistics for the OS, browser, screen size, even mobile device types and the like for visitors to a web site (using a mixture of the methods described above). LittleBen (talk) 15:26, 9 October 2012 (UTC)

Little Ben, you only cite people that seem to agree with whatever point you are trying to make (often hard to tell what that point is). Whether you do attempt to pigeonhole browsers by UA, other headers or whatever, you are ten years (at least) behind the times. This point was conceded around the turn of the century (which you would know if you bothered to read my numerous citations). None of my points are theoretical; I've been working in this industry for almost twenty years and am quite familiar with the gap between reality and whatever buzzwords the bloggers are pushing this week. Get some experience (or talk to anyone with experience) and then you'll see I am right. Apology accepted in advance. :) 75.186.15.4 (talk) 02:19, 7 January 2013 (UTC)

"With faster devices that support client-side JavaScript, that can be used to test support for features" -Little Ben (of Wikipedia fame) This is what I'm talking about. :( 75.186.15.4 (talk) 02:21, 7 January 2013 (UTC)

In answer to the questions posed: there is both client and server side browser sniffing. The former relies on an optional and non-standard DOM property and the other an optional header (or multiple headers as the case may be). Both are losing propositions, no matter how many losers out there use them (that's sort of the definition of a losing proposition, isn't it?)

The nonsense that starts with "In faster devices..." is typical "Little Ben" brand gobbledygook. And there's no server side feature detection for browsers. Doesn't matter what he's linked to or how he misinterpreted its meaning. It doesn't even make sense.

Here is an article on browser sniffing, written by Richard Cornford (a noted expert on cross-browser scripting).

http://jibbering.com/faq/notes/detect-browser/ 75.186.15.4 (talk) 02:28, 7 January 2013 (UTC)

HTMLSliceMate spam[edit]

Raised at Wikipedia_talk:WikiProject_Spam#Responsive_web_design_and_persistent_EL_to_Responsive_Testing_Tool Andy Dingley (talk) 12:26, 27 November 2012 (UTC)

Reactive Web Design[edit]

  • This is a reply to User talk:LittleBenW#Responsive web design .28reactive web design.29.
  • I had never heard of Reactive Web Design, and—according to Google—the most reliable reference appears to be here: this opinion piece coins the term Reactive Web Design to describe a web page that changes depending on a (e.g. mobile) viewer's location—a local person would get a different page than an overseas visitor or someone located some distance from the location of the cinema or other business that has the web site.
  • This concept is quite different from Responsive Web Design. Google advertising is capable of sending a visitor who clicks an AdWords Ad to different URLs depending on whether they are a mobile or desktop user—for example: someone who is using a mobile to find a site dealing in locks is likely to be locked out of a car or house, whereas someone using a desktop is more likely to be thinking of copying a key or changing a lock, for example. But I've never heard this called Reactive Web Design.
  • If you work for the web company called Reactive then please be aware of Wikipedia rules on COILittleBen (talk) 12:00, 10 December 2012 (UTC)

Try again Little Ben[edit]

Or don't. You don't understand any of what you are editing. That much is clear. Basically, you put back all of your original (and laughable) gobbledygook. You clearly don't understand the terms, patterns or why it is idiotic to reference jQuery in an article about RWD. Leave it alone until such time as you do. Blithering about perceived violations of Wikimedia policy is no substitute for knowing the source material. ;) — Preceding unsigned comment added by 75.186.15.4 (talk) 01:54, 7 January 2013 (UTC)

The comment when reverting the bit about handheld style sheets says it all. It's an old quote from noted "mobile strategist" PPK. Word of advice: don't blindly cite that guy as he's often confused (much like Little Ben).

Read the bit about handheld style sheets again. What did I say about them? Why were PPK and many fellow bloggers confused? Do you get the point now?

https://gist.github.com/3768460

Finally, where do they fit in today (hint: see the helpful examples in the article)? Yes, the ones you keep deleting.

Then there's the revert where you translated my warning about monolithic JS libraries being too large and slow for battery-powered mobile devices to:

"All Libraries are Evil".

That's when I know I'm talking to a pinhead. Re-read and try to understand it this time, yes? :)

75.186.15.4 (talk) 02:39, 7 January 2013 (UTC)

  • If you want to post statements like "All Libraries are Evil", then you need to quote a reliable source that says "All Libraries are Evil". Or you could try trashing Wikipedia articles on libraries, or inserting such statements in them, and get yourself blocked.
  • Maybe you have never heard of WURFL, etc? WURFL is not Waffle, please don't be confused. LittleBen (talk) 13:26, 7 January 2013 (UTC)

Responsive theme for Wikipedia[edit]

I feel like there should be a responsive design for Wikipedia. If one is already out there, it should be noted here. However, I do not know if there is one out there, and on a first search I could not find one. I could make a responsive design for Wikipedia via the User:css and UserJs pages (i.e. doing so is within my skill set), but I thought I'd mention it here first to see if one already exists. Does anyone know of one? Zubachi (talk) 15:49, 14 February 2013 (UTC)

  • Please start new talk page sections after the last existing section (I've just moved this to the bottom).
  • If you resize the width of your browser window, you will find that the Wikipedia page also resizes, however at present I don't think that images are fluid.
  • I believe that there's a mobile-specific Wikipedia site, though I haven't used it.
  • You may be interested in the discussions at Wikipedia talk:2012 main page redesign proposal. LittleBen (talk) 16:11, 14 February 2013 (UTC)
    • I know that Wikipedia is fluid-width. But if I'm on a 13-inch screen and split two windows on the left & right of my screen, that leaves very little room for actual Wikipedia content. I find myself using the mobile version more and more often, actually; it's very well designed. The main theme should be made more like that, in my opinion. Similar to the responsiveness of Bootstrap. Zubachi (talk) 00:39, 15 February 2013 (UTC)

How to make Responsive web design tutorial[edit]

S2ptech (talk) 07:53, 16 April 2013 (UTC)

Sorry but spam links have no place on Wikipedia --Biker Biker (talk) 09:26, 16 April 2013 (UTC)

"NoMoreLinks"[edit]

While cross-linking this page to tableless web design (the original Responsive Web Design approach), I noticed a glaring admonition that reads: "DO NOT ADD MORE LINKS TO THIS ARTICLE. WIKIPEDIA IS NOT A COLLECTION OF LINKS ". Partly affronted by the ALL CAPS, and partly affronted by what I see as stifling behavior, I propose a solution that may allow for continued development of this resource and other resources linked to it. Notability guidelines are important.

How about we:

Wes Turner (talk) 20:28, 17 July 2013 (UTC)

Additional external meta-resources[edit]

Wes Turner (talk) 20:27, 17 July 2013 (UTC)

Responsive design / responsive web design[edit]

This article has a redirect from Responsive design to Responsive web design - since the theory and terminology of responsive design predates its usage on websites (eg, in architecture), shouldn't Responsive design be its own page which has links to other implementations? Star-one (talk) 14:52, 17 January 2014 (UTC)

I'm assuming lack of response as being assent to this proposal, so I shall get to work in due course. Star-one (talk) 17:20, 28 January 2014 (UTC)