The medusa and the snail
Or rather just the snail. This is taking too long! Right now I’m working on Beyond only in my free time (because of these work projects that have a higher priority), and there isn’t much of that with midterms crunching me (not to mention other obligations). But the time constraint isn’t the main thing.
What’s taking too long is designing the interfaces. I think I’m a perfectionist and so I want to get each screen just right before proceeding, which is really slow and not good for creativity. Time to say goodbye to Mr. Perfectionist. Bypassing the internal censor (and this is common to writing and other arts as well) will free me up to get the ideas out and done with, and then I’ll be able to start coding. (I’ve hesitated to start coding until the interface was done, per the 37signals philosophy. But I’ll admit that they don’t recommend taking forever on the interface design. I’ll have to get back on track…)
Here’s a quickie roadmap of what I hope to accomplish next:
- Finish rough drafts of the interface
- Put together really quick HTML mockups of the interface
- Design the database
- Upload some test data
- Write code to display the data in some usable form
- Figure out where to go from here :)
To make sure that I don’t get caught up in the interface design again, perhaps I’ll set a limit on myself — one minute per screen, or something. We’ll see. Being a graphic designer has its downsides when doing stuff like this, because it’s hard to allow yourself to put out unbeautiful screens. Oh well.
Posted in Design
Comment feed for this post
Why don’t you put all your effort into improving an existing open source project. Do you really think that you have the resources to build something similar to PhpGedView? It would be a terrible waste.
I’ve certainly thought about that many, many times. “What in the blazes do you think you’re doing? This is madness, you know, pure madness.” :) And here is my response:
I think it’s great that people have put together projects like phpGedView, and I don’t want to demean their efforts in the slightest. They do good work. But I have a different vision for how things ought to be done, and it would be impossible to take an existing project (especially one as far along as phpGedView) and mold it into what I think it needs to be. (Not to mention the fact that the developers might have a bone to pick with that. :))
Instead, starting from scratch is the only thing to do, because none of the existing solutions are satisfactory as far as I’m concerned. The closest was PAF, but that’s only available for Windows. Thus Beyond was born.
I don’t want to pick apart phpGedView’s faults, since that’s not fair or nice. But I can say why I chose to start a new project. First, user-friendliness is key and has to be designed in from the very beginning. Second, simplicity, not feature bloat. Third, aesthetics (or style or taste, whatever you want to call it).
Do I really think that I have the resources to build this? Heck no! :) It depends on how you define “this,” actually. I do think that I can build a solid foundation, yes, and from there get help with the rest. phpGedView wasn’t built by a solo developer. :) (Nor was Rome built in a day, for that matter.)
I can’t join forces with a project which has a markedly different philosophy, at least not on anything but a superficial level. No, that doesn’t mean I’m against collaboration — certainly not! But I’m going to do what’s best for Beyond and what I deem best for users and the genealogy world, and if that means being different, so be it.
One last reason: being small means I’m free to innovate and try new ideas, with a very low cost (in time and resources, since there isn’t a huge code base threatening to fall on me if I mess up). Can’t beat that. :)
Keep in mind that PhpGedView has full SOAP access to its data layer, so you could use that for the full back end support, and bolt your front end to the back end using the SOAP interface. This woulkd save you a LOT of time in recreating the wheel. I am sure that they would be glad to add any SOAP interfaces that you might need that are not currently availible. This would free you up to work on the user friendly front end.
Here is a link that might be out of date but provides some info
http://phpgedview.net/devdocs/webservice_api.php
But there are things I want to do with the data layer that I can’t do with PhpGedView (my way of doing evidence/sources, for example, and the research pages). And not to mention the revision control idea. Nor do I think GEDCOM is a good foundation to build on. These things might be possible to change, yes, but (a) it’s more work than doing it from the ground up, (b) I’m not a lead developer on PhpGedView and thus don’t have the clout or authority to make these sorts of changes, and (c) I don’t want to work in PHP, I want to work in Ruby on Rails.
I appreciate your concerns, and I hope that PhpGedView continues to get better and better. As I’ve said before, I’m not in this for self-aggrandizement; I’m in it to make the genealogical world a better place. Beyond gives me a blank slate on which I can try new ideas, and if any good ideas do come out of this, other developers are more than welcome to incorporate them into their projects.
In short, I’m not concerned so much about the time/resources issue. Constraints often unleash creativity, honestly, and that’s good. PhpGedView just isn’t my style; sorry.
Plus, names are important (at least for poets like me :)). Firefox is a much cooler name than, say, HtmlWebView. But I digress.
Let me put it this way: I’ve been reading 37signals’ Getting Real stuff, and I completely agree with them. It’s the Right Way to do things. It’s also the Mac Way, to be honest. Steve Jobs and 37signals have style and good taste. I’m going with them. PhpGedView, conversely, wasn’t built that way, and so I’m really just not all that interested. Sure, I’ll make Beyond as compatible as possible with PhpGedView and all the other record managers out there, but I have my own vision of what Beyond can become, and I’m not going to give that up. Again, sorry.
BTW PhpGedView supports committing all data changes into either CVS or SVN, so this should nto be an issue (it is a config option). PhpGedView has a new Research Assistant module developed by Neumont Univ. If this had a SOAP layer would that help?
You might not be a PhpGedView developer, but did you ever ask on their forums about the items that interest you? or are you just assuming that any suggestion would be rejected?
Two more things: PhpGedView is bit of a pain to install (more than it should be, at any rate — look at WordPress’s simplicity for a comparison), and the initial configuration screens are daunting and completely unfriendly. But I’ll install it again and give it a second chance. (Well, a second chance to see what it does and how it works, but I doubt I’ll switch over to use it.)
Make sure that you use the latest 4.0 beta and not the 3.3.8 version. Ease of use is very important, but much less so for a server sided install.
Um, I disagree. Administrators need to be happy as much as users do (especially when they’re the same person). Installing WordPress is extremely easy, which makes me as a blog administrator happy.
As for whether the SOAP layer would help, the kinds of things I have in mind go down to the very core of the app. It wouldn’t be nice of me to insist on the PGV developers uprooting everything just to suit me and my (radical) ideas. (And no, I don’t think they’d necessarily brush off my suggestions.)
Anyway, I don’t want to wage war with PhpGedView. :) Our paths will be different, but that’s okay. We can learn from each other and cooperate, and yet I don’t think we need to merge. At least not at this point; we’ll see where we are a year from now.
Let’s just leave it at that. And yes, I’ll try the 4.0 beta and report on it.
One last thing: my aim is simplicity, which means cutting out features. PhpGedView seems to be more interested in adding them. (It’s not just PGV, of course — virtually all the applications out there are the same way.) That alone is reason for this project.
Ponds?