A place to cache linked articles (think custom and personal wayback machine)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

hace 2 años
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184
  1. title: Comfort of Bloated Web
  2. url: https://susam.net/maze/wall/comfort-of-bloated-web.html
  3. hash_url: fc0fd0dbeeb8a3f2b47e8ccab6d2cbc9
  4. <p>
  5. There is a tiny
  6. <a href="https://susam.net/form/comment/?post=hello">comment form</a>
  7. application on this website to accept comments from visitors and
  8. save them on the file system of the web server for me to review
  9. later and publish. This form is one of the only two things on this
  10. website that is dynamic in nature. The other dynamic part is
  11. the <a href="https://susam.net/form/subscribe/">subscription form</a>.
  12. Everything on this website other than these two things are static in
  13. nature.
  14. </p>
  15. <h2 id="mysterious-copies">Mysterious Copies<a href="#mysterious-copies"></a></h2>
  16. <p>
  17. Most of this website is made of handcrafted HTML. The blog posts and
  18. other content files are handcrafted HTML pages. A Common Lisp
  19. program adds common headers and footers to these pages and generates
  20. the HTML pages that are served as static files via Nginx running on
  21. a Debian system. The comment form, however, is a dynamic web
  22. application served via another Common Lisp program that makes use of
  23. the Hunchentoot web server to serve the form, accept the input
  24. submitted by the user, and then process it. This comment form is a
  25. very simple, minimal, and stateless application that fulfills the
  26. modest requirements of this modest website pretty well.
  27. </p>
  28. <p>
  29. However, often I see multiple copies of the same comment being saved
  30. on my web server. In the initial days of encountering this issue, I
  31. felt quite confused. I could rule out a bug in my program by
  32. carefully reviewing and testing it. Further, the web server logs
  33. clearly showed multiple POST requests being received by it from the
  34. same client usually with a few seconds of intervals between the
  35. consecutive requests. The comments seemed to have legitimate
  36. content. Since the duplicate copies would all have the same comment,
  37. I would arbitrarily pick one and publish it on my website. But I
  38. often wondered why on earth well meaning visitors would sometimes
  39. submit the same comment multiple times. For good measure? Perhaps!
  40. But still quite odd!
  41. </p>
  42. <h2 id="so-what-is-the-problem">So What's the Problem?<a href="#so-what-is-the-problem"></a></h2>
  43. <p>
  44. The mystery of duplicate comment submission remained a puzzle for
  45. several months. Then one day, one of the visitors to my website
  46. contacted me via Twitter messages to tell me that my comment form
  47. was broken and it was not working for him.
  48. </p>
  49. <p>
  50. The conversation began like this: "Hey! The comment form on your
  51. website seems to be broken. It says it has accepted my comment but I
  52. don't think it is doing that."
  53. </p>
  54. <p>
  55. I responded, "Hi! Thank you for contacting me about this issue. What
  56. do you mean it does not accept your comment? Do you see an error?"
  57. </p>
  58. <p>
  59. "There is no error. In fact, after submitting, I get a success
  60. message that says, 'Comment was submitted successfully. It may be
  61. published after review.'"
  62. </p>
  63. <p>
  64. "That sounds about right. So what's the problem?"
  65. </p>
  66. <p>
  67. In the meantime, I performed some testing at my end to find that the
  68. comment form appeared to be working fine with no apparent issues.
  69. Further, I found that there were multiple copies of his comment
  70. saved neatly on the server for me to review later and publish.
  71. </p>
  72. <p>
  73. Before I could share my findings, he continued, "Well! That success
  74. message appears almost instantly. It couldn't be storing my comment
  75. successfully that fast, could it?"
  76. </p>
  77. <p>
  78. That is when the mystery unfolded for me! The issue was that the
  79. comment form accepts the user's comment and returns a success
  80. message too soon for the user to believe that it could have possibly
  81. saved the comment. I have had a couple of other very similar
  82. conversations since then when a visitor contacted me via email or
  83. another means to double-check if my comment form was really working
  84. fine. In all of these cases, they were skeptical about the success
  85. message because it appeared much sooner than they expected.
  86. </p>
  87. <h2 id="bloated-expectations">Bloated Expectations<a href="#bloated-expectations"></a></h2>
  88. <p>
  89. Depending on where the visitor is located, the comment form on this
  90. website may take anywhere between 30 ms to 900 ms, and very rarely a
  91. little longer, to accept the user's comment, save it successfully,
  92. and then display a success message to the user. But apparently, a
  93. few hundred millseconds is too fast for many people to be able to
  94. trust that the comment application is actually doing its job. I
  95. presume that they have become so used to waiting for at least a
  96. second or more for dynamic pages to load that a web application that
  97. finishes its job in a few milliseconds appears to be fishy.
  98. </p>
  99. <p>
  100. I must clarify here that the duplicate comment submissions do not
  101. bother me at all. The duplicate comments I receive is a very small
  102. fraction of the total number of comments. I just find it interesting
  103. that users can mistrust a simple piece of software that does a
  104. simple thing in a reasonable amount of time. I had one visitor to my
  105. website even say, "I really was expecting a spinning wheel on the
  106. browser tab or some sort of progress indicator to be assured that it
  107. is saving my comment. The instant success message took me by
  108. surprise!" He felt nervous that his comment was not saved and
  109. resubmitted the comment again.
  110. </p>
  111. <p>
  112. As a result of these conversations, I have sometimes even wondered
  113. whether I should add some artificial delay in the comment
  114. application before responding with a success message to satisfy the
  115. expectations of people who are so used to the bloated web. Of
  116. course, I am not actually going to do that. I want to keep it
  117. simple. I do not like adding artificial restrictions to a simple
  118. piece of functionality. Further, I do not mind the duplicate comment
  119. submissions at all. However, I cannot help but remark that the users
  120. of the web today have become so comfortable with the bloated web
  121. that a simple web application without bells and whistles that is
  122. fast and responsive makes them nervous!
  123. </p>
  124. <h2 id="update">Update<a href="#update"></a></h2>
  125. <p>
  126. <strong>Update on 13 Mar 2022:</strong> Many commenters to this post
  127. have suggested that the issue here might not be the fast response of
  128. a successful comment application but instead the fact that the
  129. comment form elements remain intact even after the comment
  130. submission. In their opinion, merely displaying a success message
  131. may not be assuring enough. They further suggested that I should
  132. change the state of the form in some way on successful submission.
  133. Popular recommendations included disabling, clearing, or removing
  134. the form elements entirely on successful submission.
  135. </p>
  136. <p>
  137. These suggestions are valid of course. However, I also think that
  138. these suggestions reinforce the point of my blog post. Users of the
  139. web today are so used to these fancy features and restrictions that
  140. without them one feels unsure if the comment form application has
  141. really done what it is <em>literally</em> saying it has done.
  142. </p>
  143. <p>
  144. Do I really need to consider <em>artificially</em> clearing,
  145. disabling, or removing the form elements and thus removing the
  146. ability to edit a comment again and resubmit it (even if the user
  147. really so desires) with a single click of a button? What if someone
  148. wants to post another comment immediately after the first one? What
  149. if someone wants to edit their previous comment slightly and repost
  150. it? Do I need to force the user to hop through separate links and
  151. buttons to be able to do these simple things? "But every other
  152. website clears, disables, or removes the form elements," you might
  153. rightfully offer as a counterpoint. I know. I know. But why is it so
  154. that the "right" user experience nowadays involves artifically
  155. encumbering the user or hiding the user's own submitted text from
  156. themselves?
  157. </p>
  158. <p>
  159. In fact, in an earlier version of this website, the comment form
  160. application did disable the form elements on a successful comment
  161. submission. In an even older version of this website, a new page
  162. consisting only a success message appeared. However, visitors would
  163. still report their suspicion regarding the comment form doing its
  164. job to me. So I have observed the results of employing at least two
  165. of the measures suggested and they were still consistent with the
  166. reporters' claims that they find the instant success message from
  167. the application to be disconcerting.
  168. </p>
  169. <p>
  170. UX best practices notwithstanding, I do not want to hide the users'
  171. content from themselves after a successful form submission. Maybe
  172. they want to copy the message and keep it for themselves. Maybe they
  173. want to edit it again and repost it. I do not want to restrict any
  174. of these simple things. I also do not want the user to hop through
  175. another additional link or button to be able to do these things.
  176. Therefore, heeding some of the other advice I have received, I have
  177. now made two tiny changes to the comment form application that is
  178. consistent with its original spirit of simplicity, minimalism, and
  179. statelessness. I have moved the success message to the top of the
  180. response page. I have also added additional text in the success
  181. message that explains the submitted input has been left intact in
  182. case the submitter wants to copy it, or edit it and resubmit it.
  183. </p>