Live data from Hacker News

Google to Hacker News: Not Mobile-Friendly

google.com

71–78 of 78 posts

Re: Google to Hacker News: Not Mobile-Friendly

#71

Earlier quoted context omitted.

Three browsers across a very large variety of screen sizes, resolutions, colour depths and so on. Clearly writing some 'basic CSS' is not hard but writing future proof CSS that will remain compatible with all the devices that do not exist yet is next to impossible. Therefore backwards compatibility is expected of new devices rather than that we expect existing websites to be forward compatible with devices that do no…

Seriously, all they need to do is throw in Twitter Bootstrap, re-change some div classes, and bam mobile friendly.. It's not like the site has a lot of eye candy that needs changed anyhow...

And bam lots of stuff that works today might break.

Re: Google to Hacker News: Not Mobile-Friendly

#72

Earlier quoted context omitted.

Seriously, all they need to do is throw in Twitter Bootstrap, re-change some div classes, and bam mobile friendly.. It's not like the site has a lot of eye candy that needs changed anyhow...

And bam lots of stuff that works today might break.

If you're referring to tools that crawl the site, there is an official HN API now for exactly that reason. If you expect the HTML to never change and then it does and your thing breaks that's no one's responsibility but yours.

Re: Google to Hacker News: Not Mobile-Friendly

#73
post #72

Earlier quoted context omitted.

And bam lots of stuff that works today might break.

If you're referring to tools that crawl the site, there is an official HN API now for exactly that reason. If you expect the HTML to never change and then it does and your thing breaks that's no one's responsibility but yours.

No, I'm not referring to tools that crawl the site. I'm referring to the fact that simply replacing a bunch of working code to placate one segment of users will surely create issues elsewhere. Crawlers are a (small) subset of that. Pleasing everybody on a fixed budget is impossible.

Re: Google to Hacker News: Not Mobile-Friendly

#74
post #72

Earlier quoted context omitted.

If you're referring to tools that crawl the site, there is an official HN API now for exactly that reason. If you expect the HTML to never change and then it does and your thing breaks that's no one's responsibility but yours.

No, I'm not referring to tools that crawl the site. I'm referring to the fact that simply replacing a bunch of working code to placate one segment of users will surely create issues elsewhere. Crawlers are a (small) subset of that. Pleasing everybody on a fixed budget is impossible.

How big is that one segment, though?

I honestly don't know, so maybe dang or kogir could clue us in. If a significant number of users are on mobile, and it's reasonable to expect that number to increase for the foreseeable future, then placating mobile users makes sense. I doubt that increasing their SEO is really a priority for the HN staff either way.

Also, two out of the three issues on the google site come down to simple typography and UX. Elements being too close together (links, line-height to add my own personal pet peeve) or too small (font size and the oft-complained about vote arrows) or too poorly contrasted (grey text on a lighter grey background) making things difficult to read and navigate. I don't see anything wrong with improving the readability of a site which is meant to be read... that makes the experience better for everyone.

Re: Google to Hacker News: Not Mobile-Friendly

#75
post #38

Earlier quoted context omitted.

It's not about being backwardly compatible (by and large most mobile browsers do a sterling job of that), it's about "friendly", which is to say, something which works fairly well with common mobile devices. HN has pretty tiny fonts and very small hit areas for fat human fingers. Mobile friendly isn't a meme, it's just a description of how well your chosen presentation of content translates into a different context o…

Font sizes are hints that can (and should, when appropriate) be overruled locally. Shifting the layout burden to content supplied (and or javascript) was/is a huge mistake, the browser on the device should do the layout using whatever style hints it feels are appropriate.

What about something like the size of the up/down buttons? Should mobile browsers also automatically upscale those?

Re: Google to Hacker News: Not Mobile-Friendly

#76
post #46

Earlier quoted context omitted.

The up/downvote buttons on HN are an example of 'not mobile friendly'. They work fine with a pointer, but not with a touchscreen - you often see someone apologise for downmodding when they meant to upmod, because of this problem. Pointer-driven UI and touchscreen UI have different local maxima. One of the reasons Ubuntu's Unity looks like it does is because they intend for it to look and work well on both UI types.

FWIW, opera (on iOS at least) did this right years ago, when I hit the area it just zooms in and highlights both clickable areas, so I can effectively click on the up or down arrow. (OTOH, the up/down buttons on HN are not desktop friendly either)

Sure, this still happens. That doesn't change that the experience is less nice than if the website had been designed with mobile in mind. Or if it had been and app.

Re: Google to Hacker News: Not Mobile-Friendly

#77

Earlier quoted context omitted.

No those websites should be expected to be readable at all times, but it up to the provider of the content to make that happen. Old sites read fine, as long as their stylesheet didn't make decisions to try to look a certain way at a certain resolution. If you never made the decision to write your styles a certain way, you don't have to worry about wierd rendering issues. Unless we want to force folks to use Lynx, it…

You utterly mis-understand the nature of the relationship between the server provided stream of information and the browser. Websites are not pixel perfect renditions created by dictates issued from servers, they are streams of information decorated with meta-data that give hints on how the information could be rendered. http://en.wikipedia.org/wiki/Hypertext > A browser can not predict the particulars of my design w…

This is exactly my point, the browser doesn't make me choose comic sans and wingdings. I hold in my hands, the ability to not make a site look like garbage...by using less crazy css. Information is what is relavent, it's the designer's choice to make it look like poop. This is exactly the argument that it's your job as a developer/designer to apply good css. If you do some crazy positioning and lock down your text size so it looks great on a 27inch iMac, its not the browser's fault when it obeys your styles and renders like a turd on an Galaxy S1, 2, or 50 million.
Post reply on HN