4. dimension læringsgrundlag
Denne side er en del af 4th Dimension Learning Basics-serien, som leder udviklere gennem 4D-platformen ud fra grundlæggende principper. Emnet her er menuer – specifikt hvordan menusystemerne i FileMaker Pro (FMP) og 4D adskiller sig, og hvorfor den forskel har betydning, når du migrerer en mental model fra det ene værktøj til det andet. Menuer er noget af det første, en ny 4D-udvikler bemærker, fordi 4D opdeler det, FileMaker behandler som en enkelt overflade, i flere forskellige miljøer.
Key Takeaways
- FileMaker Pros Browse-tilstand præsenterer én menulinje med ét sæt menuer og menupunkter; 4D adskiller User-miljøet fra Custom Menus-miljøet, og de to opfører sig forskelligt.
- 4D User-miljøet er et testrum for udviklere, ikke det sted, dine slutbrugere normalt befinder sig. Design ikke din produktionsmenu-oplevelse omkring det.
- Foundation er en 4D-strukturfil, der er forudindlæst med metoder og formularer, du kan kopiere og indsætte – en genvej, når du først forstår det grundlæggende, ikke en erstatning for det.
- Menudesign i 4D er en bevidst, strukturel beslutning. Du bestemmer, hvad brugeren ser; du arver ikke en fast programmenulinje, som du i vid udstrækning gør i FileMaker.
- At forstå miljømodellen først forhindrer den mest almindelige begynderfejl: at bygge og teste menuer i det forkerte miljø og derefter undre sig over, hvorfor brugerne ser noget andet.
Hvorfor menuer er den første virkelige divergens
Når du flytter fra FileMaker Pro til 4D, overføres databasekoncepterne rimeligt godt. Tabeller, felter, poster, layouts og formularer har alle genkendelige modstykker. Menuer er der, hvor de to platforme skiller sig fra hinanden på en måde, der tvinger dig til at tænke anderledes om applikationen som helhed.
I FileMaker er menulinjen i det væsentlige applikationens menulinje. Du får File, Edit, View, Insert, Format, Records, Scripts, Window og Help, og din opgave er for det meste at undertrykke eller supplere det, der allerede er der. Du arbejder inden for en fast ramme.
I 4D er menulinjen noget, du konstruerer. Platformen giver dig miljøer, og hvert miljø kan præsentere sin egen menulinje. Det betyder, at menuen ikke er givet – den er et resultat af dit design. Dette kræver mere arbejde up front og giver betydeligt mere kontrol senere, hvilket er præcis den afvejning, der definerer 4D som en udviklingsplatform snarere end et skabelondrevet værktøj.
FMP Browse Mode-menuer
I FMP Browse-tilstand er der kun én menulinje og ét sæt menuer og menupunkter. Denne enkelte linje betjener hele browser-oplevelsen. Figur 2 i det originale materiale viser FMP-menulinjen med “File”- og “Edit”-menuerne synlige.
Den praktiske konsekvens er enkelhed. En FileMaker-udvikler, der lærer platformen, behøver ikke at spørge “hvilken menulinje ser jeg på?” Der er kun én. Tilpasning sker ved at fjerne elementer, du ikke ønsker, at brugerne skal have adgang til, og tilføje script-triggers bag dem, du beholder.
Relateret: — En regneark-simpel grænseflade, der sidder oven på en rigtig relationel database, med automatiseringer, visninger og delbare grænseflader..
Dette er virkelig praktisk, og det er værd at anerkende frem for at afvise. Til små enkeltformålsløsninger bringer FileMaker-modellen dig hurtigere til en brugbar grænseflade. Prisen er, at du altid skal forhandle med en menulinje, der er designet til en generel applikation, ikke til din specifikke virksomhedsapp.
4D User Environment-menuer
I 4D er der en standard menulinje for User-miljøet. Det kritiske at internalisere er dette: User-miljøet er normalt ikke der, hvor brugerne vil være. User-miljøet er der, hvor udvikleren tester det, der er blevet udviklet. Normalt vil slutbrugeren aldrig se User-miljøet.
Figur 3 i det originale materiale viser 4D User-menulinjen og dens menuer.
Hvis du handler: — En lavkode-appbygger, der tilsluttes den bredere Zoho-suite og priser pr. bruger i stedet for pr. app..
Tænk på User-miljøet som et værksted, ikke et showroom. Det giver dig et forudsigeligt standard-menusæt, så du kan navigere i din struktur, køre metoder, inspicere data og verificere adfærd under udvikling. Fordi det er standardiseret, er det stabilt – du kan stole på, at det ikke ændrer sig under dig, mens du arbejder.
Begynderfælden er subtil og almindelig: du bygger en formular, tester den i User-miljøet, alt fungerer, og du udgiver. Så åbner en bruger applikationen i det implementerede brugerdefinerede miljø, og menuerne er anderledes, nogle elementer mangler, og en arbejdsgang, der afhang af et menupunkt, du brugte under testen, er der simpelthen ikke. Løsningen er ikke teknisk – den består i at teste i det miljø, dine brugere rent faktisk vil bruge.
Sådan beslutter du, hvor du skal teste
- Under strukturudvikling — arbejd i User-miljøet. Det er hurtigt og forudsigeligt.
- Før enhver udgivelse — gå gennem alle brugervendte arbejdsgange i det implementerede brugerdefinerede menumiljø, ikke i User-miljøet.
- Når et menupunkt “forsvinder” — tjek først, hvilket miljø du befinder dig i, før du fejlfinder selve menudefinitionen.
4D Foundation Default Custom Menus Environment
Foundation er en skal. Det er en 4D-strukturfil, der har en lang række metoder og formularer defineret for dig. Du kan blot kopiere og indsætte disse metoder og formularer. Når du har mestret det grundlæggende i 4D, giver Foundation en hurtig vej til at få dit program udviklet.
Figur 4 i det originale materiale viser Foundations standard brugerdefinerede menulinje og dens menuer.
Foundation forstås bedst som en referenceimplementering og en “reservedelsbeholder” snarere end et framework, man adopterer wholesale. Værdien ligger i de konkrete, fungerende eksempler: du kan se, hvordan en brugerdefineret menulinje faktisk er samlet, hvordan menupunkter er forbundet til metoder, og hvordan delene passer sammen i en rigtig strukturfil. At kopiere en fungerende menu og modificere den lærer dig modellen hurtigere end at læse om den.
To forbehold, der er værd at nævne klart:
- Copy-paste medfører bagage. Metoder og formularer hentet fra Foundation kan referere til andre objekter, tabeller eller navngivningskonventioner, der ikke findes i din struktur. Forvent at skulle spore afhængigheder frem for at antage, at det er en ren “drop-in”.
- Foundation afspejler sin æra. Det blev bygget til at demonstrere 4D-koncepter, og dets konventioner matcher muligvis ikke moderne 4D-praksis. Betragt det som et undervisningshjælpemiddel og en kilde til mønstre, ikke som en stilguide.
Sammenligning af de tre menukontekster
Den klareste måde at holde disse tre miljøer i hovedet på er side om side.
| Kontekst | Hvem bruger det | Menulinjens adfærd | Primært formål |
|---|---|---|---|
| FMP Browse-tilstand | Slutbruger | Én fast menulinje og et fast sæt punkter | Kør løsningen som leveret |
| 4D User-miljø | Udvikler | Standard, forudsigelig menulinje | Test og inspicer under udvikling |
| 4D Custom Menus-miljø | Slutbruger | Menulinje, som du definerer | Lever produktionsoplevelsen |
| 4D Foundation | Udvikler (læring) | Forudbyggede standard brugerdefinerede menuer | Lær mønstre; kopier metoder og formularer |
Den række, der betyder mest for en ny 4D-udvikler, er den tredje. Alt i FMP-kolonnen kollapser til en enkelt overflade; i 4D deles det op i en udvikleroverflade og en brugeroverflade, og du ejer brugeroverfladen fuldstændigt.
Praktisk vejledning til menudesign i 4D
Fordi du bygger menuen frem for at arve den, opstår der tidligt et par beslutninger, som er værd at tage bevidst.
Start fra brugerens opgaveliste, ikke fra standardmenunavnene. FileMaker træner dig i at tænke i termer som Fil, Rediger, Poster. I 4D er du fri til at organisere omkring det, dine brugere rent faktisk gør — “Ordrer”, “Kunder”, “Rapporter” — og det er normalt en bedre menu end en generisk en.
Beslut, hvad der hører til i en menu versus på en formular. Menupunkter er globale og altid tilgængelige; knapper på en formular er kontekstuelle. En destruktiv handling som “Slet alle poster” er sikrere på en formular, hvor du kan styre adgangen, end i en menu, hvor et fejlklik kan ramme den fra hvor som helst.
Hold udvikleroverfladen og brugeroverfladen mentalt adskilt. User-miljøets standardmenulinje er et værktøj. Lad ikke dens bekvemmelighed sive ind i dine designbeslutninger om produktionsmenuen.
Brug Foundation til at lære forbindelserne, og byg derefter din egen. Den hurtigste vej er at kopiere én Foundation-menu, forstå hver eneste forbindelse i den, og derefter genopbygge den fra bunden til din applikation. Det er ved genopbygningen, at læringen sidder fast.
Test i målmiljøet før hver udgivelse. Denne ene vane forhindrer den mest almindelige klasse af “det virkede for mig”-menubugs.
Hvor dette passer ind i læringsstien
Denne side ligger tidligt i serien, i afsnittet, der sammenligner standardmenuer mellem FMP og 4D. De naturlige næste skridt er de detaljerede menusammenligninger, der følger — sammenligninger af filmenuen, forslag til filmenuen, andre menusammenligninger, forslag til postmenuen og den brugerdefinerede splash-skærm. Hver af disse tager et udsnit af menuoverfladen og gennemgår detaljerne.
Grunden til, at miljømodellen kommer først, er, at enhver senere menubeslutning afhænger af den. Hvis du ikke ved, hvilket miljø du designer til, har de specifikke råd om menupunkter, der følger, intet anker. Få styr på miljøerne, og resten af menumaterialet vil fremstå som et sæt konkrete valg snarere end en liste over fakta.
For en bredere baggrund om selve platformen giver Wikipedia-artiklen om 4th Dimension nyttig kontekst om dens historie og positionering, og artiklen om FileMaker dækker den platform, som denne sammenligning drages mod. For generelle principper, der gælder for begge værktøjer, publicerer Nielsen Norman Group bredt respekteret forskning om menudesign og navigation, og W3C vedligeholder tilgængelighedsvejledning, som er værd at konsultere, når du beslutter, hvordan brugerne skal få adgang til kernefunktioner.
Ofte stillede spørgsmål
Hvorfor har 4D et separat User-miljø, hvis brugerne aldrig ser det?
User-miljøet eksisterer, så udviklere har et stabilt, standardiseret sted at teste og inspicere deres arbejde. Fordi dets menulinje er fast, flytter den sig ikke under dig, mens du udvikler. Slutbrugeren arbejder normalt i et brugerdefineret miljø, hvor du styrer menulinjen. Ved at holde de to adskilt kan din testoverflade og din leveringsoverflade hver især optimeres til deres forskellige formål.
Kan menulinjen i 4D User-miljøet tilpasses?
Det er en standardmenulinje leveret af platformen, og hensigten er, at den forbliver standard, så den fortsat er en pålidelig udviklingsoverflade. Din tilpasningsindsats hører hjemme i det brugerdefinerede menumiljø, som dine brugere rent faktisk vil se. Betragt User-miljøets menulinje som et værktøj, du bruger, ikke som et leveranceprodukt, du designer.
Hvad er Foundation helt præcist, og skal jeg bygge min app på det?
Foundation er en 4D-strukturfil — en skal — der indeholder et stort antal forudbyggede metoder og formularer, som du kan kopiere og indsætte i dit eget arbejde. Det er en genvej, når du først har styr på det grundlæggende i 4D. Den bruges bedst som en kilde til arbejdseksempler og mønstre snarere end som et fundament, du adopterer i sin helhed, fordi kopierede objekter kan medbringe afhængigheder og konventioner, der ikke passer til din struktur.
Hvorfor fungerede mit menupunkt under testning, men ikke for brugeren?
Næsten altid fordi du har testet i bruger-miljøet, og brugeren kører i et brugerdefineret menumiljø. De to har forskellige menulinjer, så et element, der er tilgængeligt for dig under udviklingen, findes muligvis ikke i den implementerede menu. Før du fejlfinder menudefinitionen, skal du bekræfte, hvilket miljø du befinder dig i.
Skal jeg genopbygge FileMaker-menustrukturen i 4D?
Nej, og det bør du generelt ikke. FileMakers Fil/Rediger/Post-organisering eksisterer, fordi FileMaker præsenterer en generel applikationsmenulinje. I 4D konstruerer du selv menuen, så du kan organisere den omkring dine brugeres faktiske opgaver i stedet for at spejle en generisk struktur. Brug FileMaker-layoutet som et referencepunkt for, hvilke funktioner du har brug for, ikke som en skabelon til, hvordan de skal arrangeres.
Hvor meget af menudesignet skal være på plads, før jeg bygger formularer?
Nok til at vide, hvad der er globalt, og hvad der er kontekstuelt. Beslut tidligt, hvilke handlinger der hører hjemme i menuen — tilgængelige fra hvor som helst — og hvilke der hører hjemme på formularer, hvor de kan styres af konteksten. At få den opdeling rigtig tidligt sparer omarbejde senere, fordi flytning af en handling mellem menu og formular efterfølgende påvirker både menudefinitionen og enhver formular, der refererede til den.
Ofte stillede spørgsmål
Hvorfor har 4D et separat brugermiljø, hvis brugerne aldrig ser det?
Brugermiljøet eksisterer, så udviklere har et stabilt, standardiseret sted at teste og inspicere deres arbejde. Fordi dens menulinje er fast, flytter den sig ikke under dig, mens du udvikler. Slutbrugeren arbejder normalt i et brugerdefineret miljø, hvor du styrer menulinjen. At holde de to adskilt betyder, at din testoverflade og din leveringsoverflade hver især kan optimeres til deres forskellige formål.
Kan menulinjen i 4D-brugermiljøet tilpasses?
Det er en standardmenulinje leveret af platformen, og hensigten er, at den forbliver standard, så den forbliver en pålidelig udviklingsflade. Din tilpasningsindsats hører hjemme i det brugerdefinerede menumiljø, som dine brugere rent faktisk vil se. Behandl brugermiljøets menulinje som et værktøj, du bruger, ikke en leverance, du designer.
Hvad er Foundation helt præcist, og skal jeg bygge min app på det?
Foundation er en 4D-strukturfil - en skal - der indeholder et stort antal forudbyggede metoder og formularer, som du kan kopiere og indsætte i dit eget arbejde. Det er et hurtigt spor, når du først har det grundlæggende i 4D. Det er bedst brugt som en kilde til arbejdseksempler og mønstre snarere end som et fundament, du bruger engros, fordi kopierede objekter kan bære afhængigheder og konventioner, der ikke passer til din struktur.
Hvorfor fungerede mit menupunkt under testen, men ikke for brugeren?
Næsten altid fordi du har testet i brugermiljøet og brugeren kører i et brugerdefineret menumiljø. De to har forskellige menulinjer, så et element, der er tilgængeligt for dig under udvikling, findes muligvis ikke i den installerede menu. Før du fejlfinder menudefinitionen, skal du bekræfte, hvilket miljø du er i.
Skal jeg genopbygge FileMaker-menustrukturen i 4D?
Nej, og det burde du generelt ikke. FileMakers Fil/Rediger/Record-organisation eksisterer, fordi FileMaker præsenterer en applikationsmenulinje til generelle formål. I 4D konstruerer du menuen, så du kan organisere den omkring dine brugeres faktiske opgaver i stedet for at spejle en generisk struktur. Brug FileMaker-layoutet som referencepunkt for, hvilke funktioner du har brug for, ikke som en skabelon til, hvordan du arrangerer dem.
Hvor meget af menudesign skal ske, før jeg bygger formularer?
Nok til at vide, hvad der er globalt, og hvad der er kontekstuelt. Beslut tidligt, hvilke handlinger der hører hjemme i menuen - tilgængelige fra hvor som helst - og hvilke der hører hjemme på formularer, hvor de kan lukkes af kontekst. At få den opdeling rigtigt tidligt sparer omarbejde senere, fordi flytning af en handling mellem menu og formular efter kendsgerningen berører både menudefinitionen og enhver form, der refererede til den.
Prøv FileMaker gratis i 45 dage
Den langvarige relationsdatabaseplatform til teams, der har brug for tilpassede apps på desktop, web og mobil fra en enkelt fil.