The Wayback Machine - http://web.archive.org/web/20050419022521/http://www.livejournal.com:80/community/suggestions/
Recent Suggestions Archives Profile Prior Suggestions Previous Previous
LiveJournal Suggestions
This is your opportunity to share your ideas for LiveJournal, as well as voice your opinion on proposed ideas!

We encourage you to add this community to your Friends list, so you can contribute your thoughts on suggested improvements to LiveJournal.

If you want to submit your own suggestion or read through past suggestions, please view the links below.
Helpful Links
Archives
Back April 2005
12
3456789
10111213141516
17181920212223
24252627282930
Suggestions Box
Want to improve LiveJournal? Contribute your ideas!
breaklikeagirl
[info]suggestions
[info]breaklikeagirl
Add to Memories
Moderator/Maintainer Only Comment Screening

Title
Moderator/Maintainer Only Comment Screening

Short, concise description of the idea
Allow screened comments in a community to be visable only to maintainer/moderator, and not author of specific post.

Full description of the idea
I run a community dealing with a sensitive topic, and lately we've had to disable anonymous comments due to abuse. I did not wish to do this, as due to the nature of the community I felt those who wished to comment anonymously should be able to.

Screening is obviously an option in such a case, but due to the fact the abusive comments were aimed at the author of the entry, this also wouldn't help.

I think there should be an option which allows screening of comments where only the moderator/maintainer of the community can view them and unscreen them (either as an overall community setting or as a setting per post).

An ordered list of benefits
  • Reduction of abuse
  • Reduction of drama
  • Added user security/peace of mind
  • Added community control

An ordered list of problems/issues involved
  • Misuse of control by moderator/maintainer
  • Some users wish to see all comments to their entries (can be got around by making feature per post)

An organized list, or a few short paragraphs detailing suggestions for implementation
  • Additional option either in the update journal page or the community information page
manuka
[info]suggestions
[info]manuka
Add to Memories
Make editing colors for existing friends easier

Title
Make editing colors for existing friends easier

Short, concise description of the idea
Put a foreground/background selection dropbox on each existing friend in your list, so you can easily work with your colors. Doing it separately, 5 at a time is a huge pain.

Full description of the idea
The current line for deleting a friend entry is as follows:

[info]1_acme_journal


I would modify it as follows:

[info]1_acme_journal


Another possible way to implement something similar with less generated repetitive code would be the ability to create certain foreground/background color "styles" that can be labeled.. For example, I could set "white FG/green BG" to be known as "tech communities", and then have a dropdown list with my various labels.

An ordered list of benefits
  • Makes it WAY easier to mass-tweak colours to suit a new style or whim

An ordered list of problems/issues involved
  • More code in generated page if you've got a large friends list, but this makes the process much easier for nutjobs like me with lots of friends.

An organized list, or a few short paragraphs detailing suggestions for implementation
  • Change template for edit friends page to move color selectors around.
  • Another possible way to implement something similar with less generated repetitive code would be the ability to create certain foreground/background color "styles" that can be labeled.. For example, I could set "white FG/green BG" to be known as "tech communities", and then have a dropdown list with my various labels.
  • This method would also make it easier to change a whole bunch at once just by changing the FG/BG associated with a label, much in the same way that changing the definition of a text style in a page layout or word processing program pushes those changes out to everything using that style.
__enigma__
[info]suggestions
[info]__enigma__
Add to Memories
nc=X not counting your own posts

Title
nc=X not counting your own posts

Short, concise description of the idea
If the nc= section of a friends page should either not count your own posts or have an option to not count your own posts

Full description of the idea
Currently if I click on a friends post and read the comments then the link changes colour so I know I have read it, but if I post a reply myself then the link also changes colour - so I end up reading my own replies all the time!

If it only counted other peoples posts then that would solve the problem.

An ordered list of benefits
  • The links on the friends/users pages would only change colour if someone else had posted there.

An ordered list of problems/issues involved
  • If it wasn't made optional then it might be annoying for people wanting to see a total post count there - although the displayed human-readable count wouldn't change so that shouldn't be a problem...

An organized list, or a few short paragraphs detailing suggestions for implementation
  • Instead of adding nc= to the html then add nc= or nc=-.
    I would be very surprised if either is hard to do in the database!
cmshaw
[info]suggestions
[info]cmshaw
Add to Memories
Allow users more than ten styles

Title
Allow users more than ten styles

Short, concise description of the idea
S2 layouts and themes can only be previewed via S2 styles, but each user is limited to ten styles. More would be good.

Full description of the idea
Currently, users may have up to ten S2 styles. However, there is no limit to the number of S2 layers each user can have. For users working on several different layout or theme designs at once, limiting the number of styles (and therefore the number of previews of layouts or themes) to ten is a very low bar. (For example, the recent [info]lj_stylecontest asked people submitting designs to include ten themes. If people were submitting more than one design, or using any other layout on their own journal, it was impossible to provide previews for all themes with the submission.)

An ordered list of benefits
  • More previews of S2 designs available.

An ordered list of problems/issues involved
  • Perhaps performance is bad when too many styles exist?

An organized list, or a few short paragraphs detailing suggestions for implementation
  • I don't know if this limit is arbitrary or tied to some other function.
cmshaw
[info]suggestions
[info]cmshaw
Add to Memories
Better layout on the "Modify Friend" page

Title
Better layout on the "Modify Friend" page

Short, concise description of the idea
The "Modify" button should be at the bottom of the "Modify Friend" page, not at the top.

Full description of the idea
The current layout has the "Modify" button at the top of the page. It would make more sense at the bottom of the page, after the items which are modified (friend groups and color selection), so that the flow of action through the page is not "scroll down to modify, scroll up to button, save" but instead "modify, scroll down to button, save".

An ordered list of benefits
  • Ease of use.

An ordered list of problems/issues involved
  • Any change in the placement of buttons will startle users accustomed to the current configuration.

An organized list, or a few short paragraphs detailing suggestions for implementation
  • This is just a layout change.
lirimaer
[info]suggestions
[info]lirimaer
Add to Memories
Move "join community" link.

Title
Move "join community" link.

Short, concise description of the idea
Move the "join/leave community" links on the community userinfo down to the bottom, just above where the "memories" link is located.

Full description of the idea
A lot of communities post their rules in their userinfos, but, often, people tend to just click the "join community" button at the top of the page without even reading past the second sentence of the userinfo.

My suggeted solution is to move the join/leave community links further down, towards the bottom of the page, so that new members are forced to at least view (and hopefully read) the userinfo before joining the community.

An ordered list of benefits
  • forces people to view the userinfo before joining the community, which is good since most communities keep their rules in the userinfo
  • will reduce number of posts against the rules where people's excuse for the post is "they didn't know" about the rule (ie didn't read it)

An ordered list of problems/issues involved
  • the joining link could be difficult to find, depending on its placement

An organized list, or a few short paragraphs detailing suggestions for implementation
  • it could be set up just like the memories, pictures, interests, etc. on the top of that list (but for communities only, obviously) with a bolded header of "members" and then links for "join" or "leave"
manuka
[info]suggestions
[info]manuka
Add to Memories
Expand LJ Comment e-mail

Title
Expand LJ Comment e-mail

Short, concise description of the idea
Provide journal/community info in the header of LJ Comment notification e-mails for filtering purposes

Full description of the idea
I'd like to see the community/journal name added to a comment notification, allowing me to filter (either visually or using mail filters) based on certain communities, so that I can separate out comment notifications from my personal journal and prioritize them. Alternately, adding a custom header would work too for automatic filtering (but not for visual filtering)

Currently, the community/journal information is presented, but it's buried inside a URL in the body of the message. This means I have to open every message, and then go examine the link, which is very time consuming.

An ordered list of benefits
  • Ease of filtering through large numbers of comment notifications

An ordered list of problems/issues involved
  • Slightly longer headers, but overhead should be minimal.

An organized list, or a few short paragraphs detailing suggestions for implementation
  • Simply add the journal/community name to the subject line or a custom header such as X-LJmetadata. The data is already in the body.
  • Comment notification subjects could be as follows:
    Subject: Reply to your {post|comment} in {journal|community} lj_nifty
    X-LJmetadata: journal/manuka or community/lj_nifty
desh
[info]suggestions
[info]desh
Add to Memories
Invalid HTML and syn feeds

Title
Invalid HTML and syn feeds

Short, concise description of the idea
For syndicated entries, don't break the link to the original entry if the entry contains invalid HTML.

Full description of the idea
When a journal post is made with certain invalid HTML, LiveJournal's HTML cleaner catches it. It disables all HTML in the entry, and prints an error message at the top of the entry like "[Error: Irreparable invalid markup ('<a [...] badly-closed-tag>') in entry. Owner must fix manually. Raw contents below.]"

When content from another site is syndicated onto LiveJournal, LiveJournal adds a link to the original "entry" (or whatever the other site calls the unit being syndicated) at the top of the LiveJournal post.

When a syndicated feed has bad HTML, this HTML-disabling happens like it would with any other entry. There are at least two problems with this. First, the automatically-added link to the original entry is disabled, just like with any HTML that was in the original entry itself. Second, the error message is inaccurate, since there's no "owner" of the syndicated feed, and in fact the owner of the original site might not even know there's a problem, if their site has less strict HTML cleaning and if they never read their LiveJournal syndicated feed. This error message should be changed to more accurately reflect what's going on here (though I don't have any specific text in mind; haven't thought about it yet).

An ordered list of benefits
  • A useful link (to the original entry) is retained in more situations
  • Clearer error messages are always a good thing

An ordered list of problems/issues involved
  • Implementing a special case for the HTML cleaner (to not fail the entire entry, just the original not-added-by-LiveJournal stuff, and only on syn feeds) might be difficult, though I'm not sure
  • Similarly, a special case for that error message might be tough to add
  • There might be sentiment that the entire entry should be broken, to encourage better HTML, though I disagree with this

An organized list, or a few short paragraphs detailing suggestions for implementation
  • The HTML cleaner and text of the error message need to be edited and special-cased, as explained above
taphu
[info]suggestions
[info]taphu
Add to Memories
Community Scrapbook

Title
Community Scrapbook

Short, concise description of the idea
It would be nice if the maintainers for paid-account communities could maintain a scrapbook for that community.

Full description of the idea
Paid account members get the benefit of a Scrapbook while communities do not. Amoung (many) other things, LJ communities sometimes serve as a place for specific groups of people who know each other and share real life experiences (i.e. my rather large family) to get it together. It is not always the case that every memeber of the community has a paid account, and, therefore, their own personal Scrapbook in which to post community related pictures. Furthermore, the real life community, which the LJ community represents, often extends beyond the demographic of geeks like me into people who would find it onorous to maintain a personal LJ account. While these people obviously could not post pictures, we allow them to participate in the online forum of our real life community and we would also like them to be able to access photos that belong to the community, and not just to some particular memeber of the community.

This would also allow the community photo gallary to be organized relative to the community, rather than organized as a subsection of some member(s) Scrapbook gallary.

Obviously, this would apply only to paid acounts.

An ordered list of benefits
  • Community Based Photo Area.
  • Warm heart of human being.
  • More Community Zen.

An ordered list of problems/issues involved
  • Authentication Complexity (is a beotch)
  • Long, Dark Night of Implementation (think E. Poe)
  • Hell if I know, I don't know the LJ codebase.

An organized list, or a few short paragraphs detailing suggestions for implementation
  • Well, I don't know shit about the LJ codebase or software architecture, but.. if it were ME, I would say make "community maintainer" equivalant to "community scrapbook maintainer" and not try to bother with adding yet another authorization param for community members.
surye
[info]suggestions
[info]surye
Add to Memories
Quote button not accessable when needed.

Title
Quote button not accessable when needed.

Short, concise description of the idea
Quote button is not accessable from any page that is not "?mode=reply".

Full description of the idea
On the normal post/comment view "?style=mine", there is the "Quick Reply" comment entry. However this does not have the quote button, and this is where one would hi-light the post to quote it. However, when you click on more options, you get the quote button, but now nothing to quote!

An ordered list of benefits
  • Greater functionality from the quote button due to access from more views.

An ordered list of problems/issues involved
  • The "Quick Reply" design of fewer options breaks down a bit further.

An organized list, or a few short paragraphs detailing suggestions for implementation
  • Add quote button right of subject box, as there is already whitespace there.
rahaeli
[info]suggestions
[info]rahaeli
Add to Memories
a shocking suggestion

Title
a shocking suggestion

Short, concise description of the idea
Electrocute [info]suggestions posters and commenters who do not first read the community rules and memories

Full description of the idea
We've all rolled our eyes as Yet Another suggestion that's only a rehash of something first proposed -- and rejected -- in 1998 comes through. Imagine how bad it is for the moderators of the community, who reject 10 suggestions (duplicate, misfiled, unintelligible, etc) for every 1 which gets through. And let's not talk about the same five debates which come up in the comments to this community all the time.

This suggestion proposes a negative-feedback loop which will hopefully be more effective than community moderation in reinforcing proper conduct in this community.

An ordered list of benefits
  • Saves sanity of [info]suggestions maintainer and moderators
  • Lowers amount of eyerolling when reading [info]suggestions
  • Fewer flamewars
  • More sanity
  • Greater percentage of non-lame suggestions
  • Greater chance of things catching on fire (fire is cool, heh heh)

An ordered list of problems/issues involved
  • Rigor mortis
  • Liability
  • Electrocuted people smell funny
  • The lawyers won't like it
  • Electroshock algorithm must be carefully tuned to avoid false positives
  • Some may accuse LJ of being self-righteous prescriptivists if this suggestion is implemented
  • Possible power outages

An organized list, or a few short paragraphs detailing suggestions for implementation
  • Market new USB electroshock-device (in various tasteful colors) through the LiveJournal store
  • Develop electroshock algorithm to identify posters who do not read [info]suggestions community rules and memories before posting and commenting
  • Possibly include "stupidity mode" which can be manually deployed when flamewar breaks out anyway
  • Check date on calendar
snarkbite
[info]suggestions
[info]snarkbite
Add to Memories
Change 'Entry is backdated' option's title

Title
Change 'Entry is backdated' option's title

Short, concise description of the idea
Change title of the 'Entry is backdated' option on the Update form to 'Entry is non-chronological'.

Full description of the idea
The current title of the 'Entry is backdated' option causes a lot of confusion for people due to its name. The name makes people assume that it's only used to post entries in the past. (Gee, how would the term 'backdated' cause people to think that, eh? LOL...)

The real issue with the current title is that the option is actually more often used to set an entry that is *future*-dated, rather than one in the past. The "This gerbil iz Fiends Only!" entries are almost always a far-future dated entry, but such entries need to actually be 'backdated' for people to continue posting normally afterwards. So, trying to explain to someone that "you need to backdate your future entry" gets a little dicey, both to explain correctly and for the user to understand.

The true point of the checkbox is to simply tell LiveJournal "I'm posting this entry in such a way that it is out of chronological order with the current entries in my journal -- it's either in the past, or it's in the future but I'd then like to continue posting 'current' entries after that."

So, I'd like to suggest changing it to "Entry is non-chronological" to make it more generic, so that it fits in with both directions on the timeline. At least give a clue that it doesn't *have* to be a past date, which is what its current title mandates (until you're told otherwise).

I have no actual preference on the wording -- if someone can come up with a better phrase that's short but still gets the idea across, that's fine.

An ordered list of benefits
  • A title that is more accurately reflective of the setting's actual functionality.
  • Less user confusion right out of the gate.
  • Easier for Support to explain what the feature does.
  • More likelihood the user will actually 'get' such an explanation.

An ordered list of problems/issues involved
  • It's just a field name change -- no actual functionality/coding/programming would be touched. Therefore, I don't think there would be anything that qualifies as a real "problem" that would be created by making the change.

An organized list, or a few short paragraphs detailing suggestions for implementation
  • Title would need to be changed.
  • Site error messages (such as 'incorrect time value') that reference the 'Entry is backdated' option by name or that use 'backdating/backdated' in a general sense would need to be updated accordingly.
  • Site FAQs that reference this option in any way would need to be changed accordingly.
unholysmickage
[info]suggestions
[info]unholysmickage
Add to Memories
Adding music

Title
Adding music

Short, concise description of the idea
being able to add a song/sound clip to an entry

Full description of the idea
a link or space to upload song or sound in a journal entry or profile.

An ordered list of benefits
  • more interesting entries
  • saved space where lyrics would take up

An ordered list of problems/issues involved
  • copyright laws
  • too long to load pages due to too much content

An organized list, or a few short paragraphs detailing suggestions for implementation
  • possibly just the ability to add a song to user profiles or one sound link per page of entries (?)
  • would need more memory space in the servers
underhiswings1
[info]suggestions
[info]underhiswings1
Add to Memories
Add "Refried Paper" to S2

Title
Add "Refried Paper" to S2

Short, concise description of the idea
Add the "Refried Paper" layout/scheme to available layouts for S2

Full description of the idea
Add the "Refried Paper" layout/scheme to available layouts for S2

An ordered list of benefits
  • Many of the available layouts are nice, but "Refried Paper" rocks!

An ordered list of problems/issues involved
  • I see no drawback, unless y'all have already considered it and decided against it.

An organized list, or a few short paragraphs detailing suggestions for implementation
  • I don't think this request applies. (No suggestion for implementing it)
wooosh
[info]suggestions
[info]wooosh
Add to Memories
Streaming Media

Title
Streaming Media

Short, concise description of the idea
We should have the ability (paid and non paid accounts) to stream media to our updates!

Full description of the idea
We should be able to have streaming media linked to our posts. We can already do it with pictures based on HTML and open source coding that you all use. The fact that we would be able to put full length songs into our posts for others to listen too instead of just the lyryrics, do a video update where you dance around explaining how your day of picking berries and fighting sharks went! Its a great idea I feel. Of course the user would have to have there own webspace to stream from, but yet the paid users would be given space on your network.

An ordered list of benefits
  • A more exciting Live Journal Experience

An ordered list of problems/issues involved
  • Some people might not have web space
  • Some people might not have a connection fast enough to be able to do this effectively.

An organized list, or a few short paragraphs detailing suggestions for implementation
  • All I think you'd have to do is modify your coding placement and use. It shoudlent be TOO hard of a deal.
lizyerby
[info]suggestions
[info]lizyerby
Add to Memories
log in

Title
log in

Short, concise description of the idea
i really miss being able to log in at the top of the screen before clicking not logged in.

Full description of the idea
i noticed that now i have to click "not logged in" at the top right of the screen before you type your log in information now, and i wish you had it as it was previous.

An ordered list of benefits
  • i used to be able to just press tab, and then type in my username and then press tab and type in my password. being a complete geek, i have this system of pressing tabs and ctrl+t, and stuff to do all my websurfing very fast and not having to use the mouse. now i have to use the mouse to click on not logged in, and its really not cool.

An ordered list of problems/issues involved
  • i just dont like to have to use the mouse.

An organized list, or a few short paragraphs detailing suggestions for implementation
  • just put it back to how it was so i wont have to use the mouse, and i will be fifty times happier. thats like once more than fortynine times happier.
comrade_robinov
[info]suggestions
[info]comrade_robinov
Add to Memories
LJ-Cuts, and Domain Aliasing

Title
LJ-Cuts, and Domain Aliasing

Short, concise description of the idea
LiveJournal ought to update all links - not just some - for aliased domains.

Full description of the idea
LiveJournal allows paid users to mirror their journals for a more professional look. For instance, my journal appears at www.revisionist-history.net. My recent entries, archive, and friends pages show up at revisionist-history.net, as do the permanent links and comment pages.

However, LJ-cuts link not to my domain but to a livejournal.com link.

An ordered list of benefits
  • Although LiveJournal's main appeal is its communities of friends, in order to keep up with the competition, our journals should look as polished as possible.
  • Inconsistent links are amateurish.
  • Paid users deserve better.

An ordered list of problems/issues involved
  • Somebody will have to do some programming, but I suspect this is more an issue of finishing up the job. After all, the other links work properly.
  • Other LJ-specific tags will still need to link to LiveJournal and not to the user's domain.

An organized list, or a few short paragraphs detailing suggestions for implementation
  • I am not an able programmer, so I cannot forsee the problems here. I hope implementation of this feature is as simple as the concept.
leora
[info]suggestions
[info]leora
Add to Memories
Allow Bulk Deletion on Main Memory Category Page

Title
Allow Bulk Deletion on Main Memory Category Page

Short, concise description of the idea
Rather than making users tack on an extra bit to the URL to delete memories by checkbox, make that the default view when they go to a memory category.

Full description of the idea
When I click the links to look at my memories, instead of sending me to someplace like:
http://www.livejournal.com/tools/memories.bml?user=leora&keyword;=psychology&filter;=all
send me to:
http://www.livejournal.com/tools/memories.bml?user=leora&keyword;=psychology&filter;=all&multidelete;=1

An ordered list of benefits
  • It makes it easier to delete uneditable memories.
  • It'd reduce Support requests.
  • It'd make the interface more intuitive (having to look in a FAQ to find out how to do something fairly basic and then URL edit is not user friendly UI).
  • It will save the world. (I can't prove this, but it might. Take it on faith. By decreasing the amount of frustration in the world, it will set off a chain of events that will, within 5000 years, lead to peace and harmony on Earth.)

An ordered list of problems/issues involved
  • Some users might check the boxes, then submit, then click that yes, they do want to delete a memory, and then go - but I didn't actually want to delete those memories! By making it easier to delete, we do make it easier to delete by accident. I'd argue that there comes a time when you have to let users hurt themselves, and taking 3 steps toward deleting something when you don't want to delete it seems to me like that time.
  • It'd require a change be made. Where things point to... I don't know how difficult that is to do. However, old links wouldn't break, so it shouldn't be too messy.

An organized list, or a few short paragraphs detailing suggestions for implementation
  • Change it such that when you click the heart icon to see your memory categories, all of them link to the new and extra-powerful URL.
  • Alternative option, yet equally good, but the ticky boxes for deletion on the main page for the memory categories. This involves cleaner, neater URLs, and more power to the users (than doing nothing). Power to the users!
emperor
[info]suggestions
[info]emperor
Add to Memories
LJ should support relative URLs

Title
LJ should support relative URLs

Short, concise description of the idea
When an image is included in an LJ post or comment, it should be possible to use a relative URL in the src field. i.e. <img src="//www.hostname.com/image1.jpg">

The Current behaviour is for lJ to prepend http:// to the front of the URL, which breaks at least some web-browsers (Opera and IE).

Full description of the idea
[see above]

An ordered list of benefits
  • Permits users to enter syntactically valid relative URLs
  • Avoids the current problem where a syntactically-valid <img> tag is adjusted by LJ to an invalid one that some web-browsers cannot use.

An ordered list of problems/issues involved
  • Users to incorrectly omit the protocol: section of their URLs might see confusing results?

An organized list, or a few short paragraphs detailing suggestions for implementation
  • If a URL is a syntactically valid relative URL, do not prepend http:// to it.
boredinsomniac
[info]suggestions
[info]boredinsomniac
Add to Memories
clusters off-limits for account creation

Title
clusters off-limits for account creation

Short, concise description of the idea
Temporarily directing new accounts away from clusters that are down

Full description of the idea
The recent FiletMignon issues and the resulting flood of support requests have led me here. There were many, many requests from user who created accounts on the FiletMignon cluster while the maintenance was in progress, and who were almost completely unable to use their accounts for up to a few weeks after creating them. There was also a huge upswing in account deletion requests from FiletMignon users during that time, many of which were brand-new accounts.

If a cluster has major problems that will take a while to fix and will severely inhibit account usability, or if it is going to be unusable for a while due to maintenance, someone ought to flip a magic switch somewhere that will prevent new accounts from being placed on that cluster until it is again usable.

An ordered list of benefits
  • prevent a slew of new users hating the site as soon as they start using it, and abandoning their accounts en masse
  • reduce discontent among new users
  • Creating an account only to discover that you can't use it is Not Fun.

An ordered list of problems/issues involved
  • If the cluster needs to be off-limits for long enough, and enough accounts are created during that time, there could be server load balance issues that would take a while to even out once the cluster was made available again. (if you think I don't really know what I'm talking about here, you're right.)
  • The main priority for developers, of course, is fixing the problems and getting the maintenance done, and taking the time to put a cluster off-limits would delay the actual maintenance. For this reason, I have this in mind only for long-term problems that seriously affect usability (as opposed to, say, a 2-hour repair or all those annoying-but-nonfatal Chef issues back in the day).

An organized list, or a few short paragraphs detailing suggestions for implementation
  • Dude, you don't need to worry about me getting too technical. I really couldn't say how this would be done.
  • It might be nice to set up a console command for it, so it could be taken care of quickly without delaying actual maintenance. But of course I have no idea how much work that would entail.