Replies: 48 comments 51 replies
-
Did we get it 100% right. Probably not but that is why we had beta versions and release candidates so that people could test and give feedback. If my memory serves me correctly it is three years since the change was made. |
Beta Was this translation helpful? Give feedback.
-
I don't mean to be annoying, just think of it as a technical question. Was there any research done on this, a poll, or did someone simply say it would be better not to display certain information? For me personally, it's very inconsistent and confusing because I don't see any key in when to display the hint or not. What I see as systematic and not confusing is that the tooltip will also display information that most people don't need to know. In fact, the tooltip has one great feature. Those who want to see it, will go to the tooltip. Those who don't want to see it won't see anything. People just know, where to find the quick help.
Does it mean, it is not allowed to give feedback for stable version? I will give myself as an example. I am only now getting feedback from community members. Either I can tell these members that it is too late, or I am simply trying to provide this feedback even now. It's not always about the person giving the feedback, but also about the person collecting more feedback in their community, and it comes gradually and later.
Another very important thing is that the extensions in which this issue shows up in full are only available from the stable release. I would strongly urge everyone to not only look at features from the core perspective, but also from the extension perspective. Something that's not so prominent in the core can be very problematic in extensions. I don't want to cause conflicts, please don't take this personally, but if I played a game with my users like "90% is useless, you should have called when Beta was, etc." I wouldn't have any more users :-( Why I'm talking about this. Because I am part of various Joomla communities where people are leaving Joomla as a system because nobody listens to them. BTW - I am not writing this comment as myself, rather I am speaking for the people in the communities in which I am a member. For me personally, such a shortage is more of an opportunity to create another extension that people will thank me for. |
Beta Was this translation helpful? Give feedback.
-
Display it when its useful. Dont when its not. Just looking at your own downloads extension you can see how many of the field descriptions are completely useless and of no help to anyone at all. So you really think it is helpful to make your users hover over every field to see if there is some hidden magic only to read such useless text. They will quickly realise they are useless and stop even looking - and then you as a developer will wonder why people dont understand your extension Just picking one field as an example
Yes I said it was useless to display useless information. It was merged very very early so that you could give feedback on it. It was not something changed at the last minute. The beta and rc releases are the research.
No one stops you but then again your opinion would have been more useful earlier
Not at all. None of your descriptions are hidden now. They are all displayed for your users to see and they dont have to hover over field one at a time to see them. YES I AM ANGRY WHEN CODE COMMITTED THREE YEARS AGO IS COMPLAINED ABOUT AS IF IT WAS COMMITTED YESTERDAY. |
Beta Was this translation helpful? Give feedback.
-
Did you read what I wrote? It's a reality that you don't get feedbacks from other members until the stable version. Yes, the reality is that 99% of the members in all the communities where I am a member only started testing the version when it was stable. And someone is simply listening to those members and conveying that feedback only now. And either we want to hear it or we ignore it. But the fact is that simply based on various events, this feedback is only coming now. That's just the reality. It's just feedback, an opinion. It's not something to upset anyone. |
Beta Was this translation helpful? Give feedback.
-
Well, yes - some param descriptions can be shorter or do not need to be displayed. However, there are some params that really need a bigger description. E.g. params in Global configuration. All params matter!
Sorry but I think it is always never too late to report bugs and suggest improvements. Just remember how Joomla 3 was changed from the beginning and how many cool featured were implemented later. |
Beta Was this translation helpful? Give feedback.
-
The change WAS DONE 3 YEARS AGO where was your feedback all these years? Also, since I was involved in this change, I kept repeating this quote: Also another quote from Elon Musk: |
Beta Was this translation helpful? Give feedback.
-
|
@wojtekxtx thanks, I'm aware of the relativity theory... |
Beta Was this translation helpful? Give feedback.
-
Please read:
All written above. You really don't understand that many many people started to test Joomla 4 now? What exactly don't you understand about the user feedback only coming in now for various reasons? How do I understand that instead of arguing about the use of a property, we deal with what time the feedback came? Is there a reason we're diverting the conversation away from factual comments to personal attacks? Why should someone who provides feedback has to answer personal questions about why he/she didn't provide that feedback three years ago? |
Beta Was this translation helpful? Give feedback.
-
Damn, you're absolutely unbearable! Leave your imagined world with pink ponies and unicors (how it should be) and return to reality (how it is). |
Beta Was this translation helpful? Give feedback.
-
I do understand that
Let me ask you something: did you put the energy required to bring your extension to the J4 level? To me this complaint is all about |
Beta Was this translation helpful? Give feedback.
-
|
It's good to know that some extensions don't include simple parameters like whether or not to publish an article. But also parameters for which there are many pages of documentation (just for the parameter itself), and the short version used in the tooltip contains dozens/hundreds of words because it is in context with other parameters. This has nothing to do with personal stuff like "my old form". If you knew my extensions, you would know that I try to adapt them to the latest features of the system, unlike many other developers. This is a general suggestion about simply being able to test some things when the system was stable. Because it was only then that various extensions were available that contained different features than core. But it depends on everyone, my advice is that when I create a feature, I don't just look at how it will work in core, I also look at how it will work in extensions or in other parts. I'm not just thinking about making sure that parameters are easy to explain, but also that some parameters, even if they have extensive documentation, unfortunately have to have extensive information in the tooltip. Whether the person who does such propriety wants to hear that is up to them. However, it would be good to make a factual arguments. But let's leave the extension aside, in the first question I see the core parameter "Enable versions" in the images as an example. I really don't think I can find any Joomla user who would appreciate the fact that now he/she has to visit external documentation for a parameter that says nothing. In abbreviated computer speech: Tooltip: No description at all: And again, this is an opinion, an opinion at the time we came across this problem. If it's too late or you don't like this opinion, maybe it's better to leave it without comment. |
Beta Was this translation helpful? Give feedback.
-
3 YEARS AGO Joomla was in alpha stage and was tested only by developers. |
Beta Was this translation helpful? Give feedback.
-
|
@Sulpher @PhocaCz @kernusr Let me educate you a little bit because by criticizing without the appropriate knowledge you're offending some people here, particularly Brian and me in this case. The decision to declutter the UI was one of the main goals for Joomla 4.
The in-place help part then was given to a GSOC student in 2018, but the solution was rejected: https://github.com/joomla-projects/gsoc17_helpscreens_on_jdocs The in-place help was given again to a GSOC student this year and I have no clue what's the status: https://github.com/joomla-projects/soc21_guided-tour In short, the project had a very viable solution that would cover every requirement that was given. Unfortunately, you are criticizing something with a very poor background on the subject. Ideas are not exactly contributions, you want to help then present some code... And I'm unsubscribing... |
Beta Was this translation helpful? Give feedback.
-
@dgrammatiko Please let me know where exactly I offended you? Can you distinguish between criticism and feedback? If we are giving some feedback without some knowledge, then surely there is some rational argument and certainly not an argument like "The change WAS DONE 3 YEARS AGO where was your feedback all these years?" Only now will I make the first criticism. Instead of addressing what is in the very first post, i.e. the missing parameter description, there is only misrepresentation and nonsensical arguments with personal attacks, but certainly not from our side. So can we get back to the point? The missing parameter description. |
Beta Was this translation helpful? Give feedback.
-
|
You’re all wasting your time. It’s like talking to a stone wall. No matter what you say and when you’ll be told you’re wrong. That’s the one true Joomla way of dealing with its contributors. Three years ago Joomla was alpha 2 and every comment about the UI was met with “this is alpha, it is not the final version, we are still making changes to the template”. Now you’re told you should’ve provided feedback back when it was blatantly ignored. Two years ago it was late alphas when I contributed improvements to Download Keys. I added tooltips. I was asked to remove them because accessibility. Now you’re told they don’t have to do with accessibility per se. You’re told that the interface should be intuitive, yet Joomla has many non obvious options. We could phrase them with long sentences but this is against decluttering, the supposed main goal in J4. Meanwhile the documentation page for many core pages, including the Users options for example, is out of date and there is no indication what each option does. I think it’s pretty obvious what is going on. There has been ZERO UX work on Joomla 4, something which is blatantly obvious to those of us who were at the Joomla 4 sprint in Athens when the UX lead was told that the UX team is supposed to just say yes to everything the developers want to implement. That’s why she quit. She never told anybody but fuck it, she’s my wife now, she told me and I can finally say it after six years. That’s Joomla’s problem, right there. UX needs to drive development, not the other way around. UX is about what our target audience needs to get shit done, not any one person’s ego. I’ve implemented things in my software I personally disagree with EXACTLY BECAUSE the UX research said that my users actually needed those features to get stuff done. If people here can’t put their massive egos to the side to help the users that’s a systemic failure and the single most major endemic problem in Joomla. |
Beta Was this translation helpful? Give feedback.
-
|
I was also in Athens and can't remember that someone said the UX team should just say yes, anyway I don't know anything but this wasn't an offical statement from team. We all know we can do better in certain areas and I can understand the frustration on both sides. From what I know the guided tour project was good and successful. For the people missing information at some places, let's discuss and add them if they are providing something usefull. I can say that I am not a big fan of tooltips, if they have to be there, there then to often without information. I know this becuase have written to much of them :-) |
Beta Was this translation helpful? Give feedback.
-
So the solution is to remove the description for all? Isn't there any solution, which can even help blind users to decide if they want to hear the description or not? How does removing descriptions completely help blind users? I mean, the tooltip system in J3 may not have helped the blind users, but it certainly didn't hinder them, and if we compare the tooltip with the situation in J4, where the description is completely missing, then we can't say that we have achieved better accessibility in the description area. |
Beta Was this translation helpful? Give feedback.
-
|
Visual impairment comes in many forms: there's total blindness, there's colour blindness, there are people who have impaired ocular motor function, dyslexia, etc. These people may be heavily reliant on other aids (e.g. screen readers) to navigate around the web. One of the most commendable goals of the J! 4 project was to make the CMS more inclusive: to respect and to assist all kinds of people who have a11y needs. I don't think we can flippantly dismiss a11y concerns simply because, as a person who has "normal" visual acuity, you don't think something may be necessary. I'm sure there's a way through this matter but it requires an understanding of how disability aids can be tailored to meet people's needs just as much as it involves giving non-disabled people the ability to choose certain preferences. This is something that requires careful thought giving consideration to the different needs of different users. I don't have the answers. I am, however, saying that J! 4 is better for people who have additional a11y needs. |
Beta Was this translation helpful? Give feedback.
-
|
@sozzled Yes, but see second post in this discussion made by Brian:
So we can extends this:
with: Once again. The goal of this discussion is not to preserve the tooltip at all costs, but to preserve the description of the parameters and create a feature that will not limit those who do not want to see this description. And this topic should be independent of accessibility. If you display the description, of course, make it as accessible as possible. We can all agree on that. |
Beta Was this translation helpful? Give feedback.
-
Why please? |
Beta Was this translation helpful? Give feedback.
-
|
@Dylis Because we already have more than enough parameters and don't need an additional one for things which can be done using a simple CSS rule. |
Beta Was this translation helpful? Give feedback.
-
|
It's a bit more nuanced than a simple CSS rule. Showing / hiding requires a bit of JavaScript which not only toggles the CSS class but also modifies the control's ARIA properties so screen readers don't announce the visually hidden help text. You can both see for yourselves how it works in my PR in #35610 The overall idea is this. Inline help text (form text) needs to be a concise description of what this parameter does and any non–obvious gotchas. It will be hidden by default so it doesn't get in the way of the more experienced user. There is a toggle inline help button in the toolbar to show it and hide it at will. The whole thing is totally b/c by the way. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, it gets a bit more complicate if you take care of ARIA. Your solution looks fine and sensible to me from a first glance. |
Beta Was this translation helpful? Give feedback.
-
Ok my bad, I understood you didnt want any "show/hide descriptions" button at all. |
Beta Was this translation helpful? Give feedback.
-
|
There are many things that Brian and I disagree on ... but there is one area in which we in total agreement: accessibility. I don't think you'll find a better advocate—a better champion—for the needs of people who "see" the world differently from the way that you and I, perhaps, may see it. Even @chmst "sees" the world differently (and that's not just because she lives in Germany). We're all different but, to its credit, J! 4 has been more inclusive in understanding the differences that separated and isolated people who have physical impairments. I have no problem with making J! more accessible. Yes, I agree, that the advancements made in a11y have side-effects that may niggle "un-impaired" users. Yes, I have the "normal" physiology of a human being: I can read, write, walk, hear, touch, taste, smell, feel. People may question my mentality and I can laugh with them about that. But we're all different. No, I don't believe we can discuss the issue of tooltips or other mechanisms for displaying help-text without involving the issue of accessibility: to do that would be to abandon a primary objective of the J! 4 project. |
Beta Was this translation helpful? Give feedback.
-
|
Changed my mind after the eighteenth re-read of the topic from beginning to end: this topic has nothing to do with accessibility. It has everything to do with people who mandate what they think is best for other people. Sorry for my distracted thoughts about a11y. |
Beta Was this translation helpful? Give feedback.
-
|
I'm beginning to wonder if it's not a matter about how to improve "help text" in the backend as opposed to the absence (or removal) of any help text in J! 4 that could be displayed if it existed in the first place? 😕 Brian mentioned displaying help text/tooltips "where needed" ... Eugene's screenshot at the beginning of this discussion shows these tips appearing in several places in the J! 3.x backend (when you hover a mouse over the field caption). In the corresponding J! 4 version of it, there are no such tips. I deduce from that example (and probably countless others) that someone, in their wisdom, decided that in J! 4 those things weren't "needed" ?!
So, who decided to remove things that in, some people's opinions, didn't "add value"? |
Beta Was this translation helpful? Give feedback.
-
|
It's like always. Someone does a PR with the suggested change. Then some people test it. Then maintainers or release lead decide to merge. |
Beta Was this translation helpful? Give feedback.
-
|
Why is the https://github.com/joomla-projects/soc21_guided-tour not the answer in the documentation/explanation of the UI here? (kinda funny that we have to explain the UI in the first place which obviously exposes another deeper problem, but anyways) This was the solution that was agreed upon many years ago based on the response of numerous UX/UI people. A half-decent button that reveals/hides descriptions might sound nice at first but might be locking the CMS to the same bad UI as tooltips did... |
Beta Was this translation helpful? Give feedback.
-
And I thought that the new installer (which exists because I was stubborn and introduced it in J4, as it wasn't even in the list of todos) was much friendlier. Well, that's honest feedback and I will take full responsibility for it 😔. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, Dimitris. I wasn't complaining: I know how to install J! (you upload the ZIP file, uncompress it, and then run the installer). What took me so long to learn was how to shorten the preliminary [upload/decompression] phase. What's missing, for those who have never used a CMS before in their lives, is a short instruction/tutorial (text or vision-based) that shows people how to upload the J! installation package, decompress the package, before you go through the couple of minutes answering the prompts in the installation dialog. The J! 4 installation dialog is a breeze (and thanks for that). What I'm talking about is what happens before people see the first screen that says "What do you want to call your new J! website?" Most people assume that everyone knows how to get to "the installer" and, I think, most people would be wrong. A lot of new J! users get themselves into strife because they use third-party software deployment scripts (and we all know that these kinds of "deployments" lead to ongoing maintenance problems). Just look at the number of questions asked by first-time users on The Joomla Forum™! This is off-topic. I'm just saying that I agree with the statement that J! is not intuitive. |
Beta Was this translation helpful? Give feedback.
-
I think I had proposed a single |
Beta Was this translation helpful? Give feedback.
-
|
I'm saying that, for some things, short, inline, context-relevant help text is useful. For some other things, a context-linked button to the relevant doco is helpful (assuming the doco exists and it's up to date). Some other things may require different methods to explain things: trial-and-error, ask questions on a technical self-help forum, or find a "personal trainer". The problem that we're discussing here is not about the different approaches to providing help. The problem lies with the decision to remove a lot of the help text (that existed in older versions of J!) from J! 4 because someone decided that it was intuitively obvious and therefore "wasn't needed". How help text may be displayed/revealed/rendered (while keeping in mind the objective to make things as accessible as possible) is another question. The "missing parameter descriptions" that Eugene was talking about were junked/trashed/thrown away/trash-binned/exterminated/carved-out/dumped/excised/expurgated/abridged and that's the problem that will, in Nick's words, lead to J! 4 becoming useless. |
Beta Was this translation helpful? Give feedback.
-
The guided tour AFAIR could provide help for anything on the particular screen, it even allows to point and explain. The idea of the button will work only in a form context, so no list views or any other view that doesn't derive from/or use an XML. That alone is a huge barrier. Introducing a new system that will cover only forms instead of providing help for every view is a no-go for me. Either get a holistic solution that covers the entire UI or keep the existing help button with the new window approach... My 2c |
Beta Was this translation helpful? Give feedback.
-
Thank you for the apt example. If we don't understand such a basic and clear principle of UI/UX, then it's hard to reach new users, plus we lose existing users who are being deprived of these basic and very natural elements. |
Beta Was this translation helpful? Give feedback.
-
|
For history this was the original proposal
(step 2 labels is a typo and should have said descriptions) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, Brian. I'm still none-the-wiser for knowing who undertook the task of making the change or who approved the implementation of the change but I now understand how the change was done (and, without going to the trouble of rewriting my earlier guesswork about culling language files, just ignore where I may have mentioned that it earlier). The fact is that J! 4 is different to J! 3. Many field descriptions have been clobbered: the XML files have been altered from J! 3.x and that's why there's no description/help appearing underneath the form field. Returning to Eugene's example at the beginning of this discussion, I've attached the XML files used in J! 3.x and J! 4 So, where does that leave us? If fields in XMLs don't have descriptions there's no way to "optionally" display them, is there? Someone decided that the XML field descriptions didn't add value. Someone approved the removal of the XML field descriptions. The consequences are what led to Eugene's discussion (and to Nick's fury). This leaves members of the community in three camps: there are those who think it's important to retain the descriptions, those who don't think these descriptions add value, and those who would like the option to display or hide whatever descriptions exist, if they exist (which they don't). In the "retain" camp, there's @Sulpher , @nikosdion and me (to an extent). In the "remove" camp, there's @brianteeman, @chmst and @rdeutz. There are probably others who have not been involved in this discussion who fall into one or other of these two camps. In the "optionally-display-if-we-could" camp, there's @PhocaCz and @Bakual. I understand the different viewpoints and where they've come from but, at this time (with J! 4 having arrived at this place where it now is), I don't see an easy resolution of those differences. |
Beta Was this translation helpful? Give feedback.
-
Yep. That's what we're talking about. The descriptions were removed by purpose. Someone (Brian) suggested it, some others (at least two people) tested it and the release leader (George) or someone else from the maintainer team approved it and merged it. That's the way development of Joomla works for years. If you want to have them back, add them back to the XML (and add the strings to the INI for translation) and they will appear again. It's as simple as that. It's a dead simple PR. I'm a bit tired of repeating myself. This discussion is a waste of time. Just do a PR to add the descriptions back where you think they are helpful. Then we can discuss the effective proposals in said PR and either approve or deny them in the end. But just theoretical arguing brings nothing. |
Beta Was this translation helpful? Give feedback.
-
|
you are putting me (and I suspect others) in a camp that I am not in. You are simplifying things to produce divisions. I dont believe anyone at all wants to go back to having tooltips that were identical to the label |
Beta Was this translation helpful? Give feedback.
-
|
It is over 4 years so I forget who was the first person to come up with the idea. I did however, just like Nik does, request approval from the release lead before even starting the work. I can however remember where that approval was given - a pub in London before a JoomlaDay. As can be seen from the original PR no one in the last 4 years has chosen to work on step 4 of the workflow
At least now it seems that someone has woken up and is doing that |
Beta Was this translation helpful? Give feedback.
-
Did a quick search of the language files: it doesn't appear to me that the original "description" strings have been removed from the INIs. It's not a simple PR to revert things back to the way they were before someone spent dozens of hours changing the XMLs. As for me putting people in various "camps", that's my opinion. If the cap fits, wear it; if it doesn't, ignore it. 😜 |
Beta Was this translation helpful? Give feedback.
-
|
Conceptually, this is how you could "restore" the missing DESC values in the XML files:
Conceptually straightforward. Would break if the naming standard for descriptions wasn't consistently used (or if there were no translations for them) but it might work. Just an idea. Will not please everyone, however. |
Beta Was this translation helpful? Give feedback.
-
|
If you just restore all descriptions to J3 state, then it will be rejected for sure. Nobody wants to have useless descriptions back. |
Beta Was this translation helpful? Give feedback.
-
|
I have already made a POC both for the interface to Show/Hide inline help AND how inline help text should be (for com_config, I am not crazy to spend a week without getting approval) https://github.com/nikosdion/joomla-cms/tree/feature/inline-help You can see that not all options warrant inline help. Some are obvious such as Site Title, Site Offline etc. Some have non–obvious implications, e.g. that the default text editor is the only one which can be used by Guest users (I get a ton of email on Akeeba Engage about that) so I explained those. Same with options that have a non–obvious security implication e.g. that using /tmp as your temp-directory does work but it's woefully insecure (what I didn't explicitly say: this is because any other site on the same server has access to that folder and depending on permissions it MAY be able to overwrite or read your files or otherwise they'd be able to create a folder / file under the name you are trying to use, causing your extension installation/updates to fail). Other options can break your site, e.g. changing the DB driver to a different technology. “But it's obvious” the peanut gallery screams. I have 16 years of experience helping at least two dozen people every year who do exactly that (and I know that for every ticket filed there's another 10 people who didn't file a ticket) so, no, it's no obvious for quite a few folks, so I added a small warning. Other options which are outright confusing I documented. By default, I show no help text. Pro users can skim through the form and change what they need without tooltips and help text in their way; bliss for us power users. Beginners can click the Show/Hide Inline Help button to have those hints shown which will save them a lot of trouble and confusion. I have some errands to run. Expect a proper PR this afternoon or early evening (Eastern European timezone). PS: Unlike Brian said, I did not “finally wake up”. I have been supporting Joomla 4 in my software since Alpha 2 in November 2017. However, every single time I tried to propose something about the visual appearance of the CMS I was met with toxic pushback. I was repeatedly told I don't know what I am doing (I guess having the most popular extension on the JED for 14 years running, praised for its interface and documentation, must be an accident...) or told that the template is not final and generally had my time wasted without any effect. On top of that I had to keep working around things Joomla was changing so my software can still work on each and every alpha, beta and RC — the fact that there were breaking changes in RC versions is insane — which took a lot of my time without paying anything in return. So, yeah, excuse me that I provided a free service to the community without getting anything in return and didn't let the toxicity dissuade me from coming back for more. I am here to help users because a. I believe in Free and Open Source Software and b. it's also in my best interests to increase the adoption of the CMS that helps my family make an honest living. It's not about “waking up”, it's about toxic people finally shutting up and work on solutions instead of insisting nothing can be done for the first 20 posts before admitting that the plan all along was to actually find an alternative solution!!! And no, I do not consider “being given permission in a pub” to be even remotely acceptable. First of all, this makes Joomla sound like a drunkards' clique with everything that entails. Second, there is zero transparency if permissions to make MAJOR changes are not publicly recorded. I'm tired of running git blame and play detective only to come up to an issue which alludes to an off–line agreement between parties unknown and content unknown under circumstances unknown. |
Beta Was this translation helpful? Give feedback.
-
|
Hi there, Greetings Example: <field
name="MOD_SOMENAME_FUNCTIONALITY_LABEL"
description="MOD_SOMENAME_FUNCTIONALITY_LABEL"
type="functionality"
> |
Beta Was this translation helpful? Give feedback.
-
|
Since J4 there is a button on top right "inline Help". It is a toggler to show or hide descriptions. This is a rather old and very long discussion. If you have more question, could you pleas open a new on discussions? |
Beta Was this translation helpful? Give feedback.
-
You can't (at least not easily) since the changes done with the introduction of the inline help button affect ALL the descriptions (with initially hiding everything). Also since Guided Tours are already part of the CMS the whole inline help is just irrelevant. Would be nice to eventually revert it and have the form fields with the description always visible (as it was with v4.0.0) My 2 cents |
Beta Was this translation helpful? Give feedback.
-
|
Tooltips are generally used to provide help. Joomla has always used Tooltips and until then everything was fine. Then, for some incomprehensible reason, Tooltips were thrown away and replaced with text under each parameter. But this has the disadvantage where some descriptions are longer and can cause lack of clarity for form fields. That is why the switch button was chosen.
I don't understand why this is no good for us? Why we have to discard standards? We have made life completely pointless and unnecessarily complicated for ourselves and Joomla users by discarding standards. Even ones that have worked flawlessly in Joomla all along. By the way, Tooltips are still accessible in Joomla and work both on desktop (hover) and mobile (click):
Let's not go on and on about nonsense and use the standards everyone is used to. MOBILE: DESKTOP: In short:
|
Beta Was this translation helpful? Give feedback.
-
|
A truely heated discussion :-D Thank you, with some clues I could figure out, that:
|
Beta Was this translation helpful? Give feedback.
-
|
THANK OUT :-)))) ANd this descussion reminde s me, that everybody wants the best for J!, you are great! |
Beta Was this translation helpful? Give feedback.
-
|
"By the way, Tooltips are still accessible in Joomla and work both on desktop (hover) and mobile (click): I do nopt get this, how can I activate / provoke this behaviour in my module; do I need a special tag? Any help appreciated :-) |
Beta Was this translation helpful? Give feedback.
-
|
I do this with loading the library
and then foreach (form fields) and just echo the description: The role="tooltip" hides the text and displays it in tooltip. But this works e.g. in component where you can manage the output of the form, not in module where the form is rendered by Joomla system. The situation is now very confusing and problematic:
The help system is now completely destroyed. Jan |
Beta Was this translation helpful? Give feedback.
-
In Joomla 4 params have no description.
As I've heard, it happened to meet WCAG standards.
However, param descriptions are a must-have to understand what exact param is used for especially when it comes with new params that J3 doesn't have or when a user is a newbie. And, to tell the truth, sometimes even experienced users need to see the description to get more info about technical details.
My idea is to add [QUESTION] icon near each param and make it clickable. When the click is performed, the tooltip window appears.
And this mode can be optional - so if someone needs it - they can disable tooltips and get the result as now.
Joomla 4:
Joomla 3:
Beta Was this translation helpful? Give feedback.
All reactions