Title
Provide warning when editing user layer

Short, concise description of the idea
When someone is editing a user layer, provide a warning that it should only be used for defining properties that can be changed through the Custom Options customization area, and that other information can be lost.

Full description of the idea
A fair number of people seem to put custom S2 functions, and other custom code, as part of their user layer. I've seen unofficial tutorials that specifically instruct to put code in the user layer rather than the theme layer; I've known people that put code in the user layer because they want to be able to use the theme layer for different color schemes, or because they think that's What You Do, or because it's user-created code and therefore makes sense in the user layer.

Except that the way the S2 style system is set up, the user layer is automatically overwritten by the customization area, which means that custom code can be lost without warning or without possibility of backup. The layer-related S2 FAQs do mention this problem, and anyone who asks in support will be told not to put code in user layers, but a lot of people don't look at those FAQs and don't ask in support and so don't know there's a problem, until all their code gets wiped.

There are valid reasons why people might want to manually create/edit user layers. (For example, color theme switching -- if the custom functions are in the Theme layer, multiple user layers for the different color arrangements would mean that it's easy to switch back and forth without re-doing each customization each time.) So I don't think it should be disabled. However, there *should* be some form of warning -- something that appears at the top of the S2 editor, or a confirmation screen when starting to edit a user layer, or something -- informing the user that code can be lost without warning and they should probably do a theme layer instead.

(Preferably, of course, the warning would only show up for user layers; someone who's editing a theme or layout layer doesn't need to know that editing user layers can be bad.)

• People are more likely to be aware of the problems with editing user layers, since it's not very obviously documented
• Those people who pay attention to the warning and create a theme layer instead of a user layer will not lose code unexpectedly
• Those people who ignore the warning and work with user layers anyway can't claim they weren't informed ;)

• People who are actually trying to create a user layer might be offended/annoyed at the warning
• Also, a lot of people will (unintentionally) skip over warnings without seeing them, which may reduce the effectiveness
• Alternatively, if the warning is in a blinky neon marquee for visibility, I may have to spork my eyes out. *grin*

• Change the S2 editor to recognize when someone is editing a user layer, and generate the warning as appropriate
• Push the code live
• Get snarked at for changing something about LiveJournal...

Title
HELP

Short, concise description of the idea
Ack! The new menus don't include a dropdown for HELP or the FAQ's. They are hard to find now. Please add to one of the drop downs - perhaps FIND?

Full description of the idea
There is NO Help option listed anywhere in the dropdown menus as they were revised this week.

• Benefit - Being able to find HELP and the FAQ's easily and quickly at LiveJournal

• Help is commonly listed in this kind of menu as the last option or drop down. By eliminating it completely from the menu you have made the website harder to navigate, made help harder to find and that is not a good thing.

• I have no idea what this entails. As a user, my impression is it can't be too hard, or every other program in use on the internet and computers wouldn't list it this way. It appears to be the common accepted way to guide users to HELP and LiveJournal should adopt this standard to assist users in finding help at this site

Title
FAQ link needed in lynx layout

Short, concise description of the idea
FAQ link needed in lynx layout

Full description of the idea
FAQ link needed in lynx layout

Try saying ^that^ three times in a hurry. ;)

I've started using the lynx scheme because I'm now browsing LJ on my mobile 'phone (usually through Opera Mini). All is well and good, but while organising my account to be more mobile friendly I've come to miss having direct access to the FAQ link from my homepage (the friends filter page). It's not that I don't know where to find it, just that it's a PITA to go and look for it... especially while I've been playing with styles for the first time in ages.

Please add it somewhere relevant within the following list:

[ Home | Update Journal | Recent Entries | Friends | Login/Logout | Search | Browse Options | Site Map ]

• The FAQ'll be easier to find!
• The FAQ'll be easier to find!
• The FAQ'll be easier to find!

• Someone's gotta pick where in the list it's going, and someone else'll have to cut'n'paste the relevant 'a href' link from where ever else it may exist on the site.
• Oh yeah, and then remember to hit save. :p

• I reckon it could go at the end of the list, after 'Site Map', since the ends of lines are easier to find anyway.
• See 'ordered list of problems/issues involved' explanation for suggestions on implementation. :)

Title
Change template definition error message

Short, concise description of the idea
"User (foo) has messed up their journal template definition" is a bit derragatory and agressive.

Full description of the idea
"User (foo) has messed up their journal template definition" is a bit derragatory and agressive as an error message, and gives no direct help whatsoever to the journal owner on how to solve the problem.

• A more user-friendly, neutral and useful error message.

• None.

• Something on the lines of "There seems to be a problem with user (foo)'s journal template definition. If you are (foo), you can solve this problem ..." (point the user with a link to Journal Display).

Title
Add to My LJ/Portal

Short, concise description of the idea
Add the ability to link to lj_releases and lj_design from the LJ Announcements box in My LJ/Portal

Full description of the idea
Add the ability to link to lj_releases and lj_design from the LJ Announcements box in My LJ/Portal, giving users a stronger sense of connection to the LiveJournal community -- and less like new changes are being foisted off on them with no prior knowledge

• Enables dedicated LJ users to more quickly find out what's going on behind the scenes in LJ
• Saves users from having to subscribe to community

• Some users may not realize this option is available and will still complain about not knowing what's coming in LJ

• Add ability to subscribe to the lj_releases and lj_design communities to the LiveJournal.com announcements box

Title
"Uploading userpics filesize limit" notice

Short, concise description of the idea
The "Manage Userpics" page does not suggest the filesize limit of the pics that users should upload.

Full description of the idea
Though the filesize limit is stated in the FAQ, it is not on the "Manage Userpics" page. While I was trying to upload an 100x100 animated GIF, LJ told me an incorrect error message (a separate issue) that the pic could not be uploaded because it was not 100x100, which really confused me. In the end, I figured out it was the filesize of my pic that was the problem.

• Immediate and clear instruction on userpic limits.
• Save time reading through FAQ page to find the problem.

• Inaccurate/Incorrect error message (which I believe LJ Staff already know about)

• I guess it'd be simple to just type "Filesize limit: 40kb" or similar on that "Manage Userpics" page.

Title
Navigation strip - link wording/position change

Short, concise description of the idea
Changing the text of the "hide this message" link to something less ambiguous, to avoid user mistakes when removing the navigation strip.

Full description of the idea
With the navigation strip recently becoming switched on by default, a number of people who didn't want it have had difficulties in trying to remove it. I'd like to suggest changing the "hide this message" link to something a little less ambiguous, such as "hide this link" or "hide this option".

If one mistakenly clicks on this link hoping to remove the navigation strip, the option to remove it (the "change/remove" link) permanently disappears. One must then hunt through the FAQs or "Manage Accounts" menus to find the right place to turn it off. This difficulty is compounded by the fact that users may not know that the feature is referred to as a "navigation strip", even if they do look at the FAQs or appropriate settings menu.

The mistake is made all the more likely by placing the link in the top-right of the interface - a similar place to other "close window/bar" buttons such as those used in security/popup bar alerts in both IE and Firefox. Perhaps switching its position with that of the "change/remove" link would further lower the chance of mistakes being made.

• Making it easier/more intuitive for users to remove the navigation strip if desired

• May require similar changes in other (non-English) language settings, if the navigation strip is internationalized at all
  

• The position swap should be a fairly simple template change
  

Title
Hire a Technical Writer

Short, concise description of the idea
Hire a contract or full-time technical writer to consolidate, rationalize, and generally improve the Help available to users.

Full description of the idea
The Help system is one of the most frustrating I have ever encountered, with some information siloed in one area (FAQs), some in another (How-To), with confusing or non-existent links between the two. The tutorials are not tutorials (they don't provide the actual step-by-step instructions to complete tasks), and the information in them is partially useful at best (I could cite numerous examples, but telling me in the S2 documentation that something is similar to an aspect of S1 is not helpful). Finally, given the availability of HTML help authoring systems these days, there's no reason why the Help couldn't be a link that opens a separate file that enables users to view the Help contents while also having their appropriate journal page open.

Full disclosure: I'm a professional technical writer, and I'm looking for work.

• Improved overall user experience
• Improved use of all LJ functionality
• Fewer customer service requests

• You will have to hire somebody to do this work

• Put an ad on craigslist (or hire me), find someone with experience in working with online applications who knows how to write Help systems in RoboHelp or a similar app, and set them to work uravelling the spaghetti that is the current Help system.

Title
Snapshot Pic of Sponsored Plus Example Page

Short, concise description of the idea
Make a screencapture snapshot of an example sponsored page available so we can see what it looks like.

Full description of the idea
Make a screencapture snapshot of an example sponsored page available so we can see what it looks like. I personally worry that when I switch it will be too invasive with all the ads or just plain annoying, and I won't be able to switch back.

• It would make people more likely to switch to sponsored+
• More people switching to sponsored + means more money for LJ

• None

• None

Title
Create An Additional Account Type For Official LiveJournal Accounts

Short, concise description of the idea
Currently LiveJournal has four account types: Free, Early Adopter, Paid, and Permanent. LiveJournal should create an additional account type for official and officially-sponsored. This new account type would be called "Official."

Full description of the idea
As it stands, it is difficult for some users -- particularly new users -- to discern which journals and communities are official sources of information. Most offical accounts are Permanent Accounts, but not all Permanent Accounts are official accounts. Account name limitations now restrict users from starting accounts with "lj_" as this prefix is intended to be used for official accounts, but not all official accounts start with "lj_" (currently). Further, some journals and communities seem to be official, especially for less-savvy users, but are not; this has the potential to cause confusion when someone is looking for information, discussion, or announcements that come from an official source.



Official accounts are listed in the FAQ {{ http://www.livejournal.com/support/faqbrowse.bml?faqid=125 }}, but it can be difficult to locate FAQ 125, especially if you are a new user or unaware that this information is listed in the FAQ (or even that there are FAQs, which is more common than you might think). Creating an additional account type for Official Accounts, to display on a journal's/community's userinfo page makes it easier and more convenient for users to immediately tell if a journal or community is an official source of information and announcements.



The ability to create an Official account will be limited to Admins, naturally. Official accounts will still retain and enjoy Permanent Account status and benefits.

• Better distinguish official communities and journals through a more readily-viewable and user-friendly method.
• Helps eliminate and prevent confusion caused by inconsistent account naming conventions, account types, and potentially (for some) difficult-to-find or outdated (or at least potentially un-updated) documentation.

• None come to mind, other than the minor inconvenience for admins/developers to make this change.

• Create new account type: Official.
• Change account type of all official and officially-sponsored journals and communities to new account type.
• Update account-type and official-journal FAQs, and any other FAQs that discuss or reference account types or official communites and journals.
• Announce in news once completed so user-base is informed and aware of this.

Title
have a page describing LiveJournal's history

Short, concise description of the idea
have a gallery of sorts showing the various changes to LJ's design over the year

Full description of the idea
Show screenshots of LiveJournal as it undergoes design changes (eg. new browse styles, "banners" during the holiday seasons, different looks for the homepage)
Outline milestones in LJ's design/features history (eg. new homepage, My LJ)

• 1.allows users to know how the "face" of LJ has changed over time
  2.a simplified version of "news" without the hassle of digging through archives
  3.lets prospective users know that LJ is being constantly developped to be more user-friendly

• screenshots of how LJ used to look prior to implementation may not be available
  pictures take up bandwidth
  time-consuming to dig through archives to decide which are the memorable events

• 1.start taking screenshots every time LJ's "face" changes
  2.ask users for old screenshots if LJ staff don't have them
  3.set up a page to organize these information

Title
FAQ References on Edit Info Page

Short, concise description of the idea
Add links to appropriate FAQs on the Edit Information Page.

Full description of the idea
Since space is limited on the Edit Information Page, specifics about what each option does can't really be displayed there. However, for many of the options, there are corresponding FAQs that provide more information.

I propose to add links to the appropriate FAQ to the end of each description of each option.

• Less confusion about what each option does.
• If you haven't referenced the FAQ recently, it's right there.

• FAQ content and numbers change.
• Every option may not have an appropriate FAQ and some information would be missing.
• Finding acceptable placement for such links.

• ursamajor suggests adding more s to applicable sections.

Title
Stop hiding the FAQs!

Short, concise description of the idea
Stop using the cut-tag (or whatever's being used) to hide the full FAQs!

Full description of the idea
People don't read the FAQs often enough as it is - making them click yet again after going to $FAQ page is only gonna encourage people to read them even less.

Example: you go to the front FAQ page/give someone a link to $FAQ, and all you get now is the intro. part, to read any more you have to click the (read more) text - a lot of people just won't.

• Users may gain insightful knowledge on how to use LJ better by being able to read more of a FAQ without having to click yet another link (people're lazy remember)
• Haven't looked on the support board of late, but I bet hiding most've $FAQ hasn't made their (the peeps who have been in support of late) lives any easier

• Too much info. could confuse the easily befuddled, I s'pose - which is why I'm guessing this was implented in the first place?

• Get rid of the (read more) links and go back to how it used to be

Title
Less terse confirmation emails

Short, concise description of the idea
Include the details of what you are seeking confirmation of.

Full description of the idea
Currently emails get sent out which are so terse that they do not provide enough information for the recipient to determine if they should confirm the change or not.

As an example:

Your email address has been changed, click on the link to confirm.

Has been changed from what to what. How can I know that I am confirming my own change or the guy who is sitting right behind me in the computer lab. My girlfriend took down our email server, she may have updated my account so I still get the LJ mails, but I wouldn't know because there is no information.

How about this:

Your email address has been changed from fred@nerks.com to boo@gallooo.com click on this link to confirm. To report a breakin please click the following link.

• Significantly improved security.
  Significantly improved usability.

• Every mailout form-letter needs to be reviewed and extra data added.

• Sorry I can't hack php/whatever this is done in.

Title
Warn users when they hit the 100 limit in tags

Short, concise description of the idea
People are wasting thousands of hours tagging things because they don't know there is a 100 limit for viewing. They should be warned when they go over 100.

Full description of the idea
(dummy text because this field is not optional even though it claims to be)

• Thousands of hours of wasted work avoided.
• Happier users.

• Could possibly annoy some users who don't care if they go over the limit.

• If a user edits the tags or submits an entry with tags, check to see if one or more of those tags is over the 100 limit. If so, list each tag that went over on the confirmation page, and provide a link to the FAQ that addresses it. Also provide a link to edit the tags again, or to view the entry.

Title
Addition to the Download Client page

Short, concise description of the idea
A widget for OSX.4 Tiger exists for updating LJ.

Full description of the idea
At the Apple Download site for Dashboard Widgets, a LiveJournal Widget is available for download. I think you guys should list this widget for the client download page.

Mac OSX 10.4 TIGER is requied.

• Can post Directly from Dashboard.
• Easy "F12" key access.
• People can know about this widget.

• N/A

• Add these to the client download page for Macintosh.

Title
Label and document 'memorial accounts'

Short, concise description of the idea
Accounts that have the "memorial account" status should be identified as such on their info & main pages; memorial accounts should be mentioned in the FAQs.

Full description of the idea
LJ has a "memorial account" status intended to protect journals of deceased users from policy changes etc. However, I only discovered this when I filed a support request trying to figure out a discrepancy which turned out to be caused by this status. (I hadn't heard of the user's death, and hadn't thought to check the comments on his last entry, which was some time back.) There was no way for me to tell from viewing the user's info page that this was a deceased account. This behaviour also caused confusion among other friends of the deceased as to whether he'd removed people from his Friends list before committing suicide.


IMHO, it would be tasteful if memorial accounts were prominently identified as such on their info page (and probably on their main journal page as well). It would also be helpful if memorial accounts were documented in FAQs, including the appropriate way to notify LJ of a user's death - I know of another user who died three months ago, but her journal doesn't appear to have memorial status.


For reasons given in the drawbacks section, it would probably be good to have a required waiting period between a user's death/last edit and changing to memorial status (if that isn't already done).

• Avoids confusion as to account status.
• Avoids distressing people trying to figure out why they're no longer on a dead person's friends list.
• Helps ensure that deceased accounts *are* given the appropriate status.

• Finding out that a friend has died by looking at their info page is potentially distressing. (But no more so than finding out via a support request.)
• Increased awareness of the memorial status could lead to abuse (e.g. by malicious false reports). A waiting period would help prevent this but isn't a complete fix.

• Automatically add "This is a memorial account belonging to a deceased user" boilerplate (with linkage) to users' info page and main journal (the latter possibly as a final entry) when they are set to 'memorial' status.
• Document 'memorial' accounts, including behaviour of friends lists and how to report a user's death, in FAQs.

Title
Admin console: Listing commands per access level required

Short, concise description of the idea
Flag admin console commands per access level required

Full description of the idea
While many of the commands on the admin console are obviously not for J. Random Free User (e.g., the ones to adjust account balances and such), a helpful item would be to list the commands that are otherwise inaccessible to said users and/or list access level required to use them. Alternatively, one could create lists for each user level, and when a user of that level accesses the admin console guide, that list could come up.

• Makes use of the admin console a little clearer

• None forseen

• None known at this time

Title
Faster and better updates of status page...

Short, concise description of the idea
The status page needs to be updated faster, and with a more clear idea of what's going on.

Full description of the idea
I'll give a for instance: Multiple journals (and some portions of the site) have been dropping "database unavailible" errors since around 4:45am CST (09:00 GMT). The status page still listed information from the 27th of October (two days previous). It was finally updated to reflect the fact that the porkchop cluster is undergoing maintenance and is unavailible at apx 8:00am CST (13:00 GMT), a full three (plus) hours after issues began.

Not only was this a significant lag - in which we were left wondering - but the status page mentions only ongoing maintenance. Obviously maintenance on a cluster should not take four hours, and if it does it should be planned. If it is planned, a listing in news would be appreciated (or something similar). If it is a major issue requiring extended downtime (i.e. something broke), the status page should reflect at least a brief description of the problem at hand (i.e. "porkchop is broke, we're attempting to fix the cluster, journals therein will be unavailible until it is fixed, sorry."), instead of just saying "...undergoing maintenance..." as that makes us (myself, at least) think of a quick fix here and there... not a rediculously extended downtime.

(Rediculously extended downtimes are fine, every website has them occasionally as things break and need to be repaired. That, I don't mind. Letting us KNOW, however, would be nice. If this WAS planned maintenance, I can find no record of it that I - as a user - have access to.)

Additionally, it may help to include a detailed commentary (such as "The database in unavailible due to maintenance. We hope this will only take a short time, however you will be unable to comment/login/use your journal during this time" etc...), or auto-refresh to the status page when attempting to access a journal on a downed cluster.

Thanks.

• Users would know the true issue behind a problem, and might not be as upset if things are back to working pronto.
• Staff may be able to cut down on the number of support requests during extended downtime.
• When extended downtime maintenance is planned, users would be well aware of it and not be as worried.
• When major issues do happen, users would feel that there is more communication from the staff - as opposed to brushing us off with promises of simple maintenance that will be over soon.
• Users would be informed MUCH FASTER of downtime, and not be left wondering for several hours.

• Staff would have to think/work slightly longer at the status messages instead of tossing pre-canned posts onto the status page, this may impact time availible to work on issues (though hopefully not by more than a minute or so).
• Extended maintenance would have to be scheduled and notification given each time via news posting, etc..
• Staff would have to de-techify issues when posting to the status page.
• Some major code may have to be edited to implement the refresh function.

• Appoint multiple people the duty of updating the status page the moment an issue is discovered, and re-updating it with progress reports during work (as time permits), including more information than just "undergoing maintenance." This ensures that someone who gets called in with be able to do so, and the word would get out quickly.
• Make status page updating the first thing that is done when an issue is discovered - it shouldn't take long (if it does, make is easier/faster).
• Make extended maintenance - and scheduled maintenance - in news, so that everyone would see it (friends page, if not on the front page of the site), and update the status page a good few hours in advance.
• Include drop in the main page or userinfo pages of a scaled-down version of the status message (possibally at the top of the page, or the very bottom).
• Find a way to add a link to the status page (or direct-refresh to it) instead of "Sorry, database unavailible" when accessing downed journals/areas.

Title
Add "Translation Last Updated" string to translated FAQ entries

Short, concise description of the idea
Add "Translation Last Updated" string, just below "Last Updated" to translated FAQ entries. This will help both readers and translators to understand how old is current content in translated entry comparing to original english FAQ.

Full description of the idea
N/A

• Readers of FAQ will see how old current translation is and may decide that they should check english version.

• None

• Format should be same as for "Last Updated:" string. Also "Translation last updated:" string itself should be available in translation system.