4. dimensjon læringsgrunnleggende

En av de mest karakteristiske egenskapene til 4D-plattformen er støtten for Custom Menus. Ikke bare kan du bygge dine egne menylinjer, du kan konfigurere 4D til å starte direkte i Custom Menus-modus, noe som gir deg full kontroll over brukerens opplevelse fra det øyeblikket applikasjonen åpnes. Dette er et betydelig avvik fra mange verktøy for rask applikasjonsutvikling (rapid-application-development), der menylinjen i stor grad er fastlåst av rammeverket og du er begrenset til å aktivere eller deaktivere innebygde kommandoer.

Med 4D Custom Menus har du lov til å endre filmenyen og legge til dine egne menyer og menyelementer mellom Rediger- og Hjelp-menyene. Rediger- og Hjelp-menyene er faste — du kan ikke endre dem. Alt annet er ditt å designe.

Viktige takeaways

• 4D Custom Menus lar deg erstatte standardmenylinjen med en du designer, og du kan stille inn applikasjonen til å åpne i Custom Menus-modus for total kontroll.
• Du kan endre filmenyen og sette inn dine egne menyer og elementer mellom Rediger- og Hjelp-menyene, men selve Rediger- og Hjelp-menyene er faste.
• Du kan lage flere forskjellige menylinjer og tilordne hver til en annen situasjon — men overbruk av dette er en rask vei til å forvirre brukerne dine.
• Å sammenligne den planlagte menylinjen med hva etablerte programmer bruker, er en praktisk måte å sjekke designet på før du forplikter deg til det.
• Menydesign er en beslutning om brukeropplevelse like mye som en teknisk; konsistens og forutsigbarhet betyr mer enn smarthet.

Hvorfor Custom Menus er viktige i 4D

I en tradisjonell skrivebordsapplikasjon er menylinjen det primære kartet over hva programmet kan gjøre. Brukere skanner den for å oppdage funksjoner, og de stoler på at den er stabil. Når du leverer en 4D-applikasjon til et bedriftsteam, er menylinjen ofte det første de samhandler med — før noe skjema, liste eller post berøres.

Det gjør menylinjen til en designflate, ikke en ettertanke. 4D anerkjenner dette ved å la utviklere ta fullt eierskap til den. De praktiske konsekvensene er verdt å utdype:

• Du kontrollerer oppdagbarheten. Hvis en funksjon er viktig, kan du plassere den i menyen der brukerne finner den, i stedet for å håpe at de snubler over en knapp.
• Du kontrollerer ordforrådet. Innebygde menyetiketter bruker generiske termer. Dine egendefinerte etiketter kan bruke språket brukerne dine faktisk snakker — «Post faktura» i stedet for «Utfør».
• Du kontrollerer oppstartsopplevelsen. Ved å åpne i Custom Menus-modus forhindrer du brukere i å vandre inn i standard 4D-menyer som avslører interne elementer de aldri skal berøre.
• Du kontrollerer omfanget. Du kan skjule hele funksjonskategorier fra en gitt brukergruppe ganske enkelt ved å ikke legge dem i den gruppens menylinje.

Avveiningen er ansvar. Når du tar over menylinjen, eier du dens konsistens, fullstendighet og vedlikehold etter hvert som applikasjonen vokser.

Hva du kan og ikke kan endre

Å forstå grensene tidlig sparer mye frustrasjon. Reglene er enkle:

Relatert: Claris FileMaker Pro — Den langvarige relasjonsdatabaseplattformen for team som trenger tilpassede apper på skrivebord, nett og mobil fra én enkelt fil..

• Filmeny — kan endres. Du kan omforme den slik at den samsvarer med applikasjonens filrelaterte operasjoner.
• Rediger-meny — fast. Du kan ikke endre den. Dette er bevisst: Rediger-menyen har standard utklippstavle- og redigeringsatferd som brukere forventer skal fungere identisk på tvers av applikasjoner.
• Hjelp-meny — fast. Kan heller ikke endres, av samme grunn — tilgang til hjelp skal være forutsigbar.
• Mellom Rediger og Hjelp — ditt territorium. Det er her dine egne menyer og menyelementer bor.

Designlogikken bak å låse Rediger og Hjelp er sunn og verdt å internalisere som et prinsipp: standard atferd bør forbli standard. Brukere bygger muskelminne rundt klipp ut, kopier, lim inn, angre og tilgang til hjelp. Hvis hver applikasjon omdefinerte disse, ville plattformen føltes kaotisk. 4D beskytter dette grunnlaget og gir deg frihet overalt ellers.

En nyttig mental modell: tenk på menylinjen som å ha en reservert sone (Rediger og Hjelp) og en forfattersone (alt annet). Din jobb er å få forfattersonen til å føles like naturlig og velorganisert som den reserverte sonen.

Utforme menylinjen din: praktisk veiledning

Før du begynner å klikke deg gjennom menyredigeringen, må du bestemme hva applikasjonen din faktisk trenger å eksponere. En menylinje er et hierarki, og hierarkier er lett å gjøre feil med.

Vårt valg: Airtable — Et regneark-enkelt grensesnitt som sitter på toppen av en ekte relasjonsdatabase, med automatiseringer, visninger og delbare grensesnitt..

Start fra brukeroppgaver, ikke fra kodestrukturen din

En vanlig feil er å speile den interne strukturen til databasen — én meny per tabell, ett element per metode. Brukere tenker ikke i tabeller og metoder. De tenker i oppgaver: «legg inn en ny ordre», «finn en kunde», «kjør den månedlige rapporten». Bygg menyen rundt disse oppgavene.

Grupper etter frekvens og risiko

Plasser de mest brukte kommandoene der de er lettest å nå. Plasser destruktive eller irreversible kommandoer (slett, rens, arkiver) unna rutinemessige kommandoer, og vurder å kreve bekreftelse. Menyplassering er en form for feilforebygging.

Hold dybden lav

To nivåer med nøsting (meny $\rightarrow$ element) er behagelig for de fleste brukere. Tre nivåer (meny $\rightarrow$ undermeny $\rightarrow$ element) er tolerabelt når undermenyen faktisk er en kategori. Utover det mister brukerne oversikten over hvor de er. Hvis du finner at du trenger fire nivåer, hører funksjonen sannsynligvis hjemme i et skjema eller en dialogboks i stedet.

Bruk skilletegn og konsekvent rekkefølge

Separatorer grupperer relaterte elementer visuelt. Innenfor en gruppe bør elementene sorteres etter forventet bruksfrekvens eller etter en logisk sekvens (for eksempel rekkefølgen en arbeidsflyt utføres i). Hold denne rekkefølgen stabil på tvers av utgivelser – omorganisering av menyer mellom versjoner er en subtil, men reell kilde til brukerfrustrasjon.

Skriv etiketter som verb eller klare substantiv

“Skriv ut faktura” er tydeligere enn “Fakturautskrift”. “Rapporter” som menytittel er greit; “Rapport” som et element er tvetydig. Følg konvensjonene brukerne dine allerede ser i den andre programvaren de bruker daglig.

Flere menylinjer: Kraft og fare

4D lar deg lage flere forskjellige menylinjer og tilordne hver enkelt til en bestemt situasjon. Dette er virkelig kraftfullt. Typiske legitime bruksområder inkluderer:

Relatert: Microsoft Power Apps — Enterprise-grade lavkode-apputvikling koblet til Microsoft 365, Dataverse og Power Automate..

• Rollebaserte menyer. En dataregistreringsmedarbeider ser en slank meny; en leder ser kommandoer for godkjenning og rapportering.
• Kontekstbaserte menyer. En meny som vises mens en post er åpen, kan avvike fra en som vises på en søkeskjerm.
• Modusbaserte menyer. En “oppsett”- eller “administrasjonsmodus” kan eksponere konfigurasjonskommandoer som vanlig drift skjuler.

Den opprinnelige veiledningen her er verdt å gjenta og understreke: Jeg anbefaler forsiktighet her, siden det kan være veldig lett å forvirre brukeren. Flere menylinjer multipliserer antall tilstander en bruker må holde styr på. Hvis en kommando flyttes eller forsvinner avhengig av kontekst, kan brukere konkludere med at funksjonen er borte i stedet for at den er flyttet.

En praktisk tommelfingerregel:

Situasjon	Anbefalt tilnærming
Ulike brukerroller trenger ulike funksjoner	Separate menylinjer — tydelig og begrunnet
Samme bruker, ulike skjermer	Foretrekk én stabil menylinje; deaktiver elementer i stedet for å fjerne dem
Sjelden brukte administrative oppgaver	En dedikert admin-menylinje, låst med pålogging
Mindre kontekstuelle forskjeller	Behold én menylinje; endre elementstatus, ikke layout

Prinsippet: endre tilgjengelighet, ikke plassering, når du kan. Et grået ut element forteller fortsatt brukeren at funksjonen eksisterer. Et forsvunnet element forteller dem ingenting.

Leserfavoritt: Knack — En databasebygger uten kode rettet mot portaler, kataloger og interne verktøy – med fastpris i stedet for avgifter per bruker..

Sammenligning med etablerte programmer

For å se hva andre programmer bruker for menylinjer, kan det være nyttig å foreta en direkte sammenligning. Dette er en av de mest praktiske vanene en 4D-utvikler kan ta i bruk. Figur 5 i det originale materialet viser en sammenligning av bare menylinjene – en side-ved-side av hvordan forskjellige applikasjoner arrangerer toppnivåmenyene sine.

Verdien av denne øvelsen er at menykonvensjoner i stor grad er arvet, ikke oppfunnet. Tiår med programvare for stasjonære maskiner har konvergert mot en grov konsensus om hva som hører hjemme hvor. Å studere denne konsensusen – i tekstbehandlere, regneark, databaseklienter og regnskapspakker – gir deg en grunnlinje du enten kan følge eller bevisst avvike fra.

Når du sammenligner menylinjer, se etter:

• Antall på toppnivå. De fleste modne applikasjoner lander på et lite antall menyer på øverste nivå. En linje med et dusin oppføringer føles rotete.
• Navnekonvensjoner. Legg merke til hvor konsekvent “Fil”, “Rediger”, “Vis”, “Verktøy” og “Hjelp” brukes, og hvor applikasjoner setter inn sine egne domenespesifikke menyer.
• Plassering av domenespesifikke menyer. Hvor plasserer en vertikal applikasjon sine bransjespesifikke kommandoer? Vanligvis etter standardmenyene og før Hjelp – akkurat den sonen 4D lar stå åpen for deg.
• Elementtetthet. Hvor mange elementer ligger under hver meny, og hvordan er de adskilt?

For bakgrunn om selve konvensjonene er Wikipedia-artiklene om menylinjen og Fil-menyen nyttige referanser for å forstå hvor disse mønstrene kom fra og hvorfor de vedvarer.

Et praktisk eksempel: Menylinje for en liten ordresporingsapp

Anta at du bygger en beskjeden ordresporingsapplikasjon for en liten bedrift. En fornuftig tilpasset menylinje kan se slik ut:

• Fil — Ny ordre, Åpne ordre, Skriv ut, Forhåndsvisning, Avslutt
• Rediger — (fast; beholdes som den er)
• Ordre — Legg inn ordre, Finn ordre, Bokfør ordre, Annuller ordre
• Kunder — Ny kunde, Finn kunde, Kundehistorikk
• Rapporter — Daglig sammendrag, Månedlig sammendrag, Restordrerapport
• Hjelp — (fast; beholdes som den er)

Legg merke til flere bevisste valg. Domenemenyene (Ordre, Kunder, Rapporter) ligger mellom Rediger og Hjelp, akkurat der 4D tillater dem. Destruktive kommandoer (Annuller ordre) er gruppert på slutten av menyen, adskilt fra rutinemessig registrering. Rapporter-menyen er en flat liste i stedet for et nestet hierarki, fordi det bare er tre rapporter. Hvis rapportlisten vokste til femten, ville en undermeny etter kategori vært berettiget.

Vurder nå rollevariasjonen. En lagermedarbeider kan få den samme linjen minus Rapporter-menyen. En leder får hele linjen. Det er en legitim bruk av flere menylinjer. Men hvis medarbeiderens linje også hadde omorganisert elementene under Ordre annerledes enn lederens, ville du skapt forvirring uten noen fordel.

Vanlige fallgruver å unngå

• Eksponering av standard 4D-menyer ved et uhell. Hvis du ikke angir at applikasjonen skal åpnes i modus for egendefinerte menyer (Custom Menus mode), kan brukere nå innebygde menyer som eksponerer funksjonalitet for designmodus. Lås dette ned tidlig.
• Duplisering av kommandoer i flere menyer. Hvis “Skriv ut” vises under både Fil og Rapporter, vil brukerne lure på om de er forskjellige. Velg ett fast sted per kommando.
• Bruk av menyelementer som den eneste veien til en funksjon. Menyer er for oppdagbarhet; ofte brukte handlinger bør også være tilgjengelige fra skjemaer og verktøylinjer.
• Glemte hurtigtaster. Menyelementer uten snarveier tvinger brukeren til å bruke musen. Tilordne konvensjonelle snarveier der slike eksisterer.
• Å aldri revurdere designet. Menylinjer samler opp overflødige elementer. Se gjennom din menylinje ved hver utgivelse og fjern det som ikke lenger brukes.

Hvordan dette passer inn i den bredere 4D-læringsveien

Egendefinerte menyer ligger side om side med flere andre grunnleggende 4D-ferdigheter som dekkes i denne serien: forståelse av definisjoner og terminologi, sammenligning av 4Ds menyer med menyene i FileMaker Pro, utforming av Fil-menyen spesifikt, og bygging av en egendefinert splash-skjerm. Sammen danner disse presentasjonslaget til en 4D-applikasjon – delene en bruker ser før de i det hele tatt berører datamodellen din.

Den røde tråden er kontroll. 4D gir deg en uvanlig grad av kontroll over det brukervendte skallet til applikasjonen din. Egendefinerte menyer er et av de tydeligste uttrykkene for denne filosofien, og å mestre dem tidlig gir utbytte etter hvert som applikasjonen din vokser i omfang og publikum.

Vanlige spørsmål

Kan jeg endre Rediger- og Hjelp-menyene i 4D?

Nei. Rediger- og Hjelp-menyene er faste og kan ikke endres. Dette er tilsiktet, fordi disse menyene har standardatferd – utklippstavleoperasjoner, angre og tilgang til hjelp – som brukere forventer skal være konsekvent på tvers av applikasjoner. Tilpasningen din skjer i Fil-menyen og i rommet mellom Rediger og Hjelp.

Hvor vises mine egendefinerte menyer og menyelementer?

Dine egne menyer og menyelementer settes inn mellom Rediger- og Hjelp-menyene. Dette er forfattersonen 4D reserverer for utviklere. Fil-menyen kan også endres, mens Rediger og Hjelp ikke kan det.

Bør jeg lage flere menylinjer for applikasjonen min?

Bare når forskjellen er virkelig begrunnet – vanligvis for ulike brukerroller eller en administrativ modus. Flere menylinjer øker antallet tilstander en bruker må holde styr på, og det er veldig lett å forvirre folk. Når du er i tvil, behold én menylinje og endre elementtilgjengelighet i stedet for layout.

Hva gjør egentlig “åpning i modus for egendefinerte menyer”?

Det forteller 4D at den skal starte applikasjonen din ved å bruke din egendefinerte menylinje i stedet for standard 4D-menyene. Dette gir deg full kontroll over programmets brukervendte skall og hindrer brukere i å nå innebygde menyer som eksponerer interne funksjoner de ikke skal se.

Hvordan vet jeg om utformingen av menylinjen min er god?

Sammenlign den direkte med etablerte programmer. Menykonvensjoner er i stor grad arvet snarere enn oppfunnet, så å studere hvordan tekstbehandlere, regneark og databaseklienter ordner toppnivåmenyene sine gir deg en pålitelig grunnlinje. Se på antall toppnivåmenyer, navngiving, plassering av domenespesifikke menyer og elementtetthet.

Er det et problem hvis et menyelement forsvinner i noen sammenhenger?

Det kan det være. Et grået-ut element forteller fortsatt brukeren at funksjonen eksisterer; et forsvunnet element forteller dem ingenting og kan få dem til å tro at funksjonen ble fjernet. Foretrekk å endre tilgjengelighet fremfor å endre plassering når du kan.