Starting in 1996, Alexa Internet has been donating their crawl data to the Internet Archive. Flowing in every day, these data are added to the Wayback Machine after an embargo period.
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
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:
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.
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!
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 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.
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
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"
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
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
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.
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.
Short, concise description of the idea Electrocute 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 suggestions maintainer and moderators
Lowers amount of eyerolling when reading 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 suggestions community rules and memories before posting and commenting
Possibly include "stupidity mode" which can be manually deployed when flamewar breaks out anyway
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.
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.
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.
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.
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.
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!
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.
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.