Basisprincipes van 4th Dimension Learning
Dit wijkt aanzienlijk af van veel tools voor snelle applicatieontwikkeling, waarbij de menubalk grotendeels wordt bepaald door het raamwerk en u beperkt bent tot het in- of uitschakelen van ingebouwde opdrachten.
Met aangepaste 4D-menu’s kunt u het menu Bestand wijzigen en uw eigen menu’s en menu-items toevoegen tussen de menu’s Bewerken en Help. De menu’s Bewerken en Help staan vast — u kunt ze niet wijzigen. Al het andere is aan u om te ontwerpen.
Belangrijkste punten
- Met 4D Aangepaste menu’s kunt u de standaardmenubalk vervangen door een menubalk die u zelf ontwerpt, en u kunt instellen dat de applicatie wordt geopend in de modus Aangepaste menu’s voor totale controle.
- U kunt het menu Bestand wijzigen en uw eigen menu’s en items invoegen tussen de menu’s Bewerken en Help, maar de menu’s Bewerken en Help zelf staan vast.
- U kunt meerdere, verschillende menubalken maken en elke menubalk aan een andere situatie toewijzen — maar overmatig gebruik hiervan is een snelle weg naar verwarring voor uw gebruikers.
- Het vergelijken van uw geplande menubalk met wat gevestigde programma’s gebruiken, is een praktische manier om uw ontwerp te controleren voordat u zich eraan vastlegt.
- Menuontwerp is evenzeer een beslissing op het gebied van de gebruikerservaring als een technische beslissing; consistentie en voorspelbaarheid zijn belangrijker dan slimheid.
Waarom aangepaste menu’s belangrijk zijn in 4D
In een traditionele desktopapplicatie is de menubalk de primaire kaart van wat het programma kan doen. Gebruikers scannen deze om functies te ontdekken en vertrouwen erop dat deze stabiel is. Wanneer u een 4D-applicatie naar een bedrijfsteam levert, is de menubalk vaak het eerste waarmee ze communiceren — voordat er een formulier, lijst of record wordt aangeraakt.
Dat maakt de menubalk tot een ontwerpoppervlak, niet tot een bijzaak. 4D erkent dit door ontwikkelaars de volledige eigendom ervan te geven. De praktische gevolgen zijn het vermelden waard:
- U bepaalt de vindbaarheid. Als een functie belangrijk is, kunt u deze in het menu plaatsen waar gebruikers deze zullen vinden, in plaats van te hopen dat ze toevallig op een knop stuiten.
- U bepaalt de woordenschat. Ingebouwde menulabels gebruiken algemene termen. Uw aangepaste labels kunnen de taal gebruiken die uw gebruikers daadwerkelijk spreken — “Factuur plaatsen” in plaats van “Uitvoeren”.
- U bepaalt de opstartervaring. Door te openen in de modus Aangepaste menu’s voorkomt u dat gebruikers afdwalen naar standaard 4D-menu’s die interne onderdelen blootleggen die ze nooit mogen aanraken.
- U bepaalt de reikwijdte. U kunt hele categorieën functionaliteit voor een bepaalde gebruikersgroep verbergen door ze simpelweg niet in de menubalk van die groep te plaatsen.
De tegenprestatie is verantwoordelijkheid. Zodra u de menubalk overneemt, bent u verantwoordelijk voor de consistentie, de volledigheid en het onderhoud ervan naarmate de applicatie groeit.
Wat u wel en niet kunt veranderen
Het vroegtijdig begrijpen van de grenzen bespaart een hoop frustratie. De regels zijn eenvoudig:
Gerelateerd: — Het langlopende relationele databaseplatform voor teams die aangepaste apps nodig hebben op desktop, internet en mobiel vanuit één bestand..
- Menu Bestand — aanpasbaar. U kunt de vorm ervan aanpassen aan de bestandsgerelateerde bewerkingen van uw applicatie.
- Menu Bewerken — vast. U kunt dit niet wijzigen. Dit is opzettelijk: het menu Bewerken bevat standaard klembord- en bewerkingsgedrag waarvan gebruikers verwachten dat dit in alle applicaties identiek werkt.
- Menu Help — vast. Ook niet aanpasbaar, om dezelfde reden — de toegang tot help moet voorspelbaar zijn.
- Tussen Bewerken en Help — uw territorium. Hier bevinden zich uw eigen menu’s en menu-items.
De ontwerplogica achter het vastzetten van Bewerken en Help is degelijk en de moeite waard om als principe te internaliseren: standaardgedrag moet standaard blijven. Gebruikers bouwen een spiergeheugen op rond knippen, kopiëren, plakken, ongedaan maken en de toegang tot help. Als elke applicatie deze opnieuw zou definiëren, zou het platform chaotisch aanvoelen. 4D beschermt die basislijn en geeft u overal anders vrijheid.
Een handig mentaal model: beschouw de menubalk als een gereserveerde zone (Bewerken en Help) en een auteurzone (al het andere). Uw taak is om ervoor te zorgen dat de auteurzone net zo vanzelfsprekend en goed georganiseerd aanvoelt als de gereserveerde zone.
Uw menubalk ontwerpen: praktische begeleiding
Voordat u in de menu-editor begint te klikken, moet u beslissen wat uw applicatie daadwerkelijk moet weergeven. Een menubalk is een hiërarchie, en in hiërarchieën gaat het gemakkelijk mis.
Onze keuze: — Een spreadsheet-eenvoudige interface bovenop een echte relationele database, met automatiseringen, weergaven en deelbare interfaces..
Begin vanuit gebruikerstaken, niet vanuit uw codestructuur
Een veelgemaakte fout is het spiegelen van de interne structuur van de database — één menu per tabel, één item per methode. Gebruikers denken niet in tabellen en methoden. Ze denken in taken: “een nieuwe bestelling invoeren”, “een klant zoeken”, “het maandrapport uitvoeren”. Bouw het menu rond deze taken.
Groepeer op frequentie en op risico
Plaats de meest gebruikte opdrachten waar ze het gemakkelijkst te bereiken zijn. Plaats destructieve of onomkeerbare opdrachten (verwijderen, opschonen, archiveren) uit de buurt van routinematige opdrachten, en overweeg om een bevestiging te vereisen. Menuplaatsing is een vorm van foutpreventie.
Houd de diepte beperkt
Twee nestingniveaus (menu $\rightarrow$ item) zijn voor de meeste gebruikers comfortabel. Drie niveaus (menu $\rightarrow$ submenu $\rightarrow$ item) zijn acceptabel wanneer het submenu echt een categorie is. Daarboven verliezen gebruikers het overzicht van waar ze zich bevinden. Als u merkt dat u vier niveaus nodig heeft, hoort de functie waarschijnlijk in een formulier of een dialoogvenster thuis.
Gebruik scheidingstekens en een consistente volgorde
Scheidingstekens groeperen gerelateerde items visueel. Binnen een groep kunt u items ordenen op verwachte frequentie of op logische volgorde (bijvoorbeeld de volgorde waarin een workflow wordt uitgevoerd). Houd die volgorde stabiel over releases heen — het opnieuw ordenen van menu’s tussen versies is een subtiele maar reële bron van gebruikersfrustratie.
Schrijf labels als werkwoorden of duidelijke zelfstandige naamwoorden
“Factuur afdrukken” is duidelijker dan “Factuur printen”. “Rapporten” als menutitel is prima; “Rapport” als item is dubbelzinnig. Sluit aan bij de conventies die uw gebruikers al zien in de andere software die ze dagelijks gebruiken.
Meerdere menubalken: kracht en gevaar
4D stelt u in staat om meerdere, verschillende menubalken te maken en elk aan een andere situatie toe te wijzen. Dit is echt krachtig. Typisch legitieme toepassingen zijn onder meer:
- Op rollen gebaseerde menu’s. Een medewerker die gegevens invoert, ziet een beknopt menu; een supervisor ziet goedkeurings- en rapportagecommando’s.
- Contextgebaseerde menu’s. Een menu dat wordt weergegeven terwijl een record geopend is, kan verschillen van een menu op een zoekscherm.
- Op modus gebaseerde menu’s. Een “setup”- of “administratie”-modus kan configuratiecommando’s blootleggen die bij normaal gebruik verborgen blijven.
De oorspronkelijke richtlijnen hier zijn de moeite waard om te herhalen en te benadrukken: Ik raad aan om hier voorzichtig te zijn, omdat het heel gemakkelijk kan zijn om de gebruiker in verwarring te brengen. Meerdere menubalken vermenigvuldigen het aantal statussen dat een gebruiker moet bijhouden. Als een commando verplaatst of verdwijnt afhankelijk van de context, kunnen gebruikers concluderen dat de functie weg is in plaats van verplaatst.
Een praktische vuistregel:
| Situatie | Aanbevolen aanpak |
|---|---|
| Verschillende gebruikersrollen hebben verschillende mogelijkheden nodig | Aparte menubalken — duidelijk en gerechtvaardigd |
| Dezelfde gebruiker, verschillende schermen | Geef de voorkeur aan één stabiele menubalk; items uitschakelen in plaats van verwijderen |
| Zelden gebruikte administratieve taken | Een speciale beheerdersmenubalk, afgeschermd door login |
| Kleine contextuele verschillen | Houd één menubalk; wijzig de itemstatus, niet de lay-out |
Het principe: wijzig de beschikbaarheid, niet de locatie, wanneer dat kan. Een grijs item vertelt de gebruiker nog steeds dat de functie bestaat. Een verdwenen item vertelt hen niets.
Vergelijken met gevestigde programma’s
Om te zien wat andere programma’s voor menubalken gebruiken, kan het nuttig zijn om een directe vergelijking te maken. Dit is een van de meest praktische gewoonten die een 4D-ontwikkelaar kan aannemen. Figuur 5 in het originele materiaal toont een vergelijking van alleen de menubalken — een zij-aan-zij weergave van hoe verschillende applicaties hun menu’s op het hoogste niveau rangschikken.
De waarde van deze oefening is dat menuconventies grotendeels worden geërfd, niet uitgevonden. Decennia aan desktopsoftware zijn samengekomen in een ruwe consensus over wat waar hoort. Het bestuderen van die consensus — in tekstverwerkers, spreadsheets, databaseclients en boekhoudpakketten — geeft u een basislijn die u kunt volgen of waar u bewust van kunt afwijken.
Wanneer u menubalken vergelijkt, let dan op:
- Aantal op het hoogste niveau. De meeste volwassen applicaties steken op een klein aantal menu’s op het hoogste niveau. Een balk met een dozijn vermeldingen voelt rommelig aan.
- Naamgevingsconventies. Merk op hoe consistent “Bestand”, “Bewerken”, “Beeld”, “Extra” en “Help” worden gebruikt, en waar applicaties hun eigen domeinmenu’s invoegen.
- Plaatsing van domeinspecifieke menu’s. Waar plaatst een verticale applicatie zijn branchespecifieke commando’s? Meestal na de standaardmenu’s en vóór Help — precies de zone die 4D voor u openlaat.
- Itemdichtheid. Hoeveel items bevinden zich onder elk menu, en hoe zijn ze gescheiden?
Voor achtergrondinformatie over de conventies zelf zijn het Wikipedia-artikel over de menu bar en het File menu nuttige referenties om te begrijpen waar deze patronen vandaan komen en waarom ze blijven bestaan.
Een uitgewerkt voorbeeld: menubalk voor een kleine app voor ordertracking
Stel dat u een bescheiden applicatie voor het volgen van bestellingen bouwt voor een klein bedrijf. Een verstandige aangepaste menubalk zou er als volgt uit kunnen zien:
- Bestand — Nieuwe bestelling, Open bestelling, Afdrukken, Afdrukvoorbeeld, Afsluiten
- Bewerken — (vast; ongewijzigd gelaten)
- Bestellingen — Bestelling invoeren, Bestelling zoeken, Bestelling plaatsen, Bestelling annuleren
- Klanten — Nieuwe klant, Klant zoeken, Klantgeschiedenis
- Rapporten — Dagelijks overzicht, Maandoverzicht, Naleveringsrapport
- Help — (vast; ongewijzigd gelaten)
Let op een aantal bewuste keuzes. De domeinmenu’s (Bestellingen, Klanten, Rapporten) bevinden zich tussen Bewerken en Help, precies waar 4D dit toestaat. Destructieve commando’s (Bestelling annuleren) zijn gegroepeerd aan het einde van hun menu, gescheiden van de routine-invoer.
Het menu Rapporten is een platte lijst in plaats van een geneste hiërarchie, omdat er slechts drie rapporten zijn. Als de lijst met rapporten zou uitgroeien tot vijftien, zou een submenu per categorie gerechtvaardigd worden.
Beschouw nu de rolvariatie. Een magazijnmedewerker krijgt mogelijk dezelfde balk minus het menu Rapporten. Een manager krijgt de volledige balk. Dat is een legitiem gebruik van meerdere menubalken. Maar als de balk van de medewerker de items onder Bestellingen ook anders zou rangschikken dan die van de manager, zou u verwarring creëren zonder enig voordeel.
Veelvoorkomende valkuilen die u moet vermijden
- Per ongeluk standaard 4D-menu’s zichtbaar maken. Als u de applicatie niet instelt om te openen in de modus Aangepaste menu’s, kunnen gebruikers ingebouwde menu’s bereiken die functionaliteit van de ontwerpmodus blootleggen. Sluit dit vroegtijdig af.
- Opdrachten dupliceren in meerdere menu’s. Als “Afdrukken” verschijnt onder zowel Bestand als Rapporten, vragen gebruikers zich af of ze verschillen. Kies één vaste plek per opdracht.
- Menu-items gebruiken als het enige pad naar een functie. Menu’s zijn bedoeld voor vindbaarheid; veelgebruikte acties moeten ook bereikbaar zijn via formulieren en werkbalken.
- Sneltoetsen vergeten. Menu-items zonder sneltoetsen dwingen het gebruik van de muis af. Wijs conventionele sneltoetsen toe waar deze bestaan.
- Het ontwerp nooit meer herzien. Menubalken hopen ballast op. Controleer de uwe bij elke release en verwijder wat niet langer wordt gebruikt.
Hoe dit past in het bredere 4D-leerpad
Aangepaste menu’s staan naast een aantal andere fundamentele 4D-vaardigheden die in deze serie worden behandeld: het begrijpen van definities en terminologie, het vergelijken van de 4D-menu’s met die van FileMaker Pro, het specifiek vormgeven van het Bestand-menu en het bouwen van een aangepast opstartscherm. Samen vormen deze de presentatielaag van een 4D-applicatie — de onderdelen die een gebruiker ziet voordat hij ooit uw datamodel aanraakt.
De rode draad is controle. 4D geeft u een ongebruikelijke mate van controle over de gebruikersgerichte schil van uw applicatie. Aangepaste menu’s zijn een van de duidelijkste uitdrukkingen van die filosofie, en als u ze in een vroeg stadium onder de knie krijgt, levert dat voordeel op naarmate uw applicatie in reikwijdte en publiek groeit.
Veelgestelde vragen
Kan ik de menu’s Bewerken en Help in 4D wijzigen?
Nee. De menu’s Bewerken en Help staan vast en kunnen niet worden gewijzigd. Dit is opzettelijk, omdat deze menu’s standaardgedragingen bevatten — klembordbewerkingen, ongedaan maken en toegang tot help — waarvan gebruikers verwachten dat ze consistent blijven over verschillende applicaties heen. Uw aanpassingen vinden plaats in het menu Bestand en in de ruimte tussen Bewerken en Help.
Waar verschijnen mijn aangepaste menu’s en menu-items?
Uw eigen menu’s en menu-items worden ingevoegd tussen de menu’s Bewerken en Help. Dit is de auteurszone die 4D reserveert voor ontwikkelaars. Het menu Bestand is ook aanpasbaar, terwijl Bewerken en Help dat niet zijn.
Moet ik meerdere menubalken maken voor mijn applicatie?
Alleen als het verschil echt gerechtvaardigd is — meestal voor verschillende gebruikersrollen of een administratieve modus. Meerdere menubalken vermenigvuldigen de statussen die een gebruiker moet bijhouden, en het is heel gemakkelijk om mensen in verwarring te brengen. Houd bij twijfel één menubalk aan en wijzig de beschikbaarheid van items in plaats van de lay-out.
Wat doet “openen in de modus Aangepaste menu’s” eigenlijk?
Het vertelt 4D om uw applicatie te starten met behulp van uw aangepaste menubalk in plaats van de standaard 4D-menu’s. Dit geeft u volledige controle over de gebruikersgerichte schil van het programma en voorkomt dat gebruikers ingebouwde menu’s bereiken die interne zaken blootleggen die ze niet zouden moeten zien.
Hoe weet ik of mijn menubalkontwerp goed is?
Vergelijk het rechtstreeks met gevestigde programma’s. Menuconventies worden grotendeels overgenomen in plaats van uitgevonden, dus door te bestuderen hoe tekstverwerkers, spreadsheets en databaseclients hun hoofdmenu’s rangschikken, krijgt u een betrouwbare basislijn. Kijk naar het aantal hoofdmenu’s, de naamgeving, de plaatsing van domeinspecifieke menu’s en de itemdichtheid.
Is het een probleem als een menu-item in bepaalde contexten verdwijnt?
Dat kan. Een grijs item vertelt de gebruiker nog steeds dat de functie bestaat; een verdwenen item vertelt hen niets en kan ertoe leiden dat ze denken dat de functie is verwijderd. Geef de voorkeur aan het wijzigen van de beschikbaarheid boven het wijzigen van de locatie waar dat mogelijk is.
Veelgestelde vragen
Kan ik de menu's Bewerken en Help in 4D wijzigen?
Nee. De menu's Bewerken en Help staan vast en kunnen niet worden gewijzigd. Dit is opzettelijk, omdat deze menu's standaardgedrag vertonen (klembordbewerkingen, ongedaan maken en hulptoegang) waarvan gebruikers verwachten dat ze consistent blijven in alle applicaties. Uw aanpassing gebeurt in het menu Bestand en in de ruimte tussen Bewerken en Help.
Waar worden mijn aangepaste menu's en menu-items weergegeven?
Uw eigen menu's en menu-items worden ingevoegd tussen de menu's Bewerken en Help. Dit is de auteurszone die 4D reserveert voor ontwikkelaars. Het menu Bestand kan ook worden gewijzigd, terwijl Bewerken en Help dat niet zijn.
Moet ik meerdere menubalken maken voor mijn toepassing?
Alleen als het verschil echt gerechtvaardigd is – meestal voor verschillende gebruikersrollen of een administratieve modus. Meerdere menubalken vermenigvuldigen de statussen die een gebruiker moet volgen, en het is heel gemakkelijk om mensen in verwarring te brengen. Houd bij twijfel één menubalk aan en wijzig de beschikbaarheid van items in plaats van de lay-out.
Wat doet 'openen in de modus Aangepaste menu's' eigenlijk?
Het vertelt 4D om uw applicatie te starten met behulp van uw aangepaste menubalk in plaats van de standaard 4D-menu's. Dit geeft u volledige controle over de gebruikersgerichte shell van het programma en voorkomt dat gebruikers ingebouwde menu's bereiken die interne onderdelen blootleggen die ze niet zouden moeten zien.
Hoe weet ik of mijn menubalkontwerp goed is?
Vergelijk het rechtstreeks met gevestigde programma's. Menuconventies worden grotendeels geërfd in plaats van uitgevonden, dus door te bestuderen hoe tekstverwerkers, spreadsheets en databaseclients hun menu's op het hoogste niveau rangschikken, krijgt u een betrouwbare basislijn. Kijk naar het aantal op het hoogste niveau, de naamgeving, de plaatsing van domeinspecifieke menu's en de itemdichtheid.
Is het een probleem als een menu-item in bepaalde contexten verdwijnt?
Het kan zijn. Een grijs item vertelt de gebruiker nog steeds dat de functie bestaat; een verdwenen item vertelt hen niets en kan ertoe leiden dat ze denken dat de functie is verwijderd. Geef de voorkeur aan wisselende beschikbaarheid boven wisselen van locatie wanneer je maar kunt.
Bouw in één dag een klantenportaal
Een databasebouwer zonder code, gericht op portals, directory's en interne tools, met vaste prijzen in plaats van kosten per gebruiker.