search

WeblateOrg / weblate

Web based localization tool with tight version control integration.
https://weblate.org/
GNU General Public License v3.0
4.61k stars 1.02k forks source link

Consistent navigation-menu options #9532

Open comradekingu opened 1 year ago

comradekingu commented 1 year ago

Describe the problem

The top menu items all focus-shift (in language view) because the second entry is "language".

Describe the solution you'd like

Add "Language" to this menu image

Describe alternatives you've considered

Also considered adding all the submenus to the top menu, but that is more of an involved approach.

Screenshots

This is what it usually looks like image (Språk (Language) goes missing.)

Additional context

"Administrate" and "Share" could be grayed out?

nijel commented 1 year ago

What should the “Language” tab contain when you are already at language level? There are different actions at each level and that's not going to change.

yilmazdurmaz commented 1 year ago

Hi @nijel, I am not sure what is the intention of the OP here, but I have a similar idea for that and I will drop it here. maybe we want the same thing.

While we are already in Language, having the list of "other" languages as well would prove beneficial to switch between languages without searching for the same component, especially when there are lots of components in the project.

For a multi-lingual translator, this would come pretty handy.

It is also a different way to browse a component: if I misclicked the wrong language, I could use that list to find my own as long as the component is what I want. (sometimes going forward in the app is faster than using browser's back button)

comradekingu commented 1 year ago

@nijel The problem occurs when I am in a specific language. When I am in https://hosted.weblate.org/projects/openrefine/#languages I can click nb_NO, but then I am in https://hosted.weblate.org/languages/nb_NO/openrefine/ and I can't click "Language" again.

If I was able to click "Language", I would expect it to go back to https://hosted.weblate.org/projects/openrefine/#languages

That means added functionality, and the first 6 entries in the menu are always in the same place. I see no downside to it.

yilmazdurmaz commented 1 year ago

Yep, we want very similar things here.

the "language" button in a project links to {host}/projects/{project_name}/#languages

If I am not missing something, just simply adding the same button when under {host}/languages/{lang_code}/{project_name} should do the job.

for me, it is the same button but for a component pages at {host}/projects/{project_name}/{component_name}/{lang_code} to have a link to {host}/projects/{project_name}/{component_name}/#translations

need I open a new issue, or is it ok to merge these two requests?

nijel commented 1 year ago

That means added functionality, and the first 6 entries in the menu are always in the same place.

These entries are always context-specific. This is not a place for navigation to other contexts.

I see no downside to it.

I do see downsides here.

If I am not missing something, just simply adding the same button when under {host}/languages/{lang_code}/{project_name} should do the job.

I've changed the breadcrumbs link to languages in bbfb24eae6 instead. This is where you should look for navigation to the upper level.

comradekingu commented 1 year ago

So, that makes clicking "OpenRefine" in image https://hosted.weblate.org/languages/nb_NO/openrefine/

different from doing it in image https://hosted.weblate.org/projects/openrefine/#languages …?

The underlying problem there is that it isn't possible to undo mid-level nesting from the breadcrumbs menu, which I think would only be possible if there was a button to close each one Project/components[x]/languages[x]/local language[x] and Project/+^/languages/local/language for example, to add the component.

(It already isn't possible to shorten the URL from https://hosted.weblate.org/projects/openrefine/database/nb_NO/ to https://hosted.weblate.org/projects/openrefine/nb_NO/ (because that is https://hosted.weblate.org/languages/nb_NO/openrefine/)

However, to get back to the main issue (which is now somewhat worse), I like buttons to always do the same thing, and are always be in the same place.

This allows quick navigation, as muscle memory kicks in more easily to click something when I know how far away it is.

Knowing it will be somewhere else in some menus is very hard to learn. (Similar to finding administration or plugins, which confuses some users.)

I go between local language in a component to all strings or a different component in a different language every day, and it is both hard to do and visually displeasing.

I am sure there is a reason to keep it tidy with a needs-must minimal approach, but here I think usability suffers for what is a very pure technical approach.

nijel commented 1 year ago

I like buttons to always do the same thing, and are always be in the same place.

Buttons will never be same at all levels. There is no point in attempting that. If you have already chosen language, why it should show Languages button?

yilmazdurmaz commented 1 year ago

If you have already chosen language, why it should show Languages button?

Multi-linguals maybe?! The current menu system seems to try breadcrumbs to switch depth in the project, but it is not as intuitive as you may think. the coloring and the size of it is not discriminative enough. Besides, we are used to clicking on bigger buttons with intuitive names.

Instead, having that "language" button on all levels would simply mean "the language list of this depth" or "back to language list of this".

comradekingu commented 1 year ago

I am not navigating based on where I am, but rather what I want to do. Therefore where I happen to be and the particulars of it aren't as interesting to me, just how easy it is to get stuff done. How things look and function is also important.

Going to another language to translate it (as mentioned) is one thing, but sometimes I only remember what language a comment is posted in and want to switch to that, for example.

I changed something in a source string, and I want to get to another language to fix all the broken checks, etc.

Or I just want to go to the source language to fix stuff after seeing that it makes more sense to do than submitting a translation beforehand.

Doesn't matter if I am in local language view, or browsing a component, all components, or a component with a selected language, but the logic differs between those.

In Project/languages I can switch back to "Components", bilde

but in Project/languages/selected language I can't bilde

In project/components I can navigate to "languages", bilde but in project/components/selected component I can't. bilde

(And why can't I administrate stuff the same as I would be able to in project/components or project/languages?)

If project/components "Language" is already selected, and there is no navigating back to "project/components".

That I can click "project" in the breadcrumbs to view components is not clear to me. I suppose it is better than having one button for "main components" and one for "language components".

However, if one menu works, I ideally want it to work all the time, and it could do all the things I want to do if just "language" and "components" is added in respective places.

In my main language "language" and "languages" is the same word, which I suppose doesn't help.

TL;DR The idea that there is some kind of hierarchy (that isn't obvious in the URL) is lost on me, I just want to get to where I want to be.

I would much prefer the non-available buttons to be grayed out, and clickable as often as possible, even if the view doesn't fit 100%. The focus-shifting of 1 2 3 4 5 6 7 vs 1 3 4 5 6 7 vs 2 3 4 5 6 7

in different views is grim.

It makes navigating the menus seem more like a forest than a flowchart with an overview.

nijel commented 1 year ago

And then you have other pages with a different set of buttons:

image

image

TL;DR The idea that there is some kind of hierarchy

Yes, it's project / component / translation hierarchy, with different actions being available in different scopes.

nijel commented 1 year ago

Oh, I see you've also created a pull requests https://github.com/WeblateOrg/weblate/pull/9561 https://github.com/WeblateOrg/weblate/pull/9560, even when I repeat here that it's not a good idea. Let me explain it again:

The UI is consistent right now, and what you are trying to introduce breaks that. To go level up, there already is the breadcrumbs line. It has the links you are trying to add. The tabs (or buttons, how you call it) are always actions on the current object. Introducing repeated navigation here makes it less consistent and consumes screen space (which is a scare resource on mobile devices).

yilmazdurmaz commented 1 year ago

To go level up, there already is the breadcrumbs line

Speaking for myself, I don't want to go "level up". I want to go back to the language list of the project/component with less effort.

consumes screen space (which is a scare resource on mobile devices).

with all those contents on screen (already-crowded), I am not sure this makes any difference, and also modern phones have wide enough screens (even my 7-year-old 5.5'' mid-range phone has FHD screen).

The tabs (or buttons, how you call it) are always actions on the current object.

I hope you did not hastily rejected my pull requests, because they were already doing that exact thing:

If another button breaks the page, you say, then why have these two links in the breadcrumbs list, for example at the end of it? This one is a better idea than the last change you accepted, as it affects all unsuspecting users now. "space, again" you say? then why not make it a recognizable icon.

I am sure, instead of rejecting, you can come up with a better placement/appearance for these two time-saving additions.

orangesunny commented 1 year ago

To go level up, there already is the breadcrumbs line

Speaking for myself, I don't want to go "level up". I want to go back to the language list of the project/component with less effort.

There are solutions for all these situations:

consumes screen space (which is a scare resource on mobile devices).

with all those contents on screen (already-crowded), I am not sure this makes any difference, and also modern phones have wide enough screens (even my 7-year-old 5.5'' mid-range phone has FHD screen).

Mobile screens are wide and large these days, but we are not going to fill them up with nonsense buttons. Moreover, some phones are not 9:16, but thinner and taller. The current Weblate UI layout has been tested widely, and we are not going to ruin it with a redundant tab.

The tabs (or buttons, how you call it) are always actions on the current object.

I hope you did not hastily rejected my pull requests, because they were already doing that exact thing:

* `{{ project.get_absolute_url }}#languages` for the "current" project

* `{{ object.component.get_absolute_url }}#translations` for the "current" component>

That rejection of PRs was not hasty. It was purely intentional after a proper discussion within the Weblate team.

If another button breaks the page, you say, then why have these two links in the breadcrumbs list, for example at the end of it? This one is a better idea than the last change you accepted, as it affects all unsuspecting users now. "space, again" you say? then why not make it a recognizable icon.

I am not getting to this whataboutism workout. If you feel that something in Weblate UI is redundant in the current state, feel free to suggest a removal.

I am sure, instead of rejecting, you can come up with a better placement/appearance for these two time-saving additions.

We are open to the suggestions, but this issue is time-consuming nonsense. Adding redundant UI elements is not viable. You can open a discussion about these ideas in the community and get back here if a better implementation comes up from there: Ideas discussions

yilmazdurmaz commented 1 year ago

We are open to the suggestions

I am not sure anymore.

comradekingu commented 1 year ago

The UI is consistent right now, and what you are trying to introduce breaks that.

What is it that breaks really? Form and function are IMO both improved. It seems you are trying to shoehorn a technical decision into usability because undoing even more of it makes it harder to think that way. Give the other way of thinking a spin.

The GUI is in the very least inconsistent, but the thinking behind it is consistent on an otherwise logical level. I would posit the interface is primarily graphical here, as that is how it is presented. One could say the statement holds from a user point of view, but that logic is hard to apply for users, seeing as it means learning something not from the GUI, but rather from its underlying logic. The resulting actual navigation is also different for each type of place. I think it is misleading to focus on what could be called an interface, when the interfacing the user does and is most likely to adopt to is graphical…

Level(s) up is solved by breadcrumbs Back is solved by the browser. There is a big button for back, as well as keyboard shortcut.

These two are dependent on state. Navigating freely is independent of state.

There is an inconsistency of function in how the menu works, and what parts of it are available. Going back implies linearity to begin with, when starting with opening for example a previously used URL skips that entirely. (This is the fastest way to reopen a project.)

Between (more) different tabs, (or given enough when many use-cases require more) it is impossible to remember what the depth is between them. One does not preclude the other btw. I would have the same option if the menus were better. Web browser navigation just does different things, similar to how the navigation now doesn't delineate all possible levels.

You can also get wild and duplicate tabs in your browser and go back and up the level respectively :)

The state isn't inherited, and the logic varies between web browsers. (Does "back" mean level, or the previous site when something happens in between? I haven't relied on it since Opera.)

The wild assumption isn't that there are multiple tabs open or available to open, but rather how it would solve the issues of navigation for how that works on a basic level.

For basic use, (and basic users) this remains important. Changing also how the breadcrumbs work between views isn't going in the right direction IMO.

The current Weblate UI layout has been tested widely, and we are not going to ruin it with a redundant tab.

At a wild guess, this functionality was never tested. Don't mistake use for compliance, this is a fallacy. It solidifies mistakes.

As a product of feedback from the people using it the most, the proposed change only replicates the amount of buttons available from the base level navigation. bilde (9 buttons at /project level, and when clicking each of them, which happily is consistent.) If there are too many buttons there I don't know what to tell you. If the main issue to solve is navigating from the instance level in a linear fashion, this is presented before the only-6-buttons-available menus.) If what you are arguing is usability from a space-concern, and that even some level of redundancy ruins the UI, maybe that factorises into dwindling places, and that the UI doesn't even functionally work from a usability point of view. The function proposed is not the redundancy, and it seems users really care for the usability directly.

(Compare how administration is really only available per component, but is now available in the base menu as a button, where it lets you select component, rather than the one-layer deep button that even admin users couldn't find.)

Moreover, some phones are not 9:16, but thinner and taller.

I have several of those. Fortunately the pixel density always allows for the resolution needed. We are down to visual acuity of size, for a non-typing device meant for video, for a UI that isn't exactly mobile first. One GUI without much dynamic change isn't going to cover all bases, but functionality for all users is fortunately more important always.

Designing for the edge-case of non-usability isn't good, and the above default holds. Whether vertical or horizontal on the handheld device, the width of buttons or vertical presentation wasn't ever part of the considered design constraints to begin with, and is in the very least far from ideal. https://github.com/WeblateOrg/weblate/issues/2767 gives some inspiration. Rather the consideration is usability of not what is strictly possible (or as the case may be not), but of how menus function.

It isn't possible to forego someone not thinking forwards, in using examples of the current to imply thinking was always what changed.

Project/languages/selected language doesn't allow going "level up" even if the hierarchy is project / component / translation, as there is never a possibility of getting to project/component/languages

The actual hierarchy is Project/component/translation just as much as it is Project/language/project/function bilde or OpenRefine/language/editor bilde

for the exact same thing, between editors. How the breadcrumbs are a usable and considered idea for a modular (non-hierarchical) tree is as clear to me as why internal discussions are "proper", or why unanswered questions are "nonsense". A thumbs down for my post doesn't tell me a whole lot of anything either.

Is Valka part of your internal discussions? I can tell how he thinks based on the things he makes, and I think you have something to gain.

Buttons will never be same at all levels. There is no point in attempting that. If you have already chosen language, why it should show Languages button?

At a fundamental level, this gives visual continuity.

TL;DR The point is to replicate what something does consistently, rather than what the intended logic is. People want to do stuff. The sanctity of puritanical simplicity gets in the way.

If there is one set of languages for the project, and one set of languages for each component, the button that selects each respectively is just sometimes there, and does different things. That is the worst of all worlds.

The hierarchy isn't present in the URLs, and the breadcrumbs are presented in different ways for different views, and also function differently.

orangesunny commented 1 year ago

TL;DR, @comradekingu. Definitely not now, I might get back to it some other day.

I understand that you want to show your opinion is truly right, but writing a paragraph instead of a point is not a way to be successful in Weblate repo, as well as many other repositories on GitHub, as you know. Please, earnestly, focus more on being kind and open to discussion than trying to bulletproof and cement your opinions in large paragraphs.

yilmazdurmaz commented 1 year ago

I had once reported a bug to vscode rep when I was baby steps with it. The bug was on a function almost any programmer is using: copy-paste names of files, but with the mouse. It was introduced somewhere 2 years prior (and many versions before)

Some guys closed the issue marking it as a duplicate, just because "he thinks" it is a duplicate. it was not. After I told him so and sometime later, he gave me some links. I checked them; one was close but not the same. I stated my reasons, yet, no matter what I say, the issue stayed closed, as with the living bug. It was apparent he took it personally that questioning this decision was questioning his authority. I had no choice but to learn to live with the bug.

1.5 years later, I checked again and saw that, a few months ago, someone had a fix on one of the linked issues. I commented on that commit, and the guy checked my bug report. Just a few weeks later, the bug was fixed. It took almost 4 years to fix a bug, with an extra 2 years just because a grumpy guy refused to acknowledge the problem and kept it away from real solvers.

In all your responses here, I feel the same scent. So, I will drop one last suggestion, and if you stay the same, I will wait until that grumpy (or grumpies) leaves Weblate (however long it takes).

The following code fragments have the language links to go back to the language list of the project/component from the breadcrumbs. They can be placed at the end, maybe in parentheses, and can be made as icons. But they do what we expect them to do: go back to the language list.

weblate/templates/language-project.html

It will show `project_name/Languages/lang_code` and is faster way to get to project language list. There can be an icon instead. (addition is at line 3) ```html {% block breadcrumbs %}

  • {{ project }}
  • {% trans "Languages" %}
  • {{ language }}
    • {% endblock %} ```

    weblate/templates/translation.html

    It will show `project_name/component_name/Languages/lang_code` and is faster way to get to component language list. There can be an icon instead. (addition at line 4) ```html {% block breadcrumbs %}

  • {{ object.component.project }}
    • {% include "snippets/component-breadcrumb.html" with object=object.component %}
  • {% trans "Languages" %}
    • {% include "snippets/translation-breadcrumb.html" %} {% endblock %} ```

    weblate/templates/translate.html

    It will show `project_name/component_name/Languages/lang_code/Translate` and is faster way to get back to component language list while translating a string. Again, there can be an icon instead. (addition is at line 6) ```html {% block breadcrumbs %}

  • {{ project }}
    • {% if object.component.slug != "-" %} {% include "snippets/component-breadcrumb.html" with object=object.component %} {% endif %}
  • {% trans "Languages" %}
    • {% include "snippets/translation-breadcrumb.html" %} {% if object.component.slug == "-" %}
  • {{ unit.translation.component.name }}
    • {% endif %}
  • {% trans "Translate" %}
    • {% endblock %} ```

    nijel commented 1 year ago

    weblate/templates/language-project.html

    I've changed the link to point to languages in https://github.com/WeblateOrg/weblate/commit/bbfb24eae68f4572a08553e31d23faa4724aa0cc 2 days ago (also mentioned in https://github.com/WeblateOrg/weblate/issues/9532#issuecomment-1631989719).

    weblate/templates/translate.html weblate/templates/translation.html

    {% include "snippets/component-breadcrumb.html" with object=object.component %} points to same page as <li><a href="{{ object.component.get_absolute_url }}#translations">{% trans "Languages" %}</a></li> you've added.

    Can you please clarify how having two neighboring links with the same target and different text improves things?

    yilmazdurmaz commented 1 year ago

    The change you made is not "intuitive". Clicking on the project name "should" take you to project page, not to its languages section. this is for those that I referred "unsuspecting" users. All my suggestions have this "exclusively" named link back to the languages section.

    comradekingu commented 1 year ago

    A further expectancy of what stuff looks like, functions as, and where it will be across menus would not go amiss.

    If a button does a thing, what does that button do if it is moved elsewhere? If a button has a place in menu 1, where is the most obvious place for it in menu 2? If the breadcrumb menu works one way in one editor, should it be different in editor 2? If a button is named "information" in one menu, should it be "info" in another? If the URLs look like https://hosted.weblate.org/languages/nb_NO/3d-slicer/ and understanding hierarchy is important, then why is it https://hosted.weblate.org/projects/3d-slicer/3d-slicer/nb_NO/#overview

    The indicator stock on a car is located in the same place regardless of whether the driver turns left or right. It is even there if the car is driving straight on a one-land road with no near exits. Moving it one way always does the same thing.

    If the answer isn't obvious when navigating, it is not part of an intuitive UI. The overarching logic may or not be simple, but hard to grasp by way of just trying to navigate.

    github-actions[bot] commented 1 year ago

    This issue has been automatically marked as stale because there wasn’t any recent activity.

    It will be closed soon if no further action occurs.

    Thank you for your contributions!

    github-actions[bot] commented 1 year ago

    This issue has been put aside. It is currently unclear if it will ever be implemented as it seems to cover too narrow of a use case or doesn't seem to fit into Weblate.

    Please try to clarify the use case or consider proposing something more generic to make it useful to more users.