Trust and Isolde
Earlier this afternoon I read Dan Lawyer’s post Trust Model. The intro paragraph does a great job of catching the gist of it:
Have you ever used an application that violated your trust? Maybe it didn’t save something when you thought it should have or maybe you unexpectedly came across you and all of your living relatives in some online pedigree. One of the subtleties to successful applications is not breaking the user’s trust model.
This is very, very, very important. I don’t think I can overstate it — it’s that important. There are two ideas in the article that hit me. First, access to data:
Provide at least the three mental buckets: my stuff, my shared stuff, and my published/public stuff. This does not imply complex access control systems. The simplest form can be stuff that only I can see, stuff that people on my shared list can see, and stuff everyone can see. More and more I find complex grouping concepts in sharing to be too much for ordinary people.
I admittedly hadn’t gotten to thinking much about this yet (except on a very cursory level), but I agree that the simpler it is, the better. Dan gives Flickr as an example, where your photos are private or public, but you can share private photos with friends and family as well (if you want). I like that. Not too complex, and I can’t think of any shortcomings, really. Sure, there might be complex situations, but I’m not going to design for complex situations if I don’t need to. Let the other record managers do that. I’m aiming at the 80% of the problem which most people will be dealing with. Fringe features have no place in Beyond.
The second idea, which is a beautiful solution for a problem I’ve been mulling over for a while now, is this:
Allow the user to say “I think” or “Maybe” about their conclusions. This is an area of functionality that is tempting to make overly complex. You could build a whole feature set around analyzing the quality of evidence, a surety schema, etc., etc. Ordinary people are likely to be driven off by this. One simple way to implement this might be to have a flag or button associated with fields that indicate that the conclusion is really a hypothesis of sorts. This would allow the user to share their work in progress with others without losing that important piece of metadata “I think”.
Is any more than that necessary? Either something is verified or it’s a “maybe.” I think that’s enough, and if more detail is required, they can go in the notes or research pages. The main thing is saying that the data isn’t certain. And that’s all it needs to be. This vastly simplifies things, which is a Good Thing. :)
Now I just need to figure out how to balance my time more wisely so that I can work on this project without completely leaving my schoolwork in the dust…
Technorati Tags: genealogy
Posted in Design
Comment feed for this post
I would suggest another category of conclusion: false. Because there’s a lot of disagreement about facts, it can be useful to assert when a specific fact is not true, and optionally why. This would be especially useful for interaction with other online genealogy services.
I’m thinking in particular of how Genesis will interact with Beyond. Genesis will have a software agent that identifies highly similar individuals and allows the user to mark them as the same, not the same, and “not sure.” Also, it allows the user to have conflicting facts about individuals along with their source data, and mark which ones the user doesn’t agree with. They still stick around though, because if they were removed completely, the same data would just get picked up again by the search agent.
My first reaction was, “What? You’d include data that’s patently false? What are you thinking?!?” :)
Whenever that’s my reaction, though, curiosity teases me along (surely there’s a reason for such an opinion), and after mulling it over a bit here’s what I’ve come up with. In a single-user environment (since that will often be the case), being able to mark data as false has the benefit of letting you know that something is clearly wrong (for example, you’ve found 1919 as a death date for your great grandfather all over the place on the Internet, but you know he was in the 1920 census, so while you don’t yet know what his death date is, you know it’s not 1919, and you want to remember that). Does something like this belong in the notes? Hmm…
It may be a moot point. In a collaborative tree, which is what I’d prefer to design for, you do need to mark data as incorrect — your uncle has been doing some research, let’s say, and he reads a name as Boffacle. But you’ve seen the records and it’s clearly Raffaele. So you mark Boffacle as wrong.
This brings up a question I should’ve thought about long ago. ~blush~ Namely, should all changes be stored separately? For example, in this last example, would you actually change Boffacle to Raffaele, or would you add another first name (so there would be two, Boffacle and Raffaele, with one marked as wrong and the other marked as sure)? Hmm… I’ve been subconsciously assuming the former, but that doesn’t work so well in a collaborative environment (especially when the community gets larger than a handful). Looks like it’s time to brainstorm on the ramifications of keeping all the variations…
(After that little PhpGedView debate on the other post, by the way, I have to say that you’ve made a good choice on the name of your project. :))