Ask HN: Why does HN require tiny baby fingers to operate on a phone?
A full 3rd or more of the time when i try to tap on the "new" link at the top of HN, i accidentally tap the "jobs" link with my average-sized fingers because my phone wraps HN such that "jobs" is directly below "new", with like 3 pixels of gap between them.
Similarly, the links across each post in the list, along with the near-microscopic "up" arrow, require teeny tiny baby fingers to tap reliably.
Certainly no tiny babies are using HN, so... please, HN, fontSize+=2 for the links! :-D
102 comments
[ 3.7 ms ] story [ 183 ms ] threadi've tried 3 of them over the past 10+ years and hated every one of them. The fact is that Android apps are simply not designed with physical keyboards in mind. They're designed for touchscreens, with keyboards being (if anything) third-rate citizens.
Still works!
PS: you lost me at "Steve Jobs".
fact is NH on mobile web is not optimized for unknown reasons. its not a big challenge to do it either. I have a userscript that makes everything bigger and removes junk out.
Sent from my iphone
in other words, lots of changes to make the experience easier (to me)
HN is well optimized on mobile. It's great as is. Lot of people just bullying their opinions.
well that's a turn of phrase I have yet to hear until this point.
Spotify recently (well over a year ago now) merged its two clients with the mobile UI being the winner. Its interesting how as a desktop user you notice all these imperfections where you are now the loser. The search is top(ish) left instead of top right and various UI elements work now _so_ much better when you are able to swipe right (to easily navigate albums in a scrollable carousel) or swiftly swipe downwards (where on desktop one must find and drag a scrollbar).
I imagine we've all experienced some of the more irksome manifestations that have already transpired due to this schism such as: websites that tell you to download an application, a support call for a broken web function that results in "use the mobile app, it works there" and isn't fixed for weeks or months, or the horrific pop-ups that encourage the use of one or the other application as dev teams hint at their disinclination to continue minority support.
that promise was a myth. The closest we got to it was responsive design and flex boxes, which are less there because there's "one size fits all" and more because it's trying to make it less painful to tweak your page for desktop vs. mobile. Many companies fall towards the latter, so a ood 95% of the time there will be a "base design", with other platforms simply being "ports".
At the end of the day, they are two different problems, so they will have two different solutions (you know, unless we enter some Cyberpunk rennassaince where humans can grow precise stylus-like appendages). The above solutions were made because it wasn't cost effective to run two different websites perfectly optimized for their respective medium.
It’s literally the only site I use zoomed-in on desktop as well, 150%.
Ironically (re. the title), I believe he even referred to the preceding standard of mobile browsing as the “baby web”.
But now “responsive design” has taken over instead. Still no multitouch.
Tangent aside, HN is a site purely focused on text with no dynamic content. It really doesn't benefit from needing to zoom in and out on your phone. It's just unnecessary friction.
Love the browser concept in it though, never seen anything like it before.
https://apps.apple.com/us/app/octal-for-hacker-news/id130888...
It's the most featureful FOSS Android app for HN, it's UI is a breeze to navigate too (if you enable swipe gestures from the tiny settings!).
There's an Android version as well: https://play.google.com/store/apps/details?id=com.pranapps.h...
I would definitely not enjoy working on a very small screen. I did have some feature phones with screens about 2x3", but those were not touch-enabled.
I currently have a phablet of sorts, a Moto g Play phone, and so it's got a relatively large screen. I have no problems navigating HN on the phone, which I do every day, usually while I eat.
I have learned that touchscreen operation does take a delicate touch, of course. The slightest feather brush of the tip of my finger is enough to activate any link, and no more is used, lest the tap mash three other links nearby.
And I agree with the poster upthread who recommends zooming. Phones have tons of accessibility tools; use 'em!
Because, as the OP states, i'm on a phone.
Though I wish Stylus supported Firefox mobile, it's better for CSS as it only does CSS.
There no technical reason that pocket computers should be incapable of applying user styles. Alas, we allowed the advent of a new technology ratchet tighter the grasp of commercial interests over society.
There were in the beginning of Smartphones. We grew past them, but the paradigms and mentalities of smartphones were well cemented by then.
The accessibility on mobile devices leaves much to be desired.
Even on desktop the text is small, down to 7pt, which leads me to have Chrome show HN at 125%.
To me, the most annoying part of using HN w/o other clients on mobile is not this, which can be addressed with extra care or zoom in. It's the idiotic decision to somehow think the post text is less important than comments and so the font color must be set to be lower. It's so low that it's unreadable in mobile. For long posts like many show-HNs, I have to just skip reading it until I get back to desktop, which isn't only not ideal, but also defeats the purpose of show-HNs since the ones that doesn't stay at top are the ones needed all the attention and HN is not helping by making it unreadable.
Ya, a simple css color change to match comments' color need to be part of the fixes to be addressed when there's a blue moon.
I'd be curious what the internal stats are for comments made on mobile since I wonder if the stats are already high and whether they show any trend of less highly rated comments.
So do these little tiny arrows really vote up and down or are they just a neutral engagement signal?
I always intended to look in the code but as it fits this topic, I guess I can just as well ask here.
Presumably you're talking about the HN developers' skills?
https://en.m.wikipedia.org/wiki/Norrmalmstorg_robbery
and
https://en.m.wikipedia.org/wiki/Leopold_von_Sacher-Masoch
While you’re complaining about link sizes, did you notice how tiny and close the voting buttons are and how bad the general accessibility of HN is?
In a way, I think all this bad design prevents people from using it too much…and that may actually be a good thing.
If this answer seemed pointless, that’s because nobody can answer this question properly on an Ask HN post. Emailing hn@ycombinator.com may probably get a more appropriate answer.
I wish Stylish worked on Firefox mobile. These are issues I can solve myself if the right tools existed (at least, the ones that exist on desktop).
https://blog.mozilla.org/addons/2020/09/29/expanded-extensio...
Ideally this should solve the "mass downvoting to impose your pet echo chamber" problem that can happen in other online communities.
With the ongoing fall of reddit if I were an admin i would propose a limit based on account age, in order to not shift the common etiquette suddenly.
Browsers on touch screens should be built to browse web pages on touch screens. Touch input events are a particularly poor representation of the operator's intent -- compared to keys, pointing device with cursor, etc. -- yet a lot of software built for touch seems to assume the opposite. The software decides that the user definitely wants to click on something and it just needs to find which thing.
As all good web browsers know, the extremely precise touch event position corresponds exactly to the (region of the) element that the user wants to click on. This is a certainty[2]. So what if the user tapped precisely on a background element for no reason at all? So what if there are multiple clickable things nearby? The user would have sent different coordinates if they wanted to click somewhere else.
[0] you generally do get some control over this, in lieu of a solution to the problem
[1] and the browser must, as much as possible, style the content in the way (not-) specified, even at the cost of the user experience / accessibility
[2] It is, by definition, without doubt. A fact. A universal truth. A ---
Saying that making things bigger isn't a solution is nonsense. Shifting blames to browser makers is even less of a solution.
Making HN 200% bigger if it detect a small screen would fix most issues and it's 3 lines of CSS. But sure, let's wait until that magical browser you describe arrives to fix everything instead. Any day now.
Simply making things bigger isn't a comprehensive solution (to what is a difficult user input problem, as you know), but it is something that can help, and crucially can be implemented in web browsers. I want web browsers to be less cowed by web designers/developers, to empower the users.
I'm not trying to change your mind/experience. I know that a lot of people must be similarly unaffected by such issues. Not everyone is in that privileged group, however.
You'll see this with all sorts of other mobile UIs that are web based. Honestly, as much of a pain in the ass as it can be, I prefer it to existing mobile UX "solutions" out there, it might suck to pinch zoom on links before I touch them, but it sucks even worse to interact with the majority of mobile web interfaces.