![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
piscinarii) wrote in ![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
dw_suggestions2009-12-17 11:19 pm
"Vacation" option for journals.
Title:
"Vacation" option for journals.
Area:
account settings
Summary:
Enable an option on the accounts settings page for a "vacation" mode in the active/deleted section.
Description:
In the latest news post it was announced that deleted account purging will begin in January. A journal that has been deleted for over 30 days enters the purging queue. Journals that have been purged are extremely difficult to recover. People sometimes delete their journals when they take a break from the internet and then revert them back to active status at a later date.
For example: I have deleted my journal in the past while studying for finals because my journal was a daily distraction. However, I needed to revert back to active status before 30 days had passed to prevent my journal contents from being purged from the servers. If I had forgotten, become distracted with other life events, etc. and not reactivated my journal the contents would have been deleted from the servers.
I suggest that the third option "vacation" (or some other applicable wording) be added to the active/deleted section of the account management page. This would help prevent accidental deletion of accounts.
Implementation could be as simple as the current "30 days before entering the deletion queue, unless reactivated" but instead be "30 days before automatic reactivation, unless manually reactivated" or "XX days before automatic reactivation" with the number specified by the account owner.
It could be completely open, allowing the account owner to come back at any time to reactivate early, or a lockout where the time would have to run through completely before posting to journal/reading subscriptions/editing of profile/etc was enabled again. If a lockout is enabled, it should only prevent any use of or modifications to the account, not prevent the account owner from logging in. I see both of those options as useful for different personalities.
I think options for handling the displayed contents of the journal while in vacation mode should be offered. The journal can be left in "read only" mode, so subscribers can still read the contents but no new posts will be made to the journal OR the option of removing the journal from display and instead placing an account owner generated "this is why I'm gone" blurb or a site generated "user is on vacation" note.
If the time is specified by the account owner, and the option of complete lockout is enabled, there would have to be an alternate way to reactivate the account early by some other process. For example, I accidentally locked myself out for "100 days" rather than "10 days". Perhaps a verification e-mail similar to the "verify your e-mail address/verify your account creation" for "verify vacation time for XX days from Month Day Year to Future Month Day Year" could prevent most mistakes. Maybe also a link to submit a support request to have the lockout reversed.
Paid time will not be paused or saved by going into vacation mode. The paid time expiration date will remain the same. During the vacation period the account will be removed from the pool of users that can receive paid time through the "gift a random account" in the Dreamwidth shop and paid time purchased for the account outright will not be applied until after the account become active again.
Something like this could be offered in tiers for free/paid users. For example:
Basic Tier: predetermined drop down menu of times (7 days, 14 days, 30 days), open to reactivation at any time by account owner, generic "user is on vacation" blurb.
Paid Tier: dropdown menu with previous times PLUS other (please specify) field, reactivation at any time or lockout option, option of read only mode, generic blurb, or user written blurb.
That way all users have access to the functionality of this option.
The main drawbacks I see are deciding how in depth to make this option and how complicated I imaging the coding for it would be, as well as deciding how best to offer this option to free/paid users. Hopefully I covered most of the main points.
This suggestion:
Should be implemented as-is.
26 (54.2%)
Should be implemented with changes. (please comment)
4 (8.3%)
Shouldn't be implemented.
6 (12.5%)
(I have no opinion)
9 (18.8%)
(Other: please comment)
3 (6.2%)
no subject