Revamping the 'Export Journal' tool to allow exporting in larger time intervals

[flo]

Title:
Revamping the 'Export Journal' tool to allow exporting in larger time intervals

Area:
exporting, interoperability, backups

Summary:
Revamping the 'Export Journal' tool at http://www.dreamwidth.org/export so that you can export entries from your journal on a yearly basis, and also export it all as one giant file. Export options on that page could also use some clarification so that you understand why or why not to tick them.

Description:
Basically, I want to the basic export tool to allow me to export my journal as XML on a yearly basis as well, or even just all at once. Currently, the export tool at http://www.dreamwidth.org/export only allows you to export on a monthly basis, which means lots and lots of repetitive action if you post even occasionally on your journal. As far as I know, people that want to back up their Dreamwidth journals generally resort to something like LJ Archive, which is thorough, but can be inexplicably buggy, and is not at all maintained by Dreamwidth or otherwise affiliated with Dreamwidth. I would much prefer being able to export my journal with an on-site tool that I know will be fixed or improved as necessary, and I would be willing to go without exported comments if the Dreamwidth tool will provide a complete set of all my entries.

It would also be rather nice if the more esoteric options on the tool's page had more explanatory labels. Currently, this is approximately what the "Fields" options look like:

- ID Number
- Event Time (from your clock) *
- Log Time (from system's clock) *
- Subject
- Event *
- Security Level
- Allow Mask *
- Current Mood & Music

Some of these fields (the unstarred ones) are fairly self-explanatory. The rest are somewhat confusing to me-- "Event Time" and "Log Time" seem self-explanatory at first glance, but then you also have "Event", and before I actually looked at an export file, I honestly wasn't sure what all those fields would mean when taken together. "Allow Mask" is also really badly named, and probably should not be an option at all, since that field is basically the bit that is used to determine whether an entry is public or access-only. Not exporting that field just removes part of the distinction made between private and public entries in the export file, which really doesn't serve any purpose since the tool currently exports everything. A fine-grained option to control what is exported would be nice, but it probably should not be at all related to what fields get exported.

Another confusing option on the page is: "Don't translate between encodings". Is this something an end user is supposed to just know? I know what encodings are, and that option does not really tell me exactly what it does. Does ticking the option mean that it will just leave any entries that are not encoded as X (where X is the encoding you selected from the preceding combo box) as they currently are? Is this an option that's more for debugging or troubleshooting export files that don't import elsewhere correctly? Should it even be on the page at all?

As far as using the tool goes...well. There is nothing on the page that indicates that the tool will only export by month, so unless you got to it from the FAQ, you won't even know about that. When I tried putting in just the year to see if I would get an explanatory error, it basically just gave me an empty CSV or XML file named after the year. Putting in the wrong month/year combination also gave me an empty file, which, remember, I won't know about until I actually look within the file. Considering that the tool is supposed to let you export entries, I really think it should let you know when your settings mean that you will not be exporting any entries at all.

In summary, what I want is for the export tool to
a) Allow you to export entries by year
b) Allow you to export all your journal's entries at once
c) Provide understandable and useful options that will not make your export useless or incomplete in ways that you did not mean (e.g. if, for some reason, you do not select "Event", none of your entry text will be added to the export file)

If there is a question of the tool putting strain on the servers, the number of times that free users can export their journals can be restricted (e.g. once a month, once every couple months, etc).

Poll #7709 Revamping the 'Export Journal' tool to allow exporting in larger time intervals

Open to: Registered Users, detailed results viewable to: All, participants: 46

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
21 (45.7%)

Should be implemented with changes. (please comment)
9 (19.6%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
16 (34.8%)

(Other: please comment)
0 (0.0%)

Comments

[denise]

I don't think there'd be a problem with exporting comments to a file, just with re-importing them once they'd been exported.

[matgb]

I've always wondered why that objection is there anyway-it effectively means an import from Blogger or Wordpress is impossible as well, as a blog owner can edit anything on their blog on both those platforms. If the plan continues to be to allow imports from them, then the difference between that and importing from file is tiny-sure, there might be some abuse caes, but they'd be done by people who'd do abusive stuff anyway.

[azurelunatic]

I believe the traditionally-suggested thing involves labeling such imports so that their source is apparent and clear (like an "(imported from file) (?)" note), thus allowing anyone who saw it to make up their own mind about how much trust to put in the words as published, complete with nice prominent FAQ link about what exactly "imported from file" meant and implied, for those who did not already know on their own.

Not sure how much that would be wp-beans to people in possession of files to import from, however. Oh well.

[denise]

Comments from those services will likely be a different case, as they're essentially anonymous comments and the commenter has no expectation of being able to manage their comment once it's been made. (Not to mention, yeah, the owner of the blog can edit comments/change comments/yadda.) So, we'll likely import those as anonymous, not as authenticated; they're a different use case and a different community expectation.