solutions verkopen

[alex]

hallo iedereen,

 

ik heb voor eigen gebruik (ik ben grafisch ontwerper) een kantoortoepassing gemaakt met de naam DirtyWork, met daarin de gebruikelijke zaken: adressen, facturen, begrotingen, projecten, uren, kosten enz.

 

de reden dat ik er ruim tien jaar geleden aan begon was dat ik de indertijd al bestaande toepassingen te onhandig, te lelijk of gewoon te duur vond en meestal alle drie tegelijk.

 

inmiddels is t een behoorlijk geavanceerde, gepolijste en gebruiksvriendelijke toepassing geworden (al zeg ik t zelf en ik heb t gevoel dat ik m zou kunnen verkopen. alleen... hoe reëel is dit... en hoe doet men dat dan... zelf aan de man/vrouw brengen? een uitgever zoeken? de toepassing in zn geheel aan een bedrijf verkopen?

 

heeft iemand ervaring met deze zaken? en bestaat er bijvoorbeeld zoiets als een uitgeverij van FMP toepassingen? en wat komt er allemaal kijken bij het zelf op de markt brengen van een toepassing?

 

voor de nieuwsgierigen onder u: ik heb een screenshot bijgevoegd met gefingeerde gegevens.

 

dank en groet, alex

[JeanWM]

Verwacht er niet teveel van….

 

Hier enkele van mijn persoonlijke bedenkingen, zonder echt dieper op het onderwerp in te gaan. Enkel losse ideeen, helemaal niet in volgorde…..

 

Je gebruikt een Engelse naam (Dirty Work), terwijl de veldbenamingen Nederlandstalig zijn.

Ik zou er al voor zorgen dat het geheel een ‘veranderlijke taalmodule heeft om zo algemeen mogelijk te blijven.

Je zit met je product al in een klein segment (grafische sector) en die ga je nog kleiner maken door ééntalig Nederlands te blijven.

Ik neem het voorbeeld voor Belgie, waar het gros van de grafische industrie in Wallonie zit, en dat is bij mijn weten Franstalig…..

 

Het probleem ligt niet noodzakelijk in het hoe op de markt brengen. Jij vindt zelf dat het produkt rijp is, vraag is of de markt rijp is voor je produkt.

Jij bent overtuigd dat anderen je product kunnen gebruiken, zaak is die anderen te overtuigen dat zij jouw product nodig hebben.

 

Dat betekent geld uitgeven vóór er geld binnenkomt, dat heet dan investeren, investeren in reclame…

Ik zou dan al vaktijdschriften kunnen uitpluizen om te zien hoe er daar een kleine advertentie kan geplaatst worden en de kost ervan….

Misschien kun je verkorte versies maken van je programma, beperking op aanmaak van records bv, het geheel op een 8 cm CD branden en die ‘uitdelen’ op ‘grafische sector vakbeurzen’ b.v.

Die methode was jaren geleden misschien ‘in’, weet niet of het nu nog lonend is....(hier in alle geval wel)

 

Zelf zou ik in het begin zoveel mogelijk in eigen beheer houden, tot het geheel zichzelf onderhoudt.

Bedenk ook dat er ergens een financiele dienst rondloopt die ‘belasting’ heet en gewoonlijk de naam BTW heeft. Kan vertaald worden als Beter Tijdje Wachten.

 

Hoe zit het met de documentatie die samen gaat met je programma. Hoe zie je de service na verkoop. Verwacht je aan telefoons of mails met vragen. Hoe behandel je die ? Ben je bereikbaar, altijd bereikbaar ? Ook ‘s nachts ? Zorg voor een goede, duidelijke helpafdeling, alhoewel die niet vaak zal gelezen/gebruikt worden.

Ik zie nergens een ‘Help’ knop op je screenshot, terwijl ik toch al vragen heb bij bepaalde items…..

 

Hoe zit het met de ‘bescherming’ van je toepassing. Wachtwoord engine ? Of kan iedereen binnen de korste keren overal aan, zodat het vrij kan gecopieerd en doorgegeven worden (wat zeker zal gebeuren).

 

Zijn er ingebouwde mogelijkheden tot update/upgrade. Hoe ga je dit in praktijk uitwerken/opvolgen ?

Doe je de verdeling als runtime of niet. Doe je het niet, dan dwing je gebruikers tot het hebben van een FM versie, wat de kans tot verkoop/gebruik gaat verkleinen, want als ze FM niet hebben....

 

Hoe verpak je de zaak ? Enkel een CD in een klassiek doosje, of ga je verder. Je zit in de grafische sector…..De bijhorende documentatie zou dan moeilijk een doodgewoon recht toe recht aan Worddocument kunnen zijn…..

Zet je het geheel als te downloaden op een website of gebruik je andere kanalen. Ik kan me moeilijk inbeelden dat je product op een schap in Carrefour kan liggen, of Albert Hein voor mijn part….

 

Geef je dat beheer uit, dan moet je ervoor betalen, wat de uiteindelijke kost gaat opjagen, wat ons dan breng bij de prijszetting van het product.

Als je er een prijs op plakt, is dat doorgaans het bedrag dat JIJ er graag voor zou hebben (in tegenstelling tot wat het kost, dat is een andere zaak), maar is dat een bedrag dat een gebruiker ervoor zou willen geven ?. Dus maak je best een ROI voor je programma.

 

Enkele losse gedachten en mijn 2 centavos.

 

Succes.

[Joris Aarts]

Hallo,

 

Het ziet er alvast erg professioneel uit: sober en netjes. Proficiat!

 

Brian Dunning heeft nogal wat artikels geschreven over het verkopen van FileMaker toepassingen. Hij geeft daar zelfs cursus over ("ToMarket"): http://www.briandunning.com/tomarket/

 

Ook Brian is krititsch. De meeste van zijn bedenkingen zitten ook in Jean's antwoord. En in de VS gaat het dan nog om een gigantisch ééntalig gebied.

 

Op FMForums is er een forum voor FileMaker Developers: http://fmforums.com/forum/showforum.php?fid/68/fp/1/

 

Groetjes,

 

Joris

[burggraaf]

Eerlijk is eerlijk, wat kritische noten:

 

Qua design ziet het zo op het eerste gezicht fraai uit. Ben wel benieuwd hoe dat er onder Windows uitziet... Helaas wat minder fraai denk ik omdat Windows, anders dan op de Mac, alles binnen 1 venster wil plaatsen.

 

...de reden dat ik er ruim tien jaar geleden aan begon was dat ik de indertijd al bestaande toepassingen te onhandig, te lelijk of gewoon te duur vond en meestal alle drie tegelijk.

De vraag die boven komt is: zullen mogelijk toekomstige prospects deze criterea ook hanteren? En zo ja, wat zou hun beoordeling dan zijn?

 

Ik ga mee met Jean z'n epistel en denk dat zelfs hij daar nog het nodige aan toe zou kunnen voegen...

 

Er is veel, heel veel, van dergelijke software en je moet je op e.o.a. manier weten te onderscheiden. Op het moment dat je denkt dat er alles inzit weten gebruikers vanalles te verzinnen wat het eigenlijk ook nog zou moeten kunnen. Bijvoorbeeld zomaar 1 als je 'm als runtime zou uitgeven: '...kan ik m'n eigen printlayout samenstellen?'

 

Je zult er dus veel, heel veel, energie in moeten blijven steken en hopen dat het gaat lonen. Als je er voor gaat zou dat best kunnen lukken maar zul je nog veel hobbels op je pad gaan tegenkomen.

 

Software is (helaas) niet als een boek wat je schrijft, aan een uitgever geeft en er zelf geen omkijken meer naar hebt...

 

En als ik je fictieve voorstel zo zie: Blijf gewoon grafisch vormgever...

[Peter Wagemans]

Wij noemen dat bij ons in het bedrijf iets "productisen" - aha, weer een woord voor de bull shit bingo.

 

We blijven er zoveel mogelijk van weg, FileMaker is nog steeds niet de perfecte toolbox om "productjes" mee te maken.

Er zijn echter al een paar dingen die helpen:

- scheiding van data en interface is mogelijk

- tabellen en scripts kunnen gekopieerd en geplakt worden

- bij kopieren en plakken van zowat alle objecten probeert FileMaker eerst een "naam-resolutie" te doen

 

Een product op de markt brengen is 1 ding, het onderhouden is een ander. Vraag maar eens aan Rony.

Stef zal je een vergelijking met Servoy geven... de architectuur van die software leent zich veel beter to productising.

 

FileMaker heeft nog steeds nood aan betere deployment en update scenarios. De IWP engine is nog steeds speelgoed, een goeie Java front-end zou een oplossing kunnen betekenen.

[Stef]

Stef zal je een vergelijking met Servoy geven... de architectuur van die software leent zich veel beter to productising.

 

Ik wilde er eerst niet op reageren, maar als Peter nu toch de voorzet geeft...

 

FM heeft één groot probleem, en dat is dat de data niet écht gescheiden kan worden van de motor, en dit geeft problemen met updaten van versies.

De meest succesvolle oplossingen dezer tijd zijn ASP (application service provider) oplossingen, d.w.z. dat de oplossing online gehost wordt, en in feite verhuurd wordt.

Deze zijn meestal via een dure Citrix oplossing of in een webbrowser (zoals Salesforce.com). Servoy biedt echter een "Smart Client" via Java webstart, wat véél beter oogt en werkt.

 

Dit heeft tal van voordelen:

 

Voor u:

-solution kan niet gecopieerd worden

-updates zijn heel makkelijk te installeren

-je hebt "recurring revenue"

 

Voor de klanten:

-ze zijn in enkele minuten aan de slag

-ze hebben direct een netwerk

-kunnen van overal werken

-hoeven geen backups te maken

-hebben geen server nodig voor de solution

-ze betalen "concurrent" licenses

 

Nadelen:

-constante internet connectie vereist (maar je kan ook een offline versie maken die moet syncroniseren)

 

En hier is Servoy perfect voor:

 

-zeer dunne "Smart Client" die zeer weinig van de server eist

-makkelijke scheiding van data van verschillende bedrijven

-i18n (internationalization): je kan op een makkelijke manier je solution vertalen

-zeer snel en makkelijk ontwikkelen (ik vond het na enkele weken makkelijker en sneller dan Filemaker, bovendien stukken stabieler, crasht nooit)

-je kunt met "modules" werken

-nu ook "multi-developer"

-er is nu ook een web-client om in een browser te werken, en dit werkt fantastisch

 

Wij hebben een server in een datacenter die onze solution host. Hier kunnen een duizendtal gebruikers tegelijk op werken, momenteel een 50-tal.

 

Als je eens wilt proberen:

http://www.willcom.be/startup/

Dit is een oplossing voor een expeditiebedrijf (zeevracht)

Is nog wel niet 100%, maar we werken eraan...

 

ps ik heb géén Servoy-aandelen!

 

HTH

Stef

[SuperWimmie]

Wij noemen dat bij ons in het bedrijf iets "productisen" - aha, weer een woord voor de bull shit bingo.

 

We blijven er zoveel mogelijk van weg, FileMaker is nog steeds niet de perfecte toolbox om "productjes" mee te maken....

 

....Stef zal je een vergelijking met Servoy geven... de architectuur van die software leent zich veel beter to productising.

 

FileMaker heeft nog steeds nood aan betere deployment en update scenarios. De IWP engine is nog steeds speelgoed, een goeie Java front-end zou een oplossing kunnen betekenen.

 

Het hangt er allemaal maar vanaf wat jouw klanten er mee willen bereiken.

Zelf maak ik dus wel degelijk gebruik van Filemaker om een standaard product in de markt te zetten. Eén van die producten draait op één versie bij 20 klanten.

Updates zijn best goed uit te voeren, mits je een goede procedure maakt om alle data te exporteren en na upgrading weer te importeren.

Bij mij is dat nu een "één druk op de knop actie" geworden.

 

De software die ik maak is echt specialistisch. Dat maakt de verkoopprijs tot een kleine discussie, evenals het gekozen platform. Zeker ook omdat zeer specialistische programmatuur vaak toegepast wordt in kleine werkomgevingen.

 

Maar hoe ik het ook doe, reclame maken doet bij mijn product helemaal niets.

Het is slechts de mond-op-mond reclame die echt werkt. De overtuiging is aanwezig dat hier een oplossing ligt die bij een ander niet te verkrijgen is. En ook nog zo breed is ingezet, dat het voor veel gebruikers toegankelijk blijft.

 

Helpdeskactiviteiten is bij mij geen enkel probleem. Mits goed ontwikkeld kan je Filemaker verrassend stabiel krijgen. Zeer stabiele omgevingen vragen vrijwel geen helpdesk.

Veel stabieler zelfs dan diverse SQL oplossingen, omdat de wijze waarop geprogrammeerd wordt veelal de onstabiliteit veroorzaakt. Dat valt met SQL oplossingen vaak niet mee.

 

Maar ik heb het geluk dat internet-oplossingen niet echt van wezenlijk belang zijn bij mijn klanten.

Bij mij past Filemaker wonderwel goed.

Dat geldt niet voor alles wat automatiseringsvraagstukken betreft.

[alex]

driewerf dank iedereen voor de uitgebreide reacties.

 

ik ben me bewust van de vele obstakels die enerzijds te maken hebben met de beperkingen van filemaker en anderzijds met het op de markt brengen van een product in het algemeen. het is prettig om ze nu eens allemaal overzichtelijk opgesomd te zien, ook al kan je er wat moedeloos van worden.

 

een aantal van de obstakels denk ik redelijk getackeld te hebben:

- ik heb het afgelopen jaar veel aan de toepassing veranderd naar aanleiding van de ervaringen van andere gebruikers.

- ik denk een manier te hebben ingebouwd waarmee upgraden betrekkelijk eenvoudig verloopt (met de nadruk op betrekkelijk

- ik overweeg een localiseringstabel toe te voegen waardoor de toepassing in meerdere talen te gebruiken zou zijn, maar dat ik geef toe, dat gaat wel heel ver en tot dusver had ik nog niet zo’n trek in een dergelijke klus, nog afgezien van de vraag of t ècht mogelijk is. t zou DirtyWork (wat overigens nog een werktitel is) nog veel complexer maken dan het al is.

- bescherming blijft een probleem, maar met gebruik van een combinatie van activeringscodes (niet voor de toepassing als geheel, maar voor ieder account dat je wilt aanmaken) kom je denk ik al een eind. dat betekent dat de toepassing vrij te downloaden zou zijn en dat je pas betaalt wanneer je een nieuw account wilt aanmaken. dat houdt het goedkoop voor kleine zelfstandigen bijvoorbeeld.

 

het grootste probleem zie ik zelf in training en support. een goede handleiding maken kost waarschijnlijk net zoveel tijd als het bouwen van de toepassing zelf en dan nog zal je een soort van helpdesk of iets dergelijks moeten onderhouden...

 

wat de compleetheid van het toepassing betreft: ik denk dat je niet voor ieder kantoorprobleem een oplossing moeten willen geven, alleen voor die problemen waarvan je redelijkerwijs kan aannemen dat vrijwel iedereen er mee te maken heeft. en je hoeft ze ook nog niet eens helemaal op te lossen, het scheelt al heel veel als een aantal problemen weet te verkleinen... de meeste kleine ondernemingen hebben te maken met projecten, die projecten moeten begroot worden, er moeten uren en kosten worden bijgehouden en uiteindelijk moet het hele zaakje zo overzichtelijk en makkelijk mogelijk gefactureerd kunnen worden en dat zonder veel boekhoudkundige kennis. vooral in dat laatste onderscheid DirtyWork zich voor mijn gevoel.

 

online kantoortoepssingen heb ik nooit helemaal begrepen. ikzelf zou er mn gegevens nooit aan toevertrouwen en bovendien vind ik ze te beperkt en te trrrrrrrraag...

 

enfin, ik weet nog niet waar het allemaal op uit zal draaien, maar ik ga voorlopig nog opgewekt verder (ik weet niet hoe het bij jullie werkt, maar het maken van een toepassing heeft iets verslavends). en ik ga de gegeven links eens bekijken.

 

dank en groeten, alex

[Stef]

Veel stabieler zelfs dan diverse SQL oplossingen, omdat de wijze waarop geprogrammeerd wordt veelal de onstabiliteit veroorzaakt. Dat valt met SQL oplossingen vaak niet mee.

 

Wim, eventjes serieus blijven aub.

SQL is een database, geen programmeeromgeving.

SQL is razendsnel en uiterst stabiel, iets wat je met Filemaker nooit kunt bereiken (ken je de recover-functie?).

Bovendien kunnen we ook op Oracle draaien. Maar dat zal ook wel niet stabiel zijn, zeker?

 

MVG

Stef

[SuperWimmie]

Veel stabieler zelfs dan diverse SQL oplossingen, omdat de wijze waarop geprogrammeerd wordt veelal de onstabiliteit veroorzaakt. Dat valt met SQL oplossingen vaak niet mee.

 

Wim, eventjes serieus blijven aub.

SQL is een database, geen programmeeromgeving.

SQL is razendsnel en uiterst stabiel, iets wat je met Filemaker nooit kunt bereiken (ken je de recover-functie?).

Bovendien kunnen we ook op Oracle draaien. Maar dat zal ook wel niet stabiel zijn, zeker?

 

MVG

Stef

 

Hardstikke mee eens, Stef. Puur database-technisch gezien heb je helemaal gelijk.

 

Maar voor veel mensen is het woord SQL gelijkwaardig aan Stabiel, totdat je vraagt wat of het Programma in de praktijk doet.

Dan blijkt het programma aan de ene kant stabiel te zijn "want het is SQL" maar het is niet stabiel want het crashed, loopt vast, updates werken niet goed, werkt onhandig, doet niet wat de gebruiker wil....

Ik had het ook over SQL oplossingen, niet over de SQL database itself.

 

Recovery?

Met alle respect, maar dat zit er toch alleen maar in om de in de soep gelopen handel te herstellen?

Hoezo herstel?

 

Whaha, ik moet het afkloppen.... (knock-knock)

Alle bovengenoemde problemen heb ik niet

 

Ik haal nog maar even mijn eigen quote aan:

 

Bij mij past Filemaker wonderwel goed.

Dat geldt niet voor alles wat automatiseringsvraagstukken betreft.

[Peter Wagemans]

Stef:

SQL is een database, geen programmeeromgeving.

SQL is razendsnel en uiterst stabiel, iets wat je met Filemaker nooit kunt bereiken (ken je de recover-functie?).

 

Ikke niet akkoord. SQL is een taaltje, geen database. Zo kan je met FileMaker ook via SQL babbelen. Ik heb een maand geleden een plug-in gemaakt die toelaat dat je vanuit de FileMaker client SQL kunt praten met je eigen FileMaker bestand. Die gaan we eerste nog wat testen, en dan wordt hij hoogstwaarschijnlijk gereleased als freeware, net zoals de DoScript plug-in.

 

Het verwarrende is, dat de gekende database systemen die zeer snel zijn, via SQL moeten worden aangesproken.

FileMaker kán via SQL aangesproken worden, maar onderscheid zich van veel andere database systemen doordat je er ook op een gebruiksvriendelijk manier zonder SQL mee kan praten.

 

Stef, ik weet ook hoe ik een MySQL database moet recoveren, en heb dat ook al veel nodig gehad.

Wat niet vergeten mag worden is dat Filemaker meestal draait in omgevingen waar men niet erg om het technische maalt. Geen UPS, geen backups, en een schrijnend gebrek aan andere know how.

Een Oracle database wordt meestal verkocht inclusief een klein database hogepriesterje die heel de dag de vinger aan de pols van dat systeem houdt.

Als we vergelijken, laten we dat a.u.b. op een eerlijke manier doen. Als je een vinger krijgt, Stef, moet je de hele arm niet opvreten he...

[Stef]

Ikke niet akkoord. SQL is een taaltje, geen database

 

Laat ons de kerk in het midden houden: SQL is ZEKER geen programmeeromgeving, maar een "querytaaltje" om een SQL database te ondervragen. Of zit ik nog niet juist?

 

FileMaker kán via SQL aangesproken worden, maar onderscheid zich van veel andere database systemen doordat je er ook op een gebruiksvriendelijk manier zonder SQL mee kan praten.

 

Kan met die andere ook...

 

Stef, ik weet ook hoe ik een MySQL database moet recoveren, en heb dat ook al veel nodig gehad.

 

Nu spreek je ook over MySQL. Dat is freeware!

 

 

Als we vergelijken, laten we dat a.u.b. op een eerlijke manier doen. Als je een vinger krijgt, Stef, moet je de hele arm niet opvreten he...

 

Heb ik me weer laten gaan? Was het erover? Sorry guys! Didn't mean to hurt ya!

 

Nu voel ik me net Alain Vandam voor de spiegel op de toiletten van Cynalco. "Neeje Alainke toch, neeje, ge zijt weer te rap, Alain! Leert nu toch eens zwijgen, Alain!"

[Koen Van Hulle]

Ook Oracle databanken kunnen corrupt geraken: zoals bij FileMaker kunnen ze last hebben van Bad Blocks. Ze hebben zelfs een apart pakket om corrupties te herstellen: Recovery manager.

 

Oracle is trouwens niet de enige. Zo heb ik ook al eens last gehad van een corrupte MS SQL Server database.

 

Ik mag hopen voor jouw, en je klanten, dat je rekeninghoudt dat het wel eens kan fout lopen.

 

Koen

[Stef]

 

Ik mag hopen voor jouw, en je klanten, dat je rekeninghoudt dat het wel eens kan fout lopen.

 

Koen

 

Nogmaals sorry mannekes! Excuse!

 

Zoals bovenaan gezegd wou ik eerst niet reageren. Maar ik denk dat ik een normale uitleg gegeven heb op de vraag, wist niet dat het nog zo gevoelig lag.

 

Ik wil niets voortrekken! Ik ken ondertussen beide paketten door en door, werk nog steeds met beide, dus ik denk toch dat ik een vergelijking mag maken als daar om gevraagd wordt? Nog iemand in de zaal die ervaring heeft met de twee? Anyone? Bueller?

 

Naar mijn ervaring is SQL een veelvoud stabieler. Maar ik kan natuurlijk ongelofelijk veel pech in het ene en fantastisch veel geluk in het andere hebben, dit is niet uit te sluiten!

 

Perdonna me!

 

MVG

Stef

[Koen Van Hulle]

Nog iemand in de zaal die ervaring heeft met de twee? Anyone?

 

Met Servoy niet, met SQL databanken wel. Toegegeven als je weet hoe je zo'n omgeving moet gaan beheren en configureren, heb je een heel stabiele omgeving. Het zou anders ook nie zoveel ingebruik zijn.

 

Ook de kracht en snelheid van zo'n databank kan bij complexe systemen soms niet geevenaard worden in FileMaker. (Als het goed geconfigureerd en geschreven is, want ik heb Oracle databanken zien vooruit kruipen). Alleen, inderdaad niet voor Jan met de pet.

 

Ik heb niet meer en ook niet minder problemen met FileMaker dan met andere omgevingen. Ze zijn vaak anders. In de één wat meer vrijheid, in de andere overgeleverd aan de keuze (en de bugs) van de ontwikkelaars van die omgeving.

 

 

Koen

Nb: Het grootste probleem met het uitbrengen van een product is, inderdaad het kunnen blijven supporteren van het product, het goed kunnen aflijnen van bijkomende functionaliteit in volgende versies, handleidingen, opleidingen, ...

Als je dat allemaal bij elkaar telt, en de tijd die je er instopt, en wat je er uiteindelijk van terugkrijgt, is het vaak de moeite niet waard. Zeker als je het als een nevenactiviteit wil gaan zien, en het gevaar opduikt dat het je hoofdactiviteit in de weg gaat zitten.

[Stef]

Ook de kracht en snelheid van zo'n databank kan bij complexe systemen soms niet geevenaard worden in FileMaker. (Als het goed geconfigureerd en geschreven is, want ik heb Oracle databanken zien vooruit kruipen).

 

Volledig akkoord! Alles valt te misbruiken!

 

Alleen, inderdaad niet voor Jan met de pet.

 

Niet mee akkoord. De kracht van Servoy is dat je met méér gemak dan in Filemaker gebruik kunt maken van de kracht van SQL, zonder die code te moeten kennen. Dus wél voor Jan met de Pet, anders had ik het niet kunnen doen.

 

Nb: Het grootste probleem met het uitbrengen van een product is, inderdaad het kunnen blijven supporteren van het product, het goed kunnen aflijnen van bijkomende functionaliteit in volgende versies, handleidingen, opleidingen, ...

Als je dat allemaal bij elkaar telt, en de tijd die je er instopt, en wat je er uiteindelijk van terugkrijgt, is het vaak de moeite niet waard. Zeker als je het als een nevenactiviteit wil gaan zien, en het gevaar opduikt dat het je hoofdactiviteit in de weg gaat zitten.

 

Dat hangt van je levensvisie af, en we moeten soms af van onze Europese bescheidenheid en er gewoon voor gaan!

 

Voor mij zijn er 2 keuzes:

-ofwel doe je maatwerk en moet je veel sparen voor je pensioen als zelfstandige. Als je stopt met werken stopt nl. ook je inkomen

 

-ofwel tracht je iets op te bouwen dat verkoopbaar is of dat geld blijft opbrengen en een organisatie rond kunt bouwen. Is natuurlijk een grotere gok en vereist véél geduld.

 

Ik kies voor het tweede.

Dus Alex: go for it! Probeer! Vecht! Verspreid! Natuurlijk kan het! Geloof erin!

(en kies de juiste tool).

 

Groeten!

Stef

[Koen Van Hulle]

Dat er bij het op de markt brengen van een product, je moet denken aan support, handleidingen, evt opleidingen, volgende releases, ... dat indien je succes hebt, daar meer tijd inkruipt dan je vaak hebt voorzien.

 

Als software bouwen niet je hoofdbezigheid is, is het gevaar er, dat je ander werk blijft liggen. Dit is inderdaad een keuze en het stellen van prioriteiten.

 

Als je hoofdzaak software bouwen is het een ander verhaal.

 

Niet mee akkoord. De kracht van Servoy is dat je met méér gemak dan in Filemaker gebruik kunt maken van de kracht van SQL, zonder die code te moeten kennen. Dus wél voor Jan met de Pet, anders had ik het niet kunnen doen.

 

Akkoord, als het om het bouwen van een toepassing gaat. Niet akkoord als het om het opzetten, onderhouden, maintainen van je databank (niet je toepassing) gaat. De keuze van het juiste merk databank, voor de juiste klant is cruciaal.

 

Koen

[Peter Wagemans]

Ik stel voor dat we op topic blijven. Alex wou geen vergelijking tussen FileMaker en andere toepassingen, maar ervaringen over de problematiek van een FileMaker "product" uit te brengen.

[Stef]

Ik stel voor dat we op topic blijven. Alex wou geen vergelijking tussen FileMaker en andere toepassingen, maar ervaringen over de problematiek van een FileMaker "product" uit te brengen.

 

Allé! Het werd juist gesjellig!

 

ok Pete, we hebben het gehad.

Maar gij zijt begonnen, ik waagde het niet! Ik vind mijn antwoord toch vrij braaf en informatief achteraf gelezen...

 

Och, als we er allemaal maar wat wijzer van worden vind ik deze discussies nog zinvol.

 

Ik vind persoonlijk dat een oplossing in Filemaker verspreiden niet echt kan.

Stel je voor dat Alex door deze discussie overstapt naar een andere tool dat er meer voor geschikt is (en dan zeg ik niet dat S-ding) , dat het na een tijdje supergoed werkt, dat hij steenrijk wordt en op een caraïbisch eiland zich terugtrekt en voor de rest van zijn leven zich platlacht met cubalibres? Dan heeft dit toch nog voor iets gediend.

 

Bestaat er zoiets als een forum voor ALLE platformen, ALLE ontwikkelomgevingen en business initiatieven met freedom of speech?

Ik denk dat ik daar meer thuis hoor...

 

Cheers!

Stef

[alex]

hahahahahahaha, pfffff, heb t gevoel dat ik ergens op een verkeerde RODE knop heb gedrukt.

 

enfin, ik ben GEEN programmeur en ook GEEN database- of programmeertijger/diehard/guru/wizzard/whatever. ik ben slechts een eenvoudig grafisch ontwerper die eerst en vooral geïnteresseerd is in, en gefascineerd wordt door ‘user experience’ (excusez le mot).

 

vertellen jullie me nou s één ding: waarom zijn databaseinterfaces toch altijd (ik weet het, jullie zijn allemaal uitzondering zijn op de regel zo L E L I J K en R O M M E L I G en O N G E B R U I K S V R I E N D E L I J K ?

 

...ok, pilletje ingenomen en nu weer rustig...

 

maar echt. als jullie techneuten (respect!) nou ook es een cursusje interface design zouden doen zou ik het niet allemaal zo nodig op mn eigen manier moeten doen...

 

beste groet, a

[JeanWM]

...waarom zijn databaseinterfaces toch altijd zo L E L I J K en R O M M E L I G en O N G E B R U I K S V R I E N D E L I J K ? ....

 

...omdat wij allemaal nogal menen te weten waarom we een veld, calculatie, key, relatie portal en nog wat dingetjes nodig hebben om het geheel werkend te krijgen. Of het écht is wat de klant vraagt is ook al een andere discussie als ik sommige databases zie.

 

Achter de schermen is het al een rotzooi. En nu zou je nog willen dat vóór de schermen het er nog mooi en gebruiksvriendelijk, logisch is.

 

Ik zorgde er voor dat ik alles netjes op orde kreeg achter de schermen, technisch gezien.

Ik denk hier enkel nog maar aan de veldbenamingen. Die moeten duidelijk zijn, zodat je (of ieder ander die daar toegang toe heeft) wéét over wat het gaat.

Ik zag (en zie nog steeds) zaken zoals:get_author_names_and_addresses

(kan het nog langer aub) of ytirucesboj21548264 (is waarschijnlijk bedoeld als jobprotectie).

 

Wat zichtbaar moest zijn voor de gebruiker heb ik laten 'ontwerpen' door iemand die daar verstand van heeft/had. En altijd in samenspraak met de 'klant'. (... al gezien hoeveel verkeerde kleurcombinaties er zitten in sommige databases en om nog maar van alle gebruikte icoontjes te zwijgen...)

 

Is geen volledig garantie dat het altijd goed zal zijn...

 

Het is als het verschil tussen het rijden met een auto en een trein.

Iedereen kan wel aan een rijbewijs raken om te rijden met een voertuig dat alle kanten op kan, op het zelfde ogenblik dat honderden anderen dezelfde activiteit doen (en even ondoordacht), terwijl voor het besturen van een trein, die in principe alleen maar vooruit of achteruit kan en helemaal niet opzij, zeker niet van 'zijn baan zal afwijken', heb je een jarenlange opleiding nodig.....

 

Als je het gevoel hebt dat je toepassing rijp is voor 'anderen', ga op zoek naar die anderen, vertel de wereld wat je hebt en maak er het beste van...

[Peter Wagemans]

Mijn collega Danny is bij ons zo beetje de "interface guru", hij deelt alex zijn mening over dat een rommeltje is.

 

De meeste gevorderde ontwikkelaars zijn gewoon te geeky om ook nog eens een mooie en duidelijke interface op hun werk te plakken.

De meeste beginners zijn nog erger... tenzij ze kaas gegeten hebben van design. Op de Mac kom je die gelukkig wat meer tegen.

 

Alles loopt een beetje in elkaar. Danny schreef ook een freeware "development guidelines" PDF, en zette zijn interface en ordeningsdriften om in een development template file, die we hier in het bedrijf altijd als startpunt gebruiken voor elke nieuw project.

 

Op die manier hoeven we ons niet te veel zorgen te maken over "of het wel mooi is", en een aantal tabellen en layouts met strict afgesproken structuren zitten er al in, zodat het development ook veel sneller vordert.

 

Heel wat developers doen dat, wij proberen dat met zo'n man of 10 te doen, en dat is niet altijd gemakkelijk. Dat smaken verschillen is 1 ding, maar ieder van ons heeft zo zijn manier van programmeren, en zo'n template moet op dat gebied als het ware de gulden middenweg bewandelen.

[JeanWM]

... en als Alex nu eens een

stoomcursusje interface design

in mekaar zou boksen, iets in de aard van do's en don't's, en dat als shareware op de ( FM ) markt brengt.....

 

... of bestaat er al zoiets. Buiten Matt's heb ik nog niet veel gevonden....

[Peter Wagemans]

maar echt. als jullie techneuten (respect!) nou ook es een cursusje interface design zouden doen zou ik het niet allemaal zo nodig op mn eigen manier moeten doen...

... en als Alex nu eens een

Quote:

stoomcursusje interface design

in mekaar zou boksen, iets in de aard van do's en don't's, en dat als shareware op de ( FM ) markt brengt.....

Borg serving... of speelt die geen ping pong...

 

Als we het nu eens aan Danny vragen?

[JeanWM]

Als we het nu eens aan Danny vragen?

 

Geen probleem mee...als iemand het maar eens doet.

 

Uit (klas)ervaring weet ik dat er nood is aan degelijke begeleiding op dat vlak.

We modderden zelf wat aan, tot ik naar de marketing opleiding afdeling van de univ ben gestapt om daar wat documentatie op te halen.

 

Technisch zitten onze bestanden vrij goed in mekaar, nu het uitzicht nog...

 

.. en daar ben ik geen specialist in...

[Peter Wagemans]

Ik heb'm een privé berichtje gestuurd. Misschien vervoegd Danny ons binnenkort.