June 19th, 2001

amused, happy
  • mart

Making HTML email forms work outside OE and Netscape

This has been discussed a little, and it would seem that external email clients such as Eudora and Pegasus have trouble producing POST requests in browsers since the browsers don't provide a way to launch a POST request from the command line.

I'm wondering if these clients would be happier if we used a GET request from the forms in the emails. Email clients could then launch the browser with a mega-long URL and stand more chance of getting their intentions known.

There are some issues with this approach, though. Firstly, using a GET request for something which makes changes on the server is not advisable because a refresh could cause it to happen again with no user prompting, and if it's stuck in the users' history they might accidentally press the back button to return to it and possibly post the comment again. My solution to this is to throw out a 302 redirect to a 'safe' URL after the database bit has been done. This safe URL would just be a page saying "Success - your comment has been posted" - doesn't even need to have any code on it, although the itemid and talkid could be passed in the query string so a link to the comment can be provided. In sane browsers, a 302 redirect should cause the new location to replace the bad one in the browser's history thus removing the 'back' problem.

The other issue is that it would create some awful long URLs in the server logs. Brad has expressed his distaste at doing this before, and I can see where he's coming from. Turning off the logging of URLs with their query string doesn't seem like a good idea, either. I have no solution to this problem, but perhaps people will consider this important enough that we can just suffer this minor inconvenience.

  • mart

More Laborious Cleaning Work

Lots of places on LiveJournal there are GET forms which don't specify an ACTION attribute. These include the new support filtering feature and the interests browser.

Most browsers, when ACTION is ommitted, will use the current URL as the URL to submit to, which is a reasonable idea. Internet Explorer will, in the case of help.bml in support, submit the form on http://www.livejournal.com/support/help.bml?state=closed&cat= to, maybe, http://www.livejournal.com/support/help.bml?state=green&cat=... which would, again, seem like a reasonable idea. It took the URL up to the query string and used that as the default.

Enter Opera. A different browser, with different ideas about what to do when you leave out the required ACTION attribute. Opera submits the form on the URL I indicated before to http://www.livejournal.com/support/help.bml?state=closed&cat=&state=green&cat= ... that is, it adds the new form values in addition to the ones that are already there. This also seems like a reasonable idea, since they were already part of the URL which it has elected to use as the default.

I have no idea which of these, if either, is a HTML-compliant action... we don't generally seem to care on LiveJournal anyway for better or worse, so long as it works in as many places as possible.

LiveJournal's querystring parser does some odd stuff when there is more than one of the same variable, which stops the support form thing working correctly in Opera.

The solution to this is simple. action="help.bml" needs to be added to the form tag. This fixes the problem, and makes it work in both IE and Opera. I don't have any other browsers around to test in, but there's probably another one somewhere which does what Opera does.

This would be all well and good if this were the only place on LiveJournal where this is done, but it isn't. I also know of the problem being in the interests section, and I'm sure elsewhere too. This leads to the reasonably laborious task of reading the code of lots of BML documents looking for form tags without action attributes and, hopefully, adding it and submitting a diff. This would be a reasonably simple job for someone with some time to kill. Any takers?


LiveJournal for reporters

I had a thread of emails recently with a reporter about a story that he did on weblogs and we got into discussing the needs of reporters for weblog applications.

The long and short of it is that a lot of reporters are starting to get very interested in having their own weblogs, but there are several barriers preventing them from doing so.

- Budget (for software, such as Userland's Manila)
- Budget (for all the html and IT help they'll need to get it all set up)
- The lack of a truly good application for doing what they need to do
- Their own innate lack of technical ability

The standard for such reporter-run weblogs is currently Dan Gillmor's, but then again, he is technically skilled himself and is the technology reporter for the major paper in the Silicon Valley. He has resources that lots of other reporters simply do not have.

If LiveJournal wants serious attention as a project, we should work to solve the problems that all these other reporters have... if we can create some kind of customized solution geared towards what they specifically need, so that they can do weblogs like Gillmor's easily, it would greatly help us.

What reporters need are weblogs that:
- are easy to set up and maintain from a web/IT perspective
- are painless for reporters to create and update
- look professional and have appropriate styles for their needs.
- have a built-in ability to associate anchors with headers for posts.
- allow them to have their recent weblog entries on their site, regardless of whether our servers are down.
- can be edited on their side temporarily (if possible).

My question to all of you is what can we do now that will get us to a state where all of these specs can be achieved? How do you think we should implement these features?