|  |
Весьма поучительная история о том, как мы ссорились с адвокатской конторой в процессе покупки домика в деревне
Часть первая
И вторая, надеюсь, последняя!
Post A Comment | Add to Memories | Tell a Friend | Link
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. An ordered list of benefits
- 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.
An ordered list of problems/issues involved
- I can't see the issues this would cause.
23 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
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. An ordered list of benefits
- 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.
An ordered list of problems/issues involved
- Time for developers to research and put something into place
13 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
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. An ordered list of benefits
- 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.)
An ordered list of problems/issues involved
- 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.
15 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
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 An ordered list of benefits
- - 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.
An ordered list of problems/issues involved
- - Costs additional money to implement
20 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
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.
( Twitter E-mail Example... )Integrating LiveJournal information along with the Twitter template above, I suggest the membership request e-mails could look like the following: ( Suggested LiveJournal E-Mail... )As you can see in the above mock-up, the e-mail would give basic, more useful information about users. Often times journal creation dates, comment statistics, number of friends, and age determine whether someone will be approved or not. The information is basic and condensed and should not be of concern for those concerned with privacy. It only draws from information that is elected to be displayed in the profile. (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.) An ordered list of benefits
- 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.
An ordered list of problems/issues involved
- 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.
26 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
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. An ordered list of benefits
- 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.
An ordered list of problems/issues involved
- 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.
9 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
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 -_- An ordered list of benefits
- 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
An ordered list of problems/issues involved
- Maybe it's difficult to implement ? I've no idea but honestly I don't see any drawback to this suggestion.
21 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
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. An ordered list of benefits
- The HTML profile page will not have to be downloaded and parsed, just as the /bots document suggests.
An ordered list of problems/issues involved
- I do not see any drawbacks.
2 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
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. An ordered list of benefits
- BenefitS:
- PAid members can use it exclusively.
An ordered list of problems/issues involved
14 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
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. An ordered list of benefits
- The flow of conversation will not be interrupted, like it currently is now.
An ordered list of problems/issues involved
32 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
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. An ordered list of benefits
- Less annoying. Would remove another way that people will try to harass other people on LiveJournal.
An ordered list of problems/issues involved
- Unsure of implementation. Could be code intensive, I'm not sure.
29 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
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. An ordered list of benefits
- Better dissemination of information among Support volunteers
- Increased access to information
An ordered list of problems/issues involved
- 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.
17 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
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? An ordered list of benefits
- 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.)
An ordered list of problems/issues involved
- 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.
14 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
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 An ordered list of benefits
- The Europeans will be related to Europe.
- It will be easier to find their time zone.
An ordered list of problems/issues involved
- Some of the users will have to set right their time zone.
6 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
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. An ordered list of benefits
- 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.
An ordered list of problems/issues involved
24 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
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. An ordered list of benefits
- less inbox spam
- more control over comment notifications
- a good opposite to the ability to track a thread
An ordered list of problems/issues involved
- coding time
- modification of notification behavior needed
- a troll might post a bad comment/entry and turn notifs off to be obnoxious
12 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
|
|
|
|
|
![[info]](http://l-stat.livejournal.com/img/community.gif){kind=small}
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
borj's Friends Page
Partner (1): 
Sponsored (1): ![[info]](http://l-stat.livejournal.com/img/newsinfo.gif){kind=small}
Official (1): 
Community (1):