|  |
Title
Better behavior on entry posting when over the tag limit Short, concise description of the idea
Instead of giving you no errors when saving, showing no tags, but displaying tags on the edit screen when you're over the tag limit and use mixed existing and new tags on an entry, the system should handle it better. Full description of the idea
So you have reached or passed the tag limit (if you created more tags than the tag limit before tags were capped, you may be over the limit), and you post an entry. You type in a tag you know you have, and a tag you think you have. You post. Success! You view your entry. No tags! You go to edit entry (not edit tags for some reason, because you don't feel like that today) and lo and behold, your tags are right there in the tags field where they should be. You view edit tags, and there are no tags. You ask Support, and someone tells you that the tags are right there in the entryprops.
This is (now) known bad behavior.
Obviously something instead of this should happen. Please shred the following ideas to pieces and contribute your own if you think of some.
Proposals: - Post with only the tags that already exist, not preserving any of the attempted tags. (Advantages: posts immediately which is good for Really Weird Clients and post by email. Disadvantages: no record of the tags you were trying to use.)
- Post only with the tags that already exist, but throw an inescapable (no-optout) email and inbox error that contains the tags you were trying to use. (Advantages: preserves tags, good for weird clients. Disadvantages: more notifications that people might ignore.)
- Post entirely without tags, with no error and no attempt at preservation. (Advantage: probably simple to implement. Disadvantages: legion.)
- Post entirely without tags, but sending error messages to email and inbox with the tags you were trying to use, all of them. (Advantages: immediate posting, tags preserved, possibly simple. Disadvantages include no tags, in addition to the above-mentioned problems with notifications.)
- On attempting to post, an error to the effect of:
"The following tag(s) could not be created, as you have 2,926 tags and the current maximum is 1,200:- this tag does not exist
- bunnies
- why me and frank the goat are homies
Please go edit before posting."
Advantages: a whole lot of information, consistent with other errors, tags preserved.
Disadvantages: Complexity to implement, may cause issues with Weird Clients (some clients will take error messages, some aren't so good at it) and/or email posting, entry is not posted immediately.
5 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
Title
Mailer Daemon / Failed Delivery Test For Inactive Accounts Short, concise description of the idea
Send a mass e-mail to inactive accounts. For those where a mailer daemon / failed delivery message is received back, flag the journal for deletion. Full description of the idea
There are currently 22,025,963 accounts that are not active in any way (calculated using http://www.livejournal.com/stats.bml). Many, of course, are names that people want but can't under the current method of treating inactive accounts.
So, why not do some sort of test to see if an account is truly inactive, abandoned, and does not have a proper owner?
My suggestion is for LiveJournal to put together a population of inactive journals. (Start with no comments / posts / few log-ins.) For the inactive journals, send a mass e-mail......a friendly one that says how we've missed you, how to delete accounts if they are no longer wanted, it's LiveJournal's birthday, etc.. (And as pointed out in the comments, this should be advertised all over the place so users know this is occurring.)
For any journal for which a "Mailer Daemon" message is recieved (a bounce message / failed delivery message), flag the account for deletion.
If there is no "owner" over the account, then that account should be deleted / purged and then made available to others. An ordered list of benefits
- Cleaning up abandoned accounts
- Make names available to those who want it
- More revenue for LiveJournal with rename tokens
- Bring back old members/people who forgot they had accounts
An ordered list of problems/issues involved
- Potential that an "abandoned" account is someone who died (depending on the populations the e-mail is sent to)
- Someone may want their account but forgot to update their e-mail address
22 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
Title
automatic ?date=YYYY-MM-DD links for paid users after ?skip=1000/2 weeks Short, concise description of the idea
Show link to view friends page by date for paid users after they have reached the ?skip=1000 / 2 week limit on their friends page. Full description of the idea
Paid users can view their friends pages by date, but this is little-known and not intuitive to reach. Similar to how you are offered date links for your journal in most styles once you've reached the skip limit, this should be offered for the friends page as well.
This revisits the concept from http://community.livejournal.com/suggestions/740622.html, which was made before the ?date= feature was offered. An ordered list of benefits
- Better feature discovery for paid users
- Ease of use = more people using it regularly and getting hooked on it = more incentive to maintain a paid account
- Fewer support requests and suggestions from paid users who don't already know about this
An ordered list of problems/issues involved
- The friends page uses server time to build itself, so there could be some confusion about seeing entries with a stated date that differs from the server date they were posted on. (This goes double for comms, where Date Out of Order does not exist.)
- Overlap between the trailing ends of ?skip= and the beginning of where ?date= starts, unless ?skip=1000 happens to happen at exactly server midnight.
10 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
Title
Generate correct embeds for Youtube videos in Atom/RSS Short, concise description of the idea
Livejournal should generate correct HTML in RSS/Atom for LJ entries which contain Youtube videos. Full description of the idea
When I make a Livejournal post with a Youtube video in it, the RSS and Atom feeds that LiveJournal generates for it are wrong.
Instead of including the original EMBED or OBJECT tag, LiveJournal is instead including the LJ-EMBED tag only.
The entire point of RSS feeds is to be able to present those items in feed readers and on other sites. And other sites, pretty much *by definition* do not understand the LJ-EMBED tag.
The fix is trivial. Livejournal should simply include the un-altered source of the post in the RSS feed, rather than the "sanitized" version. Include the version of the HTML that one sees when one does "edit".
Here is an example:
My post: http://jwz.livejournal.com/1122617.html
What I see when I "edit source" on that post: What is included in the Atom and RSS feeds at http://jwz.livejournal.com/data/atom -- This is, quite simply, a bug. But "support" replied to my email with a brush-off telling me to make a "suggestion" that this bug be fixed, so here we are.
An ordered list of benefits
- The RSS feed of my journal would be useful and correct.
An ordered list of problems/issues involved
- I guess if you like it being broken, this would be a drawback.
15 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
Title
Make the profile 'Journal Entries' link go to the calendar Short, concise description of the idea
Link to the journal calendar in the profile, using the 'Journal Entries' link Full description of the idea
I always expect the '#### Journal Entries' link in the profile of a journal/community to take me to the calendar. It feels weird to click on a link text that says '7,036 Journal Entries' and get sent to just the latest 20 on the journal homepage.
Also, there's a link to the journal homepage just above, at the very top of the profile, in big letters. And as far as I can see the calendar isn't linked to anywhere. If it's not in the journal sidebar or similar then you have to know the URL structure to get to it.
Suggestions:
1) Use the 'Journal Entries' link to send you to the calendar, which after all is the only reasonable way of navigating the total number of journal entries displayed in the link text
2) Alternatively, add a link to the calendar somewhere else on the profile page. I think it makes sense in that line of links to tags and memories and other ways of navigating non-recent posts, but that might be just me. An ordered list of benefits
- Consistent way of finding the journal calendar, regardless of whether the journal style has a link to it or not
- More people using this really very handy feature
- Better use of space in the profile by not linking to something that is already linked to (and otherwise very easy to find)
An ordered list of problems/issues involved
- Confusion for users who have learned to click on that link to get to the 'Recent Entries' page, of which I'm sure there are many
10 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
Title
Better "success" message for when a message has been sent. Short, concise description of the idea
Include the username(s) and/or subject in the success message after sending a message from the inbox. Full description of the idea
After a user sends a message from the inbox using http://www.livejournal.com/inbox/compose.bml , they are shown a generic message that says "Your message has been sent successfully."
A better success message would say "Your message to [list of users] regarding [subject] has been sent successfully." or "Your message to [list of users] has been sent successfully." An ordered list of benefits
- Better user experience.
- Better troubleshooting options when a user reports problems that may just be cache.
An ordered list of problems/issues involved
- Most of the other success messages are generic, so until those are corrected this would look out of place.
4 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
Title
ESN tag subscriptions: the editing-friendly version Short, concise description of the idea
Send out notifications for ESN tag subscriptions even when tags are added after posting. Full description of the idea
Our friend the ESN system does not send out notifications for tag subscriptions when the tags are edited in after posting. This is not good, particularly because lots of people like to add tags after the entry is posted, and then people who have subscribed don't get told.
Editing tags should trigger an event that temporarily saves the old tags, compares them to the new tags, and executes notifications for any tags that were not there previously.
(People who were notified about tags that are removed shouldn't be really considered, as there's no way to un-notify, really.)
This suggested implementation does not take into account the users who have subscribed to new entries on the tags that already existed on the entry, in the time between posting and/or the last edit of tags, and this edit of tags, but they presumably took a look at the journal and saw that entry before subscribing.
This does have the risk that an entry is posted with a tag and someone gets notified, the tag is taken off, then the tag is put back on again and they get notified again. Short of making a cache (maybe a week or two?) of notifications that got sent, I see no way around this, and anyway, people also get multiple notifications if someone edits a comment a lot. An ordered list of benefits
- Tag subscriptions work intuitively and as advertised.
- Users posting entries don't have to remember to tag them before posting.
- Users subscribing don't have to freak out about why they're missing notifications.
An ordered list of problems/issues involved
- Possibility for multiple notifications.
- Increased strain on the system.
- Someone who retags their whole journal using a tool that quickly untags, saves, and then retags and saves the entries. (Rate limiting of no more than 5 notifications in a single journal per hour on entries older than 2 weeks, perhaps? Making a cache of about 10 minutes and using the net tag changes from that?)
13 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
Title
Remove cake from sitescheme Short, concise description of the idea
The 10th Birthday Cake should be removed from the LiveJournal site scheme header. Full description of the idea
While all (ok, most) LiveJournal denizens are full of joy and mirth at the 10th birthday of the service, it is nearly the 11th year of existence of this service and thus the 10th birthday cake in the site scheme is nearly at the end of its time. It should be removed summarily with all honors and distinctions to be awarded at a later date. Perhaps a Site Scheme Hall of Fame, where it may rest with Dystopia and xColibur? That is, however, for another suggestion. At this juncture, I only request that the birthday cake be put away until such time as LiveJournal has another 10th birthday, which is to say, never to be seen again. An ordered list of benefits
- The site will remain current with the general time-space continuum that the rest of the world enjoys.
The cake will go AWAY.
The people who can not eat cake will stop being sad when they see the header. This will serve a secondary purpose of making LiveJournal more accessible to those with a cake allergy.
An ordered list of problems/issues involved
- The people who like cake might be sad...?
25 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
Title
Explainer Notes Short, concise description of the idea
A means of providing short, explanatory notes, in a link in a journal entry, so that those who don't know who "disgraced former boss" was, or what "the one minute rule" is can click on the link and be provided with a brief explanation (in the form of a short note written by the owner of the journal). Full description of the idea
In the course of writing a journal entry, one may, on occasion, refer to some person, entity, event, location etc that played a part in the journaler's history, for example...
"I got an email from disgraced former boss today, proposing that we work together on a project. Given the history, I had to laugh..."
That entry might make more sense to longer-term readers, who know (from previous entries) about the DFB, but newer readers may not know that. If the phrase "Disgraced Fomer Boss" could be linked to some short explanatory note (maybe a #bookmark in an FAQ list), those that need to can quickly look to see what this means. Yes, this could be achieved by linking to a previous entry where the story of said boss was told, but that might be a long way ago, not easy to find, or too long an entry for a quick explanation.
Having an area (possibly an extended and linkable part of the profile, or some special set of undated journal entries) where the author can insert a number of FAQ style entries, individually accessible by links, bookmarks etc, would enable the author to put in helpful explanatory notes. For example...
An entry in the FAQ - "my leg" might read... "When I was 18, I broke my leg in a motorcycle accident. Despite all the pins and metal plates, I am still very weak in the left leg. While I can walk and such like, it put an end to my sporting aspirations. Also, I've never been able to get on a bike again."
Which could be linked to in any number of entries where one might otherwise have to offer an explanation of why they couldn't accept an invitation to a hiking contest, assist them in moving house...
It could also be used in communities - with links for submission guidelines, judging rules, community etiquette etc...
It could be implemented as a linkable area in the journal/community profile, maybe as an FAQ, with #bookmarks for individual entries.
Maybe it could also be set up in the journal display like the Tags area - so much as you see a tag for "health", you could see an FAQ-tag for "my leg", and easily right-click on it to get the URL and HREF that in the journal entry.
An ordered list of benefits
- Easy means of providing explanatory notes
- Centralised place for useful information
- Saves hunting for when you made that entry explaining how you broke your leg
- Provides useful quick links for communities to community information
- Saves journal owners from forever having to explain why they can't play football
An ordered list of problems/issues involved
- Implementation - woued require work on the profile area
- Linkage - need to find an easy way to use it (other than opening a fresh window, seeking to that profile entry and copying the URL back to the entry where it is referred to).
- Need to find a way to show said entries (e.g. in a tag-cloud like display area) so that they can be easily got at by the author.
22 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
Title
cursors upload in gallery Short, concise description of the idea
accepting upload of files ext .cur and .ani in gallery, for layout purposes - and evtl .css too Full description of the idea
all objects necessary for layout modifications can be stored in LJ gallery - images, and to a certain extent, css, in the customize panel (when they're not too long).
customizing a cursor is a really nice feature, but as this file extensions .cur and .ani can't be stored in the galleries as well, you have to use the url of an extern location (cursors4u.com etc). which means: if their website is cancelled, or the cursor's url modified, no custom cursor in your LJ either. and not all sites allow uploading of selfmade cursors anyway.
so, if it was possible to store these .ani/.cur files in LJ, this would make sure the ressources don't disappear, and simplify the search for them while modifying a layout.
same applies to .css when the files are too long for storage in the customize journal panel. An ordered list of benefits
- all the elements for a customized layout would be in the user's own gallery, easy to get quickly where the user needs them.
no problems with linking to external websites which could get modified or deleted. An ordered list of problems/issues involved
- can't think of any, since it's only for storage.
these files are very small too and don't use much server space.
15 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
Title
View subscriptions on friends list Short, concise description of the idea
Provide option whereby subscriptions are included in friends list. Full description of the idea
When a user sets up a subscription to a journal or community (or a tag thereof), they would have the option of including the relevant posts in their friends list, instead of receiving email notifications. An ordered list of benefits
- Users can effectively friend a subset of an LJ, a kind of partial friending.
- Fewer email notifications.
- Centralisation of posts.
An ordered list of problems/issues involved
- Makes friending less transparent (although this is already the case, given that subscriptions exist at all).
15 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
Title
More Characters for Custom Stylesheet Box Short, concise description of the idea
On the Custom Journal Style page, it would be great for layout makers and people who enjoy those layouts to be able to enter more characters into the Custom Stylesheet text box. Full description of the idea
Once of the things I love most about LiveJournal is the ability to make lots of changes to a layout and really make it your own.
I don't know if many layout makers have met with this issue but, when creating customized layouts for other users, I've discovered that the Custom Stylesheet text box on the Custom Journal Style page doesn't always have enough characters for what the user wants me to make their journal do.
Styling all aspects of their journal (Flexible Squares), I am then met with users who want to change all their tiny icons and am unable to get the coding to work without removing major portions of the journal styling code I just finished.
I don't know how many characters this box allows but I'm hoping it you will let us enter more characters in the future.
Also, not sure if this is just in Flexible Squares or layouts across the board. An ordered list of benefits
- Happy Layout Designers.
- Happy users who are requesting the layouts.
- More flexibility for users, making it obvious that LJ is the place to be.
- More people wanting to use LJ and design their own layouts (thanks for the ability).
An ordered list of problems/issues involved
- I don't know if this would cause any problems with storing the data on your systems. That is all I can think of as a downside.
3 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
Title
Add 'view at source' link to video placeholder Short, concise description of the idea
If at all available, insert a link to the source page of an embedded video when the placeholder is turned on. Full description of the idea
Video placeholders replace an embedded video/object with a box holding the dimensions of the video that's supposed to go there, and cheerful little image; you click on it to see the thing. It would be ever so useful to have an actual link to the source page for the embedded video, if it's possible to get such a thing. An ordered list of benefits
- Gives some sort of idea about the content (is it a YouTube video, another known video provider, something you've never heard of, something you've heard of and want to avoid, and the link name may be enlightening)
- Fewer page loads if someone just wants to open the YouTube video in a new tab (one ctrl+click to open in a new tab; compare clicking on the placeholder, clicking on the video)
- Unlikely to cause more of a problem than if the original poster had thrown in a link to the source.
- Might give more options for users with accessibility issues (including screen readers and the like)?
- Probably more that people who feel strongly about this can share in the comments
An ordered list of problems/issues involved
- May not be technically feasible to extract useful source/home page information from an embedded item; when you dissect the code for a YouTube embed it gives you a page with just the video on it, not the one with the comments and all.
- Like the ill-fated Snap, this would involve slightly altering the way someone's entry is served to have something they didn't specifically put in there. (Though that's already happening with the placeholder to start with, as well as any client-side browser add-ons that might be changing things around.)
- The usual effort-to-benefit ratio, as I don't know how popular video placeholders even are, and this sounds like it might have hidden snags in implementation.
12 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
Title
RTE handling pasted usernames Short, concise description of the idea
When you paste a copied LiveJournal username into the Rich Text Editor, the Rich Text Editor should recognize it and treat it as a username. Full description of the idea
When you copy text containing usernames and paste it into the Rich Text Editor, the usernames turn into so much HTML. This can be really awkward when you're trying to work on the entry in HTML mode later, and burns through about ten times as many characters as you'd need to just do the <lj user=""> tag.
LJ has to have on file, somewhere, the pattern of code it uses to build the HTML for the usernames. It should therefore be not horribly horribly impossibly hard to build something that recognizes the current pattern in which LJ serves a username (the details of how LJ displays the username may change over the years, but the concept that LJ builds it and therefore should recognize it stays the same). Then it's just a matter of extracting the username, wrapping the username the <lj user=""> code, and inserting it into the RTE in the proper place, at speed, and without screwing anything else up.
Also/originally proposed by me on Dreamwidth. An ordered list of benefits
- Less space used in entries made via the RTE, which is a big concern.
- More intuitive to LiveJournal users
- HTML editor will display the expected code if you switch back over after using the RTE, to create or to edit
- Posted usernames are unlikely to break as LJ's server-side rendering of the user tags into proper HTML changes over the years (remember when copying and pasting the HTML from a username resulted in general brokenness?)
- If the thing does not recognize an out of date username format as a usernam, it should leave it alone, and at least it (hopefully) should be valid HTML.
An ordered list of problems/issues involved
- This may not be a common scenario
- It will take a lot of doing
- Someone could still have a page featuring usernames rendered with old code, and the old code could break and/or confuse the RTE. (Someone is unlikely to have a page loaded in their browser that they haven't refreshed for long enough to have the username build change, and less likely to then copy it and stick it in the RTE, but they could. More likely is that someone saved an HTML copy of a page.)
- Anything done to the RTE is likely to make the whole shebang break
2 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
Title
Show Date Out of Order enabled status prominently when editing Short, concise description of the idea
When the Date Out of Order option is ticked, show this status prominently on the Edit Journal page. Full description of the idea
Amazingly enough, the new incarnation of the Update page, and therefore the new incarnation of the Edit Entry page, conceals the Date Out of Order checkbox until one clicks upon the Edit Time link. Thus, upon editing, an unwary user who is not wise to the ways of this particular user interface can be gulled into thinking that because this box is not immediately visible, it is not set.
This, of course, can lead to confusion, panic, entries not being on the friends page, unintentional wrong information being given to Support personnel, and updates from two years in the future.
To remedy, while a bright red flashing thing might be in order, a simple "Date Out of Order Enabled" text below the timestamp would work. Or even displaying the time with the edit bit already open. An ordered list of benefits
- Less confusion about which entries are Dated Out of Order
- More accurate information being given to Support
- People solving their own problems without need for intervention by someone who can view entryprops and tell them what's what
- More intuitive user interface
An ordered list of problems/issues involved
- Inconsistencies between the Update and Edit Entry page might pose a problem
- One more thing to display that could confuse a user
9 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
Title
Notes for paid communities Short, concise description of the idea
Communities could really, really use notes. Full description of the idea
Revisiting the basic concept brought up in http://community.livejournal.com/suggestions/892471.html: community maintainers could really use the notes feature that exists now, even if only on the ban page, but ideally the fully-functioned notes feature. An ordered list of benefits
- Makes community management much, much easier.
- Another excellent reason to get and keep a paid community.
- Group note feature while banning could be used to set a date for a cluster of banned users.
An ordered list of problems/issues involved
- Possible confusion if no-one knows who set a particular note.
- Maintainers could perform actions to community members using their personal journals (for example, via the contextual hover menu) and be confused when it did not take effect in the community.
- There is no automatic date stamp on the notes.
7 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
Title
Embedding Google Waves in LJ Short, concise description of the idea
Enable Google Wave to make a post in LJ, which also embeds an entire Wave in said LJ post. Full description of the idea
Blogspot and Wordpress already have bots or plug-ins embed Google Waves into Blogpost or Wordpress posts, and it'd be great if LJ has something like that too.
The entire wave is embedded in the post, so other Wave users can interact with the embedded wave as if they were in their own Wave clients i.e. they can edit and reply to the Wave, they can input their own content through drag and drop, they can use the Playback function etc.
For a demonstration of the Blogspot-Google Wave integration, please see minutes 3:11 to 4:15 of this video here: http://www.youtube.com/watch?v=p6pgxLaDdQw
And the WordPress plug-in is here: http://mashable.com/2009/09/08/google-wave-wordpress-plugin/
Resources LJ will need to implement this here: http://code.google.com/apis/wave/ An ordered list of benefits
- Richer user interaction without taxing LJ, since it's the Google Wave that's doing the heavy lifting.
- Integration with one of the most exciting new products on the Internet makes for a great reputation for LJ.
An ordered list of problems/issues involved
- There should be at least one person on the LJ Dev team who already has a Developer's Preview.
20 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
Title
Allow set 24h time format for comment timestamp in Dystopia scheme Short, concise description of the idea
Currently all comments in Dystopia scheme have AM/PM time format and there is no option to configure it Full description of the idea
Would like to configurable parameter to set time format for displayed comments to Europe common 24h An ordered list of benefits
- In Europe 24h format is common
An ordered list of problems/issues involved
- AM/PM format is not used in Eastern Europe, we use 24h
6 Comments | Post A Comment | Add to Memories | Tell a Friend | Link
|
|
|
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
![[info]](http://l-stat.livejournal.com/img/community.gif){kind=small}