On Thursday 17 of September 2020 03:46:45 E. Liddell via tde-users wrote: > On Wed, 16 Sep 2020 23:24:49 +0900 > > Michele Calgaro via tde-users <ml-migration-agent@xxxxxxxxxxxxxxxxxx> wrote: > > >>> 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. > > Now that I've taken the time to look around more, I think I know what > kind of thing Slávek means. It involves a specialized CSS rule that > moves the menu to the bottom of the page when the width of the viewport > is less than 900px or so (since testing for portrait orientation is > apparently not reliable). I'll see what I can do (if possible, I'd like > the rearrange the menu horizontally when it's moved). > Yes, that's exactly what I had in mind - a solution in CSS. This could preserve the simplicity and no need for javascripts. Remember that if moving a menu is a response to a "narrow display", then there probably won't be much space for the menu to be arranged horizontally. That's my guess. > > >> 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 problem with the big links is that they don't really work with the > rest of the nav menu (and never have). I think they were inherited from > Tim's original website design, and I didn't feel strongly enough about > them at the time to protest their presence. > > A quick, unscientific survey of the websites of other Linux desktop > environments shows that they either have two unrelated sets of nav > links (not the best idea, IMHO) or place their wikis and bug trackers > at the level of our "small links". That means that most people should > have no trouble locating them there. > Yes, because both levels of our menu are still displayed, there should be no problem for users to find Bugs and Wiki on the second level. These links do not seem to be so special that they are like first-level items that have no children. > > >> 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. > > There are definitely too many links in that section. > > -The GIT links should all be combined into one which points at the > current repository, agreed. > > -Nightly builds are limited to specific distros and should be filed with > the installation information for those distros. > > -There's already a link to the CLA on the "get involved" page—no reason > to have it (or whatever replaces it) at the top level. > > -"TDE Team" has more to do with "Home > About" than "Development". We > might want to punt the "Donations" link up to the first section as well, > to make it more likely it will come to the attention of non-developers. > > -RFEs should be removed until their status is clarified. > > -"Related Projects" needs a different name and a content refresh to add > libart-lgpl and TQT at minimum, since it seems to be mostly about > libraries. > > > Weeding thus reduces the menu structure to something like this: > The proposed rearrangement looks good. I suggest only small changes to the order at the second level: > HOME: News, Features, About, Screenshots, Donations > HOME: News, About, Features, Screenshots, Donations > GET TRINITY: Packages, LiveCDs > > DOCUMENTATION: FAQ, Wiki, Installation, Applications > DOCUMENTATION: Wiki, Installation, Applications, FAQ > SUPPORT: Bugs, Mailing Lists, Service Alerts, Contact > > DEVELOPMENT: GIT, API Docs, Library Projects, Get Involved > A little note here: We have three useful interfaces - CGit, Gitea and Weblate. I believe that all three should be mentioned here. In addition, Commit history provides an excellent overview of what's going on in git across all the individual GIT modules - it seems like a good idea to keep it in the menu as well. > This structure has no "floating" headers without children, and the > headers do not need to be links. > Remember that Home and News, for example, are different pages. If the items at the first level were not as a link, there would not be a reasonable location for a backlink to the home page. > > 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? > > That's a relatively small change. > > E. Liddell > Cheers -- Slávek
Attachment:
signature.asc
Description: This is a digitally signed message part.
____________________________________________________ tde-users mailing list -- users@xxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxx Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@xxxxxxxxxxxxxxxxxx
