Auto-space within input field - html

I'm currently working on a project in which I need to fetch street/city details from a DB using a zipcode. Dutch zipcodes use a "1111 AA" format, I would like to have this entered in a single input field while automatically adding the space in between the numbers and letters if the user doesn't enter the space himself.
I've been googling this quite a bit and all I have been able to find so far were ways of restricting the user input to numeric characters.
Thank you.

You'll need JavaScript to do that. In this case, jQuery can actually help you a lot. Here's a neat plugin to handle what you want:

There is no tool for such operations in HTML. You could code the functionality in JavaScript, using a keypress event handled that checks whether four consecutive digits have been entered and appends a space in the positive case. This gets more difficult if you consider what should happen if the user presses the delete key to remove characters. You would also have the problem that users may type “1111 AA” pressing the space bar, and what should happen then?
So it’s of questionable usefulness. It’s better to just accept the zip code with and without a space.

Related

Implementing a range in HTML time input

I have been asked to help fix a bug in a web application that is mostly python (running Flask) which is what I know and why I offered to help. However my HTML knowledge is very bad and I need help. I've fixed the bug in the python code, but I want to make sure the user can't find more ways to break the application. It has to do with the form in HTML where users input the time for a deal. The input is in text format with the placeholder 'hh:mm:ss' but that doesn't stop them from entering all kinds of things other than a time in that format. If I had done this from the beginning I would have made this field a 'time' format but too many things depend on it being a text field now that I would rather just set some validation on this text input field.
The piece of code is:
<input type="text" name="time_left" id="time_left" placeholder="hh:mm:ss">
The only restriction is that the time can't be less than 00:00:00 and it can't be more than 01:30:00. I would love to just put a min/max attribute in here somewhere but I doubt it's that simple. Especially with it being text.
Can anyone advise me what I can do (the simpler the better, as I say, I'm not very good with HTML)
For HTML5 only solutions, there are two ways. One is to make it a type="time" input. It's value can still be read with input.value as a string, if that's of any concern to you.
<input type="time" min="00:00:00" max="01:30:00">
Browsers will allow steps of 1 minute. If you need second precision, add a step="1".
The other solution is to add the pattern attribute:
<input type="text" pattern="0(1:30:00|1:[012][0-9]:[0-5][0-9]|0:[0-5][0-9]:[0-5][0-9])">
Both solutions are viable and each has its advantages and disadvantages.
The latter will have better browser support, but for support closer to 100% you will either way need a JS library that takes over from the browser. I wrote Hyperform, that would do that (and more), but if it's just this one field you might be better off writing your own event handler and attaching it to the change event of that input field.
Edit: The regexp in the pattern attribute will distinguish several cases separated by |. The first and simplest is the max time 01:30:00. The next are the times from 01:00 to 01:29:59, and finally the times from 00:00 to 00:59:59.

HTML5 Input Types & Touch Device Keyboards: Appropriate Number, Tel & Text Usage?

I would like to automatically initiate the numeric keyboard on touch devices for zip code and social security number input fields. Zip codes are entered in a five digit format, while SSNs are entered as 111-22-3333. My understanding is that type=number and type=tel fields will automatically initiate the appropriate keyboard, so these inputs seem appropriate, but I'm not confident they are the right choice.
Type=Number
I originally thought type=number would be the optimal solution (since it sounds semantically correct), but have since found that this type is really only for true numbers and not strings of numeric characters. I've seen blog posts making accusations of browsers automatically including the comma as a thousands separator, and stripping leading zeros on submission (neither of which are zip/ssn friendly).
Type=Tel
From what I have read, this seems like the best solution to my problem. I'm concerned by the meaning of this new type though. Should I really be using a telephone field for zip code and ssn? What if some mobile phone manufacturer decides to start showing the address book for tel fields? That would make no sense for a zip or ssn.
Alternatives
I've found that the new pattern attribute of type=text inputs can be used to trigger the numeric keyboard on iOS devices, but that only partially solves the problem.
I've also found a new attribute inputMode which seems to be the ideal solution, but doesn't seem to be implemented by any browsers yet.
The Question
What I'm hoping is that someone has a suggestion or a best practice? Should I use TEL? Should I go with the iOS solution and ignore other devices? Will inputMode ever work?
My suggestion is to use pattern and inputMode only.
Additionally, Type = number is acceptable if you are only accepting integers between 0-999 and you are okay with the extra validation that will be done - even if the user clicks cancel.
Type=Number has issues even if it is a number, let alone a SSN etc, as it has unpredictable handling of values with regard to negative numbers, localization, precision, leading zeroes, etc, depending on the browser's implementation. Best practice is to avoid unless you have an internal website with a fixed user base where you know the devices/locales being used - unless you are expecting an integer between 0 and 999. Negative numbers, decimals, and thousand characters all will have problems on certain devices.
In addition, if you use 'type' the page will validate data even if the user clicks a cancel button. You could globally turn off validation, but now the page will auto-delete any invalid data on post back! If either of these are acceptable to you, you can use 'type'.
Type=Tel works 'today' but as you point out, it is dangerous to use as who knows what browsers will do in the future. Not to mention that '122-222-2223 Ext.34' isn't even accepted by these devices. I would advise caution if it is a phone number, and avoidance otherwise. The day may come that some device decides to validate the number even though the HTML5 specs say not to.
Pattern=... is good to add. Most browsers will ignore it, so use another validator as well, but at least newer iOS devices will use it, and that's 45% of mobile users.
InputMode=... seems to be the only other hope at this time. Hopefully it will get supported in the future.

How to create a clickable "tag cloud" to populate a subform?

I've been lurking around for years reading up on all sorts of topics. Professionally I'm a Systems Interface Specialist/Interface Architect. I can work wonders with tcl, Cloverleaf, HL7, even Excel, but Microsoft Access eludes me. It repeatedly befuddles and confounds me. Everything that would seem simple and logical to me is neither of those things where MS Access is concerned.
So, I've come to you. Honestly, I'm not even sure I'll be able to put into the correct "technical" words what I want to do. I only know how I want things to appear to function when I'm finished.
I have built a very "simple" relational database to be used by authors who collect sentences or sentence snippets for use/inspiration in writing. There are three tables:
tblPhrases contains an autonumber field idxPhrases and a memo field Phrase.
tblTags contains an autonumber field idxTags and a memo field Tag.
tblTagsToPhrases contains an autonumber field idxTagsToPhrases and two number fields: Tags_index and Phrases_index
The first two tables require that all fields be unique.
Clearly (or not so?), the third table is the many-to-many connection. It allows for there to be many tags associated with a phrase and more than one phrase to be associated with any one tag.
I have figured out how to set up a form and subform but it looks clunky as you can see and it's not at all what I had imagined.
What I really want instead of the dropdown combo box in the keyword/tag subform -- which does populate from tblTags and when I select something, correctly populates tblTagsToPhrases and when I return to that Phrase in the form, displays the list of associated tags...
What I would really like instead is to have the values in tblTags appear in a "Tag Cloud" like on a webpage. Then I can click on the hypertext control for that value and it will populate a text field, adding commas between the selections. However, behind the scenes, it's really just adding to tblTagsToPhrases. I should also be able to type in a new Tag right there. Basically, treating the field like a Tag field on a bookmarking site.
And if I were really honest, I'd like to be able to display the phrases as hypertext too because that would look much less clunky and less like a database.
Can anyone give some direction to get from where I am to there.
Thanks so much in advance for any and all help!
You need VBA to do this, using the Timer event of the form to move labels around randomly, using some detailed maths to get them to move in a direction-of-flow, rather than completely random. Each label (or textbox) would first have to be populated with the field-values. If you only want a static tag-cloud then you wouldn't need the the Timer event.
If you don't know VBA then you'll have to search but I think it unlikely that you will find an example of this (and if you do, will you be able to adapt it?). In fact, if you get this to work, and include the animation, I would expect it to exhibit noticeable flicker.
I think you should ask yourself if you intend to build a database or a web-application. (If you are struggling with Access, why go even further and attempt to make it do things that it wasn't designed for?)

best way to present huge html forms

My application has a requirement such that I have to display a huge number of HTML input textfields (maybe 2,000 text fields). The fields can be logically grouped into sections and the sections are repetitive. What is the best way to display it to the user so that they can enter data with minimum clicks?
I'm not sure what kind of users you have that would willingly sit through 2,000 text fields, but if it's a requirement, then you do what you have to. :)
You say it can be grouped into sections and the sections are repetitive. I'm not sure what parts are repetitive, but managing the sections carefully seems of utmost importance. Some sort of Javascript hiding/showing seems likely to be a big help... I think I would choose JQuery's Accordion effect or something similar.
You could add Tab key events to each section in order to assist with navigation and open a new section once an old one was complete. Adding change events to the fields might assist with that as well.
If you need to break the form up across multiple pages, then you'll probably want to utilize AJAX to load new sections/pages and store the submitted data into a session until the user is done.
Depending on the format of the required answer, there are two ways:
If the answer is of a known length or the answer is one of a few choices, you may auto-advance the cursor w/some javascript/jquery. For instance, if you're expecting phone numbers, when the person enters the 10th digit in the box, move the cursor to the next box.
If you don't know and you can't apply (1), the quickest way is to encourage users to tab their way through the boxes.
Speaking of tabs, if the boxes can be logically grouped, you could create tabs and have the users page their way through the questions. This will create more clicks, but will improve user experience.
But holy crap, 2k text boxes on one page is crazy!
I work on a similar product, and perhaps the number one thing would be to make sure that tabbing between fields works logically and quickly. The people who do data entry on this type of thing are lightning fast and fairly mindless (I don't mean that in a pejorative sense), typing in numbers from a log or printout without looking at a screen.
Apart from that, we implement tabs (like tabbed browsing) on the page, group boxes, and other things like "dynamic lists" which is like a data grid of text boxes that the user can add and delete rows from client-side.
Paged format, like a survey? You could then use SESSION to store the input for each page and retrieve the prior answers when the user switch between them. Another method is to use ajax to navigate between different . I think the issue is not the number of clips, but 2000 textfields is going to look scary on just one single page.

UI elements for entry of an activation code

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.