December 17th, 2006

jess-paul

Fix =3D on comment reply urls

Title
Fix =3D on comment reply urls

Short, concise description of the idea
Some mail clients don't do well with the character encoding used and "=" becomes escaped as "=3D". Livejournal could be made smarter to "magically" redirect the extraneous url to the correct one.

Full description of the idea
urls such as http://babaloney-w00.livejournal.com/27818.html?replyto=594858 get mangled by some mail clients (eg. PopTray) into http://babaloney-w00.livejournal.com/27818.html?replyto=3D594858 which returns a 404. Since this is a predictable problem, logic could be added to correct this error by rewriting the url to take out the extranous "3D" from the replyto parameter

An ordered list of benefits
  • easier to reply to comments if you're using a lame mail client
  • possibly less requests to support about email links being "broken".

An ordered list of problems/issues involved
  • could add a slight delay to comment lookup time if coded inefficiently

An organized list, or a few short paragraphs detailing suggestions for implementation
  • Add logic to the url fetching code that if the replyto parameter begins with 3D to remove the 3D since "=3D" is really just an escape character for "=". If efficiency is a concern this could be done conditionally on the first attempt to lookup the thread failing.
tie one on

Adding 'Journal Default' to the Security field on update.bml

Title
Adding 'Journal Default' to the Security field on update.bml

Short, concise description of the idea
"Journal Default" should be an option for the Security field as well as for the Screening and Comment fields on the update.bml page.

Full description of the idea
When using http://www.livejournal.com/update.bml, the current default setting in the security field is "Everyone (Public)". It should be "Journal Default", like it is in the Comments and Screening fields.

If you are given the option to choose "Journal Default" then your post will be marked with the journal's default security setting. But, if you choose any of the other options, then your post will be marked with the security level you specifically choose.

An ordered list of benefits
  • It's confusing to have the setting shown as "Everyone (Public)" when that is not necessarily the security level that will be applied to the new post.
  • In a Friends-Only Journal, you can only choose a higher security setting from the update page - to choose a lower setting, you must post, then go back and edit your original entry.
  • It's confusing that the Comment and Screening options are different from the Security level options.

An ordered list of problems/issues involved
  • Currently, global changes are applied differently to Security than they are applied to Screening and Comments. However, this should only be confusing for the handful of users who 1) know how global changes are made and 2) think about how possible, future global changes will affect the current post they are making. But, following all suggestions for implementation below will make this issue moot.

An organized list, or a few short paragraphs detailing suggestions for implementation
  • Add "Journal Default" to the security field on the update.bml page.
  • Have "Journal Default" mean that the security level of that post will be whatever is the default security setting of the journal in which the post is being made at the time the post is being made.
  • If a user chooses a security setting other than "Journal Default" then that is the security setting that should be used, even if that security level is lower than the journal's default setting.
  • Correct how global changes are applied to Comments, Screening, and Security - that is, make the change apply only to posts from that point forward (like it currently does for Security).
  • Don't assume that users will want their global changes applied to all posts (past and future). Instead, give the user the OPTION to make the change retroactive, whether the change is to the Comments, Screening, or Security level.