Hacker News new | past | comments | ask | show | jobs | submit login

Yeah, I get that. But why punish the Desktop users with mobile interface? We used to punish Mobile users with Desktop interface back then, we just reversed the problem, didn't actually solve it.

They should be 2 separate things. 2 separate css files with @media select. 2 separate button sizes and styles.

I know what happened - designers got lazy.




Doing all the work twice is expensive. It’s not just the actual work of doing the design, but then you’re 2x testing costs too (unless you YOLO one of the modalities). More cost effective and better quality result to make a choice to make the platforms more uniform rather than trying to optimize for both. This obviously only holds when there’s a massive disparity in revenue. If your PC/laptop users make up a non-trivial parts of revenue it can start to make sense (but again, generally only if doing so will help you retain that market or get better revenues). The other thing unifying things does is it helps engineering and design teams by removing complexity.

All of the above is general trends of how these decisions are made. There will always be counter examples or situations those aren’t good ideas (or that someone has made a mistake applying a lesson to the wrong situation).

Saying an entire group of people is lazy or dumb is not a particularly insightful way of looking at anything that helps your understanding of the situation or learning what kind of results different incentives yield.


> Doing all the work twice is expensive.

Sure, but they already do all the work twice.

I get a completely different site on my phone than on a desktop/laptop.

In fact, they maintain far more than two designs - in addition to two native apps, there's a mobile website, the desktop website, and the basic HTML version. On top of that, they have multiple display density options for desktop (which admittedly is mostly just adjusting padding), redesigned the desktop site a few months ago, and had Inbox for a few years. On top of that, you can (some of these without a reload) change whether there are separate inboxes for various labels, add/remove a reading pane, and split threads into individual emails.

I don't think Google is lacking in potential to maintain a website.


They don't. The browser just adapts.



Is the plain HTML version under even the most basic maintenance? I was under the impression that was the old interface and they just kept it around because people liked it/slower countries.

The mobile vs desktop versions you posted are likely the same codebase with minimal (if any) differences. My understanding is that generally such things are accomplished transparently with flex layouts that automatically adjust to screen size


> Is the plain HTML version under even the most basic maintenance?

I doubt much work is being done on it, but presumably they at least make sure it works; I mentioned it because a few posts up (edit: you) mention testing (rather than initial design) as the reason why having multiple designs is so difficult.

> The mobile vs desktop versions you posted are likely the same codebase with minimal (if any) differences....

It's entirely possible that they're derived from a similar codebase at some point, but what reaches the browser is significantly different - it's barely responsive, based on user-agent, and appears to be significantly different obfuscated blobs of HTML, CSS, and JS.


I can’t speak to it but just because something is tested occasionally doesn’t mean the testing budgets are the same or serve the same purpose.

For example, the feature set required to support the HTML page could be frozen and the APIs backing them stable with no need to change. So testing isn’t really necessary. Alternatively, there’s just API changes being made to remove dependencies on deprecated code and so the testing coverage comes from the testing that happens of that API surface through other means. Finally, it could be that the HTML page is even fully staffed to support emerging markets. That’s a different budget potentially than the budget for the “rich” UI.

Again, my point isn’t to argue over the specific business pressures and practices Google has for their email UI. This requires a level of knowledge I don’t think either of us possess. All I’m trying to do is illustrate that there could be all kinds of pressures why the system is the way it is, but dismissing it as “laziness” or “stupidness” on the part of the designer is itself a lazy and stupid conclusion to make without concrete evidence. I generally assume that’s not the case and look for the incentives/pressures those people are under until there’s overwhelming evidence those people are actually stupid/incompetent (and even then, the question becomes what structures, incentives, pressures were in place to put those people in positions they shouldn’t occupy).


> Saying an entire group of people is lazy or dumb is not a particularly insightful way of looking at anything that helps your understanding of the situation or learning what kind of results different incentives yield.

Maybe, but when you're talking about the armies of designers at the multi-billion-dollar tech company Google not going through the effort to maintain two stylesheets, I think "laziness" is an accurate description.


No, designers did not get lazy. Devices got weirder.

It used to be that you could check the width and height of the viewport and say something like “320px wide? Must be a touch interface, deploy the big buttons”. Then tablets got big and it was like “1024px? Could be a laptop, but it’s probably an iPad, which has a touch interface, deploy the big buttons”. Then laptops got touch screens, then the Surface Studio came in and was like “HAHAHAHA”.

Now the game is “1920x1080? Could be a big tablet with touch, or a 1080p monitor without touch, or a non-maximized window on a Surface Studio with touch, or maybe it’s a monitor without touch hooked up to a laptop with a touchscreen and our window could get moved between them at any time...”

Nowadays, there’s no single reliable way to tell if a page is going to have to support touch until it gets a touch event, by which point you’ve already rendered the UI and it’s too late.


Simple solution would be to ask the user what they want. I genuinely don't understand why this is not common instead of trying to guess it.


You don’t have to ask the user, there is a media rule for querying whether the device is currently using coarse or fine pointer input[0] (though, of course, it relies on the OS not lying, which is not a given).

[0] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/poin...


Some websites probably do have settings around this, but that gets to a point someone else mentioned: you would have to basically design, build, test and maintain two UIs. Except now with the kicker that one of those layouts is only used by the 5% of your userbase that both knows that the option is available and chooses to take you up on it.


Yeah, I like rich, data-heavy, information dense desktop displays. Mobile UIs are such garbage, not to mention shit like reddit that only is able to process a request 30% of the time.



Agreed. it drives me absolutely berserk that Reddit forces you to "Click to view more comments" just to see like 3 more comments.


That particular anti user behavior is a strategy to pay reddit gold, which removes that limitation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: