-
Notifications
You must be signed in to change notification settings - Fork 308
convert tip-ranges to text input #1070
Comments
Or we could do like Humble Bundle (#434): The amount on the right is an editable input. Garbage text results in $0.00. |
+1, but I'd like a low amount such as 1 also labelled. (You can have both snappable slider, and a linked snappable input field) |
Maybe something even bigger and more obvious? E.g.: |
I like the big obvious range for profiles, but it wouldn't work for things like https://www.gittip.com/on/github/gittip/ -- but the Humble Bundle range would work well there. Also, we'd probably have to have a smaller, but still very obvious, range for profiles on mobile |
@rummik Let's go with the humble bundle slider in all places for now. |
I think the simple slider (with one bubble containing the tip amount) is far more intuitive than the current one (with three bubbles). I support the idea of having a text input box on the side of the slider as well. Perhaps add little up and down arrows that change the amount in the text box by $.25 increments to encourage the user to interact with the text box. 0-10-100 range on the slider is numerically pretty, but not practical, as most tips will fall on the lower range of the spectrum. @whit537 I also like the More button on the yellow slider example you posted. That would be a good alternative to the text box mentioned above. The slider could display the more common, smaller values (maybe 0-10 or 0-5) and then the More button would allow users to select larger amounts. Also in the yellow example above, I like the little question marks. I think tooltips or something similar would be good to inform the user about the constraints of tipping (minimum, maximum, increment). |
+1 for dumping the slider and making it a dropdown and textbox. From my own experience when such an input is required, developers tend to just fallback to that due to the simplicity, so perhaps users could be more accustomed to that. Gumroad implements the desired outcome of this feature more or less in their pay what you want feature, with that link pertaining to some interesting stats. Maybe there is something there we can use. |
Perhaps, taking it from a different tact on how to approach this, is do we even need the slider? what is it for? what is the purpose of the slider? Gumroad doesn't use it, do we need to?. Once they're answered, then perhaps we'll know if the slider is the right direction, or maybe it's a waste and we're improving a broken feature? Sliders tend to make sense when we want to impose a linear passage of something, from a decrease to increase. E.g. the volume knob. However, Kickstarter implements this successfully on their project rewards without using a slider, so maybe we don't need to. Another usage we use, is special prices that are displayed - we show $0, 25c, and $10 by default. Why is 25c special? why is $10 special? why do we care? The reasoning behind these selections and why they are meaningful is not conveyed within the current experience - my only guess is that 4x25c = $1/month - but does that justify the value assigned to $1? It's kind of picking a plan for a SaaS service without knowing the differences between any of the plans! What are the differences, why do they matter, what are the meanings behind those numbers? Running with this notion of conveying the meaning behind the default number groups, maybe have pictures of what they would entail instead. On the slider at $0 have a starving bum with no money, at $1 have a fed bum with an instant noodle packet, at $5 have a bum with a coffee, at $15 have a bum eating a meal, at $50 have a bum enjoying a restaurant meal, at $100 having someone sleeping on a couch, at $500 have someone feeding their family, at $1000 have someone really happy. Then the money groups have huge meaning, and then the slider is now a medium for conveying a story, of which, the patron picks whichever story they wish to be a part of. |
Another idea: dump the slider in favor of buttons, with one button labeled "Other" that reveals a textbox. |
The only meaning I can see behind favoring certain tip amounts over others is their frequency of use. 84% of tips are either $.25 or $1.00. https://www.gittip.com/about/stats.html |
For me, the worst part of the new slider is that it does not allow you to abort your selection and shows an annoying blocking alert() box. I'd like the UI to show a "Save" button instead. |
Two suggestions as someone who just accidentally gifted someone $10 and meant to give $5:
|
From @evbogue on #1066 (comment):
|
|
Sorry, I shouldn't have kept adding +1s to #1066 after closing it. Now we have a ticket fork! 🙀 |
The simplicity of a button is nice but then what amounts do we have buttons for? See #76, #95, and #180 for prior discussion here. The button-as-slider was intended as a compromise between the two, but it's too non-obvious. Text box is nice because it's the most obvious in terms of what to do with it (right?) and it also shows the exact amount you're giving better than a slider. However, the slider indicates that there's a max gift per week of $100, which I don't think is unimportant to communicate. How about this: That's two variants on a text input box with a slider under it as well as "suggested amounts" that are links instead of buttons so that we can show many more of them because links are compact, though that makes the click target smaller which could be a problem on mobile. Also note that I picked up on @evbogue and Gnome's suggestion of shading the left part of the slider. Doesn't account neatly for explicit "save" (do we actually want that?), nor for turning a tip off (the |
Also doesn't account for usage in batch context ("giving" page and org pages). |
Why is there a max? |
Max could be conveyed with some little grey text below the input textbox "Max $100/week" which appears to communicate the max without the visual clutter of the slider. Text could also just show when editing the text box. |
To avoid over-dependence on any one patron (conversely, to avoid giving any one patron undue influence).
It does add a lot of clutter, doesn't it? We could also just give feedback when the user goes over $100 without worrying about communicating it ahead of time. We could also have $100 as the highest suggestion which would softly indicate the max.
Perhaps, though for new users approaching Gittip with beginner's mind I think it's helpful to suggest amounts right off the bat. |
I'll note that the sliders in the Humble Bundle example are actually three linked percentage sliders: When you slide one, the other two adjust accordingly so the total remains the same. |
Maybe the simplest possible, don't make me think way to do this is @whit537's sketch, but take away the slider all together. And then put a confirm button under or next to it. The Red Cross money capture is very clear too. People don't use sliders on the Internet much. And never with money. Think about how much you hestiate around a 'send money' button on Paypal, to make sure everything is right. Plus, this is WAY easier to implement. |
Here's a sketch without the slider at all (per @balupton @ceboudreaux @gwenbell): |
Yay! Yes. Plus a confirm button. |
@gwenbell @evbogue The twist here is that the Red Cross page is a one-time transaction page, this is a part of a profile page that you may visit without any intention to modify your tip. In fact I would expect that most times you visit a profile page you don't intend to change your tip. Do we show the confirm button at all times? Or only when the user changes the amount? Or maybe when they focus that input box? |
I would like to say that the slider entered this whole conversation when I misunderstood how Humble Bundle worked. See #434 and #1070 (comment). Consider the slider dead. |
@gwenbell That sketch isn't bad but we're constrained for now by our layout with the bit of the box we get to use for this. |
IRC agreement on: |
So the amount is entirely free form now, or does it snap to anything? I like the design above, but I feel something has been lost since the original set of buttons - this design requires more thought on behalf of the giver, and provides far less context to the typical amounts that are gifted. Simply stating $100/wk max, may seem daunting to some users and unintentionally price them out. |
@cakey Freeform + suggestions as text links underneath (like Gmail does for including other people on an email, e.g.). I'm curious to see what the suggestions feel like once implemented. I agree that we need some guidance for new users here. |
I built a little prototype slider based on jQuery UI's slider. Take a look here: http://bruceadams.us/donation-slider.html |
Thanks @bruceadams! This presents a good learning opportunity for our team. :-) As we figure out how to work efficiently together, we need to get in the habit of assigning ourselves to tickets, and, conversely, noticing when someone has assigned themselves to a ticket. I'm hoping we can write up a more detailed explanation of this under
@rummik has assigned this ticket to herself, so be sure to be aware of that, and coordinate any work on this with her. (Unfortunately, GitHub doesn't include issue assignments as events amidst the comment stream on the issue; see isaacs/github#77. We should probably do that manually for now.) |
@bruceadams I'll also point out that after hashing it out in the comments above and on IRC, we landed on a design that doesn't include the slider. Sorry. :-( Yesterday afternoon I updated the ticket title and description to reflect this. Here's where the slider officially died: #1070 (comment). |
@bruceadams Feel free to push back on slider death, of course, recognizing that @rummik has probably already started implementation. |
I have no special love for a slider implementation. I'm very unhappy that we have a user interface that we know confuses people, especially when the confusion has an impact on their money. We really need something, anything, that's better than what we have live on the site now. I had put together that prototype a few weeks ago and hoped to figure out how to hack it into Gittip itself. The existing slider was beyond my JavaScript reading ability. |
I've been remiss in not explaining how bad the existing tip button/slider problem is. (My usual MO is to fix things, not just talk about them.) We've had several people complain about the current button/slider, both as being confusing and as having actual tip amounts be far higher than intended. This is a public web site. What is the ratio of people who report an issue to the total number of people who experience the issue? One in a hundred? One in a thousand? I'm convinced the existing button/slider combination has confused and/or pissed-off hundreds, maybe thousands, of people. This has been broken for far too long. Can we get this fixed today? As I see it, we have two clear choices:
|
@bruceadams Yes, this is a big problem. We got a big bump in users and givers from @jeresig's Khan announcement, but not a corresponding rise in giving: This accords with the effect we've heard reported: people are signing up and are in fact tipping, but they're only tipping 25¢ because they think $10 is the only other option. Let's give @rummik until noon (EDT) to surface, otherwise @jeromegn or I will knock this out. |
Thanks @rummik! :D |
Going with this (per discussion in comments):
That's a text input box with a [ Confirm ] button and Cancel link on the right, and text link tip suggestions underneath:
Ex: $100, $25, $10, $2, 25¢
was: convert tip-ranges to a simple slider
The current tip ranges widget has a couple drawbacks:
I propose that we solve these by dropping back to a simple slider:
Between 0 and 10 we should snap (in even-width increments) to 25¢, 1, 2, 3, 4, 5, 6, 7, 8, and 9 (that's 10 values between 0 and 10).
Between 10 and 100 we should snap (in even-width increments) to 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75, 80, 85, 90, and 95 (that's 17 values between 10 and 100).
Let's try it with only 0, 10, and 100 actually labelled.
Note that we still should add pop-up confirmation to tips >= $10 (#1065), and a success confirmation (#1062).
The text was updated successfully, but these errors were encountered: