'Is there a point talking about limitations in this context? In our opinion - no.'
That is a perfect exemplification of the exact point you are missing. You are referring to a different 'higher level' context.
The context to which I am referring is not one involving an extremely sophisticated UI which understandably requires Javascript.
The limitations to which I am referring which should be present without requiring resorting to Javascript are basic core features/functionalities used in developing applications.
If they were present, then I'm sure 'Is it worth it? For some people - yes, for many more - no.', would instead read:
'Is it worth it? For MANY people - yes, for others - no.'
And you don't have to do/change/add much to capture a chunk of the 'many more'.
For instance, take the tab functionality, since it was mentioned recently in another thread.
You recently added the CLOSE TAB Action. Very good. Obviously a tab can already be opened by directing output thus the opening of a tab functionalityis covered. And AwareApp.startProcess.. with AwareApp.getPanelId ('frame', 'tab_name', 'panel_name') can be used to direct output more precisely if required.
But job only half done! What use is CLOSE TAB on it's own if a Configurer is building an application revolving around tab navigation? Not much!!
Yet how hard would it be for you to complete/consummate the job you started and also include a SWITCH TO TAB Action so the Configurer can control the UX of the application they are configuring?
NOT VERY, I bet! Maybe it's harder than I imagine, but it doesn't seem so based on other functionalities already present.
And to confer complete control over the Tab related aspects of the UX, in the 'Frame Settings' Dialog there would need to be:
- 'Execute the following process when a tab is selected/switched to (by user NOT Action):'
- 'Execute the following process when a tab is closed (by user NOT Action):'
A process can already be set to run after a form is saved. And the onHover event is now captured for grid rows. Surely these two are not overly time consuming or technically challenging to add?
How can your sense of achievement, perfection and 'finesse' allow you to omit these obvious UX control features, which any developer developing a fully featured application would use?
I can't reconcile it. It seems crazy to me to start a job and not finish it completely.
For the sake of completeness.. users often want to reorder tabs by dragging them to group them to be in a logical order, but I would say this functionality not imperative (even though the Kendo Tabs component allows it) to implement.
If your attitude is 'take it or leave it, we don't need the money', then why encourage users in this forum to post reviews on Capterra and PCMag?
Once you get fish to nibble via reviews on Capterra etc., you've still got to get them to bite to get them hooked, and this has always been the obstacle I bet.
But the solution is so simple..
Just COMPLETING the basic core functionality so that functionality omissions which materially impact the capability/competency of applications which can be developed are NOT omitted is the obvious way to get new developers to bite so as to hook them after their nibble.
