colombo

Het is inderdaad interessant te weten wie de app gebruiker zijn maar het is nog meer interessant waarvoor deze apps dan gebruikt worden. Met de combinatie van deze gegevens weet je dan waar mogelijke kansen liggen. Neem bijvoorbeeld verzekeringen, wil je nu een bepaalde groep (jongeren) bereiken dan maak je een app met een paar vragen verdeeld over een paar schermen om een eerste schifting te maken.

Is het niet zo dat je de auto voor minimaal 10% zakelijk moet gebruiken om de auto als zakelijk te bestempelen? Ik lees dat TS van plan is de auto 100% prive te gebruiken. Maar BD zegt volgens TS: Bij 100% prive gebruik je de auto NIET helemaal of gedeeltelijk dus deze vlieger gaat dan niet op. Ik heb het vermoeden dat de BD deze constructie van zakelijk IB en prive OB niet zal accepteren bij 100% prive gebruik.

De "Hot or Not" app. ;D Ik heb al zo'n vermoeden wat voor app dat is. 15 jaar geleden was er ook al een website waarbij je cijfers kon geven bij foto's. Bij apps geldt, 100 keer schieten en 1 keer raak. Die markt is zo groot en voor je het weet is een goed idee al gekaapt door een ander die een mooiere app kan maken.

Onderstaande reactie wilde je graag een reus geven. Maar de basis om dit mogelijk te maken is toch een bestaande website op basis van HTML5 en Javascript, of zie ik dat verkeerd? Dus een wrapper om een dergelijke webapp om het zo als een "echte" app te laten lijken vind je wel acceptabel, maar enkel de webapp die als basis dient vind je van niet. De vraag is: "Hoe zelf een app maken". Mijn bescheiden mening is dat een webapp geschikt voor mobiel gebruik ook prima kan functioneren als een app en dus ook als app gezien mag worden. Maar ook hier geldt: Waarvoor dient het en wat is je doelgroep.

Ik geef mijn mening als professional (van de oude stempel) met een bepaalde visie over software ontwikkeling. En ja je kunt van alles zelf in elkaar klikken, dat doen een aantal zichzelf benoemde "specialisten" trouwens ook, maar met een klein beetje meer moeite kun je ook gaan voor een betere oplossing en eenvoudiger oplossing. Maar ik bespeurde al eerder uit je reacties dat je graag wilt horen wat je vooraf graag wilde horen. Het kan ook zijn dat ik erg conservatief in mijn houding ben als ik zeg dat ik enkel apps gebruik voor social media, bankieren, parkeren, OV, nieuws en spelletjes spelen. En al die andere apps kunnen me gestolen worden, af en toe installeer ik dan een (volgens anderen) "interessante" app die ik vervolgens binnen twee weken alweer verwijderd heb. Overigens heb ik nog geen reden gelezen waarvoor en waarom de app nodig is.

Uiteraard kies je de techniek die voor een bepaalde toepassing het meest geschikt is, en dat is wat mij betreft HTML5 / JavaScript (al dan niet vanuit TypeScript gecompileerd) voor de frontend, Java voor de backend en JSON over REST voor de interfaces. Een interessante ontwikkeling is Scala.js waarbij je de webapp in Scala bouwt en dit laat compileren naar JavaScript. Een andere interessante ontwikkeling is Nashorn waarmee je JavaScript in de JVM kunt draaien. ps. Een paar jaar geleden heb ik wat zitten stoeien met een Android plugin in Eclipse en ik werd niet echt vrolijk, ondanks mijn ervaring met Applets/AWT/Swing en eerder met Motif/XView/Xlib. Het gaf me toen een net-niet gevoel.

Het is inderdaad wat ongelukkig geformuleerd.

Het van scratch handmatig opbouwen van een native (Android) app kan voor een ervaren (Java) ontwikkelaar al een flinke kluif zijn, laat staan voor iemand zonder programmeerkennis. Zelf ben ik overigens voorstander van native apps, maar waarom zou je dat pad op gaan met JavaScript in je achterhoofd. De toekomst ligt toch echt in JavaScript, althans alle seinen lijken op dit moment die kant uit te wijzen.

Zelf zou ik een app simpel en overzichtelijk houden en dan volgt hieruit dat het aantal user stories beperkt zal zijn. Voor bijvoorbeeld een bestaande webapplicatie selecteer je een aantal functionaliteiten die je ook via een app beschikbaar wilt stellen. Neem als voorbeeld een administratie voor je bedrijf, het invoeren van een boeking of woon-werk kilometers kan dan best via een app. Succesvolle apps zijn doorgaans eenvoudige apps!

Daar is geheel niets mis mee.... behalve dat dat de vraag niet was waar ik deze thread mee begon ;-) Mijn opmerking moet je meer zien als de tegenvraag. Waarom moet het een "echte" app zijn? Wat mij betreft is het de stelregel: Maak een website die (ook) op een mobiel gebruikt kan worden, tenzij ...

Wat is er mis met een website maken die geschikt is voor mobiel gebruik? Je hebt dan geen toegang tot lokale resources, maar je moet eerst nagaan of dat werkelijk nodig is. En je "app" is niet vindbaar via de appstore, maar is dat ook nodig?

Ik zou zeggen: Schoenmaker blijf bij je leest! Als krediet verstrekking niet tot de activiteiten van je onderneming horen dan zou ik het er ook niet op deze manier onder scharen.

En welk document/specificatie gebruik jij dan als start voor het bouwen van een klant-website ? https://en.wikipedia.org/wiki/User_story

Je zou er in dit geval bij dit soort kleine bedragen voor kunnen kiezen de BTW over de verzendkosten voor eigen rekening te nemen.

Dat weet ik wel zeker! Vandaar dat ik me in eerdere reacties richtte op de frontend.

Ik ga het eens een keer proberen. Zelf denk ik aan een case voor het bijhouden van de boekhouding. Dit doe ik nu in een Excel-sheet, maar er zijn al een aantal formules flink uit hun jasje gegroeid. Overigens heb ik uit de nabije omgeving wel goede verhalen gehoord. Al blijf ik wel sceptisch gezien de reputaties van voorgaande producten. De afgelopen jaren heb ik enkel aan projecten gewerkt waarbij alles zelf met het handje geklopt werd. Vorig jaar heb ik wel even mogen snuffelen aan Blueriq, maar ik kan niet zeggen dat ik daar echt vrolijk van werd. Zelf ben ik overigens meet een backender en ik word wel weer vrolijk van de ontwikkelingen die daar de afgelopen jaren hebben plaatsgevonden. Overigens werk ik weinig aan de frontend, maar mijn mening is wel dat hier een behoorlijk gat zit. JSF heeft in mijn ogen de beloften nooit waar kunnen maken en AngularJS is mijns inziens veel te complex en fout gevoelig. @Jeroen. Mijn post was meer een reactie op wat onzinnige beweringen over webdesign. Overigens heeft het wel zeker een relatie met een product als Mendix. Het is bekend dat je bij gebruik van een dergelijke tool minder flexibel bent en minder controle hebt op de GUI. Ik zou wel eens willen weten hoe dat ervaren wordt bij Mendix.

Hoe is hij vanochtend dan op kantoor gekomen? Met de auto? Mijn gedachte is dat je zoiets niet zomaar vergeet. Zelf had ik de beste man naar huis gestuurd met de opdracht zijn rijbewijs op te halen omdat het NU noodzakelijk is voor de administratie.

Een goede website ontwerpen is toch wel een vak apart en bij een professionele website heb je echt de hulp nodig van een interaction designer. Alleen die worden weer niet zo vrolijk van de bagger HTML en JavaScript die door allerlei tools gegenereerd wordt, die willen graag zelf controle hebben over eenvoudige HTML die ze met CSS helemaal naar eigen inzicht kunnen stylen. Er is wel een trend waarneembaar om websites simpel en herkenbaar te houden met vooral een eenduidige look&feel.

Ik heb ook geen ervaring met Mendix maar ik geloof zeker in Low-Code voor de GUI. Maar een applicatie bestaat nu eenmaal uit meerdere lagen en grote delen van applicaties en services zijn niet eenvoudig of beter gezegd onmogelijk te modelleren. En daar geloof ik dan in Lower-Code, dus minder code maar wel krachtiger. Daarbij is er een duidelijke trend naar reactive programming, bijvoorbeeld Akka. Zoeken op de woorden Mendix en Akka levert resultaten die er op duiden dat Mendix onderwater Akka en Scala gebruikt en dat is wat mij betreft een goed teken. Er is wel een "Start for Free" optie. Ik ben benieuwd hoe lang de periode is dat je free mag starten. Voor ontwikkelaars is een gratis ontwikkelomgeving een vereiste om dit soort concepten verder te verspreiden, anders blijft het een gesloten omgeving waarbij Peter terecht opmerkt dat bijvoorbeeld voor de MKB al snel sprake is van een mismatch.

Als ik Wehkamp moet geloven dan zijn ze qua ontwikkeling van de website state of the art. Op dit moment loopt er een pilot in Belgie en binnenkort wordt de website overgezet naar Nederland.

Kijk eerst of het wel interessant is om de auto zakelijk aan te merken. De regeling voor youngtimers lijkt lucratief te zijn maar het voordeel valt al snel weg als je veel zakelijke kilometers en weinig prive kilometers rijdt.

Voor de lezing is het denk ik wel terecht dat het eten als zakelijk gezien wordt, maar bij die broodjes onderweg heb ik wel zo mijn twijfels. Dat is inderdaad het criterium. De grens is een beetje vaag en wellicht ben ik net even te braaf. Mijn indruk is echter wel dat er genoeg ondernemers zijn die het allemaal te vrij nemen.

Ik gebruik liever de term W&V berekening, of sterker liever Winstberekening. ;)

Er zullen ongetwijfeld uitzonderingen en nuances zijn maar de stelregel is dat zaken als ontbijt/lunch/avondeten onder de normale dagelijkse behoeften vallen en daarom niet zomaar zakelijk aftrekbaar zijn. Om een voorbeeld te noemen. Ik ben bij een sessie geweest over dit soort fiscale zaken gegeven door een guru op dit gebied. Voorafgaand aan de sessie heb ik mijn avondeten genuttigd in het inpandige restaurant waar de sessie gehouden werd. Na afloop heb ik nog wat vragen gesteld over welke invloed mijn bezoek heeft op de administratie, denk hierbij aan reiskosten / uren / kosten bezoek sessie enz. Ik eindigde met de opmerking: "Maar het eten wat ik vooraf genuttigd heb moet ik beschouwen als regulier avondeten en is daarom niet aftrekbaar." Ik kreeg hierop een bevestigend antwoord omdat er inderdaad geen sprake was van een zakelijk doel, het was volledig mijn eigen keuze om daar mijn avondeten te genieten.

Ja, maar dat maakt de lunch niet meteen tot een zakelijke lunch. Ieder mens wordt geacht te eten omdat je niet kunt leven zonder eten. Het hoort gewoon bij je normale dagelijkse behoefte. Je had er ook voor kunnen kiezen wat boterhammen van huis mee te nemen.