- This topic has 15 replies, 2 voices, and was last updated 13 years, 4 months ago by
.
-
Posts
-
The new capability in the current trunk version to step location map displays back and forth day-by-day, week-by-week, or month-by-month is working well; except that users have no way to know the date-range of the map location markers they are viewing. Furthermore, the navigation arrows may not be noticed or their function may not be obvious, especially if the map size is large, because they display below the lower-left corner of the map.
I suggest moving the arrows above the map (or both above and below) and displaying the map data time-period between them, as follows:
For the case of daily data:
The date displayed in a format that can be specified on the Event Manager Options page.
For the case of weekly data:
Starting and ending dates displayed in a format that can be specified on the Event Manager Options page.
For the case of weekly data:
Month and year displayed as at the top of the EME full-calendar or even better as specified on the Event Manager Options page.
Ok, implemented something like this in trunk (and corrected the weekly period paging thing). Do try it out (for day format: general settings taken into account, for month format: EME option taken into account, for week format: scope shown)
Great! I will be gone the rest of today, but will test it early tomorrow.
So, far I have tested only the monthly map location data option. A map showing January event locations displays with the following above and below the left edge of the map.
<< December,2010February,2011 >>
The dates incorrectly imply that the map shows event locations over a three-month period.
A date separator should be used if starting and ending dates are going to display, e.g. “January 1, 2011 through January 31, 2011” or “January 1, 2011 – January 31, 2011”. However, it would be better to simply display “January 2011”.
It would look nicer to center the navigation-arrow/date string sets horizontally above and below the calendar, rather to have them left-flush with the map edge as they are now.
I just added the following to eme.css:
div .entry-content {
text-align:center;
}That makes the existing code display as shown below, which is great and even better than what I suggested above, except that there should be spaces after the commas.
<< December,2010 February,2011 >>However, that has the adverse side-effect of centering the location list below the map.
Adding the following CSS instead avoids that problem, but necessitates the additional use of “clear:right” on the location list below the map.
a.eme_nav_right {
float:right;
}The dates of the month indicate the previous/next month (idem for week/day), not the current one being displayed. Have you updated your event_manager.css file as well? Well, maybe it would be better to indicate what’s being displayed now, something like:
<< previous month Jan, 2011 next month >><< previous week January 2, 2011 -- January 8, 2011 next week >><< previous day Jan 2, 2011 next day >>I can’t take the calendar into account: not everybody has a calendar on their page.
I edited my post above while you were posting. Please see what I wrote there.
I updated “event_manager.css” if the latest file was included in the trunk package downloaded about an hour ago.
The css in trunk had a small error, this is what should be in there:
#locations-pagination-top,#locations-pagination-bottom,#events-pagination-top,#events-pagination-bottom {
text-align: center;
}
#locations-pagination-top a,#locations-pagination-bottom a,#events-pagination-top a,#events-pagination-bottom a {
margin: 0 20px 0 20px;
text-decoration: none;
padding: 3px 0;
}
.eme_nav_left {
float: left;
}
.eme_nav_right {
float: right;
}And the “spaces after the comma” thing: check your eme setting “Monthly period date format” (it lacked a space, added in trunk).
Still, I believe my previous comment stands: the current period should be displayed, not the previous/next ones. So I’ll change that in te code later on.
NOTE: These comments apply to the code downloaded earlier this morning. I haven’t tried the code you just uploaded.
I corrected “event_manager.css” to what you posted above. That properly positions the arrow/date sets. However, it causes the event list below the map to display incorrectly. The following addition fixes that problem.
#eme_locations_list {
clear:both;
}You wrote: “Still, I believe my previous comment stands: the current period should be displayed, not the previous/next ones. So I’ll change that in te code later on.”
Even though that is what I originally suggested, I like the way it is now. The best option with a large map size like I have would be to display the current period in the center with previous/next periods on either side. However, there won’t be space for that with small maps unless a small font size is used.
I just tried your latest version. It looks and works great the way you have it now. My only suggestion is to bold the current time period displayed in the center, but that of course is something uses can do themselves if they want.
CORRECTION to what I just posted above:
I had the following in my eme.css file when I ran that test:
#eme_locations_list {
clear:both;
}Your latest version doesn’t lay-out the event list below the map correctly without that CSS.
You wrote: “And the “spaces after the comma” thing: check your eme setting “Monthly period date format” (it lacked a space, added in trunk).”
Yes, that was the problem. I added a space in the “Monthly period date format” and the display is correct now.
A bit weird that it needs that, I don’t see the CSS dependency … but you’re right, if not the first element in the list is off. So, added to the general css file in trunk.
The issue isn’t due to CSS dependency. It is due to the way floats work. Content following floats is, by default, placed to the right of a left-float and/or to the left of a right-float. That default behavior can be changed by “clear” styling. “clear:left” forces following content to be positioned below a left-float instead of to it’s right. “clear:right” forces following content to be position far enough down to clear a right-float. “clear:both” forces following content to be positioned low enough to clear both left and right floats, even if one is taller than the other.
- The forum ‘Bug fixed or feature request implemented’ is closed to new topics and replies.