From LJ Suggestions
Everything from suggestions that doesn't totally suck. (IE: anything non-obsolete, non-reactionary, and not related to details of LiveJournal.com's business plan and not LiveJournal-the-service).
(Built over time, la la la, categorize however y'all find appropriate...)
To ensure catching all useful entries from the community, please view by day ( http://community.livejournal.com/suggestions/2008/11/01/ ) or month ( http://community.livejournal.com/suggestions/2008/11/ ) rather than using the previous/next buttons on the entries, as some entries were posted out of chronological order.
Months from suggestions that have already been mined for useful suggestions:
- None yet.
- November '08 - ursamajor - DONE.
- October '08 - principia_coh - in progress
- September '08 - Magycmyste - in progress
- August '08 - ursamajor (ursamajor) - DONE.
- July '08 - squirrellyq (squirrellyq) - in progress.
- June '08 - ursamajor - in progress
- May '08 - John has mined, just needs to be added
- April '08 - tty63 - in progress
- Accounts Wishlist
- Community Wishlist
- Syndication Wishlist
- WTF Wishlist (Watching, Trusting, Friending) - anything to do with the actual WTF system.
- Watch Page Wishlist
- OpenID Wishlist
- Intersite Wishlist - is this different from "external services"? Or referring to LJ clones/forks?
- Interface Wishlist
- Multimedia Wishlist
- Posting Wishlist
- Commenting Wishlist
- Data Management Wishlist
- Styles Wishlist
- Support Wishlist
- Installation Wishlist
- Client Wishlist
- DWTalk Wishlist
Contents
Memories
- http://community.livejournal.com/suggestions/348380.html -- Option at time of entry creation to instantly make entry a memory.
This would be fairly easy to implement if actually wanted.
- http://community.livejournal.com/suggestions/349056.html -- Export memories by category (needs work to avoid huge hit).
- http://community.livejournal.com/suggestions/380025.html -- Indicate in archive view (or other places too?) if entry has been added as a memory (by me) (maybe public memory by others too).
- http://community.livejournal.com/suggestions/891542.html - Revamp Memories - "should feel like a cross between delicious and inbox management;" specifically, put categories/keywords on the left and memorified links on the right. Better ability to bulk edit/rename/move between memories cats. Better ability to see/find uncategorized memories. Add the ability to add a note to a memory, a la delicious?
Service-specific markup
- http://community.livejournal.com/suggestions/350836.html -- List of pre-defined people and/or entities that could be linked to in a way similar to another local-service user, except this would be defined per-journal by the user, for example, <lj cast="mymom">. Link would go to sub-page belonging to user, the space defined for "mymom", where the user could provide all the relevant explanation of the person and/or entity "mymom".
Inbox/ESN/Notifications
- http://community.livejournal.com/suggestions/887768.html - mark PMs as read after they've been replied to in the Inbox
- http://community.livejournal.com/suggestions/889605.html - 1. Don't allow blank PMs to be sent. 2. LJ form completion behavior - should be internally consistent, yes (PM form behavior mirrors Tag form behavior, for example - but should also be consistent with external standard form behavior?
- http://community.livejournal.com/suggestions/890016.html - refresh message count in headers when deleting messages in inbox (only on the page where the messages were deleted from, not cross-tab or cross-window)
- http://community.livejournal.com/suggestions/890470.html - need a better process for spam removal - fewer clicks, able to remove in bulk.
- http://community.livejournal.com/suggestions/890784.html = allow unformatted links in the inbox to be clickable.
Userpics
- http://community.livejournal.com/suggestions/881651.html -- Make anchor tags on the 'allpics' page so that when someone clicks on an icon associated with a post or comment for more information it takes you to that specific icon rather than putting you at the top of a page that may have almost 200 icons on it.
- http://community.livejournal.com/suggestions/356886.html -- Show stats on userpics use (most frequently used) (shinier would be most frequently used over time).
Moods
- http://community.livejournal.com/suggestions/380573.html -- Moods can show intensity via color modification (probably not suitable for all mood themes)
- http://community.livejournal.com/suggestions/384894.html -- paid mood themes
Site Schemes
- http://community.livejournal.com/suggestions/864581.html -- add "find:" search to Lynx, omg why was this not done back in 2003?
- http://community.livejournal.com/suggestions/888650.html - 1. Figure out better way to differentiate between screened and unscreened comments in Lynx. 2. Adjust alt text sensibly for screen/unscreen button - it says "screen" for both "to screen" and "to unscreen;" combined with the above problem, it's hard to know whether you're screening or unscreening a given comment!
- http://community.livejournal.com/suggestions/888876.html - Text links in lieu of image buttons? Similar issue as above - alt text not changing appropriately when situation changes ((un)screen, (un)freeze). Also, "is Lynx meant to be for mobile browsers? For visually impaired readers?" Make as clean and compact, codewise, as possible.
- http://community.livejournal.com/suggestions/871214.html - option to have a dark-background, light-text profile. Unsure if this is meant to be a sitescheme choice on the viewer-end or a personal "force this customization on the viewer" author-end.
Error Pages
http://community.livejournal.com/suggestions/889338.html - On the journal pages of purged accounts, link to "rename accounts page." Part of a larger point - non-sitescheme 404s such as journal pages are utterly useless right now. Should we force 404s into sitescheme with contextually appropriate links? For example, going to the profile page of a purged journal is in sitescheme; going to the journal or friends page of a purged journal is not. For ease of use, this needs to be addressed.
http://community.livejournal.com/suggestions/889458.html - On the pages of unregistered usernames, a link to "join DW;" also, links to "create a journal with this name" and "create a community with this name."
Suggestions
- http://community.livejournal.com/suggestions/892296.html - Ability to preview (and then edit) a suggestion during the submissions process. Enthusiastically supported.
- I don't think there actually is a suggestion in for this yet, but given recent Suggestions deletion drama, users should not be able to delete their top-level Suggestions posts. They should be able to disable receiving notifications from it, yes, but if a suggestion is posted and discussion occurs, even if it is entirely against the proposed suggestion, it is useful to have discussion pointing out all these issues archived to show people "this is why this suggestion is not such a good idea for DW," etc.
Statistics
- http://community.livejournal.com/suggestions/377309.html -- Extended site statistics.
Search
- http://community.livejournal.com/suggestions/419057.html -- Search for users with PGP keys
External Services
Et cetera
Some of these are probably categorizable, but I'm not sure where. --Ursamajor 05:15, 10 January 2009 (UTC)
- http://community.livejournal.com/suggestions/893954.html - Image placeholders. Applies across friends page and entries. Dre (need to find her userpage) points out that on-demand size detection is impractical especially for low-bandwidth readers (and would force images to go through DW's bandwidth for said detection, costing even more money), so the existing implementation of image placeholders is as good as it can be for now; still, upgrading the existing console command for customizing the placeholder size threshold to being in the settings would be lovely.
- http://community.livejournal.com/suggestions/386309.html -- redirect www.usersub.example.com to usersub.example.com so fewer people need to be fish-slapped.
- http://community.livejournal.com/suggestions/879620.html?thread=13611524#t13611524 -- friendbot preventative measure proposed by commenter: force completion of captcha for each additional friend an account adds after a certain number of friends are added in a certain amount of time.