Terminological proposals

[Peeter Tinits]

Just a place for terminological proposals up for discussion.

• Preferences -> Settings (depends on how the meaning of that word usually works, but it seems to me that preferences is usually non-essential). Currently the things you change under there however are essential.

[Andrjus Frantskjavitsius]

Use bullets if there are multiple changes.

[Andrjus Frantskjavitsius]

@peeter_t2, I think that Preferences is fine. My IDE and Firefox use Preferences. I also want to keep as much consistency as possible (I use Preferences internally).

[Peeter Tinits]

Well, that can very well be. This topic is more to create a place for these proposals. The meanings of these words however depends on how they are normally used in software programs, which is probably not consistent, but there may be some majority-minority rules. I don't know that really so these questions are best discussed publicly. Probably preferences is fine.

[Kristian K]

Does JavaFX have a way to let the users computer (i.e the window manager) to use it's own preferred, standard menu item labels? I know some widget toolkits do have that option, but I don't know if Java has it.

[Andrjus Frantskjavitsius]

@keeleleek, to my knowledge, JavaFX doesn’t offer standard menu item labels.

[Andrjus Frantskjavitsius]

Also, note that Preferences contains text processing, which is not essential. I assume the user will end up on that page quite often. I will probably add more non-essentials.

There is also the shortcut Ctrl + P which would be changed to Ctrl + S or Ctrl + C if configuration.

[Andrjus Frantskjavitsius]

I want to add all kind of different non-essential options to preferences. Lets keep it like this for now.

[Peeter Tinits]

It can stay like this why not. This suggestion was made particularly as part of a general topic for all terminological issues, so that they would have a future reference point. Why not keep this open for other users/designers to propose more terminological improvements, so that they could be dealt with at some point.

I would define essential as: "includes anything that is essential", whether or not it includes non-essential things too wouldn't matter for me. The point is that you absolutely must look there before doing anything else. But like I said, I think the terminology is a matter of practice and habits of use, and I can only really say about my own intuitions. Keeping it open would allow the best solution to be chosen in the long run. But by all means keep it as it is for now, as it is not an very important topic at this point.

[Andrjus Frantskjavitsius]

@peeter_t2, as I said in the previous reply, just make a new issue for every proposal.

I prefer issues for what I can sit down, do some modifications and then resolve.

[Peeter Tinits]

Ok, Andrjus, where should we place the design process then, as previous times have shown gmail list does not work at all, because rarely will we all have the time to read all the emails at the same time. However, there are and will be issues that may or may not be solved or improved on at future times, when we agree on them. "Issues" would assume that we are already agreed upon them. This is not always the case.

Can this bitbucket location not be multifunctional?

[Andrjus Frantskjavitsius]

I think we are starting to talk past each other a little. So here is a quick example of what I mean.

Lets say you are annoyed by how the articles can be added. It's tedious. You are not sure what is the best way to make it better, but have some ideas.

Here is how I imagine the workflow (from start to end):

• You create a issue "Improve article adding"
• Mark it as a proposal
• Add a description of the problem
• In the comments you propose your ideas
• We discuss it in the comment section
• Agreement is reached "add an option to not close the add article dialog"
• I change the proposal to enchantment and change the status to open
• A open issue sits there (with all the additional info in the comments) until I find time to work on it

This streamlines the process. @peeter_t2, what do you think?

[Peeter Tinits]

I don't know, I think there's bound to be lots of issues that you can't categorize straight away, and they may be perhaps picked up later. Discussion on usefulness and feasibility are not the same thing, such as this issue with preferences - but this is just an example.

I moved all I could find to a very dirty place here: http://translate.keeleleek.ee/wiki/Design_proposals, perhaps some day it will be made more pretty and useful.

I think the general aim of this development environment with such an explicitly open-minded software is to be careful not to lose any advice that is given by the users and the advisers. And gradually these can then be sought to be incorporated into the program in time as they become feasible, necessary or relevant again. Wiki seems like more open terrain, so the very open ideas are perhaps best to sandbox there. You'll be able to solve the issues here then.

I don't have experience making software, but for this particular item I think that it is important to provide as easy access to any potential user's ideas as possible. It's fine for now, let's see what happens in the future.

Your solution might be solid, I have no idea. The crucial thing I think still is to not to lose any even potentially useful information, that could be picked up in the future.

[Peeter Tinits]

Sum: I've moved the stuff so you can clear out the issues as you had before. These design issues can be thought about in the vague future.

[Andrjus Frantskjavitsius]

Ok, fair enough. Just make sure to make an issue when something is decided (if I forget to do that).

Its impossible to tell how workflow will go until we seen it in action.

[Peeter Tinits]

Yes, will do. Something to look forward to then! Can't promise I'll be very active except for very sporadically though. Good luck with the continuing work!