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

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
- - 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.

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

Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Reply via email to