Did you try to to contribute on the wiki but give up?

Feedback
1

A “Welcome Survey” for new WikiContributors is now being added to the user pages created for new accounts to edit the wiki.

But after more than 60 new users, we’ve still not gotten any response. Maybe the ‘welcome’ message is written poorly… or maybe it too effectively informed the new account holders that they hadn’t needed that account.

Did you sign up for an account so that you could contribute to improving the wiki but then were frustrated in that intent?

If so, we NEED your feedback. Please comment on the survey’s Discussion/Talk page… or here, if you found editing a MediaWiki page impossible.

2

I’m curious how many of the sixty new wiki account creators contributed to the wiki? If they did, that’s success!

3

Five contributed edits to the wiki. One of those 5 replied to the welcome survey that they’d Post to the forums if they needed help.

4

Interesting that 55 out of 60 people saw something that could be improved in the wiki that motivated them enough to create an account, but did not follow through.

What about sending new account holders an email a few days after their account is activated, reminding them they saw something that they cared enough to want to edit, and invite them to do so? Is it possible to include a link to the last page they might have visited before requesting access?

5

My suspicion is that they thought they needed the account for another purpose. The Gramps project has separate user accounts for: the MediaWiki, WordPress, MantisBT, GitHub, Discourse, Weblate, maillists (developer, user, bug, announcements) and several unofficial channels.

Beyond that, new visitors might erroneously think they need an account to download/validate Gramps itself. Or to use the add-ons management… like when using an App Store.

And, even if they ACTUALLY desired to edit the wiki, we don’t know if we lose them because they find MediaWiki editing unintuitive, or because they discover the article collection overwhelming, or because starting a new article is too difficult.

As for a follow-up eMail, I don’t believe the wiki has a feature to reference where a visitor was browsing when they chose to create an account. (Thankfully… because that sounds too much like ‘Big Brother’ monitoring.) And sending unsolicited eMails should be considered carefully. That might be a bad path to fall into.

6

On 10/22/2021 4:21 AM, Brian McCullough via The Gramps Project (Discourse Forum & Mailing List) wrote:

My suspicion is that they thought they needed the account for another purpose. […]
Beyond that, new visitors might erroneously think they need an account to download/validate Gramps itself.

I see, so if the suspicion is that MediaWiki contributor accounts are being created when they aren’t really needed, let’s think about how that may be avoided. How about something along these lines on the account creation page:

Hey! We’re glad you’ve come here to create a MediaWiki account! With this account, you’ll be able to contribute to the Gramps community by editing wiki documentation. (and go on to list anything else that can be done with the account).

You won’t need to create this MediaWiki account if you simply want to read the documentation, or download Gramps, report a bug, (…etc… hyperlink each item so user can find what they need).

Shall we proceed with creating your account?

Something like this would make a reader pause and think about what their intent is, and potentially reduce account creation when it’s not really needed. What do you think?

–
Himanshu

1 Like
7

Lots of wiki sites have a problem with spam. How do we know that these are ‘real’ users v. attempted spammers?

Craig

8

The sad fact is that we know very little at all.

Even if there is only 1 hero out there who is actually interested in contributing, has experience we lack but just needs encouragement, then the community is missing out.

We need all sorts of skills with the wiki. Not just authors, we need people to help organize more than a decade of accumulated clutter. And there are a bunch of broken bit of the MediaWiki framework that need a bit of love.

Statistics

Page statistics
Content pages 2,044
Pages
(All pages in the wiki, including talk pages, redirects, etc.) 13,997
Uploaded files 4,244
Edit statistics
Page edits since Gramps was set up 86,488
Average edits per page 6.18
User statistics
Registered users 5,727
Active users (list of members)
(Users who have performed an action in the last 30 days) 5
Bots (list of members) 0
Administrators (list of members) 18
Bureaucrats (list of members) 11

9

In looking at the “Version” MediaWiki special page, it appears the the Gramps-Project is using the ConfirmAccount extension to communicate with New account applicants. (Which explains why I was unsuccessful in locating documentation for the welcome message in the main reference. The documentation would’ve been in the add-on section.)

We probably need to review and revise the “user experience”.

10

Being a long time Gramps user but never having considered contributing to the Gramps Wiki, perhaps I can share my view in this context. I think the Gramps Wiki is very impressive, with lots of detailed documentation and even translated into many languages. I appreciate the time and effort so many in the community have invested in it. Still, I’ve never really gotten to grips with it, and I suspect there are other users who feel similar.

In my opinion, the Gramps Wiki tries to be too much at the same time, and this makes id unwieldy.

It is, at least:

  • A multilingual user manual for the current version
  • A history of user manuals for all previous versions
  • A developer documentation site
  • A repository of enhancement proposals (many of which outdated)
  • A collection of tutorials
  • A collection of general genalogy hints

Again, this is not to dismiss anybody’s efforts and I am aware there are many nice “overview” and “portal” pages that can help navigating this forest, but very often when I google something or use the search function in the Wiki, I am unsure in which part of the above bullet list I’ve landed.

For me, the download page is a good example of this, if you compare it to this, for instance. It’s a mixture between download page, tutorial, change log, …

I once read a review of Gramps in the journal of the German Association for Computer Genealogy and as one of the weak points it mentioned that it’s “hard to install”. Which we know isn’t true at all, but I think many users are scared by the - in parts too detailed - documentation.

What I would find more user friendly would be to have, clearly separated:

  • A multilingual documentation site for the current version. (The archive of previous versions can still be made accessible, but more hidden then they are at present.) This is basically the “Gramps Wiki Manual” section of the current Wiki. But I’d like to be able to search it without results from the other tutorial/developer/… sections showing up.
  • A developer documentation site. Only for developers/contributors. No need to be multilingual.
  • Everything else (tutorials, general advice, …) belongs either to Discourse or to a separate Wiki (not mixed with the documentation).

There are fantastic open source tools like Docusaurus that might make for a more accessible/clean/user friendly alternative to documentation than a Wiki (see the Home Assistant Dev Docs as an example I like).

Again, please don’t take this as criticism of people’s efforts on documenting Gramps, which are all in all very impressive.

Sorry if I hijacked this thread!

4 Likes
11

Some very good points.

And those of use who’ve been whittling away at the wiki (for years) are all too familiar with such faults. I suffer a sick feeling every time I consider that “Pages (All pages in the wiki, including talk pages, redirects, etc.) 13,997” statistic. That stretches back 14 years to Feb 2007 when MediaWiki was first installed. And I’ve only read a fraction of these so far.

We been tweaking the download page but it is still too intimidating. Maybe a radical redesign (like that Visual Studio download page) is needed with drill-down to the detail. Matt’s Gramps Add-on webpage is a radical departure too.

It hasn’t been that long since Gramps WAS complicated to install. So we’re probably second-guessing ourselves about how much detail is appropriate. (Although some add-ons with dependencies are still only accessible to the tech savvy.)

Although the idea of separating is attractive, we’d have a major technical challenge… the stuff hotlinked from within Gramps application is anchored to far, far too many spots in the wiki. (Multiplied by the translation anchors.) These immutable anchors make a major redesign problematical.

Despite the pain, a redesign still needs to happen at some point.

12

I agree, things should be seperated.

The download page for example, just some things: (I dont have an user on the wiki and dont know how to edit)

  • The Missing language thing under windows should really be just maybe one link to another page that explains it.

  • Is it really any point saying the portable one isnt for touch screen devices? is that a thing that muliple people have thought it was? Other places that have a portible version havent had to specify that, my guess is that Gramps wiki dont really have to either?

  • There is 3 links going to exact same site in there for the portable version? Maybe reduce?

  • The sentance with the portable version it having all dependancies reqired for windows, should be combined, or moved to the same place it mentions it can run from an external device or USB drives.

I dont have a comment about the Linux and MacOS one spesifically, but Linux one takes a lot of space, at least good that its at the bottom.

13

Or I mean, Remove this:

A PortableApps version will run from an external device without the requirement of installing on the OS drive. PortableApps installations are not for touchscreen-based mobile devices. They just allow the application to run from external storage, USB thumbdrives.

And

Portable Gramps from PortableApps.com includes all dependencies required for Windows.

And switch it out with something like:

A PortableApps version will run from an external drive/USB thumbdrives, without the requirement of installing it on the OS drive. It has everything required for windows to run it.

Where the first one of them is placed.
Just a example of what I would change there, feel free to not do exactly that, others might disagree.

14

Yes, we had to repeatedly clarify that Gramps Portable is for Windows, not Mobile devices. Lots of Android and iOS users (tablet & smartphone) are asking about for Gramps.

(Note that’s there is a NOT-free crappy genealogy tool in the Apple Store under the name Gramps. It apparently doesn’t work but they don’t give refunds. Apple doesn’t respond to request to ban it from their store.)

15

Very weird, its very clear to me its not…
Either way, what I said would be better if you still keep that sentance.

16

If there is a - more or less - strong coupling between the application and its documentation, perhaps you should consider integrating it into the Gramps (app/data?) model, so that the architects and developers of the application can imagine how to make this coupling looser so that things can change on one side independently of the other.

Typically the kind of decoupling that could be interesting. Whenever I quote a Gramps addon, I now give its link on this page. It’s up to it to provide the correct link to the wiki. If it included a resolver (a sort of bit.ly type redirect link) I would use it directly avoiding a hop through this page to my reader.

Using it in Gramps would allow to be able to change the wiki to something else as suggested by @DavidMStraub (I really like its suggestions) without changing the links in the app

17

Quote from that webpage about Domain Driven Design [fr]: “Complexity is like cholesterol. Above all, you have to get rid of the bad" (Gascon-Malagasy proverb) :grinning:

1 Like
18

This is a dangerous thought.

Created as a core,/built-in, th lead time for documentation, feedback loop & translation latency would collide disastrously with the Gramps release cycle. Progress would be tied up in recursive knots and slow to a complete halt.

And it would pull developers into intimate involvement with writing user documentation. Developers frequently often hate anything connected with the fussy wordsmithing needed for beginners or English-as-a-second-language users. (Much of that tweaking happens in the months AFTER the documentation goes public.) So that unwanted intimacy creates a negative incentive to create any new feature.

They only way it MIGHT work is if Gramps added a 'help_url" crosswalking lookup table plug-in … as an add-on not built-in/core. New crosswalks could be pushed via the Plugin Manager. Perhaps that could uncouple the documentation cycle from the code development cycle?

Such a lookup table could be used for localization too. And we could use it developmentally: to target consolidation of interchangeable help_url anchors.

Such a lookup table would be usable as a control file directing a data scraper add-on to cache Complete WikiPages and remap help_url requests to that cache. It could even give us some options to remap ‘help_url’ anchors to bookmarks in local PDF(s) exported from MediaWiki.

If someone wanted to write an aftermarket book on Gramps, a lookup table could give page references.

19

Good point, but the solution cannot be to never tackle the redesign. It shouldn’t bee too hard to set up a list of 301 redirects to a new documentation site. Even a generic page notifying users that the documentation has moved wouldn’t be a disaster IMO…

1 Like
20

The redirects wouldn’t too hard. But harvesting the targets from the source code isn’t even on anyone’s radar.