Sorry @Ilia me again.
Trivia I know, but perhaps needs attention, a general rule of thumb - accepted norm - if a user hovers over a link / menu item a help prompt is displayed indicating the url that the user will go to if they click on the link/menu item.
This is pretty much true throughout Virtualmin.
for example go to Virtualmin -> Server Configuration -> and hover over SSL Certificate and the help prompt shows https://domain.com:10000/virtual-server/cert_form.cgi?dom=16890059795199&xnavigation=1
Go to Virtualmin -> Dashboard (and I select a another domain from that list - not the first in the list of course) then hover over Dashboard menu item
The help prompt shows https://another_domain.com:10000/sysinfo.cgi
This is nothing like where that link actually takes you.
If you click on the menu it does take you to the Dashboard.
But if you enter the url in the browser one goes to a bad place. It takes one back to Webmin (for a start) and it resets the selected domain to the first in the list. On top of that when you tab to Virtualmin one gets the spinning circle of doom as there seems to be stuff happening.
Also if the help prompt was changed to the actual destination https://another_domain.com:10000/sysinfo.cgi/?xnavigation=1 that is still incorrect as going to that url still takes you on the same journey through Webmin.
I think you know what Iām going to say here!
why not https://domain.com:10000/dashboard or similar https://domain.com:10000/virtual-server/dashboard.cgi?dom=16890059795199&xnavigation=1 in keeping with all the other help prompts?
and while Iām on my hobby horse why ?dom=16890059795199 and not dom=a_real_domain_name ? I donāt know about everyone else but I find long numbers difficult to remember.
Ed: Actually all one needs to do to be dumped is to do a browser refresh (Ctrl + R) ā domain forgotten and back to Webmin. Because the system has forgotten where you were.
Actually all one needs to do to be dumped is to do a browser refresh (Ctrl + R) ā domain forgotten and back to Webmin. Because the system has forgotten where you were.
If you make full page reload while being on the Dashboard, then yes, the menu switch isnāt remembered. This is quite expected, and would be pretty hard to make it work as you suggest.
Moreover, this is absolutely not important in my opinion, because you only need to reload the page when theme is upgraded, i.e. as part of Webmin upgrade.
That said, the menu switch is remembered for all other Virtualmin pages, except Dashboard. Whatās the big deal?
Alright to try to be more clear. Iām on Windows (and Chrome browser not that the browser makes any difference) and Iām pretty sure it is the same on an Apple machine.
If you move the mouse over a anchor link (menu item with a title attribute) or when using a screen reader. You see a small popup at the bottom of the browsed page that displays the āhref=ā or ātitle=ā content of the link. That is the help prompt to which I am referring. There are long established and accepted rules about this prompt. Some of which that have been expanded W3C (SC 1.413) regarding making them focusable / dismissible / persistent especially for accessibility.
Perhaps that is something slightly off this topic. I was just using it as an example and the question flashed into my head - why? it seems so easy to design everything with the same principle design rules.
why use url path parameterisation ../virtual-server/some.cgi/ for one url and then url query string parameterisation ?dom=some_unmemorable_number&xnavigation=1
for another it is inconsistent even if correct and confusing and meaningless to users.
There is no need to care about domain name in URL. It is possible to change it, although I donāt see any practical value in doing it, as you always have domain name shown in navigation menu.
I could have a look in making sure that the Virtualmin tab is restored with Dashboard reload.
They can but that is a separate process so changing the id number could be included in that process on that page. The numbers (or name) seem to have some importance when they are included in urls yet the number remains meaningless to the observer or someone entering the url.
An example would be me providing a novice user with a go to link as help. If that link was clear as in https://your_domain.com/virtual-server/some.cgi/?dom=your_omain&xnavigation=1 it would do as expected.
whereas the link https://your_domain.com/virtual-server/some.cgi/?dom=1234567890&xnavigation=1 would be a total guess and probably wouldnāt work.
Oh course it will work as that would be the expected target, you donāt need to guess the domain ID at all you can find it at vmin->domain->Virtual Server Summary
from a coding point of view I find a numeric variable much simpler to work with than a string there a lot less checks to make on a number over a string to make sure its correct.
at a bare minimum the following files would have to be renamed to a new id
I am not saying the id as a number cannot be found but could I guess yours or anyoneās if I was providing you or someone else a link to āgo toā finding my own id number would also require several more menu selections. ā might as well just click on that link as provided. The whole idea of providing a link visible on hover is that it has meaning to the user (otherwise why is it there and in the W3C).
in some languages maybe (in NodeJS my language of choice) strings are pretty much a given throughout. interpreting ../spam/14457205497609/v342.pre would be split into path = {"spam", "14457205497609", "v342.pre"} the number ā14457205497609ā or string ā14457205497609ā are just as meaningless to the user. the word ādomā is suggestive of meaning ādomainā othewise just save 2 bytes of code (and bandwidth) and just use ādā if the number is just an attempt to obscure the domain then just use a hash. ?x=a13bf, or better still stop using links (GET requests) altogether.
But this is post not really about the internal workings or choices made in the code of the siteās GUI. It is about the information (specifically the urls), as they are currently provided, being functional. I do note that there are no url links provided on the main menus eg Virtual Server Summary, or Edit Users ā yet they do take you to different pages. That clearly demonstrates intent to show the user.
Not 100% valid anymore, especially on the title attribute. It is useless on all mobile/touch devices so is basically semi-deprecated in all modern design builds.
Illa probably already gets nagged endlessly in his build process by missing ally and aria attributes all over the place and that is more applicable here as far as future navigation improvements to the front end is concerned.
there are plenty of old folk out there still, at least until we all die out or get put into āhomesā who do not use or even have an implanted mobile/touch device.
So most āfuture improvementsā gets put in the same waste basket as ājust stop oilā and āgo vegan, save the planetā clap trap.
Iām fine with adding features to accommodate such things but keep the functionality we are all used to because it simply works, as it was originally designed to do.
So most āfuture improvementsā gets put in the same waste basket as ājust stop oilā and āgo vegan, save the planetā clap trap.
Itās worth noting that the agriculture process for meat production necessitates a minimum of four times more crops for livestock feed than direct human consumption would. Additionally, animal agriculture is significantly water-intensive. Itās not just an opinion; itās grounded in research and facts.
That is why these urls should not change into something human readable there is no need. but have you hovered over a discord link ? it shows in your āhelpā popup something like
where as the human sees that as
so using numerics in urls is not just a vmin/wmin thing itās all over the place. I must admit wordpress tends to āprettifyā itās urls into human readable forms for seo purposes
Iām well over 70 and do not wish to live in a bygone era of web design ā¦ I love to see how it changes over time and incorporate modern ideas into my code
SYSTEM INFORMATION
