Title
Dates for LJ friends

Short, concise description of the idea
Dates for when you became friends with people on LJ

Full description of the idea
Wouldn't it be great to be able to pin point the exact date you added a friend to your LJ list of friends? What if when you added a friend it tide a date to them of when you did this so when you looked back you could remember or see how long you have been friends.

• Its nice to have a date for when you have met a person.
• You may reconsider defriending them if you see you have been their friend for 5+ years.

• I can't see the issues this would cause.

Title
Provide Alternate Methods Of Creating & Modifying Friend Groups For Journals and Communities

Short, concise description of the idea
Provide alternate methods of creating and modifying friend groups for journals and communities by revamping the editgroups.bml page or allow additional commands in the admin console.

Full description of the idea
Some users and communities utilize the friend group option to set privileges in regards to tagging posts. There are currently two methods to set the friend groups:

1) The editgroups.bml page (http://www.livejournal.com/friends/editgroups.bml) - Used to set-up and modify friend groups (works for both journals and communities).

2) The admin console (http://www.livejournal.com/admin/console/) - Used to modify friends (does not work for communities as there are no commands for it currently).

The above two methods do not work, however, if you have a very large friend's list or if you have many members in your community. In order to even set-up a group, you need to visit the editgroups.bml page. If you have a lot of friends / members, the page won't even load to create a group (because the current behavior is to list out every single friend / member users have).

Therefore, for those with many friends and members, I suggest that LiveJournal modify the method in which friend groups can be made. Here are a couple ideas which may be feasible:

1) Make it so the editgroups.bml page does not have to load every single friend / member you have at once. Possibly make it load a partial list at a time (or use a drop-down list) and then you can flip through and assign users to friend groups / create groups.

2) Make it so that groups (for both journals and communities) can be initially set-up using the admin console.

3) Make it so the admin console can be used for communities. Currently users can add / remove members using the "friend add / remove user group" command, for example. Communities cannot use this or any command.

• Large communities and those with many friends will finally have the ability to set-up groups.
• Large communities and journals can finally take advantage of setting it up so only certain users can tag posts.
• Users who use alternative access methods (such as screen readers, voice command software, mobile devices, mouseless-input, etc.) would be able to use the editgroups.bml page (provided the way it loads is modified) or be able to use the 'Friend Groups' function via other methods (e.g. admin console).
• More efficient methods for all users / journals to access / utilize friend groups.

• Time for developers to research and put something into place

Title
Disallow Journal Inheritance

Short, concise description of the idea
Prevent people from inheriting ownership of a journal when they receive a recycled email address previously used to open a journal.

Full description of the idea
In working in Support I've noticed that a lot of people make "unsubscribe me" requests, not knowing their email account was recycled from a previous LiveJournal user. They are instructed that they are the journal owner as the owner of the email address.

Instead of encouraging these non-LiveJournal users from deleting another person's journal, I'd like to see a way of dissociating the email address from the journal. That way if the user is still around and still has the password or secret question, they can recover their account.

• Users won't write to support asking who deleted their account.
• Abandoned accounts that were useful to the general community won't be unnecessarily deleted.
• As a permanent account holder, I won't have to worry if I die that my account will be wiped out by the next person to inherit my current email account. (Yes, I know that an account can be marked "memorial", but that requires a tech savvy family member who knows to ask.)

• More unwanted or unaccessable accounts may be retained.
• Users asking for "unsubscribe me" might not take the time to explain that they have never been LiveJournal users in the first place.

Title
Accidental Deleted Entries

Short, concise description of the idea
I'd like LJ to automatically save entries more often.

Full description of the idea
I use Firefox and I can't tell you how many times I have lost an entry because I hit the "delete" key and instead of deleting the previous character, it functions as a "back page" button. I could go into Word, type up my entry, and then post it, but I'd rather not do that when I don't have similar problems when I use other blogging services like wordpress.com

• - More posting
  - Less frustration
  - I'd I feel like LJ is no longer so far behind technologically-speaking. I feel like LJ is way behind other blogging sites, like wordpress or blogger. For example, wordpress tracks how many people see your blog. Not only can LJ not do that, I feel like it was designed for Windows 2000 and very little has changed.
  

• - Costs additional money to implement

Title
Modify Membership Request Emails To Include More Information About Users

Short, concise description of the idea
Modify the membership request e-mails to include more information about users. This will make it possible to tend to requests from e-mail, rather than the "Pending Membership Requests" page.

Full description of the idea
This suggestion stems from two earlier suggestions: "User Profile in Membership Request Emails" and "Modify 'Pending Membership Requests' Page...".

As most community maintainers who tend to membership requests know, this can be a tedious job. With the current membership request e-mails, there is not enough information about users to make an approve / reject decision. The same goes for the "Pending Membership Requests" page which not only does not have a lot of information about users, maintainers have to view profiles one-by-one if they want to learn more and go back-and-forth to approve / reject.

Based on the above, I would like to put forth another suggestion in an attempt to make tending the membership requests easier. This is based off of the current Twitter e-mail update, which is sent anytime users have a new friend / follower. Below is an example of such update, which includes basic information about users such as friends / followers and updates / tweets.

• Membership requests will actually have enough useful information that maintainers can make decisions from their in-box, as opposed to visiting the membership request page (which is not exactly user-friendly).
• With the revised e-mail template, maintainers can even tend to membership requests from their mobile device.
• Convenient / quicker than having to visit each individual profile to find information.
• Especially beneficial for communities with high traffic / number of requests.
• This template could be applied for regular friend requests on LiveJournal--dual use.

• Privacy concerns - but as noted in the suggestion, it only draws from information that is elected to be displayed in the profile and it is kept basic. For example, if someone has chosen the option to not display their birth date in their profile, then it would show up as blank or "-" in the membership request e-mail.
• Time and programming for the e-mail / compiling the statistics for the e-mail.
• Concern that e-mails might be forwarded to / accessed by other people.
• Need to consider those who do not get HTML e-mails / messages.
• Would only be used by maintainers who receive e-mail updates. Am unsure as to the number of maintainers who use this for their communities.

Title
Syn account URL edit request form

Short, concise description of the idea
There should be a form linked from the profile page of syndicated accounts that users can use to request the source URL be edited, much like the suggestion proposal generator or Abuse report form.

Full description of the idea
It's documented in the FAQs that syndicated accounts can have their source URL changed by opening a Support Request in the syndication category. This often results in people opening requests that don't have all of the required information (unfortunately,) which means that volunteers have to investigate further and which makes the lag time in changing the URL longer than it should be.

I'm suggesting that, on every syndicated account's profile page, a link appear that says something like "(Request a change in this account's source URL)". This link would direct the user to a form like the abuse report form, which would populate with the syndicated account name, then ask the user to provide the URL to the new syndicated account, and to enter any other details that the user wanted to provide. The form would then verify that the site is reachable and that the user provided a link to the new RSS feed (not just to the site), then would open a Support Request for the user, already containing the necessary information and the necessary console command to make the change.

This way, Support Volunteers would only have to verify that the new feed contains the same content as the old feed, and then copy and paste the command to actually make the change in URL.

• Less burnout for Support Volunteers answering these types of requests.
• Faster response to URL change requests.
• Likely, a better directory of syndicated accounts, since the current change process isn't easily accessible unless you read documentation for fun. This results in a lot of stale syndicated accounts.

• Requires coding of a new page and editing the profile page, both of which would likely not be high development priorities.
• Less technically-oriented users may not be able to find the RSS feed for the new site's address (this would be mitigated, at least somewhat, if the reporting form used the same logic that the /syn/ page does to auto-detect RSS feeds.)
• There's a potential for frivolous/abusive edit requests if there isn't any rate limiting by account as far as using the page goes.

Title
Viewing x last active entries in a community

Short, concise description of the idea
Having an option in communities sidebars where anyone can see what are the x last active (i.e commented) entries

Full description of the idea
I maintain a community where members often comment on old entries and unfortunately, maintainers are the only ones able to see that on the recent comment page. The idea is to have in the sidebar a box with the last 5 or 10 (or more for really active communities, number could be chosen by the maintainer, it could also be a paid communities advantage) active entries : just the name of the entries with the name of the latest person who commented (and maybe the date as an option).
The important thing here is not to view the 10 last comments for example but entries, so that an hyperactive recent entry wouldn't hide a new commment in an old entry. I've seen that some people suggested an RSS feed for comments but for some communities, that might be a hell of a spam. That's why maybe this idea would be less troublesome for very large communities where you can have hundreds of comments in a few hours -_-

• Anyone could notice new comments in old entries
• Community members would me more reactive and incited to comment on old entries
• Could make more people come to LJ cause this is THE main default of communities compared to boards

• Maybe it's difficult to implement ? I've no idea but honestly I don't see any drawback to this suggestion.

Title
Account creation date in FOAF

Short, concise description of the idea
Add a field for account creation date in FOAF.

Full description of the idea
There is no way to retrieve the date automatically without parsing the HTML profile page. I need this date to do some historical research on LJ dynamics. I suggest adding the account creation date in the exported FOAF record for each account.

• The HTML profile page will not have to be downloaded and parsed, just as the /bots document suggests.

• I do not see any drawbacks.

Title
Virtual Gift

Short, concise description of the idea
Virtual gift to be included as a package

Full description of the idea
I would like to suggest for the paid members, including the virtual gift as a free package will be beneficial.
This will enable the virtual gifts to be used actively.

• BenefitS:
• PAid members can use it exclusively.

• Nil

Title
Comments from suspended users

Short, concise description of the idea
Don't remove a users comments when their accounts are suspended

Full description of the idea
Currently, when a user's account is suspended, any comments they may have left anywhere on LiveJournal are removed. This makes it rather difficult to keep up with a conversation that may have been taking place with those comments. I think a suspended users comments should remain visible.

• The flow of conversation will not be interrupted, like it currently is now.

• I can't think of any.

Title
Remove the autoplay option for videos posted

Short, concise description of the idea
I would like to be able to remove the autoplay option from a video, even if the original poster included it.

Full description of the idea
In reading my friends page several times people have placed videos in communities that used the autoplay option with the intent to annoy. I'd like for there to be a mechanic where either I (on my friends page) or the community maintainer (via their options page) could disable autoplay for videos.

• Less annoying. Would remove another way that people will try to harass other people on LiveJournal.

• Unsure of implementation. Could be code intensive, I'm not sure.

Title
Identification for Official LiveJournal Communities

Short, concise description of the idea
Create an identification section for official LiveJournal communities similar to that of the "Partner :" and "Sponsered :" identifications.

Full description of the idea
When I was looking at a friend's profile, I noticed in the "Member of :" section that there was a grouping for "Partner" and "Sponsdered" communities. It looked as follows:

Partner (1): partner_name
Sponsored (1): sponser_name

news

community_promo

lj_support

Member of (4):
Partner (1): partner_name
Sponsored (1): sponser_name
Official (1): official_name
Community (1): community_name

• More asily identifiable communities/categories in profile
• Already adding to the community/profile background in place (i.e. the breakouts for sponsers and partner communities"
• For LiveJournal employees and volunteers, the breakout could look more prestigous in your profile and not get lumped in with all the regular communities you may be a part of

• Time and effort in implementing

Title
Way to leave notes on FAQs for Support-types and other priv-having people

Short, concise description of the idea
I wish there was a way to leave internal comment-type notes on certain FAQs to give Support-types and other people with privs more information than what the average user needs.

Full description of the idea
In Support, there is a way to leave internal comments (ICs) on requests to discuss the issue at hand internally before the user sees it. It's a way to help the Support-types communicate various things before getting back to the user with a final answer. They're stupidly helpful sometimes, and I would love to see something similar implemented in the FAQ. This feature would come in particularly handy when used on a FAQ that is referring to a common problem/issue and would enable Support to better handle issues as they appear.

• Better dissemination of information among Support volunteers
• Increased access to information

• Who would have editing control over these FAQ ICs? This would need to be worked out before this was implemented.
• May be difficult to implement with the current FAQ structure.

Title
Modification to how friends (and ex-friends) are managed

Short, concise description of the idea
Currently anyone who friends you or you have ever friended appears in the Add or Remove Friends matrix. It seems to be impossible to change the colors of ex friends without re-friending them. Also the table gets cluttered by LJ names that are defunct or will otherwise never be used again.

Full description of the idea
On the Add/Remove page I changed the colors of all old (ex) friends as a reminder why they were ex-friends. (Dark gray meaning "missing in action", Orange for "argumentative annoyance", etc.) I didn't realize until after I'd done it that changing the colors RE-friends EX-friends (some of whom are still on LJ, but I really don't want to refriend -- makes it a little awkward if they have notifications turned on, eh?) I thought as long as I didn't check the add/remove box next to the account name, it would not affect the f-status.

Also, the table gets cluttered with dormant accounts after several years -- "dormant" in this case meaning
A. the LJ page still exists, but the user clearly has moved on years ago, or
B. you have no intention of ever friending this anonymous person who friended you, or
C. they were un-friended by you, but for whatever reasoon haven't removed you from their f-list.

As far as I can tell, there's no way to remove accounts from this table unless the account holder deletes the account him/her self. If there is a way, please tell me what it is.

Would it be possible to do the following:
1) Allow color changes WITHOUT changing the Friend Status?
2) Allow color changes to custom filters en masse?
3) On the Add/Remove Friends and Set Custom Color page, have a way to segregate (or even remove completely) dormant and ex-friends?

• 1. Makes it easier (and more likely) users will use custom color feature, and easier to organize one's LJ page and custom filters.
• 2. Declutters the add/remove friends page -- especially helpful if you have a large f-list or have been on LJ for years.
• 3. Lessens possibility of accidentally re-friending someone you were only too happy to un-friend in the first place. (Probably happens more often than we like to admit.)
• 4. Gives us AR types who obsessively color-code everything a thrill. (Only half-joking.)

• 1. If inactive friends were removed from the add/remove friends page and someone wanted to re-add a person, they might have to go to more trouble than one little click -- but, come on, how lazy is that, really?
• 2. Would probably totally mess with the profile page friend classifications. I see the need to show who has friended someone on the profile page and to have a way to add them -- just not all jumbled together in the same matrix on the Add/Remove page. I don't know anything about coding and table links to know how big a headache this would be.

Title
Time Zone for Some Regions of Russia

Short, concise description of the idea
LJ Users from some cities which are located in Europe are to choose Time Zone Asia/Yekaterinburg.

Full description of the idea
User from Perm (Russia) asks (http://www.livejournal.com/support/see_request.bml?id=984365) in LJ Support: "What time zone should I use? We are Europe Moscow +2" (i.e. +5:00 (YEKT) and +6:00 (YEKST)).

He is quite right! Yekaterinburg (the only city in their zone)) is related to Asia.

So I suggest to add Europe/Perm (or Europe/Ufa) with +5:00 (YEKT) and +6:00 (YEKST) to the list at http://www.livejournal.com/manage/settings/?cat=display

• The Europeans will be related to Europe.
• It will be easier to find their time zone.

• Some of the users will have to set right their time zone.

Title
Include Journal Entry ID number in subject of e-mail comment notifications

Short, concise description of the idea
Include the Journal Entry ID number in subject of e-mail comment notifications so that e-mails can be grouped/sorted appropriately by subject, as is done by g-mail.

Full description of the idea
Currently, all LJ e-mail comment notifications use one generic subject. The effect, in g-mail, is that everything is lumped together in one group, regardless of the related LJ journal posts.

• Adding the LJ Journal Post ID number to the subject line is a concise way to allow g-mail to group all related LJ comment notification messages together, thus making it easier to manage such notifications.

• No discernible problems.

Title
De-Tracking of Threads

Short, concise description of the idea
The ability to turn off notifications for a specific comment thread in your post or in another post where you founded the comment thread.

Full description of the idea
Sometimes it would be convenient to be able to unsubscribe to a comment thread-- if someone in a post you wrote gets into a conversation with another commenter and you don't care what they're talking about. Or maybe you posted a comment in someone else's journal but you don't want to read any of the comments in reply (it's too late to edit but everyone is pointing out your spelling mistake! or something like that). But if you left the comment or it's your post, and you have notifications turned on, you have no choice but to receive these messages. What I'm suggesting is a *selective* de-tracking of these threads: the ability to unsubscribe to a thread just like you can track a thread right now. Right now, you can receive replies to every comment you made, and comments to every journal entry, but you can't opt out of any threads. It would be a great paid member option, if nothing else.

• less inbox spam
• more control over comment notifications
• a good opposite to the ability to track a thread

• coding time
• modification of notification behavior needed
• a troll might post a bad comment/entry and turn notifs off to be obnoxious

Title
Convert userinfo contact information to images.

Short, concise description of the idea
To cut down on contact information harvesting/spam, disallow plain text.

Full description of the idea
For the past month, I have been getting spam sent to my @livejournal.com email address. The only place that that email is listed is in my userinfo, which means someone is harvesting LiveJournal contact information.

I am suggesting that LiveJournal convert all contact information (email addresses as well as AIM names, etc.) into images. It would cut down on the amount of information that bots could harvest.

Here is one converter to illustrate what I'm talking about: http://services.nexodyne.com/email

• Less spam
• More security
• Peace of mind

• Work for the developers
• Wouldn't totally eliminate harvesting, but it would still cut down on it.

Title
Update to Twitter

Short, concise description of the idea
Basically, an update would go to twitter with all or part of your entry title and the link to it.

Full description of the idea
We already have the option to update our Livejournal account with our Tweets, but I think it would work better the other way around with a link to the journal entry created.

• Attracting non-Livejournal users to become Livejournal users?
  It would be cool
  You wouldn't have a million Twitter updates on your journal

• I suppose if you have your twitter profile set to public, people who monitor the "everyone feed" might be clicking the link, generating a lot of traffic. This could pose a problem if it's generating too much traffic regarding bandwidth?

Title
New feature

Short, concise description of the idea
finding all user posts with just one click

Full description of the idea
Hi, the other day when I tried to search for a particular entry I had posted quite a long time ago in a LJ community, I realized how problematic and difficult it was, as I had to go through the entire community again just to search for that 1 particular entry I made, which I don't even remember exactly when I had posted it. And the community I posted the entry in is very big, there's been A LOT of entries posted there since then. It's very inconvenient, and a hassle to go through the whole community.

So I think it would be a good idea if there's a feature that gathers ALL the entries a user has made, both in their own LJs and in LJ communities, and enables the user to find all their entries with just a click and reveals a page that shows them all their entries.
I think this would be a very handle, and beneficial feature, and not to mention very convenient.

Although users can always add their entries to their memories...but I think this feature is more practical as it would be automatic...while with memories, users have to manually add their entries. Besides the memories are mainly designed for users to save certain entries which they love.

With this new feature, if they decide to edit a particular entry they posted in a LJ community quite a long time ago, they can just use the feature and then search for the entry they're looking for on the page and edit it. They'll be able to find the entry much quicker and there's no hassle.

• - can easily help users find all the entries they've posted in both their own LJs and LJ communities
  - very convenient and simple
  - saves a lot of time for users in having to search for their entries in all those LJ communities

• well...to be honest, I can't think of any cons with this feature...I think it's an all-round fantastic and convenient feature.