To the left of the separator all that isn’t context specific.
These icons will be static (and therefore always displayed in the same place, in the same order).
To the right of the separator everything that is context specific.
The “Config active view icon” will always be displayed first and the following ones will depend on the context used.
The advantage being that the position of the “Config active view icon” will not vary depending on the context.
I think this makes less toolbar movement when navigating through the interface.
It should also simplify the choice of the added icon positions for addons developers.
I don’t like that.
For me the navigation should be the first then “+” and “-” I never use what you place at the beginning, so it should be the last as it is now.
If you modify this, all views will have this.
One of the challenges when making any modification is limiting the disruption to a user’s environment and work flow.
I added these icons for myself and even after doing so, I found myself still going to the menu, by habit, to open Preferences.
If you shift all the icons, that is a major disruption and I am sure users would hate the change and curse the person who ruined their experience. Adding the icons to the end does not disrupt any other icon.
But having set the icons in your own hack, you can have this icon configuration.
If I understand you correctly, everything to the left of the separator goes to the right?
Even “Manage databases” and “Open recent databases”?
And the navigation block is at the far left of the toolbar followed by the +“edit”- block ?
It’s obviously not in the spirit in which I rearranged this but I’ll test your proposal a few days to see what comes out of it in use.
The arrangement presented here is the one I would have liked to have seen when I discovered Gramps and would have helped me understand how it works faster.
Especially the separation of what is contextual or not.
After having insisted a little bit to understand, is still the fact that I don’t like to see all these icon movements in the toolbar when you switch from one category to another.
It made me feel a bit like rolling dice in a yams game.
And the mice travel seems shorter to me if contextuals stuffs are on the right but as I said I will experiment your use.
Otherwize one thing I don’t understand in this part of the grampsui.py code concerning the toolbar is the use of accelerators: all buttons have an icon.
I think the “use-underline” properties could be removed (they are False by default) as well as the underscore in “label” properties’s names.
Speaking of accelerators, that’s out of topic, but I think there’s a problem with duplicates in the menu bar.
Maybe it’s due to the translation of the strings but :
if I do Alt, I get this:
if I do Alt+A, I get this (I think I’ll get the other if my mice was over before but we can’t do an Alt+A+A to navigate):
This could be said for any modification made in the interface (reorganizing a menu, the position of items in the menu bar, adding dialog boxes, etc …).
I also think that a user who is a bit used to Gramps can get used to this kind of changes quite quickly (of course some reflexes will persist at the very beginning).
And some of them are able to make changes of the kind that are made here to meet their expectations.
The ideal would be to have a configurable toolbar but that would be too much time wasted in development and I’m not sure that an addon could offer it.
Modifications of the interface based on a simple reorganization of what already exists are quite simple to make and don’t consume much time.
A higher priority should be given to new users concerning interface IMHO.
this is why i generally think that layouts should be customizable by the owner/user to the extent that is practical for the app. that would mean development of a UI to do this with. that is likely something to push into the future and maybe someone will volunteer to do it. but at the very least, current development should be considerate of being able to add that in the future … don’t design in a way to lock it out.
When it comes to GUI stuff, I think people should think about what is best for new users to understand/learn, and not what experienced users are used to using.
At least if you want as much new users to use Gramps as possible.
More users = more likely that there come ideas for improvements to Gramps and people that is willing to help with programming things for Gramps.
It depends where you make the modifications.
For the preference window, I don’t mind because we open the preferences once a monce or less.
The problem is the toollbar we use several times per minute.
I use them for 15 years now and I don’t want they change.
When you buy a software, new users needs to use what the have and they have no choice.
I only need you leave the toolbar like it is. For me, the order is correct. If you don’t like it, you always have the possibility to remove it.
The order must stay:
1 - The database selector
2 - The navigation ( “<” and “>”)
3 - The itemsedition ( “+”, “-”, edit, merge and tags)
4 - The view options
5 -The possible views depending on the category
6 - after that, the clipboard, reports, …
If you don’t like it, you can hide the toolbar. In all cases whatever the modifications you make, you will always see these movements
It’s effectively a translator problem. He must know all the accelerators and it’s a difficult work.
Don’t do that.
It only means you don’t use mnemonics (accelerators) in the title.
As you can see:
The Windows world is a Microsoft world vision
The macOS world is an Apple world vision
The linux worls is a free world vision.
Those three worls are incompatible.
If you don’t like how gramps works, you can always buy a proprietary software for your favorite operating system, for which you will have only the right to use it. You will need to use their way of seeing things as they decided
The needs of New Users should be considered but must not be the absolute gauge. The vast majority are experienced users and the project dies if we become a newbie tool that become increasingly clumsy as your research matures.
And while fresh user population includes a small a percentage that will become contributors, the greater majority will be dead weight. (It is not a complaint. Merely reality.) And only a small percentage will contribute from the beginning.
We don’t have the capacity to handle a flood of non-contributors.
My feeling is that making Gramps easier for Developers to become productive is a better return on investment.
New Developers who are also New Users will have a keener interest in improving the New User experience.
Something that is easier for new users than it is not do not have to be more clumsy always. It does have to make some things somewhat different tho. Just switiching the order of buttons dont make it more clumsy for example. (as long as you dont like have no logic behind it or its different from page to page or whatever). Ofc you have to think about not making it clumsy at the same time.
Majority of Gramps users now is also “dead weight” most likely.
I bet someone using Gramps for a many years do not make them that much more likely to contribute, at least if you dont count those that havent really learnt Gramps yet.
That too, I personally thing both these things are more important than strictly adding compleatly features for example. Tho compleatly new features might be more fun for a developer…
Yes, you get less of those with less new users, I bet. (Not saying I am correct, its just my guess)
Programs like Gramp have a benefit if there is new users that also is developers that contribute.
My main point is really that if its only the same eyes that have lots of experience with a program are the only one that decide where a program is going only, its probably not going to improve as much as it could have done. Not saying this is true with Gramps, I havent seen enough yet to make that call or not.
Maybe I wrote what I mean in a way that made it seem too one sided.
People shouldn’t assume that I am ‘anti-new user’ in any way.
Most of my enhancement requests & bug reports are directly traceable to interacting with new users… testing workflows before posting replies, discovering bugs in the process.
I also try to explore things that reduce drag of our ‘dead weight’ but help streamline workflow for advanced users too.
Because the percentage of people contributing as not grown at ANYWHERE NEAR the user base growth, we need to continually encourage people to contribute to the best of their ability. Otherwise, the project will collapse under the weight of its own success.
As an example… look at the volume of bugs reported and resolved.
That was my start too. And, since I am cash poor and unable to contribute to overhead costs, I started by looking for Wiki sections related to new user questions… and tried to quickly post a link with the official answer.
Once the more advanced users realized the burden of easy questions had been offloaded, they could focus on more complex stuff. Or they could expand on what the wiki did NOT say.
The searching helped me become more familiar with a broader variety of features. And I started inserting those nuggets of knowledge to improve the wiki. …And then started consolidating information info that was there but widely scattered.
That lead to creating absent content. Occasionally, I was even able to include a leg up to a solution in a Feature Request or Bug Report.
Even if you have no Gramps skills at all, the wiki needs a lot of grammar improvement. Anyone can help there.
And anyone can help by verifying really old outstanding bugs are still reproducible. (If a new user can’t reproduce a problem from the Report, a Developer shouldn’t spend their valuable time on it. But you can add a note requesting a clarification. That will go to the original Bug poster.)
I dont think I will spend time on reading things on the wiki or whatever spesifically to see any improvements but might try to do if I stumbe over it, if I remember.
That’s a problem many sucessful open-source projects have, especially because all ideas and suggestions are welcomed and kept instead of filtered for the most important ones and the rest being closed.
An idea about that: old bugs could be posted here (automatically posted?), i.e once a week, to ask users to test if they are always current and post tagged as Solution returned back to the bug tracker, like as we receive email from discourse when we post something on it.
