Hi, this is a nifty app. I like it's simplicity and speed. But I'm reluctant to bang in lots of data to an application that I can't get it out again, if need be. I read your comment about the Print Wallet button being the only current way of exporting data, so I'd like to cast my vote for a button to "Export Wallet to CSV", or something like that. I know this would blow any security on the wallet, but if the user clicked that button, it would be their choice after all. Similarly, if there could be an "Import from CSV" button, that would be extermely handy.
That's a good topic.
We've spent some time trying to figure out how should the CSV look like, given that each card has different set of fileds. There does not seem to be a good way to do this. the best I could come up with is this ("sparse mapping"):
| UserID | password | web site | Driver license number | expires on |
|---|---|---|---|---|
| JohnDoe | Fido123 | http://gmail.com | - - - | - - - |
| - - - | - - - | - - - | WADOE123 | 02/2012 |
Or this ("tagged mapping"):
| name 1 | value 1 | name 2 | value 2 | name 2 | value 3 |
|---|---|---|---|---|---|
| UserID | JohnDoe | Password | Fido123 | web site | http://gmail.com |
| Driver license number | WADOE123 | expires on | 02/2012 | - - - | - - - |
Neither one looks good to me. How about you? Would you be happy with either one of these, do you have better ideas?
I liked the tagged mapping idea.
I was wondering, if I sync with the website and then get a warranty replacement for my iPhone,will the iPhone wallets get refilled from the website?
Yes, your data will flow from the website back to the iPhone. It was designed to work that way, and several people mentioned (among comments in iTunes app store) they had a chance to use it already.
Maybe you could have a field mapping script so you can determine which field goes to which upon importing. Also, the user could rename their main categories ("Web Logins", "Software Registrations", etc.) to match Memengo's so it knows which category to put it in.
I don't think many of our users will know how to write scripts… this is what you suggest, right?
I'm nt sure I understand your second idea (About user renaming things). Can you provide an example?
Hi Guys,
I guess it's difficult to get a bunch of relational tables into a flat spreadsheet? Of course I don't know how you have things organised but if you had something like a Values Table that relates to a Fields Table that relates to a Cards Table, could you export this to something like an access database?
Thanks.
How many people would know what to do with an Access database? We trying to make features appealing to most of our users, and so far the best we could come up with was the "Print" button.
Or design philosophy is that you should have three copies of data:
1. iPhone copy for everyday access when you're out and about.
2. Web Site access for convenient editing, and also for when the iPhone is not with you. Imagine gong on vacation and your iPhone being stolen? Web Site to the rescue!
3. A printed copy in the fire safe or a deposit box.
The first two should cover you in all of life's everyday situations. The last one is there in case of an unlikely event such our software getting irreparably broken, our compnay going out of business or your house burning down with the iPhone inside.
I can't imagine a situation that is not covered by these three copies of data.
The only thing that is missing here is ability to casually migrate to another software - you can still do it by re-typing things from the printed copy, but it's not convenient. Alas, for us to do something here would mean to export in a format that another program can import from - otherwise it's back to retyping. There is no single universal export/import format. A CSV file or an Access database are useless unless other programs can read from it.
The best solution in my opinion would be to use XML.
Example:
<wallet>
<folder>
<name>My Accounts</name>
<accounts>
<website>
<link>example.com</link>
<username>John Smith</username>
<password>mypw</password>
</website>
<website>
<link>test.com</link>
<username>John S</username>
<password>mypw</password>
</website>
<vehicle>
<licensenumber>1ABC234</licensenumber>
<year>2009</year>
</vehicle>
</accounts>
</folder>
</wallet>
You shouldn't have to worry about how other programs will use this information. All you need to do is support importing and exporting of this format on your website. People can easily modify the XML to match whatever program they are going to import from or export to. XML provides the most flexibility and the best data structure, especially for an application such as this where each entity has different fields.
Well, if you are willign to edit the result by hand, why not copy-paste the data from the "Print" page?
The only people who can take advantage of the structured nature of XML are people who can write their own programs to parse and transform the XML. In all other uses Print format is just as good, no?
The main reason you should support XML is so that you can implement an import feature. Forget about importing from another application for the moment. You mention that the print feature could be used as a last resort for a backup. Let's assume that the user does have a situation that they do need to restore from this backup. I'm sure they would appreciate it if they could have saved it as XML and would simply import all their data from the file they created, as opposed to having to manually create the potentially hundreds of accounts they just lost.
It would be significantly easier for you guys to implement import from XML as opposed to import from the print page.
The product is great btw, keep up the good work. Also, I like how you respond quickly to posts.
This makes sense. We actualy had this particular feature: export and import via the web site. It exported data still encrypted and thus not usable without our web site, so we decided that this would of little use and removed it.
By the way, if you lose your data to an accident (e.g. accidentally delete your data and sync to web site) please contact tech support - we can restore your web site account from backups. An importnat disclaimer: we currently provide this service for free, but if it gets popular we may have to start charging for it. I can promise that the switch will not be sudden and the charge will be reasonable (I am thinking $20 per incident).
I am also thinking about creating premium $20/year web site accounts that would include unlimited restoration from backup (hopefully you won't be losing your data all the time) and other customer support perks.
What do folks think fo this idea?