Scott Adams (Dilbert) explains why sometimes entering events (dates) can be tiring. He puts it down to too many different spatial models.
He also proposes an alternative (a one spatial model) events calendar interface.
Interestingly one commenter offers the google ‘ figure it out from the text’ method. Perversely that does not work for me. I have been influenced by my husband to get in the habit of recording the planned date and time in th text as well as in the date fields as a ‘backup’. Too many tools make it so ‘easy’ to shift an event, that it sometimes happens inadvertently…. If you haven’t recorded the original somewhere… you’re in trouble!
Any way point of the post was to give you all a place to offer any suggestions. Yes please comment meaningfully if you want to. If you like the current interface and prefer it to stay that way, please say so too. (hard to please everyone all the time, but I try)
Quite some thought did go into the current amr-events interface:
- datepicker for dates, but not a time picker (too limiting, not enough value added)
- flexible date entry if you want – it’ll do its best guess to figure out what you want rather than insisting how you should enter the date.
- flexible time entry – lots of logic to work out what you want – it is not going to insist on 10:00, you can enter just 10
- if no time – will assume all day (you don’t have to tick the all day)
- it’ll echo back the day of week to you when saved for confirmation
- in settings one choose the date and time entry format. See also date formats by country
- english oriented with dd/mm/yy
- american with that weird month first thing they do
- europeans who like to adhere to the international standard yyyy-mm-dd
- 24 hour clock or
- 12 hour am/pm
- define the separators
- Choose also the start of week (Monday, Sunday, Saturday etc)