Re: A Maybe Help Request

Morgen Sagen wrote:
> 
> I have opened a bug to track this issue:
> 
> http://bugzilla.osafoundation.org/show_bug.cgi?id=2807

Comments from bugzilla:

> Chandler.py catches RepositoryOpenDeniedError and
> ExclusiveOpenDeniedError, and displays the "already
> open" dialog if either of those exceptions are
> raised.  Could those be being raised incorrectly?
> 
> 
> ------- Additional Comment #1 From Morgen Sagen 2005-04-04 12:45 PST [reply] -------
> 
> That dialog indicates some process still owns a lock
> on the repository files.  Please verify there isn't
> a chandler or python process running (via Task Manager, etc) and retry.

I reply:

This pops up as soon as (and every time) I start Chandler.  I
don't have any other python things running; besides, why would
some other program get a lock on the Chandler repository?

Seth

--

-- 

Backpackit

Backpackit <http://backpackit.com/> is a new web based PIM by the  
people that did BaseCamp.

The videos show a few interesting features...

----
Ted Leung                 Open Source Applications Foundation (OSAF)
PGP Fingerprint: 1003 7870 251F FA71 A59A  CEE3 BEBA 2B87 F5FC 4B42

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Design bugs with email/detail view

Today I was using Chandler email on Windows XP, and noticed something
that looked like clear bugs to me. Then I was informed that they were by
design. So now they look like design bugs to me.

The first issue is that when you have created a new mail message, but
have not sent it, clicking Sync All will not send it. Clearly I would
expect it to do so, functioning like a smart "send later".

The second issue is that the mail messages summary does not look
editable. This is totally against Windows UI guidelines. On Windows (at
least, I thought everywhere else as well), you give an edit box for text
that is, well, editable. The way it is now it looks like label text,
same as From and To which you can't edit. I really was stumped for a
while because I could not see any way to give a summary for my email! I
was told Apple Mail.App works like this, but it feels broken for the Mac
as well.

--
  Heikki Toivonen

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Re: Backpackit

Hi Ted,

Thanks for posting the backpack PIM link.  It looks
like an interesting product.  There are some very
useful features that Chandler could re-mould for it’s
own usage such as the email reminders that could be
built into Chandler’s Datebook alarm system.  I also
like the free form features where memo’s and ToDo
lists can be applied as needed an then organized
according to the user’s thoughts.  However, I don’t
like the web based nature of the app.

Most web based applications other than email have not
been very successful with mainstream PC or even Mac
users.  This is especially true with web based PIM
apps.  There have been many attempts but AFAIK none
have ever gathered significant mainstream usage
including Apple’s iCal.  I’m not sure why this is but
I can speculate that three important reasons might be
as follows:

1) Compromise of bandwidth speeds during peak traffic
times.

2) Lack of access to web when away from home / office
unless one is willing to pony up an extra $10 or so
per month for data access connection on their
smartphone or PDA which many are just not willing to
do.  

Re: Backpackit

selva r wrote:

> Most web based applications other than email have not
> been very successful with mainstream PC or even Mac
> users.  This is especially true with web based PIM
> apps.

my experience building a web-based PIM app in the late 90s 
tells otherwise, given the millions of accounts (consumer, 
isp, and enterprise) that my company had under management.

of course, the web application was only part of a larger 
ecosystem which included standards-compliant desktop and 
mobile device applications and servers, offering the widest 
amount of choice to the user.

osaf is following this same path with the chandler (desktop 
app), scooby (web app) and cosmo (server) projects. so i'm 
curious as to why you devoted so much effort to lecturing 
about the badness of web apps :)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Re: Design bugs with email/detail view

Thanks for your feedback Heikki, please see below for in-line 
comments...

On May 5, 2005, at 4:52 PM, Heikki Toivonen wrote:

> Today I was using Chandler email on Windows XP, and noticed something
> that looked like clear bugs to me. Then I was informed that they were 
> by
> design. So now they look like design bugs to me.
>
> The first issue is that when you have created a new mail message, but
> have not sent it, clicking Sync All will not send it. Clearly I would
> expect it to do so, functioning like a smart "send later".

Sync All should send email that you've hit the Send button on. 
Essentially, queued up email that's ready to go. It shouldn't send 
unfinished Drafts however. I'm not sure if we have a notion of  "queued 
email" in the content model.

>
> The second issue is that the mail messages summary does not look
> editable. This is totally against Windows UI guidelines. On Windows (at
> least, I thought everywhere else as well), you give an edit box for 
> text
> that is, well, editable. The way it is now it looks like label text,
> same as From and To which you can't edit. I really was stumped for a
> while because I could not see any way to give a summary for my email! I
> was told Apple Mail.App works like this, but it feels broken for the 
> Mac
> as well.

Re: Backpackit

Brian Moseley wrote:
> selva r wrote:
>> Most web based applications other than email have not
>> been very successful with mainstream PC or even Mac
>> users.  This is especially true with web based PIM
>> apps.
>
> my experience building a web-based PIM app in the late 90s tells
> otherwise, given the millions of accounts (consumer, isp, and
> enterprise) that my company had under management.

Chandler design has always been with the idea in mind that you don't
want to share (=upload to server) all of your PIM data to be accessible
to everyone.

There are several levels one can go to, depending on trust assigned to
the server(s) as well as options and implementation details.

Typical usage (afaik) would see you maintaining the majority of your
data in your desktop Chandler application, or in a Cosmo server you
maintain yourself. You would then allow a limited set of people to view
some collections of your data by setting ACLs. Connections to the server
 would be over SSL. For example, maybe you will only allow other people
to set appointments with you, and you would just share information about
your calendar as to when you will be available/unavailable.

A paranoid user would share (upload) the data to server in an encrypted
format, although implementing this last piece is on a wish list status
at the moment. There are some technological hurdles, as well as
practical experience pointing to some pitfalls in this approach.

Re: Backpackit

Heikki Toivonen wrote:

> Chandler design has always been with the idea in mind that you don't
> want to share (=upload to server) all of your PIM data to be accessible
> to everyone.

putting your data on the server doesn't equal making it accessible to 
everyone. cosmo's default security policy is to protect your data from 
everybody and let you make the decisions about who can access it (by 
setting acls and/or passing out tickets).

> Typical usage (afaik) would see you maintaining the majority of your
> data in your desktop Chandler application, or in a Cosmo server you
> maintain yourself.

i wouldn't character that as typical usage, but rather one of several 
common scenarios. others are:  corporate workgroup server, 
public/community server, university faculty/staff/student server.

the fact is that most people in the world aren't paranoid, or even 
terribly security-conscious. we need to cater to those people too.

in any event, scooby is there for people who want web access, and 
chandler is there for people who want desktop access. we're doing the 
right thing providing the choice.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Re: Design bugs with email/detail view

Mimi Yin wrote:
>> The first issue is that when you have created a new mail message, but
>> have not sent it, clicking Sync All will not send it. Clearly I would
>> expect it to do so, functioning like a smart "send later".
>
> Sync All should send email that you've hit the Send button on.
> Essentially, queued up email that's ready to go. It shouldn't send
> unfinished Drafts however. I'm not sure if we have a notion of  "queued
> email" in the content model.

Good point. Not sure what to do about the draft status of messages yet.
Need to think some more.

>> The second issue is that the mail messages summary does not look
>> editable. This is totally against Windows UI guidelines. On Windows (at
>
> The type-over text feature will not be fully implemented in .6...so
> we'll be living in an awkward partial implementation for now. In the
> full design, all text fields will have the type-over-text look with grey
> hint text. The text will sit on a flat, white background and "activate"
> when the user clicks on the grey hint text.

I hope you just described a common text edit control with editable text.
The one part that seems a little uncommon is the grey text. Seeing that
I would expect it is something I don't need to touch (optional field).

> I'd like to try experimenting with some non-standard "form" designs
> given Chandler's attribute-intensive detail views. Currently, we're
> looking at 18 fields in the detail view, just for the basic PIM: From,
> To, CC, BCC, Date, Subject/Title, Location, All-day, Start date, Start

AW: Design bugs with email/detail view

>> I'd like to try experimenting with some non-standard "form" designs
>> given Chandler's attribute-intensive detail views. Currently, we're
>> looking at 18 fields in the detail view, just for the basic PIM: From,
>> To, CC, BCC, Date, Subject/Title, Location, All-day, Start date, Start
>> time, End date, End time, Timezone, Event status, Recurrence, Recurrence
>> ends, Alarm, Notes, Collection membership
>
> Careful with non-standard design: accessibility relies on common
> controls and functionality.

>> I'm looking for ways to:
>> a) break up the visual monotone of having such a large number of fields
>> by visually grouping fields by Kind and emphasizing certain fields over
>> others (ie. Subject).
>> b) make the detail view less intimidating
>
> Yes, I can certainly see this needs some thought when we have multiple
> fields.

Having worked both in companies with Windows and Mac computers, I have
definitely come to appreciate the simple and very clear layout of OS X
calendar / mail / addressbook apps. They provide a very good and slim
overview of my personal information, whereas almost anything in the windows
world looks to my eyes more complicated than it could be.

When I first came to the Mac-based company, I was not used to Mac OS X
controls at all. Within less than 5 minutes I got accustomed to them, since
their simple and concise way of working seemed quite intuitive and reminded
me of browsing through the web.