Comments inline below.
Priscilla Chung wrote:
**Proposal**
+ From a bookmarkable URL, when a user clicks on 'Sign up for an
account' a 'Creates an account' dialog appears. In the 'Create an
account' dialog at the bottom display a check box that says:
[ √ ] I'd like to subscribe to this collection once I create my
account. (default to: checkbox is checked)
+ Once the user goes through the sign up process (e-mail verification),
the user logs in and will be placed into the collection they were
previously looking at—the collection sent from Chandler Desktop user.
+ On the left navigation, once the user logs in it will default to the
collection they were looking at, but they will still be able to switch
to the default 'Chandler' blank calendar. Meaning the user would start
off with two calendars in the left navigation.
In the previous discussions about how to do this, there were a three
possible approaches we discussed:
1. Adding the subscription on the server-side after the account is
created, but before it's activated.
The benefits of this approach are obvious -- the subscription is added
to the account right away, and nothing can happen in between creating
the account, getting the e-mail, and verifying/activating the account
that would cause the subscription to be lost.
IIRC, the major downside of this approach is that it was deemed to be
difficult to implement because of the inflexibility of our security
model. (I believe there were also concerns that allowing subscriptions
to be added to a not-yet-activated account could be a security risk,
which seemed a little dubious to me.)
2. Storing the information about a 'subscription to be added' in a
browser cookie, and adding the subscription after the user actually logs
on to the new account.
The benefit of this approach is that it doesn't require any server-side
work.
The downside is the inherent unreliability of cookies. For example, if
the users completes the account-activation process from a different
browser (e.g., goes home from work and checks e-mail there), the
subscription will not get added to their account.
The bottom line would be that we can't assume the process would always
work, and end-users in those cases would be left wondering why it didn't
"add this subscription" like it said it would.
3. Change the activation e-mail to include information about the desired
subscription, and put it into the URL for the confirmation page.
The benefit is that approach is that the info for the subscription is in
the actual e-mail, so it comes along with the users to the activation
and login pages -- no matter where they log in to the app from.
The only drawback I can think of is that it would require some amount of
server-side work. There may be others. I would appreciate feedback from
Travis on this.
I believe we had a discussion on the list to see if it was necessary to
keep the out of the box 'Chandler Hub' calendar. I think for now, I
don't see much harm to keep a blank calendar for the CC users. When we
introduce remove, perhaps they would be able to remove it from their list?
Any thoughts on this proposal?
-Priscilla
I think it's a good idea anyway to give CC users their own empty
calendar in the Web UI. It's a way of encouraging them to try it out
themselves.
Currently they don't lose their Ticket View (or are we calling
this the bookmarkable URL view now?) e-mail verification just
opens up a new tab/window in their browser.
Another proposal is that we close the old 'ticket view' after
clicking on e-mail verification and the user is logged in,
and seeing the current subscribed collection. This I think may
be disorienting based on your point earlier. It's better that
the user closes the window themselves.
Second, when users have a Chandler Hub account open, it's
possible to keep another tab/window open for the ticket
(bookmarkable URL) view. Even if the collection is in their
account. Are there any reasons why we want to enforce users
not to do this?
I think I've mentioned this before, but it bears repeating -- once we
move the workflow outside of the current browser window, we cannot
assume that we have control over what windows are opened or closed, or
where.
First of all there are tab/window-control and pop-up blocker addons that
can affect whether pages will open in a new window. Secondly, once we
ask users to go check e-mail, there is no guarantee they'll complete the
process in one sitting. As I mentioned above, they may go home and check
e-mail from there, or wait until the next day.
It's a remote app, which simply means we have less control over user
behavior than with a desktop app.
I'm not saying we shouldn't build any niceties in -- just that we
shouldn't build something where if you're not in the 90% where it works
as expected, you're 100% screwed.
The amount of client-side work for this feature is about the same no
matter whether we go with the client-side (cookie) or server-side
approach (a day or two, tops). I see you have a bug (8720) for this.
I'll add a SWAG in there for that.
Matthew
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
