It was the Bitcointalk forum that inspired us to create Bitcointalksearch.org - Bitcointalk is an excellent site that should be the default page for anybody dealing in cryptocurrency,
since it is a virtual gold-mine of data. However, our experience and user feedback led us create our site;
Bitcointalk's search is slow, and difficult to get the results you need, because you need to log in first to find anything useful - furthermore, there are rate limiters for their search functionality.
The aim of our project is to create a faster website that yields more results and faster without having to create an account and eliminate the need to log in -
your personal data, therefore, will never be in jeopardy since we are not asking for any of your data and you don't need to provide them to use our site with all of its capabilities.
We created this website with the sole purpose of users being able to search quickly and efficiently in the field of cryptocurrency
so they will have access to the latest and most accurate information and thereby assisting the crypto-community at large.
Suchmoon has a point: everything is turned into a captcha nowadays, and someone might think he has to solve the equation to continue.
Seriously? If someone misinterprets the merit page in such a way, (s)he should probably fail hard on that page for the better of the merit system. Just my opinion: we don't need to make it such easy for the dumbest imaginable so that no user needs to flex even a single cell of his brain muscle. How deep can humanity sink?
If you find traces of S, Ar, Ca, Sm you can keep the primary elements of humor...srcs
I like approach B with the default value=1 instead of 0. (...)
Yep. That's something shahzadafzal suggested, too (approach B with "1" instead of "0" as the default). I do like that approach, but it relies exclusively on JavaScript, and leaves the no-JS folks with basically the same problem as before (only now, instead of 0-based mistakes being easy to make, 1-based mistakes would be easy to make: accidentally sending 20 merits when you meant to send 2 would just become accidentally sending 21 merits). Catering to people that have JavaScript disabled is getting a bit silly these days, but it's still the way I lean when it's easy to do so. I also think that having a sendable default value will likely skew the statistics (that is, people will probably send exactly the default amount more often than they would have if they had to type something into an empty field).
I don't like "1-50" as a placeholder. If you know nothing about merits, that doesn't really help you. 1 minus 50 so... -49 ??
Hmm. You and Loyce can duke it out. "0" as a placeholder is the least distruptive change, I suppose (it's what people have gotten used to seeing in that field, anyway).
I don't like "1-50" as a placeholder. If you know nothing about merits, that doesn't really help you. 1 minus 50 so... -49 ??
I'm not a fan of placeholders in general, they tend to be styled barely visible and disappear when you need them.
I'd say leave it empty. Add an explanation above/below if needed. That page has enough space, even on a phone screen. Ensure the field is focused automatically so that the user can just type in the number and hit enter ("autofocus" attribute IIRC).
I like approach B with the default value=1 instead of 0. I think it won't confuse newbies because they'll definitely realize it's a numeric field and 1 is the average value most users send. This saves the user a few seconds without touching the keyboard at all. This is a fair convenience imo.
"1-50" placeholder I think is unnecessary because theymos has by default applied sendable limits. After all, it would be a very rare case where a newbie had more than 50 smerits. And I'd exclude merit sources from needing approach C or D because they certainly know its limitations without placeholder text.
This approach would replace the pre-populated "0" with the placeholder text "1-50" (which acts as a hint, and is only visible while the field is empty). This approach also adds a bit of JavaScript that "selects" the value whenever the field is clicked, so that whatever you type in will replace whatever was already there (meaning that, in addition to 0-based mistakes like 10, 20, 30, 40 and 50 being mitigated, 1-based mistakes, 2-based mistakes, etc. are also mitigated).
In this sense, I choose approach D.
This idea, that when you click, the numbers are automatically selected, would also be a good solution.
Having had some time to think about this one, it's occurred to me that approaches B and C can actually be (harmoniously) combined (that is, approach C + the onclick="this.select();" JavaScript from approach B will lead to an approach that works just like approach C does when JavaScript isn't available, but that will still be able to catch a wider range of mistakes when JavaScript is enabled).
I like Loyce's refinement of Trawda's idea: "1-50" makes more sense as placeholder text than "0" does.
So, combining the above thoughts, and following the format in the OP, we have:
Approach D
This approach would replace the pre-populated "0" with the placeholder text "1-50" (which acts as a hint, and is only visible while the field is empty). This approach also adds a bit of JavaScript that "selects" the value whenever the field is clicked, so that whatever you type in will replace whatever was already there (meaning that, in addition to 0-based mistakes like 10, 20, 30, 40 and 50 being mitigated, 1-based mistakes, 2-based mistakes, etc. are also mitigated).
That would look like this:
And this (after entering a value, and then clicking on the field):
The HTML would change to: (that is, value="0" would change to placeholder="1-50", and onclick="this.select();" would be added).
(I did read and appreciate all of the posts/suggestions in this thread, and while a lot of them make sense, some of them are likely to create new problems; they're worth revisiting at another point, I think. Getting bogged down in an overhaul that tries to fix too many problems at once will likely result in something that doesn't get merged. For now, I think a strict improvement that isn't too complicated has the best shot at getting accepted, IMHO.)
P.S. I also like Cricktor's suggestion to have the field automatically take input focus, so that all you have to do is type the number of merits and then hit "Send". But, there are some accessibility notes on MDN about how that might interact poorly with screen readers, and I'm not sure how people on mobile devices would feel about the on-screen-keyboard automatically appearing on that page (maybe they'd prefer it?). Anyway, if theymos thinks it's a good idea, then the HTML would change to: (that is, same as approach D above, but with autofocus added).
l How will the button actually work? Suppose I want to send 5 merits. Do I have to press (+) five times then? Won't that take much of my time? As LoyceV said, "He wouldn't want to waste a single second".
In my opinion, by default, it should be 1. And even if a user sent smerits rushed, only 1 merit would be sent. After that, he or she can make changes to how much they want to send anyone. Previously, I suggested there should be a confirmation message. But now I see it will only create more problems.
Indeed I am not in the favor of button and I think the default manual putting number is better then all. If you want to send 5 merit, just input 5 which is much easier than tapping + button five times. I don't think LoyceV will think, This default Merit system will waste his time as he is old member and If he thought that, he would have expressed it already.
I am active here for almost year and visited so many threads and observed that sharing 100 or 50 merit is very rare. A high number of merits given to the some old threads. Some Useful Thread Iike Talkimg and threads in technical Bitcoin discussion also got so many merit. Normally Merit source send 10-30 merit for good post/transaltion while people like me has limit of 5 maximum per post.
How will the button actually work? Suppose I want to send 5 merits. Do I have to press (+) five times then? Won't that take much of my time? As LoyceV said, "He wouldn't want to waste a single second".
In my opinion, by default, it should be 1. And even if a user sent smerits rushed, only 1 merit would be sent. After that, he or she can make changes to how much they want to send anyone. Previously, I suggested there should be a confirmation message. But now I see it will only create more problems.
The problem of sending more merits happens to those who generally send merit in two figure. I didn't face any problem so far when sending Merit but some members facing issue so I think Approach C is best suitable to solve the problem and if initial value remain 1 instead of zero , it will be more helpful
It's appropriate for low ranks users who only shares a small amount of merits. But those with high rank or those who are merit source might think this as inappropriate as they distribute hundreds or thousands (I don't know the numbers) of merits each day. So sending out merits, selecting how much to send can be seen as a headache to them. Even a loss of one second is unacceptable for some members. Again I'm not any merit source or high ranked user, so I don't know if I'm right or wrong. Only they can give the correct insight of the situation.
I am active here for almost year and visited so many threads and observed that sharing 100 or 50 merit is very rare. A high number of merits given to the some old threads. Some Useful Thread Iike Talkimg and threads in technical Bitcoin discussion also got so many merit. Normally Merit source send 10-30 merit for good post/transaltion while people like me has limit of 5 maximum per post.
I have sent 10 and 20 credits maybe three times. I would love to see this fix.
I've thought of it in my imagination but never knew the mistake was real. I pray to have this kind of luck one day...lol.
It's good that the OP is pointing this out and is very thoughtful of him at the same time for the betterment of the forum and to guide against it in the future. I hope his proposal will be granted.
No one is above mistakes but I don't think I can make this one since I'm always careful and attentive when sending merits. The mistake I can only make is to send my merit twice due to the way the page goes back to how it was at times after sending the first merit.
I think the initial value could just be settled to "value=1" the place holder will always dissappear after an input so if there's no input we can just set it to a text to display the user needs an input
Why is the "type=text"? it could be number with a max value and minimum value "type=number max=.... min=....." Since it will be authenticated before storage in BE a more secure way is used already.
Text area keyboard mode and increase and decrease mode
With this input is set to null initially and the arrow will help to add and decrease to the max and min value with, users can also make use of keyboard to type numbers from min value to max value if users don't want the increase and decrease button. Then,we could have a modal prompt before submittion for confirmation.
I think Approach A will be better, because it will leave the field completely empty to avoid any error. You can manually insert a particular number of your choice. Or the approach of @mk4 which you will add or reduce the number of merits.
It's appropriate for low ranks users who only shares a small amount of merits. But those with high rank or those who are merit source might think this as inappropriate as they distribute hundreds or thousands (I don't know the numbers) of merits each day. So sending out merits, selecting how much to send can be seen as a headache to them. Even a loss of one second is unacceptable for some members. Again I'm not any merit source or high ranked user, so I don't know if I'm right or wrong. Only they can give the correct insight of the situation.
I think Approach A will be better, because it will leave the field completely empty to avoid any error. You can manually insert a particular number of your choice. Or the approach of @mk4 which you will add or reduce the number of merits.
While I like when systems look and act smart, this would be really going overboard and the added complexity isn't worth it in my opinion (I'm quite sure you're not serious with your suggestion).
If I had to vote for an option, I'm fine with option C and I'd prefer to have the cursor already in the entry box so that I'd only have to type the number of merit points to send.
Yep . I am laying in my bed watching my Giants lose to the Raiders as I type this.
I Gave you a merit because I likely spend an hour a day typing on the iPad mini while lying in bed. It is the most likely time To make the 10 or 20 error. So C is certainly best for me.
While I like when systems look and act smart, this would be really going overboard and the added complexity isn't worth it in my opinion (I'm quite sure you're not serious with your suggestion).
If I had to vote for an option, I'm fine with option C and I'd prefer to have the cursor already in the entry box so that I'd only have to type the number of merit points to send.
After sending out 10 merits for example at a time and coming back to merit that user on a later date, you have a maximum of 40 to send, but the place holder will still display 1-50.
Good point. Let's go overboard and change the amount depending on how many sMerits the user sent to that post already, how many were sent in the past 30 days, and how many sMerit he has left. So it can be anywhere from 1-50 to 0-0.
Among the choices, I'd prefer Approach C, place holder is ideal because this can serve as an indicator that the text field is for numbers only, I do not think so if its a good idea if there a button will prompt only for the large merit send as another layer verification if the user really want to commit sending large merit. Good to know that the merit view is fixed already once you reload again it makes another merit sent.
One disadvantage of approach A is that it leaves the user wondering what they're meant to type in (that's obviously not an issue for people that have sent merit before, but I could see brand new users getting confused without any cues to help them).
I think approach A is the best option for this UI tweak, but approach C is also not bad. They are both simple, and maybe we can add few more lines of text explaining better how to merit a post, that should mostly be used for newly created accounts.
I also recommend adding an up/down or plus/minus button so people on mobile wouldn't need to manually type in the numbers. Not much of a big deal, but it's a fairly easy update that could make things a lot less of a hassle.
This could work, but than we again need to have default value, and minimum/maximum, or someone could go pressing minus and send someone 999 merits (for example).
I also prefer Approach C. Just a placeholder text, similar to how it is now, but more error-proof.
Option C is the most preferred option to me. By using option C, there isn't any number pre-inserted for you , so the possibilities of errors will reduce. But, I'll suggest that the placeholder text shouldn't be "0" . A placeholder is always an indicator of what is actually expected to be entered. So, there is no how "0" can be given as merits, that's why it doesn't fit as a placeholder. We can chose a number from 1 to 9 to be the placeholder.
I have seen people make such mistakes of sending merits way above what they are supposed to send. This could solve the problem to a certain degree when implemented.
I thought EpochTalk was meant to be a completely original platform, not just a fork of some existing open-source solution. So, these features should have been part of its core design from the start, right?
You are correct; EpochTalk is indeed a new and "next-generation forum software," not a fork of any existing solution. It's designed to provide a more modern and scalable platform for forum-style discussions. However, it's important to note that it builds upon the functionalities of the original BitcoinTalk forum. So while it is new, it still serves as an evolution from BitcoinTalk, incorporating all the functionalities of BitcoinTalk and adding new features.
I'm not entirely sure, but I've had a look at the source code of EpochTalk, and it appears to be designed for general forum use, not just for BitcoinTalk. I did notice that it has a "trust system," but I couldn't find anything related to a merit system. It's possible that the merit system has been renamed or is available as an optional add-on, rather than being included as a default feature in EpochTalk
I mean possibilities are endless after all it's a "Next generation forum software"!!!
I didn't thought it like that. I have only sent +- 60 merit my whole life. Yes, for a big merit sender like you, it would only create more problems. We better stick to approach A,B,C then.
It’s not necessary I have also had same idea before but it will be like another task for big merit spenders like merit sources because every merit done will require that confirmation message and it will slow the process down. Also the problem with this merit sending issue is mainly due to mistakes like the sender not paying much attention to what he is doing and even with the confirmation message they will still just click yes without actually cross checking it.
I believe it would be necessary to create and pin a thread in the beginners and help section about sending merits to assist newbies in using the merit function
It’s not necessary because they already have some threads that are pined and they contain merit discussion already. Example is the newbies read before posting thread on the beginner and Help bord. Funny enough newbies don’t read them and they end up asking questions about it
So my own other suggestion, PowerGlove is to make add a patch that after sending the merit we should be taken back to the post again just like how it works when posting is done.
hahaha I can understand and to be fair these are things preventing theymos from upgrading the forum or switching to Epochtalk smoothly. I think current SMF version has been changed a lot that scares even theymos to touch it. For rexample trust system would be another story.
I thought EpochTalk was meant to be a completely original platform, not just a fork of some existing open-source solution. So, these features should have been part of its core design from the start, right?
I believe it would be necessary to create and pin a thread in the beginners and help section about sending merits to assist newbies in using the merit function
All of the options will be an upgrade to the current system which makes it very easy to slip up and send more merits than you planned to. Although from the rate of merit sent, this is not a issue frequently encountered. I for one have never mistakenly sent out the wrong number of merits, but I guess merit sources will be most affected cause they send merits very frequently and multiple times within a short period.
If I get a vote, I vote for this one. But the place holder shouldn't be "0", Trawda's post made me realize "1-50" is better.
Downside to this is that it gives off the interpretation that one can only send between 1-50 neritsvinna single transaction and not the reality that that's the maximum for a month to a user.
After sending out 10 merits for example at a time and coming back to merit that user on a later date, you have a maximum of 40 to send, but the place holder will still display 1-50.
If you could add a final confirmation message before sending sMerits, that would nice.
Example: Are you sure you wanna send 50 sMerit to user X? YesNo
Please don't! People will get used to it, and click it without thinking. All in all it would just double the number of clicks required to send sMerit. As the sender of 13734+ sMerit transactions, I don't want to add even a second to each one. That would have been 4 hours already!
I didn't thought it like that. I have only sent +- 60 merit my whole life. Yes, for a big merit sender like you, it would only create more problems. We better stick to approach A,B,C then.
If you could add a final confirmation message before sending sMerits, that would nice.
Example: Are you sure you wanna send 50 sMerit to user X? YesNo
Please don't! People will get used to it, and click it without thinking. All in all it would just double the number of clicks required to send sMerit. As the sender of 13734+ sMerit transactions, I don't want to add even a second to each one. That would have been 4 hours already!
There's a small UI issue with the merit-sending page that makes it easier than it should be to accidentally send more merit than you intended (I'm sure I've run into a handful of anecdotes about this, but I can't find them now). ~ Approach B
This approach would add a bit of JavaScript that "selects" the value whenever it's clicked, that way, whatever you type in will replace whatever was already there.
That would look like this (after clicking):
The HTML would change to: (that is, onclick="this.select();" would be added).
Have we discussed this before or its a Mandela Effect?
I mean I feel that we have discussed all these approaches change default 0 to 1, leaving it blank or changing it to plus minus button.
Anyway from your proposed option I will prefer Approach B with small tweet changing default 0 to 1, something like
Our most (more than 50%) of merit transactions are 1. For example from most recent 499 merit transactions 314 are 1 merit transactions that's 62%.
So changing default from "0" to "1" will at least favor 62% merit transactions.
I would have included PHP diffs with this post, but I don't have access to the relevant code, so all I can do this time around is make suggestions like a noob.
hahaha I can understand and to be fair these are things preventing theymos from upgrading the forum or switching to Epochtalk smoothly. I think current SMF version has been changed a lot that scares even theymos to touch it. For rexample trust system would be another story.
(I'm taking a break from the forum, but I'll be back on the 27th; try not to miss me too much.)
Last time I predicted for someone going Antarctica, so please tell me are you getting married or going for long honeymoon, of course you don't need to answer
One disadvantage of approach A is that it leaves the user wondering what they're meant to type in (that's obviously not an issue for people that have sent merit before, but I could see brand new users getting confused without any cues to help them).
They all seem like good options to me but I prefer Approach A, with some improvement as mentioned above to give new users hints on the correct numbers to type in the input box.
The best way is to delete the "0", which is often forgotten and causes the wrong merit to be sent, as happened to many members on the forum. At the same time, the hint helps new members.
I believe Approach B would be the best if there be need to change the code. The zero in the approach B format should give a clue also to newbies who haven't sent merit before how ever due to this fact by PowerGlove
Quote
One disadvantage of approach A is that it leaves the user wondering what they're meant to type in (that's obviously not an issue for people that have sent merit before, but I could see brand new users getting confused without any cues to help them).
I believe it would be necessary to create and pin a thread in the beginners and help section about sending merits to assist newbies in using the merit function
I think going with "Approach C" is the most sensible option. Using a placeholder value is a common practice in user interfaces, and it shouldn't create any confusion, even for new members.
I was trying to lower my source sMerit balance, and used LoyceMobile's sent Merit history to send those posts some more. With a dozen tabs open, I filled "04" in all of them before clicking "Send" (I have this AI-thing where I try to Merit as much posts in a single second as possible, I've reached 4 posts per second several times). However, I wrapped around to the first tab again, and added another 4 to the existing "04", right before I clicked Send. Long story short: I could see my 44 sMerit transfer to this post, but it was too late to stop it.
I wanted to leave the chain of events here, in case someone questions this transaction later. It's the biggest Fork Up I've had with sMerit To easy my own mind: the post itself isn't bad, although it doesn't deserve 45 Merits. It's a Newbie who doesn't look like a spammer. So I hope the sMerits trickle down from there to others. I've Forked Up less than 0.5% of all sMerit I've sent. This was a big Fork Up though
Since I have to empty my source sMerit, I usually send 4 sMerit at a time. I wanted to Merit this post and accidentally clicked left instead of right from the "zero" on the "Merit a post"-page. As some claim I'm AI, I clicked "Send" at the same moment I realized my mistake, and my heart skipped a beat. That default zero has always been risky, but it's the first time it hit me this hard. Maybe I should send 6 sMerit at a time from now on, so this mistake can't happen anymore.
I also recommend adding an up/down or plus/minus button so people on mobile wouldn't need to manually type in the numbers.
Good idea but still can implement both of this suggestion and the ability to input manually too. Some people still like to shortcut merit points especially if they giving up so much points to a post.
For me I prefer manually input though. But nice recommendation very convenient too.
Since I'm a lazy person, I support @mk4's suggestion by having "1" number by default because I don't have to input the number to merit someone. Whenever someone want to give more merit, they can click the plus/minus button or input it by themselves.
Although this could raise a same problem someone would mistakenly send "11-19" merits.
I also recommend adding an up/down or plus/minus button so people on mobile wouldn't need to manually type in the numbers. Not much of a big deal, but it's a fairly easy update that could make things a lot less of a hassle.
We are restricted to send only 50merits to one user in a month,
I like the idea of powerglove's Approach C from that any newbie can get the clue, that what the box is for, there no need to write like these 0-50 because these much merits are sent by veterans, even newbie or low rank member don't have that much merits to sent so they will learn about the limits about merits gradually learning more about forum.
This approach would leave the field initially empty so that there's no 0 there to trip anyone up.
That would look like this:
The HTML would change to: (that is, value="0" would be removed).
From this I think is more better, this option is pretty cool with me in a sense that the entire body is empty meaning anyone can input any amount of merits s/he needs to send to reduce some common errors. Hope theymos implement this option..
I prefer the approach A, adding the number one instead of leaving the field empty, in addition to a group of buttons next to send that contain 2, 4, 5, 7, 10. if you click on send, you will send one Merit, if you click on the buttons next to it, you will send 2, 4, 5,7,10, and if you want to send more, you must change the number from 1.
In my opinion, approach A is the most appropriate with some improvements, as it is possible, for example, to add The input placeholder attribute (placeholder="Num 1-99") instead of value="0"
To become as follows:
Code:
This will solve the problem by giving new users hint to help them enter a correct number between 1-99.
I would have included PHP diffs with this post, but I don't have access to the relevant code, so all I can do this time around is make suggestions like a noob.
I don't know anything about what you're talking about, because the code language is too complicated for me to imagine. So of everything you talk about, I like the word above the most. LOL
Btw, I like option C, hopefully it can be implemented soon, but if not, it's okay because I only have a little merit to send, and often there is nothing to send
There's a small UI issue with the merit-sending page that makes it easier than it should be to accidentally send more merit than you intended (I'm sure I've run into a handful of anecdotes about this, but I can't find them now).
Basically, the "Merit points" field is pre-populated with a 0, like this:
People are used to having to get rid of that 0 before entering an amount (or, they have to make sure that the amount they enter is after that 0). Sometimes, people are careless or tired, and accidentally enter something on the wrong side of that 0 (maybe believing that they've already deleted or selected it after mis-hitting a key, or something), and they end up sending more merit than they meant to (that is, sending 10, 20, 30, 40 or 50 merits by mistake is an easier thing to do than it should be).
For comparison with what follows, the current HTML for that input looks like this: .
Here are some ways that I think this could be improved:
Approach A
This approach would leave the field initially empty so that there's no 0 there to trip anyone up.
That would look like this:
The HTML would change to: (that is, value="0" would be removed).
Approach B
This approach would add a bit of JavaScript that "selects" the value whenever it's clicked, that way, whatever you type in will replace whatever was already there.
That would look like this (after clicking):
The HTML would change to: (that is, onclick="this.select();" would be added).
Approach C
This approach would leave the 0 there, but make it "placeholder" text instead of actual text, that way, it's just there as a cue, but the field is actually empty (the 0 will disappear as soon as you type something in).
That would look like this:
The HTML would change to: (that is, value="0" would change to placeholder="0").
Closing thoughts
One disadvantage of approach A is that it leaves the user wondering what they're meant to type in (that's obviously not an issue for people that have sent merit before, but I could see brand new users getting confused without any cues to help them).
One disadvantage of approach B is that it requires JavaScript to function, and there's a (pretty small in this case, IMHO) chance that cross-browser weirdness will make it unreliable. One advantage of approach B is that it will catch a wider range of mistakes (sometimes people initially decide to send 1 merit, and then change that to a 2, but actually end up sending 12 or 21, by mistake. If the entire value gets selected each time you click the input, then those kinds of mistakes would be much harder to make).
Approach C won't catch as many mistakes as approach B, but it's simple, won't leave new users confused, and doesn't need JavaScript to work.
I would have included PHP diffs with this post, but I don't have access to the relevant code, so all I can do this time around is make suggestions like a noob.
(I'm taking a break from the forum, but I'll be back on the 27th; try not to miss me too much.)