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.
Topic: A small merit-sending UI tweak - page 2. (Read 621 times)
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.
I also prefer Approach C. Just a placeholder text, similar to how it is now, but more error-proof.
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 not serious are you?
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
You are not serious are you?
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.
Option C is the best approach in my opinion.
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.
Option C is the best approach in my opinion.
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?
Yes No
Please don't!Example: Are you sure you wanna send 50 sMerit to user X?
Yes No
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!
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?
Yes No
Please don't!Example: Are you sure you wanna send 50 sMerit to user X?
Yes No
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!
We are already missing you. 
Anyway, I prefer Approach C. Short and simple. Just a placeholder text should be enough.
May I suggest another approach?
If you could add a final confirmation message before sending sMerits, that would be nice.
Example: Are you sure you wanna send 50 sMerit to user X?
Yes No
(I don't know how it could be implemented, maybe throught Javascript I guess)
Anyway, I prefer Approach C. Short and simple. Just a placeholder text should be enough.
May I suggest another approach?
If you could add a final confirmation message before sending sMerits, that would be nice.
Example: Are you sure you wanna send 50 sMerit to user X?
Yes No
(I don't know how it could be implemented, maybe throught Javascript I guess)
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).
~
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.
Approach C
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.Fork 
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
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.
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.
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.
Although this could raise a same problem someone would mistakenly send "11-19" merits.
+1
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.
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.
snip
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.
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).
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..
Jump to: