Moving this to the 'chandler-users' list where the dogfood feedback
belongs. *Please only reply to '[EMAIL PROTECTED]'.*
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
