Archive for the 'Design' Category

Genealogy publishing

Going along with my ideas over the past few days, particularly that of focusing primarily on making Beyond a web application (though of course the desktop clients will follow, in their own due time), I’m starting to see Beyond in a newer light. I mentioned a little bit about this in my last post: people are inevitably going to want to do more than just edit their genealogy — they want to publish it. Not everything, of course, but they want to make charts that they can print out, and nowadays they want to publish to the web. I’m thinking something like genealogy translated into a blog metaphor, somehow. In fact, I still don’t know exactly how that’d work out, but I do really like the idea of making Beyond be more than just a record manager. This idea of publishing your family tree (or just part of it, even — you’d be able to specify what and how much) dynamically, with a live link, has taken hold of me. I’ve first got to look at the other apps out there — phpGedView, etc. — and see what’s around… And I’ll think about this some more, too.

Earlier this evening one of my Thai friends called and wanted some help putting together a genealogy website for her family. As I was considering what it would take, I realized that this probably fits very well into Beyond’s landscape (web-based, collaboration, etc.). And yet I don’t want that to be Beyond’s main focus — it’s going to be a record manager, and a darn good one at that. But I don’t think the two goals — managing records and publishing them — are mutually exclusive in any way.

As far as the Thai part goes, internationalization is a big thing. PAF, for example, isn’t translated into Thai, and when I try to enter Thai characters into a name field, it thinks they’re numbers. Everything will be Unicode, of course, and I’ll do my best to make sure things work out for languages with scripts radically different from ours, like Chinese, Hindi, and Arabic. More on this later. (Just out of curiosity, do pedigrees in Arabic flow from right to left? Hmm…)

Well, these thoughts aren’t as clear as I would’ve liked, but hopefully they’ll gel over the next day or two and I’ll figure out just what I’m trying to say. :) In the meantime, thanks to all those who’ve given input so far — it’s very helpful and I really appreciate it. Keep it coming. :)

More on genealogy anywhere

In the day or so since writing Genealogy Anywhere, my vision has expanded. “Genealogy anywhere” has really caught hold of me, and I’ve realized that what we need is a Firefox of genealogy, so to speak. Universality has become the new north star of the project. And so there will be Windows and Linux versions, and whatever else people use. But don’t worry, Mac users, the Mac will always be my top priority. (And I’m not going to be writing the Windows/Linux versions — others can do that.) And of course we’ll get it translated into as many languages as possible. (I have connections. :))

I’m glad I’ve come to this before I really started coding, because this will require a strict separation layer so that ports to other OSes will be possible (and not exasperating). Time to look seriously at the Firefox model and see how they do things…

Genealogy anywhere

During my text processing class this afternoon I was reading through the phpGedView website, and I came across this question on the about page: “How do you synchronize your data with your relatives when they make changes on their computers?” (It’s a question phpGedView tries to answer.) When I read that, I suddenly thought of CVS (Concurrent Versioning System). Rather than explain CVS (you can read about it on your own if you’d like), let me explain what this means for genealogy. Imagine the following scenario:

Your family tree data is stored on a central server (either something like Writeboard.com or your own personal web server). When you use Beyond on your Mac, it downloads a local copy of your data from the server and you can work on that without being connected to the Internet (useful for when you’re in the field). If you want to collaborate with someone else — let’s say it’s your sister — you can give them access to all or just part of your data. They download their own local copy and work on that. When you’re done making changes, Beyond uploads the data back to the server. Your sister does the same thing. What if there are conflicts? It allows you to decide which changes take precedence, so nothing is lost. Seamless.

It gets better. Say you have three computers at home. You install Beyond on the second computer and it will automatically download your data from the server, complete with latest changes. Ditto for the third. You can work on whichever one you want and don’t have to worry about synchronization — Beyond takes care of that for you. If you go on a trip, you can take your laptop with you, work on your genealogy as much as you want to, and when you get back home, it’ll re-sync with the server so that your desktops will automatically get the updates.

Now for the crown jewel: what if you’re on a computer where you can’t install Beyond? What if — gasp — you’re on Windows box? There’ll also be a web app which lets you access the same data as the desktop app — it’s all on that central server — and so you’re up-to-date no matter where you go on the world, on any computer. Any computer. And you don’t have to worry about flash drives or copying files or anything like that. The web app would have to have reduced functionality, of course, but you’d still be able to do all the things that matter (including printing charts to PDF). So you’re at the library and forgot to bring your pedigree with you? No worries, just go to one of the computers, log in, and print the chart (remember that this is from your latest data, the same you were working on fifteen minutes ago when you left your house).

As far as the user interface goes, it’ll have to be seamless, utterly transparent and easy to use. No clunky upload/download dialogs (unless something goes wrong). It’d be nice to be able to “check out” only certain parts of your tree, but I don’t know if that’d work too well… An advantage would be that edit histories would be built-in (by nature of the whole central-access metaphor), so you could see who edited what and when. Another is having duplicate copies of your data (you have at least two, one on your desktop and one on the server, and more if you’re collaborating with someone else). Truth be told, I can’t think of any disadvantages. If you can, please leave a comment.

You know, this is extra incentive to use SQLite, because I can use that for the desktop implementation and a normal MySQL database for the online storage. Hmm, I’m liking this idea a lot. But of course you wouldn’t have to have an online server to be able to use Beyond — it’d be perfectly usable as a standalone desktop app that never connected to the Internet at all. No worries there.

So, after I came up with all this, I was reading Dan Lawyer’s post Raising the Bar for Record Managers and came across this comment by Dallan Quass (the guy in charge of WeRelate:

Another possible 11th suggestion is the ability to “sync” your local desktop client with an on-line record manager, where you can see what changes others have made and accept or reject those changes in your desktop repository. This is similar to what software engineers use when a group of distributed engineers collaborate using a shared on-line repository that can be sync’ed with their off-line desktop repositories.

Sounds mighty familiar. :) But to my credit, I hadn’t read that until after I’d come up with all of the above. But that doesn’t matter, because this isn’t about me, this is about progress and making a better genealogy experience for all of you. And that’s what I’m committed to.

To web or not to web?

I’m thinking more about the possibilities of Beyond as a web app.

Advantages:

  • You can use it on any computer in the world, basically
  • Storage concerns no longer exist
  • Collaboration becomes much more feasible
  • It’s easier to make your data part of the web, if you want

Disadvantages:

  • You have to have your own web server[1]
  • The interface couldn’t be as rich
  • Your Internet connection has to be up to be able to work

[1] Unless someone started a website hosting accounts, which people could use like they use Flickr. But I don’t have the resources to do that.

Well, I don’t really know. Visual overlays for merging data would be harder to pull off in a web setting. As for requiring a web server, does phpGedView do that? Hmm, I need to look into that… The advantages of a web app are nice, especially if you don’t have your own computer (or your computer is broken :)).

Anyway, the main thing is to figure out whether the Right Thing is to stick with making a desktop app or to make a next-generation (pun intended) web app instead. Comments?

Separation of powers

Until my laptop died, I hadn’t really considered separating the underlying code from the user interface (Cocoa). But now that I can’t actually develop the interface until I fix my laptop, I’m forced to see what I can work on until that time. And thus I’ve realized that I really ought to make the underlying code as free from Cocoa as possible so that Beyond can be ported to Gtk or Qt or, heaven forbid, even Win32.

In retrospect, it completely boggles my mind that I wasn’t thinking along these lines from the beginning. I do believe in separating style from content, so to speak. Weird.

Taking genealogy to the common person

Discovered an excellent new blog by Dan Lawyer, Taking Genealogy to the Common Person. There’s been a lot of good discussion on it so far and I expect it to continue with innovative ideas and other things that need to happen to make genealogy the best it can be. There’s also Randy Wilson’s Source-Centric Genealogy, which holds promise but isn’t updated as often as I’d like (and there’s only one post so far).

As far as Beyond goes, my laptop died yesterday and I’m still trying to figure out what I’m going to do. The Macs on campus unfortunately don’t have Xcode installed. Maybe PyObjC would still work… I can still work on the design, of course, but I don’t have any code written and this projet’s vaporware status is bothering me a great deal. Balancing my various and sundry projects has been a tad bit difficult. But that’s no excuse. ~sigh~

Before my Powerbook died, however, I did start looking at the PAF file format. It’s more complicated than I’d expected, but not impossible (obviously). I think I’ll start by writing a Python program which reads/writes PAF files (and I can do that from any computer, really, since I don’t need Xcode).

Brainstorming notes

Set aside an hour of time tonight to work on Beyond. I consolidated my ideas into one file and put them into a PDF: Beyond-Brainstorming.pdf. Keep in mind that this is very raw material, mostly unedited. The next step is to decide on the goals I want Beyond to achieve, which will in turn influence the guidelines I use in making design decisions (like which features are important). Some of these goals have already popped up in the brainstorming PDF, as you’ll see.

I tried to do some UI sketches but realized that I need to solidify these goals first, and I also need to get a clearer picture of what the data model is going to be like. (I’d like Beyond to be capable of historical research beyond just family history — so you can use it to research the history of an organization or a town, for example — and so the interface needs to be flexible enough to support both that and the normal pedigrees, etc.) I don’t know yet if there’s a clean, beautiful way to support both types of research in the same interface; if not, I’ll either have to ditch the historical part (which I don’t really want to do) or build two interfaces. By “interface” I mean the way you access the data (pedigree charts, family group records, lists of individuals and families, etc.). With an organization, for example, you have roles (president, vice president, committee member, etc.) that can have multiple people filling them at different times (e.g., “Jack Brown was president from 1892 to 1895; Steven Stevens was president from 1895 to 1899″). Things get complicated. Hmm, I may end up splitting the historical research stuff into a separate app, leaving Beyond with just the genealogical aspects of it. Simpler = better. I’ll think about it some more and decide later.

A review of GEDitCOM

Over the next week I’ll be trying out the various Mac genealogy apps and seeing what’s good and what’s not. So I downloaded GEDitCOM and just tried it out. Um, can we say unintuitive? First of all, when you start it for the first time, it doesn’t actually open a window. So you have to go up to the menu bar and create a new file. Bad. Second, when I do create a new file, up comes a grid and it’s not really clear what to do next. There is a textbox saying “Typed Name:”, so I tried typing a name in there and hitting Return. Nothing happened. So I went down to the grid/table (which has labels like Name, Birth, Death, Father, and Mother) and tried typing in a name, to add a person. Nothing. Double-clicked. Nothing. Finally I had to go up to the menu and find the New Individual command, which is under Tree. Not intuitive. And the “New Individual” dialog is…ugly. The toolbar’s not helpful because it’s not clear from the icons what they do, and they’re not labeled.

Anyway, enough of that. I’ve got to get to bed and so I haven’t been able to do more with it, because I’m sure it has strengths that I just haven’t found yet. At any rate, seeing the level of user unfriendliness has renewed my determination to write Beyond as soon as I can and show the world how easy genealogy can be (at least when it comes to the software :)).

Shower inspirations

This morning in the shower I thought about my grandmother and wondered whether she’s been doing any genealogy lately. If she has, then of course I’d want to get a copy of her PAF file. That would then mean merging it with mine, or at least looking at the differences (including what’s new since her last update). The natural way to do that, I think, is visually. Imagine Photoshop layers: you have one file on one layer, and the next file on the next (and you could, in theory, compare even more files). There would have to be symbols overlaid on the chart so you could tell what doesn’t match up — one symbol/color meaning that it’s the same person but some of the dates/places aren’t the same, another meaning that it doesn’t look like it’s the same person, etc. Then you could overview the whole pedigree and see who you need to check. There would need to be a normal list-of-changes view as well, so that you don’t miss anything. But this seems to be a better way (a more natural way, at least) of comparing data.

Problem: there are people in the database who aren’t on the pedigree. (Namely, anyone who isn’t your direct ancestor.) Hmm… This is a problem, especially because I want Beyond to support non-family relationships as well (so you can say “Joe Clark was my friend in 2002,” or “Rick Magleby was Jane’s boss from 1995-1999″ or “Thomas Watkins bought land from Robert Shanks for $32.47 on 23 Jun 1832″). Why? Historical research needs it, to be thorough. That way you can see every person who’s connected to your ancestor in any way. (Lots of non-family relationships show up in the records, and it’d be nice to store those, because they can be of great value in finding clues that help further your research.)

Perhaps a circle/cloud view like Visual Thesaurus’s would work. You start with the Home person (#1, probably yourself) in the middle, and then the connections branch out like spokes in a wheel. The only issue with that is it’d be rather messy. I wonder if there’s a good and uncluttered way to represent a database like that…

More ideas: for the pedigree view (and this will apply to the whole-database view, once I figure out what it’ll be), I want the user to be able to zoom to any level. So instead of being set at four generations on a screen, you can zoom in/out and pan around (like in Illustrator or Photoshop). There’ll also be an Overview window off to the side that shows you the whole chart and pinpoints your current location on it (like a map, basically).

Finally, unlimited undo. I’d like to do a history list like in Photoshop, actually. The main reason is that if users feel secure and safe with the program — when they know that their data isn’t going to disappear and that they can undo anything they later regret — they’ll be more free to experiment and tinker with the data. And that’s where the good research starts to blossom.

Tagging

With all the tagging craze going on (del.icio.us, Flickr, LibraryThing, etc.), I’ve been wondering if tags would be useful in Beyond. Imagine being able to tag a person (or family, or line, or piece of data attached to a person) as “researching” or “notsure” or “followup” or whatever. If you’re collaborating with someone else, you could even tag the item with their name — a line tagged “matt” would then mean that Matt’s working on that particular thing. The advantage of this is that users would be able to superimpose their own organization on their data, free of chronology and other inherent groupings (though of course those would still be there, just on a different level). And of course you’d be able to search for tags and all that.

Another idea: it would be nice to know when you last worked on a line, a history of your research of sorts. Perhaps this would best be done visually, in the pedigree chart (the boldest lines being the ones you’ve worked on lately, fading out to the ones you haven’t touched in a while). Hmm…

Throughout the next while I’ll be brainstorming up ideas like this and then deciding which features are really necessary/useful and which can be relegated to post-1.0 status. Time to start compiling a possible-features list…

 

WordPress database error: [Table './blanksl1_beyond/wp_bdprt_targets' is marked as crashed and should be repaired]
SELECT target_ident, last_updated, target_page_url, taregt_page_title FROM wp_bdprt_targets WHERE target_page_url='/index.php'

WordPress database error: [Table './blanksl1_beyond/wp_bdprt_targets' is marked as crashed and should be repaired]
INSERT INTO wp_bdprt_targets (target_page_url, taregt_page_title, last_updated) VALUES ('/index.php', 'Design', '1231291147')