I have a system where I want users to be able to customise an order confirmation email. The email has placeholders which are replaced with real customer data.
At the moment we tell people to use tags like {customer_name}, however this confuses some people and has a lot of room for error.
I would like to have something where the placeholder can be inserted from a menu and then acts as a unit, just like any character in a textarea.
I have thought about using tinyMCE and writing a plugin but this seems like overkill.
Does anybody have any ideas, or know of any tools I could use?
Thank you.
You can't really style items within a text area. I think the best you could do is have a menu that inserts the tags that you are already using.
Another thing you could do is add a 'preview' div below the textarea. It would live parse the users entry (or just do it when the user pushes a 'preview' button) and you could do replacements on the tags to insert an image or something that made more sense to the user than the shortcode.
Related
Background
I have a text I would like to present on a web page (angular/bootstrap) in which some of the words I would like the user to be able to change by clicking on them, getting a drop-down of fixed alternatives and selecting another one of these alternatives.
Req 1:
Ideally it should be a minimal visualisation of whether a word has alternatives or not. Maybe a dotted line under the word.
Req 2:
It would be great if the entire text was possible for the user to mark and copy as usual and that the copied result doesn't contain any HTML such as select boxes etc. I realise this req may be impossible to fullfil, but you never know - maybe there are some clever work-around that the clever community has.
I tried using the select tag, but I didn't succeed to fullfil any of the reqs above.
I have made a simpler form for your problem and requirements :
https://jsfiddle.net/aakashshah/2y7kj5j3/1/
onclick element can achieve the required feature
So I have a Rails app in which users can create entries, similar to blog posts. Both the title area and the content areas are HTML5 contenteditable divs. I don't need to be able to save anything like bold or italics, I just need to be able to save paragraph breaks and commas, exclamation points, etc. When the user opens the entry again, it needs to display the entry as they wrote it, with all the correct breaks, etc.
Are there any gems or plugins of the sort that would help me accomplish this?
It turns out, that you can't simply pass HTML from contentEditable div via form submission, so some JavaScript should be involved. Checkout similar question and link in first answer.
We want to allow the users of our web application, to leave notes formatted with html.
On client side we are providing them with ckeditor [http://ckeditor.com/] which is a wisywig editor that generates html, that is then submitted to the server via a form
We then want to display the notes created by the users, with exactly the same formatting as they submitted them
My concerns are:
Putting attacks and bad intentions aside, how can I encapsulate the note when displayed on the site, so that
a. They don't inherit the design from the rest of the page
b. They don't influence the rest of the page, for example by opening and not closing a tag accidentally, or closing without opening.
Malicious code injection attacks
At the moment, the first is much more important, as it's an in house product for our clients, and is not open to the wide public. But security comments are very wellcome as well
Possible solutions that I consider are:
Ideally, I look for a way to encapsulate this pieces of user html, like : inside this area I show what you submitted (rendered, not source), you cannot influence and are not influenced by the code on other parts of the page
Specifically, we thought of displaying the notes inside iframes.
Other natural direction is dealing with parsing the inserted contents, and stripping out stuff.
Any inputs are welcome, and mainly:
How can I "encapsulate" the inserted contents, if I can?
Any comments on the iframe direction
Do I have to parse the contents anyway? What do I absolutely have to strip out?
How can I "encapsulate" the inserted contents, if I can?
The truth is unless you 'fix' their code (via some kind of check) you will get issues (think broken divs, etc). I don't see how you can encapsulate HTML FROM HTML. I would however only let them put in content like bold, italicize, center, etc;
Any comments on the iframe direction
Personally I wouldn't go that route, new can of worms for security and not a 'clean' way of doing this.
Do I have to parse the contents anyway? What do I absolutely have to strip out?
Yes don't be lazy, some devs always say "well I dont need it, its internal" and then it becomes an external thing, and at that point its so big that ONLY a full re-write will set it right, and it keeps chugging along until something is broken, then shit hits the fan and the big boss cries out why hasn't this been done. Long story short.
Yes you have to parse / validate / check all your input, wether internal or external. Anything other than that is just lazy.
In closing I would do it by using an editor like here on SO, which only allows some types of selective formatting. After all a broken <b> will not kill your whole layout, a <div> will...
Markdown formatting
You could use exactly the same type of intermediary solution that this site (StackOverflow) uses in it's user-generated-content (questions, answers, comments).
It's not the complete solution that could replace WYSIWYG solutions like the code editor, but it's just what a usual user-generated-content woudl require. It even allows you to include images.
For a complete guide:
https://www.markdownguide.org/cheat-sheet
In many prototype scripting cases, it's easier to just stick every form item (such as an input or textarea) in its own form tag. Is there anything wrong that could happen from having lots (like 1000) form tags in a page?
What do you mean by ‘prototype scripting cases’? How are the forms being submitted?
If each form is its own action, eg. you have lots of separate product listings with different REST action URLs, then, yes, a separate form per line is appropriate.
If you're just using controls on their own for scripting, and have no intention of submitting them through the normal HTML form process, you don't need any <form> elements at all, just include them bare.
(Except in the specific case of radio buttons, which require a <form> for grouping.)
Should not be a problem but why do that when you can just use one form. It will work even with 1000 forms but it would be stupid with over 50 anyway.
There is nothing particularly wrong with it, but It would be a better idea to have them all in the same or fewer.
I would say, first off, have 1000 inputs on a single screen poses a different problem that should be addressed first. That many controls will be completely unusable.
That being said, having each element in its own form will cause more overhead in processing your page. You'll have to decide whether the impact of this is too large in your scenario.
You will lose the info from other input elements when submitting any of these 1-input forms, since a form submission ONLY submits the values for input elements of that one form.
If you're OK with that in your prototype, not a big problem
The only thing wrong with this is the semantic process of what a form is. A form should only submit what the fields inside of it have. So, anything related to that "form" should have the proper fields with in it.
Technically, when using a form it'll take you to a new page, so, any of your values in any other form on that page will be lost. The only way around this is using javascript to ajaxily submit the data.
There is no issue with using the HTML markup in the way you are wondering. The only thing you will want to worry about is the more control structues you add to your HTML the more text the web server needs to serve up. This will lengthen the amount of time it takes to get your code from the server to the users browser.
I've got a bit of a usability issue that I'd value some input on.
The initial page to my site contains two groups of controls, one for users to login, the other for new users to activate.
The issue is with the latter. When users signup for the service, they recieve an activation code that's in the form XXXX-XXXX-XXXX-XXXX. At the moment they have to enter this into four separate textfields. Whilst I've added some javascript to this to automatically move them back and forwards between textfields as if it were a single control (which works pretty well) the issue is that it lacks a way for the user to paste their data into it and as such is a bit of a pain.
Now this is not a huge issue, but it potentially means that peoples very first experience with my site is a slightly frustrating one, having to hop backwards and forwards between the email containing their activation code and my page. That's obviously not optimal.
At this point you're probably thinking that the glaringly obvious answer would be to make the activation code entry into one single textfield. And you would be right, but I lose one very important thing if I do this: I lose the key visual differentiator between one form and the other, which automatically tells the user which is the form they need to use without reading anything or having to analyse anthing. As it is at the moment, effectively there are two different shaped holes on the page and the users data will obviously only fit one of them so, to an extent, it's a no-brainer which form is relevant to them.
So, does anyone have any good solutions to this? The single restriction is that I need to keep all controls on one single page.
Thanks in advance for any help.
Edit:
Thanks for all the input so far, every bit of which has been valuable. I'm currently thinking that the best solution is not one single thing, but actually an amalgamation of different approaches to make the whole thing more usable.
On that basis, here's what I'm going to do, based on all your suggestions:
In the purchase email, setup the link
to the initial page such that it
contains the activation code in the
querystring. Setup the initial page
to check this and forward them
straight on. This probably means that
the vast majority of users won't even
see the initial page, but there will
still be cases whereby people receive
their codes by other means and will
have to input them directly
Convert the four textfields to a
single textfield with
"XXXX-XXXX-XXXX-XXXX" as an inline
label.
Setup the login controls to forward
on any user that mistakenly enters
their activation code here without just dumping them to an error screen.
And I don't know why I didn't include it in the first place, but here's the URL for anyone that wants to take a look at the current implementation (you'll have to excuse the fact that it's in Italian, but it should be fairly straightforward what's what).
Have given the answer to bryan which contains most of what I'm going to use. If I had the necessary reputation I'd vote up all your answers as they've all helped. Thanks again.
A few easy options:
You can keep them the same physical page, just alter the querystring when you send the activation code. Hide one set of controls if the querystring is available. If you have to display both sections, then grey out one section based on the querystring information.
Change the control to have one textfield, but include "XXXX-XXXX-XXXX-XXXX" as the default text in the New User Activation. If the user clicks on the textbox, remove the text so they don't include the prompting text with their activation code. People will see the default text and gravitate towards it if they're expecting that pattern. People logging in will see the default text and block it out.
You could write an onpaste function in JavaScript which chops up the pasted string in to 4character blocks and them writes them to the appropriate textbox's via the dom.
Sounds to me you’ve a problem of users confusing two text boxes but then you’re making it worse by dividing one text box into four. For example, auto-tabbing through fields is bad usability -see comments and answers to “Moving a focus when the input text field reaches a max length.”
Assuming this isn’t a hypothetical problem and you’ve actually observed people use the wrong field, you need to find another solution for users confusing the fields:
Use terse field labels. Label the field “Activation Code” not “Enter your sixteen character dash-delimited activation code from the email we sent you when you signed up.” Text necessary for explaining where to get the activation code should be after the text box.
Use cueing text or graphic design on the outside of the text box to indicate it has four substrings. For example, put “XXXX-XXXX-XXXX-XXXX” under the text box.
Remove all extraneous elements from the page –the more graphic and text distractions on the page, the less the differences between the two text boxes will be noticed.
Make it so it doesn’t matter which text box the users use. If the string entered in the Username text box doesn’t match any username, then see if it matches any activation code, and vice versa.
Eliminate the activation code text box. Instead, when you send the activation request, include a sign-up URL that includes the activation code as a parameter (more details in answer by bryanjonker).
Sorry, this should probably be a comment, not an answer, but it wouldn’t fit.