verder ontwikkelen .Net Framework of overstappen op Android

[Akrapovic58]

Wij zijn een klein tot middelgroot bedrijf (uit België) en actief in de privé expertise wereld, met name schade-expertise (na brand, waterschade, stormschade,...)

Wat we doen in een notendop: Als er een huis afgebrand is, gaan wij ter plaatse, maken een inventaris van alles wat beschadigd is, constructief gezien, inboedel, dakwerken,... . Aan de hand hiervan trachten we tot een totaalsom te komen die we dan verdedigen bij de verzekeringsmaatschappij.

Anderhalf tot twee jaar geleden hebben we een firma aangenomen om hier een software pakket te schrijven en zo dit proces te digitaliseren. Omdat we dit goed wouden doen en veel werk hebben, zitten we momenteel met een voltooiing van ongeveer 60% - 70%.

De software is geschreven in .Net Framework van Microsoft. Voor de input zouden we gebruik maken van een tablet met Windows als besturingssysteem. Echt ingewikkelde software is het zeker niet. Hij moet enkel overweg kunnen met een grote database en moet absoluut geen ingewikkelde berekeningen maken. Enkel bij de output naar Excel misschien. Dit zou eventueel zelf op een aparte desktop kunnen.

Met het zoeken naar een geschikte tablet kwam steeds hetzelfde probleem terug. De meeste tablets draaien op Android. We hebben een Windows tablet van Archos, maar deze is absoluut niet snel genoeg en de touchscreen is niet precies genoeg. Veel andere opties zijn er voorlopig niet en de meeste Windows tablets zijn redelijk traag en hebben een korte batterijduur.

We hebben de vraag reeds gesteld aan de firma die de software ontwikkelt of ze niet kunnen overschakelen op Android. Voor hen is dit geen optie. Ze hebben al het werk al in .Net framework reeds gedaan en kunnen niet programmeren in Android. Natuurlijk horen ze onze vragen hierover niet graag komen, want dan zouden ze hun opdracht kwijgeraken.

We hebben reeds al enkele 10000 euro hieraan gespendeerd, dus zomaar opnieuw beginnen is niet zomaar een optie.


Nu was mijn vraag wat jullie onze kunnen adviseren hieromtrent:


1) de software proberen te converteren en verder gaan in Android (mogelijk?)

2) de software afwerken en dan proberen te converteren (mogelijk?)

3) de software afwerken en elke keer proberen te converteren na elke update (mogelijk?)

4) bij het .net framework blijven

5) helemaal opnieuw beginnen in Android

6) ...


Wij zijn niet echt op de hoogte van alle programmeertalen en die hierbij horende problemen, dus elk advies is meer dan welkom.

Als je meer details nodig hebt, vraag ze zeker!


alvast bedankt


Update :
------------

- de belangrijkste: de applicatie moet snel zijn, niet "mooi & fancy" zijn. (kijkend naar de iPad snelheid)
- de software moet stand-alone zijn, zonder continu verbinding kunnen werken.
- bij voorkeur met een centrale database-file, waar je naar eigen behoeft de eigen file kunt inladen
- de tablet moet fysiek niet te zwaar zijn. (cfr. een hele dag op je arm mee werken)
- wat met de toekomst, rekening gehouden met de kosten - baten

[ Voor 7% gewijzigd door Akrapovic58 op 03-02-2011 14:04 ]

[creator1988]

Normaal gesproken bij dit soort software is er een voorkant en een achterkant. De achterkant staat op een server en verwerkt alle gegevens; slaat deze op in een database, etc. Hier zou het meeste werk in moeten zitten.

De voorkant is in dit geval het programma op de tablet; hier zou relatief gezien minder werk in moeten zitten. Mocht het voorgenoemde kloppen (dit zou ongeveer in de offerte of het TO (mits jullie die hebben gezien) moeten staan), dan zou om over te stappen op Android alleen de voorkant herschreven moeten worden; de achterkant kan dan gewoon in .NET blijven. Zou relatief gezien dus heel wat minder impact moeten hebben dan het herschrijven van de hele applicatie; je kan hiervoor gewoon een ontwikkelclub benaderen die gespecialiseerd is in Android applicaties en die laten samenwerken met je bestaande partij.

[Verwijderd]

Mijn tip zou zijn. Werk het project in .NET af (met Webservices zodat je er over internet aan kunt) en laat dat draaien op een server.
Maak dan een applicatie in Android die dan connectie kan maken naar die webservices want een database op een android tablet zetten is niet echt een slimme zet. En zo een applicatie volledig gaan maken in Android lijkt me ook wel zwaar voor een android toestel wat dan hoogstwaarschijnlijk ook geen snelle applicatie meer zal zijn.

[SaphuA]

.

[ Voor 139% gewijzigd door SaphuA op 01-02-2022 16:26 ]

[NMe]

Opties 1, 2 en 3 zijn sowieso al niet mogelijk.

Verder heb ik zo mijn twijfels bij een ontwikkelbedrijf dat je niet vertelt dat je applicatie helemaal niet (snel) gaat werken op het device waar ze voor ontwikkelen. En het is op zijn zachtst gezegd natuurlijk niet slim om eerst het ontwikkeltraject in te gaan en daarna pas eens op de markt te gaan kijken.

Als de app inderdaad pas voor 60% af is hangt het van de werkbaarheid in Windows af of je al dan niet door moet gaan, alsook van het al dan niet goed opgezet zijn van het serverdeel. Een nieuwe Android-app laten praten met een reeds opgezette webservice is kinderspel, maar als de gemaakte webservice zich daar niet voor leent kan het rendabeler zijn om het project vroegtijdig te annuleren. Maar dat zul je aan de ontwikkelaars voor moeten leggen.

[Hydra]

SaphuA schreef op donderdag 03 februari 2011 @ 10:39:
Ben het een met de twee hierboven.

Als het software bedrijf de applicatie goed in elkaar heeft zitten zouden ze de voorkant (interface) in principe los moeten kunnen koppelen en de rest kunnen aanbieden als een service. Je zou dan een ander bedrijf deze voorkant in Android kunnen laten ontwikkelen. Let wel op dat je dan een fatsoenlijke (lees: snel en betrouwbaar) internet verbinding nodig zult hebben, want ik begrijp dat het om nogal wat data gaat?

Niet om 't een of 't ander, maar als het vooraf geen requirement gaat zijn dat een applicatie verserviced moet kunnen worden, en de hele applicatie standalone draait, dan gaan ze daar echt geen rekening mee houden omdat misschien "in de toekomst" dat opeens wel zou moeten. Het is niet aan hun om een glazen bol als developmenttool in te zetten.

Mijn bedrijf heeft ook de fout gemaakt een applicatie in .Net te ontwikkelen en er later achter te komen dat dat door gebrek aan cross-platform compatibility een issue zou worden. Dat is dus later from scratch herschreven in Java.

Veruit de goedkoopste oplossing voor de TS is gewoon bij windows-tablets te blijven. Als dat geen optie is komt er een hoop herschrijfwerk aan te pas waarbij je sowieso met een extra ontwikkelpartij zit (de huidige geeft aan dat ze niet aan Android ontwikkelen doen), wat laten we zeggen een interessante "dynamiek" op gaat leveren.

[Akrapovic58]

Alvast bedankt voor uw duidelijke en recht voor de raap reacties.


De app werkt niet in twee delen via een server opzet, maar volledig onafhankelijk.

Om te testen hebben we momenteel hiervoor een Archos 9. Deze heeft slecht 1 gb ram, wat veel te weinig blijkt. Bijplaatsen of vervangen is geen optie, omdat het geheugen vastgesoldeerd zou zitten. Ook de touch screen werkt niet snel en precies genoeg.

De bedoeling is dat we met de tablet in een (afgebrand) gebouw gaan staan en ter plaatse onze staat opmaken.
De inventaris is momenteel +/- 5000 records en zou continu aangevuld worden.
Een zeer eenvoudig voorbeeld:

pleisterwerk: b= 2m h = 3m => 6m² pleisterwerk aan 22€ = 132€

Ik vermoed dus dat de inventaris op de tablet moet staan.
Belangrijk voor ons is dat de tablet snel en precies (touch) werkt. Steeds weer denken we ah voorbeeld van een iPad.


Bij het opstarten van de software was er blijkbaar nog niet zoveel bekend hieromtrent (en het bedrijf wou natuurlijk de opdracht binnenhalen). Nu staat de tablet wereld al heel wat verder...

[Akrapovic58]

Hydra schreef op donderdag 03 februari 2011 @ 11:36:
[...]


Niet om 't een of 't ander, maar als het vooraf geen requirement gaat zijn dat een applicatie verserviced moet kunnen worden, en de hele applicatie standalone draait, dan gaan ze daar echt geen rekening mee houden omdat misschien "in de toekomst" dat opeens wel zou moeten. Het is niet aan hun om een glazen bol als developmenttool in te zetten.

Mijn bedrijf heeft ook de fout gemaakt een applicatie in .Net te ontwikkelen en er later achter te komen dat dat door gebrek aan cross-platform compatibility een issue zou worden. Dat is dus later from scratch herschreven in Java.

Veruit de goedkoopste oplossing voor de TS is gewoon bij windows-tablets te blijven. Als dat geen optie is komt er een hoop herschrijfwerk aan te pas waarbij je sowieso met een extra ontwikkelpartij zit (de huidige geeft aan dat ze niet aan Android ontwikkelen doen), wat laten we zeggen een interessante "dynamiek" op gaat leveren.

Spot on. Het is dan ook nu aan ons om hierover goed na te denken.

Ik betaal de rekening echter niet en neem geen beslissingen, ik geef enkel wat (gebruikers) advies. Ik werk hier ook pas een dik jaar.

We zijn gewoon op zoek naar een goed werkende tablet en software. De tablet moet niets anders kunnen...
Voorlopig hebben we nog geen goede tablet gevonden. Telkens opnieuw botsen we tegen Android en Mac OS aan.

[ Voor 3% gewijzigd door Akrapovic58 op 03-02-2011 11:46 ]

[zwippie]

badslats schreef op donderdag 03 februari 2011 @ 11:40:
...

Om te testen hebben we momenteel hiervoor een Archos 9. Deze heeft slecht 1 gb ram, wat veel te weinig blijkt. Bijplaatsen of vervangen is geen optie, omdat het geheugen vastgesoldeerd zou zitten. Ook de touch screen werkt niet snel en precies genoeg.

...

Zijn er dan al tablets met meer dan 1GB RAM? Volgens mij niet, maar ik kan het mis hebben.

[drice]

Ik begrijp dat het een stand-alone applicatie is. Wat op zich wel te begrijpen is omdat je in het veld niet altijd de garantie hebt van een beschikbaar netwerk. Maar je mag toch aannemen dat een medewerker deze gegevens op een gegeven moment synchroniseert met een server waar alle logica zit.

Het creeeren van een 'invoerapplicatie' die later synchroniseert op android lijkt me niet al te lastig realiseren.
Maar dit is echt iets wat de huidige ontwikkelaar moet aangeven omdat die er het meest in zitten.

Tevens zou je kunnen kijken naar zogenaamde thoughpad's. Dit zijn laptops die speciaal bedoeld zijn voor veldwerk. Hier kun je windows op draaien en zelf geheugen in zetten.

[NMe]

No offense, maar jullie zijn gewoon bedot. Dit soort applicaties zonder client/serverstructuur doen betekent dat je na elke wijziging in de database de app moet gaan updaten. Lekker onpraktisch. Daarnaast was een jaar geleden ook wel duidelijk dat Windows op de tabletmarkt voorlopig maar een kleine speler zou worden. Android was toen misschien nog niet de logische eerste keus, maar de iPad wel.

Als jullie voor jezelf duidelijk hebben dat de Windowsversie niet praktisch is dan kun je waarschijnlijk beter je verlies nemen en beginnen aan een fatsoenlijke app voor Android die wel met een client/server-structuur werkt. Die client is dan vervolgens heel makkelijk te herschrijven voor andere platforms.

[Sick Nick]

Er zijn genoeg windows tablets te koop die flink sneller zijn dan die archos, dat is een traag ding met een atom, ipod harde schijf en een slecht scherm (daar waren jullie al achter). Kijk eerder naar iets als een lenove X201 tablet of een HP EliteBook 2740p (of de consumentenvariant de TM2). Dat zijn veel snellere convertible laptops. Ja ze zijn zwaarder en flink duurder dan een archos maar de aanschaf van een paar van die dingen is nog altijd veel goedkoper dan de investering die al is gemaakt weg te gooien.

[Hydra]

NMe schreef op donderdag 03 februari 2011 @ 11:52:
No offense, maar jullie zijn gewoon bedot.

Sorry maar dat vind ik erg kort door de bocht. Jij kent de applicatie noch de originele requirement. Misschien wordt er op kantoor wel periodiek een niewe datafile overgezet. Je moet geen conclusies gaan trekken voordat je alle info hebt.

Dat client-server verhaal van je is erg leuk, maar het kan zijn dat er in de requirements sprake van is dat er geen netwerkverbinding mogelijk is op lokatie, en dan is een centrale server geen optie en zul je dus de database lokaal moeten hebben. Die kun je prima periodiek syncen als je op kantoor bent.

[ Voor 28% gewijzigd door Hydra op 03-02-2011 11:57 ]

[Noxious]

Een andere optie is om de tablets uit te rusten met een internetverbinding en gebruik te maken van Citrix (bijv) en daarmee de applicatie te draaien op een server.

Grootste risico is het niet overal aanwezig zijn van een internetverbinding helaas.

Overigens vraag ik me af hoeveel werk er precies in zit? Dit project klinkt niet als iets wat jaren werk kost, zeker daar het eigenlijk alleen maar het inkloppen van data is...

[RobIII]

drice schreef op donderdag 03 februari 2011 @ 11:51:
Het creeeren van een 'invoerapplicatie' die later synchroniseert op android lijkt me niet al te lastig realiseren.

Levensgevaarlijke uitspraak. Je hebt namelijk geen benul wat die applicatie nou precies doet (op wat vage beschrijvingen van TS na). Als ze al 2 jaar bezig zijn en nu op 60-70% van het totale project zitten dan lijkt me de "niet al te lastig realiseren" uitspraak me een tikkie voorbarig True, misschien is er maar 10 uur gespendeerd aan de applicatie en de overige 2 jaar aan een "server kant" (als die er al is) maar ik vermoed van niet

Hydra schreef op donderdag 03 februari 2011 @ 11:55:
[...]


Sorry maar dat vind ik erg kort door de bocht. Jij kent de applicatie noch de originele requirement. Misschien wordt er op kantoor wel periodiek een niewe datafile overgezet. Je moet geen conclusies gaan trekken voordat je alle info hebt.

Dat client-server verhaal van je is erg leuk, maar het kan zijn dat er in de requirements sprake van is dat er geen netwerkverbinding mogelijk is op lokatie, en dan is een centrale server geen optie en zul je dus de database lokaal moeten hebben. Die kun je prima periodiek syncen als je op kantoor bent.

Eensch. Er is, voor ons hier, gewoon veel te weinig bekend over de originele requirements en het hele project om echt zinnige uitspraken te doen hierover. Maar ik zet inderdaad wel ook een klein vraagteken bij de uitvoering en heb een klein onderbuikgevoel dat er inderdaad iets niet helemáál slim is aangepakt. Maar meer dan een onderbuikgevoel is het dan ook niet en zoals gezegd hebben we te weinig info om er keiharde uitspraken over te doen.

[ Voor 45% gewijzigd door RobIII op 03-02-2011 11:59 ]

[Hydra]

RobIII schreef op donderdag 03 februari 2011 @ 11:56:
Levensgevaarlijke uitspraak. Je hebt namelijk geen benul wat die applicatie nou precies doet (op wat vage beschrijvingen van TS na). Als ze al 2 jaar bezig zijn en nu op 60-70% van het totale project zitten dan lijkt me de "niet al te lastig realiseren" uitspraak me een tikkie voorbarig True, misschien is er maar 10 uur gespendeerd aan de applicatie en de overige 2 jaar aan een "server kant" (als die er al is) maar ik vermoed van niet

Misschien moeten 'we' gewoon eens ophouden met het trekken van allerhande voorbarige conclusies? Dat er in een periode van 2 jaar ontwikkeld is betekent niet dat er ook 2 manjaar in zit. Vooral gezien er maar 10k betaald is voor de applicatie tot nu toe, daar ontwikkelen wij ongeveer 2 weken voor.

Laten we gewoon focussen op de vraag van de TS.

[bredend]

Over een half jaar zijn er veel meer Windows tablets die sneller zijn dan de Archos 9. Ik weet niet wanneer de software klaar is maar wellicht kan je daar op wachten.

Wel raar dat 1GB geheugen te weinig is voor dat programma. Ik heb niet het idee dat het zo ontzettend zwaar programma zou hoeven zijn.

[RobIII]

Hydra schreef op donderdag 03 februari 2011 @ 11:59:
[...]


Misschien moeten 'we' gewoon eens ophouden met het trekken van allerhande voorbarige conclusies?
...
Laten we gewoon focussen op de vraag van de TS.

Dat is mijn hele punt Zie ook mijn edit

[ Voor 9% gewijzigd door RobIII op 03-02-2011 12:00 ]

[Akrapovic58]

bedankt voor uw reacties.

Er zou een algemene database zijn waar we ons persoonlijk toestel kunnen mee synchroniseren. Maar enkel dan om een "nieuwe inventaris in excel" in te laden, verder niets. De software kan via mail doorgestuurd, geïnstalleerd en gebruikt worden zonder één enkele verbinding. Echt "zwaar" is het dus zeker niet. Het moet enkel met een database kunnen werken en eventueel outputten naar Excel.

Een grotere laptop (ipv tablet) is eventueel een optie, maar als je de hele dag met een laptop op je amr moet rondlopen... wordt dit best zwaar.

[Noxious]

En iets als de Inspiron Duo?

[djluc]

Je hebt een ICT project wat uit de klauwen aan het lopen is. Terug naar de tekentafel werkt vaak het beste, eerst weer het project herzien en een clean nieuw project starten. Daarmee bedoel ik uiteraard niet dat alles weggegooid moet worden maar met name het project management moet even een nieuwe start maken. Ik heb wel wat voorbeelden voor je als je wilt hoe je dat aan kan pakken.

[Akrapovic58]

Hydra schreef op donderdag 03 februari 2011 @ 11:59:
[...]


Misschien moeten 'we' gewoon eens ophouden met het trekken van allerhande voorbarige conclusies? Dat er in een periode van 2 jaar ontwikkeld is betekent niet dat er ook 2 manjaar in zit. Vooral gezien er maar 10k betaald is voor de applicatie tot nu toe, daar ontwikkelen wij ongeveer 2 weken voor.

Laten we gewoon focussen op de vraag van de TS.

Absoluut. Het loopt +/- 1,5 jaar. Enkele vergaderingen met de opzet en doel van de software, nog wat extra tussentijdse vergaderingen en enkele weken ontwikkeling schat ik op iets rond de 10000 euro. Het kan meer zijn, ik heb de factuur niet gezien, noch betaald. De basis is er. Er moeten nog extra features en gebruiksgemakken bij...

[Akrapovic58]

Het probleem is dat bij elk advies (buiten op tweakers.net dan), iedereen vanuit zijn eigen winkel spreekt...


Het is dus ook inderdaad met het oog op toekomst, dat we beter er nu over nadenken dan nadien. Als het de werksnelheid van een iPad kan evenaren, zou dit ideaal zijn, want het gaat echt intensief gebruikt worden...

[ Voor 50% gewijzigd door Akrapovic58 op 03-02-2011 12:20 ]

[Hydra]

RobIII schreef op donderdag 03 februari 2011 @ 12:00:
Dat is mijn hele punt Zie ook mijn edit

Die was er toen nog niet

Dat gevoel deel ik wel, maar dat heb je gewoon in dat soort projecten waar de klant ook niet precies weet wat 'ie wil. En als je dan naar een .Net ontwikkelbedrijf stapt, dan gaan die natuurlijk 100% zeker in .Net ontwikkelen. Puur ethisch zou je kunnen zeggen dat zo'n bedrijf misschien had moeten zeggen dat ze bij een adner bedrijf zouden moeten zijn, maar dat doet zo'n bedrijf echt alleen maar in uitzonderlijke gevallen lijkt me.

Sowieso is het een kwestie van voortschrijdend inzicht. Destijds was android kennelijk geen issue, nu wel. dat heb je niet aan zien komen, en dat levert nu helaas issues op. Tja. Roeien met de riemen die je hebt of een nieuwe boot kopen.

[Akrapovic58]

Hydra schreef op donderdag 03 februari 2011 @ 12:17:
[...] Tja. Roeien met de riemen die je hebt of een nieuwe boot kopen.

[NMe]

Hydra schreef op donderdag 03 februari 2011 @ 11:55:
[...]

Sorry maar dat vind ik erg kort door de bocht. Jij kent de applicatie noch de originele requirement. Misschien wordt er op kantoor wel periodiek een niewe datafile overgezet. Je moet geen conclusies gaan trekken voordat je alle info hebt.

Laat ik het even nuanceren dan: op basis van wat ik uit de topicstart weet is het in elk geval niet netjes. Daar zit inderdaad een stukje aanname in.

badslats schreef op donderdag 03 februari 2011 @ 12:17:
Het probleem is dat bij elk advies (buiten op tweakers.net dan), iedereen vanuit zijn eigen winkel spreekt...

Gelukkig gaat dat hier op kantoor anders, wij hebben liever tevreden klanten die terugkomen als ze wél een relevante opdracht hebben dan dat we beginnen met ontwikkelen van iets dat we eigenlijk niet goed kunnen doen om vervolgens half werk af te leveren en nooit meer iets van die klant te horen wat andere opdrachten betreft. Dat is ook een manier waarop je zaken kan doen zonder zaken te doen.

[Akrapovic58]

NMe schreef op donderdag 03 februari 2011 @ 12:26:
[...]
Gelukkig gaat dat hier op kantoor anders, wij hebben liever tevreden klanten die terugkomen als ze wél een relevante opdracht hebben dan dat we beginnen met ontwikkelen van iets dat we eigenlijk niet goed kunnen doen om vervolgens half werk af te leveren en nooit meer iets van die klant te horen wat andere opdrachten betreft. Dat is ook een manier waarop je zaken kan doen zonder zaken te doen.

Volledig juist. Maar voor hun was het alles of niets. Maar zonder namen te noemen en uitspraken te doen, proberen zij het natuurlijk in hun winkel op te hangen. Of dit dit de beste oplossing voor ons was blijft de vraag.

[ Voor 7% gewijzigd door Akrapovic58 op 03-02-2011 12:36 ]

[YopY]

Het lijkt er hier op dat óf jullie requirements veranderd zijn, óf het product wat er tot nu toe is voldoet niet aan jullie verwachtingen (die dan niet in de afgesproken requirements stonden), óf het product wat jullie hebben draait niet naar behoren op de hardware.

Een overstap naar Android zou voort moeten vloeien uit de requirements, niet andersom. Ook de redenatie voor het gebruikmaken van Android zou iets beter onderbouwd moeten zijn dan de beschikbaarheid van dat soort tablets.

Ik zou het volgende doen:

* Zet in de requirements vast hoe snel en 'snappy' de applicatie moet zijn
* Zet in de hardware-requirements hoe de tablet moet werken - moet hij licht en gemakkelijk in het gebruik zijn? Touchscreeneigenschappen vergelijkbaar met ye olde resistieve touchscreens of met moderne capacitieve? User interface lekker eenvoudig of met kekke animaties e.d.?
* Als op basis van bovenstaande requirements blijkt dat het bedrijf hier niet aan kan voldoen -> opdracht annuleren, geld terugeisen, of je verlies nemen.
* Pas als op basis van bovenstaande requirements blijft dat Android het enige platform is dat hieraan voldoet, dan zou ik pas in die richting kijken.

Ik ben de halve TS ondertussen vergeten, maar het lijkt mij dat dit voortvloeit uit:

* Applicatie is niet zo vlot
* Tablet is niet zo kek
* Android tablets zijn wél vlot en kek -> ik wil Android!

Twee dingen moet je eigenlijk naar kijken:

* Is de applicatie goed / goed genoeg / gaat het de goeie kant op / kunnen we het de goeie kant op sturen?
* Is de hardware goed / goed genoeg of moeten we zoeken naar andere hardware?

Requirements zijn belangrijk. Dat je ze met de tijd en ontwikkelingen aan kunt passen ook - houd ook hier rekening mee bij het maken van een opdracht.

[Woy]

YopY schreef op donderdag 03 februari 2011 @ 12:51:
* Zet in de requirements vast hoe snel en 'snappy' de applicatie moet zijn

Hoe definieer je 'snappy' zonder dat er discussie mogelijk is over wat er mee bedoeld word. Juist voor een interface is dat erg lastig. Voor verwerking kun je nog makkelijk stellen van "moet binnen x minuten/seconden" voltooid zijn. Maar gebruikerservaring is erg lastig te specificeren.

* Zet in de hardware-requirements hoe de tablet moet werken - moet hij licht en gemakkelijk in het gebruik zijn? Touchscreeneigenschappen vergelijkbaar met ye olde resistieve touchscreens of met moderne capacitieve? User interface lekker eenvoudig of met kekke animaties e.d.?

Ook hier is het weer moeilijk om het ondubbelzinnig en meetbaar te defineren. Licht kan je nog specificeren met een maximum gewicht, maar voor "gemakkelijk" is geen harde grens, hetzelfde met "lekker eenvoudig" en "kekke animaties"

* Als op basis van bovenstaande requirements blijkt dat het bedrijf hier niet aan kan voldoen -> opdracht annuleren, geld terugeisen, of je verlies nemen.

Je kunt natuurlijk nooit je geld terugeisen als je de eisen pas achteraf gaat stellen.

Requirements zijn belangrijk. Dat je ze met de tijd en ontwikkelingen aan kunt passen ook - houd ook hier rekening mee bij het maken van een opdracht.

Eensch, maar het is ook belangrijk dat je duidelijke requirements hebt die maar op een manier uit te leggen zijn, en ook te meten zijn. Dingen als Snel/Mooi/Makkelijk/etc. zijn niet eenduidig. Je zult dus meetbare requirements moeten stellen.

[Hydra]

YopY schreef op donderdag 03 februari 2011 @ 12:51:
Een overstap naar Android zou voort moeten vloeien uit de requirements, niet andersom.

Beetje mosterd na de maaltijd dit. Het platform was kennelijk destijds geen requirement, nu wel. Nu zijn requirement die veranderen meestal geen groot issue (er moet vaak genoeg een wijziging in workflow e.d. aangebracht worden, puur voortschrijdend inzicht), maar hier blijkt nu dat het platform windows op tablets gewoon een dead end is.

[roy-t]

Anders kun je toch altijd nog over naar snelle netbooks totdat er echt goede windows tablets zijn (die komen er heus wel). Verder lijkt me het wijs om gewoon wat meer geld te investeren in echte goede tablets ipv zo'n cheapo Archos te proberen, tuurlijk zijn die niet voor uit te branden en de kosten van een 10x zo duur tablet staan in het niets met 1.5jr ontwikkelkosten.

De ontwikkeling omgooien van .NET naar Java (Android) betekend bijna dat alles opnieuw moet, dat is gewoon zonde.

[Akrapovic58]

Hydra schreef op donderdag 03 februari 2011 @ 13:07:
[...]
Maar hier blijkt nu dat het platform windows op tablets gewoon een dead end is.

We vrezen dat dit het geval zou kunnen zijn.

In het begin zal niet alles volgens de regels van de kunst gelopen zijn, maar alle parameters waren niet aanwezig, een paar zijn er verplaatst en een deel zijn er bijgekomen (door nieuwe platformen).

Daarom dat ik de vraag hier stel om tot een doordachte (cfr. toekomstgerichte) oplossing te komen.


@ Woy

De snelheid en het gewicht van een iPad zou ideaal zijn. Een streling voor het oog moet absoluut niet. Coded in Apple software was geen optie omdat we dan via de iStore moeten. Emuleren eventueel wel.

[ Voor 19% gewijzigd door Akrapovic58 op 03-02-2011 13:29 ]

[Woy]

badslats schreef op donderdag 03 februari 2011 @ 13:24:
[...]

@ Woy

De snelheid en het gewicht van een iPad zou ideaal zijn. Een streling voor het oog moet absoluut niet.

Maar wat heb je er aan als je platform lekker snel is, maar de applicatie nog zo traag als dikke stront is? Op de een of andere manier moet je een meetbare requirement stellen over de responsiveness van je applicatie.

De vraag is dan ook of het probleem bij de applicatie of bij het onderliggende platform ligt.

Coded in Apple software was geen optie omdat we dan via de iStore moeten. Emuleren eventueel wel.

Er moeten ook opties zijn om bedrijfs applicaties te deployen, zonder ze in de publieke iStore te zetten, maar ik weet daar geen details van.

[ Voor 6% gewijzigd door Woy op 03-02-2011 13:32 ]

[creator1988]

Woy schreef op donderdag 03 februari 2011 @ 13:32:
[...]
Er moeten ook opties zijn om bedrijfs applicaties te deployen, zonder ze in de publieke iStore te zetten, maar ik weet daar geen details van.

Ja, dit is een speciaal soort corporate account. Kan je gewoon aanmaken (als je maar betaalt) op de site van Apple.

badslats schreef op donderdag 03 februari 2011 @ 13:24:
[...]


We vrezen dat dit het geval zou kunnen zijn.

In het begin zal niet alles volgens de regels van de kunst gelopen zijn, maar alle parameters waren niet aanwezig, een paar zijn er verplaatst en een deel zijn er bijgekomen (door nieuwe platformen).

Daarom dat ik de vraag hier stel om tot een doordachte (cfr. toekomstgerichte) oplossing te komen.


@ Woy

De snelheid en het gewicht van een iPad zou ideaal zijn. Een streling voor het oog moet absoluut niet. Coded in Apple software was geen optie omdat we dan via de iStore moeten. Emuleren eventueel wel.

Hebben jullie overwogen om een audit uit te laten voeren op wat tot nu toe is opgeleverd. Het kan er bij mij niet in dat een app op een Windows-tablet niet snel zou kunnen draaien.

[ Voor 53% gewijzigd door creator1988 op 03-02-2011 13:36 ]

[Alex)]

Anders zou je altijd nog een webapplicatie ervan kunnen laten maken. Met een iPad met een 3G-abonnement kun je daar dan eigenlijk altijd wel aan.

[Hydra]

Woy schreef op donderdag 03 februari 2011 @ 13:32:
Maar wat heb je er aan als je platform lekker snel is, maar de applicatie nog zo traag als dikke stront is? Op de een of andere manier moet je een meetbare requirement stellen over de responsiveness van je applicatie.

Mwa. Ik heb een paar projecten gezien waarbij dit een issue werd. Daar was vooraf geen norm voor de applicatie omschreven (vaak wel in de zin van trx/sec maar de responsiveness is lastiger te meten), maar omdat de applicatie traag reageerde wordt de applicatie dan als 'onaf' geacht.

Het lijkt me ook dat een klant van een dergelijk bedrijf mag verawchten dat een applicatie niet zo traag als dikke stront is, net zoals je van een auto bepaalde basale zaken mag verwachten. Als softwarebedrijf moet je ook weten dat je klant het vaak moeilijk vind zulke zaken goed te omschrijven en zou je daar ook zelf of garanties voor moeten geven, of daar in ieder geval op aansturen dat je zelf die dialoog aangaat. Dat doen wij zelf ook, puur om onzelf in te dekken.

Alex) schreef op donderdag 03 februari 2011 @ 13:40:
Anders zou je altijd nog een webapplicatie ervan kunnen laten maken. Met een iPad met een 3G-abonnement kun je daar dan eigenlijk altijd wel aan.

Of je er nu een webapp of android app van maakt, maakt ook geen hol uit. Je gooit dan nog steeds de bestaande software weg en bouwt iets nieuws, en dat willen ze als het even kan voorkomen. Daarnaast is ook nog eens aangegeven dat het continue verbonden zijn geen must is, dan is het helemaal niet logisch te kiezen voor een applicatie waarbij de complexiteit en kosten van een continueverbinging komen kijken.

[ Voor 23% gewijzigd door Hydra op 03-02-2011 13:42 ]

[Guldan]

Ik weet niet wat de originele specs zijn geweest waar de applicatie aan moet voldoen etc. Maar als de performance van de applicatie slecht dan kan dit aangegeven worden en een oplossing gezocht voor worden. Dit is iets waar de ontwikkelaars invloed op hebben. Echter als het OS traag is dan is de korste klap teruggaan naar een ouder OS of betere hardware kopen. Ik weet natuurlijk niet wie besloten heeft om het op een archos te gebruiken maar daar heb je over het algemeen als ontwikkelaar weinig invloed over.

Zoals hierboven aangegeven lijkt het mij handig om de problemen op een ondubbelzinnig manier te noteren en hiermee terug te gaan naar de ontwikkelaars. Dan kan je met hen overleggen waar volgens hen het probleem zit en hoe ze dat willen oplossen. Als zulke eisen niet gespecificeerd zijn kan ik mij voorstellen dat je daar alsnog voor moet betalen. Voor de prijs van een fiat panda een mercedes SLK maken gaat natuurlijk niet werken.

Als ontwikkel club kunnen ze (vind ik) best een beetje coulant doen m.b.t. de extra kosten maar goed dat is iets wat door jullie maar uitgevochten moet worden. Ik denk dat je zonder meer details van niemand een specifieke oplossing gaat krijgen dus mocht je dat willen dan zal je meer moeten toelichten. Ook kan je een andere club inhuren die de reeds geschreven software en zijn problemen gaat nalopen en oplossingen voorstellen als de relatie onderhand zo verslechterd is dat jullie verwachten geen eerlijk antwoord van hen te krijgen.

[Akrapovic58]

Wat screens

[ Voor 3% gewijzigd door Akrapovic58 op 03-02-2011 13:52 ]

[Hydra]

Weet niet wat we er precies mee moeten, maar het lijkt in ieder geval geen hele zware applicatie.

[Akrapovic58]

Hydra schreef op donderdag 03 februari 2011 @ 13:51:
Weet niet wat we er precies mee moeten, maar het lijkt in ieder geval geen hele zware applicatie.

Gewoon om een idee te geven van wat het inhoudt, niet echt veel dus...

[Mottebelke]

Heb je al eens gekeken naar MonoDroid en MonoTouch? Daarbij kunnen C# .NET applicaties worden gedraaid op Android of iOS. Je zult waarschijnlijk nog steed de UI moeten herschrijven om het net zo soepel te laten werken als een 'native' app, maar het kan je wat werk besparen in het backend/business logic gedeelte.

[creator1988]

badslats schreef op donderdag 03 februari 2011 @ 13:46:
Wat screens

Ben ik de enige bij wie het spontaan begint te jeuken bij het zien van zo'n UX, of heb ik te lang rondgehangen op de fronteers-borrel?

[leuk_he]

Of je terug naar de tekentafel moet ligt eigenlijk heel erg aan je tablet selectie.

Er is vast nog wel meer te krijgen dan de archos, maar wat je wel ziet is dat meeste windows tablets ook op atom platform gebaseerd zijn en dus in de zelfde performance class zitten. Precisie van het touch screen (met een toch-pen of toch een extra toetsenbord) zul je duidelijk moeten krijgen, maar je applicatie kan daarop simpel worden aangepast door de vlakken waar je een touch moet doen groot genoeg te maken.

Duurder tablets hebben een groter scherm en zijn dus "precieser". Hoeveel schade experts heb je rondlopen? Een duurdere versie van de slate kost je immer s een meerprijs op een android pad. Op PC hardware is wellicht een extra accu mee te leveren?

Een ipad of android pad gaat je over een half jaar de helft kosten van een grote high-perfomace windows 7 pad. als je genoeg consultants (x * 500 euro) hebt rondlopen verdien je het wel terug.


Overigens zit in een gemiddeld android pad of een iPad ongeveer een gelijke processor als in die archos ( In ieder geval niet 2x zo snel of 2x zo langzaam). Dus het ligt vooral aan de applicatie. Daarom is het vooral werk je applicatie te tunen voor het platform waar het PRECIES op gaat draaien.


Bij tunen denk ik dan niet alleen aan Snelheid (die immers voldoende moet zijn), maar ook aan schermlayout (grootte van knoppen, invoer velden) zodat die op het gekozen hardware platform goed werkt. batterij verbruik op een mobiel platform komt ook overeen met CPU verbruik, Dus als je applicatie veel CPU verbruikt, gaat je batterij ook harder naar beneden.

[Hydra]

Mottebelke schreef op donderdag 03 februari 2011 @ 13:57:
Heb je al eens gekeken naar MonoDroid en MonoTouch? Daarbij kunnen C# .NET applicaties worden gedraaid op Android of iOS. Je zult waarschijnlijk nog steed de UI moeten herschrijven om het net zo soepel te laten werken als een 'native' app, maar het kan je wat werk besparen in het backend/business logic gedeelte.

Tja, maar als die club geen Android doet gaat dat weinig oplossen. En als je met de applicatie naar een Android club gaat krijg je hetzelfde verhaal als wanneer je van tandarts switcht

[Akrapovic58]

Wij zijn in de tak experts met een klein 10tal. Aan de HP Slate habben we ook gedacht, maar die zou voorlopig nog niet te koop zijn.... of hier uitkomen met een eigen besturingssoftware

Volgens de programmeur zou het enkel aan het werkgeheugen van de Archos liggen (= 1gb). Vooral bij het laden van de database.

Dus:

- verder ontwikkelen en wachten op een goede tablet en hopen windows tablets zijn dus geen dead end zijn
- de afgewerkte software kan eventueel in een later stadium, mits het nodige werkt "geport/converteerd worden naar een ander platform"


Is er geen optie om de database (+/- 5000 lijnen) op een of andere manier te indexeren (zoals in windows) zodat die pijlsnel geladen kan worden?

[ Voor 3% gewijzigd door Akrapovic58 op 03-02-2011 14:23 ]

[Hydra]

Het is lastig te zeggen waar de bottleneck zit. Sowieso is er iets aan de hand als de traagheid veroorzaakt wordt door de 'database', dat klinkt alsof iedere keer een volledige bak data gelezen moet worden. Dat is normaal nooit nodig, daar heb je idd indexen voor. Het klint een beetje alsof ze gewoon een grote textfile helemaal in het geheugen lezen ofzo. En als ze dat doen is het inderdaad wel broddelwerk.

[Guldan]

Heel simpel gezegd, de programmeur geeft aan dat het geheugen de bottleneck is. Wat is dan de bottleneck: De applicatie gebruikt veel geheugen? Of is de tablet van nature traag?

Ook denk ik niet dat Microsoft tablets een dead end zijn puur en alleen omdat microsoft daar anders ontzettend veel mee misloopt aan opbrengst. Aan de andere kant maakt het natuurlijk ook niet uit, zolang JULLIE maar een tablet hebben wat wel snel genoeg is.

Wij hebben ook aan de screens niet genoeg informatie om hier iets zinnigs over te zeggen. Ik ben zelf .net ontwikkelaar en heb ondanks de screens geen idee wat het probleem is. Zonder fatsoenlijke technische documentatie kan ik (en de rest van de community) geen technisch inhoudelijk antwoord geven aan je (en ik ga ervanuit dat je die niet zomaar aan jan en allemaal wilt geven). Dus als je een eerlijk antwoord wilt hebben dan zal je een toko moeten inhuren die een inventarisatie van de code gaat maken.

Als het wel ligt aan de hardware laat ze het eens op een desktop machine installeren met ongeveer dezelfde specs (voorzover mogelijk.,. vooral qua werkgeheugen) en vergelijk het eens met elkaar (echter blijft dit wel een beetje appels met peren vergelijken maargoed) misschien krijg je daardoor wat meer inzicht.

[Akrapovic58]

Hydra schreef op donderdag 03 februari 2011 @ 14:27:
Het is lastig te zeggen waar de bottleneck zit. Sowieso is er iets aan de hand als de traagheid veroorzaakt wordt door de 'database', dat klinkt alsof iedere keer een volledige bak data gelezen moet worden. Dat is normaal nooit nodig, daar heb je idd indexen voor. Het klint een beetje alsof ze gewoon een grote textfile helemaal in het geheugen lezen ofzo. En als ze dat doen is het inderdaad wel broddelwerk.

ik had ook de hele tijd dit gevoel, ook al ken ik er niet al te veel van. Als je op je pc laat indexeren, gaat het ook pijlsnel dus dit moet daar ook toch ook zeker kunnen. Vooral omdat het een statische inventaris is die enkel volgens bepaalde intervallen ge-update wordt.

We hebben 2 opties

- doorlopen van een determineertabel (werkt naar behoren: niet op de Archos, wel op de laptop)
- gewoon zoekfunctie (werkt naar behoren: noch op de Archos, noch op de Laptop)

> geen van beide gaat als behoren op de Archos

[bredend]

badslats schreef op donderdag 03 februari 2011 @ 14:23:
Wij zijn in de tak experts met een klein 10tal. Aan de HP Slate habben we ook gedacht, maar die zou voorlopig nog niet te koop zijn.... of hier uitkomen met een eigen besturingssoftware

Volgens de programmeur zou het enkel aan het werkgeheugen van de Archos liggen (= 1gb). Vooral bij het laden van de database.

Dus:

- verder ontwikkelen en wachten op een goede tablet en hopen windows tablets zijn dus geen dead end zijn
- de afgewerkte software kan eventueel in een later stadium, mits het nodige werkt "geport/converteerd worden naar een ander platform"


Is er geen optie om de database (+/- 5000 lijnen) op een of andere manier te indexeren (zoals in windows) zodat die pijlsnel geladen kan worden?

Beschikt de programmeur over een Archos? Dat alles op zijn PC goed werkt maakt voor de gebruiker niets uit namelijk. Misschien kan het laden van de database wel efficienter. Misschien is het helemaal niet nodig om de DB in het geheugen te laden?

[Akrapovic58]

We hebben er 3 gekocht en er hem 1 gegeven. Van de programmatie weten wij echter niet veel...

[leuk_he]

badslats schreef op donderdag 03 februari 2011 @ 14:23:
Is er geen optie om de database (+/- 5000 lijnen) op een of andere manier te indexeren (zoals in windows) zodat die pijlsnel geladen kan worden?

5000 regels * x bytes (10 Kbyte) = 5 Megabyte. Dat moet goed te doen zijn op een PC van 5 jaar terug. Zo niet moeten ze hun software nog maar eens goed daarop tunen. 1 GB + slome cpu moet genoeg zijn voor zo'n database, ook al houd je die helemaal in memory.

[Woy]

badslats schreef op donderdag 03 februari 2011 @ 14:23:
Is er geen optie om de database (+/- 5000 lijnen) op een of andere manier te indexeren (zoals in windows) zodat die pijlsnel geladen kan worden?

5000 rows moet sowieso geen probleem zijn. Ik heb hier een applicatie draaien die elke dag meer dan 100.000 rows per dag schrijft/leest in een SQLite db, en dat draait ook gewoon op een oude pc met 512 mb geheugen en windows 7 erop.

Zeker aangezien het een lokale applicatie is, en je dus waarschijnlijk geen last hebt van concurrent users, lijkt me dat er verkeerd gebruik gemaakt word van de database , of dat het probleem ergens anders ligt.

[Bigs]

Ik denk dat het platform hier niet het probleem is. Zoals hierboven ook al gezegd wordt; zo'n applicatie moet prima op een simpele tablet met 1GB RAM kunnen werken. Sterker nog, ik heb dit soort dingen op veel simpelere hardware gedaan (daar zat ook een artikelbestand in met duizenden regels). Dit is gewoon een kwestie van beter programmeren.

Als ik op 'rugged tablet pc' zoek kom ik ook al diverse tablets tegen die prima geschikt zouden zijn voor jullie doel (voorbeeld), dus dat er geen geschikte Windows tablet PC's verkrijgbaar zijn kan ik me ook niet voorstellen. De gemiddelde Android tablet heeft zeker geen betere specs dan de hierboven gelinkte voorbeelden.

Laat de ontwikkelaars gewoon wat meer op het uiteindelijke platform werken (in dit geval de Archos tablet) en eis dat de applicatie snel werkt. Ik kan me niet voorstellen dat dat niet mogelijk is.

[ Voor 3% gewijzigd door Bigs op 03-02-2011 15:56 ]

[Woy]

Bigs schreef op donderdag 03 februari 2011 @ 15:55:
Ik denk dat het platform hier niet het probleem is. Zoals hierboven ook al gezegd wordt; zo'n applicatie moet prima op een simpele tablet met 1GB RAM kunnen werken.

Dat is dan misschien weer een beetje kort door de bocht, aangezien je niet precies weet wat er allemaal gebeurd, maar met 5000 rows zou de data-retrieval uit de database het probleem niet moeten zijn.

[Bigs]

Woy schreef op donderdag 03 februari 2011 @ 16:08:
[...]

Dat is dan misschien weer een beetje kort door de bocht, aangezien je niet precies weet wat er allemaal gebeurd, maar met 5000 rows zou de data-retrieval uit de database het probleem niet moeten zijn.

Je hebt gelijk, ik liet iets teveel buiten beschouwing, ik bedoelde inderdaad dat de database niet het probleem zou mogen zijn.

[alienfruit]

Inderdaad en verder is het al sinds 2008 bekend dat er Android-based Archos tablets komen. Immers er waren al firmwares me Android in omloop voor de Archos 5.

[Woy]

Ik weet niet hoe jullie het geregeld hebben met de rechten op de code, maar als die ook jullie eigendom zijn, zouden jullie misschien kunnen overwegen om eens een code/performance review uit te laten voeren door een derde.

[Akrapovic58]

Ik dacht ook dat dit geen probleem zou mogen geven met +/- 5000 lijnen. Allen alvast zeker bedankt voor de moeite.

Wij dachten aan een ander platform omdat er veel meer tablets beschikbaar waren (en dat die wss wat lichter draaiden dan met windows 7 wat voor meer ademruimte moest zorgen).

Ik neem alle reacties nog eens door en leg het op tafel bij de volgende vergadering (pas binnen 1 maand) en post hier zeker een update. Verder advies is altijd zeker welkom.

[Woy]

badslats schreef op donderdag 03 februari 2011 @ 17:07:
Wij dachten aan een ander platform omdat er veel meer tablets beschikbaar waren (en dat die wss wat lichter draaiden dan met windows 7 wat voor meer ademruimte moest zorgen).

Met de huidige stand van zaken, en het feit dat de tablet blijkbaar alleen voor deze applicatie gebruikt word, is dat misschien wel zo. Maar het lijkt me een beetje vreemd om die beslissing te nemen nadat de applicatie al een stuk af is. Dat is pure kapitaal vernietiging.

Op dit moment lijkt me het meest voor de hand liggen om de applicatie aan te passen zodat het wel aan jullie verwachtingen voldoet. Maar om een goede afweging te kunnen maken zou ik een derde partij inhuren om een inventarisatie te maken, en aan de hand daarvan een goed advies.

[Mottebelke]

Er zijn nog wel andere Windows tablets te krijgen, zoals bijvoorbeeld deze: WinTab HD
Die is zelfs configureerbaar met 2GB RAM, en die webshop levert ook in Belgie. En hij heeft een capacitief touchscreen. De Archos 9 heeft een resistief scherm, wat de UX ook een stukje minder maakt.

Hebben jullie eigenlijk niet in de afgesproken specificatie opgenomen wat de minimum systeemeisen zouden zijn? Lijkt me toch een standaard ding om te doen.

[voodooless]

Ik vraag me af wat nu de werkelijke rede is dat de software traag is? Ik kan me echt niet voorstellen dat dat database is, nog een tabet systeem wat een klein beetje gedateerd is. Ook niet .net, en gezien de screenshots lijkt het me geen applicatie die super zwaar aan het rekenen is..

Als het in .net niet snel is, waarom zou de zelfde club het op android wel snel kunnen krijgen (en vergeet niet dat de specs van android tabels kwa rekenkracht veel minder zijn dan zo'n windows tablet)?

[alwinuzz]

Bigs schreef op donderdag 03 februari 2011 @ 15:55:
Ik denk dat het platform hier niet het probleem is. Zoals hierboven ook al gezegd wordt; zo'n applicatie moet prima op een simpele tablet met 1GB RAM kunnen werken. Sterker nog, ik heb dit soort dingen op veel simpelere hardware gedaan [...]

The PHL2700 is equipped with 8 MB of data memory; large enough for intensive data collection applications.

Hoe kan een Archos met 1GB nou te weinig zijn


On topic: is de applicatie al geprofiled zowel op geheugenverbruik als op CPU? Het zou best kunnen dat een paar bottlenecks de performance verpesten.

[YopY]

Als de ontwikkelaar aangeeft dat het programma teveel geheugen gebruikt of de database te langzaam is, is dat gewoon keihard zijn eigen schuld. Een Excel-met-extra's-achtige applicatie zoals dit lijkt te zijn kan die hele database in het geheugen opslaan plus de rest, en dan nog genoeg overhouden. Een database is ook niet langzaam, als hij langzaam is dan is dat geheel de schuld van de ontwikkelaar. 5000 regels is helemaal niks, voor zo'n tablet zou het pas moeilijker moeten gaan bij miljoenen regels, en zelfs dan is er nog genoeg aan te doen.

Lijkt erop dat de ontwikkelaar excuses aan het bedenken is. Laat hem eens het technische verhaal doen over de performanceproblemen.

Excuus voor mogelijk botte reactie, da's het gevaar van het internet en eerlijkheid enzo, ;D.