recovery file for page entry creation
What we need is to maintain a recovery/history file for page entries, before they are submitted. Even a simple keystroke logger. Just save 95% of what I type before I get a blue screen, or windows locks up. But like the history view in the web browser it is browseable, and purgable.
I bring this up because I've read a few horror stories about people site management conventions and loosing an entire session, or presentation when the computer / OS crapped out on them. I use MT, and haven't noticed this being a problem. It used to timeout on the post, but a backspace would return to the page window.
Does anyone else see a need for a draft history for page entries on the local side?
0 TrackBacks
Listed below are links to blogs that reference this entry: recovery file for page entry creation.
TrackBack URL for this entry: http://kennethhunt.com/mt/mt-tb.cgi/539
2 Comments
Search
Safari Online
invest in kevlar
chris harrison
Mike Erdely
The Open Prosthetics Project
Andrew W. Moore
Talking Out Loud with ASB
ducea
Andrew Baker
*scottstuff*
Ask Bjorn Hansen
Joe Topjian
John Sequeira's Weblog
Team Murder
defective yeti
postneo
Ben Hammersley
Chez Chrissie
The Frosty Mug Revolution
Jeremy Zawodny's blog
Lucas Gonze
Eric Norlin
slashdot
John Vu
Net Observer
Books Observer
Sterling
Bill Buxton
Melanie Rieback
ouch. I just started to compose a reply to your comment and Phoenix crashed.
Anyway this was a LazyWeb entry and I'm not 100% happy with the concept. I really like a browseable history of drafts that you were typing. I don't like a large bit bucket that is located in one place, so perhaps the drafts would replicate to the server. Yes. Composing in anything else is most likely stabler than the browser. But remember the critical mass will come from everyone blogging, just like everyone online has an email address. We need to prepare for these little hiccups and find ways to make the experience fun, not a pain in the neck. If the browser is the most widespread platform then we need to eliminate impacts from lost data, if it crashes. If a separate, standalone utility dominates, it should be even easier to add this content recovery. It's a trade off in any case, are they in a browser that may / can crash. Or are they running a Windows platform and experiencing OS issues...
One way to get around this is to periodically save your posts as drafts within MT. That way it actually goes somewhere other than the ether.
I've broken myself of the habit of composing directly in the browser. Every machine I work on has either GNU Emacs or XEmacs installed at least in my account. I have a tendency to work with way too many tabs open in a browser at any given time so it's usually a matter of if rather than when I crash the browser. Even if *emacs crashes it will dump something for me to work with post-mortem.