Hacker Newsnew | past | comments | ask | show | jobs | submit | mklepaczewski's commentslogin

Is it really faster though? I’ve built PoC of something similar and a test game to check how much faster it was to use keyboard. To my surprise mouse was consistently faster ( by a lot).

Yeah, I'm really not sold either on the speed aspect.

I'm using warpd which is a similar tool, and for me it's really not about speed, but more about the comfort of keeping my hands on the keyboard. Still using the mouse a lot but warpd is often handy.


https://www.asktog.com/TOI/toi06KeyboardVMouse1.html:

“We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:

- Test subjects consistently report that keyboarding is faster than mousing.

- The stopwatch consistently proves mousing is faster than keyboarding.

This contradiction between user-experience and reality apparently forms the basis for many user/developers’ belief that the keyboard is faster.

People new to the mouse find the process of acquiring it every time they want to do anything other than type to be incredibly time-wasting. And therein lies the very advantage of the mouse: it is boring to find it because the two-second search does not require high-level cognitive engagement.

It takes two seconds to decide upon which special-function key to press. Deciding among abstract symbols is a high-level cognitive function. Not only is this decision not boring, the user actually experiences amnesia! Real amnesia! The time-slice spent making the decision simply ceases to exist.

While the keyboard users in this case feels as though they have gained two seconds over the mouse users, the opposite is really the case. Because while the keyboard users have been engaged in a process so fascinating that they have experienced amnesia, the mouse users have been so disengaged that they have been able to continue thinking about the task they are trying to accomplish. They have not had to set their task aside to think about or remember abstract symbols.

Hence, users achieve a significant productivity increase with the mouse in spite of their subjective experience.

Not that any of the above True Facts will stop the religious wars. And, in fact, I find myself on the opposite side in at least one instance, namely editing. By using Command X, C, and V, the user can select with one hand and act with the other. Two-handed input. Two-handed input can result in solid productivity gains (Buxton 1986).

Command-Key Illusion. Since users do experience the illusion that keyboarding is faster, there is market pressure to supply them with "shortcuts."—even when using "shortcuts" will actually slow them down. What I generally recommend is supplying as many "shortcuts" as demanded by the market—the real market, not the programmer in the cubicle next to you. But only if these "shortcuts" are not to the detriment of the user of the Macintosh visual interface. This leads to two important guidelines:

Guideline: The keyboard interface must not dictate the design of the visual interface.

Guideline: The work to design and build the keyboard interface should not sap resources that are needed for the creation of the visual interface.

In other words, don’t rape the primary interface for the benefit of so-called "power-users," who may well end up achieving lower productivity by using the keyboard interface anyway. This is a major problem right now.”

I don’t think it’s as clear-cut as Tog says (for example, I agree with Tog about cut/copy/paste and, historically, command-S for Save (which, with Mac software from the 1980s, you hit very frequently, if you wedding want to lose stuff due to crashes). I also wonder whether do people with decades of vim editor usage really have to attend to basic cursor movement?), but it’s not completely untrue, either.


You seem to assume that a day always has 24 hours. Common (but not only) non-24h day lengths are: - 23 hours - 25 hours - 24 hours 1 second - 23 hours 59 minutes 59 seconds

You could assume that a day isn't exactly 24 hours, but it's close-ish to 24 hours. Nope, not even close.

And that assumes that we can treat an hour as a precise measure of time (we can't). On some systems, even a second is not a precise measure of time (second smearing).

To make things worse, those are "simple" edge cases.

Time is hard. I'm not sure if I can make any statement about time that is true.


I am saying that you shouldn't use day as a unit of time. You should use second, minute, hour, etc, because these have a constant duration. sleep(86400) should reliably make your thread sleep for at least 24 hours.


It depends on the context and the system you’re working with. In some systems, an hour may last 3599, 3600 or 3601 seconds (due to the leap second), a minute may be 59,60 or 61 seconds. Even a second is not always a „true” second.

There’s no single time unit that works for all situations.


You don’t need the other person to be in the same room - a video call works just fine. In fact, it can be even better for productivity since there's less chit-chat.


It is my anecdotal experience that a whole bunch of my current friends are from a pre-pandemic in-office job and I’ve made zero lasting friendships at my remote jobs.


I work every day with people addicted to YouTube. A WorkMode client shared this approach; we tested it with a small group. Anecdotal but consistent - it works surprisingly well, cuts usage sharply, and seems to hold up long-term.


User would have to enable caching in CF and the response from the server would have to be cacheable for CF for caching to kick in.


62.5ms for a non-cached request? In my experience that’s really fast response time for a blog even on a dedicated bare-metal server.


That is reasonably fast. We wrote entire games in PHP where we aimed for wall time under 100ms. That is a challenge, but often doable. Some routes managed to respond in under 50ms.


Go on—I'll bite! What did you write?

I spent a colossal amount of my childhood and teens playing browser-based games and have zero regrets!


You probably haven't heard of them. We were a German studio, and most of our games only reached a few tens of thousands of players. The biggest hit was Xhodon — it had a bit of a following among World of Warcraft fans. It was a fun time.


Really? Why?

Blog posts don’t change much. Even if your rendering code is horrendously slow (though, why?), you can just cache the resulting html and serve it up with each request. Or slap nginx in front of your web server locally and let that deal with the load. ‘Course you’ll need your http headers set correctly, but you needed that anyway for cloudflare.

Your server has to be pretty badly configured for a personal blog to run out of CPU handling requests.


Everything you wrote is true, but this is not how it works in practice. Usually, the person running the blog uses WordPress, and doesn't know about caching. They add a few plugins that significantly increase response time and make the response dynamic (for example, CSRF nonces). Add to that some "static" AJAX requests (which usually are POSTs and not cacheable), and it all adds up.

I wouldn't bet on an average dev being able to set up and configure nginx + Cloudflare correctly.

>Course you’ll need your http headers set correctly, but you needed that anyway for cloudflare

Not if you don't use CF to cache "dynamic" content.


mklepaczewski was probably talking about end-to-end. I.e. the number you see in the network tab for request duration - whereas the pricing will only care about the time that the application is actually doing something.

That basically means it starts after the connection was established by the proxy (cloudflare) and terminates before the response is delivered to the client.

Doing the whole round trip within 65ms is actually pretty challenging, even if you are requesting over the wire. It would mean you have maybe 10-20 Ms to query data from the database and process them to html or json. Any kind of delay while querying the database is going to ruin that.

If you had a 65ms in the application, you would probably get a round trip average of something above 90, likely closer to 150 then 90.


For a blog? Why is a blog fetching data from a database on every request?

If you cache the response yourself (or use nginx), the server should be responding to queries in <1ms.


Sure, but this particular case clearly wasn't using cache, that's why the free tier limit for an application was reached. Hence it's highly likely that each request hit a database.

The message would've been different if it was cached.

https://workers.cloudflare.com/


Cloudflare Workers run in front of cache -- which is generally useful since it allows you to serve personalized pages while still pulling the content from cache, and since Workers can easily run in <1ms and run on a machine you were already going to pass through anyway (the CDN), it doesn't hurt performance. But it also means that the free tier limit of 100,000 requests per day includes requests that hit cache.

(I'm the tech lead for Workers.)


> Your comment could use a better tone, but I do agree that, especially with the difficulties that people are having finding a job these days, there has been elevated interest in ADHD and thus there are more attempts to prey on people with genuine issues

When you say “prey,” what kinds of products or services do you have in mind? I’ve seen some pretty dubious offerings, but I believe most creators genuinely want to help fellow ADHDers. Whether those solutions continue to work after the initial novelty wears off is another question.


I gave the example - IMO body-doubling is an arrificially created hype to take advantage of people with real problems. It's just perfect -- a subscription service, no permanent effect, added sprinkling of human contact to take advantage of people feeling lonely as well. No medical oversight or any oversight whatsoever...


Maybe some of the companies marketing it, of course there are people looking to exploit it just like in nearly every other industry. But the concept itself isn’t some ADHD specific thing, it’s just using technology to exploit a quirk in human psychology, and there are free options available. I’m in a discord server that has hundreds of people spread across various video call rooms at any moment. I haven’t used it enough to say how effective it is, but I definitely wouldn’t call that exploitative. If it works it works, if it doesn’t don’t use it.


I haven’t checked the app, I just saw screenshots. In my opinion the leaderboard is a bad idea, especially global one. It will be unachievable by vast majority of your users, and may lead to toxic behaviours such as working for 12h/day. It will also remind others how bad their productivity is, possibly causing more stress and self-blaming.

Think about something else than gamification. In my experience and the experience of our users (https://workmode.net/) gamification very quickly stops to work.

I wish you all the best as I know how devastating procrastination may be. Stay productive:-)


No need to be snarky. If it helps someone be more productive then it’s a win, even if they spend 50% scrolling and 50% working.

I haven’t checked the app, but the description says it uses social accountability, focus music and gamification. I’m sure it’s the right combination for some people, even if only for a while (in my experience gamification works only short term).


I'm not being snarky, I just don't understand how it helps solve the problem?

If the problem is that you scroll on your phone, how does an app with a feature where you scroll on your phone solve the problem?


I assume that scrolling through productivity feed of friends is less engaging than scrolling through social media content designed and tailored to you to spend as much time on it as possible.

The app has other features to help with focus and to jumpstart productivity.


Delaying action is sometimes useful. Procrastination is never useful. The deliberate decision to postpone something because it's beneficial is very different from postponing something because we prefer to read HN.


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

Search: