[Building Sakai] Sakai DateTime Picker

[Matthew Jones]

I have filed and fixed this as the default for 11, since I don't see any
disadvantages. I'd consider it worthwhile for 10. I don't think just
assignment would benefit.

https://jira.sakaiproject.org/browse/SAK-27733


On Tue, Jul 29, 2014 at 8:23 AM, Bryan Holladay <holladay at longsight.com>
wrote:

> I think adding the dropdown options in the datepicker would be just
> fine... any objections?  Should this be a default option or just for the
> assignments tool (my vote is default)?
>
> -Bryan
>
>
> On Tue, Jul 29, 2014 at 12:14 AM, Matthew Jones <matthew at longsight.com>
> wrote:
>
>> Portal already uses mobile esp (via mobile detect library) and puts a few
>> variables into the context (mobileDevice and mobileSmallDisplay). So
>> detecting whether or not it's mobile I don't see as a problem.
>>
>> I'd consider the bigger problem that without the popup date time picker
>> what format are people going to put the dates in. It can't possibly support
>> parsing every possible date time format in the backend and the popup helps
>> restrict and guide what people input.
>>
>> Though you mention that it works but the only inconvenience is changing
>> the year, it looks like there's options for that in the existing date
>> picker that just aren't enabled and are easy to switch on. Sounds like a
>> good default to me.
>> http://jqueryui.com/datepicker/#dropdown-month-year
>>
>>
>> ​
>> And there are also better looking date pickers for mobile in the jquery
>> mobile project. Having them all consolidated into one makes it easier to
>> detect and switch. (if interest and dev time were available)
>>
>> A few jQuery Mobile specific date pickers here:
>> http://dev.jtsage.com/jQM-DateBox/
>>
>>
>>
>> On Mon, Jul 28, 2014 at 9:33 PM, Bryan Holladay <holladay at longsight.com>
>> wrote:
>>
>>>  I had an instructor come up to me today and ask why she couldn't just
>>> type in the dates when changing the open/close dates in her newly imported
>>> assignments (it was annoying to her to have to click "next month" 12 times
>>> instead of just updating the year).  I wasn't expecting the datetime picker
>>> to work this way, but it does and does so apparently for mobile devices.  I
>>> understand why you wouldn't want to show the keyboard on a mobile device,
>>> but I don't know why you'd want to disable keyboard inputs for non mobile
>>> computers.  Is there a simple way for the JS file to know whether the
>>> device is mobile or not already inside Sakai's JS API?  The SO solution is
>>> just a long REGEX check:
>>> http://stackoverflow.com/questions/11381673/javascript-solution-to-detect-mobile-browser.
>>>  I think we should not have the input disabled by default unless proven to
>>> be a mobile device.  Thoughts?
>>>
>>> Here is the datetime picker JS code:
>>>
>>>
>>> https://source.sakaiproject.org/svn/reference/trunk/library/src/webapp/js/lang-datepicker/lang-datepicker.js
>>>
>>> // disable the input field on show as to not display a tablet keyboard
>>>
>>>  cfg.onClose = function(dateText, inst) {
>>>
>>>  $(this).removeProp("disabled");
>>>
>>>  };
>>>
>>>  // re-enables input field
>>>
>>>  cfg.beforeShow = function(input, inst) {
>>>
>>>  $(this).prop("disabled", 'disabled');
>>>
>>>  };
>>>
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to
>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>> "unsubscribe"
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20140729/6a92f28e/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: calendar drop.png
Type: image/png
Size: 18634 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20140729/6a92f28e/attachment.png