Diabetesinfo-Forum
SiDiary => iPhone => Mobile Versionen => Feature Request => Thema gestartet von: BlueDevilHH am Januar 25, 2011, 09:27
-
Moin!
In meinem Spieltrieb habe ich mir gestern einmal die iPhone-Software iBG-Star angeschaut.
In dieser gibt es in der Ansicht der Werte zwei Ansichten die ich besondern klasse und vor allem auch sinnvoll finde.
1. Die Tagebuch-Ansicht (unter Werte/Tagebuch)
Hier sind in einer Tabelle alle Tage untereinander (der jüngste Tag oben) und nebeneinander die Rubriken "Frühstück vor/nach", "Mittagessen vor/nach", "Abendessen vor/nach" und "Nacht" aufgeführt.
2. Die Ansicht Statistik (unter Werte/Statistik)
In dieser Ansicht sind untereinander gelistet jeweils Mitteilwert, Standardabweichung und Anzahl der Werte für
Alle Ergebnisse
Vor dem Frühstück
Nach dem Frühstück
Vor dem Mittagessen
Nach dem Mittagessen
Vor dem Abendessen
Nach dem Abendessen
Nacht
Darüber gibt es Schaltflächen zum umschalten des Auswertungszeitraumes für 7 Tage, 14 Tage, 30 Tage, 90 Tage und Spezifisch (also freier Zeitraum).
Auch diese Ansicht finde ich einfach klasse, zeigt sie mir nach der Eingabe der letzten 7 Tage doch sehr schön, wie sich meine Messwerte jeweils vor und nach den Mahlzeiten verhalten.
Finde ich schon mal nicht schlecht...soll heißen: Sowas hätte ich auch gern! ::)
Auch wenn es etwas umständlicher ist, werde ich in der kommenden Zeit meine Werte in beiden Programmen einpflegen. Diese Ansichten finde ich wirklich sehr hilfreich.
-
Stell doch mal ein paar Screenshots rein...
Viele Grüße,
Jörg
-
Mache ich morgen mal. Nur eines: Wie bekomme ich denn hier ein Foto angehängt?
-
Mache ich morgen mal. Nur eines: Wie bekomme ich denn hier ein Foto angehängt?
http://picr.de/ (http://picr.de/)
-
Oder einfach in unsere Galerie hochladen (Link oben in der Link-Leiste des Forums)
Viele Grüße,
Jörg
-
Erst einmal Danke für die Hinweise zur Bildverlinkung.
Also hier eine Ansicht der Statistik aus iBGStar:
(http://www.forum.diabetesinfo.de/forum/gallery/2253_26_01_11_6_27_39.jpeg)
Und hier die Tagebuchansicht:
(http://www.forum.diabetesinfo.de/forum/gallery/2253_26_01_11_6_26_29.jpeg)
-
Also hier eine Ansicht der Statistik aus iBGStar:
Haben wir auch. Schau mal auf die Filter in der Statistik.
Und hier die Tagebuchansicht:
Das ist eine abgespeckte Form unseres CT-Tagebuchs.
Viele Grüße,
Jörg
-
Haben wir auch. Schau mal auf die Filter in der Statistik.
Das ist eine abgespeckte Form unseres CT-Tagebuchs.
Äh, finde ich nicht so eine Ansicht...die Filter helfen mir da auch nicht weiter... :knatschig:
Wo sind denn im CT-Tagebuch sowohl Werte vor/nach dem Essen aufgeführt? Wenn, dann wird da nur einer, nämlich der Wert nach dem Essen angezeigt. :gruebeln:
Im übrigen sind wir hier in der Rubrik iPhone/Feature Request und auf dem iPhone geht sowas, genau wie in der Bildschirmanzeige und im Druck aus SiDiary, überhaupt nicht. ::)
Gruß,
Mario
-
Du meinst du hast die Druckvorlage 'Tagebuch-CT' noch nicht gefunden? :zwinker:
(http://www.sidiary.org/snapshot/0YWS2879D.png) (http://www.sidiary.org/ssc.asp)
-
Doch, aber weder die Bildschirmanzeige des CT-Tagebuchs noch die Durckvorlage liefert mir zu morgens, mittags und abends sowohl den Wert vor, als auch nach dem Essen. gibt es einen "nach dem Essen"-Wert wird lediglich dieser angezeigt.
Wie geschrieben hilft mir das vor allem auf dem iPhone herzlich wenig. :-\
-
Wie geschrieben hilft mir das vor allem auf dem iPhone herzlich wenig. :-\
Ausdrucken und draufkleben! :duck:
-
Doch, aber weder die Bildschirmanzeige des CT-Tagebuchs noch die Durckvorlage liefert mir zu morgens, mittags und abends sowohl den Wert vor, als auch nach dem Essen.
Kann es auch nicht, wenn im definierten Zeitraum keiner vorhanden ist. Die Zeiträume kannst du selber definieren in Menü 'Diabetesprofil ->Messzeiten'
Viele Grüße,
Jörg
-
Soweit, so gut...aber diese Zeiträume lassen sich nur allgemein festlegen. Das Problem beginnt dann aber schon am Wochenende. Während ich in der Woche relativ regelmäßig aufstehe, schlafe ich am Wochenende auch schon mal etwas länger und dann fällt die "vor dem Frühstück"-Messung vielleicht erst um 11 Uhr an.
Wochentags frühstücke ich über die Wochen betrachtet auch recht unregelmäßig. Dadurch das ich als Berater im Außendienst tätig bin ist hier meine Frühstückszeit abhängig von meinen Arbeitsbeginnzeiten (in der Regel 6:30 Uhr bis 9 Uhr) die im Extremfall auch einmal Schichtarbeit bedeuten können.
Arbeite ich dagegen in meinem Büro ist meine Frühstückszeit (und somit auch meine Messzeitpunkte) ebenfalls unterschiedlich, da ich mich dann nach dem Arbeitsbeginn meiner Frau orientiere. Diese beginnt in der Regel morgens um 9 Uhr, kann aber auch manchmal 8 Uhr sein.
Logischerweise verschieben sich die anderen Messzeitpunkte ebenfalls entsprechend.
Somit weiß ich wirklich nicht was ich da als Zeit einstellen soll damit ich vergleichen kann...vor dem Frühstück kann einmal heißen von 5 Uhr bis 8:30 Uhr, ein anderes mal von 11 Uhr bis 13 Uhr.
Bei einem Typ 1-Diabetiker mag das vielleicht alles etwas logischer sein, da dieser sicherlich einen etwas regelmäßigeren Tagesablauf realisieren muss.
Eine Lösung dieses Problems wäre also, wenn die Trigger T1-T8 einen eingestellten Messzeitraum "überschreiben", also mit höherer Priorität die Auswertung beeinflussen.
-
Ja, sehr schön, danke für den Tipp dass die App schon da ist. Besonders wichtig, dass man onboard neue Parameter definieren kann ohne auf ein Desktop-Programm ausweichen zu müssen. Und alles ist gut lesbar, selbst ohne Brille, und very easy to use.
Schöne Optik, einfaches Handling.
So hatte ich mir das eigentlich von der SiDiary App erhofft.
-
Besonders wichtig, dass man onboard neue Parameter definieren kann ohne auf ein Desktop-Programm ausweichen zu müssen.
Man kann in der iBGStar-App eigene Datentypen definieren und die tracken?? :staun:
Übrigens, die eigenen Datentypen (UDTs) kannst Du für die iPhone-App auch ohne PC-Anwendung (direkt online) definieren!?
-
Soweit, so gut...aber diese Zeiträume lassen sich nur allgemein festlegen. Das Problem beginnt dann aber schon am Wochenende. Während ich in der Woche relativ regelmäßig aufstehe, schlafe ich am Wochenende auch schon mal etwas länger und dann fällt die "vor dem Frühstück"-Messung vielleicht erst um 11 Uhr an.
Dann ist es aber auch eine andere Tageszeit, für die Du nicht mehr die Therapiegrößen von "vor dem Früstück" nimmst, sondern die, die sonst fürs Mittagessen gelten. Wie Du eine Mahlzeit nennst, ist völlig egal. Der Körper richtet sich in seiner Insulinempfindlichkeit nach dem Biorhythmus. Und nach der tageszeitabhängigen Insulinempfindlichkeit richten sich Höhe der Basalrate, der Korrekturfaktoren und der BE-Faktoren. Das Problem ist also weniger die Einordnung des Zeitpunkts in eine Gruppe als das essensfixierte Denken desjenigen, der die Gruppen benennt. Wenn Du Dein Abendessen morgens um sieben einnimmst, verwendest Du ja auch die Frühstücks- und nicht die Abendessen-Faktoren. Warum also sollte so ein Wert in einer anderen Gruppe landen?
Grüße
Anja
-
"Übrigens, die eigenen Datentypen (UDTs) kannst Du für die iPhone-App auch ohne PC-Anwendung (direkt online) definieren!?"
Theoretisch ja, praktisch erzeugt das multiple Einträge, die man nicht wieder los wird, ich hatte das schon mal angefragt, andere hatten wohl das selbe Problem.
Lösung, so hieß es von euch: die Daten eben *doch* mit Sidiary-Software anlegen... und das ist, ehrlich gesagt, um drei Ecken gehüpft, aber keine akzeptable mobile Lösung mehr.
Ich weiß, dass ich hier oft an der Usability und Optik nörgele, aber so isses nun mal. Ich arbeite beruflich mit Design und Visualisierung und SiDiary macht mich stellenweise wahnsinnig.
Ich nutze derzeit *drei* Versionen von Sidiary: Online, Desktop bzw. On-a-Stick mit dem USB-Contour, die App. Das kann es eigentlich nicht sein.
Wenn eine iphone App, dann sollte zumindest online alles einzustellen sein, was onboard nicht geht. Und das nicht nur, weil ich auf meinem Mac nicht jedesmal Windows anwerfen will, nur für Sidiary.
Wenn es um Datenexport geht, dasselbe. Angepasste Templates? Nur von der Desktop-Software aus.
Die iBGStar-App hat auch ihre Probleme, klar. Aber wenigstens hat sie ein integriertes umfangreiches Manual.
SiDiary ist von der reinen "Diabetesseite" aus mit am durchdachtesten derzeit. Deswegen versuche ich es ja auch immer wieder damit :)
Vieles andere ist aber leider nicht ok.
Ich wünschte, ihr würdet Euch visuell und usabilitymäßig ein wenig an dem orientieren, was *möglich* und *sinnvoll* ist. Und deutlich mehr +in the cloud+ denken.. Dafür würde ich gerne weiter bezahlen.
Herzliche Grüße
Cat
-
Hallo Cat,
Theoretisch ja, praktisch erzeugt das multiple Einträge, die man nicht wieder los wird, ich hatte das schon mal angefragt, andere hatten wohl das selbe Problem.
Lösung, so hieß es von euch: die Daten eben *doch* mit Sidiary-Software anlegen... und das ist, ehrlich gesagt, um drei Ecken gehüpft, aber keine akzeptable mobile Lösung mehr.
Kannst Du uns das evtl. nochmal auf der Support-Line schildern. Ich wüsste nicht, warum das Definieren der UDTs auf der Website zur Verdopplung von irgendwelchen Daten führen sollte? Die Definitionen der UDTs auf der Webseite ist ja noch nicht so lange implementiert aber wenn man dort UDTs definiert, werden die auch auf den PC mit gesynct (und umgekehrt) und dass dabei bzw. dem iPhone-Online-Sync UDT-Definitionen dupliziert werden, höre ich zum ersten Mal!?
Ich nutze derzeit *drei* Versionen von Sidiary: Online, Desktop bzw. On-a-Stick mit dem USB-Contour, die App. Das kann es eigentlich nicht sein.
Wenn eine iphone App, dann sollte zumindest online alles einzustellen sein, was onboard nicht geht. Und das nicht nur, weil ich auf meinem Mac nicht jedesmal Windows anwerfen will, nur für Sidiary.
Ich kann Dein Frustpotential ja durchaus etwas nachvollziehen aber dann haben wir da zum einen auch grundverschiedene Herangehensweisen zum Arbeiten mit der mobilen App. Du möchtest dort alles komplett machen können, ohne irgendetwas anderes nutzen zu müssen, andere sehen die mobilen Applikationen eher als "schlanken Datensammler", der auch mal ein paar Auswertungen on the fly generieren kann. Für die meisten stellt hier das Arbeiten mit einer Windows-Version kein Problem dar. Da hast Du nat. mit dem Mac eine zusätzliche Kröte zu schlucken aber an der Stelle müssen wir auch ein klein wenig auf die Kosten achten.
Wir unterhalten im Moment schon zig Plattformen/Versionen:
1. PC
2. PPC
3. Smartphone
4. Java
5. iPhone
6. Online
7. Online-WebKit für iPhone&Android&Blackberry
8. und demnächst Android native und
9. Phone7
Und jedes Mal wenn wir eine neue Plattform bedienen und dort nicht der volle Umfang drin ist, kriegen wir das um die Ohren gehauen. Wir sind hier wirklich noch immer mit einer ganzen Menge Enthusiasmus und Idealismus dabei aber irgendwo muss alles auch ein Stückchen finanzierbar sein und wir müssen vor allem die vorhandenen Entwickler-Ressourcen auf die Plattformen verteilen.
Wir verdienen nicht wie die Gerätehersteller an den Streifen und können die komplette Software-Entwicklung mit einer Riesen-Entwicklertruppe quersubventionieren. Und doch fällt das was bei den Geräte-Herstellern an SW-Output herauskommt doch eher schmal aus.
Ich gönne der iPhone-Fraktion durchaus ganz viele neue tolle Features aber umgekehrt stehen da auch nicht wenige Androidler, die ebenfalls gerne eine native Version und auch ein paar Phone7-User klopfen an. Das ganze parallel aber mit Pflege und Maintenance von Online und PC-Version und der PPC/Smp/Java-Editionen.
Ich wundere mich manchmal immer, was teilweise Anwender für Vorstellungen haben, wieviele Hundertschaften an Entwicklern unsere Bürotürme bevölkern...
:kratz:
Wenn es um Datenexport geht, dasselbe. Angepasste Templates? Nur von der Desktop-Software aus.
Ja und dieser Punkt wird auch so bleiben. Das Problem ist, dass wir nicht einfach beliebigen "Byte-Code" der als Makro oder schlimmeres in Vorlagen eingebettet sein könnte auf unseren Server einschleusen können.
Wir sind aber gerade daran, u.a. die Berichte von SiDiary Online aus denen der PC-Version anzugleichen (da läuft dann im Hintergrund die gleiche Report-Engine), so dass z.B. auch die rel. neue UDT-Vorlagenart auf dem Server unterstützt wird.
Viele Grüße, Alf.
-
Hallo Alf,
vielen Dank für diese klare Stellungnahme, ich denke was Du schreibst, bzw. was hier auch deutlich wird ist jemanden, der von "Außen" auf das Sidiary-Produkt aufmerksam wird nicht immer transparent, mir lange Zeit auch nicht:
aber dann haben wir da zum einen auch grundverschiedene Herangehensweisen zum Arbeiten mit der mobilen App. Du möchtest dort alles komplett machen können, ohne irgendetwas anderes nutzen zu müssen, andere sehen die mobilen Applikationen eher als "schlanken Datensammler", der auch mal ein paar Auswertungen on the fly generieren kann.
Wir unterhalten im Moment schon zig Plattformen/Versionen:
1. PC
2. PPC
3. Smartphone
4. Java
5. iPhone
6. Online
7. Online-WebKit für iPhone&Android&Blackberry
8. und demnächst Android native und
9. Phone7
Ich wünschte, ihr würdet Euch visuell und usabilitymäßig ein wenig an dem orientieren, was *möglich* und *sinnvoll* ist. Und deutlich mehr +in the cloud+ denken.. Dafür würde ich gerne weiter bezahlen.
Hier geht es um den Schwerpunkt von Sinovo bzw. Eure Sidiary-Perspektive für die Zukunft:
Soweit ich Dich verstehe sind PPC, Smartphone, Java, iPhone, Online-WebKit für iPhone&Android&Blackberry, Android native und W-Phone7,... für Euch "nur" mit ein paar mehr Features und nicht dafür gedacht die volle PC-Version/Funktionalität zu ersetzen. Diese Zielsetzung ist Eure Entscheidung und wird sicher von vielen Usern so mitgetragen.
Was CAT hier aber sucht (und langezeit hatte ich Eure iphone app auch so verstanden) ist eine vollwertige Standalone-Applikation auf dem i-phone bzw. "in der Cloud". (Wozu ich persönlich sagen würde lieber nicht!)
Vielleicht würde es allen Beteiligten helfen, Euren Ansatz für die mobiledevices konkreter zu formulieren/kommunizieren, auch um die Ansprüche der User an die Apps - und die damit verbundenen Programmierwünsche an Euch - herunterzuschrauben. Zum Beispiel könnte meiner Meinung nach die von mir bereits vorgeschlagene Feature-Matrix helfen?
Gruß
Franc
-
Wir unterhalten im Moment schon zig Plattformen/Versionen:
1. PC
2. PPC
3. Smartphone
4. Java
5. iPhone
6. Online
7. Online-WebKit für iPhone&Android&Blackberry
8. und demnächst Android native und
9. Phone7
Und jedes Mal wenn wir eine neue Plattform bedienen und dort nicht der volle Umfang drin ist, kriegen wir das um die Ohren gehauen. Wir sind hier wirklich noch immer mit einer ganzen Menge Enthusiasmus und Idealismus dabei aber irgendwo muss alles auch ein Stückchen finanzierbar sein und wir müssen vor allem die vorhandenen Entwickler-Ressourcen auf die Plattformen verteilen.
Wir verdienen nicht wie die Gerätehersteller an den Streifen und können die komplette Software-Entwicklung mit einer Riesen-Entwicklertruppe quersubventionieren.
Und doch fällt das was bei den Geräte-Herstellern an SW-Output herauskommt doch eher schmal aus.
Du willst aber doch nicht dem Anwender vorwerfen, dass man sich bei Sinovo einen solchen Umfang an's Bein bindet und es dann nicht finanzieren kann. Dann muss SiDiary eben teurer werden...oder man sollte sich einmal Gedanken machen, ob man nicht Versionen für ein paar veraltete Techniken einfriert sofern diese stabil laufen.
Euer Bemühen es allen recht zu machen in allen Ehren, aber wie Du schon selbst schreibst lässt sich diese Bemühung nicht finanzieren. Gerade am Beispiel der iPhone-Software, die ja wirklich als "Datensammler" toll ist, sieht man wohin das führt: Da wird eine App nach einer anscheinend schlecht gelaufenen Beta-Phase in der noch nicht einmal jemand darüber gestolpert ist, dass die Uhrzeit nach der Dateneingabe ggf. wieder neu eingestellt werden muss, zu einem Preis von 4,99 EUR! auf den Markt geworfen und dann passiert monatelang aus Sicht des Anwenders nichts mehr. Auf Anfrage nach Fehlerbeseitigungen kommt die Begründung, dass man auch noch so viele andere Systeme zu bedienen hat.
Ich wundere mich manchmal immer, was teilweise Anwender für Vorstellungen haben, wieviele Hundertschaften an Entwicklern unsere Bürotürme bevölkern...
:kratz:
Viele Grüße, Alf.
Gerade dann sollte man sich in einem Softwarehaus Gedanken darüber machen was man denn noch bedienen kann (und will) und was nicht. Eine mit heißer Nadel gestrickte und mit offensichtlichen Fehlern gespickte App (für welches System auch immer) ist dabei auch dem Anwender nicht dienlich sofern nicht eine relativ kurzfristige Lösung angeboten werden kann.
Ich arbeite selbst seit mehreren Jahren für ein kleines Softwarehaus das mehrere tausend Kunden in der Industrie hat. Die Flut der Kundenwünsche war geradezu unüberschaubar, wurden aber alle einzeln aufgenommen und priorisiert in eine ToDo-Liste aufgenommen.
Eine Abarbeitung von Problemlösungen steht dabei an alleroberster Stelle und wird sofort erledigt. Lösungen stehen größtenteils bereits nach 10-15 min bereit. Ok, das ist im Fall einer iPhone-App unmöglich. ;)
Kundenwünsche mit echtem Sinn für Anwender und Softwarehaus (also die, die einen Mehrwert darstellen) werden in einem nächsten Schritt realisiert, usw.
Was aber das wichtigste dabei war, dass man in diesem kleinen Softwarehaus im Leben nicht mit 3 Softwareentwicklern ausgekommen wäre, wenn man (auch auf die Gefahr hin manchen vor den Kopf zu stoßen) versucht hätte alle Wünsche von Kunden nach Portierung in andere Systeme zu erfüllen. Letztendlich wurden lediglich Windows-Systeme, PPC, PalmOS und selbstentwickelte Hardware unterstützt. Kein Linux, kein Mac, kein iPhone, kein garnichts. Und man hat sich auch dazu bekannt es in den nächsten Jahren nicht zu ändern.
Im Falle des PPC und PalmOS-Versionen hat man auch klar zum Ausdruck gebracht, dass diese Geräte mit einer Software versehen werden die lediglich zur Datenerfassung dienen und wenn überhaupt nur sehr eingeschränkte Auswertungsmöglichkeiten bieten. Dies aber vor dem Hintergrund, dass ein PC eben ganz andere Möglichkeiten bietet und wesentlich komfortabler zu bedienen ist, wenn es z.B. darum geht in einer Datenliste mehrere Einträge mittels Multiselect zu markieren und zu bearbeiten. Letztendlich hat man auch bei einer gewissen Datenmenge eine ganz andere Übersicht an einem PC-Bildschirm gegenüber einem PPC oder Palm. Das können diese Geräte einfach gar nicht bieten.
Wofür also z.B. ein WebKit für iPhone, Android, usw.? Sollen die Anwender (und ich gehöre auch dazu) doch die Kröte schlucken sich ein App kaufen zu müssen und einen vorgegebenen Workflow einzuhalten, eben mit Hilfe einer App Daten erfassen und nach Syncronisation auf dem PC auszuwerten. Wo ist da das Problem?
Gruß,
Mario
PS: Nicht böse sein. Ich bin es ja auch nicht. ;)
BTW: Was ist überhaupt eine Cloud? Für mich ist eine Cloud eigentlich immer etwas schlechtes...entweder regnet oder schneit es aus ihr, oder sie nimmt einem einfach nur die Sonne. ;D
-
Wofür also z.B. ein WebKit für iPhone, Android, usw.? Sollen die Anwender (und ich gehöre auch dazu) doch die Kröte schlucken sich ein App kaufen zu müssen und einen vorgegebenen Workflow einzuhalten, eben mit Hilfe einer App Daten erfassen und nach Syncronisation auf dem PC auszuwerten. Wo ist da das Problem?
Ich bin da einigermassen bei Dir und sehe z.B. die iPhone-App in Kombination mit SiDiaryOnline bzw. die PC-Version eher als Hybridlösung und ich finde es da auch völlig in Ordnung, dass man Dinge, die einfach nicht so häufig gebraucht werden auf den PC oder SDO verlagert werden aber genau das wurde ja kritisiert - also ist es scheinbar doch ein Problem...
Und ansonsten binden unterschiedliche Plattformen unterschiedliche Entwickler-Resourcen, d.h. die WebKit-Version ist derzeit ein ganz wichtiges Element, um beispielsweise den Android-Usern überhaupt eine Möglichkeit zu geben, SiDiary zu nutzen.
Du willst aber doch nicht dem Anwender vorwerfen, dass man sich bei Sinovo einen solchen Umfang an's Bein bindet und es dann nicht finanzieren kann.
Nein das will ich nicht. Ich habe lediglich versucht aufzuzeigen, warum Dinge manchmal etwas länger dauern.
Du bist da aber durchaus ein gutes Beispiel: Einerseits schreibst Du, dass es für Dich ok ist, einen Workflow vorgegeben zu bekommen, so dass bestimmte Auswertungen einfach nicht unterwegs mobil an Bord sind, anderseits ist Dein Feature-Hunger aber durchaus beträchtlich. ;)
Und wenn Du schreibst, dass für Dich die iPhone-App als Datensammler "toll" ist, ist es ja wohl auch nicht so, als könne man mit der Version grundsätzlich gar nicht arbeiten und uns vorzuwerfen, wir hätten etwas völlig unbrauchbares auf den Markt geworfen.
Wir können hier bei uns auch durchaus unterscheiden, dass Fehler eine andere Priorität haben als Feature-Entwicklung aber auch da muss ich etwas das Bild zurechtrücken: Patrik hat z.B. die komplette Entwicklung für heute unterbrochen und auf insgesamt 4 unterschiedlichen Testgeräten versuchen wir den Fehler von Dir reproduziert zu bekommen. Bislang ohne Erfolg.
Insgesamt ist ein solches Sync-Problem bei mehreren Hundert iPhone-Anwendern bislang exakt 2 mal gemeldet worden. Das alleine reichte uns aber aus, es als Top-Prio zu handhaben aber nochmal: Wir können es bislang trotz 3er beteiligter Personen noch nicht reproduzieren.
Was aber das wichtigste dabei war, dass man in diesem kleinen Softwarehaus im Leben nicht mit 3 Softwareentwicklern ausgekommen wäre, wenn man (auch auf die Gefahr hin manchen vor den Kopf zu stoßen) versucht hätte alle Wünsche von Kunden nach Portierung in andere Systeme zu erfüllen. Letztendlich wurden lediglich Windows-Systeme, PPC, PalmOS und selbstentwickelte Hardware unterstützt. Kein Linux, kein Mac, kein iPhone, kein garnichts
Es ist ja wohl auch offensichtlich, dass wir Versionen, deren Betriebssysteme auf dem absteigenden Ast sind, nicht gerade in der Entwicklung neuer Funktionalitäten forcieren aber dennoch ist auch hierfür von den Entwicklern bei Anfragen ein SecondLevel-Support zu leisten, der Resourcen bindet.
Ich glaube es war wirklich mal nötig klarzustellen, dass unsere iPhone-Version niemals so komplexe Auswertungen wird fahren können wie die PC-Version und auch die Android-Version wird niemals die Messgeräte auslesen können usw.
Primäres Ziel ist es auf möglichst vielen mobilen Plattformen, unterwegs seine Daten mit möglichst wenig Aufwand erfassen zu können und einen Grundstock an Auswertungen dabei zu haben, d.h. die Trendarstelllung und einfache Kurven etc.
Wir werden, wenn die Android-Version fertig ist mit Sicherheit auch die Update-Zyklen für die iPhone-Version verkürzen können und dann auch schrittweise neue Features in die mobilen Versionen integrieren (Nahrungsmittel-DB usw. sind auch auf WindowsMobile erst schrittweise nachgekommen) aber eine unserer mobilen Versionen wird niemals ein vollwertiger Ersatz für eine PC- oder die Online-Version werden!
Viele Grüße, Alf.
-
Ich weiß, dass ich hier oft an der Usability und Optik nörgele, aber so isses nun mal. Ich arbeite beruflich mit Design und Visualisierung und SiDiary macht mich stellenweise wahnsinnig.
Ich wünschte, ihr würdet Euch visuell und usabilitymäßig ein wenig an dem orientieren, was *möglich* und *sinnvoll* ist. Und deutlich mehr +in the cloud+ denken.. Dafür würde ich gerne weiter bezahlen.
Nun gut, wahnsinnig macht mich SiDiary nicht gerade, aber ich habe mich auch manchmal gewundert wo denn einige Funktionen versteckt sein mögen. Insbesondere zu Anfang habe ich noch unheimlich viel suchen müssen, da man sich in SiDiary nicht an die üblichen Standards von Windows-Software gehalten hat.
Das beginnt mit der Menüanordnung:
Warum gibt es nicht wie in jedem anderen vernünftigen Windows-Programm ein Menü "Extras" in dem sich ALLE Programmeinstellungen finden?
Warum gibt es kein Menü "Patientenverwaltung" in dem alle patientenabhängigen Daten gepflegt werden?
Warum ist die Funktion "Rückgängig: Sync (SiDiary OnlineServer)" in dem Menü "Bearbeiten", während die manuelle Sync-Funktion sich im Menüpunkt "Optionen/SmartSync-Einstellungen" befindet?
Warum ist der Menüpunkt "Backup" im Menüpunkt "Optionen"? Das sollte etwas ganz normales und nicht optionales sein und somit gehört diese Funktion in den Menüpunkt "Datei".
Warum gibt es in der Symbolleiste keine Schaltfläche für die Synchronisation und muss um diese Funktion manuell auszuführen erst in irgend ein Fenster über zwei Menüschritte springen?
Warum findet sich der Menüpunkt "Setup Mobiles Gerät" im Menü "Datei" und nicht in einem eigenen Einstellungmenüpunkt unter "Extras"?
Warum findet sich der Menüpunkt "Update" unter "Werkzeuge" und nicht wie in 99,9% aller Windows-Programme unter "Hilfe"?
Ich könnte wohl noch den ganzen Abend weiter machen, aber ich denke diese Punkte allein zeigen, dass SiDiary an den üblichen Standards vorbei programmiert wurde, bzw. ein bisschen Wildwuchs in den Menüs während der Fortentwicklung entstanden ist.
Ich bin jedenfalls der Meinung, dass das irgend wann mal bereinigt werden sollte.
Da das eigentlich mit der iPhone-App nichts zu tun hat werde ich den gleichen Beitrag auch einmal an anderer Stelle einstellen und somit einer breiteren Front zur Diskussion stellen. Ich hoffe es spricht nichts dagegen?
-
Da kommen jetzt aber auch einige Dinge zusammen.
Zum einen hat jede Plattform ihre eigenen Bedienkonzepte und -konventionen. Und da sieht ein Standard-Windows-Programm halt anders aus als ein Linux (=Android) oder Apple (iPhone) Produkz.
Dann kommt der Unterschied des Mediums dazu und die Frage, was ich womit mache. Auswertungen am PC, Datensammeln und ad hoc-Überblick auf mobilen Versionen. Wobei letzteres für mich keine Tortendiagramme oder Durchschnittswerte sind, daran kann ich mich zuhause in voller Pracht erfreuen. Wenn ich unterwegs bin, will ich einen Überblick über meinen Therapieverlauf und z.B. anhand der letzten Therapiedaten eine Aussage treffen können, ob ich gerade in einer up/down-Regulation oder einer Lipolyse bin. Und da ist eine Tortengrafik zwar hypsch anzusehen aber so hilfreich wie ein Kropf. Das heißt, unterwegs brauche ich Fakten, also entweder Therapiedaten oder z.B. meine Nahrungsmitteldatenbank. Oder meine Laborwerte zum Besuch bei einem anderen Arzt. Oder eine Suche a la wie habe ich das Mittwochsmenü bei dem Asia-Service, bei dem meine Firma immer bestellt, letztesmal berechnet und wo bin ich damit gelandet.
Heißt, ich habe grundverschiedene Anforderungen an eine mobile und eine Desktop-Variante sowohl in Sachen Bedienung als auch Funktionsumfang. So ziemlich das einzige, was beide gemeinsam haben, ist die DAtenbasis.
Grüße
Anja
-
Hallo Cat,
Kannst Du uns das evtl. nochmal auf der Support-Line schildern. Ich wüsste nicht, warum das Definieren der UDTs auf der Website zur Verdopplung von irgendwelchen Daten führen sollte? Die Definitionen der UDTs auf der Webseite ist ja noch nicht so lange implementiert aber wenn man dort UDTs definiert, werden die auch auf den PC mit gesynct (und umgekehrt) und dass dabei bzw. dem iPhone-Online-Sync UDT-Definitionen dupliziert werden, höre ich zum ersten Mal!?
Das wurde im September schon mal hier berichtet:
http://www.forum.diabetesinfo.de/forum/index.php/topic,9850.msg254078.html#msg254078
Wir sind hier wirklich noch immer mit einer ganzen Menge Enthusiasmus und Idealismus dabei aber irgendwo muss alles auch ein Stückchen finanzierbar sein und wir müssen vor allem die vorhandenen Entwickler-Ressourcen auf die Plattformen verteilen.
Das verstehe ich auch alles, sonst wäre ich nicht seit Jahren treue Kundin.
Und ja, ich denke auch, wir kommen aus sehr verschiedenen Richtungen/Sehweisen/Denken/Sehschulen: Ich eben aus der Ecke Visual Design und plattformübergreifende Erleichterung des Alltags. Das Zeitalter von Desktop-Software ist (fast) vorbei. Gottseidank.
Für mich ist bei einem Device die Usability das A&O. Das Max. an akzeptierter Umständlichkeit ist, dass ich bei einer App Parameter auf einem PC eingeben muss: solange das plattformübergreifend funktioniert, kein Problem.
Ich denke aber wie du auch, dass das für die meisten hier alles gut funktioniert.
Insofern... danke für dein ausführliches und sachliches Posting.
Cat
-
Ich möchte nur nochmal zu bedenken geben, daß die Entwcklung der V6 zu einem Großteil auch hier über das Forum gelaufen ist. Und es hat sich niemand beklagt, daß die Menüpunkte dort sind, wo sie jetzt zu finden sind.
Wenn man ein Programm nicht so häufig nutzt oder neu dabei ist wird man sich immer erst einarbeiten müssen. Ich musste heute auch erst in der Hilfe nachschauen, wie ich bei Corel Draw einen Text um 90° drehen kann.
Und um Photoshop auch nur ansatzweise bedienen zu können war sogar ein mehrwöchiges Video-Training notwendig.
Man kann eben nicht etwas mit der Funktionalität eines SpaceShuttles erwarten, daß sich so einfach bedienen lässt wie ein Dreirad.
Nichtsdestotrotz sind wir natürlich an Usability sehr interessiert. Aber wie Alf schon andeutete hat eben alles seine Priorität.
Viele Grüße,
Jörg
-
4
Und ansonsten binden unterschiedliche Plattformen unterschiedliche Entwickler-Resourcen, d.h. die WebKit-Version ist derzeit ein ganz wichtiges Element, um beispielsweise den Android-Usern überhaupt eine Möglichkeit zu geben, SiDiary zu nutzen.
Um dann eine App für Android zu entwickeln? Verstehe ich nicht...
Du bist da aber durchaus ein gutes Beispiel: Einerseits schreibst Du, dass es für Dich ok ist, einen Workflow vorgegeben zu bekommen, so dass bestimmte Auswertungen einfach nicht unterwegs mobil an Bord sind, anderseits ist Dein Feature-Hunger aber durchaus beträchtlich. ;)
Wenn das von vorn herein so definiert ist, ist das für mich ok. Wirklich...
Allerdings ist der angedachte Funktionsumfang wirklich etwas schwammig definiert und das es hier im Forum eine eigene iPhone-Rubrik mit einem Unterpunkt "Ideen für die Zukunft" gibt in der jeder sein Wunschkonzert spielen darf macht es einem auch nicht leichter zu erkennen, dass es eigentlich gar nicht vorgesehen ist so viel Funktionalität in eine iPhone-App zu packen.
Und wenn Du schreibst, dass für Dich die iPhone-App als Datensammler "toll" ist, ist es ja wohl auch nicht so, als könne man mit der Version grundsätzlich gar nicht arbeiten und uns vorzuwerfen, wir hätten etwas völlig unbrauchbares auf den Markt geworfen.
Bitte nicht als Vorwurf auffassen. Für die Zukunft direkt mal: Ich werfe niemandem etwas vor, sondern bin sehr froh über das was ihr macht. Ich möchte einfach nur meinen Beitrag dazu leisten. Also bitte alles als Anregung verstehen. ;)
Wir können hier bei uns auch durchaus unterscheiden, dass Fehler eine andere Priorität haben als Feature-Entwicklung aber auch da muss ich etwas das Bild zurechtrücken: Patrik hat z.B. die komplette Entwicklung für heute unterbrochen und auf insgesamt 4 unterschiedlichen Testgeräten versuchen wir den Fehler von Dir reproduziert zu bekommen. Bislang ohne Erfolg.
Ups...das ist mir ja schon fast peinlich. :o
Wie bereits geschrieben kann ich Euch nur anbieten auf meine Daten zuzugreifen.
Ich glaube es war wirklich mal nötig klarzustellen, dass unsere iPhone-Version niemals so komplexe Auswertungen wird fahren können wie die PC-Version und auch die Android-Version wird niemals die Messgeräte auslesen können usw.
Allerdiings... ;)
Primäres Ziel ist es auf möglichst vielen mobilen Plattformen, unterwegs seine Daten mit möglichst wenig Aufwand erfassen zu können und einen Grundstock an Auswertungen dabei zu haben, d.h. die Trendarstelllung und einfache Kurven etc.
DAS ist doch mal eine klare Ansage. :)
Wir werden, wenn die Android-Version fertig ist mit Sicherheit auch die Update-Zyklen für die iPhone-Version verkürzen können und dann auch schrittweise neue Features in die mobilen Versionen integrieren (Nahrungsmittel-DB usw. sind auch auf WindowsMobile erst schrittweise nachgekommen) aber eine unserer mobilen Versionen wird niemals ein vollwertiger Ersatz für eine PC- oder die Online-Version werden!
Wird es aufgrund der Übersichtlichkeit auch nie sein können.
Nahrungsmittel-DB finde ich übrigens ganz große Klasse! :banane:
Viele Grüße, Alf.
Viele Grüße,
Mario
-
Um dann eine App für Android zu entwickeln? Verstehe ich nicht...
Ganz einfach: Die Entwickler Skills für die WebKit-Version sind bei uns ungleich der Skills für die Android-Entwickler, d.h. wir konnten hier parallelisieren.
Zudem ist der Aufwand für die WebKit-Version ein Vielfaches geringer als eine komplette native Version (wo wir z.B. für iPhone bei 0 anfangen mussten)...
Es war von vornherein klar, dass wir iPhone und Android nicht so schnell mit nativen Versionen bedienen konnten, dass wir die WebKit-Version über unsere vorhandene SDO-App gestülpt haben. Der Aufwand war vergleichsweise überschaubar und hat übergangsweise den größten Schmerz bei den beiden Usergruppen gelindert.
-
Und ansonsten binden unterschiedliche Plattformen unterschiedliche Entwickler-Resourcen, d.h. die WebKit-Version ist derzeit ein ganz wichtiges Element, um beispielsweise den Android-Usern überhaupt eine Möglichkeit zu geben, SiDiary zu nutzen.
Um dann eine App für Android zu entwickeln? Verstehe ich nicht...
Um Daten auch dokumentieren zu können wenn man keinen Online-Zugriff hat (ländliche Gebiete) oder wünscht (Auslandsaufenthalt ->Roamingkosten)
Allerdings ist der angedachte Funktionsumfang wirklich etwas schwammig definiert und das es hier im Forum eine eigene iPhone-Rubrik mit einem Unterpunkt "Ideen für die Zukunft" gibt in der jeder sein Wunschkonzert spielen darf macht es einem auch nicht leichter zu erkennen, dass es eigentlich gar nicht vorgesehen ist so viel Funktionalität in eine iPhone-App zu packen.
So funktioniert eben das Konzept 'SiDiary'. Wir setzen nicht 2 Entwickler, die von Diabetes keinen Schimmer haben in einen Raum und sagen 'schreib uns mal ein Diabetes-Tool', sondern wir entwickeln die Ideen hier gemeinsam. Was dann davon tatsächlich umgesetzt wird hängt davon ab ob es medizinisch sinnvoll ist, vielen Usern nutzt und technisch machbar ist.
Das heißt nicht, das außergewöhnliche Ideen keine Chance haben (sofern sie medizinisch vertretbar sind). Das heißt, das viele Augen mehr sehen als nur zwei.
Und einen angedachten Funktionsumfang im Sinne von 'bis hier und nicht weiter' gibt es nicht. Es ist alles eine Frage der Zeit und der Priorität.
Viele Grüße,
Jörg
-
Ich möchte nur nochmal zu bedenken geben, daß die Entwcklung der V6 zu einem Großteil auch hier über das Forum gelaufen ist. Und es hat sich niemand beklagt, daß die Menüpunkte dort sind, wo sie jetzt zu finden sind.
Mit der Zeit und der wachsenden Zahl der Versionen wachsen eben auch die Ansprüche. Früher war man als Anwender froh, wenn es überhaupt irgendetwas gab. Wenn sich dann eine Lösung etabliert und diese langsam erwachsen wird, erwartet man auch gewisse Standards. Und das ist eben bei Windows-Anwendungen nicht nur WIMP, sondern auch die Art und Weise, wie es umgesetzt wird. Wenn in einer Windows-Anwendung Copy nicht mehr auf Strg+C sondern auf Strg+Alt+F2 liegt, dann ist es zwar schön, daß es vorhanden ist, aber es läuft dem Standard und damit der Usability und Intuitivität entgegen. Da die wenigsten das ganze zum Selbstzweck betreiben, sondern als Mittel/Werkzeug zu einem bestimmten Zweck, sind solche Zeitdiebe zumindest störend.
Wenn man ein Programm nicht so häufig nutzt oder neu dabei ist wird man sich immer erst einarbeiten müssen. Ich musste heute auch erst in der Hilfe nachschauen, wie ich bei Corel Draw einen Text um 90° drehen kann.
Und um Photoshop auch nur ansatzweise bedienen zu können war sogar ein mehrwöchiges Video-Training notwendig.
Man kann eben nicht etwas mit der Funktionalität eines SpaceShuttles erwarten, daß sich so einfach bedienen lässt wie ein Dreirad.
Nu ist der Funktionsumfang dort aber ungleich größer. Und auch die Erwartungshaltung und die damit verbundene Opferbereitschaft, wenn man sich daran setzt und beherzt aufs Icon klickt.
Nichtsdestotrotz sind wir natürlich an Usability sehr interessiert. Aber wie Alf schon andeutete hat eben alles seine Priorität.
Es wär ja auch schlimm, wenns anders wär. Und wenn man sieht, wie SiDiary sich über die Jahre entwickelt hat, dann könnt Ihr Euch ruhig einmal auf die Schulter klopfen und wir können gespannt sein, was die nächsten Jahre so alles kommt.
Grüße
Anja