3

On Venmo's web app, you create a transaction by selecting a recipient and then filling out a field that includes a dollar amount and a description:

Venmo payment field, with example text "$5.75 for ice cream!"

Both the dollar amount and the description are mandatory, and they can only be entered in this field. If you just enter "8.00", for example, it's rejected--you have to use the format "[number] for [thing]".

This was confusing for me at first* since a dollar sign at the left of a field seems to indicate that it's a field for a numeric dollar amount. In fact, I don't think I've ever seen this done before, even on paper forms--all checks have separate fields for the transaction amount and the memo, for example. At the very least, this seems like bad accessibility, since some platforms may have different controls for numeric vs. text fields, and there's no good reason that I'm aware of to require users to enter a monetary amount as text.

Are there any valid reasons to create fields like this?

*On Venmo in particular, this is exacerbated by the unhelpful error message A transaction must have a note, e.g., "Kale salad with beans, onions, mushrooms, berries, and seeds.", which goes into details about someone's salad but fails to provide an example of correct input. But I'm wondering about this field format in general.

  • An input mask may make it better but definitely seems like a "style over function" decision. – DasBeasto Oct 3 '16 at 20:09
  • That is a gross way to expect someone to fill in a form and the error message is completely unhelpful. That said, I can see what they're trying to do: they're trying to make the form conversational, which in turns gives the form a "friendly" feel. They've done it very, very poorly, but that's the particular technique that they're going for. – Nick Coad Oct 4 '16 at 4:43
  • Select statement for a database is pretty big anti pattern. A programming language. If a field did not have mixed data there would be not need for parsers. – paparazzo Oct 4 '16 at 4:55
1

Yes, this PROBABLY is an anti pattern. Please note the PROBABLY word, because anti-patterns are usually measured on client's side. But given the information you provided and with some experience on my back, I'd bet money this is like the definition of an anti pattern: something that looks like a great idea at first, but use demonstrates it's counter-productive or provides a bad experience to users (like in your case)

Let's look to a known example: credit card numbers. There are lot of studies about the proper UX of a string which only has number and a known pattern . Even on this site, you'll find lots of question about this, including whether to use a single input, use masked inputs, use 4 different inputs, auto tab and so on.

Now, your example: it has 2 extremely different data types, with no clue on affordance and everything in the same field. Furthermore: if you don't comply with the mysterious UX, your input doesn't validate. And as you say, even on validation error messages, it's unclear what to do.

Now, compare both cases: one is way simpler, has a lot of studies about it and still represents a problem sometimes, including some anti patterns here and there. The other is complicated, with obfuscated data, unclear for the user and no clues on affordance, with botched validation messages. So.... what would you say about this? (I know what would you say because you said it in your question, and you're 100% right, it's a rhetorical question)

In short: as I said, I don't have the client's side data to confirm this is an anti pattern but... If it looks like a duck, and quacks like a duck, we have at least to consider the possibility that we have a small aquatic bird of the family Anatidae on our hands.

EDIT:

On a second view, now I can see they can share this payment on Facebook... guess that's the explanation for the convoluted UX, but well... posting your financial movements on Facebook is weird to say the least. As a matter of fact, this is the weirdest part of this UX for me

  • Yeah, as Madalina Taina noted, the focus on the transaction description is probably there to fuel the sense of conversation--you can see in the screenshot that "Public" is the default privacy setting, and right below that form, there's a timeline of your friends' money exchanges . I have no idea why that necessitates entering it all in one field though, especially since the mobile app uses separate fields like everything else in the world. – Milo P Oct 4 '16 at 18:40
1

I think this is a marketing strategy, they want to keep the transactions friendly and in this case the accent is on the action, not on the money.

They explain how to fill the input with the placeholder and I'm sure they have a solution to insert the sum separately in the database.

I don't find this wrong or counter-productive, so I don't think this is an anti-pattern.

  • 1
    "They explain how to fill the input with the placeholder" I disagree, I don't think the placeholder appropriately explains the field, it just gives you a single example of a valid input. You don't know, for example, that the word "for" is required. You don't know if you have to enter cents or not. Can you enter 50c or does it need to be $0.50? I agree with your theory that this is an attempt to make the form "friendly" but I think they've done it poorly in this particular case. – Nick Coad Oct 4 '16 at 4:41
0

Putting multiple data types into a single field definitely does have issues, when storing and recovering from the database, one merged it'll be very problematic separating the data.

However I think they might be trying a natural language approach for this field.

e.g. http://tympanus.net/Tutorials/NaturalLanguageForm/

so while it might look like a single field, it might actually be a form

0

It's not because it's mixed values, but because it's pretty unclear what that input field needs to be valid.

Instead of just showing that placeholder, it should have probably been designed as such:

mockup

This actually makes it very clear what to input, because it guides you through the process, instead of assuming users will know what to write.

  • That would definitely make it clearer what should go in the field, but wouldn't the form still be relatively non-accessible since it would be a text field instead of a number field e.g.? I found this on the desktop version of the site, but it still makes a difference for people who have onscreen keyboards or are using tablets. – Milo P Oct 4 '16 at 18:19
  • Why would this not make it accessible? It could easily shift from numbers only keyboard to full blown keyboard? – Majo0od Oct 4 '16 at 18:33
  • How would it do that? Most phones e.g. use different keyboards for a field depending on whether it's an input for text, number, etc., but each field can only have one type (textarea, in this case). – Milo P Oct 4 '16 at 18:44
  • That input field doesn't have to be an input field at all. I'm not too sure why you're concerned with the technical aspect, especially because this is mainly for UX. But because I code for work too... ill do it anyway... That whole field can easily be a div, and inside of it, the gray areas could be input fields, the first one an input of number and the second an input of text... – Majo0od Oct 4 '16 at 18:46
  • I don't think they'd really be the same field then. – Milo P Oct 4 '16 at 18:59
-2

I don't think it is the best pattern here but it is not an anti pattern. If a field did not have mixed data there would be not need for parsers.

  • query statement for a database (SQL)
  • programming language
  • Number of document management applications use a search syntax with multiple field types. It is part of them CMIS specification.
  • Many of the litigation support applications use that syntax
  • Westlaw syntax is common
  • Jason
  • ODATA
  • LUCENE (the leading search engine)
  • I guess that's true for a very broad definition of form field (i.e. one that considers an entire program a field), but here I'm thinking more specifically about fields on a traditional POST-type web form. All I could find on Westlaw syntax is a type of natural language search, which may be a good example of this pattern used intuitively. – Milo P Oct 4 '16 at 15:25
  • 1
    Can you give an example of where you've had to extract two or more expected inputs from one data field? – Andre Dickson Oct 4 '16 at 16:59
  • 1
    "An AntiPattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences." Just because you can parse it doesn't mean you should. In any case where you have an expected number/pattern of inputs just make them distinct inputs. – DasBeasto Oct 4 '16 at 17:04
  • 3
    @Paparazzi Either you're not understanding the question or you're being decidedly stubborn. Nobody here is questioning whether a programming language is an antipattern because nobody here is associating an input field with a programming language. – DasBeasto Oct 4 '16 at 17:18
  • 2
    @Paparazzi, I think the problem with your answer is that you're seeing the programming side of the question, and there's no doubt about it. But the question is about the USER experience, and most users won't know what looks common to you – Devin Oct 4 '16 at 18:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.