Check out Sunrise on iOS, best mobile calendar I've found.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 13 2015
I can see what you're saying. Ideally, we have users rushing to add events, and that will result in a messy day view on mobile. I think I'd like to keep a close eye on when that happens, and respond to any feedback, by prioritizing list over day calendar. Temporarily, I, personally, find the day calendar slightly more useful.
The list view should be the default view on mobile (I would hide the day calendar on mobile outright), the day view is too complex and will look bad pretty quick unless we're really restricting the view.
May 12 2015
May 10 2015
May 9 2015
May 8 2015
Specifically, repro steps are:
Good to go now, thanks!
@mbishopim3 can you try again with my last revision for this? Changed (GMT + 12) to actually be a timezone php knows about.
I stand corrected. This still occurs for all-day events.
Not sure if this can be reproduced on your side but the first all-day event I attempted to create on our instance (it was multi-day as well) gave me an "invalid timezone" exception. Apparently "GMT+12" was attempted to be used. I went to try again and succeeded that time.
Can't forget the javascript for the time controls.
May 7 2015
Here's a more concrete description of the problem. Overall, there are several use cases for these controls:
After some discussion, the problems we want to solve are:
- Retain present number and preferably fewer date controls on advanced search forms.
- Retain capability to set relative time and make that available anywhere we have date controls.
- Set a default duration of 1 hour on all new events.
Maybe "duration mode" should be a dropdown, and we should parse durations out of "text" mode.
A third possible mode, which only makes sense on some controls, would be a "duration" mode. So you'd have: