[dev] Kronolith category/color patch, per user

Kevin Myer kevin_myer at iu13.org
Mon Apr 25 13:58:50 PDT 2005


Quoting Chuck Hagenbuch <chuck at horde.org>:

>
> I think something else is the root issue here. I say this because my
> direct experience (which is admittedly with fewer users, but my wife is
> a pretty sharp beta tester <g>) is that showing the user's own colors
> is what the user expects.

My experience is that showing the user's own colors is what they expect, for
_their_ events.  For other users, they would expect to see _something_ to
indicate that its not their event.  And since each category has a color,
category == color, and I'd expect to look at a color and determine what the
category is, from a calendar shared between multiple users.

You can't rely on the Event Name, unless you make a massive set of rules that
you need to supply a prefix to all events.  You can't rely on using your own
colors for your own categories, because then you lose the ability to visually
tell which user an event belongs to, if you have the same categories, and if
you don't have the same categories, you get white events, with orphaned
categories in the legend.  Side-by-side shared mode works for a limited number
of calendars, over a short span of days (day - week mode, but not month).

> I think you're looking for an easy way to tell visually who an event
> belongs to, or at least, whether or not it belongs to *you*. Is that
> right? I think the color-based way you're proposing overloads the
> meaning of categories bit - a category is a category, if your Vacation
> events are really in a different *category* than your coworkers, then
> they should be a different category, not one with the same name. Also,
> I think this would break down in larger environments very quickly - I
> have 10 differently-colored vacation events, who's that? Am *I* on
> vacation? I don't know! ;) (also, people can still pick the same
> colors, especially in larger numbers).

Yes, amongst 1400 users, there are some who are bound to pick the same 
colors. But in my team, and in most teams, we're small enough, and 
cooperative enough
that we can pick different colors.  I have to work on whether or not my colors
are complementary to my co-workers colors but .. :)  I only use two Categories
myself - Business and Personal, while some people may go Category crazy 
and use
ten different Categories.  We all organize and work differently and should be
able to continue to work that way.  The issue is how we display and visually
communicate those differences.

I"m trying to think of a clever logical way to explain this :)  Vacation days
are a good example of why we run into problems with the current Kronolith
behavior (IMO).

User 1 (A)
User 2 (B)
Event 1 (Vacation)
Event 2 (Vacation)
Category 1 (Business)
Category 2 (Vacation)
Color-Category 1 (Red)
Color-Category 2 (Green)

So what do I need to visually indicate that User 1 -> Event 1 -> with 
Category 1
and Color-Category 1 is different than User 2 -> Event 2 -> with 
Category 2 and
Color-Category 2?

I could:

1) Include the username with the event name (A or B + Vacation).

- bad idea, since the user name has the potential to take a lot of screen real
estate.

2) Require everyone to adhere to standards for entering events - prefix event
names with your initials, for example.

- bad idea, rules are hard to follow, generally get broken, and its all about
choice.

3) Use the current Kronolith implementation, which is to display the 
event name
(Event 1 or Event 2), use a category Legend that displays Category 1 and
Category 2, but only use Color-Category 1 and Color-Category Default of 
User 1.
If Category 1 == Category 2, treat the event, visually, like its your event.

- why I wrote the patch :)  Because this breaks down when you start to share
multiple calendars across an organization.  The Vacation example is a simple
one.  What about a default, organization-wide shared calendar, with Holidays
(U.S. Observed, and organization Holidays, or Special Events)?  The maintainer
of the calendar chooses three Categories.  If any are the same as your
categories, they show up with your color.  If they are different, they are
tacked on in an unfiled color, and the category is displayed in the legend.

4) What my patch does.

- doesn't work if Color Category 1 == Color Category 2, but then nothing will,
except including the owner's name.  Solution is to be amicable with your
co-workers and choose different colors amongst your team :)

> What would you think of coming up with a visual indication (something
> in the border, perhaps, paired with a title= notation for non-visual
> users) of whether the event is owned by you or not?

Yes.  Using an individual's colors and categories does this, as well.  
Putting a
border around events that aren't yours does it too, although not the degree of
granularity that using that individual's colors/categories does.  But 
if you're
going to do that, get rid of displaying _all_ categories that aren't yours in
the legend.  If Category 1 == Category 2 for User 1 and User 2, only display a
color if the event is owned by User 1, otherwise it gets a border, even if its
the same category.  And to do that, you need to keep track of who owns each
event, so you might as well just display their colors too :)

> That leaves categories just categories, and I *think* gets at what you
> want. Let me know if this sounds right.

I'm not sure that I see how what I'm doing is making categories anything more
than categories, by incorporating color into it.  Actually, I think it just
dawned on me where the issue is.  I think its a good idea to have some visual
indicator of events that are shown that are not yours.  I use the individual's
category/color for the event, you're suggesting a border, but basically, it
amounts to the same difference.  You're seeing it as an overload to display
each user's categories in the legend, because they might be a category-crazy
user (which is one of the reasons in my patch that the legend only 
displays the
categories for events that are display - if each user has 100 categories, but
only one event that shows up on your calendar, the legend will only 
display one
category/color for that event).

I see it as vitally important to know what category an event belongs to, in
certain situations, at least.  For example, we have someone doing 
scheduling on
other users' calendars.  There are laws we have to comply with that mandate a
maximum number of children that a physical therapist may see in a 
week's time. So its important to see that not only is the event for 
another user (through
borders, or colors) but also what category the event is, so as to not exceed
the maximum number of children per week (are we looking at paperwork time,
travel time, a physical therapy session, and ultimately, can I cram 
another kid
in on the schedule? :).

And, at times, its helpful to overlay two therapists' calendars, to determine
the best therapist to assign the kid to.  If we assume that each therapist has
three categories - Therapy, Traveltime, Paperwork, and that those categories
are visually communicated to a scheduler, the scheduler can make more
intelligent decisions about who's schedule to put the kid's physical therapy
session on.  Because again, we have to juggle things like state law, which
dictates the maximum # of kids a therapist can see per week, along with
practical issues, like the fact that it takes time to travel from Site A to
Site B, with contractual issues, like the amount of time allocated to staff to
do paperwork.  The easier I can make it on the person doing the scheduling, by
providing visual cues, or at least a legend with accurate category colors, the
better.

So I think there are two issues I wish to solve - is the event mine?  If the
event is not mine, whose event is it (and what kind of event is it)?  You're
looking only at the first question, but I'm trying to address them all.

Kevin


-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org



More information about the dev mailing list