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

Short, concise description of the idea
Provide alternate methods of 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.

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.

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.

Длинная очередь машин при выезде из Хорватии в Черногорию. Номера немецкие, швейцарские, французские, польские, чешские, даже норвежские. Не видно только хорватов и черногорцев... ну, если нас не считать, с нашим растопыренным золотым орлом из Херцег Нови. Мы тут единственные монтенегритята, похоже. И те ненастоящие.

Posted via LiveJournal.app.