Friend Me
 Follow Me
 Feed Me
a blog by ken pardue

Archive for January, 2011

Mac Family Tree (6.0.10) Review and Feedback

Thursday, January 20th, 2011

With the opening of the Mac App Store, many titles that I’ve contemplated buying for some time have been on sale for deeply discounted prices, and thanks to a Christmas iTunes gift card I decided to jump in and get Mac Family Tree from Synium Software.  This blog will serve as both review and feedback for the developer.

What I like:

  • The bread crumbs in Mac Family Tree are probably the best implemented in any genealogy program I’ve used.  As I’m sure most family researchers are aware, it’s very, very easy to get completely lost in a family file.  Having a consistent way to travel back to a point, regardless of whether or not the context changes by clicking on a source or image, is extremely ideal
  • Source Handling is fantastic.  In the left pane, the source window tells how many sources there are, and the source list describes how many entries the source is assigned to.  A researcher can get to any of the entries to view its detail, and then use the aforementioned fantastic bread crumb trail to go right back to the source.
  • I like the way media is handled much better than how it was implemented in the previous program I was using.  The file is a central place for all of the media to be located, and a researcher can review all media in one place.  This makes much more sense than having the only way to review media to be browsing through individuals’ information pages and happen to notice that a picture is attached.
  • Tight integration with FamilySearch is a nice thing to have.  Although I haven’t personally used it, I can appreciate that FamilySearch feels much more purpose-driven than profit-driven, unlike its competitor.  But, a researcher isn’t limited to that, since the Web Search option allows searching across Ancestry, Ellis Island, Find A Grave, Footnote, Google, My Heritage, World Vital Records, etc.
  • The app has a fresh, fast appearance.  I count that as something I like only to counter it with the thought that it’s too focused on pizazz and not enough on substance.  The interface is pleasant to look at but clunky to use.

What I don’t like–and there are a lot of these but they’re mostly very minor:

  • One of the more interesting draws for the program, at least as far as screenshots go, is the 3D Virtual Tree, a representation of one’s family tree where you can navigate up, down, and around a network of individuals represented by blue or pink avatars.  While this is gorgeous to look at, it’s gimicky, and so cumbersome to navigate that it’s almost completely useless.  The Family Tree view accomplishes the same result and is much, much more practical.  It’s a real shame that the developers spent so much time making this utility and not enough refining the rest of the interface.
  • The fonts feel very non-standard.  It would probably make for a much more native feeling application if the fonts were less bold. They appear out of place next to other Mac apps.
  • Although Places is a wonderful utility allowing the user to plot an ancestor’s location on a 3D virtual globe of the Earth, it requires too precice of data.  It’s impossible to add just a county/parish or state through the search interface, for instance.  The search interface only allows one to tag specific cities, although you can manually enter latitiude and longitude for a location.
  • It would be very useful if the Places dialog was more granular and allowed a separate entry for county/parish.
  • The 3D world map doesn’t provide enough detail and is a fairly low resolution representation of the earth.  It would be much more useful if it showed state and parish/county lines.  The options to show day/night lighting and stars in the background are relatively useless here for researchers… unless of course your relatives come from outer space–a question I’m sure many family researchers wonder about!
  • The location of the search box breaks convention by being oddly located in the bottom right of the screen rather than the upper right.
  • The application doesn’t retain search results when navigating using the bread crumbs.  For example, a search for Union Parish brings up some 15 results.  I can click on one of those results to view its details, but when I go back, instead of showing the 15 results I see all of the places in the database.
  • The Person detail screen feels cumbersome and clunky.  I think most of this is because it suffers from Tab overload.  More on this in a moment.
  • When navigating the Family Tree view, the pane on the right side highlights the selected individual in a list of all of those in the researcher’s file, sorted alphabetically.  A much better use of this pane would be to show useful information such a birthdate and death dates, notes, etc. about the selected individual.  The current solution is useless, because there is no context for simply showing the individual’s name in a list of this sort.
  • The lines connecting spouses/children in the Family Tree View get very confused when complex families are introduced (e.g. families where both the husband and wife have multiple spouses, especially when there are children with each.  I’m not sure how this can be made visually distinct, but it’s cumbersome as is.
  • Perhaps it would be useful in the Family Tree View to have a way to set a default individual, e.g. the researcher, and have some sort of visual cue while navigating the family tree as to which relative to move to in order to get back to that individual?  With complex family trees, it’s very easy to get lost.  Having a visual cue leading back to a default individual would serve as an excellent bread crumb trail for context.
  • When assigning photos to individuals, if one photo is assigned to more than one person (e.g. a family group photo) MacFamilyTree shouldn’t make multiple copies of the photo in the Media Browser.  I should be able to view the photo and from the photo’s information see all of the people it is assigned to rather than a separate photo for each assignment.

The ‘Person Detail’ screen is where a researcher will spend many hours over the course of his or her research.  It also happens to be one of the clunkiest parts of the program, with a lot of unneccary and redundant information.  Here are my thoughts on how the ‘Person Detail’ screen might be improved:

  • Why is there a tab for “Additional Names?”  Not only is this a relatively rarely used field, but would actually be better placed under the Facts area.
  • “Person’s Families” is a very necessary item, obviously, because it provides quick access to a person’s parents, spouse(s), and children.  However, “Oldest Ancestors” seems like something that would be more appropriately found in some sort of report, or perhaps added to a Useful Information dialog that provides this and other useful statistics, such as the information in the “World History” tab.
  • In the “Person’s Family” tab, if I’ve already added parents and a spouse, why are “Add Parents” and “Add Partner” still visible, but grayed out?  Perhaps there’s some kind of bug with my data import, because I see the parents, a grayed out indicator saying “Family without Parents,” and the grayed out “Add Parents…” button.
  • “Person Context” on the right side seems to be somewhat redundant.  While I can see it useful to see an individual’s uncles or aunts, what this really does is replicate the “Person’s Family” tab, which is where all of the pertinent information is.
  • At the bottom of the screen, on the “Personal Events” tab, there are three separate columns covering the Place information (Place, State, Country).  This could be combined into a single field which leaves much more space for the information in the Description field, something that could very well be long enough to need it.
  • Also on the “Personal Events” tab, what is the point of having an extra column to display an icon for the event type (e.g. star for birth, a hammer for occupation, etc) if this same icon is repeated later under Event Type?  Instead, wouldn’t it be far more useful to be able to quickly see an icon indicating whether or not the given event has a source?
  • The “Sources” tab contains sources related to the selected person in a general sense. Why not just put that in with the “Personal Information”?
  • The options in the “Label” tab seem like they’d be more appropriate on the main screen.  Not only is it a small bit of information, just three check boxes, but it’s also information that’s extremely useful to have at a glance.  If I’m browsing through individuals, I’m not likely going to click on the “Labels” tab to see whether or not they areIncomplete or Important.

I realize most people who complain about an interface rarely come up with ideas to make it better.  While I’m far from being a user interface guru, I did take the time to at least put some of my thoughts to the screen with Photoshop:

Mockup for Mac Family Tree

Behold!  In one fell swoop I’ve eliminated the Additional Names tab, Old Ancestors tab, Notes tab, Sources tab, Label tab, and World tab, while presenting all of the pertinent information to the user by adding an improved Notes tab, combinging functions from the “Family View” into the individual view, and more efficiently locating Source and Label information.  I’m sure there would be a problem with reflowing content when it becomes too large on this screen, but at the outset, as a researcher, this looks much more useful to me.  Let’s consider:

We have the labels always visible on the screen.

We have expanded the area containing basic information about a person to include general source information.

We have a more robust Family Information screen that allows the user to add a new Father or Mother (since, as is the case for one person in my family, there may be conflicting information about who a person’s parents were–a person may have more than one father or mother listed), and we also have an indicator linking married parents.

We have a “Family Events” tab which, if thought through properly, could probably completely replace the Family view.

We have more useful “Person Events”, losing the redundant Event Type icon and replacing it with an indicator for whether or not an Event has Source information.  We also have a more compact and useful Place description, and a larger area to put in a Description of the event.

Finally, we have a new Notes tab which allows the researcher to type in notes about our Mr. John Q. User, as well as aggregate notes from other events attached to him.

Although I didn’t make a mockup for it, I envison the More Info tab here to contain the information such as the World History information, a listing of the person’s Oldest Ancestors, etc.  This may also be a good place to point out other useful information to the researcher, such as an improper birth and death date indicating the person died at the age of 147, or perhaps that there’s another John Quincy User in the database that might be a duplicate.

A New Twist in the HTML5 Video Saga

Tuesday, January 11th, 2011

Late in the day, a considerable announcement was made on the part of Google that once again shifts the battle lines in the development of the HTML5 standard.  Google announced on their Chromium blog that over the next few months they will phase out support for the H.264 video codec and exclusively support WebM and Theora.  Although Chrome is a lesser player in the browser market with a fractional market share compared to Internet Explorer and Firefox, this move is sending ripples throughout the browser market.  HTML5 video is one of the more contentious parts of the HTML5 spec because of codec support.

In terms of browser support, this polarizes the market since Chrome previously supported both H.264 and WebM.  The lines are clearly drawn with Internet Explorer and Safari (including mobile variants) supporting H.264 (65% of the market), and Firefox, Chrome, and Opera supporting WebM (35% of the market).  Although Internet Explorer can support WebM, I won’t include it in the WebM group since additional software must be downloaded to enable it.  If that were a good reason, then 100% of the aforementioned browsers use additional software to playback H.264 and the whole debate is moot.

So what does this mean for the web, in terms of both desktop and mobile?  Not much for either, at the moment.  Chrome’s market share is still too insignificant for it to have widespread usage effect.  People have spent more than a year slamming and dismissing Firefox’s only-open-codecs position.  Mozilla took a lot of heat and lost some market share when they decided to only support Theora (and later WebM) and not H.264.  Mozilla’s Robert O’Callahan acknowledges this heat while writing on Google’s announcement, saying, “Incidentally, it’s also a good day for us at Mozilla: the pressure that was building on us to support H.264 should ease off considerably.”  It was one of the big reasons cited for people moving to Chrome en masse.  For the most part, developers served HTML5 H.264 to browsers that can handle it and Flash H.264 video to lowly Firefox users.  My guess is that Chrome will simply join Firefox in that category.  However,  the move is having tremendous psychological effect.  For the desktop where hardware acceleration isn’t as important, it makes WebM look to have more staying power.  Unfortunately for Google, it also makes the company look like more of  a target for the salivating lawyers at MPEG-LA.  Google hasn’t exactly had much luck lately in steering clear of patent lawsuits on the principal of virtue.  For the mobile market where battery life is key, it simply underscores the competition between Android and everyone else.  The iPhone supports H.264 natively, as do virtually all other smart phones from Microsoft, RIM, etc.  H.264 has simply been around much longer and has a well established market from professional to consumer video, from production to consumption.  Android, assuming Google will also be dropping H.264 from it, will exclusively support WebM/Theora.  I truly support the idealism behind WebM.  It makes a lot of sense that something central to the evolution of the Web not be laden with patents upon which royalties are paid.  Openness has always been key to the Web, and it should remain so.  With luck, we’ll see legal threats dissolve and hardware acceleration come onto the market, as we’re already starting to see, and the barrier to entry will be lowered.

I’m not sure what Google intended, but in the few hours that the article has been available there have been more than 400 comments, nearly all of them negative.  It seems that the only people happy about the decision are those that are on Mozilla’s or Opera’s payroll.  It’s pretty clear that, considering the timing–the same day as Verizon’s announcement that they’re getting the iPhone–doing this now is a power play for Google as it faces increased competition against Android in the market.  Its a bit of corporate positioning to promote its Android platform and its own codec by removing support for the competing market de-facto standard, all under the guise of openness.  All in all, a very Microsoft-like move… especially considering the hypocrisy that they’ll continue to bundle Adobe’s Flash (a sluggish, proprietary symbol of the ‘old web’ if ever there was one) with the Chrome browser.  The most humorous of the comments are those users declaring that they’re not going to use Chrome any  longer and are moving back to Firefox (who never supported H.264 anyway).

To be fair, Apple did this as well by not allowing Flash on iOS devices, and took a lot of criticism for it.  Eventually it became clear that it was the right move because it helped to push the Web forward and away from proprietary codecs.  This may turn out to have the same result on the part of Google.  For web developers and consumers, however, to make this move right now is a major frustration.  Before the industry ships support for a WebM, it needs to better better hardware support, tooling support, and be a clear market winner.  From my perspective, a web developer responsible for shipping video to paying customers, it means encoding and storing my videos twice: once in H.264 for the majority of browsers which support it and Adobe Flash for legacy browser support, and also in WebM for those that support that format.  For  users, it means compatibility problems.  Users want a browser that just works, and this move puts Chrome in the Firefox box by removing support for something that a majority of the web is built on.

My personal take when Mozilla decided on Theora/WebM exclusivity now applies to Google: political grandstanding a video codec is a terrible overstepping of authority.  For content producers, there’s a certain cost for the tools to encode the video; for browser makers, there’s a certain cost to license the codec to decode the video.  For users of the browser, viewing H.264 video has always been free.  They don’t see any cost.  It’s presumptuous for Mozilla or any other browser maker to try to stick their heads into the affairs of  the professional or consumer video industry that they’re not really involved in and dictate that they use tools that don’t exist for them.  By not supporting H.264 with its undeniable market presence, they’re denying web developers and users the choice of what is better for them.  Denying choice runs contrary to virtually all in the open source/open standards community.  For all the denouncement Apple gets for the way it chooses technologies to include (or more controversially, exclude) in its products, providing exclusive support for an open codec at the expense of the already de facto industry standard is just as bad, if not worse.

Of course, YouTube could always be a wildcard.  It will be interesting to see if Google can find a way to satisfy its contractual obligations to offer H.264 video to mobile Internet devices and set top boxes and somehow go WebM exclusive.  I can’t see that happening, but I do wonder how far they’re going to take their power play?