[#1238] Yearly View
Summary Yearly View
Queue Kronolith
Queue Version HEAD
Type Enhancement
State Resolved
Priority 1. Low
Owners Horde Developers (at)
Requester mbydalek (at) mobilemini (dot) com
Created 2005-01-24 (5171 days ago)
Updated 2005-02-01 (5163 days ago)
Resolved 2005-02-01 (5163 days ago)
Patch No

2005-02-01 23:13:44 Chuck Hagenbuch Comment #16
State ⇒ Resolved
Reply to this comment
Okay, that patch is committed. I'm going to resolve the ticket now - 
there are a few nits, like I wouldn't show days in multiple months - 
no point since you've got all of them there - but those can be 
addressed over time on the lists. Thanks!
2005-02-01 20:37:26 mbydalek (at) mobilemini (dot) com Comment #15
New Attachment: year-tooltip-bg-patch.tar.gz Download
Reply to this comment
Okay, here's the patch to run against HEAD to see the DB 
optimizations, adding of the tooltips, and changing the year-event 
style to something more visually appealing than that aqua green color 
(who knows where I got that from!).

Also, I took out highlighting 'Today' for 2 different months.  So say 
today (Feb 1) is on the Jan. and Feb. month, it'll just highlight the 
Feb.  It looked goofy otherwise.

Overall, I think it's pretty complete. If there's something I missed, 
just let me know!
2005-02-01 19:33:34 Chuck Hagenbuch Comment #14 Reply to this comment
using the category color isn't going to fly. There should be a css 
class for days with events, which I believe there already is? And then 
themes can do what they want.
2005-02-01 19:23:55 mbydalek (at) mobilemini (dot) com Comment #13 Reply to this comment
The "random and unpredictable" part is what I was afraid of.  There's 
nothing wrong with just bolding the events, but to me, it's kinda hard 
to spot the bold in the bunch for some reason, hence the color.  If 
you wanted a quick view of what your year looks like, using a color 
background would be nice.

How to implement it, I'm not sure.  If you really feel against it, 
just let me know and I'll yank it and provide a final patch.   
Otherwise, any ideas you may have to standardize it would be great! :)
2005-02-01 19:09:15 Chuck Hagenbuch Comment #12 Reply to this comment
I think the category color idea is nice, but it's going to be too 
random and unpredictable in practice. What's wrong with just bolding 
the date, like the month block does?

Also, you should definitely hit the database only once for the year - 
will cut down on recurring events being fetched and checked every time 
a *lot*.
2005-02-01 19:01:26 mbydalek (at) mobilemini (dot) com Comment #11
New Attachment: year-tooltip-patch.tar.gz Download
Reply to this comment
Here is the tooltip addition patched on what you committed.  Putting 
that one random .php file I had in templates in the year.php was a 
good idea - started off as a template, but transformed and was never 
placed right ;)

Anyways, what I did was change the background color to the category 
color of an event on the day in question.  The thing is, it will of 
course only use the color of the last event as that's how I put it in 
the loop.  Do you think that this should just be a pref instead, or 
just leave it how it is as the point is to really know what days you 
have items scheduled.

The other question I had was in regards to performance.  In the loop, 
I grab the events for month 1, then month 2, etc.  Would it be better 
to grab the evens for the entire year in 1 query, or just hammer the 
DB 12 times?

Other than that, I don't think there's much more to do with it.
2005-02-01 18:25:29 Chuck Hagenbuch Comment #10 Reply to this comment
/Much/ better! :) I've gone ahead and committed it for now. Still 
needs a better presentation of the days with events, by default, and 
I'd like to see what the tooltips do to it - we're already fetching 
all the events, so it will only increase page size.
2005-02-01 16:54:10 mbydalek (at) mobilemini (dot) com Comment #9 Reply to this comment
Just as an addition, once I get everything all done, I'll submit a set 
of patches against HEAD.  Sorry, but I feel bad for putting the whole 
files up =x
2005-02-01 16:50:24 mbydalek (at) mobilemini (dot) com Comment #8
New Attachment: year-update.tar.gz Download
Reply to this comment
The month block was perfect!  Take a look at this and see what you 
think. I dropped down to 800x600 and it fit/looked just fine.

I didn't create patches (forgot to make .orig's!), so just replace the 
files (unless you really want me to create patches).

The one thing I did like was the tooltip's in the block, but that may 
impact performance too much, depending on how it's done I guess.  For 
now, I left it out, but I could play with it perhaps.

I want to be sure I get the look down first, and then work on 
functionality.  As you stated, this is for seeing more information, so 
the question really is, how much is too much?

Let me know.
2005-02-01 15:23:30 Chuck Hagenbuch Comment #7 Reply to this comment
800x600 would be ideal (usable at that, anyways), but 1024x768 is a 
must, IMHO (keeping in mind the Horde sidebar as well). Using 
percentages is great, but with your current code, it simply doesn't 
fit on my laptop's screen and scrolls off to the right.

Outlook doesn't even have a year view, but all of the ones that I've 
seen use single letter weekday abbreviations. That allows for seeing 
more information at once, which is, imo, the whole point of this kind 
of view. See the month block, also - it produces a single month of 
this kind of view.
2005-02-01 15:01:52 mbydalek (at) mobilemini (dot) com Comment #6 Reply to this comment
The first comment, "This is pretty unreadable," got me thinking and 
then I realized that I run at 1280x1024 and it looked good to me!  So 
my question is, what resolution should I shoot for?  The reason I ask 
is because I have the entire table take up 100% of the width, and then 
use %'ages from there.

Should I create fixed widths-heights?  Should I nix the "Week X" as 
well?  Shortly after I submitted my original patches, I did abbreviate 
the names, but just down to Mon, Tues, etc.  But if you just want 
something like the date picker (which personally I think is too 
small), then of course it'll just have to be M-T-W, etc.

Let me know what you think.
2005-02-01 05:06:13 Chuck Hagenbuch Comment #5 Reply to this comment
This is pretty unreadable. I'd go down to single letters for the 
weekday headers, get rid of the add icons - the months should be about 
the same size as they are in the date picker. The day of the month 
should be the whole cell.

You're right that sidebyside is irrelevant in this view.
2005-01-27 21:08:18 mbydalek (at) mobilemini (dot) com Comment #4 Reply to this comment
Oops! I just realized I goofed on creating the tar.gz file.  The 
directory kronolith/year is supposed to be in kronolith/templates/year

Just FYI.
2005-01-27 21:02:12 mbydalek (at) mobilemini (dot) com Comment #3
New Attachment: kronolith.yearview.tar.gz Download
Reply to this comment
Take a look at this and see what you think.  I'm gonna stay as far 
away from art as I can, so I ended up using the 'month.png' file in 
the tree_menu.

Also, I just picked a random color to show that there is an event on 
that day.  I guess a legend or something explaining that might not be 
the worst idea.

Lastly, I didn't include any of the $sidebyside stuff as I really 
didn't see a relevance, but I could be wrong of course.  I tried to 
clean up the code as best I could, so I apologize in advance for any 
errors :)

If there's something you'd like me to change, just let me know as I 
have no problem doing so.

2005-01-27 15:40:36 Chuck Hagenbuch Comment #2
State ⇒ Accepted
Assigned to Horde DevelopersHorde Developers
Reply to this comment
I suppose that if this doesn't utterly kill performance it'd be 
doable. A patch would help it get done, though.
2005-01-24 14:59:35 mbydalek (at) mobilemini (dot) com Comment #1
Type ⇒ Enhancement
State ⇒ New
Priority ⇒ 1. Low
Summary ⇒ Yearly View
Queue ⇒ Kronolith
Reply to this comment
Would be nice to add a Yearly View to the views.   The way that Palm 
and other calendar programs do it is to just highlight the days that 
have an entry, which I think would be the best way to do it as 
actually displaying entries would be impossible.



Saved Queries