I have a page that tells the user to input a time in the format hh:mm:ss. This is obviously fine for English speaking audiences, but is this an acceptable international notation?
If not, could you give me some examples of how other countries display this kind of information to the user.
In terms of time, it is usually either in format hh:mm:ss or h:mm:ss, that is you either do zero-padding or no zero padding for single digits hours.
Another thing is, the format - distinction between 12 hours and 24 hours, that also varies from Locale to Locale.
Lastly, you should take into account local user's time zone - it is natural to enter the time in relation to current time zone.
How would you go about these options? Basically, it depends on what your UI look like. If you have just one text box where user can enter free-form text, you should actually parse the text according to valid Locale format. In that case you can give an example of the format, by formatting current day, so the label would say something like "Enter the time (for example: 16:36:11):".
Other approach is to have two (hour/minute) or more text fields (seconds) separated by time separator (":") and possibly conditional AM/PM radio button group (or drop down). In that case it would be a bit harder, because to do that correctly, you should actually analyze the localized pattern (on what is and what is not supported) and dynamically create UI elements (I don't want to see AM/PM stuff as I am using 24 hours time naturally) as well as validation rules...
I know dates are different between different country, but time is pretty standard. you won't have problem with French, spanish, german, UK... i don't know for asian country tho...
Related
If a date is specified in the format
start=2021-04-05&end=2021-05-05
does that mean that 2021-05-05 is excluded from the results?
and it's returning up to 11:59:59 on the 4th?
In an API I'm using, it seems to be behaving the same as
start=2021-04-05T00:00:00Z&end=2021-05-05T00:00:00Z when no time is specified.
A few things:
I think you are asking about the full-date format from RFC 3339, which is the same as the ISO 8601 extended date format: YYYY-MM-DD
Neither specification says anything about inclusivity or exclusivity of date-only ranges.
ISO 8601 does talk a bit about ranges (they call them intervals), but they are defined as a pair of instants, not whole dates.
The typical best practice (in my experience) would be to use a fully inclusive range for date-only values, or a half-open range for date-time values. For example:
[2021-04-05, 2021-05-05]
[2021-04-05T00:00:00, 2021-04-06T00:00:00)
However, this is not a hard rule. The actual details would be highly specific to the particular API you are using and how the authors of that API designed it to function.
A whole date like 2021-04-05 is not necessarily the same thing as 2021-04-05T00:00:00. In many cases, the reason to use a whole date is to not associate a time or a time zone at all. But again, this is highly implementation specific.
Nothing you've shown would imply that UTC (Z) is being used. If that's how the API is behaving, that's another implementation detail of that API.
I need to create a PDF with a date field that displays dates in the format dd.mm.yyyy. This field must be validated and should also accept inputs in other formats.
For example, users should be able to input dates in the form dd.mm.yy, which will then be expanded to dd.mm.20yy (MS Office apps like Excel do this).
Alternatively, selecting multiple valid formats would be an acceptable solution.
What currently happens:
If the date format of the field is set to dd.mm.yyyy, dd.mm.yy is rejected.
If the date format of the field is set to dd.mm.yy, dd.mm.yyyy is accepted (but formatted to dd.mm.yy).
The last behaviour is almost what i need, just with the wrong format.
Is there a way to do this without custom Javascript? If not, is there a way to still use the built-in formatting or do i have to rewrite everything in JS?
Unfortunately this is not achievable with Acrobat's built-in formatting.
One thing to add to your second bullet point: it trims the date down to .yy when you exit the field, but it still retains all four digits. When you click into the field, it will revert back to being .yyyy. That may or may not matter depending on how you're using it.
Regarding a custom validation, a quick Google search will yield an abundance of Javascript date validation scripts. Something like this could probably be quickly repurposed for your application.
I am saving all my notes in a log file. Each line is a note, suffixed by tags, and prefixed by a date and time marker, which currently looks like this: [12.20.09:22.22] ([date:time].
I am planning to have this a long-living format. Notes will be logged willy-nilly with this format 20-30 times a day for years to come. I foresee numerous kinds of parsing for analytics, filtering, searching ...
I am worried about the [ ]s though. Could they possibly trip some parsing code (someone else's if not mine)? What would be the most non-confrontational marker?
If you end up going with your own format, can I recommend ISO 8601 for your date and time format.
In summary, the basic format is:
yyyy-mm-dd hh:mm:ss
You can extend this with timezone and microsecond info if you wish. Timezone is recommended or assume UTC.
With the date/time in this format there's no confusion over which is the month and the day. And it has the bonus of sorting using a basic string sort.
I'd consider using either XML or JSON as the format for the file.
In particular your date/time marker is ambiguous. Is it mm/dd/yy or dd/mm/yy? Or even yy/mm/dd? And in what timezone is the date and time?
Both XML and JSON define a way to have dates that are culture and timezone independent, and (best of all) there's masses of tooling available for both formats.
XML datetime format is defined here: for example, 2000-01-12T12:13:14Z.
JSON datetime format is defined as the number of seconds since Jan 1, 1970, so it's a bit uglier: { currentDate: "#1163531522089#" }
If you want everything to last in a long-lived format, then the metadata needs to be as explicit as possible. If it's intended to be long-lived, then many others will need to read it, as easily as possible.
I agree with Jeremy McGee: XML is an excellent choice. Even if no other data lives, then having it be in the format:
<note>
<datetime>
<year>
2009
</year>
<month>
12
</month>
. . .
</datetime>
<message>
Foo bar baz quox
</message>
<note>
cannot be misunderstood.
This depends on your data. However, if you escape them with a special character of some sort, (i.e. \]) and code accordingly to look at the previous character when finding a "[" or "]", you should have no problem.
Also, if you're open to a new format, I'm a fan of JSON as it's light weight and very useful.
Using '[]' as the markers would be ok provided that you allow the DSL the ability to escape the characters. This is typical of operations on text which need parsing.
As an example check out the typical regular expression syntax which enables '/' as the seperator, whilst letting the user specify an escape character such as '\'. You may get some more ideas from the likes of such Unix tools as; awk, sed and grep
I would tend to think a standardized format is the way to go, with JSON being my personal choice because of it's simplicity. Not only does that help to avoid parsing issues since others have already though about it, you are also given a lot more tools to work with over the life of the project.
I have received requirements that ask to normalize text box content when the user changes the focus to another control on the same data input form. Example normalizations:
whitespace at the start and end of the input is trimmed
If the text box was made empty and this is not valid, replace the content of the text box with the default value
I have a feeling that this is not in line with good GUI design. I have read the Windows UX Guidelines for text boxes but I did not immediately find any relevant rules.
Is normalizing text box content in this way acceptable?
I have definitely seen this before (examples elude me right now) but I personally don't like it when the UI changes my input.
If the UI is smart enough to change my input on me then it should accept it as is and change the value when it needs to process it.
When the input changes auto-magically you are now forcing the user to stop and ask themselves why it changed and if they did something wrong or if the application has an error. Don't make the user think!
Generally, you should accept user input exactly has they entered it. Chances are users did it that way for a good reason. For example, imagine a user entering a foreign address, and then your app screws it up trying to format like a domestic address. At the very least, users entered the input the way they’re used to it being, so changing it can make it hard for them to cross-check it.
However, there are several exceptions:
Add defaults to incomplete input. Adding input the user left off (e.g., years to dates, units to dimensions) provides good feedback on how the app is interpreting the input that would otherwise be ambiguous. This also encourages the user to use defaults, making their input more efficient.
Resolve other ambiguities. Change to an unambiguous format if the user’s format is open to interpretation. For example, if you have international users, you may want to change “9-8-09” to “Sep 8 2009” (or “9 Aug 2009”) to provide feedback on what your app considers the month and day to be.
Add delimiters when none provided. Automagically adding standard or even arbitrary delimiters to long alphanumeric strings (e.g., phone numbers, credit card numbers, serial numbers) provides an input display that the users can crosscheck more easily. Sometimes users may enter a string without delimiters in order to go faster or because they are the victim of web abuse by sites that refuse to accept even standard delimiters.
Spelling, grammar, and capitalization correction. Users often appreciate this, but only if there’s also a means to override it. Some users like to use "i" as the first person pronoun.
If the field is used by more than one user, then you probably should automatically format the value in some standard way that accommodates the majority of your users, but that should be done when the value is stored on the backend, not when focus leaves the field. For example, if a user enters a time of 15:30 it should remain as 15:30 as long as the user views the page. However, the next time a user (any user) retrieves the data, it should appear as 3:30pm (if that’s how most of your users are used to seeing time).
Such backend formatting applies to trimming whitespace so that all users can search, find, and sort on the field consistently. It’s probably not a good idea to replace a blank value (or any invalid value) with the default because users are unlikely to anticipate getting that value. An exception would perhaps be changing blank to 0 for numeric fields in situations where obviously blank == none == zero, but again this probably should be done when storing in the backend, not in the field itself. If blank is ambiguous, (e.g., may mean 0 or may mean "I don't know") then the second bullet above applies, and you may want to autocorrect in the field when focus is lost.
Of course, if your users vary in how they need to have a data type formatted, then you can have different variants of the app that display the data type in different ways for different user groups, or you can make the format of the data type a user preference, but that’s really another issue.
If the user wants it, and the Stakeholder ask for it, then is perfectly safe.
Trimming is very common. and the replace is common when you are talking about filling textbox with numbers. (a 0 instead of a blank).
It's a fairly standard feature, especially the whitespace trimming. The default value replacement raises a larger flag just because it is less common.
I'm pretty sure that I've seen versions of Microsoft Office that do this - putting "pt." after a value in points, for instance. Microsoft's endorsement should be a good sign.
We have quite a few of these kind of requirement. The reason given for forcing a default value rather than a blank space is that it looks better in reports or if the client wants to see the live system. A blank looks a bit like "couldn't be bothered to enter anything". For a similar reason, we often upper-case the text for consistency as the users never use consistent formatting.
"A centenarian is a person who has attained the age of 100 years or more." - Wikipedia
There are several ways to prompt a user for Date of Birth, but let's say we've chosen the drop down method.
How would you handle the oldest selectable date? Do you pick an arbitrary year (such as 1875) and populate to present?
Or, do you consult some resource for a record breaking age (Jeanne Calment, age 122), add a couple of years, and populate backwards?
Why not a text input box where they type in "1899" or whatever? When it is received you can validate that it is a legitimate number based on whatever criteria you use. I get annoyed by listboxes to select year of birth, because listboxes should not have that many values in them.
Rereading the question, you are assuming that listbox is the only option. In that case, 130 years ago seems like a good enough cutoff to me. If you're worried that the next world-record breaker will happen to be using your system, why not go with something like 200 years ago. Although I'd still say you should just use a text box.
As you're going to have to perform server-side validate the input regardless of the control used, why not use a standard text input?
`<input type="text" maxlength="4"/>
This:
Eliminates the centenarian problem.
Easier to use, especially for older individuals (Assuming the list is in descending order).
Smaller page size (don't need to include 100+ <option>....</option> tags.
If you must use a <select> box, I agree with your Wikipedia methodology. Ceiling the age of the oldest recorded person (126 -> 130 or 140) would be fairly risk-free.
It depends I think. Are you creating an application for young people?
If the application needs to be accessible for everyone, just create a configurable check and update it now and then. Look at http://en.wikipedia.org/wiki/Oldest_people#Ten_oldest_people_currently_living for the oldest possible date.
A date picker is preferable, don't use irritating listboxes with 100+ values.
My opinion on data entry like this is to cater to the user, not the programmer.
While, yes, a drop-down causes the least error handling, it's also tedious for the users.
Go for text entry that you need to validate. More code is needed in the back [allowing for both 2 digit years and 4 digit], but it's an easier experience for the user
If you want to stick to drop downs, just pick an old enough date. Personally I think drop downs are bad both for the user and you. I find selecting my birthday from a list of hundred numbers annoying (even though firefox lets me select the date by typing it). But also I think a selection makes people tend to input fake years more than if they had to type it in.
If you can live with Javascript, a Combobox might be the best of both worlds. You can list 100 years in the list, and let older people type. This only has minor ethical problem, i.e. you purposefully make elderly people type =)