[Design][Sum] Should we rename Dump and Reload?

[Mimi Yin]

Okay trying to summarize requirements for renaming Dump and Reload:

What's wrong with the word Dump and Reload anyway?
+ Um, I think there's a sense that the term 'Dump' feels borderline  
farcical, given it's ahem, other uses in American-English slang.
+ Do users understand what Dump and Reload is? I don't think it's  
something people generally run into.

How do users usually do data migration?
+ A lot of the time, it's done auto-magically.
+ If it's manual, it's usually presented as an import/export feature.
+ Does anyone have any other examples?

Why import/export is misleading/confusing.
+ Reload replaces your entire repository. Import usually only adds to  
the data you have in an app.

More requirements
+ Shouldn't we communicate to the user the end-goal of the Dump/ 
Reload feature? which is Data migration?
- File>>Prepare for migration.. (Dump)
- File>>Migrate... (Reload)

Analysis
+ Is migration a common end-user term?
+ Upgrade is more common, but the user may not be upgrading, they  
might be switching platforms or even downgrading back to a more  
stable build ;o)

+ It seems like Import is the problem in this discussion because it  
sounds misleadingly innocuous.
+ Just because 'Dump' was a problem doesn't mean we can't still use  
'Reload'.
+ Do we need to specify the end-goal of the Dump feature (migration)?  
We don't do that for Import/Export .ics: Export to import into  
another calendar client, etc..

Another suggestion:
+ What about:
File>>
+ Import .ics calendar file...
+ Export .ics calendar file...
------
+ Export data to file...
+ Reload data from file...

Any more thoughts on the requirements? Any other suggestions?

We should also add a warning in the Reload dialog that it will  
overwrite any data you already have in Chandler.

Mimi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070508/5933bb5e/attachment.html