I designed the site in 2014. The style was rather retro even then. Most of it is hand-coded PHP+CSS. There is no content management system driving it, but since it isn't usually touched by non-programmers, this hasn't been an issue as far as I know.
Mobile browsing wasn't as ubiquitous in 2014 as it has since become. I still don't own a smartphone. Based on what I know of how the interfaces work, I would guess that the main usability problem with the current design is the lack of enough padding around the nav links for them to work well with a touch interface. This was discussed a bit at the time, but everyone agreed that we were targetting the website at desktops. Alas, this is no longer a safe assumption.
For me, I don't see a problem in the size of the space around the links, but in the fact that mobile devices are portrait by default, which means that there is little room for content next to the menu, which takes up a fixed space on the left.
For example, in the current basic wiki style, it's nice that when viewed on a mobile => on a narrow screen, the menu is at the bottom instead of on the left. Something like that would be enough for me. Maybe there will be some more ideas.
The best way of dealing with the menu crowding is probably to add
some kind of slide-out functionality for Javascript-equipped browsers. Or we could take the opportunity to redesign from scratch, but if we're going to do that, I'd like to know before I get too much deeper into the guts of MediaWiki's revised skinning system.
The current style seems good to me - some parts of the user interface are in the same style - for example, the front page in Konqeuror.
I think having a more smartphone/tablet friendly website would be good, as E. said lot have changed since 2014. Maybe a different position for the menu is enough, maybe we need some bigger changes like a popup menu on smartphone linked to a button, which is a fairly common user experience on mobile.
The nav menu redundancies are due to the headers being links—for the sake of uniformity, they all had to point somewhere, even when the destination was a duplicate of another link. The ideal way to remove the redundancies would be to de-link all of the headers, but that means adding some small links. Or we could just remove the redundant "Bugs" and "Wiki" header links and leave the rest.
Removing the separate Bugs and Wiki entries from menu seems good to me.
I am not sure I understand the exact technical issues with links here, but double links are a bit of a waste. I found the main link like "wiki" "bugs" better than the small links under Support and I would support removing some of the links under Support.
The one actual *suggestion* I'd like to make is that we expand the "CLAs" nav link into something like "License Agreements", because I had to blink at it for several moments before I was able to figure out what it was (especially since the top search result is "Conjugated Linoleic Acids" . . .)
CLA will be a completely separate chapter for discussion - see Project status report - tasks. Maybe there could then be a Contributing item instead of CLAs, where there could be instructions on how to contribute code (TGW), how to contribute translations (TWTW) and so on. The license agreement could then be one of the related pieces of information.
I think other sections could be reworked too. 1) GIT, commit history, Packaging GIT, secure GIT --> just need one entry to point to TGW. 2) uLAB GIT: should not be displayed, since uLAB is an unrelated project from TDE 3) nightly builds: either remove or point to PSB/PTB archives 4) Related projects: they are part of the TDE repos, no need for a separate page on main menu 5) RFEs: just remove that 6) Donations (once we clarify the legal status of TDE): make link stand alone and more visible 7) CLAs: as mentioned by Slavek, this will be a separate discussion
We could even simply consider to have a simple "Development" link to point to the relevant section on Wiki in fact.
Overall I think a bit of restyling would be good. For example change the main screenshot, maybe add a second one too.
What do you think?
Cheers Michele