This is a great example of why mobile browsers suck. It is the job of the mobile browser to be able to fix these problems automatically, to resize and reflow text so that it displays properly on the device.
The whole business model of Google is knowledge about what users want to see on the web. And their judgements about it are context-specific: they are true for the current situation, when the mobile browsers work as they do. If Google is wrong, and users want the sites that are _not_ optimized for mobile, they will lose their market share.
However, if they are right, and the users _do_ want to see sites optimised for mobile, it means that while you are right technically about how mobile browsers are supposed to work, and how sites are supposed to work, the real users just don't agree with you.
What if my target audience is actually that 1% niche that doesn't care about mobile, or a niche that actually uses decent browsers and mobile platforms, so they're perfectly able to view my simple page even without stupid meta viewport tag?
It seems easy to just add the tag and a few CSS rules - but what if this is a still useful page from 2005 which I have forgotten about?
Google makes these kinds of decisions to improve their service: Finding the information you need. If you look up some information about bananas on your 4" touchscreen device and 2 sites provide info on them: A mobile site and a "regular" website, I want the mobile/responsive website, not the "regular" one.
They should not. A mobile browser should follow standards defined by people who thought about this kind of stuff. Mobile browsers render "desktop-designed" webpages this way because they should so according to the HTML/CSS/JS specs.
As a developer, you should define which content should scale and/or resize according to browser viewport width and pixel density: Better known as "Responsive".
Isn't it the web designer's responsibility to provide enough metadata so that the browser can actually reflow the content without breaking the intended flow? Correctly reflowing a website doesn't sound like something a program could do without knowing enough context.
I didn't think that was ever in doubt, was it? HN has always been difficult to use on mobile devices due to all the fixed dimensions forcing the page to render at an unsuitable size.
Which always surprised me. I know very little about web design (just use bootstrap for prototypes sometimes), but the HN seems to be very minimalistic in design and features (that's what I like about it, actually). So it would seem that making it fit the viewport would be an easy task.
Apart from accidental downvoting I never had any problems with it. Get a browser that nicely reflows and that locks horizontal scrolling nicely (not too much, not too little) and it's a breeze to read and participate. I love that I can choose the font-size and zoom level myself, notblindthankyouverymuch.
If you resize desktop browser window you see that is scales well. The width is set to 85%.
I assume that most popular mobile web browsers render HN the same. This could mean that there are some standards for mobile devices that make it look as bad as it is. Unless you are someone who really wants to and can change the standard I assume that you start complying with it. :)
Two bookmarks for different browsers, no big trouble. I actually like the old school table based layout of HN. One of the things that stay the same. And it works great with Vimium^_^
I think one thing that will greatly help mobile experience for me is to add a reddit-style collapse comment section toggler. On mobile devices (and in some cases on desktops), it will help reach the lower comments easily without having to scroll a lot.
The address bar takes up a lot of vertical space that could be better used to show more lines of text. That big block of empty white space on the previous item next item close menu bar is also wasted.
If Google really wants to fix browsing on mobile they might want to look at their own products as well as using their seo powers.
It still blows my mind that the text on the HN homepage is unreadably too small on my Samsung Galaxy S4. Surely you guys have enough money and/or technical chops to fix that?
The Galaxy S4 came out well after HN was built, why should the burden be on HN, why don't you say 'Surely Samsung would have the money and/or technical chops to make a product compatible with the web as existed prior to when the device was launched?'.
edit: hello downvoters, would you be equally upset that a windows 95 machine would refuse to run office 2000?
The device's web browser should attempt to adapt the page to fit the device rather than the site telling the browser how it should adapt to the size of the screen.
Either I don't understand you or we're in agreement. Yes, the device's web browser should do the adaptation, sites can tell browsers whatever they want and browsers are totally free to ignore that information, after all the browser and the device have more information to work with.
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 not even exist.
And that's ignoring for the moment the burden of testing a website on all possible devices (which is the way we nowadays go about developing commercial websites, and which is entirely wrong, if a website works on one browser it should work on all, a ship which has long ago sailed but which made good sense at the time and was one of the main reasons the web caught on over all those proprietary and fragmented efforts at information dissemination that preceded it).
>>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.
Considering that the problem exists in the present and is very real, I'm not sure why not being able to write future-proof CSS is a big issue. How often do commonly-used CSS properties (e.g. font-size) become outdated? When was the last time you had to re-write the stylesheets on one of your websites?
>>And that's ignoring for the moment the burden of testing a website on all possible devices
I think the HN userbase is not only capable but also would be willing to perform this testing. Deploy the website on a separate directory (e.g. news.combinator.com/newdesign/etc.) and direct users who opt into the beta there.
Heck, I bet there's quite a few people here who would love to take it on as a volunteer project.
It's not about capability it's about where the burden should lie. Future readers should be compatible with past documents, not the other way around.
Case in point: the geocities files that were backed-up and are on display from a variety of sources (including mine, but also the internet archive and archive team) are static, no longer in maintenance. The same goes for all of the internet archive. If you want to see that content at any point in the future you had better hope that the browsers are the ones to adapt to the past because the past is certainly not going to adapt to the browser and as the web ages there will only be more of the past and relatively speaking less of the present.
The web is aging rapidly and the current development of modern browsers on modern devices failing to render sites that are only a few years old properly is a worrisome one.
HN is in fact one of the least affected sites in this respect.
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...
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.
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.
So, the browser's failure to behave the way every browser for decades upon decades has been supposed to behave is actually a problem with the website? Show me a browser from before 2005 that won't reflow text.
The whole 'not mobile friendly' meme really needs to die. The sites are never at fault, a mobile browser is entirely capable of rendering sites however they see fit and to ignore or incorporate any or all elements of the style sheets and mark-up that a site supplies.
The pixel-perfect coupling that people expect between what a site should look like according to the designers and how that site is rendered by the browsers is an illusion, that's not the way the web was supposed to work at all, web sites provide information and loose markup hints and browsers then render that information in the best way suitable for the device and its user.
Don't blame the website, blame the browser instead.
Ironically, looking at ancient (pre-CSS, pre table based layouts) websites through modern browsers gives you instant adaptive design because all there was was content, no eye candy.
If we had wanted pixel based rendering we could have done a damn sight better than CSS, style sheets and markup are hints, not ultimatums to be obeyed or failure will occur.
Just think about the burden that these demands make on older websites, websites that worked perfectly well in the past suddenly need to be modified in order to be displayed properly, that's a total inversion of the way things are supposed to work. Old content and older websites should be displayed with as high fidelity as possible on newer browsers and devices. You can't fault the makers of old websites for not being 'future compatible' but you can fault the makers of new devices and browsers for not being compatible with the past.
When I switch to "no style" in Firefox, HN becomes pretty responsive. The only 2 problems I can see are that the textarea on top still has a fixed width and that the comments are not indented.
Mobile browsers should offer a custom style option, or at least a "no style" option like FF does.
Sidenote: Is it possible at all to have horizontal scrolling websites that Google consideres mobile friendly? Some websites are intended to have a horizontal scroll. What are they supposed to do?
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 of use. Context changes often require different choices about how you break up your content to throw at someone - this has been the case since the web began.
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.
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.
A browser could detect that a component on the page has a link attached to it, could reason out that that component is too small for the default display resolution / DPI combination of the device and could decide to scale up the element in response.
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.
Its up to the person who wrote the site stylesheet to make it behave in this instance. It's not Safari, or Chrome, or FF, or Dolphin that made me declare that my text should be this big or that my div should be that wide no matter the context. I am capable of writing css that adapts; if I choose not to, my site is less readable. Writing a web browser that makes those decisions for me would make my job of designing the site harder, not easier.
Perhaps an alternative would be some declaration that says "Hey render me this way if you feel like it, but use these all powerful browser supplied styles if I become unreadable"
Some browser's have implemented that reading mode (safari?) and it seems like a cool idea, but I think it only works if you provide really good HTML5 markup.
Essentially you are saying that older websites should not be expected to be readable on more modern devices because the burden of change lies with the provider of the style sheet to be compatible with devices that don't exist yet. That's not the intention of the web, it's not a display protocol, it's an information transfer protocol.
if it were a display protocol then we could have kept things a lot simpler, specify display width, height and DPI in the request, get back a compressed image and a bunch of 'hot zones' or 'fields' in response. Such protocols existed and they did not make the cut, the one that did explicitly left the rendering decisions to the client receiving the data.
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 is up to the content provider to say what their content looks like. A browser can not predict the particulars of my design well enough to make those decisions for me.
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.
> A browser can not predict the particulars of my design well enough to make those decisions for me.
On the contrary, you are not capable of predicting the context in which the information you supply will be used, so less design is better. If you want pixel perfect eye candy write an application but don't use the web, it's lossy by design, for all you know your information will be presented in an audible rather than a readable form, will be printed out on a printer that does not support colour and/or will be read with a device 10,000 years into the future.
Your design is not relevant, the information is what is relevant.
Are you saying that sites that don't provide a positive experience across screen sizes shouldn't worry? Because browsers aren't supposed to do anything besides present information?
Sites don't worry, people do and plenty of sites are divorced from the people that created them. In the interest of keeping that information accessible the onus is first and foremost on the makers of the consumption devices and associated browsers to render that content as accurately as possible. Regressions (where content that rendered just fine on previous generation devices but where future devices for whatever reason fail to display this content) should be avoided where possible.
Note that in the case of content such as 'flash', 'silverlight' and other plug-in related content this is going to be a major problem.
Finally, in the interest of commerce and user experience website owners are free to improve their sites to enhance the experience for their users but they should not be required to get basic functionality working.
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.
The browser, by default, styles most content pretty well. It's the designers who have asked for and gotten all of the tools which break how our web looks, via CSS and JavaScript. If we really wanted the browsers to decide how the content should look, then we shouldn't have given the designers these tools in the first place.
The "let the browser decide" ship has sailed, and the designers won (with our support, I might add). All we can do now is use those a same tools to take back control.
I see 3 schools of thought:
1) HN should be more mobile-friendly, so I can read it.
2) HN should be more of a platform on top of which users can build tools to use it, so let's build one.
3) Why not both?
I think both iOS and Android have already a plethora of user-made apps. (some of them ok, some of them not ok)
On a tablet i prefer the HN website to any of the apps currently available.
On a phone, I think there are a few good Android apps and no good enough iOS apps...
What is the best HN experience on mobile? I think there's need for better understanding of what we "want" from mobile, apart from the obvious things (i.e. readability)
Interesting, here is my HK clone site(Most of code r same as HK) and it's Mobile-Friendly according to Google[1].I think they can change come code for Mobile.
Just bunch of easily reflowed text and a bit of ASCII art. Browser on my Nokia N900 shows it just fine, zooming is usable, everything seems "friendly". If Nokia could do it on Maemo long time ago, why Apple and Google can't do it now?
The biggest winners of this change are the SEO companies that charge small businesses lots of money who will now charge them lots of money to make sure their website is mobile friendly (even if it already is).
I'd like to take this moment to point out that a few weeks ago, HN did try for a mobile friendly styling, and the HN population at large rose enough of a fuss about "it looked fine as it was before" that they reverted it back.
77 comments
[ 4.2 ms ] story [ 101 ms ] threadAnd: It pisses me off to no end that Google is in the position to decide how a site has to look like on $device.
They announce that you will get a worse SERP if your site doesn't do X and everyone scrambles to please mighty G.
If they decide that every site has to have a yellow background, starting next week, what will you do? Give in?
However, if they are right, and the users _do_ want to see sites optimised for mobile, it means that while you are right technically about how mobile browsers are supposed to work, and how sites are supposed to work, the real users just don't agree with you.
It seems easy to just add the tag and a few CSS rules - but what if this is a still useful page from 2005 which I have forgotten about?
As a developer, you should define which content should scale and/or resize according to browser viewport width and pixel density: Better known as "Responsive".
Mobile browser should render the page exactly how the designer specified.
If you resize desktop browser window you see that is scales well. The width is set to 85%.
I assume that most popular mobile web browsers render HN the same. This could mean that there are some standards for mobile devices that make it look as bad as it is. Unless you are someone who really wants to and can change the standard I assume that you start complying with it. :)
Two bookmarks for different browsers, no big trouble. I actually like the old school table based layout of HN. One of the things that stay the same. And it works great with Vimium^_^
http://imgur.com/XpygcTq
http://imgur.com/cAjceFY
The address bar takes up a lot of vertical space that could be better used to show more lines of text. That big block of empty white space on the previous item next item close menu bar is also wasted.
If Google really wants to fix browsing on mobile they might want to look at their own products as well as using their seo powers.
edit: hello downvoters, would you be equally upset that a windows 95 machine would refuse to run office 2000?
The device's web browser should attempt to adapt the page to fit the device rather than the site telling the browser how it should adapt to the size of the screen.
And that's ignoring for the moment the burden of testing a website on all possible devices (which is the way we nowadays go about developing commercial websites, and which is entirely wrong, if a website works on one browser it should work on all, a ship which has long ago sailed but which made good sense at the time and was one of the main reasons the web caught on over all those proprietary and fragmented efforts at information dissemination that preceded it).
Considering that the problem exists in the present and is very real, I'm not sure why not being able to write future-proof CSS is a big issue. How often do commonly-used CSS properties (e.g. font-size) become outdated? When was the last time you had to re-write the stylesheets on one of your websites?
>>And that's ignoring for the moment the burden of testing a website on all possible devices
I think the HN userbase is not only capable but also would be willing to perform this testing. Deploy the website on a separate directory (e.g. news.combinator.com/newdesign/etc.) and direct users who opt into the beta there.
Heck, I bet there's quite a few people here who would love to take it on as a volunteer project.
Case in point: the geocities files that were backed-up and are on display from a variety of sources (including mine, but also the internet archive and archive team) are static, no longer in maintenance. The same goes for all of the internet archive. If you want to see that content at any point in the future you had better hope that the browsers are the ones to adapt to the past because the past is certainly not going to adapt to the browser and as the web ages there will only be more of the past and relatively speaking less of the present.
The web is aging rapidly and the current development of modern browsers on modern devices failing to render sites that are only a few years old properly is a worrisome one.
HN is in fact one of the least affected sites in this respect.
But then iPhone happened.
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.
The pixel-perfect coupling that people expect between what a site should look like according to the designers and how that site is rendered by the browsers is an illusion, that's not the way the web was supposed to work at all, web sites provide information and loose markup hints and browsers then render that information in the best way suitable for the device and its user.
Don't blame the website, blame the browser instead.
Ironically, looking at ancient (pre-CSS, pre table based layouts) websites through modern browsers gives you instant adaptive design because all there was was content, no eye candy.
If we had wanted pixel based rendering we could have done a damn sight better than CSS, style sheets and markup are hints, not ultimatums to be obeyed or failure will occur.
Just think about the burden that these demands make on older websites, websites that worked perfectly well in the past suddenly need to be modified in order to be displayed properly, that's a total inversion of the way things are supposed to work. Old content and older websites should be displayed with as high fidelity as possible on newer browsers and devices. You can't fault the makers of old websites for not being 'future compatible' but you can fault the makers of new devices and browsers for not being compatible with the past.
Mobile browsers should offer a custom style option, or at least a "no style" option like FF does.
Sidenote: Is it possible at all to have horizontal scrolling websites that Google consideres mobile friendly? Some websites are intended to have a horizontal scroll. What are they supposed to do?
Mobile friendly isn't a meme, it's just a description of how well your chosen presentation of content translates into a different context of use. Context changes often require different choices about how you break up your content to throw at someone - this has been the case since the web began.
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.
Works well, looks identical on all devices, is future proof: pick any two.
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.
(OTOH, the up/down buttons on HN are not desktop friendly either)
Perhaps an alternative would be some declaration that says "Hey render me this way if you feel like it, but use these all powerful browser supplied styles if I become unreadable"
Some browser's have implemented that reading mode (safari?) and it seems like a cool idea, but I think it only works if you provide really good HTML5 markup.
if it were a display protocol then we could have kept things a lot simpler, specify display width, height and DPI in the request, get back a compressed image and a bunch of 'hot zones' or 'fields' in response. Such protocols existed and they did not make the cut, the one that did explicitly left the rendering decisions to the client receiving the data.
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 well enough to make those decisions for me.
On the contrary, you are not capable of predicting the context in which the information you supply will be used, so less design is better. If you want pixel perfect eye candy write an application but don't use the web, it's lossy by design, for all you know your information will be presented in an audible rather than a readable form, will be printed out on a printer that does not support colour and/or will be read with a device 10,000 years into the future.
Your design is not relevant, the information is what is relevant.
Note that in the case of content such as 'flash', 'silverlight' and other plug-in related content this is going to be a major problem.
Finally, in the interest of commerce and user experience website owners are free to improve their sites to enhance the experience for their users but they should not be required to get basic functionality working.
The "let the browser decide" ship has sailed, and the designers won (with our support, I might add). All we can do now is use those a same tools to take back control.
I think both iOS and Android have already a plethora of user-made apps. (some of them ok, some of them not ok)
On a tablet i prefer the HN website to any of the apps currently available. On a phone, I think there are a few good Android apps and no good enough iOS apps...
What is the best HN experience on mobile? I think there's need for better understanding of what we "want" from mobile, apart from the obvious things (i.e. readability)
How many possible ways is there for a site to make itself hard to read on a small screen?
How many rules would a mobile browser need to have to handle them all?
How smart would these rules need to be to distinguish between intentional and unintentional design decisions?
It's beyond question that websites should be coded in such a way that they works on a range of devices screen sizes. Anything else is madness.
[1] http://news.fdzh.org/
[2] https://www.google.com/webmasters/tools/mobile-friendly/?url...
Just bunch of easily reflowed text and a bit of ASCII art. Browser on my Nokia N900 shows it just fine, zooming is usable, everything seems "friendly". If Nokia could do it on Maemo long time ago, why Apple and Google can't do it now?
We can't have it both ways.