Archive for December 2005

And now for a commercial break…

I’ll be taking a short break from working on Beyond, because I’m designing a book for a friend. I don’t imagine it will take more than a few days, though — at least not the time-intensive part of it.

But concerning Beyond, part of me wants to try writing a smaller app first (iDiary, I’ve called it), to test the waters and get some experience coding in Objective-C with Cocoa. But part of me wants to jump right in with Beyond instead of “wasting time.” I’m still not sure which part will win. :) At any rate, from time to time I take a step back and say to myself, “What in the heck do you think you’re doing?!? You can’t really do this.” And then I look at a quote I put up on wall: “You must do the thing you think you cannot do” (Eleanor Roosevelt). And then it’s back to the battle, because I am going to do this, no matter how difficult it is or how many obstacles other are or how impossible it seems. You can call it my personal Everest if you like. :)

Back to life :)

Sorry for not posting in a while. I’ll post again later today with more details, but rest assured that work has not halted. :) I’m still in the design stage, but this week I plan to finalize the first designs and start running them by people for usability testing. I’m also sending back the non-disclosure agreement today for the PAF specs, so I should get that back in the near future. I think I’ll work on the website, too, since that’s kind of essential. :) Since I’ve never coded for Mac before, I’m going to write a small journaling program first, to get a feel for things. At the moment I’m reading through the OS X developer guidelines and the human interface guidelines. Lots of good stuff there.

One decision I need to make soon is how to store the data internally. Speed is essential, as is scalability (since there are people out there with well over 10,000 names in their file). Hmm…

And now for a break

I’ve been reading Designing from Both Sides of the Screen, which is really good. I’m leaving for Mexico tomorrow morning and won’t have Internet access, but by the time I get back I expect to have first drafts of the task flow diagrams and hopefully much of the UI (but then again I don’t know how much time I’ll have to work on it while I’m there).

Do I really have to name these posts?

The PAF guys up at the Family History Department in Salt Lake are sending me the paperwork necessary to get the sample source code for working with the PAF database (file format). Hopefully it’ll include specs for the older versions; if not, I’ll lobby for them until I get them. :) Compatibility’s important. In the meantime, the first prototype will read Beyond’s native format and (since Beyond’s native format will be useless until I add the editing features) GEDCOM.

Usability

I checked out several books on usability from the library, including Joel Spolsky’s User Interface Design for Programmers, which I read last night, and Designing from Both Sides of the Screen (Ellen Isaacs and Alan Walendowski), which I’m reading right now. Good stuff. My primary goal for Beyond, which has now risen above all the others, is usability. The second, just as important, is simplicity. Now my task is to figure out how to take all these 10 pages of features I’ve come up with over the past two weeks and condense them into a simple and supremely usable interface that fits the needs of beginner and expert alike… :)

UI design

I’m reading stuff on user interface design. Anti-Mac is quite interesting… Wow, this is a short post. :)

PAF stuff

Spent some time exploring PAF today, to see all the features it has. There are more than I realized. :) But I did come across some design shortcomings that I as a user found frustrating:

1. Navigating through my tree was bothersome. It was clunky, basically, and didn’t feel smooth. Beyond will fix that. :) (More on that in the preview release.)

2. Searching for people was difficult. I wanted to search by first name but the default search only let me search by last name (I would have to set up a filter to get it to work). Too much effort. Searching needs to be fast and easy. And selecting one of the search results should automatically update the main window.

I’ve been thinking about how the program should be designed, interface-wise. Should I use drawers? Panes? I’m going to draft a set of user interactions (basically what the user will be trying to do and how they go about doing it) for a number of tasks to see what is used most commonly and thus should be prominent in the interface. Designing this app is going to take longer than usual, but I think the end result will be well worth it.

Designing away

This coming week I’ll be doing more research for the program, in the following general areas:

1. Usability. The goal is to make Beyond as user-friendly as possible. So, what goes into making an application user-friendly? How can I ensure that users’ needs are met? Part will be familiarity, which will come from borrowing familiar models (like the web browser model), at least in theory. We’ll have to wait for the first beta release to see if that’s actually true or not. :) Keystrokes have to be well-chosen (and completely user-configurable, of course). Things have to feel right. I’ll also be doing usability tests to see what things people have trouble with and where we can make it easier.

2. Database format. I’m almost 100% certain that the native file format will be in XML, but internally I need something faster, especially when the files contain over 10,000 names. Core Data looks nice but I don’t have Tiger, so we’ll see if we can do without for now.

3. Open file formats. The goal is for Beyond to be 100% compatible with PAF (not only 5.2 — the latest version — but also the earlier versions, so that you’ll be able to open any old PAF file and save it into whichever format you want) and GEDCOM and whatever else I can get specs for. And instead of having to import it into Beyond’s native format (which of course you’ll be able to do), you’ll be able to open a PAF file and work with it and save it just as if you were running PAF itself. The idea is for it to work kind of like Photoshop — you can open a JPEG and hit save and it’ll save a JPEG, not a PSD file. And of course you’ll be able to have multiple documents open.

Anyway, I have pages and pages of design ideas that just keep coming. This week I’ll hopefully get a good grip on the internal database format so I can design the file structure and write the core of the viewer module. I’ll also put together the website and write some general design docs and a release milestone chart and stuff like that.

New banner and more

Finished the new banner today. I’m satisfied enough with it that I can start coding. :) (I’m the sort of person who has to have a beautiful banner under which to code, otherwise it just doesn’t go as well.)

I’m also corresponding with the Family History Department of the Church (the Church will mean The Church of Jesus Christ of Latter-day Saints, by the way) about the PAF file format. One of my new goals for Beyond is as much compatibility with PAF (including older versions) and other genealogy programs as possible.

Oh, I guess I should say what Beyond is, huh. :) Beyond is currently in the design stages and will be a next-generation genealogy program for the Mac. Some of the goals I envision for it (and I’ll write these up on the website once I create the website :)) include compatibility with PAF and TempleReady, very user-friendly (and not just for beginning users but also for expert genealogy researchers), and solid with respect to sources and evidence. I realize this is hardly anything but I’ll get the planned specs up soon.

Coming soon…

This blog is about the development of Beyond, a genealogy program for the Mac. More to come in the very near future…