Ok, but there are also other css things I would like to add on mobile, but how can I do this without a console, do I need an extension like grease monkey?
With notion.site, they basically went out of their way to break everything for viewers: they give you what I presume is their editor (which clobbers a lot of the browser’s normal functionality, though whether it does a good job of it or not I can’t tell, never having used it), but with most of the editing functionality clumsily disabled. The end result is a bit better than it was a year and a half ago (https://news.ycombinator.com/item?id=23925461; the links and contenteditable parts have been mostly fixed), but still extremely bad, and still painfully keyboard-inaccessible (Up/Down do their own wonky thing that does let you navigate, but roughly by paragraph, and PageUp/PageDown/Space/Shift+Space/Home/End do nothing; but I just discovered that if you click on the page title text, then Up/Down start to do nothing and PageUp/PageDown/Space/Shift+Space/Home/End work).
The issue in the article was about finger clicking on links.
On a desktop OS, you should not have issues using pointer devices. (On mobile devices, when using fingers to tap, one normally pinches to enlarge and re-pinches to adjust size... Although I am not really sure if this still works with nowadays' mobile software: I am assuming text reflow, being that strictly required, and last time I checked most implementations in browsers were broken.)
For comfort in readiing, on a desktop OS, one is supposed to quickly adjust the zoom level with [Ctrl]+[Wheel], or [Ctrl]+[+/-] or similar...
I zoom out to 80% in Firefox fwiw. There may well be more of you that zoom in, just wanted to point out it's not necessarily obvious to everyone it should be different in that direction.
Last time when I use this app, there is no login and comment function, only reading. I had to use Materialistic - Hacker News [0], with old UI and no update.
Personally not a fan of using an app to browser something that contains that many links to the web. You're either stuck in the in-app browser (no bookmarks, etc.) or there is a lot of switching between the app and the browser.
I have an iOS device. The experience might be better on Android.
I have a rudimentary app wrapper for HN on Android, that just renders HN in a webWiew control but shells out to your default browser for external links.
It was the starting point of my own HN app, but as usual I never finished it.
I personnally prefer to use Glider for HackerNew [0] mostly because it is available from F-droid and the webview uses firefox and can be switched to the browser pretty seemlessly.
Writing from it now, it's pretty simple and has everything needed
A bookmarklet like this one could also be used as a quick fix - but I know it's not very practical in the long run because it has be called on every page reload:
And Chrome strips the `javascript:` prefix before pasting. I guess to make it harder for attackers to trick clueless users into running JS on their online banking?
-- it's not clear how to automate applying one such javascript snippet on each page load of a URL of defined pattern matching - there probably exist at least browser extensions
> it's not clear how to automate applying one such javascript snippet on each page load of a URL of defined pattern matching - there probably exist at least browser extensions
If anyone from HN is here reading: maybe just make this change? The current touch targets on mobile are much too small and definitely fall below most UX / accessibility standards.
`em` is a relative unit that can change depending font-size of the given element while `pt` is an absolute value. the W3C does not recomend using any absolute value such as `pt` for text rendered on screens. only relative values or `px` should be used. [0] I would suggest this very helpful article on the topic, it provides a lot of good info and context on this subject.
Historically, the term "em" goes back to the days of printing with metal type, and referred to the width of a capital "M" in the current typeface and point size:
Both px and pt (and cm, mm, in etc.) are absolute (in the sense that they don't depend on the current font size, only on the pixel density and scale factor of the display). So there is no reason to prefer px to the other units.
In traditional typography, pt is relative to the size of a font, but in CSS it is just an absolute measurement like px.
The tutorial you link to is wrong, which is weird since it is written by the inventor of CSS! It might be because it is out of date and reflect the original intention of CSS, not how it actually turned out.
Originally, the intention of CSS was that px should correspond to a pixel and pt/mm/in to physical dimensions, so the ratio between px and pt would vary depending on the pixel density. But people started to specify font sizes in px, which meant text would just become unreadably small when high-density displays were introduced. So instead px was redefined as a physical unit rounded to nearest pixel, and the other absolute units defined relative to this.
Much terminology have a different meaning in CSS than in traditional typography. For example the em unit does not actually depend on the width of on "m"-letter in the font, rather it depends on the height of the font.
Yes. Also, use unitless values for line-heights, it's basically a shorter way of expressing it as a percentage of the font-size. This way, if the font-size changes (either a change to the site design or the user changes it), the line-height will be proportionally appropriate.
12pt equals 16px, 20pt equals 26.667px. The unitless line-height would be 1.6667. Regardless of how it's written, that's a pretty big value for regular-sized text (compared to larger text for something like a heading). I guess that's helpful in narrow views of nested comments, where the close button might wrap to a new line, below another clickable element.
For me the up- and downvote icons are too close together and I always have to pinch zoom to upvote (I don't downvote often). So prefer a bit more spacing between them.
You can't downvote comments if you have less than 501 karma, and the downvote button doesn't appear on replies to your own comments. Plus, there is no downvote button for stories, just for comments.
I'd prefer moving them to the same line as "reply", putting them side by side, and changing them to "▲ upvote" and "▼ downvote". Adding the text and putting them side by side makes them easier to hit, and moving them down to the "reply" line frees up valuable space at the left side.
To that newly freed space on the left move the "next" and "prev" links, and if "next" and/or "prev" is not available for a particular comment pad its space so if "next" and/or "prev" is there it is always at the same horizontal position.
This makes it easier to skip forward or back a subtree at a time, because after a given click of "next" or "prev" is executed your mouse or finger will be over the next "next" or "prev".
An other issue is the link to your profile in order to get back to discussions you were involved in.
On some phone widths, you end up with the profile and "logout" links right above one another and it's even odds you'll have to log back in on all your device because you'll fat-finger the wrong one and there's no confirmation or anything, just straight fuck off.
No idea why that damned logout link can't be moved to the profile, is anyone really in such a hurry to log out they can't just hit two links?
(A bit ironic that the article about supporting small screens doesn't render well on a small screen: The before and after headings are both placed above the two screenshots.)
not really? looks good, functions well. slightly awkward on mobile since the text is small. very fast, loads on all devices, very accessible because of good document structure. you could reasonably browse HN on a text-only terminal.
It's weird because HN seems like it has a very simply document structure and would easily be made very accessible. But no, it's a horrible mess instead.
Readable HTML does not mean it's good HTML, also these are not mutual exclusive. The UX and design can only be improved if you improve the code. Tables only bring you so far..
I for one value the HN limited aesthetic. From a ui perspective its not ideal, but keeping the site extremely simple and a little coarse surely disincentivizes mass and mob adoption.
Personally, I find the user experience on mobile is fantastic. The small icons and links mean that more content can fit on my tiny screen. This is without a doubt one of the main reasons HN is the most visited site on my phone.
(Not trying to start a debate. Just pointing out that user experience on mobile is subjective, rather than objectively "pretty bad".)
With the unimportant caveat of the upvote and downvote icons being too close to each other I think the plain simpleness of HN works perfectly from a mobile browser.
Same here. Of all websites I frequent HN has the best mobile experience. The only thing they need to fix is indeed up and down being too close to each other.
Yes, please! I often tap the “[-]” button as well and it is quite difficult to get right.
Especially now that the “next” button has been added. It is very disorientating when I accidentally tap that.
In fact, all tap targets are too small for mobile. Clicking the comments link to open a post is difficult and I sometimes click flag or hide by accident.
- 'prev' / 'next' goes to the adjacent sibling comments
- 'root' goes to the top level comment in the thread (not the post)
They are very useful on mobile if you're deep in a thread, and want to go to the next top-level thread. To do that, press 'root' and then 'next' (or collapse it with [-]).
What I really would like to have would be to collapse comment threads via a column that runs the length of the comment thread and is indented like its respective comment.
This way I don't have to scroll to find the comment to collapse its thread, and clicking the column is easier.
Hackerdaily [1] has a nice interface for collapsing comments too, though it suffers from the same issue on mobile that the main HN site does. The collapse button just follows you down the page until you are through all of a comment's children, so you can always collapse without scrolling back up.
This is one of the few things where I think the new Reddit is actually a little better. Same basic idea as at your link, but make it so that those guidelines that are running down to the left of the subtree are the thing you click to collapse, instead of having a separate invisible (until you mouse over) collapse column next to the guideline.
My 5 cents: This makes it way too easy to accidentally collapse threads as the clickable area is hard to tell apart from whitespace. (Speaking from regular and annoying experience with on old.reddit.com.) I, for one, much prefer the HN style buttons.
I was going to ask how to install it but figured I should be able to figure it by myself. After a few web searches and reading this Hacker News discussion¹, I installed GreaseMonkey and it was super-easy from there.
There are lots of interesting HN-specific browser extensions, if you know where to look.
One I came across performs automatic voting. On pageload, it scans for comments starting with "So..." or ending with " lol" and downvotes them. I'm not sure who this is for. "Communication peeves" comes to mind, but doesn't quite fit. I'm don't know what the word is for this.
A little bit of UX like this would go a long way towards fixing the problem where the first root comment gets all the activity, because people get sucked in to one of many subthreads as they scroll past.
See, I would have just put that in a userstyle (yes, I have Stylus on mobile) rather than write a blog post about it. But I'm grateful for the blog post...now I can put those lines in my userstyle.
Custom user styles might work on Chrome, but on Firefox mobile, it's an atrocious experience. You need to install the nightly version, set some hidden developer flags, create a addon collection with your user account on addons.mozilla.org and type the collection ID in the settings of your mobile browser.
162 comments
[ 0.23 ms ] story [ 244 ms ] threadAt least the work on mobile chrome. You open a site, then tap the url bar and type the name of the bookmarklet and tap that.
I have one that removes all iframes, getting rid of 90% of ads
The two Screenshots are placed next to each other instead of having the headline between them, and one of them doesn't even render.
I have to use notion at work and if I didn't love my job for other reasons their UI might be enough to make me walk out the door.
Plus: my goodness for a few words and two images this page takes forever to load and render, even with a warm cache. Cutting-edge UX in 2021! hooray!
On a desktop OS, you should not have issues using pointer devices. (On mobile devices, when using fingers to tap, one normally pinches to enlarge and re-pinches to adjust size... Although I am not really sure if this still works with nowadays' mobile software: I am assuming text reflow, being that strictly required, and last time I checked most implementations in browsers were broken.)
For comfort in readiing, on a desktop OS, one is supposed to quickly adjust the zoom level with [Ctrl]+[Wheel], or [Ctrl]+[+/-] or similar...
Just a few lines of CSS could really improve readability here.
Font size is buried three levels deep under Settings > Accessibility > Font Size
[0]: https://play.google.com/store/apps/details?id=io.github.hidr...
I have an iOS device. The experience might be better on Android.
It was the starting point of my own HN app, but as usual I never finished it.
I'm typing this comment via it, actually.
Writing from it now, it's pretty simple and has everything needed
[0] https://github.com/Mosc/Glider
javascript:(()=>document.querySelectorAll('.comhead').forEach(e=>{e.style.fontSize='12pt';e.style.lineHeight='20pt'}))()
-- a good starting guide is at https://www.freecodecamp.org/news/what-are-bookmarklets/
-- it's not clear what could be the best method for calling them with a keyboard shortcut (where relevant/applicable), but a few approaches exist: https://superuser.com/questions/387729/creating-hotkeys-in-f...
-- it's not clear how to automate applying one such javascript snippet on each page load of a URL of defined pattern matching - there probably exist at least browser extensions
Userscripts with extensions like tampermonkey.
I don't know how many times I've accidentally flagged a post when using my iPad because the text is so small. And there's no unflag button.
Fortunately, I have a controversial commenting history, so the system only very rarely allows me to flag anything.
[0] https://www.w3.org/Style/Examples/007/units.en.html
https://en.wikipedia.org/wiki/Em_(typography)
There's also a unit called an "en", which was based on the width of "N":
https://en.wikipedia.org/wiki/En_(typography)
Both px and pt (and cm, mm, in etc.) are absolute (in the sense that they don't depend on the current font size, only on the pixel density and scale factor of the display). So there is no reason to prefer px to the other units.
In traditional typography, pt is relative to the size of a font, but in CSS it is just an absolute measurement like px.
See: https://drafts.csswg.org/css-values-3/#absolute-lengths
The tutorial you link to is wrong, which is weird since it is written by the inventor of CSS! It might be because it is out of date and reflect the original intention of CSS, not how it actually turned out.
Originally, the intention of CSS was that px should correspond to a pixel and pt/mm/in to physical dimensions, so the ratio between px and pt would vary depending on the pixel density. But people started to specify font sizes in px, which meant text would just become unreadably small when high-density displays were introduced. So instead px was redefined as a physical unit rounded to nearest pixel, and the other absolute units defined relative to this.
See: https://drafts.csswg.org/css-values-3/#absolute-lengths
Much terminology have a different meaning in CSS than in traditional typography. For example the em unit does not actually depend on the width of on "m"-letter in the font, rather it depends on the height of the font.
12pt equals 16px, 20pt equals 26.667px. The unitless line-height would be 1.6667. Regardless of how it's written, that's a pretty big value for regular-sized text (compared to larger text for something like a heading). I guess that's helpful in narrow views of nested comments, where the close button might wrap to a new line, below another clickable element.
EDIT: It originally said "less than 500 karma".
To that newly freed space on the left move the "next" and "prev" links, and if "next" and/or "prev" is not available for a particular comment pad its space so if "next" and/or "prev" is there it is always at the same horizontal position.
This makes it easier to skip forward or back a subtree at a time, because after a given click of "next" or "prev" is executed your mouse or finger will be over the next "next" or "prev".
On some phone widths, you end up with the profile and "logout" links right above one another and it's even odds you'll have to log back in on all your device because you'll fat-finger the wrong one and there's no confirmation or anything, just straight fuck off.
No idea why that damned logout link can't be moved to the profile, is anyone really in such a hurry to log out they can't just hit two links?
body { margin-top: 0; background-color: #EAEBE3; }
.title { font-size: 14px; }
.titlelink { color: #131010 }
.subtext { font-size: 11px; }
.comment { font-size: 14px; line-height: 1.5; }
.default p { margin-top: 16px; max-width: 100ch; }
https://i.imgur.com/FmbgVOo.png
and moving "Lists" from bottom navigation to the top navigation would good thing.
I thought it was bad but it is actually worse. Maybe accessibility is the argument to make, because my prayers always fell upon deaf ears.
The UX and design could be better, that's true.
(Not trying to start a debate. Just pointing out that user experience on mobile is subjective, rather than objectively "pretty bad".)
Especially now that the “next” button has been added. It is very disorientating when I accidentally tap that.
In fact, all tap targets are too small for mobile. Clicking the comments link to open a post is difficult and I sometimes click flag or hide by accident.
- 'prev' / 'next' goes to the adjacent sibling comments
- 'root' goes to the top level comment in the thread (not the post)
They are very useful on mobile if you're deep in a thread, and want to go to the next top-level thread. To do that, press 'root' and then 'next' (or collapse it with [-]).
This way I don't have to scroll to find the comment to collapse its thread, and clicking the column is easier.
This is used in some subreddits in the old Reddit style, e.g. /r/de as can be seen here: https://old.reddit.com/r/de/comments/rcc9us/experten_finden_...
https://hackerdaily.io/29482351/comments
Link: https://github.com/plibither8/refined-hacker-news
[0] https://gist.github.com/evanreichard/96d89512cbfe23e5d7a8147...
[1] https://i.imgur.com/qGUltI8.png
Many thanks! It works like a charm.
¹ https://news.ycombinator.com/item?id=22896078
One I came across performs automatic voting. On pageload, it scans for comments starting with "So..." or ending with " lol" and downvotes them. I'm not sure who this is for. "Communication peeves" comes to mind, but doesn't quite fit. I'm don't know what the word is for this.
I very much appreciate the fact that this wasn't turned into a article three times the size, just the information and relevant code.
In other words, you can't really do it.