-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey Folks,
I reread our conversation and my need to contribution is not met by it. So I made a request to myself to remove any attachment to the outcome of this conversation and write from this point. When I originally wrote my question about why the account types are good at all I was coming for the same perspective where Trevis was coming. I see account types as extra stress on the source code and on the developers, because If you have a simple easily maintainable data structure the software itself is a lot simpler to create and extend later. In order to find the best solution I decided to put together a specification which includes both the data and the usability side. I'd like to invite all of you to add modify, comment constructively what I put together here. === Definitions === - - Field This is the smallest entity in the system, a container which holds the actual information what the user wants to store. There are several types of the field which are hard coded into the system and all of them have certain functionality. List of types: * Text Can hold one line of characters. Can copy the test to the clipboard. * Password Can hold one line of alphanumeric characters and able to generate text based on certain rules. The visibility of the content of the field is changeable. Can copy the password to the clipboard. * Multi line text Can hold multiple lines of characters * URL Can hold one line of characters which are pointing to a website. The format is http(s)://........... It can launch the browser to view the website. The browser can be set also. * Email Can hold one lines of characters. The format is [EMAIL PROTECTED] * Intelligent Launcher Can hold one lines of characters. The content of the field can be executed by the shell. The line can contain pointer to other fields. Example: command %user% %password% * Date Can hold a date and time with a date time picker tool. * File Can contain the name and the content of a file - - Tag This is a user defined data which can be used for labeling. - - Account This is a container which hold several fields in itself. Properties of an account: * Name * Icon * Multiple tags - - Collection This is a set of rules what defines an account. The rules can define the name, the icon, predefined tags, list of fields and the content of the fields. - - Container This is a file which can be saved and loaded to and from the disk. The structure of the file is XML. It is encrypted with a single password. It contains: * Accounts * Collections === Operation === - - Create account - - Create account based on a collection - - Delete account - - Duplicate account - - Edit properties of an account: * Name * Icon * Tags - - Edit list of fields of an account: * Remove field * Add field * Rename field * Change type of field - - Edit content of fields of an account - - Edit list of fields of multiple accounts * Remove field * Add field * Rename field * Change type of field - - Edit content of fields of multiple accounts - - Create collection - - Delete collection - - Duplicate collection - - Edit properties of a collection * Name of collection * Icon of collection - - Edit rules of a collection * Name of to be created account * Icon of to be created account * Tags * Remove field * Add field * Rename field * Change type of field - - Create container - - Load container - - Save container - - Save as container - - Delete container === Display === - - Show accounts - - Filter accounts based on multiple tags. Have at least a 2 levels filtering. - - Search within the accounts === Other functionality === - - Import and export from and to other applications - - Password generation based on length and character set. (avoid ambiguous characters) - - On application start reload last opened file - - Lock application and ask for password again after a certain amount of time === Back to our discussion === There were two main questions during our discussion regarding to the account type vs template question: Filtering / Searching: With multiple tags the filtering is possible in a very flexible way. On one hand it can be filtered by interest let say "my mothers stuff" on the other hand it can be filtered by similar accounts, lets say "my credit cards". Combining these two options gives us a very powerful filtering capability. Changing easily multiple similar accounts: With the "Edit list of fields of multiple accounts" and the "Edit content of fields of multiple accounts" functionality we are able to change everything what we want on multiple accounts. If I compare this with the maintaining the connection between account and account types I have to say that the existing way is much less powerful and it depends on hard coded functionality. Lets say that we have 10 ftp accounts and the code of the web account type says that the icon and the launcher of the account type must be the same on all of the accounts. This way if the launcher is changed on the account type it is going to be reflected on the individual accounts too. Very good. How about if you want one account handled by a different ftp client? How about if I change my username for all of my ftp accounts and that is not maintained by the ftp account type. I will end up opening all 10 accounts and renaming each of them. I don't have any problem with the account type, but I'm against any hard coded functionality, because today we agree to build these functionality and it turns out that the people wants to use it differently. If we go with the new model they are allowed to do whatever they want and we don't ever need to change the hard coded functionalities because there are none. It seems to me that with having simple arbitrary account with tags and bulk edit revelation would offer more functionality and freedom than with account types. I'm still open minded to hear your arguments and would love to see you modification to the above specification. Cheers, Karoly Molnar Devan Goodwin wrote: > On 2/21/07, Travis Snoozy <[EMAIL PROTECTED]> wrote: > >> Search, then bulk-change the results. That should totally be a >> feature, >> regardless of whether templates are used or not. > > What would you search on? Entries are now disjoint from their template > or type, unless you imagine using a tag, but that could return many > results not related unless you expect users to enforce a "tag == type" > mentality in their day to day use. I tend to think of tags as subject > matter related, and not as a type. > >> >> <snip> >> > Both of these are quite serious usability issues, and I'd say these >> > alone are reason enough to keep a link between the accounts and the >> > account type. >> <snip> >> >> You'll have this issue anyway, with custom accounts. I think that >> going >> to completely generic accounts with some default templates is the way >> to go. >> > > User modifies their custom account type, all affiliated entries are > updated. Not sure what you mean when you say this issue will exist > either way? > >> >> It's just a matter of developing the right tool set to work with the >> data. Having everything be template-based is waaaay more elegant and >> extensible, and this will make the code way simpler to deal with >> (there are no "special" code branches for specific types of accounts). >> You don't lose any of the benefits of having "hard" account types -- >> you just have to think about things in a slightly different way, and >> all of the functionality is present and accounted for. If you can't >> tell, I'm a big fan of having things be data-driven. :) > > I expect there won't be any account type specific code branches once > the current work towards custom account types is complete. > > I can understand striving for general solutions to problems, but I've > also seen it go too far to the point where a project sacrifices too > much usability or convenience. I'm not sure if this is such a case or > not, so I won't label it as such, just point out that picking > something that's more general may not always be the best decision. For > instance, we could all be using encrypted free form plain text files > to store our logins/passwords. :) Duplication of data is another > pitfall to avoid, and in this case I think we might be duplicating a > lot of data by forcing any information we'd like applied to a type > into every entry of that type. > > In my mind I see just one small benefit to severing the relationship > (one-off's), and many downsides that will affect the use of that data > through it's lifetime. I think my preference would remain to have the > entries affiliated with their types. My one-off needs are slim and > easily remedied by a notes field, or by Revelation knowing how to > interpret and display extra entry fields that it's type doesn't have > defined. > > Cheers, > > Devan > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF3g2kOkBLd7nU8XcRAnM6AJ9LvWmcZ1Cv7t2UpFzSBT6JY9299gCfThzs QD0GH9AlzxQYTHN1KgDm6gQ= =b/zn -----END PGP SIGNATURE-----
