Re: [Gramps-devel] Possible enhancements to selectors

[Doug B. <dou...@gm...>]

On Sun, May 5, 2013 at 10:06 AM, Nick Hall <nic...@ho...> wrote:
> Following on from a thread on the gramps-users list, I have been
> considering possible enhancements to the Gramps selectors.
>
> My primary motivation would be to improve the user interface, but I also
> suggested we may be able to improve performance for large databases.

Nick, this sounds useful. It also sounds like some issues that we have
wrestled with on the gramps-connect project. You might want to take a
look at the interface to see if there are ideas that are useful in
gramps-gtk, or if you have suggestions for gramps-connect.

You can login at http://gramps-connect.org/ with id: admin, password: gramps.

On each main view (eg, http://gramps-connect.org/person/) there is a
freestyle search box, and a number of objects that are shown by
default. It happens that the number of objects shown per page (50) may
be bigger or smaller than your screen can display, and so there may be
a scrollbar. (I don't know if it is possible in JavaScript to query
the screen to see how big it is and make the number exactly equal the
available space, but that would probably be ideal).

> I suggest 3 possible improvements:
>
> 1. Before populating the list, select a filter from a combo box to
> narrow the objects to be displayed.

If you have to filter the data, you are still traversing it which may
take a while, right?

> a. Person selector
>
> At the moment a two-level tree of names grouped by surnames is presented
> to the user.  This list can be large, but is sometimes filtered.  There
> is no search bar.
>
> We could add a combo to select a surname.  Selecting a surname would
> populate the flat list with all names with this surname.
>
> This might be easier to use than the existing functionality.  It could
> be annoying if the original list is already heaving filtered though.
>
> Using a surname index on the person table would obviously increase
> performance.

Currently in gramps-gtk, the surname index only indexes one name (the
formatted name). In gramps-connect, you see all possible names, so
possibly multiple names per person (eg, the Person View is really a
Name View).

BTW, in gramps-connect, the search box has something like "named
parameters" so entering "Smith" in the search box is the same as
entering "surname=Smith".

> b. Source or Citation selector
>
> At the moment we use a two-level tree of source/citation.
>
> We could use a combo to select a source, and then populate a flat list
> of citations.  I would also suggest removing the search bar.
>
> Would this be easier to use?  It would certainly improve performance
> when the source/citation list is large.

Not sure.

> 2. Change the order of the columns
>
> This is a trivial change to make.  I like having the column I filter on
> most to be the default.

Yes, that would be useful. Good idea in both UI.

> a. Event selector
>
> Move main participants and event type to the start.
>
> b. Family selector
>
> Move Gramps ID to the end.
>
> 3. Provide an "Add new object" button
>
> When adding a new event, I always use the place selector to check that
> the place doesn't already exist.  If it doesn't, I cancel the selector
> and than add a new one.  Would an "Add new place" button in the selector
> be a good idea?

Gramps-connect has that on every view (the plus at the bottom).

> General comments:
>
> The selector code uses the models and search bar from the list views.
> Suggestion (1) will need some thought.
>
> We could improve performance for large databases on all selectors by not
> displaying the list until the users applies a filter.  In some
> selectors, such as event, the user will probably always want the filter
> the list.  In others, such as repository, the full list is probably usable.
>
> What are your thoughts on this?

It seems that you could just display the first N objects. But SQL
(gramps-connect) has the ability to select the N objects at an offset
in O(1) time. In gramps-gtk that would still take O(N) I guess.

-Doug

> Regards,
>
>
> Nick.
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> Gramps-devel mailing list
> Gra...@li...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel