Finally, voting without refresh • Hacker News Board

Re: Finally, voting without refresh

#41

Post by [deleted] » Fri, Jun 15, 2007, 2:42 PM UTC

pg wrote: post #36

nirs wrote: post #34

There a stupid bug - after you vote, the arrow is hidden, but it will accept clicks :-) So you can continue to upvote many times, and the score text updates. When you refresh, the actual vote is restored. Tested with Safari 419.3.

I don't think I count this as a bug. If you do something stupid, you see something stupid, but it doesn't affect anyone else.

[deleted]

Re: Finally, voting without refresh

#42

Post by [deleted] » Fri, Jun 15, 2007, 2:42 PM UTC

pg wrote: post #36

nirs wrote: post #34

There a stupid bug - after you vote, the arrow is hidden, but it will accept clicks :-) So you can continue to upvote many times, and the score text updates. When you refresh, the actual vote is restored. Tested with Safari 419.3.

I don't think I count this as a bug. If you do something stupid, you see something stupid, but it doesn't affect anyone else.

[deleted]

Re: Finally, voting without refresh

#43

Post by aston » Fri, Jun 15, 2007, 2:42 PM UTC

pg wrote: post #36

nirs wrote: post #34

There a stupid bug - after you vote, the arrow is hidden, but it will accept clicks :-) So you can continue to upvote many times, and the score text updates. When you refresh, the actual vote is restored. Tested with Safari 419.3.

I don't think I count this as a bug. If you do something stupid, you see something stupid, but it doesn't affect anyone else.

It's not a harmful bug, but it's certainly not behavior users will appreciate. I could imagine a new user not understanding the one man, one vote property of the system, then being confused later when the votes seem not to have gone through.

Adding the visual effect of idempotency on the frontend is probably a two-second fix, anyway.

Re: Finally, voting without refresh

#44

Post by aston » Fri, Jun 15, 2007, 7:10 PM UTC

paul wrote: post #26

philh wrote: post #25

Earlier quoted context omitted.

You could always update the UI on the assumption that it will succeed, and then check the return value. If you get failure, notify the user somehow. Making the UI seem a slight bit more responsive might not be really worth it, of course.

UI latency is actually very important, and generally under-appreciated. Sometimes, it's better to be fast than perfect.

I think the standard solution here would be not to lie to the user. A quick sending graphic, which is replaced with a received graphic would accurately portray the events that are happening. These could easily be iconic, maybe just a differently colored arrow while sending, which fades out when it's sent.

Re: Finally, voting without refresh

#45

Post by ralph » Sat, Jun 16, 2007, 9:12 AM UTC

pg wrote: post #2

Don't worry, I'm not going to post a link about each releaselet. I just wanted to thank PB for helping us.

Yeah, thanks PB. It's a big improvement and cuts down bandwidth use a lot too.

I've peered at the Javascript and most of its obvious even without knowing Javascript :-) Might someone answer a few questions?

node.href just returns an empty text/html document when fetched. Does this happen synchronously or not? What do browsers do when they're given text/html as the content of an image and what do the specs define they do? When is ping freed? Is it automatic when it goes out of scope and does that suggest that the image fetch is synchronous?

I'm trying to understand what delays occur when and whether on a larger scale you'd need to manually free some of these resources.