Are there examples of using the Host and Port setting in the Preferences for Database Location?
As an experienced Gramps user, I generally ignore those preferences and merely change the Database path field if the default path is not appropriate.
But there are no hints (or default with dimmed & italic text) in these fields to indicate that they are left blank normally. The rollover hint (tooltip) of “Any changes are saved immediately” is not enlightening.
Adding to the counterintuitive confusion, it is definitely important to fill in the blank “Backup path” and “Base Media path” fields in the Family Tree tab of Preferences… So new users are likely to assume ALL blank fields need customization.
Maybe there should be “leave blank unless using network/remote storage” default text.
So if a user incorrectly assumes that they need to fill in these blanks for a local installation, is it likely that they will see something like a Login dialog?
Agree with you - it is a minor annoyance. The mouse pointer has to be placed just right when editing settings so that this tooltip doesn’t cover the fields that I’m really interested in! From a discoverability point of view, there’s no save button so users would understand the auto-save concept anyway and reminders are not needed constantly.
When I attended university, to become an electronic engineer, I also had to attend some courses in social sciences, where I chose psychology and ergonomics, among others. And I think that those are things that developers often forget.
I mention these things, because a lot of problems seem to be triggered by users making choices that are not the best in their situation, and they’re making them partly because as developers, we like to have a lot of choices, and we give them too. And when users have them, they may choose the one that sounds the most familiar, or the most advanced, with dire consequences.
This is why I send a question back, when someone asks one, or writes about a problem. And that question is: What did you do? And that actually means: How did you get there?
And part of the answer is this tab, which is even worse than it is in 5.1.
Enno, I agree with you 100%. In my early days I had to test a software application as the customer representative. I knew that it would do what the spec called for so I did everything that it shouldn’t allow. I would just enter garbage in and do everything that it should not allow. I usually had bets with the coders on how long it would take me to break it. I won most of the time. Later in my career I got to spec out interfaces for client input, and even thou we put a lot of hard work into the design, it usually was not good enough until the 3rd version. GRAMPS is so feature rich that know one knows how it all works.
With GRAMPS, I think it is at a stage now that “tweaking” should be put on hold for a while and the inherent faults should be addressed. This is one example. Brand new out of the box should have a default configuration based on the OS. All the user needs to do is say Ok.
We see also complaints of speed, this should be fixing in 6.0. The 5.* versions should only address bug fixes. I don’t see any features the majority of users need. It needs to be made into a “stable” application. Look how many are staying with 5.1.6 because they are unsure about 5.2.2. Sad.
Sorry to hijack this thread again! I discovered that there’s a preference to turn this behavior off (yea!). The tooltip says changes are saved immediately as can be seen in the screenshot, but ironically they aren’t applied immediately…the setting takes effect when the dialog is re-invoked.
Hehe, yes, I recognize that. I have always done coding and a bit of testing, and I like coding much better. But when I tested, I loved breaking things, and for some odd reason, some fellow coders didn’t like that attitude. And I think that it is quite an essential skill.
So we don’t slide off track into the philosophy of numbering…
Gramps adopted a (Major.Minor.Patch) Semantic versioning, not a change significance versioning system for its releases.
And the pre-release systems use a build versioning and with alpha/beta/release-candidate test phases markers. (I don’t know how to identify the GitHub change management versioning.)
So you seem to be saying that the project has been trying to hit more major and minor release targets but needs to spend more energy on patch targets?
In maintenance releases (5.2.x) we only accept bug fixes. Anyone can submit a pull request with a bug fix.
Feature releases (5.x.0) contain new features. Changes should be discussed on the gramps-devel mailing list. Major changes will be added to the roadmap for the release.
For changes that break the API, we will increase the major version number to 6.0.0.
I am not a fan of the current Preferences layout or defaults either.
It needs a “going over” by some UX and UI designers. But we have to attract those kinds of personality types rather than try to shoehorn developers into doing things where they are not inclined, gifted or experienced.
I have put forward the idea before but here I will do it one last time
I think to encourage more users we should have
“GRAMPS Basic” or “GRAMPS for Dummies” no insult intended.
For example with plugins some are stored in usr/lib…/plugins and some
in .gramps/gramps51/plugins why?
Some are “built in” some are not I would argue that none should be built
in but a few basic ones would be installed by default and could be
uninstalled easily and completely. The first look at the Plugin Manager
is enough to send anyone looking for another way.
For example under Reports/Text Reports there are currently 28 reports in
my drop down list I use or have used 5 of these my next project is to go
through them all and then remove all the ones I do not want but I
believe this is the wrong way round.
Start with a minimum and as experience or requirement grows bring on
board the extras. Making sure “GRAMPS” basic is stable. Anything else is
at the users own risk.
phil
The updated preferences dialog was open for discussion in feature request #12049 and pull request #1149. Unfortunately we didn’t get any feedback.
I requested some minor changes where the dialog failed to conform to our UI style guide and in particular the Gnome Human Interface Guidelines, but apart from that, I saw no good reasons to reject the PR.
Input from a UX designer would be greatly appreciated.
It seems unlikely that the appropriate UX feedback will be generated from a MantisBT, Dev maillist, or GitHub thread.
Visitors of the Forums (the official Discourse, 3 Facebook groups, Google group, Reddit, Geneanet, Genealogy.net) are representative of the target audience. They aren’t likely to monitor the technical forum nor be comfortable with patching their installations to do ‘use’ testing. So they’ll need screen captures to visualize.
Maybe we need a thread (PM or Feedback subcategory) that involves Moderators of those forums. Where a project leaders can note a Developer thread where a UX proposal needs feedback. The moderators could compose content (collaboratively using the Discourse ‘make wiki’ feature) and cross-post to their communities.
Links to the resulting cross-post threads could be a response in the Developer thread.
Or here, for that matter, for the simple reason that, as an experienced user, I don’t really care about that dialog. And as you already know, I don’t care about 5.2 either, because it doesn’t give me anything that I need, and only brings more work.
And although I understand the idea of a UX designer, that is a fantasy too, and I never liked that kind of specialization/segmentation in my job. I find it very boring, and in my last job, I often walked to the UX team for a nice discussion, both to educate them and myself. And in practice, I was the person who was in touch with users in the field, not they.
In many cases, common sense is more than enough, and I hope that most of us have that.
Yes. When I review a pull request I have to take a balanced view. In this case I thought that it made an overall improvement to the preferences dialog.
If I thought that the PR was a bad idea, I would have rejected it. Although I approve most contributions, there are some that I reject even if it makes me unpopular.
Designing a good user interface is difficult, and I appreciate that when I review code. I think that @DaveSch did a good job, but that doesn’t mean that we can’t improve things further.
And I understand that, and appreciate your work, and the idea that our resources are limited.
I also believe that we do a lot of things better than the authors of Ancestral Quest and Legacy, and some Dutch programs too, that become more complex every year, and have a sort of 90’s look, which is the Windows 3 era.
IMO, it helps a lot if we can push (nudge) users to make the ‘right’ choices, which can be done with subtle changes. And I also think that Phil’s idea of a Gramps for Dummies is a good one, if we can give that a prominent place on our site.
As a software engineer, and amateur psychologist, I know that most people don’t read long texts, and follow their instincts, whatever those may be. And that makes me ignore the wiki, most of the time, and stick to the readme, when I want to try (to build) a new Gramps.
Back in the day, it was said if you could open an app and use it without reading the “how to” then it was well designed. I tried that with GAMPS and it didn’t work for me. However (in my case) I thought I knew enough about genealogy that I could make it work. Wrong! We have also heard of people giving up on GRAMPS because it was too complex. Likely they were correct because they also did not understand the complexities of genealogy. So maybe a GRAMPS for Dummies is needed. Something to get the novice started. That also applies to installation on their platform of choice.
Put together an outline for a digestible tutorial a couple years ago. But after starting writing, it became apparent that there were too many ways to start a tree with too many rabbit holes.
And the approaches were so dissimilar that writing a quick guide became more and more unlikely. (From a source, start with addings persons then stitching together relationships, starting with a family and add persons, importing from GEDCOM/vCard/CSV, building from a Chart, starting with a family gather photo, use forms, use data entry Gramplets … it is endless.)
On principle, I will never, ever have any involvement with a “for Dummies” book… either as a reader or when writing. The idea of calling any member of your community a ‘dummy’ or being okay with them considering themselves that way is offensive.
But the starting point (creating a Family Tree, loading it, and adding a Home Person’s with parents) was the big stumbling block. If new users make it past that point, They are not any of the people posting 1 star reviews. The 2 star reviews usually complain about not being about to add immediate family: spouses, children, sibs.
So those “1 star review” barriers-to-entry lent themselves to being targets for a minimal effort improvement in the “What’s Next?” gramplet. The completely missing messages for the novice stage:
You could put Host and Port into their own edit window that could only be activated when the appropriate Backend is selected. The edit window would be called similar to the window called to create custom Place or Display Names is activated.
OK, for user complaint about the login, they had to have selected an advanced backend before the Host and Port fields become relevant. They are not even active for SQLite. (Although the field labels are not dimmed.)
I suppose it would be more intuitive if the “Database path:” field moved to the top and the Host & Port titles were dimmed. (And there was a dimmed “not applicable” placeholder.)
with you - it is a minor annoyance. The mouse pointer has to be placed just right when editing settings so that this tooltip doesn’t cover the fields that I’m really interested in! From a discoverability point of view, there’s no save button so users would understand the auto-save concept anyway and reminders are not needed constantly.
