Why you should move that button 3px to the left - <AUTHOR> http://www.gv.com/lib/design-details <comment><USER3> So why should you move that button? The article doesn't actually answer the question. If a UX designer just says "move the button by 3px because it looks nicer", then there is a good chance that someone higher up the hierarchy will say move the button by 4px because that looks better. And since neither of them are able to actually justify their reasons beyond some vapid and subjective claim of making the product "more delightful", the person with more seniority wins.

Contrast this with the engineering version of this debate where the decision between using foosort and barsort can be decided based on which one results in lower CPU usage. Or a UI element is moved 3px because it allows reducing the depth of the UI widget tree which improves the FPS by X during complex animations. Or that a button's bg shouldn't be #282828 because of the problems with 16-bit color.

The other big problem with quibbling over 3px in Photoshop mocks is that the mocks tend to be designed on high dpi displays using Photoshop or Illustrator which do not need to handle realtime rendering so they use high quality antialiasing and scaling. When the mocks are implemented, the final product is viewed on a multitude of devices with different rendering characteristics. So the 3px change might result in a blurry line because the widget no longer snaps to the pixel grid of the lower resolution device after the system scales the image to handle resolution independence.

So if a designer asks for a 3px change without justification, then the engineer should push back until a good reason is given. There are objective aspects to UI and subjective aspects. Discussing the former is straightforward and the decisions are relatively easy to make. But discussing the latter quickly degenerates into bikeshedding.

<comment><USER4> _And since neither of them are able to actually justify their reasons beyond some vapid and subjective claim of making the product "more delightful"_

Do you appreciate the irony that you just wrote a whole post about making decisions objectively, in which you have essentially dismissed designers as ignorants who just make arbitrary decisions according to their personal whimsy, based on a series of unsubstantiated claims, out-of-date stereotypes, and straw man arguments that any half-decent designer could have corrected for you in moments?

Why would you think a designer would have no justification for a change beyond "it looks nice"? What would you assume designers don't understand issues like pixel alignment or designing for multiple devices? Why would you think designers would be raising these issues based on Photoshop mock-ups?

Do you understand that there is actual research underpinning a lot of design theory, demonstrating both how humans respond to different design choices and the fact that those choices can directly and sometimes dramatically affect metrics you care about like conversion and retention rates?

 _So if a designer asks for a 3px change without justification, then the engineer should push back until a good reason is given._

I wonder how you'd feel if you as a developer were told that every line of code you wanted to change — even those with obvious bugs — could not be touched unless you had previously demonstrated why you expect a measurable benefit to the satisfaction of the business development staff, and that your commit access was going to be revoked and every change would have to be made by bizdev after someone who didn't know anything about programming decided whether it was justified.

<comment><USER3> _Why would you think a designer would have no justification for a change beyond "it looks nice"? What would you assume designers don't understand issues like pixel alignment or designing for multiple devices? Why would you think designers would be raising these issues based on Photoshop mock-ups?_

Experience. I've had arbitrary requests made based on Photoshop mocks. I've pushed back against them after showing that the proposed design looks blurry on devices with a low dpi. Or showing that the UI breaks down in edges cases where the text field contains more text than what is shown in the mocks which results in unwanted wrapping. These are issues that can only be understood by someone who knows the implementation details and constraints of the underlying OS that does the final work of rendering the UI rather than relying on the constraints of Photoshop.

 _Do you understand that there is actual research underpinning a lot of design theory, demonstrating both how humans respond to different design choices and the fact that those choices can directly and sometimes dramatically affect metrics you care about like conversion and retention rates?_

Yes. And good UX designers know this research which is why they can quickly justify their choices.

<comment><USER4> It sounds like your real problem has nothing to do with a "design version" or an "engineering version" of anything. You've just worked with some people who were in a design role but didn't know how to do it. That's unfortunate, but I don't think it invalidates the original premise of the article that paying attention to seemingly minor design details matters more than a lot of non- designers tend to acknowledge.

<comment><USER5> I have yet to see a proposed application design or cosmetic change whose justification does not ultimately rely on "this guy's taste is better than that guy's" \-- yes designers do sometimes bring out some justifications which are expressed with objective sensibilities but to me they always seem to be rationalizations, in the same way that evolutionary psych seems to be. That is, first see a behavior or a look that seems appealing, then figure out which design principles are making it seem better. I think the best designers temper their taste and predilections with judicious application of statistical methods such as split-testing.

I don't find anything objectionable about this, as long as the designer _actually owns_ the design and has the fortitude and clout within the organization to defend their changes. Design seems to me an art in many respects, so some decisions will come down to a matter of taste in the end. Like any successful artist, the designer then will need the persistence to defend their vision against the meddling of bike-shedders.

I also think @sxp's characterization of the objectivity of engineering decisions leaves too much out. Engineering debates rarely come down to foosort() v. barsort(), where one obviously performs better. More often, they come down to questions like "should we be passing this argument first or last?", "what should these methods be named?", "can this code be extracted into its own module?" \-- in other words, how to design the code.

<comment><USER6> You're not working with properly trained designers then. Layouts have certain empirical properties which can be judged objectively:

      * Conforms to a grid
      * Internally consistent padding and margins
      * Information sized and arranged hierarchically according to importance
      * Proportions conform to the rule of thirds or golden ratio
      * Internally consistent UX patterns
        (eg cancel buttons might be always red, confirm buttons might be always green)
      * Text column widths are not too wide
      * Color choice is harmonious (conforms to color wheel rules)

These are the main ones but there are many others. Unfortunately, these kind of classic design principles don't seem to be taught very often these days, instead design courses focus on the mechanics ie how to use Photoshop.

<comment><USER7> Is there strong scientific evidence that when one of these is slightly violated, it will negatively impact the user?

<comment><USER4> The short answer is no, slight violations of these ideas don't tend to cause the sky to fall. Indeed, the list of examples given by nikatwork was unfortunate, because some of them are well established with a decent evidence base, but a few are basically just nonsense that has unfortunately somehow become dogma.

For example, a few studies have been performed under controlled conditions to try to determine how typographic details like line length affect measurable performance levels such as reading speed and retention. There are many rules of thumb floating around — "2.5 alphabets", "8–10 words", and the like — and it actually does turn out that most of them are reasonable. It also turns out to be unwise to consider line length in isolation, that a wider range of lengths can be used before serious degradation is widely observed than some of the old folklore would suggest, and that having lines too short can also cause serious degradation in reading performance, among other interesting results.

Another good example is the consistency of user interface elements. Numerous usability tests, from formal studies to simple A/B tests on web sites, support the theory that violating a user's expectations tends to have negative effects, sometimes severe ones. Of course you always have to be careful not to assume too much about what your users' expectations might be, but things like using green for cancel and red for confirm almost invariably exhibit poor performance with audiences who are used to the opposite convention.

On the other hand, if someone tells you the Golden Ratio is important for keeping some sort of page area proportionate, it's a good bet that this person should be hunted down and locked away by the maths police. Using precise ratios really does matter in some contexts: if you look at the ratio between the width and height of a piece of A4 paper, it is aiming for exactly √2, which is why two A4 sheets fit neatly into one A3 sheet and so on up and down the scale. However, someone who is advocating use of the Golden Ratio for width/height proportions usually just likes the look of dimensions that are proportioned roughly 5:3, and probably has no hard data to support choosing that over 3:2, 16:9, 1:1, or any other ratio that fits with the rest of the design.

Likewise, if someone advocates picking a colour scheme based on where certain hues fall on a wheel, consider that hue represents only one dimension. The most common colour models for human vision use three, and in practice if you fix the others (typically saturation and lightness) and just choose evenly spaced and/or opposing hues around a colour wheel, the results are rarely good. That means much repeated ideas like choosing analogous or complementary colours are, at best, only part of the story. If you're using a typical colour wheel for computer graphics that has red, green and blue at 120 degree separations and then cyan, magenta and yellow on the 60s, those ideas are even less helpful, because it turns out that by the time the human eye has detected the light and the human brain has interpreted the resulting signals, those colours aren't really uniformly spaced around the wheel anyway; see the trichromatic vision and opponent process theories, or the early experimental work of Munsell.

In short, there really is robust evidence that some established design principles are worth following, though rarely do minor variations in design cause major variations in performance. However, there are also some dogmatic assumptions in the design world that get passed on as if they are inalienable truths but in reality have little evidence to support them.

<comment><USER6> We're talking at cross-purposes here. My point is that if someone hands me a layout with wildly inconsistent internal margins, no call to action and a text column that is a full screen width wide, I can objectively say those elements are wrong and need to be fixed.

Of course, the other side to design is "style", which cannot really be quantified, merely subjectively judged against current trends, the target audience and "taste".

<comment><USER4> Apologies if I misunderstood your previous post. From your final paragraph before, I thought you were arguing that the properties you listed were not only things that could be judged objectively but also desirable principles that should be taught as part of design courses. I was countering that this would have been OK for some of the items but dubious for a few others, because while they are widely held and promoted beliefs in some quarters, they are also examples of things many designers say that _aren't_ backed up by rational arguments or empirical data.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> This is a fantastic article.

To people below who say the designer should make the change him or helself -- as a front-end developer, I say a million times, NO NO NO. Does the designer know how to use git and commit properly? Do they know on what branch? Understand the deployment schedule? Perform browser testing? Are they part of code reviews? Do they understand whether that rule is used by just that component, or just that page, or if it will affect code elsewhere?

I think it's _great_ when designers know enough to code the CSS of their own portfolio or blog, and can converse fluently about the concepts. But unless they're true hybrid designer-coders who are participating fully in dev meetings, please DO NOT touch the code. I've seen sites break too many times before, because a designer changed something they didn't understand, and which there was no reason for them to understand anyways. (And to anybody who would say a designer should understand their tools, well it's not like most print designers can operate a printing press either. Design professionals design, and generally other professionals actually implement those designs.)

And to anyone who replies "design has caused real harm to the WWW", sorry buddy, that boat has sailed, and makes as much sense as saying we should expect Rolling Stone magazine to come in a dot-matrix text printout instead of a glossy, attractive magazine. Design is important, period.

<comment><USER9> > Does the designer know how to use git and commit properly? Do they know on > what branch? Understand the deployment schedule? Perform browser testing? > Are they part of code reviews? Do they understand whether that rule is used > by just that component, or just that page, or if it will affect code > elsewhere?

If he doesn't, find one who does. A web-designer who doesn't understand code is like a fashion designer who can't sew.

<comment><USER10> > A web-designer who doesn't understand code is like a fashion designer who > can't sew.

Except there are successful fashion designers who rarely if at all sew, just like there are successful interactive designers who rarely if at all code.

Do I think knowing how to code typically makes a designer a better designer than others? Yes. Do I think it's always that way? Hell no.

</comment></comment></comment><comment><USER11> Engineers don't look at a finished product and see something that's a few pixels away from perfection. They know all the kludges and hacks that are hiding behind the scenes. As a designer it's your job to help them get past that.

Being able to communicate is one of the most important skills a designer can have. If engineers don't understand the importance of good design that is your failing, not theirs. Talking about delight and pixel-perfection to the wrong audience just makes you sound like a Jony Ives wanna-be.

Merely asking everyone stops to sprint towards a perfect design shows a lack of empathy towards your team mates. At launch time everyone has features they needed to cut or temporary hacks they never got to fix. Telling team mates the most important thing is to "perfect" a vision they haven't bought in to is not a convincing argument. And viewing their hard work as a "sloppy version of my design" is not likely to win favors either.

The most effective designers I've worked with have been able to create and also sell their design. They can express both the motivation behind their design as well as the importance of implementing it well. They haven't just dictated design from up on high.

<comment><USER12> That first sentence got a bigger response from me then I was expecting. I can't even tell you how many times I've been told a project I worked on looked great, but I struggle to believe the person because of the numerous improvements I know can be made.

</comment></comment><comment><USER13> When I used to work with my designer friend, he would tell me to do things like that: increase this padding by 5px, lighten the color by a little, slightly decrease the border-radius, etc. One by one like that, I find it hard to follow and it doesn't feel like anything really looks different -- until I compare the finished product with what I originally made by myself.

Anyway, slightly OT: the screenshot looks like a Google page. Does anyone know which one? I really want to know what difference the 3px makes!

<comment><USER14> Did you show your designer friend what happened when someone presses ctrl +? Or uses a different browser or loads their own fonts or etc etc etc?

Designers have caused real harm to the WWW. They're clearly not the worst thing about WWW but they're pretty bad.

<comment><USER13> No, but I just checked a few of the sites we made and none break from ctrl+ (regarding this: I've never seen a non-tech person, i.e. 99% of traffic for the sites, use shortcuts in the first place); they also look consistent between _modern_ browsers; and how often do people load their own fonts? Is the designer responsible that a site becomes unusable under Wingdings? (Sorry for the strawman.)

That being said, when a designer says things like "move this button 3px to the left" they usually mean things like "move this button so its right edge aligns with the right edge of the content below, which got shifted because we added padding-right." So the original request gets implemented as what he _wants_ rather than what he asked for.

<comment><USER15> > Is the designer responsible that a site becomes unusable under Wingdings? > (Sorry for the strawman.)

Rather than apologize for making a strawman, how about we not make one in the first place? Nobody's talking about dingbat fonts from the 90s - GP is talking about usability _today_.

> No, but I just checked a few of the sites we made and none break from ctrl+

I'm glad your team has thought ahead, but I can assure you that many have not.

I can't count the number of sites that I've seen that would be completely unusable for people reliant solely on mobile devices (used as primary computing devices in the developing world), for people who rely on screen readers (blind and otherwise disabled people exist too!) - I could go on and on.

The common rebuttal I hear to this is that "the average user doesn't care about this", and the website isn't designed for "edge cases", which always makes me cringe. The wheelchair ramp at your storefront may not be used by your "average" customer, but that doesn't mean you shouldn't have one, even if the law didn't require you to[0].

Amusingly, in many cases, the sites that are the best-suited for a range of devices (desktops, tablets, phones) _and_ clients[1] are the ones that look like they stepped out of the late 1990s.

[0] [http://www.adawheelchairramps.com/modular_ramps/ada_modular_...](http://www.adawheelchairramps.com/modular_ramps/ada_modular_ramp_specs.aspx)

[1] Take a minute and check if your site works in Lynx. If not, there's a very good chance your site is inaccessible to visually impaired people (yes, Lynx and similar browsers _are_ still used by people with disabilities today!).

</comment></comment></comment></comment><comment><USER16> >As designers, we are held responsible for the overall quality of the experience. Yet we're at the mercy of our teams

Part of me empathizes and sees the similarity. Another part of me wants to point out that there is nothing stopping the designer from fixing this themselves. Learn your medium.

<comment><USER17> Some companies have rules that actually do prevent people from just diving on and doing whatever they want with the code.

<comment><USER18> Demonstrating a change in a local repo, or even with a local CSS stylesheet, isn't "doing whatever you want", it's a prrof of concept.

There ate plenty of broken corporate cultures out there.

<comment><USER18> s/ate/are/ damn you mobile

</comment></comment></comment></comment><comment><USER19> Prove it. Measure it.

Demonstrate with data that moving that button 3px to the left will increase sales by X% or customer retention by Y% or whatever our business metrics are.

There's a difference between "obsessing over the details" and "tweaking for tweaking's sake". Make sure you're really doing the former and that the particular details you're obsessing over matter measurably.

<comment><USER20> Yeah. And then you find out exactly why social sciences are progressing so slowly and have such a tough time of getting definite results.

I envy everyone working in natural sciences. Their jobs are immensely challenging, no doubt, but at least they have a clear path forward, more or less. But they are making impressive progress all the time.

Looking at human behaviour is much more challenging (so challenging that hardly anyone has an idea how to do it and most stick with boring unreliable ways that have somewhat kind of worked in the past), fraught with ethical issues, and so on.

Measuring everything is not a realistic goal. Measuring should be done whenever possible and is an awesome tool every designer should be using but it is impossible to employ it for every little change. And it has so far not been possible to develop a general theory of design that would help you decide small things without testing that specific instance of the design.

</comment></comment><comment><USER21> It's also that for a designer that 3px is HUGE.

It's like if you see this in your code:

      print 1
      print 2
      print 3
      print 4
      print 5
      print 6
      print 7

Any programmer would refactor that in a heartbeat without thinking too much about the impact or if it really matters.. it's just a plain bad smelly code.

For a designer, unaligned things is just as annoying. It's not that much about if other people can see it. Some will "feel" it, some will clearly see it, some won't see it. But it's just smelly wrong.

Yes you could make a point of not tweaking it, but it's faster anyway to fix it rather than discuss it.

</comment><comment><USER22> "How do we convince our engineering and product counterparts to care about design fit and finish?"

I expected the first answer - especially from Google ventures - to be "show them through data / testing the power of getting the details right".

Marissa Meyer's infamous "we once tested 41 shades of blue"(1) was the nexus of Google's design culture in the 2000's, has this changed?

(1) [http://www.nytimes.com/2009/03/01/business/01marissa.html?_r...](http://www.nytimes.com/2009/03/01/business/01marissa.html?_r=0)

</comment><comment><USER23> Wow, this is a superb article that resonates with me as much as anything I've ever read on the subject. It practices what it preaches, too. Reading it made me feel the very things it's talking about.

I sense, though, that the author's tactics for working with teams that don't share his values are half-measures. It reminds me of the large and sad literature on "organizational change" in software development, wherein people trade stories about how to cajole managers into letting them do fragments of good engineering. None of that works very well. The satisfying solution is to be part of an organization that values good engineering in the first place.

Similarly, a designer like the author would be better served by working with–I'm tempted to say _better_ engineers, but that's my bias–engineers who feel the same way that he does about product. These exist; I'd consider myself blessed to collaborate like that.

<comment><USER4> _...engineers who feel the same way that he does about product. These exist..._

Unless my personal experience has been wildly unrepresentative, software developers tend as a group to be almost obsessive about getting fine details right. We're the guys who worry about whether our design will be as easy as possible to maintain in the face of arbitrary future requirements or whether using some clever data structure would have given 0.07% better performance. We know, rationally, that sometimes our work is good enough and that we need to move on to other useful things, yet still there is a little voice in the back of our heads telling us we should have done better.

If I were to pick one other group who tend to exhibit the same trait, it would be designers. There ought to be a natural camaraderie here that makes it easy for little details to get done right. If that's not the default outcome, and probably something that people in management and sales regularly have to balance with pressure to ship, the first question should be why.

<comment><USER24> To the developer, every decision is a trade off, a tension between the demands of the now (features and time) and the demands of the future (elegance, maintainability).

Designers are not in a good position to appreciate the trade offs. It's very easy for a designer to think 'this infelicity decreases delight, and fixing it involves _just_ moving this thing to there'. This is probably an excellent spot of a real design issue, but that isn't the only thing that determines whether the work should get done or not.

I have no solutions, but problems like this are generally because of an insufficient appreciation of the other professions challenges, and if you're working in an environment with skilled practitioners of both disciplines, more communication is likely to fix it.

Here are some suggestions that might help designers talk to developers: Never use the word 'just' when talking to developers, frequently apparently simple things have huge ramifications and just as a designers specialty is understanding how the little things create a full experience, a developers specialty is understanding how little changes affect other things in the full system. Talk to them about the effect you're aiming for, rather than just the change itself - if the change is trivial, the worry is that you're not respecting their time, but if you convey that the trivial change will have a large specific effect then they will understand and may be able to do other things proactively to help you achieve your effect. Show that you care about more abstract values such as 'maintainability'; the ability to add features quickly in the future and having a low bug count are both massively beneficial to the user experience. Where you can, show that your fixes are not merely matters of opinion but are based on empirical evidence, good developers respect evidence. Get involved early in the process and talk regularly to the people implementing the design - show that you care about their opinion, but educate them in seeing things from another viewpoint too.

As a developer, you are probably used to having a discussion with the person who reported a bug for technical issues. Do the same for design issues - <USER2> if it's just 'move this button three pixels', talk to them about it, find out why it's important, find out if they really mean that it needs to align with some other element. If you have a legitimate reason to not want to do it, explain the problem - you might be able to work out a better solution together.

<comment><USER4> _Never use the word 'just' when talking to developers, frequently apparently simple things have huge ramifications_

Sometimes that is true, and that is so whether you're talking about changing a design or changing the underlying implementation, and whether you are talking about web design/development or software development more generally.

Having said that, if a designer can't request and a developer can't implement trivial changes that really are as simple as shifting something by 3px, most of the times that means at least one of the following is true:

1\. The person who implemented the previous version wasn't very good.

2\. The person who implemented the previous version was pressured to take short cuts in order to hit time/money targets and produced work that wasn't very good.

3\. There is some more general problem with the development process that means a designer requesting a trivial change and a developer then making it are expensive when they shouldn't be.

Obviously there could be exceptions where that 3px change has much wider implications for the overall layout, but I don't think those cases are really what any of us are talking about here.

<comment><USER24> The point is that if you use the word 'just' you're saying that you already know that the change is trivial. Perhaps it is, perhaps it isn't. Show respect to the person who will implement it by letting them say whether its trivial or not.

It's absolutely true that moving a button 3px should be trivial, but it's also true that things are often not as they should be.

<comment><USER4> I agree with your fundamental point that making the assumptions about what colleagues will have to do can be dangerous, though I would still challenge your earlier suggestion that apparently simple things "frequently" have huge ramifications. It's sensible and polite to acknowledge the possibility, but if trivial-seeming changes are getting push back more than occasionally, IME that probably indicates a more serious underlying problem with how the project is being built.

</comment></comment></comment></comment></comment></comment><comment><USER25> Maybe designers should learn a little bit of CSS and git and just fix the pixels.

<comment><USER26> This article makes a strong case for that.

Things like "grab me before you check this in" and "we need a design fix-it day" are indicators that this problem has a high communications cost between the designers and engineers who have to implement those designs. Companies who observe symptoms like this should consider hiring a designer/engineer instead of having those two separate people. Yes, the combined person will be more expensive but they will just do the same work in a fraction of the time.

</comment></comment><comment><USER27> I read assertion after assertion and kept waiting for that 'why' from the title.

</comment><comment><USER28> One big perception is that if the UI is not quite right (or worse), the code is also not quite right (or worse). Since the UI is seen and code is unseen, it becomes the visible representation of overall quality. So even if the code is tight and elegant underneath a sloppy UI, it will be perceived at the quality of the UI.

<comment><USER23> Absolutely. To nearly everyone, the user interface _is_ the program. This sounds like a truism but really is the opposite. It has important practical consequences.

<comment><USER4> _To nearly everyone, the user interface_ is _the program._

I would add to that the reason I'm wary of shipping an unpolished product as early as possible with the idea of refining it later: you only get one chance to make a first impression.

<comment><USER29> I think there's an important distinction between an unfinished product and an _unpolished_ product.

To use an overused example, the iPhone was unfinished in terms of features but what was there was incredibly polished.

</comment></comment></comment></comment><comment><USER30> Hmm. I can say with certainty that the great designers I've worked with have never had to make requests like this. They understand the idea that all sites should be built out of reusable components, and the visual relationships between those components should flow across the whole site. The CSS is robust and working site wide, the code is simple and beautiful and the design/UX is great, everyone is working efficiently - and everything flows from it. But any time you have to budge a button -3px, increase some front size 1px, tweak that padding there, fiddle with the line spacing on that subheading, or satisfy some other pixel pushing whimsy ... then the design has failed, the designer doesn't understand the medium.

Usually these sorts of requests come from mediocre designers who feel professionally threatened by a rapidly evolving scene and then feel the need to create a sort fake value for their role by insisting on such things. Very often such behaviour will come along with the sentiments expressed in OP's article, some sort of implied idea that they have the sole understanding of aesthetic value or what can be considered "delightful".

<comment><USER31> I really doubt you have worked with designers at all, let along great ones. Any designer, junior or senior, that I've worked with, won't ignore the small stuff, and the better designers are more likely to be perfectionists.

> Usually these sorts of requests come from mediocre designers who feel > professionally threatened by a rapidly evolving scene and then feel the need > to create a sort fake value for their role by insisting on such things.

This is such an immature comment I don't even know how to respond. A designer that was so deferential to developer to not sweat pixel alignment would simply not even get hired in the design studio I've worked with.

<comment><USER30> You've missed my point, and resorted to ad hominem. Way to go. I'm not saying that the little things aren't important, its great to be a perfectionist and I think sites are absolutely built out of details by designers and developers working in respectful partnership. But my point is that the design details that should be obsessed over come way before the traditional pixel pushing session at the end of the job. Things like consistent, simple and really robust visual relationships between components and typography across devices and viewport sizes. In my experience this is where good designers spend their energies - and if its done well pixel pushing should not be required.

I just responded to the point you were making in a polite manner, without calling you immature or calling your professional experience into question. Now do you fancy having a go?

<comment><USER31> I did not call you immature, I called your comment immature. You made your point with an ad hominem on a whole profession of designers who care about pixel alignments, and so I seriously doubt you have significant experience working with designers.

> But my point is that the design details that should be obsessed over come > way before the traditional pixel pushing session at the end of the job. > Things like consistent, simple and really robust visual relationships > between components and typography across devices and viewport sizes. In my > experience this is where good designers spend their energies - and if its > done well pixel pushing should not be required.

Pixel pushing is ALWAYS required at some point; it is unavoidable given our current technology. A designer cannot magically come up with a generic responsive design because developers just can't make that happen (through no fault of their own). Take for example icon design: it is well known that vector graphics are quite limited and bitmap icons must be generated and manually red lined for various resolutions. That is work the designer (or production specialist) does. Similarly, size-independent layouts are also a pipe dream, not because the designer is incapable, but the frameworks are! Hence, we are stuck optimizing layouts and pixel alignments for multiple sizes manually.

tl;dr "consistent, simple and really robust visual relationships between components and typography across devices and viewport sizes" is very often not workable in the real world for any non-trivial design.

Hackernews is surprisingly quite anti-designer in posting sentiment.

<comment><USER30> Can a comment itself be immature? I'm pretty sure only a _commenter_ has the agency to be immature, but anyway that's beside the point :)

> You made your point with an ad hominem on a whole profession of designers > who care about pixel alignments

Nope, at no point did I ever criticise designers who care about pixel alignments. I criticised designers who place too much value on pixel pushing at the end of a project - for me it's often a red flag.

Admittedly where an approach involving "consistent, simple and really robust visual relationships between components and typography across devices and viewport sizes" works best are for projects more towards the web app end of the spectrum, I will concede that point, but it doesn't mean the design has to be trivial.

<comment><USER31> Of course comments can be immature.

> I criticised designers who place too much value on pixel pushing at the end > of a project - for me it's often a red flag.

A lot of the bugs discovered during design QA involve pixel alignment issues. That is one of the main reason why we have design QA. Frankly, if something worse comes out of that (like a bigger interaction design flaw), then there are serious problems that jeopardize the project and somebody in dev or design has royally screwed up.

> works best are for projects more towards the web app end of the spectrum, I > will concede that point, but it doesn't mean the design has to be trivial.

Does it really work for web? Even for web, better designs are often stuck with 2 or 3 layouts to manually tune.

</comment></comment></comment></comment></comment></comment><comment><USER32> Getting the design right is important. But it's poorly communicated. For better or worse, programmers tend to be primadonnas who don't respond well to being told to move a button 3px (see seivan, et. al) for no reason.

Furthermore, the exact pixel dimensions you create in photoshop rarely translate to the browser due to screen size differences, resolutions, etc. It's much, much more useful for designers to tell me something that describes the relationship they have to each other than the exact dimensions (e.g, "these elements should line up on the right" rather than "make divs 253px"). Obviously for things like spacing there's some element of eyeballing until it feels "right", but you can and should be working with design before stuff goes out to get those right.

So yeah, it's frustrating as a programmer to go through these nitpicky details. But keep in mind it's frustrating because you didn't do your job of implementing what was specified. So maybe don't complain about it in a way that sounds like you refuse to do your job.

</comment><comment><USER33> So why should you move the button? You didn't say that. All I see from you is, "move the button" which is up against the request from the business guy that reads, "add the 4th option to the drop down and the client will pay us $50K more". Want to guess what is going to make the next sprint?

</comment><comment><USER34> Honestly, I can't believe some of the responses here. 'Fix it yourself'. 'Fixing bugs is more important' and a number of other black and white missing- the-point dravel.

Let me help. Here are a few pieces of irrefutable truths:

\- Any developer who doesn't see, or care, about attention to visual details is a bad member of the team.

\- priorities. Of course big bugs are more important. Why would you even mention that.

\- Good designers have their set of priorities. A good developer understands that, and doesn't say mind numbing things like 'don't waste my time'.

\- Will all visual enhancements increase conversion rates? No. Does that mean you're free to be sloppy? No.

\- At the end of the day, the balance between perfect code and perfect visual design is up to the product owner. Discussion about what's more important is pointless. It all matters.

</comment><comment><USER35> I really enjoyed this article. Most of the stuff I read makes me feel guilty for obsessing over the details. I'm a single-founder, work alone, and do the design and development myself, so I end up moving slowly.

Now that my product is launched and fully functional I've been able to to back and polish things as I have time. This really makes me feel a lot better about the product. If I feel users are having a bad experience, it's frustrating to me and I can't get it out of my head until it's fixed. I don't have the resources to make everything perfect, but every day it gets a little bit better.

I don't have a design or tech background, so I always thought I was just doing things wrong (maybe still I am). This makes me feel a bit better about how I work.

</comment><comment><USER36> If you have good development practices in place, making a targeted build to prototype 3px UI improvements suggested by ANY trusted team member should be trivial and should be considered. After prototyping the change, it's possible to evaluate whether the suggested lightweight improvement falls into the range of essentially invisible (probably not worth the churn late-game, but fine earlier) to actually awesome (crank a build if you can). Even lightweight changes could break the hell out of some browsers/resolutions, so 3px is not really "free". Hell, 1px is not free if floating elements can cause layout changes or fixed elements can crash into adjoining ones. If you have challenges making and evaluating suggested changes on very rapid timescales, ANYpx is irrelevant in the scope of your other problems and you should trend against change where possible. Also note that I said "trusted" team member - if the team member pushing for design changes is not "trusted" that is a separate consideration - please weight appropriately. If you break the crap out of other areas, yeah, try the 3px at that point if it's a toss-up and the change is orthogonal to other changes. If you pay the price of looking at other changes, try to get the designer's suggested change tested for free. Trust, but verify.

</comment><comment><USER37> I think the author is right. Good, consistent design with good ergonomics certainly makes work more pleasant and enjoyable.

And Yes. Yes. The difference that the 3px makes is incredible. So do get yourself that extra 26" IPS monitor with extra 1920 x 1200 pixels.

I will kindly warn you though, that I do have some reservations about mentioned 'Apple _glossy_ pixels', as although I'm currently wasting time writing this on a pixel-perfect glossy MacBook Air, nothing frustrates me more as are the reflections on that perfect glossy mirror. Which I can see right now. Or the inconsistent <home>/<end>, <command>, <control>, <fn> keys, when I'm actually working [if you need to spend significant amounts of time jumping between Mac/Linux and working in a command line, you will understand]. Or inability to connect two monitors to a MacBook Pro. Or how slow is the GCC on the virtual machine on that MacBook Pro with puny 16Gb of RAM. So do take the advice of the designer, but also keep in mind that _all that glitters is not necessarily gold_.

<comment> enjoy-your-stay I love working on my Mac, but the use of Cmd-Left and Cmd-Right instead of the <home> & <end> keys really causes me lots of wtf? moments when I'm editing.

Fortunately xcode allows you to customize those keys which has made code editing a lot more pleasant.

<comment><USER37> I think it is being called 'The dreaded Home Key syndrome.'

It is that cringing feeling and a moment of hesitation that one has when pressing on these home/end (and ctrl/fn/command/alt/option/control/arrow left/arrow right) keys.

</comment></comment></comment><comment><USER38> Every once in a while this article pops up rewritten in another form.

Attention to details is fantastic, but the mark of the best designer is one who ships. It is in fact the mark of the best artist who is pixel perfect. This is not saying that you shouldn't be fixating on the details - but don't let it interfere with the client's goals of actually being out there.

</comment><comment><USER39> "When a product is close to launch, I become a perfectionist. Each misaligned element or awkward interaction is like a thorn in my side. "

When a product is close to launch, I become paranoid. I do not want to do any changes, unless critical. There will not be time for another round of testing/regression testing. We have even whole process for that.

He is talking about team moving on other projects, which means he talks about time very close to launch.

It is great when the designer is perfectionist. There is also a time for that and that is NOT close to launch. You absolutely should come up with these changes while the project is far from launch so we can time for fixing them.

You should absolutely NOT suddenly come up with tons of tiny little changes close to release. One of those tiny little changes may break something important and we will have no time to find out.

</comment><comment><USER40> Or you, the designer, could learn a little CSS and git and submit a pull request with the micro-optimizations you want changed.

Every time you request changes instead of making them yourself, you are taking away from the time they can spend delivering improvements in their area of expertise, executable code.

<comment><USER41> Photoshop cowboy is a one-man band on the run

</comment></comment><comment><USER42> The article actually makes pretty good suggestions despite coming off as a little arrogant (our design tweaks will make a world of difference, if only the developers could understand!). I think the key is to realize that the visual design work comes last. Moving things by a few pixels here or there is not going to make or break your product, because the purpose of your product is to provide some sort of useful functionality and not just to look pretty (presumably). And a lot of times it's completely subjective anyway. Get the approximate layout and user interactions nailed down first, ignoring any superficial flaws. Then, at the very end, I don't think the developer will mind if you ask him or her to make one pass of tweaking a bunch of colors and alignments.

</comment><comment><USER43> > So it's not enough to say "it looks better this way". Designers need to make > a case for why the team should spend time on fit and finish.

That point is central to the post and yet not really followed IMO. Costly changes to the UX should be justified in objective terms, e.g. consistency, color or style matching, differenciation, focus improvement, branding, readability... Not a "it feels better", or "it's delightful" or "I'm a creative person, I know what's right" (<\- if it's his/her personnal project this one is OK)

<comment><USER44> Only one way ... higher profits.

</comment></comment><comment><USER45> I think this is often a problem of dividing responsibilities.

In order to turn a design into correct CSS, the size and position of each element needs to be measured precisely. If the Photoshop-using designer can't or won't do this themselves, and send through clearly specified requirements, it falls to devs who probably aren't Photoshop experts, don't know what the designer was thinking, and might not even have Photoshop.

A nice side effect of having clear requirements is that everyone in the team can easily refer back to them to spot design bugs, not just the designer.

</comment><comment><USER46> Great article! Like many of you I have worked with great teams and bad teams. In my experience a great UI/UX is a sign of a great team/company with a clear focus. The designers and engineers cannot fight for whose approach is superior, they must respect and understand each other and the user intent. They have to communicate well and sometimes invent new options together when their views or constraints are in conflict. This requires talent, teamwork and a focus on excellence at a level that cannot be faked.

</comment><comment><USER47> Well this is overkill, but if you really care about the optimal design, I wonder if you could optimize them with something like a genetic algorithm or some kind of machine learning. Google did this to find the optimal shade of blue for their logo. There is even a site designed entirely like this: [http://www.metamorphosite.com/about](http://www.metamorphosite.com/about)

IMO it really isn't worth the time though.

</comment><comment><USER48> for the record i really dislike the sidebar of that site. ;-)

<comment><USER49> Though that i was the the only one, that is actualy one thing that need some px to the right.

</comment></comment><comment><USER50> One more argument for mapping each job to one person. A-level players don't need to be managed and shouldn't have to ask anyone for approval. The non- designers should trust the designers to worry about the right details. If a designer thinks moving a button 3px to the left is important, then it's important _whether or not everyone else understands why_.

</comment><comment><USER51> I think the article should have shown the whole page for context.

My front end UIs are limited to bootstrap - it works :) - but if one/two/three button[s] are not aligned the same as all the others - I will focus on that rather than the data. My train of thought is gone.

</comment><comment><USER9> Why is this an argument between you and the engineers? Get latest, make the change, test it as best you can, commit it with a descriptive comment, and it'll go to QA for the next deployment.

What, you want somebody to do it _for you_?

</comment><comment><USER52> Better title: "Why Your Designers Should Know Git"

</comment><comment><USER53> he has a point and i like perfected ux too, but as a programmer im unable to achieve perfected UIs :)

anyway, there is also "good enough" and most likely 3px wont matter any more than refactoring a perfectly working class into a perfectly working class with perfect code...

</comment><comment><USER54> This article pisses me off something immensely. How about you learn to fucking code your own design?

'Yet we're at the mercy of our teams. We can design beautiful, intricate, delightful details — but we can't build, test, and deploy them all.'

No shit, so how about you stop being one of those lazy-ass photoshop goons who play fucking color-the-button on dribble all day long and actually learn to code your own fucking interface, either in Cocoa, JS, CSS or whatever.

This ain't the 80's no more. Software Engineers that work on front-facing stuff can and have learned design. Not just graphical design but even interaction design and designing slick user experiences.

Though I can't speak for all platforms, most Web & iOS developers I've met can do all that photoshop pixel-perfection bullshit _AND_ code the interface.

Which makes me hard to think why even have these photoshop-cowboys.

'We can design beautiful, intricate, delightful details'

The .psd file or your design ideas isn't worth anything. Fuck you if you call yourself a designer and can't work on the final medium.

EDIT: Pardon the tone.

<comment><USER55> Tone aside, I can't help but agree. My previous job (web shop) hired supposedly "rockstar" designers on several occasions, and the results were frustrating, time-consuming and in the end, largely worthless.

What did not help was that those people had "print design" backgrounds, my bosses loved the rendered (hard) designs, and not having any design or development knowledge themselves, these sorts of ludicrous standards were somehow becoming the norm.

So we ended up spending as much time trying to render some goddamn rounded corner with a gradient for all browsers than we did implementing actual functionality, generally causing us to cut corners all around (no pun intended)...

In my opinion, a good designer should know the limitations of the tools according to context and resources. As far as I know, you never hear of car designers asking the engineers to somehow find enough space for the engine, or an architect telling you that the plumber will have to somehow figure out where to put the pipes in his 36.3cm thick walls.

This is 2014 and I don't think there's a place for single-skill design queens any longer. As a developer I have to learn a new language pretty much every 6 months, and generally speaking new technologies far more often. So surely, the argument that "true" designers should not have to learn CSS (or related) is moot and let's be honest, arrogant.

To me, it's very much like the idea that politics or philosophy by themselves are vacuous. The world isn't waiting for your design like it's a god-send, you're making the design because you were asked to, by real people with real needs, all of whom, designer included, have to put food on the table.

<comment><USER56> Where architecture is concerned this is normally true, but the exceptions are interesting/illustrative. When Frank Gehry was designing the Guggenheim Bilbao, he took stiff cloth and folded it into the final shape. Actually, y'know, making the building was someone else's problem.

<comment><USER57> This is the equivalent of implementing the design in Flash :)

</comment></comment></comment></comment><comment><USER58> * Obsessing over tiny little details is the mark of a great designer. However, that doesn't mean that you should always be doing this. Say that you're launching a startup on a limited budget, for example. If you're spending an inordinate amount of time trying to decide between two slightly different shades of purple, or figuring out whether some border should be 1 or 2 pixels thick, odds are you're misusing your resources. There's a certain time and place to obsess over certain types of details - many startups would be better served obsessing over finding paying customers and refining their business model rather than spending lots of effort on some of this stuff.

* For the record, while this person obviously seems talented, I really dislike how the site jarringly starts shifting the content you're reading over to the side a second after load. If he wants to write about tiny little design details, I'd argue that's one of the most annoying things that he's missed.

</comment><comment><USER59> Great post. I noticed I read very little about usability and only about design. I'm assuming that the OP, Braden, assumes that we understand that usability is integral to design. The reason I say this is that I've heard and seen designers spend lots of time on something that most of the techs/devs said WTF to after they were done- one carousel, crappy menu, and pointless site after the next. That was an in-house design team working for a large university, btw, so the main problem was that the administration was the customer, not the primary users, which were students, university employees, prospective students, and parents of prospective students. And their attempt at usability studies involved a small number of students passing in the student union that got snickers bars in exchange for telling them what they thought. And no AB testing ever done.

</comment><comment><USER49> UI design obsession hit as hard as software design obsession, both are equally valid and should be respected. In others words if a designer tell you to move a button 3px to the left, then you should take in consideration his gust and ask them politely why they should. The same could apply if a more experience college tell you that this method don't belong to that class or that function is doing too much. Just respect each other and be on peace for the sake of the project.

</comment><comment><USER54> Lets call them what they really are. Photoshop designer. That pretty much defines you.</comment>


Peloton Is Spinning Faster Than Ever - <AUTHOR> https://www.thecut.com/2019/10/peloton-is-spinning-faster-than-ever.html <comment><USER2> As a work from home developer, having a Peloton has been a godsend for me. I could never motivate myself to get out to the gym after work... the effect of that was a constant feeling of malaise and fatigue, presumably because I wasn't exerting myself enough. Since I've gotten the bike I use it 5-6 days a week and have made a 180* turn in my health- no more fatigue, malaise and poor lung capacity.

The Peloton is a solid bike, but it does one thing masterfully... it motivates me to use it and work hard at my personal fitness. I could care less if it's becoming the latest fitness cult. All I care about is my personal health and what gets me results.

<comment><USER3> Why Peloton over an actual road bike though? A good carbon endurance road bike costs about the same as the machine, and the cost of accessories and maintenance is comparable to the cost of the subscription fees.

And you can join a bike group for like $30 a year and get unlimited live coaching for free from real people.

Especially right now the bike industry is transitioning to disc brakes, so you can get ridiculously good deals on brand new but older model year rim brakes bikes. And if you're mainly just doing cardio on sunny days (as opposed to commuting in the rain or racing) then rim brake bikes are better anyway.

<comment><USER4> Real bikes have also one important advantage: you are force to leave the house and be in the sun. This has a ton of positive effects on both physical and mental health.

Still, exercise at home is still better than no exercise.

<comment><USER5> Gatekeeping how people do exercise is one of the reasons why a lot of people skip on it.

There are tons of possible reasons why someone might prefer a peloton to a road bike, implying one is better than the other is just naive at best.

"Oh but you get free coaching from your peers" oh you mean more people to bikeshed how I exercise and more conflicting information? What's not to like huh

<comment><USER4> I am sorry, I don't understand your reply: did you read my comment as somehow booing peloton?

If so, that was not my intent, different people have different reasons for preferring one activity over another, I just wanted to highlight that being outdoor is useful in itself, and should be considered when choosing what to do.

I hate doing physical activity with people, so the "peers" part is especially outside of what I meant :)

<comment><USER5> Not really, I'm mostly disagreeing with whom you replied to, and agreeing with your statement: "exercise at home is still better than no exercise"

Which is why I replied to you instead of directly to the main comment.

</comment></comment></comment></comment></comment></comment><comment><USER6> I still don't "get" Peloton but my 90-year old grandpa has been active his whole life and is currently in love with Peloton. He's not one to get interested in any gadgets or fads but since his gym got a few Peloton bikes he can't stop talking about it. So there must be something to it.

</comment><comment><USER7> > _Peloton wound up opening at $27 a share and closed at $25.76 — not a > bonanza day_

From the company's perspective it's good that it didn't shoot up to $50 a share, isn't it? It means it was valued optimally; they squeezed the maximum value from the investors and didn't leave any money on the table.

</comment><comment><USER8> Regardless of whether the product is better or worse than a real bike on a smart trainer like a Neo or Kickr, (and I don't think it is but that's subjective), I hate the name of this company.

I hate that people who know nothing of road cycling are now exclusively associating the word peloton with these indoor spinning bikes.

I really hate that this company is frivolously threatening to sue people for using the word peloton in the context of any kind of indoor virtual cycling.

This is a widely used phrase and they should leave it alone.

Calling a company echelon is just as bad for the same reason.

<comment><USER9> Just to add for anyone new to this topic, check out Zwift - the virtual cycling platform that cycling purists don't scoff at* because Zwift is much more rooted in the tradition and culture of the sport. They are a Silicon Valley cycling e-sports startup, 120 million in funding. Dcrainmaker.com and GPllama on YouTube will be your best 3rd party guides to the ins and outs.

*for some definitions of "purist"

<comment><USER10> I do not like Pelotom at all. Do not like Zwift either as their graphics sucks and view of bazillion animated cyclists around me does not add value either. I guess this is because I love cycling but do not really care about racing. For racing crowd I guess Zwift can make more sense.

I very much prefer software with so called Real Life Video (Tacx TDA, Veloreality, etc) for my indoor training in winter. The scenery is way more inspiring on big screen TV.

Comes summer, forget indoors. I love cycling and swimming in open water. No software would ever come even remotely close.

DCRainmaker was valuable source in the beginning (still somewhat is) but not so much now. His reviews and opinions at least in regards to cycling software lately are far from unbiased

</comment></comment></comment><comment><USER11> So maybe this is a crazy thought but I think it would be cool if peloton introduced bikes with steering and buttons and developed games for their platform. I Wonder if people would be receptive - it's certainly something I would like to try.

<comment><USER9> Check out Zwift - the virtual cycling platform that cycling purists don't scoff at because Zwift is much more rooted in the tradition and culture of the sport. They are a Silicon Valley cycling e-sports startup, 120 million in funding. Dcrainmaker.com and GPllama on YouTube will be your best 3rd party guides to the ins and outs.

<comment><USER12> Do you work for them? You copied and pasted the same ad material twice lol. If you do you should say so

<comment><USER9> I don't work for or with any entity mentioned. If I did, I would have disclosed it.

</comment></comment></comment></comment><comment><USER13> Home gyms go through fad cycles just like fashion does. Peloton is on the upswing of the "streaming fitness" fad, but give it one or two more years and it will start to die down.

I'll only admit Peloton is here to stay if we see a correlation between Peloton's profit and a loss for other fitness/entertainment. Basically, if people are just buying the bikes and paying for the subscription, but ultimately don't change their fitness behavior (by cancelling a gym membership, for example) then we know it's just a fad. Once they get tired of seeing the monthly charge, they'll cancel and put the bike up on Craigslist.

But if people decide to drop something else in favour of Peloton, then I know it's here to stay. If peloton is so great that you'll cancel your gym membership, then it must not be a fad! People only have so much time and energy in a day.</comment>


Give natural history museums back to the grown-ups – Aeon Ideas - <AUTHOR> https://aeon.co/ideas/give-natural-history-museums-back-to-the-grown-ups <comment><AUTHOR> Or, in other words, " _When I was a child, museums were fun! But now that I 'm an adult, they're full of annoying children! What gives?_"</comment>


Show HN: My weekend project, Flair -- Like a friendly reverse Pinterest thingy - <AUTHOR>

Hey all, just wanted to invite you to take a spin on this project I've been working on recently.
To give you a bit of context, I'm a Pinterest/Tumblr/Svpply user but found that it's all still sub-optimal. The experience of these, I guess 'social' things, is still always about "me, me, me": Pin things I like, post items I like, I want this and that etc. My point is, in my experience, this got boring relatively quickly. Plus, when I log in to Pinterest for example, it's this wall of sound of relatively (albeit nice looking) yet random things.
Anyways, a few weeks back, my roommate happened to have a bunch of her close friends over for a clothing-swap. Basically, everyone brings a bunch of clothes she doesn't wear any(more) and swaps it with someone in the room.
This is how it went down: One would pull out, say a skirt, and show it to the group. Within seconds - and I found this remarkable - the groupmind decided who should try it on. In 9 out of 10 cases this was an accurate assessment and the item was swapped, tried on and (with some Madonna playing in the background) presented to the group. All smiles all around :)
So, this got me thinking how important friends are for filtering out the noise and how strong their recommendation is. It's that moment, when a friend sees something in a store and says `This is so you!'.
Based on these two observations, I came up with what would become Flair. A game where friends find great things FOR each other.
What's there now is a bare-bones site ready for (in)validation. Note, that overall, this game is targeted towards women who are already using Pinterest, but I figured I'd show it to you anyways.
Here's what I invite you to do:
1. Think of a close friend and what you like doing/thinking/talking about together
2. Hop over to http://letsflair.com, check out the site
3. Unless you're averse to it, log in through Facebook (if you are, please don't bother commenting on it)
4. Start your Spree with your friend
5. Go and find awesome stuff for them!
There is a bookmarklet I highly recommend installing, it makes the process of adding stuff super simple.
tldr; Got bored with Pinterest, saw how friends are really good at recommending things to each other, built a game called Flair (http://letsflair.com) that mixes the two (and is actually a lot of fun) <comment><USER2> TLDR; Hop over to <http://letsflair.com>

Do as directed.

<comment><AUTHOR> Thanks!

</comment></comment><comment><USER3> I do a lot of the clothes shopping for my wife, so this could be a very useful tool.

Seems potentially very interesting. I have no interest in pinterest, but the inversion concept here seems very unique and could potentially be a lot of fun.

<comment><AUTHOR> Hi debacle, it makes sense, if you already do select clothes for your wife. Of course, you can always also just aggregate links in an email, but the game mechanics at Flair do make it fun indeed :)

</comment></comment><comment><USER4> You built this in a single weekend?

<comment><AUTHOR> Well, it was two weekends but, yeah, pretty much! Not to forget the giants on whose shoulders I stand on to make it: Rails, Heroku, gems like Paperclip, S3, Bootstrap. The list goes on and on and on...</comment></comment>


Death of the smartphone and what comes after - <AUTHOR> http://www.businessinsider.com/death-of-the-smartphone-and-what-comes-after-2017-3 <comment><USER2> If I understand this article correctly in 10 years all these big software companies that never managed to make a 2d UI logical, intuitive and coherent will try to put the same shit (but in 3d ... yeah) directly in my brain ?

Hell no.

And at one point I'm going to start to believe the conspiracy theories about "their" plan to implement the Matrix IRL ...

Color me not unenthusiastic for a world where our lives are even more sucked up by virtuality.</comment>


Sylvie Forbin, lobbyist for Vivendi, is new head of copyright at WIPO - <AUTHOR> http://keionline.org/node/2614 <comment><USER2> I don't know anything about Forbin, but will point out that people said very similar things about Tom Wheeler at FCC ("he's a cable company lobbyist!"), and that analysis turned out to be pretty facile.

[https://hn.algolia.com/?query=author:tzs%20wheeler&sort=byDa...](https://hn.algolia.com/?query=author:tzs%20wheeler&sort=byDate&prefix&page=0&dateRange=all&type=comment&storyText=false)

<comment><USER3> I'm not sure Wheeler's turncoat, pro-consumer behaviour was predictable (or, for that matter, predicted) by anyone, you or otherwise. I think it's both more likely and more rational to assume duckness if walking and talking are both ducklike. Put another way, this sure looks like a Bad Thing, and until a Wheeler-like situation arises and transforms it into a Good Thing, I don't think the HN hoi polloi can be blamed for reacting to the Bad Thing.

<comment><USER4> When Wheeler was nominated, he had a blog on the topic of telecom public policy, going back several years, with a lot of very deep and nuanced commentary on issues like the natural monopoly that arises in telecom infrastructure. I read a lot of it. It was obvious that he was not a last minute "turncoat". Wheeler's behavior was very predictable, if people only read primary sources instead of letting themselves get led around by the nose by clickbait/outrage farms.

<comment><USER3> Consider me having been led around by the nose by clickbait/outrage farms. I wish you'd been around to provide the link to Wheeler's blog when this was news. If you follow the other subthread, you'll find another HN user who's provided a link to his commentary when all this was going down, and if the HN of that time didn't have access to Wheeler's blog's information (do you have a link, btw?), I feel I'm in pretty reasonably poorly-informed company.

This outlines a particularly pernicious problem with redditalikes as platforms for news and commentary -- if the parent is telling the truth about Wheeler's public musings about how he couldn't abide by the monopolistic behaviours of American telcos, how and why did reddit/HN/etc not jump on it and shout it loudly from the commentthreads, riding the (perhaps more reddit-y) trope of the top comment being a stringent correction of the incorrect info in the actual submission? The only thing redditalike media platforms like more than being right is being able to correct someone, after all...

<comment><USER4> Amusingly, it seems that he allowed his blog's domain/hosting to lapse. You can find some of it on archive.org: [http://web.archive.org/web/20110206171653/http://www.mobilem...](http://web.archive.org/web/20110206171653/http://www.mobilemusings.net/2010_12_01_archive.html) I've only been able to access a subset of the posts, and I can't find the particular post that really convinced me that he wasn't the example of lobbyist/regulator revolving door that everyone was saying he was.

I wasn't on HN at the time. However, I did post links to his blog on reddit in the relevant threads, my posts linking to his blog just didn't get much traction. They got mildly upvoted and started a few small conversations, but absolutely _nothing_ compared to the witty one-liners and ranting about lobbyists, shills, and Obama being a sellout.

<comment><USER3> I hope you don't take this the wrong way, but showing me that the blog you're describing exists yet somehow doesn't have the thing you're trying to show me doesn't really fill me with surety.

The post itself is hardly a smoking gun, either. It's hard to tell whether a soft-SIM, as described in the 2010 blogpost, would be pro-consumer or pro-Big Whatever. In the post, Mr Wheeler characterizes it as "handset subsidy vs consumers' ability to switch cell providers at will". Is that the part that's supposed to dramatically reveal that he was on our side all along? My understanding of current 'soft-SIM' deployment is that it's basically only present in newer iPads and isn't really a soft-SIM.

Sorry, but I still see no proof that Wheeler was 'obviously' pro-consumer. For all that we love to bash reddit et al, I still think that if there was obvious proof that the pro-hivemind opinion was wrong, someone would post it and contrarians would get it to the top post. I presume you deleted the reddit account in question?

<comment><USER4> I read a bunch of the posts that _are_ still accessible, I still think it makes the point: it's not surprising that Wheeler is reasonably pro-consumer. It's just that I can't find the _particular_ post that has stuck in my head all this time.

<comment><USER3> I'm shocked that Wheeler's pro-consumer leanings are _so obvious_ to everyone but me. I wonder if we're reading the same archived blog?

<comment><USER4> Would you still say this:

> I'm not sure Wheeler's turncoat, pro-consumer behaviour was predictable (or, > for that matter, predicted) by anyone, you or otherwise.

After reading this[1], written by Wheeler?

> Back in the original analog-to-digital days I can remember AT&T's > representatives warning of catastrophic job losses and damage to the > national security if innovative competitors were allowed into their > business. The same echoes surround the proposed NASA changes. Many of the > Old Guard, launch system contractors, and their congressional supporters are > bemoaning the thought of a competitive manned launch environment. We've > heard all that before at the time of another "analog-to-digital" conversion. > The earlier warnings not only failed to materialize, but just the opposite > occurred as new, innovative and less expensive services came forward and > economic growth and a new generation of jobs exploded.

Is it really that surprising that someone who wrote that turned out to be a regulator with reasonable positions on things like net neutrality?

Maybe "obvious" was a bit strong of a word (Wheeler's writing is a bit heavy on long-winded metaphors...) but I also definitely do not think that the vitriol directed at him starting the day of his nomination was warranted, and I do not think that Wheeler's behavior was so unpredictable.

1\. [http://web.archive.org/web/20110206170617/http://www.mobilem...](http://web.archive.org/web/20110206170617/http://www.mobilemusings.net/2010_05_01_archive.html)

<comment><USER3> Uh, yeah, totally! Note the language used in your excerpt -- it's all finance and macro-scale consequences, job loss and less expensive services and economic growth. He talks about NASA trying to import "Internet age" thinking (by which he means, of course, entrepreneurship and disruption) into an analog world. Read some of the other posts and they're awash with the same language.

>Is it really that surprising that someone who wrote that turned out to be a regulator with reasonable positions on things like net neutrality?

No, not at all! The position I've been trying to take throughout this thread is that the _perception_ of Wheeler being an ascended lobbyist (read: hostile to consumer interests) was reasonable, in the absence of mainstream knowledge otherwise (like eg this blog we're discussing). After reading the post from which you've excerpted, I still think that perception holds. He's not pro- consumer, he's pro-capitalist. Just because the view espoused here ("established corps should not have the ability to extinguish potential competition, via regulation or fearmongering or citing national security") happens to _benefit_ consumers does not mean he's taking those actions for consumer benefit.

>Maybe "obvious" was a bit strong of a word (Wheeler's writing is a bit heavy on long-winded metaphors...)

Really? I think I've established myself as a fellow sentient, but whatever, _maan_.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> I dont really know anything about WIPO. Its this surprising? Or is announcement similar to 'Darth vader appointed as new head of the Empire' ?

<comment><USER6> i think its more like north korea heading the UN commission on human rights.

<comment><USER7> Saudi Arabia is chairing the United commission on human rights currently. Pretty crazy eh?

<comment> steve-howard It's the human rights council now, but you're right. Didn't think the UN was a particularly effective body at any rate, but that's ridiculous.

[https://en.wikipedia.org/wiki/United_Nations_Human_Rights_Co...](https://en.wikipedia.org/wiki/United_Nations_Human_Rights_Council#Saudi_Arabia)

<comment><USER8> > Didn't think the UN was a particularly effective body at any rate, but > that's ridiculous.

I'm not sure ridiculous is strong enough here..

</comment></comment></comment></comment></comment><comment><USER9> Positions of power attract the power hungry. Positions of authority attract authoritarians. I think any sane citizen of any country would love to have top-level government positions such as these have decisions relegated directly to the citizens instead. There is no reason why, with our technology now, we couldnt facilitate direct-democracy for such critical positions that control the outcome of decisions that affect society.

<comment><USER10> I used to think this, but how do you actually get fair and accurate representation of people? The digital divide is still real. We don't need any more hindrances keeping the poor and disadvantaged from participating in the system.

</comment></comment><comment><USER11> For anybody interested in a comprehensive overview of copyright in the internet age, I can highly recommend the book "Information doesn't want to be free"

</comment><comment><USER12> What could possibly go wrong?</comment>


Who needs Flash? Build Flash-like game with scripty2 - <AUTHOR> http://mir.aculo.us/tutorials/scripty2-memory/ <comment><USER2> Eh, as games go I'm not impressed. If you want to impress the guys using Flash to produce games (like me) you're going to have to make something much better than that.

Show me something that fits in at Kongregate or ArmorGames, not something that was probably done in Flash a dozen years ago.

<comment><AUTHOR> Whoops. It seems you missed the point.

<comment><USER2> Half of the point seemed to be to build Flash-like games. That's not a Flash- like game it's a one page tutorial that's probably been written for every language in the last 30 years.

The other half was who needs Flash? Until you can show games comparable to these - <http://www.kongregate.com/top-rated-games> \- with no omissions or compromises or exceptions, the answer is people who are serious about producing casual games need Flash.

JavaScript is improving in a lot of areas but "not Flash" is a horribly weak argument especially when backed by examples such as this. "Not Flash" implies the platform's actually a problem itself ... consumers, developers and an enormous portion of the internet don't share that mindset. If you want to win marketshare against Flash you need to be better in most or all areas, not almost equivalent in some.

<comment><AUTHOR> It's not about the game. You're still missing the point.

<comment><USER2> If your point isn't the title of your submission then what is it?

<comment><AUTHOR> I'll give you boys a hint. It has something to do with LOC.

<comment><USER3> How about instead of giving us 'boys' 'a hint', you drop the condescending bullshit and explain exactly what you mean.

I'm an experienced and successful game developer. Hundreds of millions of plays. Done very well financially. People sometimes recognize my game on the street when I'm wearing a company shirt. I think that entitles me to have an opinion without being treated like an idiot.

<comment><AUTHOR> Sorry guys. I messed up today. I was being condescending. Hope you can forgive me.

<comment><USER3> Hey, no hard feelings. I think we're all guilty of that from time to time. I'm sorry I hit back so hard (I'd erase it now you've appologized but unfortunately the edit window has lapsed).

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER4> Keep up the good work guys. I'm loving all the JS/HTML5/CSS games coming out these days. I made another game this week:

<http://games.zetabee.com/chains>

I hope to make tons more over the next month. I use Raphaeljs and JQuery. The best part about making games in JS/HTML is that you can pick and choose the good parts from each platform. It is easier to do rotations in Raphael so I use its .rotate() function. It is easier to make a navigation menu using ul, li tags in HTML/CSS so I use that and overlay it on top of the Raphael canvas. You can even use JQuery to bind events to nodes created by Raphael.

I can easily include images and backgrounds natively and monitor mouse events. The best part is that the games work in all browsers and iPad/iPhone natively. Also I don't have to worry about loading native fonts etc. because I can just use the default browser fonts for most everything. Testing is also very easy because it's just a single JS file that I work with. I want to create a simple library for others to use but I don't have much idea on how to go about it. I don't expect to create something as complex as <http://www.kesiev.com/akihabara/> but I think having a good framework for creating browser-based games would help.

<comment><USER5> the mechanic in chains has a lot of potential. the implementation feels solid too!

</comment></comment><comment><USER6> If you're going to put 'Who needs Flash' in the title then this is low hanging fruit. :-)

Has anyone got any examples of more complex games in HTML/JS? I'd be interested to see how far people can push performance. The only benchmarks I remember seeing currently put Canvas+JS at a significant disadvantage over Flash but I'd love to be corrected on that.

<comment><USER7> This is a much better example of games you might actually see on flash portals, done in HTML5:

<http://www.kesiev.com/akihabara/>

<comment><USER8> Impressive how fast and smooth his games are.

<comment><USER9> The key to Akihabara performance is small number of actual pixels being drawn/computed.

Resolution of game's <canvas> is just 320x240 (check "view image" in Firefox) which is then blown up by browser renderer to 640x480 (in a same way how you can resize image in CSS).

Thus you get 4x as many pixels and cool retro 8-bit look with a lot of work done by browser's C++ code instead of much slower JavaScript.

Till we don't have hardware acceleration for <canvas> tag, unfortunately demos and games are going to be quite limited.

<comment><USER8> Thanks for the info!

</comment></comment></comment></comment></comment><comment><USER10> Very nice.

I love the idea of "native" browser games. Sadly, even with the neat new things coming in HTML5 & CSS3, there will be big things missing.

Highest on my list is decent sound support. Needing to provide both mp3 & ogg (since different browsers support different sound file formats), suboptimal support for mixing, and lack of decent programmatic control of panning or channel volume all stand out as significant deficiencies, especially as compared to Flash.

Still and all, it's obvious that it's worth pursuing native browser games. Even without the sound support, there are a fair number of compelling games that could be done. Users often don't _want_ the sound on in the browser games, anyway. Still, it makes the split between browser games and stand alone games wider than it needs to be, IMHO.

</comment><comment><USER11> When made a game for Ludum Dare last weekend, I decided to see what I could do with Javascript. It was actually much nicer to work with than the flash work I've done. You can play it at <http://labs.haleret.com/ludumdare/ld17/ld17.html> .

<comment><USER12> This game is actually fun! Great work and an interesting take of platforming.

</comment></comment><comment><USER13> I think the real news here is the release of Scripty2, the successor to scriptaculous. Check out this demo: <http://scripty2.com/demos/cards/>

All in 70 lines of Javascript.

</comment><comment><USER14> Nice work. Could do without the fancy animation at the end of the game.

<comment><AUTHOR> There's the source :) Remove it and re-release it. Which is, I suppose, the whole point.

</comment></comment><comment><USER15> Looks like it doesn't use canvas. I would expect that performance will suck and it won't get any better in the future. Am I wrong?

</comment><comment><USER16> Is there a jQuery-based framework that's similar? I'm aware of GameQuery, is there anything else?

<comment><USER17> Disclaimer: I'm the author of the tutorial (and core team member of Prototype, and the author of scripty2)

You can probably port the ideas and basic functionality very easily to other frameworks. Prototype or scripty2 don't contain anything specific to games, however. It's easy to write the interactions required in plain old JavaScript...

I do like to use Prototype for stuff like this, because it helps clean up the "logic" code a lot (for example the "avoiding stuck cards bit", section 17 in the tutorial.

Note that if you like this style of coding, but prefer jQuery, you can use the Underscore.js library, you might want to look into that.

</comment></comment><comment><USER18> Linkbait title much? Comparing a js framework w/ the Flash platform is apples and oranges. Any decent web dev could port the API over to actionscript.

Also, re: LOC, fwiw, you can do position/dimension .morph()'s w/ zero lines of code in Flash.

</comment><comment><USER5> for the real story on why non-flash web games matter, you have to look at ease of porting to mobile/smartphone/social network platforms. If you could write a game that had 50% of the richness of a flash game, but worked quite nicely on (highly monetizable) facebook and could be easily ported to the (highly monetizable) iphone, is that worth more to you than the richness and playability on IE?

</comment><comment><AUTHOR> Here's my version (shameless self-promotion) <http://coderpath.com/game>

<comment><USER19> So you're using prototype & scriptaculous to make a game. How is that easier than flash? How do I do particle effects using scriptaculous? How do I pair it with background music & sound effects? What if I wanted box2d style physics and collision detection? What's the proper way to animate a sprite?

jQuery, scriptaculous, prototype, mootools -- all great javascript libraries, but not very good at game development.

</comment></comment><comment><USER20> When I read the tittle I thought there is going to be a library built on canvas with vector graphics capabilities.

thank you, but no.

</comment><comment><USER21> akihabara (<http://www.kesiev.com/akihabara/>) is better.</comment>


The top five reasons why Windows Vista failed - <AUTHOR> http://blogs.zdnet.com/BTL/?p=10303 <comment><USER2> Another problem - change for change's sake.

They wanted to push a new product, so they changed stuff that was perfectly fine. A lot of this ended up being cruft and eyecandy that was just unnecessary and annoying.

Microsoft is laden with this problem now - Windows and Office are technically very stable. How they break away from this will be difficult/painful.</comment>


Ask HN: Best Python Book For Advanced User? - <AUTHOR> So I can write concise Python code, but really want to level up my understanding of Python programming language (both good and bad parts) and gain some insights on how to use Python effectively. Is there any book can do that for me?<p>(Think "The Well-Grounded Rubyist" for Ruby, "Effective Java" for java, "On Lisp" for lisp, etc.)<p>I will really appreciate any reply. <comment><USER3> Learning Python 5/E ([http://www.amazon.com/Learning-Python-Edition-Mark- Lutz/dp/1...](http://www.amazon.com/Learning-Python-Edition-Mark- Lutz/dp/1449355730)). This book is great book for both intermediate and advanced developers. Very in-depth.

</comment><comment><USER4> I am not sure there is a generic answer to your inquiry. If you want to understand python itself you would be best off checking out the source code, building it yourself and then try to change some language features for fun.

Other than that I'd recommend that you find a domain you are particularily interested in and get some books on the specific aspects of that, for example Python for Data Analysis. [http://shop.oreilly.com/product/0636920023784.do](http://shop.oreilly.com/product/0636920023784.do)

This allows you to focus on what to do with python and the eco system of frameworks and so on.

If you want to learn how to use Python effectively, I believe you should decide what domain to apply it in. Python is no end in itself, as is the case with most other tools...

</comment><comment><USER5> "Treading in Python, Vol. 2" by Harrison goes pretty in-depth with the usual suspects -- iterators, generators, decorators, dunder methods, etc. Then Knupp's "Idiomatic Python" is handy to review for tips and tricks. But overall I also like Beazley et. al. for a great cookbook and a good glimpse into "effective" Python.

</comment><comment><USER6> If you're looking for advanced web development, check out Real Python - [http://www.realpython.com](http://www.realpython.com)

Sure, we start with the basics, but we do get into some advanced topics - <USER2> BDD, adding Angular to Django ...

(Note: I am the co-founder and author)</comment>


Will AI Surpass Human Intelligence By 2020? - <AUTHOR> http://www.dailygalaxy.com/my_weblog/2009/09/a-singular-something-in-sixty-years.html <comment><USER3> In 2009, yes, it looks like a sure bet that AI will pass human intelligence by 2020.

In 2019, yes, it will look to be a sure bet that AI will pass human intelligence by 2030.

Meanwhile computers will continue doing more and more important things by the boring expedient of taking lots of data and crunching on it. See: credit scores, which nobody considers "artificial intelligence" despite the fact that it essentially involves having a sophisticated algorithm make evidence-based predictions of the future based on what could easily be confused with a character judgment.

</comment><comment><USER4> For some definition of human intelligence, yes. For some, no. Same answer as every other year since the invention of the computer. This is not an interesting question (or article) without providing some reason for why your particular definition of human intelligence (the article doesn't give any definition at all) is the right one to consider.

<comment><USER5> Human intelligence can't exist outside of humans. We have a unique brain structure, allowing us to do what we do. But if we put our brain in a robot, it wouldn't work unless you built the robot in such a way that it believes it is human. Only then can you have an artificial human intelligence. The robot needs to be able to connect with humans on a meaningful level. This would be difficult if everyone just stared at the funny looking robot trying to act human.

I think rather than creating Skynet, we're going to start upgrading our own hardware; adding robots to ourselves until there is no human left. I think with this practice, the new AI would be compassionate towards humans.

Then again I also think about how teenagers hate their parents. Would a super- intelligent being come to loathe their parents (us)? I like to think that a super intelligence would understand that violence doesn't solve anything. But then again, that's why we have Sci-fi -- as a kind of list of things to make sure they don't happen.

Humans are no longer king of the hill. Evolve or perish.

<comment><USER4> This is a contradiction: "adding robots to ourselves until there is _no human left_ ", "the new AI would be compassionate _towards humans_."

If we use people as the foundation for building AI which eventually abandons all human foundation, then the result would not be human. It's as if you had a car and every day replaced a single part with the part for a different car. In the end, the original car would no longer exist, even though there was, as it were, a continuous camera shot of the transformation.

This is a tangent, I admit, but the contradiction needs resolved.

<comment><USER5> Not every human would become a robot. Not every robot would have started as a human. This is where homo sapiens branches in the phylogeny of life. Some become robots, some stay human. Those that stay human may eventually evolve into dwarves and night-elves and maybe tauren. Those that turn into robots may want to explore reality like the wanderer in TNG, season 1, episode 7. (that's what i want to do anyway)

Basically, what you're telling me, is that an ape that evolved into a human is no longer an ape. True, but not true. It just so happens that historically, in evolution, changes were subtle. Humans are neat because it will be the first time that a species evolved into something that barely resembles, if at all, the generation of life that spawned them.

</comment></comment></comment></comment><comment><USER6> It doesn't need to be that intelligent - it only has to fool us into thinking it is. Remember the Turing test..?

<comment><USER7> To pass the Turing test AI would most likely need to be a lot more intelligent than humans. Being able to convincingly emulate something is harder than merely running your own 'native operating system'.

<comment><USER8> Actually, studies have shown that it's not that difficult to fool most humans. One study I remember simply repeated phrases back to the human in the form of a question.

Human: I ate pizza today. AI: You ate pizza today? Human: Yes it was delicious. AI: How delicious was it?

One participant actually guarded her screen from the researchers because she was having such an intimate conversation with what she thought was another person.

<comment><USER7> The Turing tester would need to be deliberately testing to see if the other party was a bot for the test to be convincing. This is the 'standard interpretation' of the Turing test

[http://en.wikipedia.org/wiki/Turing_test#The_standard_interp...](http://en.wikipedia.org/wiki/Turing_test#The_standard_interpretation)

<comment><USER9> Additionally, you can fool people with some simple tricks like what was mentioned.

In the Loebner Prize the programmer and/or person being "tested" was allowed to pick the topic. One of the programs that won did so by picking the topic "silly conversations" and having the machine output gibberish. The judge thought this was a person being silly (how could a computer be silly?) and rated it a human. Someone who knows anything about AI/NLP won't fall for this though.

[http://www.eecs.harvard.edu/~shieber/Biblio/Papers/loebner-r...](http://www.eecs.harvard.edu/~shieber/Biblio/Papers/loebner- rev-html/loebner-rev-html.html)

</comment></comment></comment></comment></comment><comment><USER10> I would feel more comfortable with such predictions if research were clearly walking the wooded path to AI. Moore's law works because

      1. We already have processors
      2. We have a metric to measure processor speed

Then the path we're hiking is one _mostly_ of incremental improvments, with occasional boulder of innovation.

Whereas the 'intelligent' agents we currently have do not seem particularly similar in _quality_ to intelligence we already know; the path from contemporary AI to strong AI is hardly a trail at all --- it's all boulders; innovation all the way up.

[The claim I make about 'quality' is vague; in part necessarily so. If I could pinpoint my discomfort with current methods, I could propose a new course of action based on a new metric. Nevertheless I feel that the high-mathematical bent of current machine learning techniques (proto-value RL, statistical relational methods, etc) will lead to excellent answers, but does not point towards the flexibility of general intelligence. Yrom the other camp, low- level connectionist methods have not to my mind offered significant results in problem solving.]

</comment><comment><USER11> This one's easy: anyone making a clear, testable predication about what's going to happen 10 years from now is going to be Wrong.

</comment><comment><USER12> I think it's worth separating two statements that seem similar: "Computer will surpass human intelligence" and "Artificial Intelligence will surpass human intelligence".

The two statements aren't necessarily equivalent if we say AI involves an explicit understanding of what constitutes intelligence. AI doesn't seem to be making great progress on the understanding intelligence front. However raw computers might exceed human intelligence if we are able to, say, just directly simulate a brain but, say, increase the clock speed and maybe the number of neurons. But if it turns out that we create something highly intelligent _that way_ , we will be creating something potentially dangerous since we really will have no understanding of how benevolent it will or won't be.

</comment><comment><USER13> No. Real AI is like fusion power. It will arrive in 40 years, for any definition of now. We are barely scratching the surface of our knowledge of the brain. We are orders of magnitude away from its processing power. We dont even have an agreed upon definition of consciousness. Will ever get there? Sure. But first we will see prostheses like vision and augmentation mind computer interfaces.

<comment><USER8> Do you believe that Real AI must be modeled on the brain? I'm not sure that is a requirement. I think we can produce AI without fully understanding the brain.

I expect AI to be something greater than the brain. If we use the brain as a guide or the summit of achievement, then at most we'll get only as smart as a human, or group of humans considering the massive amount of information storage and retrieval possible.

I don't know... I wonder.

<comment><USER13> Actually, I dont think real AI will be modeled on the brain, but I do think understanding the brain will be key. There are 100 billion parallel processing components with some significant fraction of a quadrillion interconnections. I think that there is a lot to learn there.

</comment></comment></comment><comment><USER14> Certainly not.

A natural intelligence could eventually coalesce from emergent properties of H. Sapiens networked information processing systems, but not within 10 years.

</comment><comment><USER15> There is no way in hell AI will "surpass human intelligence" by 2020, using any reasonable interpretation of the sentence. I guess it makes a good headline though.

</comment><comment><USER16> perhaps in certain domains of knowledge such as chess.

</comment><comment><USER17> If AI surpassed even lobster intelligence by that date it would be quite an achievent.

<comment><USER18> What do Lobsters do that is so complicated?

<comment><USER19> Basic sight, locomotion, independent operation for years without human supervision. And they taste great.

</comment></comment></comment><comment><USER20> Kurzweil on 2029: Although computers routinely pass the Turing Test, controversy still persists over whether machines are as intelligent as humans in all areas.

</comment><comment><USER21> no.

<comment><USER22> yes.

Intelligence in any one measure. We'll create an intellegence that can out-do a human. Because if we can define an intelligence and understand it - <USER2> it up might be the easier part.

As an integrated whole? - mimicking humans? not so sure.</comment></comment>


In Praise of Public Libraries - <AUTHOR> https://www.nybooks.com/articles/2019/04/18/in-praise-of-public-libraries/ <comment><USER2> The good news: we now have the ability to create one of the greatest achievements in human history – a huge digital library, much larger than any physical library in the world, available to anyone with an internet connection. In fact, Google and others have already done so by scanning university libraries and the library of congress.

The bad news: we aren't making this available to the world because it would make it harder for publishers, distributors, and authors to make money. (And perhaps we're afraid of giving Google more power than they already have.)</comment>