[Design] Re: [Bug 7758] UI changes to Accounts dialog
Brian Kirsch
bkirsch at osafoundation.org
Mon Jan 22 11:17:09 PST 2007
Hi Mimi,
See comments inline.
On Jan 22, 2007, at 7:15 AM, Mimi Yin wrote:
> Forwarding a bugzilla conversation to the list...
>
> Begin forwarded message:
>
>> From: bug-comment at osafoundation.org
>> Date: January 19, 2007 5:59:07 PM PST
>> To: mimi at osafoundation.org
>> Subject: [Bug 7758] UI changes to Accounts dialog
>>
>> http://bugzilla.osafoundation.org/show_bug.cgi?id=7758
>>
>>
>>
>>
>>
>> ------- Comment #1 from bkirsch at osafoundation.org 2007-01-19
>> 17:59 PST -------
>> Hi Mimi,
>> I have some concerns about the placement of the create IMAP
>> folders checkbox.
>>
>> What must happen is that the IMAP folders are created on the
>> server for that
>> specific account before any changes to other accounts are made. As
>> such adding
>> this check on the Ok button would not work since that applies to
>> all accounts.
>
> Oh, I don't think I was intending on having the IMAP folders
> created/checked when the user hits [Okay]. Could the IMAP folders
> be created and checked when the user clicks the [Test] button?
>
In an ideal world that would be great. I could confirm that the user
selected the create folders check box and then in addition to testing
configure the IMAP account.
The issue is that one can not assume the user will click the [Test]
button 100% of the time. And as such we can not put the Create
Folders logic on the test button
unless we display some type of info to the user that says "Hey you
selected to configure Chandler folders. In order to do that you must
hit the Test button" and refuse
to close the Account Pref dialog until either the [Test] (Create IMAP
Folders) button has been clicked or the Create IMAP folders check box
deselected.
>>
>> If the user created two IMAP accounts and selected to have
>> Chandler folders for
>> both putting the logic on the Ok button would mean having to track
>> potential
>> errors for both operations and redirecting the user to resolve
>> those errors.
>>
>> That functionality is too complex to accomplish in the short
>> period I have
>> allocated for this on the Preview schedule. And would just go away
>> once we had
>> a nice GUI account wizard anyways.
>>
>> So with the current mock ups what would have to happen is that
>> once the user
>> checks the use Chandler folders box a blocking dialog would
>> immediately be
>> displayed while the folders are being configured. This is less
>> than ideal since
>> the user may decide before hitting ok not to try out the Chandler
>> special
>> folders. Once the folders are create, for Preview at least there
>> is no way from
>> Chandler to delete those folders (it would be done in the users
>> IMAP GUI
>> Client).
>
> Sure that's fine too. Or we could kick it off when the user hits
> [Test]?
>
If this is fine then lets just go with this for Preview. With out a
substantial workflow redesign, I don't think any alternative choice
is going to
any better.
>>
>> My other concern is repeat in functionality ie. An auto configure
>> is the same
>> as a test but without a username and password supplied and a
>> Create Chandler
>> folders is the same as a test but with the addition of creating
>> IMAP folders.
>>
>
> I agree it's not ideal to have so many buttons, but I think the
> differences you enumerate above are significant enough to warrant a
> separate [Test] button.
>
> We also need to account for providing users with a way to test
> their accounts after an initial test fails and they attempt to fix
> their settings. In such a workflow, it won't occur to users to re-
> click the [Auto-configure] button or uncheck and check the IMAP
> folders checkbox to re-initiate a second round of account testing.
> As a result, I think the separate [Test] button is necessary.
>
>>
>> Anyway I think we might be able to come up with a better solution.
>>
>> I been thinking about this problem today and still don't have an
>> idea I am
>> happy with.
>>
>> I thought about doing a simple GUI wizard but as I laid out all
>> the steps need
>> and the number of changes that would need to happen in the current
>> account
>> dialog it just would be too much work to perform given my tight
>> schedule for
>> Preview.
>>
>> But perhaps not. The wizard part would not be that hard to do. The
>> hard part
>> would be deciding how to redesign the current Account Prefs to
>> support a wizard
>> ie. we would not want to ship default accounts since by definition
>> these would
>> have aleady been created and thus would bypass the wizard. The
>> default view of
>> the Account pref dialog would need to change since no accounts
>> would exist i.e.
>> we would not default to showing the pre-configured IMAP accounnt.
>>
>> So hopefully you have some thoughts on the subject.
>>
>> Perhaps a brief chat on Monday by all interested parties?
>
> Yes, lets chat more today.
>
>>
>> Have a good weekend,
>> Brian
>>
>>
>> --
>> Configure bugmail: http://bugzilla.osafoundation.org/userprefs.cgi?
>> tab=email
>> ------- You are receiving this mail because: -------
>> You reported the bug, or are watching the reporter.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070122/a36c4885/attachment.html
More information about the Design
mailing list