I've fat fingered the "hide" button quite often when I was trying to hit the comments button. That's the main thing that I find slightly annoying about the default HN layout
I don't quite understand the mentioning of node at the start of the article as a cause of this. You can write a monolith in node just as well as you can write a web of microservices. That said I agree with the sentiment of this article, it's very frustrating to deal with in any company. Especially when these microservices aren't versioned under the same repo and/or are hosted at different providers causing unnecessary latency.
What's the reason for the max length in the input? 400 characters is very short to answer the prompt "Please start by introducing what you are doing and what are any other industries and nature of the job that you are looking for"
I don't really want Git to change so much. What I do want however is for other tools to take over features from Git. Pretty much every app that I use in my daily life would be enhanced if it had git-like features.
Here's a weird take: because the landing page is so vague the user doesn't know whether the app is useful or not so the user will sign up just to take a look at the app to figure out what it actually is. Once the user realizes it isn't for them they bounce. So higher signup rate, higher bounce rate in this case? Total baseless speculation here :D
This article is very frustrating, it's full of assumptions that are stated as facts.
> Most of all, it makes people perceive your site to be faster than it actually is. Remember that we are designing interfaces for use by real people. We need to give people the illusion of speed.
The first claim is not backed up by evidence? At least not in this article and the claim "we need to give people the illusion of speed" makes no sense?
And then for the perceived benefits of skeleton loading screens.
> 1. Helps people perceive your screen to load faster
Again 1. is just an assumption for all I can tell, you don't cite any research on this.
> 2. Eliminates surprises
As for 2, with skeleton screens there is still pretty much always a significant layout shift as it is quite uncommon for all elements to have pre-defined dimensions so the skeleton screen actual works. So it can work for some screens. But if you implement it only for some screens, users will be surprised about the differences. Hence, user is surprised? :D
> 3. Gradual loading of UI – clear indication of progress
As for 3, there is literally no difference in the indication of progress between this and a spinner.
> 4. Shows exactly what’s loaded and what’s yet to load
Specifically being able to create a deep link to a passage is a very powerful capability indeed. The friction required to look up a paper and navigate to the specific passage for a given reference can really be so high that we just end up avoiding it altogether I feel. Kudos to you for trying to solve this problem!
I personally find LaTeX a little too friction-full (is that a word?) on the input side. The output looks beautiful but the lack of feedback when writing stuff keeps me from actually adding stuff to it. Although your daily notes seems like it might help with this tendency a little bit.
This is a problem I'm currently trying to solve with my current project (https://topictrails.com/ if you're interested).
* The "seamless" mode for all the views that removes action buttons. Feels kind of like an "exploration view".
* New cards created on the home page are automatically added to a "daily" page (but can still be moved to another day).
* I like how the sidebar is done, it doesn't get in the way as much as in other apps.
* The "thoughts" collection, where notes without links go. The name is perhaps a little confusing though.
What I don't really like:
* The editor experience. I feel like a rich text experience might have been a better fit for this kind of application. I like markdown as a portable format, but not to write in. But that's pretty personal I guess.
One thing that strikes me about most academic knowledge tools is that they seem to focus on parsing the current set of academic literature and producing supposedly interesting insights out of them (which quickly tends to snowball into wanting some kind of generalized model for knowledge as a whole). What I think is much more interesting is creating tools that help people create better academic writing in the first place (thinking tools if you will). This is however much more a UX problem rather than it being a pure engineering problem. That is why I think we see many more tools in the knowledge extraction space as most academics thinking about these kind of things probably have an engineering background. That combined with the the fact that we seemingly all want to throw machine learning at any problem we encounter.
I think in most of the mentioned note taking methods (zettelkasten, digital gardening) spaced repetition is kind of frowned upon in a way. It is seen as a necessity because of the way the educational system requires you to conjure up a certain set of knowledge at a particular time (a test). With zettelkasten and digital gardening (or any other method with similar goals) the process and habits that you acquire over time become more important. The goal is not to optimize for the (short-term) memorization of some knowledge only to shove it aside and move on to the next set of knowledge to memorize for the next test. Rather these methods are trying to design a process by which you can build on ideas iteratively. In order to really embrace these methods we'll have to see changes in the educational system as well or we'll end up with methodologies optimized for the educational system that is currently in place (which is what spaced repetition is in my view).
The key question when reading any article/book/whatever is the following: "if anything, what is actually important enough to remember from this article?", or in the case of PKBs: "What should be in my PKB and what should be discarded?"
By asking yourself this question explicitly and then actually writing down the key points you practice your own judgment on what is worth remembering and what is not.
Now the added benefit of a PKB is that you can actually keep these key points in a central location and reference them in other contexts or share them with others. You are basically doing prework for later (research) questions you might have. However I would say the biggest benefit is the process; explicitly writing down what is important and discarding what is not.
For more on this subject I recommend following @fortelabs on Twitter. He does a lot of interesting writing on the subject.
Decentralization is a scale. Complete decentralization is undesirable, you just want to give small groups the ability to be autonomous (however big they want to become).
Then you stand for nothing at all. You can stand for decentralization of financial systems at which point blockchain might become an enabling technology. But you are arbitrarily limiting yourself if you have such a strong focus on a given paradigm.
You actually can't select text on the nytimes website? Instead they add a functionality where double clicking changes the font size. Looks like a bored designer is at work here...