Vantagens e desvantagens na utilização do menu global

Outra coisa que não faz sentido é não ter menu global, se vocês está trazendo uma experiência parecida com o Mac OS, pelo menos faça direito e ponha um menu global. É por isso que, com todos os defeitos, o KDE Plasma é a melhor interface, visto que pode recriar todas as outras.

Eles não usam menu global por escolha pessoal de design.

Declaração do fundador do projeto:
image

Particularmente, entendo que o caminho mais fácil de se implementar funcionalidades é através de barras de menu, mas eu não gosto nenhum pouco também. As vezes acaba sendo confuso demais, não é de menos que uma quantidade boa de apps que utilizam acabam por implementar alguma funcionalidade que permite que se pesquise por opções digitando pelo nome dela para justamente você não precisar sair procurando na barra de menu.

1 Curtida

Sr. Fore tem uma opinião bem forte, né? Não consigo imaginar nada do que paga as minhas contas hoje, como DataGrip, KNIME e QGIS sem barra de menus. Uso muitos atalhos, mas as barras de menu continuam sendo importantes. E o são até hoje no Macintosh também, que me parece ser uma inspiração fortíssima para o Elementary.

4 Curtidas

Sim :joy:
Ele também já deu umas patadas no MacOS, dizendo que não queria que ninguém comparasse o Elementary com o MacOS.

É possível, só que normalmente, principalmente em programas complexos como os que você citou, o foco é mais em desenvolver as funcionalidades do que pensar em organizar as mesmas. É muito mais fácil criar uma barra de menu e encher de opções e implementar um buscador de opções mais atalhos do que ficar pensando em como distribuir melhor as opções. Exemplo de programas que não usam barras de menu e continuam sendo bastante complexos são o Stoq e o GNOME Builder.

Todos possuem funções de busca, a menos conveniente é a do QGIS, porque ela se limita mais à caixa de processamento/geo-algoritmos, mas no DataGrip e no KNIME, a busca é mais fácil. O DataGrip é baseado na IntelliJ IDEA da JetBrains, então ser bastante usável com o teclado é uma prioridade, enquanto o KNIME está apoiado nos sólidos alicerces do projeto Eclipse.

Mas eu realmente acho que não inventamos nada mais prático para fornecer uma categorização hierarquizada de funcionalidades. A Microsoft tentou com a Ribbon (Faixa de Opções, no Office em português brasileiro), mas eu ainda não fui convencido, fora que no macOS ela é obrigada e entregar o Office com menus do mesmo jeito.

1 Curtida

Exatamente, é o caminho mais fácil para se lidar com essa situação. Tanto que nos produtos da Jetbrains, como o DataGrip que você citou, você não precisa tocar na barra de menu se não quiser e o mesmo ocorre com outras ferramentas como o Eclipse e o VS Code. É uma solução que foi criada para evitar os incômodos que opções incontáveis na barra de menus criam para o usuário e que me agrada bastante em qualquer aplicação.

Concordo, mas essa categorização não precisa estar necessariamente atrelada a um menu dropdown. Os próprios Ribbons da Microsoft é uma forma de apresentar opções mantendo a categorização só que de forma mais legível e menos inconveniente.

A função de busca só faz sentido para mim porque eu pude acessar menus e ter uma visão geral das funcionalidades oferecidas, sem isso, eu não teria ideia de como fazer pesquisas assertivas.

Não precisa, mas não encontrei nada melhor, nem a Ribbon, como expliquei. Eu acabo sendo obrigado a customizar aquela faixa de atalhos e adicionar uma série de coisas ali. A Microsoft deve saber das limitações, tanto que é possível fazer formatações de maneira contextual, porque a paleta de formatação foi fundida com a Ribbon e, se você está numa categoria diferente, precisa sair dela. No passado, o usuário podia ter duas ou mais barras de ferramentas.

@thespation, poderia dividir a thread em uma nova de título “Barra de menus é a única opção para organizar opções?” ou coisa do tipo? :thinking:

1 Curtida

Conteúdo sinalizado escondido.

2 Curtidas

Conteúdo sinalizado escondido.

1 Curtida

:neutral_face:

Word, Excel (que é Turing Complete, o que por tabela já adiciona várias camadas de complexidade), Power Point, Access, Diversos CRMs, plataformas de LowCode, tem centenas, talvez milhares de softwares extremamente complexos usando, além disso, a lógica de funcionamento é a mesma, se eu usar uma calculadora de exemplo continuaria válido

Por ser um software semi lowcode/nocode e ainda sim implementar todas as funções do sql, o Access é por definição mais complexo que o datagrip e olha só?

Ribbon!


O KNIME é um software extremamente simples de ser portado pra Ribbon… dá pra ficar citando o dia todo

Eu não vou levar adiante a discussão pelo tom empregado. Lamento muito.

Tu não pediu software complexo usando PowerBI? Olha ai, mais um:

Menu global só faz sentido em ambientes onde a barra de títulos é inexistente, ou se funde com a barra superior do sistema operacional.


Já os outros dependem de alguns fatores, o CSD por exemplo, as aplicações podem ser complexas desde que ela tenha sempre tarefas corelacionadas, exemplos são IDEs code, virtualmente qualquer IDE pode copiar a interface do GNOME Builder:

São aplicações que fazem algo muito específico, você não usa o Builder pra manipular imagens por exemplo

1 Curtida

Ter o menu global e não usar é liberdade do usuário.

Não ter o menu global e não usar, é opressão da interface.

1 Curtida

Você resumiu bem o assunto, e é exatamente por isso que eu uso KDE Plasma.

Obrigar a interface a ter menu global então seria opressão de usuário?

Temos que ter consciência de ambos os lados. O desenvolvedor(a) tem que ter total liberdade para desenvolver o SEU PRÓPRIO software da forma que ELE QUISER e aqueles que se interessarem usam, caso contrário não.

NÃO existe opressão alguma de interface, você NÃO é obrigado a nada, assim como NENHUM projeto é obrigado a te dar NADA.

2 Curtidas

O desenvolvedor pode escolher oprimir o usuário, mas o usuário não pode escolher oprimir o desenvolvedor. A lógica inversa não funciona porque só quem tem mais poder pode oprimir aquele que tem menos poder.

Se a maioria dos usuários deseja um menu global, é uma necessidade não atendida e um mercado em potencial. Logo será aproveitado por algum desenvolvedor que deseje fazer tal código. Mesmo que seja a maioria dos usuários, eles não podem oprimir o desenvolvedor a realizar algo.

Correto. A mesma coisa escrita em outras palavras: O desenvolvedor tem liberdade para oprimir o usuário. Nesse caso específico de forma intencional como já divulgado pelo Daniel Fore.

Como já expliquei, existe sim opressão da interface. Nesse caso o usuário é sim obrigado a algo, e esse algo é não usar o menu global por escolha do desenvolvedor. Concordo que nenhum projeto é obrigado a dar nada a ninguém, embora essa seja uma afirmação um tanto vazia :thinking:

Por último achei essa sua mensagem uma tentativa de ataque pessoal, por conta de tirar o foco do usuário e trazer para mim. O ideal é manter uma comunicação não-violenta e o debate no nível das ideias.