[chandler-users] Re: [Design] [dogfood] getting my google calendar into osaf.us

[Priscilla Chung]

Moving this to the 'chandler-users' list where the dogfood feedback  
belongs. *Please only reply to 'chandler-users at osafoundation.org'.*

Hi Brian,

First off, thanks for writing this all up! And thanks for pulling me  
aside today to go over some of the pains you've experienced with  
osaf.us/cosmo. I've started off by creating a super bug in bugzilla  
to make sure we track all this good feedback: https:// 
bugzilla.osafoundation.org/show_bug.cgi?id=8287

Then I've written up a list of things we talked about today which I  
intend to break down in bugzilla. The list should also include your  
dogfood feedback from this e-mail below as well as the following e- 
mails:
+ http://lists.osafoundation.org/pipermail/design/2007-March/006511.html
+ http://lists.osafoundation.org/pipermail/design/2007-February/ 
006503.html

Please check the following list below so that I know I have captured  
all the issues you've raised:

*Cosmo UI*
+ Support custom recurrence, ie. M, W, F but not T  Th. Currently  
support from GCal, but does allow the flexibility to make changes on  
the custom recurrence.  Would like to see custom recurrence and  
checkboxes on the UI.

+ When subscribing to a collection from someone else, when clicking  
the "+" button, sign in should allow the user to change the display  
name so it does not confuse two 'work' collection for example.

+ Currently there is a bug (BCM did you say you'll file that?) when  
adding the same subscribed collection–if the collection is already  
subscribed to the user's list of collection, but the display name has  
been altered, Cosmo detects that the same collection is being added  
and does the right thing in not adding the same collection twice. The  
issue is that once the user click 'okay', the display name is reset  
back to the original name set by the 'sharee'. Also there needs be  
better feedback to the user ie. a message dialog that a collection  
has been added to the account or not.

+ Need better instructions for feed readers who are using feed  
readers such as firefox. An additional hyperlink along w/ the URL in  
the text box would be ideal so that the user could just click on the  
link to open the firefox in a new tab/window.

+ Not enough space in the event lozenge to show the start/end time,  
time zone and summary. Do not feel the need to see tz info on every  
event lozenge on the calendar.

+ Have been a GCal user in the past and prefers the headers w/ the  
small fonts in the header and larger fonts in the event lozenge.  
Better visual distinction between the title of the event and the  
summary. Not a fan of the square lozenge and prefer wider and rounded  
corners, also found in GCal.

+ Having the event detail in 'edit mode' all the time is confusing.  
Prefer to have it be editable only when clicked.  It is common to  
have hyperlinks in the description field. If the description is  
rendered as text then URLs would become hyperlinks, and the user  
could then just click on the hyperlink opposed to an added step in  
copy/paste the URL to a new browser tab/window.

+ Prefer date/time picker then to text fields.

+ Would like to see calendar overlays for many reasons.

*Related to Admin/Account Browser*
+ Allow admin status to choose between a metrics page or calendar  
page when logging into the UI. Currently it goes to a useless blank  
page w/ a welcome note.

+ Reorganization and layout of information hierarchy of the Account  
Browser. What does each section mean? Which section is more  
important? How is   'view html' useful? Bread crumbs to go back to  
the last page. Separate buckets for files which are on the server,  
ie. atom feeds, files used for file sharing vs. event item files and  
the information associated with it. Where does the 'stamped'  
information display to show an item is stamped? –Note this is a lot  
of UI work and might have to be broken out to another super bug.

+ Subscribed collections should display in the account browser–but  
maybe only when you're an admin? Or if it's a read-write ticket. Read- 
only collections should not allow users to delete other ppls info.  
from the account browser.

Did I miss anything? After we've captured all your initial concerns  
and tracked them in bugzilla, then we'll be able to tackle them one  
by one. ;)
-Priscilla


On Mar 1, 2007, at 12:15 PM, Brian Moseley wrote:

> i'm biting the bullet and am going to try to manage my calendars on  
> osaf.us.
>
> some context: i have been using google calendar since it became
> available. i have one main calendar with 90% of my events, a calendar
> for my world of warcraft guild events, and a calendar for my movie
> club. all three calendars make extensive use of recurrence, especially
> my main calendar, which has stuff like "weekly on mon, tue, thu, fri
> ending in six weeks". i'm also subscribed to a calendar feed from
> upcoming.org and to a shared google us holidays calendar.
>
> since i can't subscribe to remote calendars in cosmo yet, i'm going to
> ignore the upcoming.org and holidays calendars. since google calendar
> can't subscribe to cosmo calendars for some reason (trying to work
> with google to figure that out), and several of the people in my guild
> and movie club use google calendar, i'm going to ignore those as well.
> so my task will be to get my main calendar into osaf.us, where i'll
> try the best i can to manually keep it in sync with google calendar.
>
> it would be nice if i could get the data from my main google calendar
> directly into my default Cosmo calendar, but cosmo doesn't give me any
> way to directly import events. so i used chandler to subscribe to my
> Cosmo calendar and then imported my google data into that collection
> and synced. i expected a dialog box with a progress bar and didn't get
> one; all i saw was the status bar saying "Syncing collection 'Cosmo'".
> i just switched weeks in the cosmo ui a lot until it looked like
> everything was done.
>
> one thing i've noticed so far is that switching weeks in the cosmo ui
> is pretty slow, on the order of 2-4 seconds. it's not clear how much
> of that time is spent fetching data from the server vs revivifying it
> into javascript vs rendering the ui updates, but it's definitely
> noticeable. and there are only 13 events this week.
>
> i also notice that for the recurring event noted above, cosmo tells me
> it occurs once, where chandler tells me that it's a custom recurrence
> "MoTuThFr every  week until 3/30/07". it would be nice if cosmo could
> at least tell me that information, even if it didn't let me edit it.
>
> this made me think that i better doublecheck that syncing to cosmo
> didn't somehow detach the occurrences of this recurring event, so i
> popped over to the account browser. the Cosmo collection page was
> pretty slow as well, as it had to add a table row for every item in
> the collection; the table is not paged or sorted, and there is no way
> to get a count of items in the collection.
>
> at this point i realized that i didn't know the uuid of the event, so
> i clicked over to the "view as html" view of the collection. this page
> has the same paging and sorting problems. additionally, there are a
> bunch of events named "Boot Camp" in the calendar, representing
> various six-week sessions spanning the last eight months or so, which
> meant i had to search through the list for the specific "Boot Camp"
> event that had the right dates. and of course the dates shown on the
> page are just for the first occurrence of the recurring event, which
> was confusing at first, cos i was expecting the period to be the start
> of the first occurrence to the end of the last occurrence. if the
> calendar detail view had shown me the uuid of the event item, then i
> wouldn't have even had to go to the "view as html" view at all. but,
> lacking that, this is a handy view for finding a specific event to
> look at its attributes.
>
> having found the specific "Boot Camp" event i wanted, i clicked "view"
> to look at it in detail, and i verified that the recurrence rule was
> indeed what i expected
> (RRULE:FREQ=WEEKLY;WKST=SU;UNTIL=20070330T233000Z;BYDAY=MO,TU,TH,FR).
> so it's just the cosmo detail view that isn't showing me the fact that
> i have a "custom" recurrence rule. that would be nice to have. it
> would also be nice if the "view as html" page for an event described
> the recurrence rule in english.
>
> taking a step back for a sec, the whole "view as html" thing needs
> some thinking. both andre and i have observed that it's handy to be
> able to see event attributes in the account browser, both at the
> collection level (a few key attributes, like summary and period) and
> at the item level (all attributes). it's also nice to be able to look
> at the icalendar representation of an event item (and probably for
> tasks and notes as well). but do we really need separate pages just
> for this?
>
> also, the "regular" collection and item pages in the account browser
> need to be reorganized. i originally built them a long time ago when
> dav was the main focus of the server, and we had a very limited domain
> model, but we've since moved to a model that more closely resembles
> chandler, and the account browser pages need to reflect this shift. we
> probably want to list every item and note attribute, including
> "unknown" ones that are not a static part of our model but are defined
> by eim or dav clients, and every stamp with its attributes. we also
> need to reorganize how we provide links (both with and without
> tickets) for all the different protocols that can access a collection.
> think about the lengths that we went to for the calendar ui's
> collection details dialog - we need something similar here.
>
> that's it for now. i'm sure i'll find more issues as i enter data
> directly into osaf.us. i'm pleasantly surprised at how easy the whole
> experience was, though. kudos to everybody!
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/chandler-users/attachments/20070306/0fb43650/attachment.htm