Feature-Wunsch: Formatierbarer Freitext (Rich-Text-Feld) für Formulare

qd_team
vor 2 Tagen
7Antworten

Aktuell steht in Ninox nur ein einfacher Freitext zur Verfügung, z. B. für Beschriftungen oder erklärende Texte in Formularen.

Für viele Anwendungsfälle wäre ein formatierbarer Freitext (Rich-Text) sehr hilfreich – etwa für Überschriften, Hervorhebungen, Listen oder strukturierte Hinweise direkt im Formular.

Uns ist bewusst, dass sich dies aktuell über HTML in einer Formel abbilden lässt. Das ist jedoch nur ein Workaround, da Formeln ständig neu interpretiert werden und eigentlich nicht für statische Inhalte gedacht sind.

Ein natives Rich-Text-Element würde:

Formulare deutlich übersichtlicher machen
Workarounds und unnötige Formeln vermeiden
Performance und Wartbarkeit verbessern

Gerade im Business-Kontext wäre ein solcher Baustein eine sinnvolle und saubere Erweiterung des Formular-Editors.

- Pushing the Boundaries of Ninox
- Gotje_Ing
- vor 2 Tagen
- Gemeldet - anzeigen
Moin ,

es ist technisch korrekt, dass Formeln neu berechnet werden. Allerdings nur, wenn die darin verwendeten Werte und Beziehungen aktualisiert werden. Dies trifft hier nicht zu.
Die Anzeige von "statischem" Text oder statischem html-Content ist bzgl. der Performance mit einem Rich-Text vergleichbar oder ggf. sogar besser, da es nicht im Kontext eines Editors geladen werden muss.

Es ist in diesem Fall also nicht von einem Workaround zu sprechen, sondern von einer korrekten Funktion und Anwendung des Formelfelds.

Man kann auch ein Rich-Text Feld nutzen, dessen "Schreibbar wenn" Einstellung auf false gesetzt ist. Damit verhält es sich wie ein statisches Feld. Dies ist für Pages völlig in Ordnung, für Records in Tabellen aber nicht geeignet, da die langen Textinhalte die Datenbank unnötig aufblähen. Da ist eine Formel zu bevorzugen.

Ich verstehe den Wunsch, allerdings ist hier mit zwei fertig implementierten funktionierenden Wegen der Bedarf aus meiner Sicht nicht gegeben.

Hoffe die Optionen sind ausreichend.
Grüße Philipp
- qd_team
  
  vor 2 Tagen
  
  Gemeldet - anzeigen
  Ein Rich-Text-Eingabefeld mit readonly ist hier konzeptionell nicht sinnvoll.
  
  Benötigt wird kein Eingabefeld, sondern ein formatierbarer Anzeige-/Layout-Baustein.
  
  Solche Rich-Text-Labels sind ein typischer UI-Standard in formularbasierten Anwendungen – zur Strukturierung, Erklärung und Nutzerführung.
  
  Der aktuelle HTML-Formel-Ansatz oder read-only-Eingabefeld zeigt genau das Problem von Ninox - das sich durch das gesamte System zieht: Bestehende Elemente werden zweckentfremdet, um einen fehlenden Grundbaustein zu ersetzen.
  
  Gerade in Business-Software sollten native UI-Bausteine vorhanden sein, statt über Eingabefelder oder Formeln simuliert zu werden.
- Pushing the Boundaries of Ninox
  
  Gotje_Ing
  
  gestern
  
  Gemeldet - anzeigen
  Ich verstehe den Wunsch, einen WYSIWYG Editor als UI-Element zu haben. Das ist aus meiner Sicht eine mögliche Erweiterung für Ninox 4.
  
  Aktuell muss ich allerdings hervorheben: Formeln sind hier keine zweckentfremdeten Elemente!
  
  Dieses Argument ist technisch falsch. Es tut mir sehr Leid, wenn ich da etwas harsch rüberkomme, aber das ist einer der Hauptbereiche, in denen Formeln benutzt werden sollten.
  Als Datenfelder sind sie in der Regel ungeeignet, da kaskadierende Berechnungen häufig zu Performance-Problemen führen. Stattdessen ist (halb-) dynamischer bzw. statischer Inhalt, der primär als Anzeige dient, eine extrem sinnvolle Anwendung.
  
  Ich persönlich würde mir viel eher einen Markdown-Editor/Renderer wünschen. Warum? Weil Rich-Text häufig bereits extrem nah an HTML ist und es für mich keinen Sinn macht, nicht direkt in HTML zu schreiben und das zu verwenden.
  Markdown hingegen besitzt einen anderen Stil. Ich kann als Mensch lesbaren Markdown-Code tippen, ohne andauernd irgendwelche <> Elemente zu nutzen oder mich mit irgendwelchen Styling-Button herumzuschlagen. Weiterhin ist Code/Syntax-Highlighting in vielen Fällen deutlich besser, als in Rich-Text. Dieser Code ist dann auf vielen Platformen, ähnliche wie HTML, direkt korrekt gestylt. Außerdem ist es, außerhalb von Microsoft, tatsächlich ein häufiger Stil, den man auch gut kopieren kann. Zu nennen sind da diverse Website-Builder/Frameworks wie Vitepress, Github, Github-Pages, Foren, Discord, Google-Docs und viele weitere.
- qd_team
  
  gestern
  
  Gemeldet - anzeigen
  Danke für die technische Einordnung – die ist nachvollziehbar.
  
  Aus meiner Sicht sprechen wir hier jedoch über zwei klar zu trennende Ebenen: technische Umsetzbarkeit vs. konzeptionelle UI-Bausteine.
  
  Der Feature-Wunsch zielt nicht auf einen Editor zum Schreiben von Inhalten, sondern auf ein dediziertes Anzeige-/Layout-Element für strukturierte, formatierte Texte in Formularen (Überschriften, Hinweise, Abschnitte).
  
  Dass sich dies technisch über Formeln oder read-only Felder abbilden lässt, stelle ich nicht in Frage.
  
  Der Punkt ist: Das sind Implementierungswege, keine passenden UI-Bausteine.
  
  Aus professioneller Software-Sicht sind solche Anzeigeelemente ein gängiger Standard in formularbasierten Business-Anwendungen.
  
  "Low-Code / No-Code" ist dabei kein Gegenargument – auch hier (und gerade hier!) gelten grundlegende UI-, Wartbarkeits- und Strukturprinzipien.
  
  Wenn regelmäßig bestehende Elemente (Formeln, Eingabefelder) zur Kompensation fehlender Grundbausteine verwendet werden müssen, wirkt das langfristig wie gewachsene Komplexität statt sauberer Architektur. Genau diesen Eindruck hinterlässt Ninox aktuell an mehreren Stellen.
  
  Der Wunsch richtet sich daher explizit an den Formular-Editor: 👉 Ein natives, nicht-datenhaltendes, formatierbares Anzeigeelement.
  
  Sollte Ninox 4 diese konzeptionellen Grundlagen nicht professionell und entlang gängiger Software-Standards adressieren, fällt es schwer, von einer nachhaltigen strukturellen Weiterentwicklung auszugehen.
  
  Ich hoffe daher, dass Ninox 4 grundlegend neu gedacht wurde und bei der Umsetzung auf erfahrene Entwickler mit entsprechendem Architektur- und UI-Verständnis gesetzt wird.
- Pushing the Boundaries of Ninox
- Gotje_Ing
- gestern
- Gemeldet - anzeigen
said:
Der Punkt ist: Das sind Implementierungswege, keine passenden UI-Bausteine.
Aus professioneller Software-Sicht sind solche Anzeigeelemente ein gängiger Standard in formularbasierten Business-Anwendungen.

Mir ist keine einzige Software bekannt, die das so macht. Welche sollen das sein?
- qd_team
  
  gestern
  
  Gemeldet - anzeigen
  Ich finde es schade, dass wir hier über etablierte Grundlagen diskutieren müssen. Der Feature-Wunsch betrifft einen ganz normalen UI-Baustein, wie er in vielen Business-Systemen Standard ist.
  
  Um nur "ein paar" zu nennen (egal ob "modern" oder "fast schon legacy"):
  
  Low-Code / Internal Tools ("Ninox Mitbewerber")
  
  Retool
  
  „Text“- / „Rich Text“-Komponenten für strukturierte Anzeige ohne Eingabelogik
  
  UI Bakery
  
  Rich-Text-Blöcke zur Formular- und Seitenstrukturierung ohne Eingabelogik
  
  Microsoft Power Apps (Canvas / „PowerForms“)
  
  Label (reines Anzeigeelement, unterstützt Rich Text / HTML Text)
  
  Knack
  
  Rich Text / Display Fields ohne Eingabelogik
  
  Bubble
  
  Rich-Text-Elemente als reine Anzeige- und Layout-Bausteine
  
  Notion
  
  Vollständig blockbasierte Rich-Text-Anzeigeelemente
  
  ...
  
  Klassische Entwicklungsumgebungen (schwelgen wir mal in Erinnerungen)
  
  Delphi / VCL / FireMonkey
  
  TLabel / TRichEdit / TMemo (auch rein zur Anzeige, ohne Dateneingabe)
  
  Microsoft WinForms / WPF
  
  TextBlock, RichTextBlock, Label (formatierbar, read-only, Anzeigeelemente)
  
  ...
- Pushing the Boundaries of Ninox
  
  Gotje_Ing
  
  gestern
  
  Gemeldet - anzeigen
  Cool, danke für die Liste.

Content aside

gesternZuletzt aktiv
7Antworten
34Ansichten
2 Folge bereits

Willkommen in der Ninox-Community

Feature-Wunsch: Formatierbarer Freitext (Rich-Text-Feld) für Formulare

7 Antworten

Content aside

Übersicht