User interface improvements

What action are you looking for from me? I am currently focused on functionality rather than UX because there are still things not working as they should. I am certainly open to UX improvements if you want to propose them.

I am certainly open to UX improvements if you want to propose them.

Great! Our goal is to:

• Not waste time implementing a bad UI idea, or a UI idea that will cause functional problems.
• If we spend time implementing a good UI idea, we'd like for it to end up in the Date module, rather than in a bunch of hook_*_alter() implementations within a Drupal Gardens specific module.

I think these are our current questions for you:

• According to http://cckdate.drupalgardens.com/media/806, at one time, the Date or Calendar modules automatically installed a Date node type. Noyz suggests to not do that. I just tried installing Date 7.x-2.0-alpha1 and Calendar 7.x-1.0-alpha3, and they don't install a Date node type. So maybe this is already "solved". Or do you plan on reintroducing a Date node type?
• Do you have any feedback on the suggested UI for Date field settings reflected on http://cckdate.drupalgardens.com/media/816? Specifically:
  - Move "Granularity" above "To Date".
  - Reword "Granularity", "To Date", and "Time zone handling" titles.
  - Change "Granularity" from multiselect to a row of checkboxes.
  - Change "To Date" from a 3 option select to 2 checkboxes, where the second one only becomes visible if the first one is checked (via #states).
  - Change wording of "Time zone handling" options.
  If we submitted that as a patch to Date, would you be open to accepting it?

Feel free to look over the rest of http://cckdate.drupalgardens.com/, but I have some questions myself on what is being suggested in the bottom row, that I'll try to hash out with Noyz. Once I do, I'll add a comment here with more questions, but if you have time to answer the above, we'd much appreciate it. Thanks!

According to http://cckdate.drupalgardens.com/media/806, at one time, the Date or Calendar modules automatically installed a Date node type.

I am pretty sure date does not do this (at least I am not aware of it). This MIGHT come from Date_Tools, which is a helper module to help people automatically set up a content type, date field, and calendar view... I don't use date_tools much; I prefer to do it the 'hard way' ;-)

Here are my comments on the rest of your proposed changes (screenshots):

Module Page:
Just adding a configure link - I'm not real sure about this. D7 has most of Date's configuration settings in core now, so it really does not add any configuration settings. Also, it could point to either admin/config/regional/settings or admin/config/regional/date-time.

Content Type Page:
See above, I don't think anything needs to change here.

Manage Fields:
I am not sure what you mean or have in mind here.

Global Fields:
I like the granularity checkbox idea. BUT, granularity must include all coarser settings too. For instance, you cannot check year & day. You must check year & month & day.
I am not clear about your proposal for the 'date field timezone' options. See here to make sure you understand what effect the options have: http://drupal.org/node/767182. But, I do agree that these options could use better descriptions.

Field Settings
This looks really nice to me and clarifies some things I was even fuzzy on.

Date Selector
I assume this only applies to the jquery pop-up selector widget...
This looks interesting to me, but needs some work/discussion. Combining the date & time into the same text box looks nice, but I don't really like the jquery time selector at the bottom of the pop-up calendar. Developer-x implemented a really nice time picker that I like better: http://drupal.org/project/datetweaks.

Thanks for your initiative. Going forward, I think we should split each of these improvements into separate issues. Much easier to divide & conquer.

I got here via @Noyz's tweet. There are a couple of things I'd like to say about the UI proposals:
1) If you need a form element description, your element title sucks.
2) IF YOU NEED A FORM ELEMENT DESCRIPTION, YOUR ELEMENT TITLE SUCKS.
3) If you managed to get to step 3, the element might actually need a description.
4) Give the "Year" checkbox a required marker rather than saying it's required in the description. This way the entire description can simply be left out, because the rest should be covered by the title, which should just be "Granularity", because the user knows it's about dates and collecting them already.
5) Same goes for the '"End" date' field. Why is "End" written in double quotes? First of all those are for quotations. Second of all I think the concept of start and end dates is hardly something that needs to be explained to most users.
6) Rename "Required" for the end date field to "Require end date". It's not about the field, but about the value. It also makes it easier to manipulate the form, as we don't use its position underneath the end date checkbox to tell it's about that field.
7) I'd try to get rid of some fieldsets. Some look like their contents don't even need to be wrapped. Others look like good candidates for vertical tabs. The reason is that nested fieldsets can make users experience the page as too jumpy.

I may seem a bit harsh, but I'm not trying to burn your plans down, Noyz. I love the improvements you suggested and my comments are based on the UX improvements that have gone into D7, plus my personal experience with copywriting.

I admit my first three comments were blunt and probably don't make much sense outside my head. I guess I made assumptions I shouldn't have. The thing with element titles and descriptions is that a lot of developers (including yours truly) tend add descriptions for the sake of descriptions or add too much text to them to make absolutely sure the user gets what the element is about. The key with form elements usually is to keep them simple. If you think you need a description because the title isn't clear enough, you usually need to rewrite the title rather than add a description. This is often an iterative process, hence the three steps. The "it sucks!" was not a comment targeted specifically at your mockups, but a general guideline.

Example
Look at the date granularity element. There are a number of checkboxes that would probably make the user think it's about configuring the date format. I'd remove the description and change the title to something like "Date elements to collect". "granularity" might be too much jargon and if you add a required marker to the "year" checkbox, that's communicated to the user as well.
The time zone element has a description that is already covered by everything else. Its title says it's about the time zone and the entire page is about configuring this particular date field already.
The "End date" field doesn't need a description either. We all know that events start and stop at a certain date and time (common knowledge), so we don't need to explain that. The concept of duration can be useful, so what about removing the description and changing the title to "Collect an end date (for calculating duration)" or something similar?

Example 2
The "Date format" element has a description that says exactly the same as the title (what it's about) and the element (which requires you to select rather than enter something) combined.
Default values are common in Drupal as well, so we don't have to explain what default means for every element that configures such values. Therefore the descriptions for "Default Start date) (why the capital "S"?) and "Default End date" can be removed as well.

I agree with the "To date" issue you raised. English is not my primary language, but I assume (not always a good thing) that "End date" as a whole doesn't have any other meanings than the date something ends on?

About "Required" being a Drupal pattern, can you give me examples? It's not a big issue here, but the reason I suggested this was to make sure the UI still makes sense without JS and CSS (it can happen, but not that often).

Fieldsets are tricky. Developers are encouraged to avoid nesting them, but most of them in these images are from Field API. What if we remove "Default formats & values" as a wrapper or is that a Field API fieldset as well?

Love the calendar picker improvements. We have to see if moving the timepicker on to the calendar will actually work.

One screen is an earlier version of what we talked about that got updated later. The screen that has 'Administrator date format' and 'Add a time buffer' is the one I thought was a total misunderstanding of what the settings were supposed to be doing. The ones that use the terms 'Choose how users enter dates' and 'Choose how users enter time' are the ones I thought we ended up with instead.

Making the year back/forward into a drop-down selector means we have to limit the options. I happen to know there are people using values like '-100' in that field. Also the current format allows you to swap in a hard-code year instead of a relative year, so you could use something like '1980:+10' which means 'go back to 1980 and go forward 10 years from now'. We would lose a lot of flexibility by forcing a limit list of options in there, plus people already using this have values that would no longer work. I know the '-99:+99' format is not totally clear, but it is useful and flexible and there is validation that tells you if you put the wrong thing in it.

Removing the 'delete' button means this field will look different from all other fields. That is a Field UI issue. I don't want to be responsible for creating a field that doesn't have the same options other fields have.

Other than that, I like these changes and they make sense. I'm all for making this easier to use.

I am not a fan of the time picker below the calendar thing.
It goes against a lot of pre-existing conventions. Outlook, Google calendar, and most other mainstream date/time pickers use a two part pop-up field: one text field with pop-up grid for date & one text field with pop-up select list for time.

I am a REALLY big fan of the Date Tweaks module, which formats a date field with time in exactly this way. See attached screenshots.
I am using it, and it works very well, and it is more intuitive to end users IMO.

Also, I think you are confused about the field's data type setting (Type of data to store). They are all essentially the same thing, but in different storage formats.
Currently (and I could be wrong about this):
'Date' means an ISO formatted date & time value. Note that this CAN include time.
'Datetime' means the database's native date & time format (often the same or very similar to the 'Date' type, I think)
'Datestamp' means a unix format date stamp (e.g. and integer value representing the number of seconds since January 1, 1970 IIRC)
Check out this page for the handbook explanation: http://drupal.org/node/262066

But, I really like where this is going. Definitely a good thing to put some effort into usability in something as complex as dates.... No one realizes just how complex dates really are until they dive in. It takes a lot of effort to reduce that complexity into something intuitive without actually compromising on the power and flexibility of dates.

Some more common examples of date & time pop-ups (see attached).
Note the "All Day" checkbox in both Outlook and Expedia. Date Tweaks module also supports this "All Day" checkbox.

I'm starting on a patch to implement the parts of this that seem to have reached consensus, and I'm wondering about "Default Display" - did it move somewhere I'm not seeing it?

I talked to Jeff about this and here's a skitch of where we ended up.

I'm thinking it would be easiest to keep this as a meta-issue and post actual patches for incremental changes in separate issues, linked here. Does that seem okay?

Keeping this as a meta issue is fine, and the screenshot in #16 looks good.

I'm not sure what happened to 'default display' in the new wireframes, but maybe it's not necessary in the current code, since you will set the display in the formatter.

For those following along, we are in the process of following Karen's suggestion in #17 and removing the default display setting altogether from this page (i.e., the "Choose how users view dates and times" option from the screenshot in #16 will no longer be there, since it duplicates the field display settings functionality).

As a consequence, I tried to transfer those design ideas to the field display settings instead. For more details (and screenshots), see #1198320-6: Implement UI improvements to field settings page

New implementation issues:

#1215686: Change name of date field types
#1215738: Make granularity checkboxes horizontal

And another:

#1216996: Change the years back and forward textfield into two dropdowns and make it more intuitive

Re #13, I talked to Noyz about adopting the dropdown timepicker from Date Tweaks module, and he agreed that was a good way forward, so I posted a patch implementing that at #233047-68: Switch to using Vega timepicker.

I'm going to go ahead and close this issue. Most of these things have been implemented, and further changes have been made to some so they don't match the screenshots above any more. This encompassed a ton of additional issues, many that aren't linked here. If someone wants to dig them all up and link them they can, but I think for now I will just mark this fixed.