July 23rd, 2004


A recent thread has brought my attention to an issue I remember debating in the past but never posted about. First, two things to consider. (1) Our users are not idiots. Though, at times, this is unclear due to some of the support requests they open, they are not lacking all semblance of common sense. There are some things around the site - features or pages - that are intuitive; we shouldn't over-explain every small detail of every individual feature to the point that our FAQs become condescending. (2) Consistency is a beautiful thing. We went over it during the Great Email vs. E-mail Debate. We went over it during the mass overhaul of S2 documentation. It's been an underlying theme in userdoc for as long as I've been around. It is very important. Little things matter. Having all of the FAQs written in a similar way, presented in a similar format, using similar language; it's all very, very important.

On that note, we come to exampleusername. After looking briefly through about ten or fifteen of our FAQs, I see an inconsistency and a string of unnecessary explanations. I am also less wary about proposing something that would, potentially, require 30-50 FAQs be edited as we are on the horizon of another great FAQ overhaul which will put our FAQs in Rho-Style(tm). Let me explain my thoughts.

Of the FAQs I looked over, I saw quite a few linkings to exampleusername, whether it be the RecentPage, FriendsPage, UserinfoPage, MemoriesPage, etc. (forgive my S2-esque naming of the pages; it's a habit). However, a handful of these mentions add a "[...] replace 'exampleusername' with your username [...]" bit tagged onto them. I have two problems with this. (1) If we're going to include this little disclaimer in some of the FAQs, for the sake of consistency, we must include it in all of the FAQs [which mention exampleusername]. (2) Is it really necessary to explain that they need to replace "exampleusrname" with their username? The journal is named "exampleusername". The RecentPage and UserinfoPage give allusions as to what the journal is for and instructions for what to do next. Any logical human being could figure out that they need to replace the "exampleusername" with their username, as it is only an "example" of a "username". See where I'm coming from? I don't see the point in mentioning something that is, for the most part, completely rooted in common sense.

As per my two problems above, were we to try and resolve (1), I would have another problem: (3) Redundancy is not something I think we should make very common in our FAQs. Yes, sometimes things are worth repeating because they are important and cover a wide array of topics or possible interpretations. Yes, sometimes features cross-over among FAQ categories and, because our FAQs cannot be cross-referenced (that is, one FAQ put in more than one FAQ category), important information could be lost while trying to preserve a lack of redundancy. But, in this case, seeing FAQ after FAQ say essentially the same thing would be not only redundant, but annoyingly and unprofessionally redundant.

So, I propose we mend (2). I don't think we need to include this disclaimer at all. If anyone has any arguments against this idea I'd love to hear them. These were all only my personal opinions and they are always subject to change if persuaded properly. Comments? Thoughts?
  • Current Mood
    contemplative contemplative
  • pne

[entries] add "span" to the list of allowed tags in FAQ 72

FAQ 72 contains a list of tags that can be used in entries.

<div> is present but <span> is not. While the list does say that "some others that are not included here" are also allowed, "div" and "span" kind of go together for me (since they're both essentially semantically empty containers, for block-level and inline content, respectively), so they should both be in there IMO.

"span" would go between "small" and "strike".

Squeak!, Pthalo&#39;s a mouse!

Interests FAQ!

The message when updating an FAQ is very cute. It says: "Updated FAQ item. All good. faqid is 60"

Anyway, the point of this post is to say that FAQ 60, the FAQ previously known as "How are interests limited?" is now called "What are interests? How do I add or remove them?" and has been completely written. It still contains all of the old information, it's just useful for larger values of useful than it was before.
  • Current Mood
    cheerful cheerful
out-of-place, costume

[site_nav] #86 What is a LiveJournal to-do list? How do I use it? (https://www.livejournal.com/support/faq/86.html)

In this recently created (well, condensed and moved) FAQ, there are references to two limitations based on account type, neither of which provides information for Early Adopter accounts.

In the third paragraph, there is the mention that Paid and Permanent accounts can have an unlimited number of to-do list items, while Free accounts can only have 25. No mention is made of how many items Early Adopters can have.

Also in that paragraph, it states that Free accounts can only use the Public security setting for their to-do list items (thus implying that Paid and Permanent accounts can use all of the security settings). Are Early Adopters allowed to use all of the security settings?

The paragraph in question is this:

Users with Paid or Permanent Accounts can have an unlimited number of to-do list items. Free Accounts can have up to 25 to-do list item, but cannot set the security to anything other than Public. For more information about the different account types, see http://www.livejournal.com/support/faqbrowse.bml?faqid=38.

I would suggest making that paragraph only about the number of to-do list items each account type can have, and moving mention of restrictions on security levels down to the area where it says:

* Security: field allows you to choose who can see this to-do list item. Public allows anyone to see it, Friends allows only the people who are listed on your Friends list to see it, and Private allows only you to see it.

I've caught a few typos in glancing over this: "Free Accounts can have up to 25 to-do list item" (should be items), "Security: field allows you" (probably don't need "field" in there). I can check the whole FAQ and fix those things, convert it to Rho-style™, etc. but it makes more sense to wait until I've got the necessary information about Early Adopters and feedback on whether or not it would be good to move that one piece of information.