Web-UI Reference Library

DRAFT: The Culprits: Current list of privs

2006-04-15T17:24:03Z

This list is intended to track privs by merit, rather than privs as recorded by the system. Please let me know if I missed anybody or got any wrong, which I'm sure I did. (I have blanket-decided that all admins are I2s in Web by merit if they weren't SHes before, since honestly, if any of you want to work on Web I'm not making you start out at screened. I mean, seriously, that would be screwed up. If any of you guys decide to get reviews, your next step will be merit I3.)

I1

I2

I3

pauamma

SH

Admin

idonotlikepeas

DRAFT: Memcache, and other Blacke Magick

2006-04-15T16:35:05Z

What is a memcache? Is it like a cache that tells you what X-man you are?

If you're not familiar with web caching in general, hit up the web-cache training post before reading this one. All set? Good.

Memcache is a system created by the LiveJournal development team to reduce load on their database servers. (It has since been adopted by other sites, but its primary users and maintainers are still affiliated with LiveJournal.) To explain what it's for, we're going to have to explain a little bit about how LJ (and lots of web apps) work. The way a page on LiveJournal is generally loaded is this:

Trust me, it's less complicated than it looks. The lines of this color represent an actual connection, the lines of this color represent paths the connection could have taken, and lines of this color represent the database's internal syncing mechanisms. So here's what's happening:

You enter a LiveJournal URL and hit return.
Your browser talks to the load balancer.
Unbeknownst to your browser, the load balancer goes out to find a web server to answer the request, and puts you in touch with that server.
For (mostly) unchanging content like images, this is as far as we need to go. The web server sends the content back to your browser. But most pages on LJ aren't unchanging; they're dynamic. So what happens next is that the web server goes to ask the database server to generate the content on it.
The database server digs out your journal entry (or any other dynamically-generated stuff) from its internal storage, and passes it to the web server, which then integrates it into the page and sends it back to you.
If you changed anything in the database when you hit the page (by updating your journal, for instance), the database server that you were talking to passes those changes to the other database servers. This process is called replication.

This picture gets more complicated when we talk about clusters and I'm elliding some subtleties about master/slave database relationships, but this is close enough for government work.

The problem with this system is that the connection to the database server is expensive, because that's where all the data really is and accessing it frequently involves talking to a bunch of disks. (When dealing with computers, disks are generally the slowest part of the system.) Ideally, as few connections to those servers as possible should happen. So what memcache does is store the results of your database query on one of the web servers when you make it, just like your browser cache does. Next time someone asks for that same piece of data, the web server figures out which server should be caching it, and checks there first before getting in touch with the database server. When you change that piece of data, the web server erases it from the cache when the database server is updated so that the next query will see the real data instead of whatever was there last time someone looked at the page. This cache is stored entirely in the memory of the machine (hence the name memcache), which makes it very fast.

This all sounds great, or at least it did once my head stopped hurting. So what's the problem?

There are a lot of things that can go wrong here, but there are two that are of primary concern to us:

Replag

Replag is short for "replication lag". This occurs when the database server that you sent your data to doesn't immediately update the other database servers about it, usually because it's a lot busier than it usually is for some reason. If this happens, you might connect to the wrong database server and see the old version of the data instead of the new one, and it's a piece of data that gets memcached, that old data might get put into the cache. If it's not memcached, this can result in someone seeing different versions of the page every time they reload it (since which web and database server you get sent to is, from your point of view, totally random.

Stale Memcache

If the memcached version of a page isn't cleared when the page is updated, the old version will still appear to be there (even if the new version has been properly stored in the database). This looks very much like a browser caching problem, except clearing the cache doesn't help with it.

So what can be done?

Most problems like this can be solved by time. And because they initially resemble caching problems, this means we'll never see them; we tell the user to clear their browser cache, and in the time between when we say this and when the user reads the answer, the blockage has been cleared and all is right with the world again. If the page gets updated by the user, that will also generally clear things out. Some problems of this kind are more persistant, though.

Web SHes have access to a tool that lets them clear the memcache for a particular user. In cases where a page is stuck in an old state, we're 100% sure that the page should be updated, and the old state is visible to the volunteers as well as the user (hence not browser cache), this tool can be used on the user that owns that page to force it to update. This is not a step that should be taken lightly, because it puts a lot of strain on LiveJournal's system to repopulate all that data, which is why use of it is restricted to SHes. However, if you're an interim, and you think a problem may be due to memcache, please IC and explain why you think this; just because you can't run the tool yourself doesn't mean you can't help out, and SHes aren't all-knowing. This tool also isn't perfect; it purges most things, but not every single conceivable memcached thing attached to a user. So if you don't notice any change in the user's journal after purging (and you've cleared your browser cache), it didn't do what you wanted.

web_ui @ 2005-07-25T09:18:00

2005-07-25T13:19:16Z

Hi there! One of your friendly neighborhood web admins speaking.

We're going to be retooling the documentation in this community. Until we're done, it'll be locked down; I've removed most of the members, and set up membership as closed. The new docs will be posted friends-only so that they can be reviewed and commented on before becoming public information. The old docs in public posts will continue to be available until the new docs are ready to replace them, of course.

Please feel free to keep watching this community; once the documentation is ready, a public post will be made announcing that fact.

Thanks!

Guide to some basic web-ui requests

2004-08-25T21:15:11Z

This document is intended to address the most common questions asked in web and how to go about answering/troubleshooting them. It shouldn't be viewed as a comprehensive list of all things that you'll ever see in web, but as a good starting point for common issues. Remember, in many cases, there isn't one specific 'correct' way to answer a request; it's just a matter of ruling out possible causes. Sometimes, you present the most likely answer, and offer the user a chance to regreen if that answer doesn't work for them. The elements of diagnosis and the guide to known issues, elsewhere in this community, will be of help.

Cache/Login:
Entry posted isn't appearing on most recent entries page.

How to answer: first, check the user's journal and calendar to see when the most recent entry was posted. If there's a public entry posted recently, inform the user they're viewing a cached version of the page and direct them to FAQ #160. If, based on the calendar, it's a non-public entry, inform them they've likely been logged out and to view FAQ #162 (which also links to 160 in case it's just cache). If there's no evidence of the entry having been posted, inform user it's possible they were viewing a cached version of the 'succesful update' page, that the entry never reached LiveJournal and that they'll need to re-post it. Also direct them to FAQ #160 to clear their cache.

User says they're being told 'you are not signed in' every time they try to do something and they keep signing in just to get the same problem again.

Inform user they really are being logged out of LiveJournal; direct them towards FAQ #162.

User states that they are certain they've typed their username/password correctly but it is not allowing them to login.

Inform user that the default login page requires that they have JavaScript enabled. Advise them to alter their browser settings to enable JavaScript, or upgrade their browser if it doesn't support JavaScript. You may also wish to inform them that other programs such as anti-virus software, firewalls, pop-up blockers or spyware may be the cause of the problem. Advise them to clear their browser's cache with a reference to FAQ # 160 as it's possible the challenge has timed out. Also direct user they can login at http://www.livejournal.com/login.bml?nojs=1 if other troubleshooting steps fail.

Comment posting:
Post comment or preview buttons are not displaying.

Inform them that in order to see these buttons, their browser must support JavaScript and have it enabled. Advise them to alter their browser settings to enable JavaScript, upgrade their browser if it doesn't support JavaScript. You may also wish to inform them that other programs such as anti-virus software, firewalls, pop-up blockers or spyware may be the cause of the problem. Also suggest that they make livejournal.com a trusted site or lower the security settings for it, particularly if they're using IE, because we think there's something weird with IE.

X-Colibur problems:
The blue bar at the top of the page is overlapping other text.

This is caused when the user is using the X-Colibur site scheme and doesn't have JavaScript functioning properly, or they're using an older browser that doesn't properly support CSS. Advise them to alter their browser settings to enable JavaScript, or upgrade their browser if it doesn't support JavaScript or CSS. You may also wish to inform them that other programs such as anti-virus software, firewalls, pop-up blockers or spyware may be the cause of the problem. Also direct the user that they may simply wish to switch to an alternate site scheme and point them to FAQ # 186.

Navigation features such as "Journal" or "Manage" do not drop down to anything.

This one is weird, and it took us a while. Basically, it means that they're not properly loading the CSS file that governs all of that, and *that* means that their computer is somehow blocking stat.livejournal.com.

Therre's a lot of reasons for this, but here's the answer that I use, and it's free for use by anyone; just be sure to customize it to the user's situation. Also note that this answer applies to things such as userpics or (LiveJournal-hosted) mood themes not loading.

LiveJournal loads images (such as the padlock icon, the mood icons, etc, etc) and stylesheets (used to control the layout of the XColibur scheme) from another server, which is not located on the same network as livejournal.com itself. This is due to bandwidth considerations. In order to display these images, you will need to make sure that you have not selected any options in your browser to disable images that do not load from the same domain as the main page's location; many browsers have this option, in order to block banner ads or other forms of advertising. This can cause the problem you are experiencing.

Other users report that the installation of some programs, such as Kazaa Lite, will install an entry into your HOSTS file that will automatically block access to stat.livejournal.com. LiveJournal cannot provide information on how to remove that entry from your HOSTS file, as it will involve changing settings on your computer and LiveJournal cannot be responsible for such alterations; however, you may wish to perform a web search, using your favorite search engine, for instructions on how to remove entries from your HOSTS file, and, if you are comfortable making such alterations, remove the entry that blocks access to stat.livejournal.com.

XColibur pages not displaying properly, generalized problems

If neither of the above situations seems to work, suggest that the user clear their browser cache (with a link to FAQ 160) and make sure that they have JavaScript enabled in their browser, then suggest they use an alternate site scheme (with link to FAQ #186).

Rich Text Editor:
The Rich Text Editor does not work properly/at all.

Inform user that the Rich Text Editor only works for some browser/operating systems. Advise them to alter their browser settings to enable JavaScript, upgrade their browser to the most recent version, or switch to a different browser if the one they are using doesn't support JavaScript. You may also wish to inform them that other programs such as anti-virus software, firewalls, pop-up blockers or spyware may be the cause of the problem.

Client Error: Missing Required Arguments
User tried to post something but received Client Error: Missing Required Arguments

Inform user that this occurs if any of the following information has been omitted: date, time, username, password, and the text of an entry. Provide link to FAQ #162 in case they are being logged out.

Friends:
An Entry does not appear on the friends page of a user and they should have access to view it

Possible causes include backdating (reference FAQ # 91), viewing a cached version of the page (reference FAQ # 160), user logged out if the entry is non-public (reference FAQ # 162), having setup a custom friends filter called "Default View" and not including the person whose entries aren't appearing (reference FAQ # 102) or memcache.

You don't want to include all this information every time. All of the following assume an entry is public: In the case of Default View, you can test by visiting the person's friends page and adding ?filter=0 to the end of the URL. You can also rule out cache by visiting their friends page; if you can see the entry, have them clear their cache. If you aren't able to see the entry they refer to, it's not a caching issue. Backdating can be tested by using a test journal, adding the user in question to your friends list and checking your friends page to see if the entry displays. If it does, it's not backdated; if it doesn't, it probably is.

There's an ongoing problem with friends not properly appearing, and we don't know what's causing it. If you can't figure out any other cause, suggest that they remove and re-add the friend, and regreen if that doesn't work.

A username does not appear on the edit friends page, but does still appears on their friends list in userinfo.

If they provided the username, first off check their userinfo and see if you see the name. If not, inform them they're viewing a cached version of the page and direct them to FAQ #160. If you can see the name or they didn't provide it, they may have banned the user from their journal. Advise them to unban the user (FAQ # 20), go to their edit friends page, remove the user, then ban the user again. If they haven't provider the username of the person in question, you can generally direct them to clear their cache first, if that doesn't work, try unbanning, removing, rebanning; if that doesn't work, comment back with more information.

File could not found error when accessing friends page.

Assuming that the user is using a Mozilla-derived browser (Mozilla, FireFox, etc) according to the User-Agent string submitted with the request: Inform user that this is a known problem with Mozilla browsers. By either adding or removing the trailing / from the URL to their friends page, they should be able to access the page correctly. You may also want to advise the user that they can switch to an alternate browser if they do not want to encounter this error.

Journal Creation:
User is unable to access the create journal page

Inform them that this page requires SSL and they will need to enable it in their browser to complete the creation process.

User cannot complete the 'prove you are a human' (also known as CAPTCHA) test.

Ocassionally there will be problems with CAPTCHAs being served; first check the rest of the board to see if there's a number of requests about this. If there are, wait for permission from an admin to call it a known issue. If there aren't a large number of requests related to this, advise the user to refresh the page to receive a new CAPTCHA, direct them to FAQ #184 for trying the audio version, and direct them to clear their cache with a reference to FAQ #160 if refreshing was unsuccesful.

Open Proxies:
Error message that user's IP address is detected as an Open Proxy and they cannot comment anonymously

Direct user to FAQ # 203 for information on how to resolve problem. If they regreen, direct them to spamhaus.org to try their IP address in the SBL/XBL lookup and to point their Internet Service Provider to it if it's listed.

Quick Reply:
The quick reply feature is either not working or behaving incorrectly

If the user mentions the feature not working all the time, inform them it only currently works in journals using S1 or which have 'use old comment page style' enabled. Advise the user to alter their browser settings to enable JavaScript, upgrade their browser or switch to a different browser if it doesn't support JavaScript. You may also wish to inform them that other programs such as anti-virus software, firewalls, pop-up blockers or spyware may be the cause of the problem. Also inform the user they can disable the feature by going to http://www.livejournal.com/admin/console/ and entering "set disable_quickreply 1" without the quotes. They can re-enable it by performing the same command and changing the 1 to a 0. http://www.livejournal.com/community/lj_support/484548.html

Server Weirdness:

The user mentions that they can see their entries on their friends page, but not on lastn/edit entries

Contact rahaeli & markf; that's replication lag (one server on the database cluster is behind) and needs to be dealt with on the server-end.

Misc. other problems

Check in with Status, lj_maintenance, and Rah and Mark to see if it's a known issue and if so, what sort of response should be used.

Adware/Spyware

Whenever you see an unfamiliar entry in the User-Agent string of the diagnostics, it's a good idea to Google it and see if it's adware. One common adware showing up a lot is "FunWebProducts", which has caused many problems with browser crashing, etc, etc, while attempting to use LJ. If you see this, even if you think it's unrelated to the issue, you should tell the user to search for some adware removal software.

Last updated: 25 August 2004

Guide to Identifying and Resolving Known Issues

2004-02-09T06:43:02Z

In Review: What is Web-UI?

Web-UI is a specialist category that deals with how users deal and communicate with LiveJournal's back-end (code, servers, and database). In particular, we deal with problems users are having with LiveJournal's code, servers, or database, and try to find resolutions to them. We do not, however, deal with questions concerning the normal use of LiveJournal's features (user education).

What sort of requests fall under the scope of Web-UI?

The web category deals with three basic types of requests:

Something is not working as it should, and volunteers cannot reproduce it. -- This is generally caused by an error in the user's browser or computer settings.
Something is not working as it should, and volunteers can reproduce it. -- Issues of this type fall into three categories: bugs, features working as intended, and direct user error. It is important to note that only user reports of bugs fall under the scope of the Web-UI category. If something is working as intended (just not as the user expects), this falls under the scope of another category, as it requires only user education. If something is due to direct user error, such as incorrectly written overrides that cause their 'most recent entries' page not to display, this is again an issue of user education, and is not dealt with in Web-UI.
Temporary errors outside the control of LiveJournal support -- These are issues such as users not being able to reach the site or receiving error messages due to site overload. Problems with database clusters also fall under this category.

This tutorial will deal with identifying and resolving reports that fall into category 2: a feature on LiveJournal is not working as expected.

For information on how to determine the difference between "user education" and "LiveJournal bug", please see Web-UI: Revisiting the Category. That tutorial will teach volunteers how to identify whether or not a particular issue falls under the scope of Web-UI or not.

The workflow for identifying whether or not something is a bug in LiveJournal's code can be (over-) simplified as follows:

Can you reproduce the situation, following the same steps that the user is reporting?
- YES: Go to step 2.
- NO: Ask the user to clear his or her browser cache, log out of LiveJournal to re-set his or her cookies, and perform other basic first-order troubleshooting steps. If this does not help, ask yourself: "What is different between the user's circumstances and my circumstances?" Good points of differentiation to look at are: Is the user paid or free? Is the user on a specific cluster? Is the user a member of any communities? Does the user have different things listed or not listed in their user information page? (bio, interests, etc). Then, go to step 3.
- INSUFFICIENT DATA: Ask the user for as much information as you can. Any of the following questions might prove useful, depending on the situation: what steps they are taking to produce the effect, what they're doing at the time of update, what text they are attempting to update with, what friend they are attempting to add, what browser and operating system they are using, what Internet provider they are using. Once you obtain this information, go back to this step and try again.
Is this expected behaviour for this feature or element?
- YES: Transfer the request to G/unk as a matter of user education.
- NO: Go to step 3.
- INSUFFICIENT DATA: Ask someone more familiar with LiveJournal's expected behaviour, or leave the request for someone else.
Has the code governing that particular feature changed recently? See: "Determining Code Changes", below.
- YES: If you can reproduce the behaviour or determine a common thread among all users reporting the behaviour, this is a bug. See: "Reporting Bugs", below.
- NO: Go to step 4.
Have any other environmental changes happened recently (such as: server crash, servers unavailable, changes to LiveJournal's backend, etc). See: "Determining Environment Changes", below.
- YES: Contact the admins of the Web-UI category to determine if such changes might cause the problem.
- NO: Go to step 5.
Is the problem intermittent? (Does it happen to the user every time that the circumstances are the same, or only from time to time?)
- YES, the problem is intermittent: Encourage the user to provide as much information as possible to determine when the problem happens and when it doesn't, then go back to step 1 and try to reproduce the problem with your own account under as many of the same circumstances as you can.
- NO, the problem happens consistently: If there are no code or environment changes, and the problem still happens consistently, contact the admins of the Web-UI category. They will then get in touch with a LiveJournal developer or employee who can help with further troubleshooting and diagnostics.

This is obviously a very simplified version of the Web-UI diagnostic workflow, and not every request will fit into it. The key thing to remember when working in Web-UI is that not every request will be solved on the first contact with the user, and it is perfectly acceptable to offer potential solutions with each answer, while encouraging the user to provide more information if the solution you offer does not work. For instance, someone complaining that their entries are not appearing on their friends' Friends pages should be asked to perform the first-order diagnostic steps of making sure that they are logged in, clearing their browser cache, and checking to make sure that their entries are not backdated, while also being invited to provide more information (such as links to specific entries that are not appearing) if those steps don't resolve the issue.

Finding Information on Known Issues

There are several things that someone can mean when they say that something is a "known issue":

A Zilla item has been opened up regarding the issue
The issue has been added to the "Known Issues" box at the top of http://www.livejournal.com/support
A lj_support, learn_support, or support_web post has been made regarding the issue
The admins of the Web-UI category have been notified of the issue directly
Developers have been directly notified of the issue (through comments to news, lj_maintenance, or lj_dev, for instance)

There is currently no one place for Known Issues to be recorded and documented, because of the number of different ways for things to be reported and identified. As a volunteer in Web-UI, you should follow the steps in "Reporting Bugs", below, if you believe that you have identified an issue.

No one person can ever be aware of all issues, due to the complexity of the LiveJournal code; don't ever feel like a failure because you can't keep all of the issues in your head at once. There will, unfortunately, always be duplication of effort involved in identifying issues. The ultimate goal is to use all of the resources at your disposal in identifying issues, so that you don't waste time diagnosing and reporting something that's already been reported or is already being worked on.

Using Zilla to determine Known Issues

The first step in determining if an issue is a Known Issue is to turn to Zilla, LiveJournal's bug-tracking system. A basic tutorial on how to use Zilla is located here. This tutorial is mainly geared towards entering bugs in Zilla. A basic, stripped-down version of a Zilla query can be found here. This post in learn_support contains some useful tips in comments for searching Zilla as well.

If you think that you've seen the problem you're facing before, and you want to know if it's in Zilla, perform a basic Zilla search on some of the keywords that might reasonably be expected to turn up. For instance, for a problem with phone posting, you might want to search for "phone post" or "phonepost".

However, just because something isn't in Zilla doesn't mean that it's not a Known Issue. It's possible that the developers are working on it separately (in a non-Zilla item), or the Zilla item doesn't contain logical keywords, or it's being handled through email and not through Zilla. In cases like that, you should do the following:

Check other Web-UI support requests (both answered and recently-closed) to see if other users are reporting the same issue, and if they are, what they are being told. Be careful, though -- make sure that the requests are dealing with the same issue, and not just something that looks like the same issue. If in doubt, ask an admin.
Check learn_support, lj_support, and support_web for posts regarding the situation.
Check news or lj_maintenance if there's been a recent code change; sometimes developers are active in the comments to those entries.
Ask a Web-UI supporthelp (if you aren't one) whether or not they're aware of any ongoing problems with that feature or element.
Check with rahaeli or markf to see if developers are aware of the problem or if there's any employee-level discussion regarding the situation.

Though the admins of Web-UI do try their best to communicate Known Issues on the employee level, it's not always possible to alert volunteers of everything. Also, please remember that sometimes, an issue may be known by employees, but that information will never be communicated to volunteers -- due to the issue itself being sensitive or relating to a policy decision or policy changes. There will be times when you will have to let an admin or an employee handle a particular request or type of request.

Determining Code Changes

The easiest way to determine if code has changed recently is to watch changelog and Zilla. It's also possible to use LiveJournal's web-based CVS repository frontend to determine when the last code change related to a particular page or routine was.

To keep as updated as possible regarding code changes, the best thing to do is to add yourself on the CC to any Zilla bug that looks like it may be relevant. You'll then get an email any time a change is made to that bug. It can be high-volume, particularly with a controversial bug, so you can also search Zilla by the web interface and sort by "last change" for each bug. That will show you which items are "hot topics".

The key thing to remember with Zilla is that just because a patch has been added to the bug, it does not mean that patch has been added to the site.

If a Zilla item has the keyword of "patch, need-review", it means that a developer has provided a (potential) fix for the bug, but that fix has not been tested. If an item has a keyword of "patch, reviewed", but the item itself is still open, it means that another developer has reviewed the patch to that bug, but it has not yet been committed to LiveJournal's CVS repository. If an item is in the status of "Resolved, Fixed", this means that the patch has been committed to LiveJournal's CVS repository, but does not necessarily mean that the code is "live" on the site.

LiveJournal attempts to sync the active, running code (the "live" code) on the site with the code present in CVS at least once a week. Currently, Brad is the only person who can update the live code to be identical to the code in CVS. This is often referred to in casual conversation as a "code push", or "new code going live".

Though patches are tested before they are committed, nobody can ever test every situation. LiveJournal's live site has over 2,000,000 users, and a production environment (the live site) is often quite different from a testing environment, so some bugs won't manifest until after the code is in live usage. If a lot of new code is going live, or if new code is going live that a developer suspects may cause problems in a production environment even if there were not problems in the testing environment, someone will make a post to lj_support saying "new code's going live, heads up". (rahaeli will also, when she's made aware of it, include a notice in the topic for the #web_motel irc channel.)

changelog contains all changes to the "ljcom" and "livejournal" CVS trees. These are the CVS trees for LiveJournal's server code in general, and the LiveJournal-specific code. All code changes are posted to changelog, unless it is the determination of the developer who is doing the CVS commit that the change should not be publicized (for security or confidentiality purposes). All LiveJournal developers currently have CVS commit access, but not all LiveJournal employees are developers.

A typical changelog commit will look like this:

Module name: This is the CVS tree the commit involves, such as "livejournal" or "ljcom".
Committed By: The login of the programmer who made the change. This is not the programmer's LJ username, but his or her danga.com login.
Date: The date and time of the change.

Modifed Files: Which file is being changed. This is not a direct one-on-one correlation with the URL of the page in question on LiveJournal, but anything with /htdocs/ in the URL is the LiveJournal site page. For instance, "livejournal/htdocs/friends: edit.bml" corresponds with http://www.livejournal.com/friends/edit.bml".

Log Message: Any comments that the developer has on this particular commit. Generally, this will be a brief description of the change, and/or the programmer's reasoning for it. Developers are encouraged to briefly describe the change, any issues it fixes, any issues it may introduce, the intended behaviour of the change, and/or any Zilla items it may resolve.

The remainder of the changelog commit will provide a link to get a "diff" of the change -- the exact details of what was changed in the code. Unless you are familiar with perl, this will generally not be of much use to you, and can safely be ignored.

All Web-UI volunteers are strongly encouraged to watch changelog on a regular basis. All Web-UI supporthelps are required to be familiar with the information contained in those methods (whether through watching the community on their friends page or visiting it directly).

If you see something that makes you think that there might be a bug in LiveJournal's code, it's also possible to determine the latest change by visiting LiveJournal's CVS repository directly. The web frontend to LiveJournal's CVS can be found at cvs.livejournal.org. By browsing the folders and files contained there, you can see how long it has been since the last time a particular file was changed (and by whom), and see previous commit messages. For instance, if you suspect a problem in http://www.livejournal.com/friends/edit.bml, and the file livejournal/htdocs/friends/edit.bml (located at http://cvs.livejournal.org/browse.cgi/livejournal/htdocs/friends/) shows that it was last updated 3 days ago, you may very well be on the right trail.

Volunteers also regularly post changelog summaries to lj_support and featureannounce, with a basic summary of what significant commits are intended to change or resolve. However, for Web-UI purposes, volunteers are encouraged to read Zilla and changelog directly. The summaries are intended primarily for volunteers who do not work in categories where basic Zilla and changelog familiarity is a requirement.

Determining Environment Changes

"Environment changes" generally indicate problems or changes to LiveJournal's servers, backend, or other setup. To oversimplify, it's a "code problem" if any site using LiveJournal's code would have the same problem, and an "environment problem" if the problem could only happen on LiveJournal.com.

LiveJournal's site architecture is documented in the lj_backend community. Problems with LiveJournal's site architecture, or planned or unplanned maintenance, are announced in the lj_maintenance community. Unplanned outages are announced at the off-site resource http://status.livejournal.org, with an on-site mirror of each post at status if LiveJournal is available for posting at the time of the status update. All Web-UI volunteers are assumed to be aware of any information that is communicated via those channels.

Some examples of environment changes that might cause an issue are:

A cluster or sub-cluster being in Read-Only mode at the time of the request
A cluster or sub-cluster having experienced database malfunction within the past few days
Users being moved from one sub-cluster to another
Changes in site architecure for a particular cluster
Changes in site-wide site architecture

Volunteers will be able to keep up with information on environment changes by following the lj_maintenance, lj_backend, and status updates. All Web-UI volunteers are expected to be familiar with the concepts and information contained in the following posts:

http://www.livejournal.com/community/lj_maintenance/60984.html
http://www.livejournal.com/community/lj_maintenance/61411.html
http://www.livejournal.com/community/lj_backend/502.html
http://www.livejournal.com/community/lj_backend/543.html
http://www.livejournal.com/community/lj_backend/974.html
http://www.livejournal.com/community/lj_backend/1312.html
http://www.livejournal.com/community/lj_backend/1911.html
http://www.livejournal.com/community/lj_backend/2482.html
any additional ongoing lj_maintenance and lj_backend posts regarding changes or upgrades to site architecture

The posts may be technical, but we'll work on getting that information into easily-understood terms.

Environment-related bugs and glitches are harder for a volunteer to resolve. Generally, if there's a cluster-wide or site-wide outage, the admins of the Web-UI category should be informed as soon as possible, so that they can inform server and database administrators as quickly as possible. The Web-UI admins will then inform volunteers about what the particular outage or situation is, and what information answers should contain.

Generally, any answer regarding a site-wide or cluster-specific outage should include, at the very minimum, links to http://status.livejournal.org and lj_maintenance. This will inform the user of where to go to find information on these outages in the future.

There will also be times when the site is just generally slow or unresponsive, due to load, without any more specific problems. If this happens, wait fifteen minutes and then try accessing LiveJournal again. If the problem persists for more than fifteen minutes, contact the Web-UI admins (following the general escalation procedures) so that someone can look into it. It's generally not necessary to escalate immediately if LiveJournal is unreachable for under 15 minutes at a time, unless you're aware of ongoing problems.

Reporting Bugs

Once you've determined that something is a code-related (not environment-related) bug, you have two options: either report it to Zilla, or ask someone to report it for you. Volunteers are not required to report things to Zilla, but strongly encouraged to do so -- if you follow all of the information presented here. If you don't feel that you can write a coherent and logical bug report, you are not obligated to do so. It's also perfectly acceptable to ask someone to look over a bug report before you make it.

A good bug report should contain all of the following information:

What the expected behaviour is. A bug report should contain a description of what you were doing, and what you expected to see. This doesn't have to be long and involved; generally, a sentence is fine.
A quick description of the bug, describing what happens contrary to expectation.
Steps you can take to reproduce the bug. Not all bugs will be immediately reproducable, but you shouldn't post a report until you have at least the beginning of an idea about how to reproduce it. You should also include information on how to work around the bug or avoid the bug, if it's a bug that only manifests under certain cirumstances. Sometimes, bugs will be entered in Zilla that aren't reproducable, or are only reproducable in certain circumstances, but the beginning volunteer should leave those for admins or more experienced volunteers.
A projected fix, or the behaviour that you would expect to see if the bug were not there.
Number of users affected if it isn't everyone, and under what circumstances they are affected.
Additional information if any, such as links to support requests that brought the bug to support's attention, or posts to any of the lj_* communities discussing changes to some part of the site that might have affected or caused the bug.

If you have what you believe is a security-related bug, DO NOT open a Zilla item about it, and don't call anyone's attention to it. Volunteers with I2 or supporthelp should immediately move the request to the "support@" category and contact the Web-UI admins regarding the problem. Volunteers who do not have I2 or supporthelp should follow the usual procedure for moving the request as quickly as possible and then contact the Web-UI admins.

Be absolutely sure, before you open a Zilla item, that there isn't already an item open on the same bug. Some duplicates are unavoidable, but they're irritating. Zilla is high-traffic enough as it is.

For more detailed instructions on the actual process of opening a Zilla bug, please see this post.

Any and all Zilla bugs that you open up regarding an issue that was first brought to your attention via Support should include the Web-UI admins as a CC. However, this is generally not sufficient for an issue to be considered a "Known Issue" if the issue is high-priority. See: "Determining Issue Severity", below.

Determining Issue Severity

Bugs and other issues can be roughly divided into three levels of severity. Note that this does not correspond with Zilla priority or severity.

Severity 3: Bug affects a small number of users, or only manifests under certain (unknown) circumstances, or is affecting a non-core element of the site, or is mainly cosmetic and/or just mildly irritating.
Severity 2: Bug affects a greater number of users, or is reproducable and affects a core element of the site but the root cause can't be determined, or is really irritating.
Severity 1: Bug affects all users of the site, or has the potential to cause data loss, or is directly related to a code change that has just gone live (within the past few hours).

If you have identified a Severity 3 bug, opening up a Zilla item should suffice. If you have a Severity 2 bug, open up a Zilla item and alert the Web-UI admin team via email, AIM, or irc when possible, but not urgently. If you have a Severity 1 bug or situation, open up a Zilla item and follow the escalation procedures (see below) to get in touch with someone as quickly as possible.

Escalation Procedures

Supporthelps in any category can view the escalation procedures posted to lj_support. This post contains lists of who to contact, when to contact them, when not to contact them, and methods for contact. A non-protected version of that post, containing general the general order of contact without any private contact information, is here.

General things to keep in mind when escalating an issue:

Don't contact employees other than the ones who deal with Support (currently: rahaeli, markf, jproulx, and marksmith) unless specifically invited by that employee.
Be as clear and concise as possible when contacting an employee -- sum up the situation quickly, and make sure you have all the information that you can when contacting an employee. (This goes double if you are calling someone and/or pulling them out of bed.)
Double-check, via AIM or irc, whether or not someone has already been contacted.

[Last updated: 09 February 2004]

web_ui @ 2003-10-02T21:28:00

2003-10-02T18:29:00Z

Web-UI: Revisiting the Category

This document serves as a follow-up to Introductory Guide To Supporting Web-UI. It explains some of the changes that have occurred in the category since the Introductory Guide was written, and provides further clarification as to what the category entails.

In Review: What is Web-UI?

Web-UI is a specialist category that deals with how users deal and communicate with LiveJournal's back-end (code, servers, and database). In particular, we deal with problems users are having with LiveJournal's code, servers, or database, and try to find resolutions to them. We do not, however, deal with questions concerning the normal use of LiveJournal's features (user education).

What sort of requests fall under the scope of Web-UI?

The web category deals with three basic types of requests:

Something is not working as it should, and volunteers cannot reproduce it. -- This is generally caused by an error in the user's browser or computer settings.
Something is not working as it should, and volunteers can reproduce it. -- Issues of this type fall into three categories: bugs, features working as intended, and direct user error. It is important to note that only user reports of bugs fall under the scope of the Web-UI category. If something is working as intended (just not as the user expects), this falls under the scope of another category, as it requires only user education. If something is due to direct user error, such as incorrectly written overrides that cause their 'most recent entries' page not to display, this is again an issue of user education, and is not dealt with in Web-UI.
Temporary errors outside the control of LiveJournal support -- These are issues such as users not being able to reach the site or receiving error messages due to site overload. Problems with database clusters also fall under this category.

To give specific examples, the following is a short list of support requests that would be handled by the Web-UI team:

Issues involving the user's browser cache. 'I can't see new posts on my friends page, even though they've all posted!' or 'I can't make a new post to my own journal. I get the 'update successful' page even though I haven't updated yet!' are both examples of this.
Issues involving other browser features, such as JavaScript or cookies. 'I can't see the menu items in XColibur' and 'I'm getting an invalid cookies message, what does that mean?' are both questions of this type.
Issues involving errors in submitting data to LiveJournal. 'I can't comment on a friend's post, the form doesn't work right!' or 'I can only post short posts to my journal, why?!' are good examples of this.
Any issues involving the user having problems staying logged in. This problem may be due to their browser, computer, or network settings, and requires the specialist knowledge of the Web-UI team.
Issues involving web Unicode settings. 'Some of my posts show up with ???? instead of words, why is that?' and 'I'm getting a weird message about Bad Encoding, what does that mean?' are examples of this type of question.
Issues involving users unable to reach the site, or pages not loading as expected. 'I'm getting 404 not found errors!' and 'My friends page is redirecting to another user's journal page!' are both questions of this type.
Issues directly involving LiveJournal's back-end. 'My journal has been in read-only mode for three days!' is a cluster-related/site maintenance issue, and belongs in Web-UI.
Reports of bugs in LiveJournal's code. The key exception to this is any report of a bug that falls under the scope of another specialist category, such as UPI or Syndication. For example, 'my user picture isn't displaying right!' or 'The syn feed slashdot hasn't updated in days, why?' are not Web-UI issues.

How do we handle such requests?

Every request in Web-UI is treated as an individual case, as each user has his or her own browser, operating system, and settings. This might make it seem like each request in web is going to take a long time to properly investigate and answer, but in truth, many questions can be answered in a similar fashion, as either the issue is handled the same for most browser/operating system combinations, or the issue is site-wide.

Further reading on the process of diagnosis and answering in Web-UI is available here. One important update to the referenced document is the recent creation of the support_testers community, where volunteers can work as a team to attempt to research, duplicate, and even resolve bugs that have been reported in support requests. You do not need to have privs in Web-UI to participate - everyone is welcome.

What sort of requests do not fall under the scope of Web-UI? How do I tell the difference?

As previously mentioned, Web-UI does not handle requests that deal with educating users on using LiveJournal's features.

The easiest way to differentiate between Web-UI and another category is to analyse the question like so:

Is the user asking a 'how do I?' question, or are they reporting a problem? 'How do I' questions, such as 'How do I change the colors in my journal?' or 'I want to create a community but don't know how!', are handled in other support categories, not Web-UI.
If the user is reporting a problem with a feature, is the feature working as intended? If so, the question is a matter of user education, and is handled by other support categories. If, however, the feature is not working as intended, then it is likely a problem that falls under the scope of the Web-UI category.

There are some exceptions to the rules, however. The following cases are not handled by the Web-UI team:

Issues involving account validation errors. This falls under the category of 'user education', and is handled by the General/Unknown team.
Issues involving improperly written journal overrides or badly written styles that cause a journal page to display abnormally. Again, this falls under the category of 'user education' and is also handled by the General/Unknown team.
Issues involving errors in receiving or displaying LiveJournal emails, including any errors involving Unicode. Email problems fall outside of the scope of Web-UI, and are usually handled in General/Unknown.

Important Note: Volunteers in other categories who are working on requests that fall outside the scope of Web-UI, but may be aided by our expertise, should feel free to contact Web-UI's administrators for help. Requests should not be sent to Web-UI for diagnosis unless they are problems Web-UI handles.

Who administers Web-UI? How do I make contact?

Web-UI is currently administered by rahaeli and markf.

General questions concerning answering in Web-UI can be directed to learn_support or support_interim as appropriate. Correspondence concerning more private matters in the category should be directed to all admins at their @livejournal email addresses, or to support@.

What about reviews and mentoring?

Reviews are required for advancement in the Web-UI category. Directions for obtaining a review are available here. You may also wish to read leora's 'Guide To Reviews'.

At this time, Web-UI cannot offer a mentoring program, as there are not enough supporthelps to allow for it. In the future, we hope to offer such a program, but currently it is not possible.

If you would like to have more 'hands on' training in Web-UI, you can feel free to join us on the IRC channel, #lj_support (directions here). There you can ask questions to available Web-UI supporthelps. Please do note that the channel is meant to be an 'off duty' place, so sometimes no one will be available to answer questions, even if there are supporthelps present on channel.

Future Projects

The admins of the Web-UI team are currently working on further documentation to help volunteers working in the category. Specifically, a series of 'how to' type tutorials are in the works, which will help to show the thought process that goes into identifying, researching, and answering questions in Web-UI.

Requests for specific documentation or aid can be directed to the admins at their @livejournal email addresses.

Further Reading

Web User Interface -- A guide for new volunteers
Working In Web-UI
Defining Web-UI And How We Got There

Last edited: 23/01/2004, to reflect new adminship

Introduction To Caching

2003-02-02T05:14:38Z

Target Audience: Unprivs and I1s
Summary: Covers in broad terms what a cache is, how browser caching works, why it can be a root or complicating issue in a presenting problem, ways of discerning these instances, treatment of caching problems, and norms for informing the user.
Assumed Knowledge: Introductory Guide To Answering In Web-UI, Principles Of Diagnosis.

Introduction

Caching is one of the first problems a new volunteer will encounter in Web-UI. Newbies could be forgiven for thinking that almost every problem in Web-UI is cache-related, because caching answers are very prevalent. It is dangerous to assume that cache is the solution to every problem, but it is an important consideration when diagnosing any presenting problem in Web-UI.

What Is A Cache?

A cache is a directory set aside for temporary copies of the websites you visit. This is so that when you regularly visit a site, the content found there (especially images, which might otherwise take a while to load) can be loaded from your cache instead. This speeds up the performance of your browser. It can also save on bandwidth costs, not only for the user, but also for ISPs, gateway servers, and the originating server (in this case, LiveJournal).

Proxy servers also have caches. However, it is less common for this to be the cause of a cache-related problem, and it will almost always be necessary to exclude browser caching before moving into diagnosing proxy caching. So let's stick with browser caching for now. Proxy caching and other intricacies will be discussed in other documents in the future.

How Does Caching Work?

There are a few factors that determine whether a browser checks for a new version of a page, or loads an existing one from the cache. It depends to a large extent on browser settings. Many browsers only check a specific URL once per browser session, by default. In addition, some browsers display buggy caching behaviour on an ongoing basis. Patches and upgrades will sometimes help in this instance.

There are other factors as well. It can depend, for instance, on whether headers sent by the originating servers indicate an expiry time for the URL (related link). Proxy server behaviour can also be a factor. These complicating factors are beyond the scope of this introductory guide, and will be discussed in other documents in the future.

Why Is This A Problem?

Caching, itself, is not a bad thing, and for people on slow modems or ISP plans with download limits, it can be extremely helpful in managing internet usage and costs. Sometimes, however, browsers can display buggy behaviour, by persistently displaying a cached version of a page instead of loading fresh content.

There are two ways in which browser caching can relevant to presenting problems.

It can be a primary or root issue. That is, it can be the root cause of a presenting problem. One example of this is where a user has a friends page displaying old entries, but support volunteers cannot reproduce (ie, the friends page has fresh entries). In this instance, the user is most likely viewing an old copy of the page from an earlier time.
It can be a secondary or complicating issue. That is, caching can exacerbate a prior problem. One example of this is where the user experienced a transitory error in the past (for instance, some message to the effect that the server is not available) but continues to see the error even though the problem is resolved. In this instance, the user is most likely viewing an old copy of the error message.

How Do I Tell The Difference?

Mostly through experience. The question you need to ask yourself, when working out whether cache is a primary or secondary issue, is - why did this user see the cached page originally? If it's an ordinary page they would have seen as a result of normal, expected site behaviour (a friends view, an "Update successful" page, a list of generated invitation codes) then caching is probably the primary problem. But if the cached page does not fall within the range of normal site behaviour (eg, File Not Found, Page Cannot Be Displayed, etc) then there is probably a separate root issue with caching on top.

How Do I Treat Caching Problems?

In some cases, where caching is the primary issue, SHIFT+Refresh will resolve the problem. In many browsers, this is a stronger form of reloading that forces the bypassing of the cache. (In other browsers it will do no harm).

However, not every cached page will respond to SHIFT+Refresh, even in browsers that support the function. For instance, cached responses to actions will often not respond, because the browser will sometimes persist in believing you have performed the action that calls that response, even if you didn't. So you might try to get to /update.bml and receive an old copy of an "Update successful" message, instead of seeing the form for writing an update.

So there will be cases when SHIFT+Refresh won't cut it, and the user will need to clear the cache. There is no real diagnostic benefit in separating these steps, so you can combine them, by telling the user to attempt SHIFT+Refresh and then clear cache if the problem persists.

If caching is a secondary issue, you will need to resolve the primary issue as well. Sometimes SHIFT+Refresh and/or cache clearing will be adequate even in these cases - that is, if the underlying problem is a transient one (for instance, load-related connection problems). But sometimes you will need to treat the primary problem also.

There will be times when you are not certain whether the primary problem is transient or persistent. In that case, you can ask the user to try SHIFT+Refresh and/or cache and then comment back if the problem persists. If the user does as you ask and the problem persists, you will have excluded caching + transient error and can move on to diagnosing the underlying problem. If the user does as you ask and no longer experiences the problem, you will have both identified and resolved the problem.

If a user has ongoing caching problems, they may benefit from a patch or upgrade to their browser. They may also like to set their browser's configuration to seek fresh content every time a page is loaded. However, this can slow browser performance and increase bandwidth costs, so it is not a step to be taken lightly. If you have reason to recommend this, make sure the user understands these implications. Many if not most users will choose to simply treat the problem as it occurs instead.

Informing The User

The user needs to understand, in simple terms, why we are asking her or him to clear the cache, and how to do it. The user also needs to understand that there are implications for doing this - namely, it will slow browser performance for a time, and temporarily increase bandwidth consumption.

Currently, it is normal for volunteers to explain very briefly why caching is thought to be the problem or part of the problem, and then refer the user to this document, with a user-maintained, no-responsibility disclaimer. This document provides the user with adequate information to make an informed decision about whether or not to clear her or his cache. This link will change in the future, but it will always be available from the sidebar of web_ui.

You are free to link to an alternative information source if you wish, but in order for your answer to be approvable, your link must provide equivalent levels of user information about the implications of clearing the cache.

If the user is using an uncommon browser for which we do not have instructions, it is acceptable to ask a user to check the browser's documentation for instructions about how to clear the cache.

Please do not tell users that they "should" clear the cache. In the vast majority of cases, they should. However, there are occasional instances where they shouldn't - for instance, if they have significant bandwidth problems, or if the computer is not their own. Let the user read the information and weigh it up for themselves. Shoot for a neutral factual statement - something along the lines of, "If this (caching) is the case, then clearing the cache will resolve the problem." The user may decide, because of their circumstances, to use a different browser or a different computer instead, and that's fair enough.

Conclusion

Caching issues are very common in Web-UI. The key to understanding when cache-clearing will resolve a difficulty is to understand how caching can cause or exacerbate problems to begin with. Developing this understanding is one of the earliest formative tasks when a volunteer is learning to diagnose and treat problems in Web. For that reason, even though cache-related answers themselves are often simple, it's worth putting time and thought into the requests that call for them, and understanding why the problem came about to begin with.

Deslea R. Judd
Last updated: 3 February, 2003

Understanding Unicode

2003-01-19T04:23:07Z

Many thanks to timwi for the following documentation.

What are character sets?

Computers store information in bits. ("Bit" is short for "binary digit".) Each bit is like a switch: It can take one of two values or states: "off" and "on", a.k.a. "0" or "1". At some point in the history of computers, it was decided to agree that 8 bits should make a byte; since each of the 8 bits in this byte can be in one of the two states, there are two to the power of 8, or 256, possible values for a byte.

Back in those days, it seemed intuitive to use one byte to represent one character of text when stored on a digital medium. They assigned each of those 256 values a byte can have a meaning. Some of them were agreed to be control characters -- for example, a line feed -- but most were printable characters such as letters, numbers, or punctuation symbols. For example, the lower-case letters a to z were assigned the bytes numbered 97 to 122. Thus, the following message:

I am a fan of LiveJournal

was stored by a computer as the following series of numbers:

73 32 97 109 32 97 32 102 97 110 32 111 102 32 76 105 118 101 74 111 117 114 110 97 108

Computers gradually spread around the world, and a need arose to represent more characters as other languages needed to be written. For example, German uses the following special characters: ä, ö, ü, and ß. So they started assigning more characters to more of those numbers and eventually came up with an assignment that would cover most major European languages. For example, ä was given the number 228.

However, 256 are not very many characters. Eventually, cultures with completely different writing systems - for example, the Russians with their Cyrillic letters - needed to represent their text as well. Since they, as they thought, would never need to use German characters, they only kept the first 128 (which covered English as well as all programming languages, mark-up languages and protocols) and created their own assignment for the remaining 128. For example, д - the Cyrillic letter De - was given the number 228.

With the advent of data-exchange technologies and in particular the Internet, it soon became clear that these character-to-number assignments - called character sets - need to be a agreed on. Furthermore, each document (for example, a webpage) needed to specify what character set it was in; the computer needed to know that, because if it did not, a German computer would display a Russian text such as

Я твой друг

using the characters for the European languages, which ended up as an unreadable mess:

ß òâîé äðóã

Notice how the д came out as an ä, because they both have the number 228.

What is Unicode?

Character sets have often resulted in problems and frustration, and they still do today. Additionally, it was not possible to write a text containing both German and Russian, because if the byte number 228 ever appeared in that text, it was not clear whether that should be an ä or a д.

It soon became clear that this problem could not be solved without dropping the constraint that every character would have to fit into one byte. Unicode aims to solve the problem by providing several encodings that can be used to represent text that contains characters from any language whatsoever. One of those encodings, called the 8-bit Unicode Transfer Format or UTF-8, is designed to use a single byte for the first 128 characters, while using several bytes to represent all the other characters used worldwide. The first 128 characters are sufficient for unadorned English text, programming, HTML, CSS and so on. Note, however, that even those writing in English will from time to time use additional characters, including smart quotes and accented letters for words and names originating in other languages.

To show an example, I will use a phrase that contains Russian, German, and special characters (typographical quotation marks):

Я люблю „Wer wird Millionär“.

Using the UTF-8 encoding, this will be represented as the following sequence of bytes:

208 175 32 208 187 209 142 208 177 208 187 209 142 32

Я (space) л ю б л ю (space)

226 128 158 87 101 114 32 119 105 114 100 32

„ W e r (space) w i r d (space)

77 105 108 108 105 111 110 195 164 114 226 128 156 46

M i l l i o n ä r " .

As can be seen here, the standard English letters, the space and the full-stop are all represented by single bytes, while the extended characters take more than one byte.

Why is this a problem on LiveJournal?

It is only a problem for LiveJournal because LiveJournal did not always use Unicode. They switched to using Unicode some time in May or June 2002. Before that, users used some character set for their respective language and then specified a GLOBAL_HEAD override containing the character set specification. For example, Russian Windows users would put this in their override:

<meta http-equiv="Content-Type" content="text/html; charset=Windows-1251">

Notice at the end where it says charset=Windows-1251 -- this is the Windows character set for 8-bit Cyrillic.

It would take an unrealistic amount of time and computing power to convert all users' journals from the character set of their choice to UTF-8. There are 30 GB of data in LiveJournal's database. This is why the entries are kept in the database using the old encoding instead of UTF-8; they are converted to UTF-8 anew every time someone views them in their browser. Now, in order to be able to display an entry that is not in UTF-8, the system needs to know what character set it is in - in other words, it needs to know whether a byte numbered 228 is an ä, a д, or whatever other characters there are in other character sets. This is what the "Auto-translate older entries from:" option on http://www.livejournal.com/editinfo.bml is for.

Every single posting on LiveJournal has a one-bit flag on it, called unknown8bit. (The word "flag" is programming terminology for an option that can be either "on" or "off", like a bit.) If this flag is not set for an entry (i.e. it is "off"), it means that all is well; the respective entry is in the UTF-8 encoding and can simply be displayed "as is". If, however, this flag is set ("on"), it means that this entry is not in the UTF-8 encoding, and the system should assume it to be in the encoding specified in that "Auto-translate older entries from:" option and use this information to convert the entry to UTF-8. If no encoding is specified, the system cannot decide whether to replace "byte number 228" with ä or д or anything else, so it places a question mark instead. This is why people posting in Russian, Japanese, or some other language that uses only non-English characters, see entries containing only lots of question marks, with an occasional comma or period in between.

Another problem is that not all LiveJournal clients support Unicode. editinfo.bml is a little misleading in this respect: The "Auto-translate older entries from:" option does not actually affect only older entries that were made before the site switched to Unicode, but also entries that were made from a downloadable client that does not support Unicode. The LiveJournal server will notice this and set the unknown8bit flag for any entries it will post. Therefore, users need to tell the system (by way of the "Auto-translate older entries from:" option) what character set their client uses. Most of the time, this is the default character set for their operating system. For example, the Russian version of Windows uses "Windows-1251" as their default character set. On editinfo.bml, this character set is referred to as "Cyrillic (Windows)". Notice that makers of other operating systems - for example, Apple Macintosh - came up with other Cyrillic character sets. There are actually five of them, but LiveJournal only supports two: "Windows-1251" and "KOI8". Similarly, there are three Japanese character sets, etc.

When users use the web form at http://www.livejournal.com/update.bml or http://www.livejournal.com/portal/ rather than a downloadable client, LiveJournal assumes - rather, has to assume - that the browser will send the data as UTF-8. As long as the user doesn't play around with their browser settings, this is not a problem. However, since some websites do not specify their encoding as they should, browsers allow users to set an encoding manually. Sometimes, users forget to set this back when they go to the Update Journal page at LiveJournal (or they may not even realise that they need to set it back). For example, if a Russian user has told their browser to assume that webpages are in the Windows-1251 (Cyrillic) encoding, it will use that encoding when sending the journal entry the user wrote. Fortunately, the LiveJournal software can find out that this data is not valid UTF-8 and reject the input with the following error message:

"Bad Unicode input - Your browser sent some text which is not recognised as valid text in the UTF-8 encoding, as it should be. This might happen if you forced your browser to view the previous page in some other encoding rather than UTF-8. It may also indicate a bug in the browser. If you cannot get around this error, contact us."

The solution to this problem would be for the user to turn the Encoding setting in their browser back to either "UTF-8" or, preferrably, "Auto-Detect", before submitting the entry. The same applies to submitting info on editinfo.bml such as one's bio, interests, name, etc.

Since the bio cannot be changed from a downloadable client, the only way problems can occur here is that someone has used non-basic characters (smart quotes, accented characters, etc.) in the bio prior to the switch to Unicode. However, there's something associated with the interests that is still causing us problems:

MySQL - the database system used to store all of LiveJournal's data - used to consider accented characters to be equivalent to their respective basic characters. For example, ú (a u with an acute accent) was considered equivalent to a simple u. As a result, "musica" and "música" where considered the same interest. Now, some of the interests have still not been converted to Unicode (interests were only converted when users invoked utf8convert.bml). When someone would enter "musica" as an interest (without accented characters), the system would assume this to be the same interest as "música", and then complain that this interest is not valid UTF-8 because it hasn't been converted yet. The only way to fix this problem appears to be for the administrators (e.g. Brad) to manually change "música" to "musica" in the database, so we need to be told when users complain about this problem.

Summary

This section is supposed to give a quick reference as to what symptoms are likely due to what causes. </p>

Symptom	Possible cause(s) (In approximate order of likeliness)
Error message: "Bad Unicode input - Your browser sent some text which is not recognised as valid text in the UTF-8 encoding, as it should be. This might happen if you forced your browser to view the previous page in some other encoding rather than UTF-8. It may also indicate a bug in the browser. If you cannot get around this error, contact us."	User has set browser to an encoding other than UTF-8 User's browser has a bug User's browser does not support UTF-8
Entry shows up with question marks instead of proper characters	User has not set "Auto-translate older entries from:" option
Entry shows up with wrong characters (e.g. accented letters where Cyrillic/Japanese/etc. should have appeared)	User has set "Auto-translate older entries from:" option to "Western European" although they should have set it to Cyrillic/Japanese/etc.
Name, location, bio, interests, memory keywords, memory descriptions, todo list, etc. show question marks instead of accented characters, smart quotes, etc	User has entered the relevant information before the switch to Unicode. They should visit http://www.livejournal.com/utf8convert.bml to mass-convert their information to UTF-8.
Interests show question marks although no accented characters were input	User has entered an interest that was introduced with an accented character by some earlier user before the switch to Unicode. Staff needs to be contacted to correct the database manually.

There are other problems that can arise from the site's implementation of Unicode. However, these are rare, and best investigated on a case-by-case basis.

Primary Contributor: timwi
Additional input: deslea, chaoticgoodnik, emmavescence
Last edited: January 19, 2003

Master Priv List, Web-UI

2003-01-19T03:22:11Z

I'll probably be spamming web_ui tonight with a bit of admin reference stuff. Sorry about that.

The Master Priv List, Web-UI

Last edited: 23 March 2003

Supportclose

deslea

Supporthelp

beginning
braindrain
circumstances
eefster
erin
jrust
emmavescence
chaoticgoodnik
isabeau
nyxie
supersat
bubba
sunday_silence

Supporthelp (Admin)

arie
asciident
deslea*
gooner
leora
rahaeli*
rho*
maria_gorbatova

*Also hold Supporthelp on basis of activity.

Supporthelp (Staff)

avva
bradfitz/brad
denisep/rahaeli
jproulx
sandy
sherm
ryanfitz

I2

entirelysonja
coffeechica
mortaine
tenshisama
timwi

I2 (Staff)

lisa

I2 (Other-Cat Supporthelp Policy)

algeh
hill_the_khore
janinedog
ladydiana
ninamazing
liliaceous
jennyrhill
sui_generis
technodummy
thewildrose
tinyjo
xb95
xtremesaints

I2 (Abuse Policy)

elfbabe
jenett
jillw
malerin
mullenkamp
nilesta
pinkfu
solcita
steve
ninjakitten

* Note that there are other Abuse team members who also have privs on other grounds, including sunday_silence, tenshisama and some of the admins.

I2 (Inactive Former Supporthelp)

mega
chemicallace

I1

angrychicken
lady_xanax
comeseptember
conlymon
dougb
fanthefire
kirylin
ratkrycek
redbird

I1 (Inactive Former I2s)

carmen
simones
tsutton
highway

Answering In Web-UI: Principles Of Diagnosis

2003-01-16T08:06:54Z

Web-UI differs from other specialty categories in that it is a diagnostic unit. This means that the methodology of answering in Web-UI is different to that of other categories.

In other categories, the aim is to be comprehensive - to cover all likely explanations in one answer, and minimise the likelihood of repeated contact. In other categories, "Still Needs Help" is often considered a less desirable outcome. This is not the case in Web-UI. In Web-UI, it is necessary to take logical, methodical steps - to identify one or more probable causes, and diagnose by exclusion.

This is why clearing the cache, for instance, is such a common initial response to queries in Web. It will treat many transitory problems, and if the problem is more persistent, that will be confirmed when the user still needs help. Clearing the cache will not treat every error, but many basic errors will respond to it. The trick is learning to identify when it might help, and when it probably won't.

What Is Diagnosis?

Diagnosis is essentially the art of informed guesswork, on the basis of knowledge, experience, instinct, and probabilities. It involves taking the information about the problem provided by the user, your understanding of common problems and the processes that are used by the site generally, and learning to compare them. In time, you will learn to make connections between the two that will allow you to identify a group of likely causes for a problem, and then you can methodically narrow the list down until you can identify the cause and provide the user with a solution.

Articulating The Manifestation And Scope Of The Problem

Users usually do not know the right information to include in a request. For straightforward matters, this need not be a problem. However, for more unusual problems, you may need to query the user for more information. You will need to have at least a rough idea of where the problem lies in order to decide what, if any, detail is needed.

Some questions you might need to ask - either by querying the user or by research - include:

How long has the problem been going on?
Does the timeframe correspond to any user system changes? (eg, new ISP, browser upgrade)
Has the user attempted any corrective steps previously?
Can the problem be reproduced? (either consistently on the user's system, or by volunteers on other systems)
Have other users reported the same or associated problems, especially within a short timeframe?

You will also need to consider whether the user is mistaken in her or his information or interpretation of the problem. If the user is using technical words in context, or displays a methodical approach to resolving the problem, this is less likely. Use of technical words incorrectly, or use of imprecise language or l337, is an indicator that the user's information is less likely to be accurate.

Sometimes users will be unco-operative. Some have short attention spans. Some have problems with attention deficit disorders. Some have English as a second language. Some are just intimidated by technical language. Try to be patient. Make your requests progressively simpler, with short sentences or in point form. If you are having trouble extracting necessary information from a user, feel free to request the help of the Category Admin.

Very rarely, the user will lie. If you suspect that a user is actively lying (for instance, in the hope of being issued with a replacement account code), alert the Category Admin. No volunteer is expected to diagnose for an intentionally misleading user. The same applies to users who will not perform reasonable diagnostic tasks.

Avenues Of Enquiry And Comparison

You will be comparing this information with your own personal knowledge base. This includes your general computer knowledge, your general knowledge of LiveJournal, your knowledge of known issues, and your knowledge of the tools available to you.

Some avenues of enquiry you might need to consider:

Can the problem be attributed to user error or false expectations?
Do the symptoms, or the user's configuration, correspond to a known issue in LiveJournal?
Do the symptoms correspond to some other known issue? (eg, browser bugs)
Do the symptoms date from some relevant change in LiveJournal's code or systems administration? (See places like changelog, lj_maintenance, or news).
Could it be that the user is presenting with multiple problems, either separate or related?
More rarely, is there any geographic issue that may be causing or exacerbating problems with data transmission? (For instance, a marine disaster in the user's country could be interfering with offshore cables, or an earthquake could have knocked out major backbone servers).

These are all in addition to more generalised knowledge of browser and site behaviour.

Forming And Testing A Hypothesis

It is not necessary or helpful to create a list of every possible cause for a presenting problem. Some problems are so rare, you might only see them once in your whole time as a volunteer. Some will only crop up every few months. You don't need to knock yourself out accommodating these sorts of extreme possibilities until more likely probable causes have been excluded.

Try to use logic to pin down the general area of the problem. If a problem can be reproduced by many people, it's unlikely to be a problem with the user's browser or OS (unless all are using the same browser or OS, of course). Conversely, if the problem cannot be reproduced, it is very likely to be with the user's browser, TCP/IP settings, ISP's proxy or domain name servers, etc. Consider whether the problem could be a transitory problem that is now peristing because of caching. Form a short-list in your head of possible causes, and then narrow down. If you have two problems on your short list that would respond to clearing cache and cookies, then start there. If you suspect that a problem is browser-specific, you could ask the user if they can reproduce the problem in a different browser. This will assist in diagnosis and possibly allow them some other way of using the site in the meantime.

If you feel that this may only be the first step in the investigation, actively encourage the user to comment back if the problem persists. Believe it or not, many users actually don't want to be a bother.

Problems That May Arise

If the user either refuses to co-operate with diagnostic tasks, or claims to have undertaken them but appears not to have done so, bring the matter to the attention of the Category Administrator.

If the user becomes obnoxious or abusive, transfer the request to support@ and bring it to the attention of the Category Admin. No volunteer on the public board is expected to accept abuse in the course of their duties.

If you are investigating a problem that is rare or new, or if you are investigating with a view to further action (eg, Zilla reporting), tag it [ui]. This stands for Under Investigation. You may also tag [rfc] for Request For Comment if you have a freaky you would like other volunteers to test or provide input for. Zilla reports arising from support requests should be made by Supporthelps or the Category Administrator. Interims are not expected to make these reports.

Don't feel that you have to pursue a problem until it is diagnosed. If you feel out of your depth, you can ask for help, research it, or just walk away. You won't be perceived as having given a "wrong" answer just because your answer didn't identify or resolve the problem. If it was a reasonable line of enquiry on the basis of the symptoms and probable causes, then it was a right answer.

Written by: Deslea R. Judd
Last updated: 17 January 2003

Informing Users About Known Issues In Web-UI

2002-12-26T07:56:28Z

Generally speaking, the norms for answering in Web-UI are the same as for answering in any category. However, our work with known issues and issues under investigation presents special challenges.

There will be times when it is necessary to tell the user that LiveJournal is at fault for an error. Do not try to gloss over this fact, nor should you dwell on it. In most cases, the user won't really care, as long as we can solve it, or reassure them that a solution is on its way. It is acceptable, and sometimes appropriate, to apologise for the inconvenience, but as in other support areas, "I" should be used rather than "we".

If the problem has been previously reported and appears in zilla, it is fine to say that this is a known issue and developers are looking into it. If you like, and if you know, you can provide basic information about the problem's progress - for instance, "Developers have identified the problem and are working on a fix," or, "A patch has been written and is awaiting review before it can be implemented." This may be helpful in appeasing an angry user. Do not provide the user with the zilla link, but please provide it as an IC for reference if possible.

There will be times when a request appears to be the first time a particular problem has been reported. If a request is tagged [ui], or under investigation, it's very possible that this will turn out to be a new bug. If you can't see internal comments, you're probably best to leave it alone. If the problem can be reproduced or tied to an existing bug, someone will zilla it (usually the Admin or a Supporthelp). After it has been entered into zilla, it is appropriate to thank the user for bringing the matter to LiveJournal's attention and say that the matter has been referred to developers for attention.

In either case, the user needs to understand that this is not a problem that is likely to be fixed overnight. Remind the user that most of LiveJournal's development is undertaken by volunteers and that an exact timeframe cannot be given for a solution, but also reassure them that the necessary steps have been taken to ensure that the matter will be attended to. Try to end your answer on a positive note rather than a negative one, and inform the user of any available workarounds.

Refrain from passing the buck. It is reasonable for a user to expect cross-compliance among current browsers and at least one version down. If a function breaks in a current browser, that's a legitimate complaint.

On the other hand, some things really are not our problem, and it's fine to say that as well. For instance, Javascript in Opera 6 does not support an extremely common Javascript element, and that breaks custom groups selection in update.bml. That's a known issue reported in Opera's knowledgebase. That is a situation where the browser is failing to meet current standards, and where it is acceptable to say that the problem is not our responsibility.

Try not to make LiveJournal look bad unnecessarily. Don't say that "many" people have reported a problem unless that is actually the case. Even a couple of dozen instances of a problem are not "many" for a site that has in excess of 800,000 users. Certainly, a sharp rise in reports of a problem indicates that something is wrong, but "many" and similar words are laden and often misleading, and they make the user feel worse about the site and the Support experience than is usually warranted.

Try not to make it sound as though LiveJournal does not care about getting a known issue fixed. Usually that is not the case. If a problem has been continuing for some time and there is an extenuating reason for it - for instance, a cause has not yet been isolated - say so, and then reassure the user that the problem is still a priority.

Please do not use the term "bug" in answers to support requests. The formal term is "known issue." "Verified issue," "confirmed problem," and other variations may be acceptable, depending on context, but "known issue" is a safe term for any problem that has been reported, reproduced, and logged in zilla.

Do not assume that a problem is part of a known issue unless other likely causes can be excluded. The login bug is a good example of this. Not every login-related problem is the login bug, and many of them probably are not. In many cases they will be persistent cookies or cached pages with incorrect session IDs. Both of these problems will respond to cookie deletion and cache clearing. Users do not need to know about the login bug until these steps have been attempted. It is very tempting to use a single answer that covers all possibilities, and that is sometimes appropriate (particularly if the user indicates that it is a long-term or persistent problem), but it is helpful for tracking a problem's incidence to address other causes first and then diagnose by exclusion. This also minimises the harm to LiveJournal by restricting LiveJournal's acceptance of responsibility to those cases where it is actually warranted. It is understood that this may be a difficult transition for some volunteers, since it is usual (and proper) to cover all bases at once in most categories. A certain amount of tolerance will be extended. But it is important to understand that our specialty role relies to some extent on diagnosis by exclusion.

Our job is not PR. It is not necessary to lie to protect LiveJournal's reputation. It is fitting and appropriate for LiveJournal to take responsibility for its own errors - indeed, that is the whole basis for this specialty category. Equally, though, it is not necessary or helpful to identify with the user's problem to the point of criticising or denigrating LiveJournal. Users should ideally feel supported and reassured by Support contact, and the very best way we can provide that is to take responsibility where it is due and then focus on a solution.

Web-UI Support Privilege Policy

2002-12-26T07:15:55Z

The following explains how privileges are assigned in Web-UI, what sort of technical skill base is expected at each level, and the responsibilities of each level. This document will probably provide some clarity to people uncertain about how to develop their skills in Web. The policy has undergone a consultation process in support_web.

Web-UI Support Privilege Policy

Privileges are not a right, but rather, an aid to professional development and to facilitating the answering of requests. No volunteer is to have a sense of entitlement about privileges. They are assigned on the combined basis of merit, trust, and the needs of the category. The following guidelines should not be seen as the only criteria for privileges, nor should it be felt that meeting these criteria will automatically result in the conferring of a privilege. However, they are pre-requisites that all volunteers desiring a particular priv should strive for.

Supporthelp

Supporthelp in Web is more than a matter of training. Although the knowledge of earlier stages is assumed, it is also a matter of instinct and a range of diagnostic skills and experience that are not always easy to identify or train for. For this reason, some experienced and competent volunteers will probably remain at I2 indefinitely. Not everyone has the capacity to diagnose in this way; it is a mix of technical skill and a kind of lateral thinking more common in creative types than techies. But it is certainly not impossible, and I do expect more Supporthelp appointments as time goes on.

It should also be understood that having Supporthelp in Web-UI involves working with broader areas of LiveJournal than Support itself. It functions as a core team that has an administrative and teaching role. Certainly, a volunteer with Supporthelp can focus on approving and working the board, but there are other opportunities and responsibilities as well. Some volunteers may wish to remain free of these responsibilities; for this reason, Supporthelp privileges will be offered, rather than given without consultation. The volunteer may refuse Supporthelp without prejudicing chances for Supporthelp in the future.

All Supporthelp in Web-UI are expected to actively watch support_web and lj_support and to have a Zilla account. (Membership in learn_support and support_interim is beneficial to Supporthelp for a full view of the Support landscape, but it is not mandatory). They are expected to be active on the board, but this need not be their primary area of activity necessarily. Activity can also take the form of reviewing, writing documentation, Zilla liaison, training sessions, research, and input into discussions. They are expected to keep abreast of known issues. Supporthelp are expected to be active in the category in one form or another, however, and they will be moved to I2 if they are inactive. It is vital that only adequately trained and up-to-date volunteers are approving answers on the board.

Volunteers should seek to acquire the following knowledge if they aspire to Supporthelp:

A rough idea of some of the more common known issues and why they occur.
How to write effective Zilla reports.
A capacity for diagnosis based on isolating/excluding probable causes.
Approving and reviewing skills.
An understanding of the ways in which the Supporthelp and Admin communicate, function, and report to one another, and of the Admin's relationship to other Admins and Staff.

Interims

Interim privileges in Web-UI are a much simpler matter. The only real responsibility of an Interim is to continue to learn. For this reason, Interims are expected to actively watch learn_support, support_interim, and lj_support. They are expected to keep abreast of training and seek reviews. They are not expected to file Zilla reports for the category or anything of that kind, but they are encouraged to get in the habit of watching bugs that are of relevance, particularly at I2 level.

Volunteers should possess the following technical knowledge in order to receive I2:

How various LiveJournal processes work. What information is sent? Where does it go?
What cookies does LiveJournal set and read? Why are they used?
An understanding of Unicode-related problems.
How to query Zilla and an understanding of categories and severities.
Basic knowledge of errors that can be returned by browsers, servers, proxies, and LiveJournal, and how to determine the source.
Basic knowlege of different errors that can be returned by the various scripting and markup languages used by LiveJournal, and how to determine the source.

Volunteers should possess the following technical knowledge in order to receive I1:

An understanding of how and why a browser uses a cache.
An understanding of how and why a browser uses cookies.
The basic mechanics of clearing cookies and cache, and the risks of doing both.
A basic knowledge of what Unicode is and why some sites use it.
A basic understanding how sites transmit information using HTTP POST, and what happens to it.
A working knowledge of the site and of generally accepted Support practices and style.

How Skills Are Assessed

At present, technical knowledge is assessed on the basis of reviews. In the future, it will probably be assessed in part through skills demonstrated during training sessions and the like, but reviewing will always play a part. It should also be understood that other, more general Support skills - for instance, the ability to convey information in a way suited to a user's technical level - will be factors in privving, as will general conduct and attitude.

Procedural Privileges

Abuse Team: Members of the Abuse team will automatically receive I2s for the purpose of transferring Abuse-related requests out of the category without a need to refer to anyone in Web-UI. This is to minimise volunteer exposure to misplaced Abuse requests.

Active Non-Web Supporthelp: Supporthelp in other public categories who are active will automatically receive I2s for the purpose of transferring requests into their categories, if necessary, without a need to refer to anyone in Web-UI.

It is assumed that both these classes of volunteer have the trustworthiness expected of an I2. If they wish to be active in the category, they are most welcome to do so, but they are expected to remain abreast of current information, like any other interim.

Privilege Removal

Inactive volunteers will have their privileges removed over time. Each quarter, inactives will move down a step, and they are free to continue to use the privs remaining if they wish to become active again. They may also seek fast-track mentoring to get them back up to their former standing. Volunteers wishing to become inactive may also request privilege removal.

In some circumstances, inactives will be allowed an extension to become active before being moved down a level, but an inactive Supporthelp will always be moved down. A Supporthelp must be up-to-date in order to approve on the board.

Privileges may also be removed for such things as misconduct or misuse, on a case-by-case basis. Volunteers with privileges have implied standing with LiveJournal, however limited, and are expected to maintain high standards of conduct, particularly in the Support-related sphere.

Reasonable Expectations And Exceptions

Expectations are based on what knowledge and tools volunteers need in order to do their job effectively. The intention is to keep requirements to the most practical minimum. Where an expectation creates a legitimate difficulty, the onus is on the category either to provide a solution or, where appropriate, to make an exception. Volunteers should bring any such difficulty to the attention of the Admin.

Where To From Here?

It is understood that these standards may not be entirely met by volunteers currently holding these privileges. No-one will be penalised for this. It is the responsibility of the category to train people to meet these standards, and that will happen over the next couple of months. Please do not be alarmed if you have identified gaps in your knowledge base as a result of this policy. Mechanisms and documentation are already being written with a view to making this transition. Please just continue to watch the required communities, and you will be given opportunities to access this training as soon as it is available.

Deslea R. Judd
Category Administrator
Web User Interface (Web-UI)

Last updated: 26 December 2002

Defining Web-UI, And How We Got There

2002-12-26T06:32:07Z

This document exists more for historical purposes than anything. It spells out the history of the category and how the present definition was reached. However, the main substance of this document - the definition and what it means - is also found in the Introductory Guide To Supporting Web-UI. The definition has undergone consultation processes in support_web and lj_supportadmin.

Preface

Historically, Web Client, as it was originally known, existed as one arm of the Clients group of categories. Web Client existed to serve those users who used the web interface to enter and manage their actual entries. It also included queries in which it was possible that the Web interface, rather than the user, was at fault. This information is derived largely from documentation written by mega, my predecessor as administrator of the category, in early 2002 (referenced with kind permission).

Over time, Web evolved. It came, loosely, to encompass a specialist area dealing in browser and HTTP-related issues and diagnosing problems with the whole interface. It involved quite a bit of administrative contact between the Admin and development, and a high level of specialised knowledge of the back-end of the site. For this reason, it remained an independent category and its name was changed to Web User Interface (Web-UI) when the decision was made to merge Clients in August (link).

The context is very different now than it was in August, when Web-UI took on its present identity, and until now there has not been a formal exploration and spelling out of what Web is and what it does. That has now changed. A consultation process has taken place, involving Web-UI Supporthelp (all of whom are also Supporthelp in General/Unknown), the other Category Admins, and employees. We've hammered out a definition, and a delineation, that we all believe that we can live with, and that we believe will serve Support as a whole.

Web-UI As A Specialist Category

Why do we have specialist categories? Clearly, to make sure that a request will be matched with people who have the right skills to resolve it. For that reason, in defining Web and delineating it from other categories, the aim has been to arrive at a useful, functional definition grounded in our role as a specialty category. The idea of having Web as a separate category is not merely to split the workload with Gunk, but to separate out queries requiring a defined range of specialty skills that we can provide. It is not in the interests of Support for Web to become the new Gunk.

With this in mind, the following definition of Web-UI has been agreed to:

Web User Interface, or Web-UI, is a specialist category of LiveJournal Support specifically devoted to the ways in which users communicate with LiveJournal's back-end (which includes the servers, LiveJournal source code and the database itself) using the web interface, with an emphasis on problems which may be grounded in the back-end. The purpose of this specialty is to ensure that bugs and inadequacies in the back-end can be detected and, where appropriate, pursued at development level. Not all requests in Web-UI will be of this ilk; many will be routine matters of user, browser, or communications error. However, the common thread in them all is that they are Web-based difficulties in which LiveJournal's own back-end is one possible contributing factor or cause, and which should be diagnosed by people trained to specialise in this kind of diagnosis.

In addition, Web-UI will accept requests that do not meet this functional definition but for some reason require the specialist knowledge of its volunteers.

What Does That Actually Mean?

Using this definition, the following common requests would fall under Web-UI:

UTF-8 problems. These are caused or contributed to by the implementation of UTF-8 at development level.
Login/cookie problems. These may be caused or exacerbated by interface or protocol errors. It will be necessary to diagnose these by elimination.
Javascript problems. These may be caused by our coding, or a combination of our coding and hacky browser behaviour (eg, Opera). It will be necessary in these cases to establish whether LiveJournal can be reasonably expected to address the problem. In some cases the problem will simply be bug reported to the browser's developers instead.
"How do I make a custom login page?" and similar user education requests requiring specialist knowledge of LiveJournal's back-end. These are not ours by virtue of diagnostics, but they require our expertise.
Investigating and diagnosing problems related to the functionality of new or unstable features, such as S2, Syndication, Export, and the To-Do list, with a view to working out whether bug reporting or manual database manipulation is required, or to adding information to existing reports.
Other site responses inconsistent with user actions or reasonable user expectations. This excludes bugs that come under another specialist category, eg UPI.

The following common request areas would not fall under Web-UI:

User education about how to access a function. "How do I make a custom filter?" or "How do I join a syndicated feed?" are questions of this kind.
Clarifying user misconceptions. "I can see my private posts on my friend's Friends page" is a query of this kind.
Questions about policy or intentional service limitations. A free user asking "Why can't I join a syndicated feed?" is a question of this kind.
LiveJournal error that is not web-based or web-specific. A user failing to receive emailed comments is a question of this kind.
LiveJournal error that falls under another specialist category (ie, User Picture Icons, Communities, Clients, Embedding, or RSS/Syndication).
Problems for which LiveJournal error can immediately be excluded. Clear cases of images failing to load as a result of remote loading, for instance, are problems in which it is very unlikely that LiveJournal error is a factor. However, if the user responded that it was their own server and that they had allowed LiveJournal in the .htaccess, the request would then need to come to us for further investigation, both to exclude the possibility of LiveJournal error and because it would probably require our expertise.

Basically, and within the definition above, "How do I?" and "Why can't I?" would go to General/Unknown, and "I have problems when I..." would go to Web.

What About The Web Client?

Traditional Web Client areas such as "How do I make an entry?" will no longer come under Web-UI. It has been decided that Web-UI does not need to be locked in to the models of its prior identity, and making exceptions of this kind to the above definition is confusing and unhelpful to volunteers. Furthermore, such questions do not require our areas of specialisation; they are routine matters of user education that are completely within the competency of General/Unknown and do not require any particular additional training. Many old Web Client queries will still come under Web-UI under the definition above (eg, double posting), but they are no longer to be identified with Web-UI merely because they would once have been transferred to Web Client.

Last edited: December 31, 2002
Edited to reflect addition of Syndication category

Introductory Guide To Supporting Web-UI

2002-12-26T03:43:14Z

This guide pulls together a lot of things that have been thrashed out in support_web and lj_supportadmin in the month or so since I came into the role of Category Admin. Hopefully it will clarify a lot of the issues that have been problematic in recent months and shed light on the way forward.

Introductory Guide To Supporting Web-UI

Please note that this document refers in several places to the community support_web. Please be aware that this community will soon be renamed to support_web. The links should follow through after the change takes place.

What is a specialist category?

At present, there are six categories among the public ones that may be considered specialist. These are Communities, Clients, Embedding, User Picture Icons, Syndication, and Web-UI. In addition, there is General/Unknown, which encompasses all queries that are not covered by an existing specialty, or that require multiple specialties.

We have specialist categories to make sure that a request will be matched with people who have the right skills to resolve it. The idea of having Web-UI as a separate category is not merely to split the workload with Gunk, but to separate out queries requiring a defined range of specialty skills that we can provide and have elected to make our training focus.

What is Web-UI?

Web User Interface, or Web-UI, is a specialist category of LiveJournal Support specifically devoted to the ways in which users communicate with LiveJournal's back-end (which includes the servers, LiveJournal source code and the database itself) using the web interface, with an emphasis on problems which may be grounded in the back-end. The purpose of this specialty is to ensure that bugs and inadequacies in the back-end can be detected and, where appropriate, pursued at development level. Not all requests in Web-UI will be of this ilk; many will be routine matters of user, browser, or communications error. However, the common thread in them all is that they are Web-based difficulties in which LiveJournal's own back-end is one possible contributing factor or cause, and which should be diagnosed by people trained to specialise in this kind of diagnosis.

In addition, Web-UI will accept requests that do not meet this functional definition but for some reason require the specialist knowledge of its volunteers.

What does that actually mean?

Using this definition, the following common requests would fall under Web-UI:

UTF-8 problems. These are caused or contributed to by the implementation of UTF-8 at development level.
Login/cookie problems. These may be caused or exacerbated by interface or protocol errors. It will be necessary to diagnose these by elimination.
Javascript problems. These may be caused by our coding, or a combination of our coding and hacky browser behaviour (eg, Opera). It will be necessary in these cases to establish whether LiveJournal can be reasonably expected to address the problem. In some cases the problem will simply be bug reported to the browser's developers instead.
"How do I make a custom login page?" and similar user education requests requiring specialist knowledge of LiveJournal's back-end. These are not ours by virtue of diagnostics, but they require our expertise.
Investigating and diagnosing problems related to the functionality of new or unstable features, such as S2, Export, and the To-Do list, with a view to working out whether bug reporting or manual database manipulation is required, or to adding information to existing reports.
Other site responses inconsistent with user actions or reasonable user expectations. This excludes bugs that come under another specialist category, eg UPI.

The following common request areas would not fall under Web-UI:

User education about how to access a function. "How do I make a custom filter?" or "How do I join a syndicated feed?" are questions of this kind.
Clarifying user misconceptions. "I can see my private posts on my friend's Friends page" is a query of this kind.
Questions about policy or intentional service limitations. A free user asking "Why can't I join a syndicated feed?" is a question of this kind.
LiveJournal error that is not web-based or web-specific. A user failing to receive emailed comments is a question of this kind.
LiveJournal error that falls under another specialist category (ie, User Picture Icons, Communities, Clients, Syndication or Embedding).
Problems for which LiveJournal error can immediately be excluded. Clear cases of images failing to load as a result of remote loading, for instance, are problems in which it is very unlikely that LiveJournal error is a factor. However, if the user responded that it was their own server and that they had allowed LiveJournal in the .htaccess, the request would then need to come to us for further investigation, both to exclude the possibility of LiveJournal error and because it would probably require our expertise.

Basically, and within the definition above, "How do I?" and "Why can't I?" would go to General/Unknown, and "I have problems when I..." would go to Web.

You can find out more about the process that led Web to its current identity here.</b>

How is Web-UI administered? Where do I fit in?

Web-UI is administered by the Category Administrator, deslea. The Category Administrator engages in consultation procedures with her Supporthelps in support_web and her fellow Admins in lj_supportadmin. She reports policy in lj_support and provides day-to-day guidance to screened volunteers in learn_support and support_interim. She conducts formal training and archives Web-specific guides and the like in web_ui.

People who work in Web-UI do so at varying levels and types of activity. Each level carries certain privileges and certain expectations. Expectations are based on what knowledge and tools volunteers need in order to do their job effectively.

The intention is to keep requirements to the most practical minimum. For example, documentation posted here is announced in one of the required communities, so that no-one needs to watch this one. Where an expectation creates a legitimate difficulty, the onus is on the category either to provide a solution or, where appropriate, to make an exception. Volunteers should bring any such difficulty to the attention of the Admin.

Supporthelps in Web-UI have responsibilities to train others and to remain up-to-date themselves. Some write training documentation or review. They also participate in administrative decision-making. All are expected to have some board activity, although low levels of activity are acceptable for specialists in key areas and those involved in training. They are expected to actively watch lj_support and support_web, and encouraged to watch learn_support and support_interim. They are expected to have Zilla accounts.

Interims in Web-UI who are actively working Web requests are expected only to learn and to be active on the board. They are expected to actively watch lj_support, learn_support and support_interim. They may like to watch support_web, but this is not required, and relatively little information is public there. I2s are encouraged to have Zilla accounts and to get in the habit of using Zilla for research, but this is not mandatory.

Interims who are not active in Web-UI have no responsibilities to Web aside from responsible use of their privs. These include procedural interims such as the Abuse team, other-category Supporthelps, and inactive volunteers whose privileges are being incrementally removed. Procedural interims are most welcome to be active in Web, but in that case they are expected to remain up-to-date in the same way as any other active interim.

Volunteers without privileges are expected only to learn. They are expected to actively watch lj_support and learn_support, and to become familiar with Support practices and style, and to become familiar with the site and the FAQs. They are encouraged to introduce themselves in learn_support and, after a few weeks working the board, to seek a review. Generally, new volunteers will find it easier to begin in General/Unknown, tackling general user education questions, before moving into Web-UI. However, there is no particular restriction or expectation of G/U experience, and those whose interests or knowledge tend more to Web are certainly welcome to come to us in the first instance.

For more information about the various priv levels and the technical expectations at each level, please see the post here.

Tools

Aside from the tools available to all volunteers through the Support-wide avenues, there are several tools specific to volunteers in Web.

Test Accounts. Every new interim in Web is entitled to an invitation code for the creation of a test account. This code will be supplied regardless of whether the volunteer has codes to spare already. This is a matter of principle and good practice. The onus is on the category to provide the tools the volunteer needs.
Paid Test Account. A permanent test account exists for the investigation of Web-UI problems specific to paid users, such as Syndication and S2 problems. Due to the possibilities for abuse, use of this account is restricted to category Supporthelps. However, any volunteer can ask for a problem to be tested on this account. If it relates to a request, the volunteer may wish to IC the request, or else contact a Supporthelp or the Admin. Other categories may access this facility as well, but requests should go through the relevant Category Admin.
web_ui. This community exists as a reference and training ground for volunteers in Web-UI. Guides, policies, and reasonably static training documentation are archived there, and formal training is conducted there as well. No user is required to watch this community, except when participating in formal training. It is intended to be a journal you go to for research purposes rather than a journal you watch in the usual sense.
glitterjournal. This journal exists to provide user resource material, with instructions for common tasks such as cache-clearing and deleting cookies. It started out as my personal support resource back when I was an interim. You should be aware that some of the content, for this reason, is less revelant to Web than others, and the journal address itself should not be given to users. What you can give to users, however, are links to the guides for Clearing Cache and Deleting Cookies. Both resources have disclaimers, but as a matter of form, your reply should state that these are maintained by a user and that LiveJournal is not responsible for their content. As a matter of policy, these two resources are favoured over external resources, which tend not to provide adequate user information about the risks involved in these actions. These resources will be moved to howto in the future. If you think we should have other guides, such as guides for enabling Javascript or cookies, please let me know. Volunteers in other categories may reference these resources too, at the discretion of the relevant Admin. EDIT: These resources have been moved to howto. This segment will be edited properly later.
Zilla Reporting. Since I became Category Admin, it has been customary for me to provide regular bulletins about known issues that are likely to arise in support requests. These have been provided as protected posts in support_web. The rationale for sharing that information in that community is that the information is considered assumed knowledge for Supporthelp and optional for volunteers with lower privileges. However, there is no reason for the information to be particularly restricted, so future bulletins of this type will be made public. The format is still being worked out, but they will appear as public posts in bugbulletin. Please note, you are not expected to friend this journal. You may prefer to simply look there when you're wondering about a specific issue. If you're already watching Zilla and changelog, you probably won't need this - it will likely overlap with what you're watching already.

Making Contact

If you would like a review, please see the information here for the latest information on who is available to review. You may contact an available person directly if you wish, but be aware that your review may be passed on to another person if the reviewer has received several requests. Copies of all reviews are sent to the Admin, and a summary is provided to category Supporthelps.

Mentoring is available in principle, but there are no concrete procedures in place at this time. If you would like a mentor, please contact deslea. Please understand, it may take a little time for you to be matched with a mentor. A set of guidelines can be decided upon if you feel you need them.

Day-to-day queries may be posted in learn_support or support_interim, as appropriate. However, queries that pertain to mistakes made by other volunteers or any kind of misconduct should be directed privately to deslea or support@.

Deslea R. Judd
Category Administrator
Web User Interface (Web-UI)

Last edited: 31 December, 2002
Edited to reflect addition of Syndication category

208	175	32	208	187	209	142	208	177	208	187	209	142	32
Я		(space)	л		ю		б		л		ю		(space)