Support Category Userpics — LiveJournal

As you're all aware, the fix we hoped would take care of GIF userpics over 40kb giving the over 100x100 error didn't actually work. I've added this issue to the BBB to hopefully reduce the number of requests we get about it. (I thought of adding it before, but that was just as we though the fix was coming out, so I didn't bother, then I just kinda forgot about it.)

We don't have an ETA on when the bug will be fixed, because it's been difficult to pin down in dev environments. Obviously I'll let you know as soon as I hear anything.

So yes, fingers crossed for a reduction in requests!

Thanks to Abe and Mischa, these two bugs should be fixed after the next code push. For those not wanting to go to RT:

* GIF images that are within 100x100 but over 40kb will now get the proper "over 40kb!" error rather than the "over 100x100!" error.
* The UPF should work properly with communities -- userpics from personal accounts shouldn't be getting stuck when trying to use the UPF to upload a userpic to a community.

I'll let you know once the code push has happened so that we can look out for any further reports.

Users who try to upload GIF userpics that are over 40kb but under 100x100 are being told that they can't upload userpics over 100x100 if they're GIFs; this shouldn't be happening. Users should be getting a "Can't upload userpics bigger than 40kb" error. I've reported this and it'll hopefully be fixed soon.

In the meantime, if someone reports an "over 100x100" error when their userpic is less than that and they're trying to upload a GIF, tell them it's because it's over 40kb, which isn't allowed -- this is pretty much what we've been doing already. Please also apologise for the confusion and let them know that devs know etc. SHs, I've added a stock for you to use as appropriate.

A while ago, there was a glitch that caused some userpics for some users to mess up. The img tag will be present on the editpics and allpics pages, but the image won't show up. In these cases, the URL of the userpic will resemble http://www.livejournal.com/userpic//###### (note that the ID number of the userpic is missing). There should be no new reports about this, only reports that trickle in from people who were affected before.

To fix it, the user needs to upload a different userpic, set it as the default, and then delete the problem userpic. They can then edit their userpics however they like.

( The [ru] translation of the answerCollapse )

There was a time where we thought images with really high resolutions would cause problems with the UPF. However, this actually isn't the case; the problem lies with the metadata (such as information added to the headers of images by image editting programs or digital cameras). Information can be found in this RT ticket: http://rt.livejournal.org/Ticket/Display.html?id=1583

Mischa said that stripping the metadata wouldn't be appropriate, so instead an error message will be displayed saying something about there being trouble compressing the image (or something). This is checked in, but hasn't been pushed lived yet, and I can't give you an ETA, sorry.

I've added a stock for SHs/I3s to use. Before we can give it to anyone though, we need to get the user to give us a link to the image so we can check for metadata. Viewing the image's properties will probably give you information on any metadata it has (at least, Opera lays it out there clearly, so I'm assuming other browser's have similar bits).

I'm also not 100% sure on the whole being able to strip metadata deal, but I'm guessing it's possible. Still, that's NOP.

First of all, you can see the details about how the mood to keyword mapping works here. You should take note of how it works in regard to drop down moods vs. ones typed in to the text box. This part isn't going into the FAQ at the moment, as I don't think it'll be that big of an issue, and it's too much for an FAQ if it's not that frequently asked.

Secondly, FAQ 95 has been updated to include information on moods and keywords, so you can use that for requests regarding this now.

We all good now? Great.

I realised (through backlog in IRC) that I hadn't mentioned this yet. It has been posted to featureannounce and lj_userdoc (the change to FAQ 95 isn't done yet; it's in production), but not here. The patch to map moods to userpic keywords has gone live. The way it works is fairly limited and intricate, so here's a brief explanation:

Pick mood. If a userpic has a keyword the same as that mood, on site scheme pages (non-customised entry pages), that userpic will be used. If no userpic keyword matches the mood or the entry is viewed on a customised entry page, the default userpic will be used. Also, selecting a userpic keyword to use when posting will always take precedent to any mood that's selected.

If you don't understand anything, or you have questions, let me know.

The switching userpic bug is still around and wreaking just a little bit of havoc. When this first came about, the situation the process of dealing with them was quickly changing and, being that my online time is erratic at the moment, I didn't get the chance to pass along the information to you guys. I'm sorry about that.

Now, however, I do have some information for you. Some of you may have seen Carrie and me asking people for five things from the users who report this. We now only need three of them:

1) The URL for the userpic -- keyword is fine; we can find it on our own using that.
2) Description of what the userpic should look like.
3) Description of what it actually does look like.

1) is needed for the developers to collect information, and 2) and 3) are used to see if we're reproducing. If someone writes in to report switched userpics, please ask them for any of the above information they haven't already included.

We were asking for dates when the userpic was uploaded and when it first changed, but those aren't necessary anymore.

Supporthelps, I've added a stock you can use that asks for all 5 points, so you'll need to edit it appropriately for each request. Also, once you approve an answer on these, either your own or someone else's, please comment to this entry with the URL of the request. I'm going to use this request to keep track of the information so I can forward it on as needed. You only need to comment here when you're approving the first answer on a request; you don't need to comment when something regreens. Screened and interim volunteers, please leave commenting here for the supporthelps so that we don't duplicate effort.

If there's anything you need to know that I've left out or you have any questions, please let me know.

Thanks for your help, guys, and for being patient with me while I get this sorted. ;)

Getting started in Userpics is pretty easy; all it takes is a bit of reading.

Where to Begin

Familiarizing yourself with the following should get you set for answering the majority of requests:

• The FAQs. You should know exactly what you're referencing to the user.
• The most recent category documentation, which provides:
  • Policies. Aside from content, these will shed light on why you might have been passed over.
  • Error Messages. These are all the errors that a user can encounter while working with their userpics, and what each error means to us. It's incredibly useful for recognizing what to tell the user.
  • What is Userpics. Understanding what belongs in the category and what doesn't, which is a good resource for I2s+ (in any category) to keep on hand so they know where to move things.

Watching support_upi in addition to lj_support is also a good idea; sometimes we post notices, brainstorming, or troubleshooting here publicly for everyone to read or pitch in.

Reviews & Feedback

Remember to look over the approved answers on requests, especially on ones where you've been passed over. You can use this to teach yourself what the approved answer needs to look like – and if you can't tell, be sure to include the request and your comments in your next review.

Reviews should be about 10-15 links long, preferably with your commentary on all or most of the links (why you think you were passed over, why you think you were approved, questions, etc.); send your review request to support@livejournal.com and make sure to include 'userpics' in the subject line somewhere. Reviews are the best way to get feedback in Userpics.

It's also okay to ask supporthelps and/or admins about specific requests for feedback if they're around.

Common Issues

The most common requests are all answered by the FAQs, but it's not always obvious to new volunteers which FAQs best address a user's problem.

• The most basic questions should use FAQ1: "What are userpics? How do I upload them?" as a starting point, because it links to all the common Userpics FAQs. You don't need to do all the linking yourself; you can just say that the FAQ you referenced (FAQ1) links to whatever else they might be asking about.
• If a user wants to "get" a userpic, we give the aforementioned FAQ1. If a user wants to "find" a userpic, we give them FAQ194: "Where can I find userpics? How do I give credit for a userpic?"
• In the context of Userpics, if a user is asking about expired paid time or add-on space, give FAQ193: "What happens to my userpics when my paid account or add-on userpic space expires?" instead of the more general FAQ114: "What happens to my Paid Account when it expires?"
• Give FAQ98: "Why are there errors when I try to upload a userpic?" only if they mention an error message that's covered by that FAQ in particular.
• Two other FAQs that Userpics uses frequently are FAQ116: "Why am I having problems accessing pages on LiveJournal? What is "read-only" mode?" and FAQ160: "Why can't I see the most recent version of a page? Why is my journal or friends page not updating?" If you reference 116, it's not necessary to also use 160, as it's linked within 116. Be sure to use the one most specific to the problem at hand, however.

Miscellaneous Tips

• The user's userpic shown on the request links to their allpics.bml page.
• Comments start on a new line, but aren't labeled like keywords. It's easier to tell at some browser widths than at others. Another hint is whether the last keyword on a line has a comma after it.
• The only animated file type that LiveJournal supports is the GIF type. JPGs are static images, as are PNGs. There's another type out there called MNG, which is basically a PNG file that supports animation, but it hasn't been widely adopted. If a user is complaining that their userpic isn't animated when it should be, make sure it's the right file type.
• Uploading a userpic from a URL still saves the image to LiveJournal's servers, though there is a common misconception that it will "hotlink" or load the image from the URL instead.
• Default is just a special kind of keyword.
• Deleting userpics and then reassigning keywords (or in other words showing new images to entries with old keywords) is kind of tricky. Read through the deletion FAQ carefully, and experiment a bit to fully understand it.

Policy: All Userpics supporthelps are required to watch both lj_support and support_upi.
Explanation: Supporthelps should be aware of all the information posted to support_upi, including policy discussions, issue investigation, and training. Participation is encouraged and preferred, but not mandatory.
Side Note: It is not required that you actually "watch" the community in the sense of having it on your friends list, but the only other way I have of knowing you are keeping up is by participation -- in other words, if you aren't "watching," you will need to be participating in some way.

Policy: Do not suggest specific programs.
Explanation: It can come across as an endorsement. The user may also expect program-specific help. Point the user to a search engine; it’s also fine to provide search keyword suggestions.

Policy: Do not give program-specific help.
Explanation: It's outside the scope of LiveJournal Support. Point the user to a search engine; it’s also fine to provide search keyword suggestions.

Policy: Do not show a preference for a certain file type.
Explanation: It's not within the scope of LiveJournal Support to lecture users on the pros and cons of JPG, GIF and PNG. It is, if applicable, acceptable to briefly explain the differences of each file type.

Policy: Send questions to Accounts only when the issue is specifically about payment.
Explanation: Most of the time, requests can be handled publicly. Unless the user is specifically asking about the payment process, or there’s something we simply cannot figure out without the tools available to Accounts, it’s not necessary to move it.

Policy: If a user specifically mentions ‘taking’ a userpic from someone or somewhere, briefly mention that they should have the creator’s permission.
Explanation: The information is useful, relates to the issue, and may save both the user and LiveJournal from the trouble of dealing with copyright infringement problems later.
Side Note: The information provided needs only be very basic: the user should obtain permission to use the work of another person or entity. If they ask more specific questions, they should be directed to contact Abuse.

Policy: Only Userpics supporthelps should use the memcache purging tool for Userpics requests; the tool should only be used in situations in which the purge would alleviate the issue and not interfere with investigation.
Explanation: Memcache purging should only be used if information might be miscached by memcache; it tells LiveJournal to clear the server-side cache, forcing new data retrieval. Using it can make a problem go away, but if the problem is gone, we probably won’t be able to keep investigating it. The tool should be used with caution in general; when in doubt, double-check with admins.

Policy: Notify admins when reporting Userpics bugs/enhancements; only supporthelps should open Zilla items.
Explanation: In order to track issues for support_bugs lists, Issue Investigation, and Zilla, it’s important that admins be aware of what you’re reporting. If you’re adding something to Zilla, be sure to include the right CCs. Additionally, only supporthelps should open Zilla items to ensure that all information in the report is accurate and no effort is being duplicated.

Policy: Do not refer users to Zilla items.
Explanation: Never tell a user a bug number or give a link in your support reply. You may instead say that it's a known issue, that it's been reported, and/or that it's being investigated by the appropriate people. Offer workarounds, if they exist.
Exception: If the user is, for example, a support volunteer or someone else you know to be already familiar with Zilla, you may provide a link to the Zilla item.

Policy: Only supporthelps may use the stock answers provided.
Explanation: We want you to keep writing your own answers, using your own words, when you work on a request. Writing your own helps you learn both the Support writing style and how to think through the solution to the problem. Stock answers interfere with the learning process.