Wij zijn straffe gasten, maar FileMaker wringt soms tegen

[AvD]

Wij zijn straffe gasten, maar FileMaker wringt soms tegen - So what?

De vragen die op Clarify binnenrollen zijn bijzonder divers. Vroeger volstond het een ervaren FileMakeraar te zijn om op die vragen te antwoorden. Er waren talrijke kneepjes waarmee je heel wat mensen kon blijmaken, en voor elk probleem had iemand wel een oplossing bedacht.
Maar geleidelijk aan is er in die vragenlijst een verschuiving opgetreden, en steeds vaker wordt er in de haren gekrabd, en dat om twee redenen. De eerste reden is dat het antwoord op de vraag zomaar niet voor de hand ligt, ja zelfs niet in de manual of in de on line help te vinden is. De tweede is dat dat eigenlijk ook niet hoeft, omdat de vraag in wezen weinig met FileMaker te maken heeft. Het gaat dan om hele speciale toepassingsgebieden waar FileMaker geïntegreerd moet worden in een reeks automatisch verlopende processen waarvan een deel buiten FileMaker verloopt, en een deel zelfs buiten de computer.

En dan klagen we er over dat wij ons een plugin moet aanschaffen voor een functionaliteit die eigenlijk ingebouwd zou moeten zijn: “Zoiets belangrijks had er toch al lang in moeten zitten!”.
Ja, dat zal dan wel. De ene wil dit, en de andere wil dat.
FileMaker moet bijzonder krachtig zijn en onnoemelijk veel data kunnen stockeren, sorteren, terugvinden, omrekenen en ga zo maar door. FileMaker moet dus de beste databank zijn. Dat zouden we toch willen.
De lay-outs die we maken moeten echt mooi ogen, met transparante gifs, logo’s op kleurige achtergronden, automatische warning colors en prachtig design. FileMaker moet dus een perfect opmaakprogramma zijn. Dat zouden we toch willen.
FileMaker moet gigantisch goed en snel kunnen rekenen. Wachttijden en zandlopertjes kunnen echt niet geaccepteerd worden. FileMaker moet dus de krachtigste spreadsheet zijn. Dat zouden we toch willen.
FileMaker moet knappe rapporten kunnen printen, maar ook lange brieven, lastenboeken, hypothecaire akten en advocatenconclusies, desnoods van meer dan honderd bladzijden. FileMaker moet dus de beste tekstverwerker zijn. Dat zouden we toch willen.
FileMaker zou vlot moeten communiceren met om het even welk boekhoudpakket, met Isabel, met de zelfgemaakte lottogenerator. FileMaker moet dus de beste communicatiemiddelen hebben. Dat zouden we toch willen.

Hebben wij dus nog andere software nodig? Nee natuurlijk: als onze dromen waarheid zouden worden, dan kon Bill Gates zijn bedrijf sluiten.

Maar zo werkt het niet…

En waarom niet? Heel eenvoudig: omdat we vergeten zijn wat FileMaker eigenlijk is, en waarvoor het bedoeld werd.

De grote Ilyse Kazar zet ons dan weer netjes met de voeten op de grond, met een klare kijk die ons steeds weer bewondering ontlokt:

“I think one point *you* keep missing is that FileMaker Pro is an *end-user database*. You have chosen to use it as an application development environment, and while you are certainly not alone in having made that choice, those of us who develop "applications" using FMP must accept whatever limitations we run into as a result of its being an *end-user* database environment. That's how it was designed, that's how it's marketed. The product description for FMP 6 on FMI's web site says, in part:

<<FileMaker Pro 6 is the leading workgroup database software for quickly creating and sharing solutions adapted to your business needs. Powerful features, broad platform support, and an easy-to-use interface make FileMaker Pro 6 indispensable for anyone who needs to track and manage people, projects, images and information. Use built-in instant-productivity templates to quickly design and deploy customized solutions. >>

Notice that it does not say: "FileMaker Pro 6 is an application development environment that allows you to quickly create sophisticated solutions for resale to end users."

I would wager that among all the installed seats of FMP in the world, the redominance of them are in situations where end-users are creating their own little databases, either in a small-biz environment or in a corporate environment where FMP enables end-users to quickly roll their own, rather than have to ask (and wait for) IT to develop a database for the workgroup's specialized, "boutique" requirements.

The way things worked out, some people started exploring ways to "push the envelope" using FMP to develop "applications" as a result of entrepreneurship/ingenuity applied to FMP's relatively rich feature set, and IT departments use it to serve Mac or mixed-platform networks (or they simply want to develop centralized db's rapidly and need to modify them frequently and on-the-fly). It may even have come as a surprise to Claris that a community of "FMP developers" came to be, who demand such things as event triggers and custom menus and more sophisticated relational functionality. Those of us who call ourselves "FMP developers" must remember that the target market of the software vendor (FMI) is the end-user, with the chief attractions to the product being cross-platform capability, *ease of use* and ease of networking.

Well, when Billy End-user spends a couple of hours one day to slap together a Contracts database for his workgroup to share, do you think he needs custom dialogs? Would you think he even scripts the hiding of windows, never mind wants to learn sophisticated functions that control application window size, document window placement, etc.?
Do you think he would understand the implication of event triggers? Does he care about putting in extra time to design what the custom menus would be in each file? I'd say chances are his FMP database is not even relational, probably does not even use scripts (or, if it does, only very simple ones), and allows full menus to all users.

Meanwhile - in response to loud demands, when it became apparent that a small group of people (a few thousand?) around the world decided to become "FMP developers" who create applications for others using the tool - FMI has indeed striven to incorporate into this product some of the features requested by dev's. (If you don't think many developer-oriented features have been added to the product, just try doing a several-hour-long development session using FMP 4 after you're thoroughly used to 5-6.) But FMI's mission, if it is to remain a profitable, enduring product, is clearly to continue to be marketable as the "easy to use" database. Developers are NOT FMI's core market, end-users are.

It would be interesting to see some real statistics on how many of the world-wide installed seats of FMP were bought because a developer had an FMP-based application to sell, versus seats that were bought because people heard about FMP on their own and wanted a quick and easy way to put together relatively simple solutions on their own. I'd expect that the latter category of customer is by far the larger category, and is the one that keeps FMI solvent.

We've all heard the news about great things underway at FMI, destined to appear in a future product release. While I certainly look forward to more powerful developer-type features being included in the product, at the same time my hope is that the engineers find a way to keep FMP easy to use for all those do-it-yourselfers (else risk losing a huge chunk of FMP's customer base). They have done so, and done it brilliantly, in the past, and I fully expect them to pull it off once again. And I wouldn't be surprised if some of the features you describe as being "basic," which might be true for an application development environment, are still not included (and may never be included) in a product intended largely to empower non-developers to create their own data-management solutions.

kazar

Met dank aan Ilyse Kazar!

[DJ_Lucv]

Zoals je ook al zegt, het zet je weer even met beide benen op de grond. Ik vind eht heel goed dat je dit gepost hebt AVD, ik hoop dat dit aanleiding is voor een goede discussie.

Als je de vergelijking gaat maken met een SQL database als MySQL dan valt je eigenlijk meteen op dat het een database is, en niet meer. Er zijn dan ook talen zoals PHP waarin je die informatie kunt gebruiken. Maar waarom voor Filemaker kiezen als je ingewikkelde applicaties wilt maken? Dan kom je volgens mij op het punt waarop je kunt zeggen dat Filemaker gewoon niet meer geschikt is. Dit wil dus niet zeggen dat het niet, zoals in het artikel ook al wordt uitgelegd het geen fantastisch programma is om eenvoudig een database mee te maken! Het is heel eenvoudig om een database te maken maar als je wat ingewikkeldere taken uit wilt gaan voeren kom je uiteindelijk op een limiet. Je gaat dan dingen doen via omwegen waarvoor Filemaker eigenlijk niet voor bedoeld is. Of dat niet mag? Lijkt mij wel maar of je daarmee applicaties waar bedrijven mee moeten werken mee moet gaan maken, dat lijkt mij niet echt verstandig. Zeker als je later wijzigingen aan wilt gaan brengen moet je gewoon gebruik kunnen maken van geteste oplossingen en niet van plakbandoplossingen.

Ook als je naar applicaties gaat kijken die bijvoorbeeld beveiligd moeten worden kom je op problemen te zitten. Zo wil je bijvoorbeeld recordlevel security gebruiken. Zodat bijvoorbeeld alleen gecertificeerde informatie via het internet beschikbaar is. Als je dit soort dingen met CDML wilt gaan doen kom je verscheidene problemen tegen. Je zult namelijk een zoekactie moeten uitvoeren met daarin het wachtwoord, je zult dus eerst het recordwachtwoord ergens op moeten laten zoeken in een database. Je zult die database echter ook weer moeten beveiligen want anders kunnen al die record zo opgehaald worden. Je moet dus meerdere zoekacties uitvoeren en dus meerdere pagina's achter elkaar laden om de informatie op je scherm te rkijgen zonder dat het gewoon toegankelijk is voor de andere internetgebruikers. In de Filemaker handleiding "lossen ze dit probleem heel mooi op" Ze maken gewoon een tekstveld aan en laten de gebruiken constant een wachtwoor dinvoeren, maar of de gebruikers daar blij van worden?

[jw]

Wel, ik onderschrijf jullie standpunt. Het kan niet alles, maar je kan er mooie dingen mee maken en daar zijn de klanten weer heel blij mee.

Toch een ding die maar hardnekkig niet in Filemaker worden opgelost en waar ik ook geen work-arround voor weet.

Bij de afdruk correct uitrekenen waar de blad-overgang komt zonder dat regels dubbel of half worden afgedrukt.

[Arnoud]

Ik ben niet zo'n kroegloper maar voor jullie maak ik een uitzondering.
Tja, in het artikel is het al duidelijk gemaakt, Filemaker heeft een bepaalde doelgroep en dat zijn de eindgebruikers. En die hebben slechts een klein gedeelte van de mogelijkheden van FMP nodig en zijn dan volmaakt gelukkig.
De meesten van ons zijn begonnen als eindgebruiker. Een aantal zijn echter 'doorgegroeid' tot wat we power-user noemen of developer.
Ja bij deze kleine groep, wringt Filemaker soms een beetje. Dingen die bij andere pakketten simpel met een regel code worden opgelost, daar moeten soms halsbrekende toeren voor worden uitgehaald. Maar het omgekeerde komt ook voor.
Een aantal van deze power-users en developers overwegen NAAST filemaker ook andere programma's te gaan gebruiken, zoals 4D of het onlangs geintroduceerde SERVOY. Prachtige pakketten, maar niet voor de gemiddelde eindgebruiker die snel iets in elkaar wil flansen en het beetje bij beetje wil verfraaien.
Maar wel goed geschikt voor de genoemde kleine groep die soms tegen de muur aan lopen met Filemaker. Ik zei hierboven al in grote letters NAAST.
Omdat ik er van overtuigd ben dat sommige applicaties ook voor de developers beter en sneller! in filemaker gemaakt kunnnen worden. Daarom hou ik aan de ene kant mijn hart vast en ben aan de andere kant benieuwd hoe het volgende FMP product eruit komt te zien. Ik hoop echt dat het de lage instap blijft houden van nu.
Want het is nu pakket waar zeer snel zeer fraaie dingen mee gedaan kunnen worden.
Mij overkomt bij FMP soms hetzelfde als ik in gedachten verzonken door een tunnel ben gereden, waarvan ik me later afvroeg, heb ik die al gehad?. Zo heb ik op de automatische piloot vele leuke dingen gemaakt in Fielmaker, en ik zie me dat nog niet (snel) met andere software doen.
Tja dan nog even die opmerking van JW over de pagebreak.
Gek genoeg kwam die functie wel in FMP4 voor, zij het als hidden feature (shift>modus>layoutinstellingen), maar hij is verdwenen sinds versie 5.
Met dat betreft ben ik van mening dat FM-inc. beter moet luisteren naar opmerkingen van gebruikers.

[AvD]

Zeer goede en scherpe analyse, Arnoud! EN ook JW heeft gelijk als hij het printprobleem van FileMaker ervaart als een van die wringerijen. Toch nog een opmerking daarover:

Tja dan nog even die opmerking van JW over de pagebreak.
Gek genoeg kwam die functie wel in FMP4 voor, zij het als hidden feature (shift>modus>layoutinstellingen), maar hij is verdwenen sinds versie 5.
Met dat betreft ben ik van mening dat FM-inc. beter moet luisteren naar opmerkingen van gebruikers.

Die functie is niet verdwenen sinds versie 5. Integendeel: ze zit nu standaard ingebouwd in de print engine van FileMaker (en voelt zich best in zijn nopjes bij een ruler-instelling in pixels i.p.v. centimeters of inches). Dat gezegd zijnde: "Non los marcheros pico bello", of zoals een medewerker zei: "Izzi no workin!". Hoofdprobleem is dat FileMaker puur grafisch print en dus niet door het interpreteren en/of sturen van ASCII- of Unicode-codes. FileMaker ziet enkel pixels en het zijn onze hersenen die van bepaalde pixelcombinaties tekst maken. Dit probleem blijft dus onoplosbaar zolang FileMaker die grafische print engine gebruikt. Daarom slepen we het probleem al zes versies lang mee .

Maar we dwalen af van het eigenlijke onderwerp (of toch niet?): we zijn straffe gasten, en FileMaker wringt soms tegen. Ik zou graag nog reacties zien op de postings van Arnoud, onze DJ en JW.

[JeanWM]

Filemaker wringt soms tegen..... so what ?

Is iedere tegenwringerij geen uitdaging ?

Sinds versie 2.1 is alles maar ‘méér’ geworden.
In een tijd waar Lotus 123, dBase III en dBase IV de plak zwaaiden (en dan had je nog Clipper nodig) werkte FM reeds, toen nog alleen op Mac, maar sinds de Win versie kwam er steeds meer uitbreiding.
We waren blij met wat FM kon, en waren tevreden met wat méér kon. Eisen waren er nog niet zoveel.

Sinds versie 3/4 kunnen we op het net (zonder HTML code te ‘moeten’ kennen), gaan we ‘relationeel’ (wat een zégen !), Excel spreadsheets (en nog een paar andere) gewoon inlezen en omgekeerd, met ODBC is zelfs Oracle geen probleem.
We werkten met dezelfde gegevens als in een spreadsheet, maar het resultaat (rapport) zag/ziet er heel anders uit. En hiermee scoren wij.....

Uitwisseling tussen verschillende platformen.... wie kon/kan dat ?

FM is als een auto.
Je koopt een 1300 cc, en die brengt je probleemloos van punt A naar B.
Als het regent, zit je droog, als het koud is, zit je warm, en je kunt probleemloos ‘met het verkeer mee’.
Met naar andere ‘1300-gebruikers’ te luisteren kun je er meer zaken mee doen.
En indien je echt meer wil, bouw je er een ‘welvaartsknobbel’ aan, hang er iets aan (b.v. een karretje of een caravan) en ‘plug’ de stekker ‘in’. Je blijft rijden.....en je komt met je zaakjes op plaatsen waar je vroeger ‘van droomde’.
Het achteruit rijden ? Hmm... is wat moeilijk, maar je leert het snel, door te doen....

Het is pas als je de 1300 wilt of gaat gebruiken als zou het een 1600, 1800 of zelfs 2000 zijn dat je in de problemen komt. Maar is dat niet bij alles wat je wilt gebruiken voor wat het ‘eigenlijk’ niet gemaakt is ?

FM is voor beheer van data, punt.
Wat je met data allemaal kunt is oneindig. Wat je via FM met de data kunt is beperkt (geef hier zelf een definitie aan ‘beperkt’). Alhoewel, met de hulp van verschillende ‘anderen’ (forum, devcon, confituursessies) die ik hier zou willen bedanken, schuift die ‘beperkt’ steeds verder op....
En hier heeft André overschot van gelijk, het ‘méér’ heeft eigenlijk te maken met wat ‘buiten’ FM allemaal kan, en heeft eigenlijk nog weinig met FM zelf te maken....

Voor iemand die nog de uitlopers van het ponskaart systeem heeft meegemaakt, ben ik enorm tevreden met wat FM mogelijk maakt. En het gaat nog steeds ‘met zijn tijd mee’.

Dat het niet ‘alles’ kan is normaal, ergens moet een grens getrokken worden. Als je de mogelijkheden nagaat, bij welk ander soortgelijk programma ligt de grens zo ver ?
Natuurlijk zitten in FM ‘schoonheidsfouten’ en zijn er zaken ‘die we nog zouden willen’.

Wie weet, uiteindelijk zullen die foutjes verdwijnen en komen onze dromen uit.
Ondertussen slagen wij er toch maar in FM zaken te laten doen waarvan de makers zelf misschien droomden, en geeft dat geen ‘goed gevoel’. ?

We zijn straffe gasten en FM wringt soms tegen, maar uiteindelijk geeft dat ‘een goed gevoel’ .....

Keep on FileMaking.....

[AvD]

FM is voor beheer van data, punt.
Wat je met data allemaal kunt is oneindig. Wat je via FM met de data kunt is beperkt.

Een uitstekende samenvatting! En dat het verleggen van de grenzen een uitdaging is, is meteen de verklaring waarom we zo graag met FileMaker bezig zijn. Er is niets dat meer de creativiteit stimuleert, en geef toe, het is fantastisch als je de wenkbrauwen (ongemerkt) fronst bij de vraag van de klant, denkend "Dat kan nooit", om dan onderweg te beginnen pîekeren, tot plots die inval komt... Daarna eens proberen, mislukken, opnieuw proberen en toch een licht zien. Uiteindelijk denk je: het gaat toch, als... Na verloop van tijd heb je het voor mekaar, het draait dan bij de klant, en die vindt dat doodgewoon.

[DJ_Lucv]

FM is voor beheer van data, punt.
Wat je met data allemaal kunt is oneindig. Wat je via FM met de data kunt is beperkt.

Die eerste regel is inderdaad bij een standaard databse het geval, maar Filemaker valt daar niet onder. Filemaker is een totaalpakket geworden alleen kan Filemaker het niet voor elkaar krijgen om aan de eisen van alle gebruikers te voldoen. Dat zal geen enkel bedrijf lukken hoor maar wat je daardoor dus krijgt is dat je een punt krijgt waarop Filemaker gewoon niet meer voldoet.

Een uitstekende samenvatting! En dat het verleggen van de grenzen een uitdaging is, is meteen de verklaring waarom we zo graag met FileMaker bezig zijn. Er is niets dat meer de creativiteit stimuleert, en geef toe, het is fantastisch als je de wenkbrauwen (ongemerkt) fronst bij de vraag van de klant, denkend "Dat kan nooit", om dan onderweg te beginnen pîekeren, tot plots die inval komt... Daarna eens proberen, mislukken, opnieuw proberen en toch een licht zien. Uiteindelijk denk je: het gaat toch, als... Na verloop van tijd heb je het voor mekaar, het draait dan bij de klant, en die vindt dat doodgewoon.

Dit is natuurlijk niet echt Filemaker gerelateerd maar meer developement in het algemeen.

[dirk]

beste goeroes,
Misschien is het nuttig om met Filemaker een beetje bescheiden te blijven ... maar anderzijds ...
Vandaag kwam er op het ICt forum van de openbare bibliotheken volgende mail (van de bibliotheek van Anderlecht):

“Een m.i. belangrijk criterium - dat mee het kostenplaatje zal
bepalen - is in welke mate de bibliotheekcatalogus naadloos
geïntegreerd is (of kan worden) in de rest van de website van de
bibliotheek. Van de bibliotheken met website én met catalogus op
het web heb ik er nog niet veel gezien waar beide echt volledig
geïntegreerd zijn en waar je (als kenner uiteraard) niet van kan
aflezen dat de resultaten eigenlijk uit een database van VubisWeb
of VubisSmart afkomstig zijn. Ik merk wel dat er een evolutie in
die zin bezig is. De website van de bibliotheek van Boutersem is
een mooi voorbeeld van hoe die integratie wel kan. “

De bibliotheek van Boutersem gebruikt voor alle aspecten van automatisatie Filemaker (uitleen, catalogus, ledenadministratie enz…)
Dit is voor jullie, specialisten een weinig complex systeem maar het werkt vlot en is in eigen beheer ontwikkeld … en dit tegen een aanschafprijs en onderhoudskost die fenomenaal lager ligt dan de “traditionele” bestaande systemen voor bibliotheekautomatisatie die kant en klaar op de markt te vinden zijn …
In feite had ik er nog niet echt bij stilgestaan , met wat persoon in desbetreffende bovenstaande mail schrijft, … maar naar aanleiding van deze mail ben ik eens eventjes terug gaan kijken naar wat er zo inderdaad al te vinden is op het web, gemaakt vanuit deze paketten
beoordeel zelf :
in Vubis ontwikkeld : http://wwwob.cevi.be/vubis3/n/mvbs1.htm
in Bidoc ontwikkeld: http://www.bidoc.be/poblendelede/bidoc1.htm
in Dobis Libis ontwikkeld: http://bibliotheek.antwerpen.be/MIDA/
...
in Filemaker ontwikkeld : http://bib.boutersem.be

Ik wil niet ontkennen dat de bovengenoemde paketten krachtiger, complexer, enz. zijn dan onze Filemaker toepassing ... maar naar flexibiliteit, aanpasbaarheid enz. kunnen ze niet aan Filemaker tippen ... en dit is toch ook een belangrijk aspect! Tevens spreken we van kostprijzen die toch al snel het 5 a 10 voudige zijn van onze IT-kosten!!


Dirk Hermans
bib Boutersem

ps. met dank aan Leo, en aan Koen, Claude en de Shpartnersclub

[AvD]

Dag Dirk

Dank voor je reactie. Je hebt gelijk voor de volle honderd percent. Waar het Ilyse Kazar om ging is dat FileMaker zich profileert als een end user database maar dat de ingebouwde tools zo krachtig zijn dat de meesten onder ons zich laten verleiden om FileMaker te beschouwen als een application development environment. Vanuit dat standpunt komen er dan soms negatieve kritieken omdat FileMaker een aantal essentiële dingen zou ontberen. Het is die onterechte kritiek tegen FileMaker die Ilyse wil counteren, en ik geloof dat ze daarin gelijk heeft.
Ik denk dat we hiermee trouwens ook aan het essentiële verschil komen tussen FileMaker en Servoy.

[murtje]

Bedankt voor de complimenten, Dirk!

Ik denk dat we hiermee trouwens ook aan het essentiële verschil komen tussen FileMaker en Servoy

Gelijk heb je. FileMaker is geen Servoy en Servoy is geen FileMaker. Het zijn alle twee mooie pakketten met elk hun eigen toepassingsgebieden.



Koen

NB: (ik weet het Peter, we moeten FileMaker Pro zeggen )

[Sanne]

"In de beperking toont zich de meester."

[DJ_Lucv]

En na bijna een half jaar weten we dan toch door Sanne waar we het allemaal voor doen

[SuperWimmie]

....Maar zo werkt het niet…

En waarom niet? Heel eenvoudig: omdat we vergeten zijn wat FileMaker eigenlijk is, en waarvoor het bedoeld werd....

Mag ik eens een geheel andere visie neerleggen?

Met bovenstaande quote kan ik mij uitstekend vinden en ben het er hartsgrondelijk mee oneens

Zo op het eerste gezicht spreek ik mijzelf tegen.

Zou ik voor deze stellingname zijn, dan was de computer vandaag nog gelijk aan de kleinste zakrekenmachine die je nu voor 2 euro in de winkel koopt. Want was de computer niet oorspronkelijk bedacht om het rekenwerk te versnellen?

Kijk ik naar de mogelijkheden van de computer van vandaag, dan is het een stuk gereedschap geworden waarmee ik ben gaan tekstverwerken, plaatjes ben gaan tonen, archieven ben gaan opbouwen, handelingen ben gaan automatiseren, spelletjes ben gaan spelen, filmpjes ben gaan kijken, ben emailtjes gaan uitwisselen met de rest van de wereld en vandaag de dag zelfs gratis de wereld over aan het bellen ben...
Vertel me nou niet dat we liever weer de beperkingen zouden willen zien van de rekenmachine... dan moeten we nu direct stoppen met dat overdreven gedoe hier met internettende Clarify forumgebruikers

Zo vergaat het Filemaker ook. Ik ben dan ook bijzonder blij dat Filemaker naast de grondbeginselen van een database veel meer is gaan doen om het leven te veraangenamen. Volgens mij is dat de enige manier om te overleven in deze geautomatiseerde wereld. Anders had ik Filemaker al lang vaarwel gezegd.
Oftewel: Filemaker moet eigenlijk alles kunnen, de beslissing is aan mij om mijzelf te beperken.

Ik begrijp overigens best dat een te uitgebreide Filemaker allerlei nieuwe problemen gaat brengen die ik niet wil. Zolang de extraatjes de stabiliteit en eenvoud niet in de weg staan is er weinig aan de hand.

[AvD]

Het doet plezier dat deze thread nog altijd niet dood is, hoewel een van de oudsten van dit forum. Het vertrekpunt van de stelling situeert zich in 2003, de glorietijd dus van FileMaker 6. En wat toen door FileMaker Inc zelf gezegd werd over de software, getuigt van een zekere voorzichtigheid, ja zelfs terughoudendheid op het vlak van de marktpositionering. Het is trouwens precies dat aspect dat Ilyse Kazar zo heeft benadrukt toen ze hierover commentaar leverde:

Notice that it does not say: "FileMaker Pro 6 is an application development environment that allows you to quickly create sophisticated solutions for resale to end users."

Ondertussen zijn we een aantal jaren verder, en heeft FileMaker de evolutie gevolgd, zonder daarbij zijn oorspronkelijk standpunt aan te passen. Da's zoiets als de kinderen naar bed sturen, en dan niet reageren als ze blijven zitten.
We pleitten toen dus ook niet voor een behoudsgezinde en niet evoluerende FileMaker, verre van. Wat we wel wilden was het bijbrengen van enige realiteitszin aan de gebruikers die boos werden op hun lief omdat ze niet Paris Hilton heette, als je het beeld begrijpen wil.
Er is vandaag - ondanks het standpunt van SuperWimmie - niet veel veranderd: we kunnen al veel meer met FileMaker, maar de hemel op aarde wordt ons nergens op de doos, nergens op de FileMaker-website beloofd. We kunnen er dus ook geen aanspraak op maken.
Goed voor ons, zo blijven we tenminste straffe gasten!