 |
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 suggestions
 jayo |
|
|
|
|
|
|
|
Title
Various improvements to the Invite pages
Short, concise description of the idea
A collection of ideas to neaten up the Invite pages, including a system to transfer invite codes to another user
Full description of the idea
I feel sorry for the people in the top 100 on support's high scores page. (I realise I'm including myself in this statement, so try and ignore that for now.) Not for the sheer amount of time they've put into support to get there, for which they should be applauded; but for how the Invite pages must take a hell of a long time to load as a result. This is because as it stands, the main page is one long list of all the invite codes you have, and even the generate codes page lists a reason for each and every invite code generated in the past. For the sake of server load, page load times and sanity, these two pages should be neatened. Here's a list of things that could go a long way towards this goal. - Split generated codes into two groups, used and unused, and separate each group into groups of 25 for display purposes;
- Attach the reason a code was generated (and perhaps a timestamp) to each invite code on the main page, and in turn limit the number of "prior" reasons displayed on gen.bml to fifty;
- Implement a transfer mechanism, whereby user A can transfer up to five invite codes at a time to user B. This would involve marking that number of user A's codes as "used/transferred to <lj user="B">", and generating new codes for user B.
An ordered list of benefits
Cleaner layout and easier access to invite codes;
Reduced server load and page load times;
Certain invite codes would have more sentimental value than others ("oh look, this user got to use the invite code I earned when I reached my goal of 20 support points. Ain't that special?");
Transfer mechanism would save code sharers the trouble of remembering who was given which codes;
Transfer mechanism hands over (partial) responsibility of used invite codes from sharer to receiver, as sharer would not know who had the use of a transferred invite code via the receiver.
An ordered list of problems/issues involved
Interface clean-up benefits only a small number of users;
Certain invite codes would have more sentimental value than others ("the invite code I earned when I reached my goal of 20 support points is sacred, nobody's getting to use it, grr!");
Required timestamp/reason metainfo is probably not already attached to a particular invite code in the database;
Transfer mechanism could be abused in the form of code sharing communities gaining access to a large number of "donated" codes;
Transfer mechanism might have to take into account which codes user A wants to transfer (see sentimentality value, above);
Invite codes are going away Any Day Now™.
An organized list, or a few short paragraphs detailing suggestions for implementation
Implement the changes to /invite/ and /invite/gen.bml, using attached invite code metainfo (if it's available) on the main page;
Implement transfer mechanism, which shouldn't be too much of a headache;
Or, forget about this suggestion, because invite codes are going away Any Day Now™.
|
|
|
|
|
|
|
|
|
suggestions
godisprolife |
|
|
|
|
|
|
|
Title
Make Quicker Polls...
Short, concise description of the idea
Allow people to add more than one question at a time when creating a poll
Full description of the idea
Right now, when you want to create a poll, you can only add one question at a time. It would be nice, for those LJ users who create longer polls, if there was an option to add more than one question of the same kind at a time. For example, if I want a group of Radio Button questions together, then I could click the "Radio Button" option, plus the number (maybe up to 5 or 10?) of them I want. The format would still be the same, allowing people in add or delete parts of polls, and stuff like that, but this would allow people to create polls faster, and for those of us with slower connections, it saves a lot of time!
An ordered list of benefits
Saves time
Makes using LJ easier
An ordered list of problems/issues involved
Who would do it?
Would this slow down LJ in any way?
An organized list, or a few short paragraphs detailing suggestions for implementation
I am not sure how this would be done. I am guessing someone has to volunteer to do it, and there you have it!
|
|
|
|
|
|
|
|
|
suggestions
vzaliva |
|
|
|
|
|
|
|
Title
RSS feeds and paid users
Short, concise description of the idea
Instead of providing full article content in journals
of paid users, it makes more sense for users who paid, to
be able to access full text of articles via RSS feeds.
Full description of the idea
I am using RSS to read live journals. The problem is that for paid users I can read full article via RSS feed, but for free users it just shows couple of lines and I have to click on browser and open it again to see it in full. I am paid user myself.
I understand that this is done to encourage users to pay. But it is unlikely somebody would pay just to help others to read his journal via RSS. On the contrary, RSS user will gladly pay to be able to read others journals more easily easily.
Also, for free journals read via RSS, your server is sustaining unecessary extra load, since user download it twice: via
RSS (partial) and then after clicking via browser (full text).
So my suggestion is simple, once user is paid for his account, it should be able to have RSS access to all journals he wish to read with full article text included. This probably could be done by supplying authentication information (HTTP basic auth for example) to access such feeds.
An ordered list of benefits
Less server load (RSS is more efficient)
Better incentive for users to pay
An ordered list of problems/issues involved
Need to find a way to distinguish free vs. paid readers. (I suggest HTTP auth)
An organized list, or a few short paragraphs detailing suggestions for implementation
Add new URL path for paid RSS feeds. For example now you need to add /rss at the end of user journal URL to get old-style RSS feed. Add /authrss to access paid feed
PLAN A: for /pairss path require HTTP authentication.
PLAN B: include in url parameters with user name and MD5 password hash. e.g. ...vzaliva/authrss?user=john&pass;=123455
Once authentication with valid LJ username/password is passed, check if this is paid user. If user is paid, return via RSS full article text, if not, return summary (first couple of lines).
|
|
|
|
|
|
|
|
|
suggestions
katuto |
|
|
|
|
|
|
|
Title
A chance to create you're own cards
Short, concise description of the idea
Model it youreself with different pictures, icons, colours, fonts, backrounds, poems, lyrics, phrases, self-written thoughts or poems
Full description of the idea
Well alot of sites offer alot of different cards, but when I start looking for the right one mostly I end up with nothing, either the colours aint right, or the picture or poem etc etc
So I though since people come here to write, why not make it possible to create something here and send it to somebody you want, and not only to the people on lj but to everyone, simply entering an email address where it should be sent
The idea im talking about is, you could choose youre own pictures, icons, emotions, youre own colours, fonts, backrounds, youre own languages, sizes, shapes of the card, lyrics or poems, wishings, to be able to totally model it youreself, write on it youreself
Ofcourse there should be some examples of styles, pictures, writings and colours
An ordered list of benefits
To end the hopless searching for a appropriate card
To be able to make somebody happy
Getting a birthday notification you can make a birthday card right here
An ordered list of problems/issues involved
It might turn out to be too complicated
People might not be interested
An organized list, or a few short paragraphs detailing suggestions for implementation
It could be something similar to the journal modifying system
|
|
|
|
|
|
|
|
|
suggestions
algeh |
|
|
|
|
|
|
|
Title
Allow members to be added to closed communities without confirmation if they already watch them
Short, concise description of the idea
If a user already watches a community, it's a pretty good guess that they wouldn't mind being made a member. Thus, a community admin should be able to add them without them having to confirm it via email.
Full description of the idea
I run a closed community, squankygurps, which is for people who I know personally and who have an interest in participating in off-line, table-top RPGs. I keep it closed because it is common for members to posts things such as their addresses and phone numbers (since we meet at members' houses). I recently made an offer to members of animepdx, which I also run, that they could join and that I would add them if they friended squankygurps. One person did, and I just found it kind of silly that someone who had already gone to the trouble of friending a community also had to confirm that they wanted to be a member.
An ordered list of benefits
Those with email programs which do not make it easy to visit external webpages (such as pine), would not have to copy/paste a link (which is also pretty non-obvious when using the command line stuff in Windows XP, since it doesn't use ctrl-c for copy)
Users who were having trouble receiving email from LiveJournal could still join communities
It just seems to me that community membership should really be something contained within LiveJournal rather than something that requires emails to be sent
Immediate gratification for community admins
An ordered list of problems/issues involved
Someone might, theoretically, want to watch a community but be really upset if they became a member (I can't come up with a specific example, but it's always possible)
Might encourage people to friend communities as a way of begging to become members
An organized list, or a few short paragraphs detailing suggestions for implementation
Add in a check after an admin tries to add a member to a community. If the potential member already watches the community, have the system add them to the members list without further fuss. Otherwise, send it on to the code that sends the emails.
|
|
|
|
|
|
|
|
|
suggestions
bunsennbeaker |
|
|
|
|
|
|
|
Title
Preventing Comments from being Over Max Length
Short, concise description of the idea
Since (last I checked) comments are limited to a certain # of characters, make the comment boxes "stop" the users from typing if they reach the limit.
Full description of the idea
People (including me) get wordy at times. So far, if I have more than x number of characters to say, I get this screen saying to shorten it... sometimes, I can go back and retrieve the old comment, but I think that is a fluke considering it only works about 5% of the time. I've tried with 2 browsers on different computers, and it just doesn't do it for me. Anyway, instead of having to retype it all, would it be possible to make comment boxes like forms I have seen elsewhere that will make an icky ding sound and stop accepting characters if you go over the limit? I don't really like the comment character limit, but I figure this is easier to implement and subject to no abusive 50k character comments.
An ordered list of benefits
Self explanatory--no retyping of comments or having to "count" them in a word program if something is very lengthy. Also saves bandwidth because the person only loads the comment and verification pages once.
An ordered list of problems/issues involved
I know it is implemented elsewhere--college and job applications, contests that require essays, etc. have this encoding often. I don't know enough about coding to know how hard it is to program this into LJ.
An organized list, or a few short paragraphs detailing suggestions for implementation
I think it is really just changing something about the actual comment box's coding, which seems pretty universal around LJ, but I'm not the wizard :)
If this was suggested earlier, I apologize--I looked through all the comment memories and didn't see anything resembling it.
|
|
|
|
|
|
|
|
|
suggestions
msilverstar |
|
|
|
|
|
|
|
Title
Suspend or freeze journals (alternative to deleting them)
Short, concise description of the idea
A way for people to take a break without losing the contents of the journal.
Full description of the idea
There has been a spate of journal deletions and undeletions in my circles and it has caused a lot of stress. A lot of different reasons: a need to take time off, people reading it who shouldn't, personal issues, worry about friendships and relationships.
When someone deletes her journal, it breaks the larger community. All the things we wrote to her disappear. All the conversations evaporate. We may have saved the fics, but not the chat. It may not be meant to undo things so much, but it does. And that hurts.
A "suspend journal" function would solve some of these problems.
This would disable new comments, with options to make everything friends-only, to disable friends-list viewing (reducing temptation), and to switch email replies to another address, or turn them off entirely.
An ordered list of benefits
Provides relief for people who are inundated with LJ stuff.
Significantly less drastic than deleting a journal.
Allows us to keep the context and conversations.
Reduces vulnerability to stalking and exposure, especially if it can switch to friends-only.
An ordered list of problems/issues involved
Requires non-trivial programming and database changes.
Some confusion among users about what it does.
People may want additional controls and options I haven't thought of.
An organized list, or a few short paragraphs detailing suggestions for implementation
Probably needs some database fields or values, and additional checking on each journal display.
Needs UI work both for the controls and the journal display, to indicate that it's suspended.
|
|
|
|
|
|
|
|
|
suggestions
rpkrajewski |
|
|
|
|
|
|
|
Title
S2 Styles Should Always Allow Browser Defaults
Short, concise description of the idea
Allow "use browser default" as an option for certain common style customizations, and use that as a default as appropriate
Full description of the idea
Currently, many of the S2 styles specify colors for links, text, and background colors, and fonts, in their stylesheets. The defaults are taken from the defaults of the style. There doesn't appear any way to have the style refrain from specifying these things, and letting the browser take over from whatever defaults the user has selected in their browser.
Whether or not a style users "use browser default" as its defaults for particular customzations is up to the style designer, although I prefer that this be the case.
An ordered list of benefits
Principle of least surprise: user gets the same fonts and link colors (and hover behavior) that they see on other pages.
Not messing with these parameters respects accessibility for vision-impaired users.
An ordered list of problems/issues involved
Might require tweaks to S2 itself (I don't know enough about it). It is realy a simple matter of refraining from generating style attributes to go into the stylesheet.
Standard S2 styles would be to be evaluated and updated to show how it's done.
Some color schemes would not work well with typical link or text colors that are usual chosen at defaults in browsers.
An organized list, or a few short paragraphs detailing suggestions for implementation
If "use browser default" is the option, refrain from generating a stylesheet attribute directive so that the brower can take over.
When a style offers themes for combinations of colors, one theme could be associated with "browser default," refraining from specifying most style attributes, and using neutral or common choices for those design elements which can't be taken from browser defaults.
|
|
|
|
|
|
|
|
|
suggestions
skinglist |
|
|
|
|
|
|
|
Title
Validation Error Messages
Short, concise description of the idea
Validation error messages need to be consistent throughout the site. In addition, there should be a spot on the site where a user can check as to whether he or she is currently validated.
Full description of the idea
Currently, when you try to post to a moderated community via Semagic without a validated e-mail address it returns the message that is described here.
However, other areas on the site refer to it as 'validated' rather than authenticated--which can lead to confusion.
In addition, there does not appear to be a page that allows a user to check whether s/he is validated. I only found out when I viewed my support request, and I only knew that would tell me because I did Support for a year.
I think there should be a page (as there is whereami.bml for checking cluster) for checking validation status.
An ordered list of benefits
-less confusion
-a user knows instantly whether s/he is validated, transitioning, etc. Perhaps this page could also lead to the FAQ that tells how to validate your e-mail address in case the user doesn't know how.
An ordered list of problems/issues involved
honestly, I don't think this will have any drawbacks. Another page to the site? I don't think that's much of a problem. Feel free to let me know of any I'm missing.
An organized list, or a few short paragraphs detailing suggestions for implementation
-someone writes the code that checks for validation (similar to whereami.bml checking for cluster)
-page is linked to from site pages
-choose one term for the status of e-mail addresses (validated/authenticated/whatever) and change all error messages to say the same.
|
|
|
|
|
|
|
|
|
|
Previous 
