Von neversfelde am Fr, 31. Oktober 2008 um 16:50 #
Nach meiner Auffassung ist es unverzichtbar für eine Groupware eine Synchronisationsmöglichkeit zu bieten. Afaik ist eine SyncML Schnittstelle in Planung, aber noch nicht integriert. Ich wage zu behaupten, dass Tine 2.0 damit eher die Qualität einer Testversion hat.
Ich schau mir das Projekt schon eine geraume Zeit an, und finde es sehr vielversprechend.
Ich würde es sogar schon nutzen, wenn ich meine Adressen auch irgendwie hinein bzw. heraus bekommen würde. Vorzugsweise per CSV Dateien mit einstellbarem Mapping und Filter für den Export, z.B. für Mailings.
Meines Erachtens ist ein Groupware ohne Kalender auch nur eingeschränkt nutzbar... Für nahezu jede Aktion ein eigenes Browserfenster aufzumachen halte ich auch nicht unbedingt für die beste Lösung, da jedes mal ein gutes MB an javascript übertragen werden muss (jaja, ich kenn den Browsercache). Das hätte man mit ExtJS durchaus anders lösen können. Aber trotzdem, das Projekt ist auf dem besten Weg eine ernstzunehmende Groupware zu werden.
Gratulation und nur weiter so!
@hjb: Wie kann man eigentlich Tine2.0 ohne javascript benutzen? SCNR
Das sehe ich genauso. Der fehlende Kalender und die Synchronisation ist das größte Manko. Vor allem aber der Kalender hat uns davon abgehalten Tine zu verwenden. Ansonsten ein sehr nettes Projekt.
Von Lars Kneschke (Tine 2.0 Core E am Fr, 31. Oktober 2008 um 23:29 #
Der Kalender kommt im 1 Quartal 2009.
Fenster im Fenster hören sich technisch erstmal ganz gut an, stoßen von der Benutzbarkeit aber ganz schnell an ihre Grenzen. 3 Kontakte auf einmal aufgemacht und schon müssen wir unser eigenes Windowhandling implementieren. Und bei einem Dualscreen möchte man auch gerne mal die Kontakte so bearbeiten, das sie die Hauptansicht nicht verdecken. also auf dem anderen Screen haben.
Im Zeitalter von Google Gears und HTML 5 kannst Du davon ausgehen, das gar kein Javascript zusätzlich übertragen werden muss wenn ein neues Fenster geöffnet wird. Selbst ohne diese Sachen machen die Browser einen "If-Modified-Since" Request, so das auch da nur sehr wenige Daten übertragen werden müssen.
Ich beobachte Tine seit seiner Abspaltung von eGroupware, da wir eGroupware vor einiger Zeit in der Firma eingeführt haben. Freigeschalten und genutzt wird davon allerdings nur der Kalender, der bei Tine noch fehlt. Daß der Kalender in eGroupware keine Top-Lösung ist, hat sich mittlerweile herrausgestellt. Deshalb hoffe ich auf Verbesserungen mit Tine. Interessant wäre allerdings, ob ich die Daten für Benutzer von eGroupware migrieren kann. Daß alle Benutzer selbst exportieren und importieren ist ausgeschlossen. Es muß für uns Admins möglich sein, die Umstellung vorzunehmen.
Und ganz besonders wichtig ist für uns eine Syncronisierung für diverse Geräte oder zumindest in Outlook um von dort weiter in die Geräte zu syncronisieren. Das haben wir mit eGroupware komplett aufgegeben. Alle möglichen Lösungen hatten wir probiert, aber waren nicht für den Produktivbetrieb nutzbar.
Die Demo sieht doch schon mal sehr gut aus und das Benutzerinterface scheint soweit auch ganz stimmig zu sein. Gut, email, Kalender und Sync fehlen noch. Wir benutzen egroupware schon seit Urzeiten und auch das Programm hat sich langsam in eine benutzbare Richtung entwickelt. Davor haben wir kurzzeitig phprojekt eingesetzt, dass sehr schnell war und zudem einen Zeittracker für Projekte hatte, den wir intensiv benutzt haben. Schön war, dass man ohne grosses Brimborium ein kleines Projekt erstellen konnte und ein Start-Stop drücken konnte (Nachtragen ging auch) Aber das war super. Ausserdem die Verknüpfungen der einzelnen Bereiche (Termin-Email-Info) die ja mittlerweile auch in egroupware vorhanden ist. Meiner Meinung nach unverzichtbar.
Tolle Wurst. Demo funktioniert nicht. Als erstes kommt ein weißer Bildschirm. Wenn man dann JavaScript einschaltet, dann kommt ein Anmeldefenster mit vorgegebenen Nutzerdaten. Dann kommt sekundenlang ein JavaScript-gesteuertes Subfenster "bitte warten" mit Rollbalken. Das verschwindet dann wieder. Es kommt keine Meldung. Und die Anmeldemaske erscheint wieder.
Fühlt sich an wie virulenter Softwareschrott. Da fühle ich alle meine Vorurteile gegen PHP-Anwendungen wieder bestätigt.
Von Patrick Willam am Di, 4. November 2008 um 04:56 #
Erstens:
Standardmäßig mit JavaScript und Cookies auf "an" im Internet herumzulaufen ist schlicht grob fahrlässig, was die Aspekte Sicherheit und Privatsphäre angeht.
Daß die Masse der Internetnutzer diese grobe Fahrlässigkeit entweder wissentlich (als vorgeblich unausweichliches Übel) oder unwissentlich akzeptiert, ändert nichts am Sachverhalt.
Und bei der Durchdringungsquote des Internets bei PCs und anderen 'Gadgets' einerseits und der Finesse und kriminellen Energie der Internet-Mafia andererseits ist die eigene Sicherheit letztlich auch immer die Sicherheit der anderen Netznutzer! ...Heutzutage mehr denn jemals zuvor.
Aber sich gegenüber solchen Gefahren hinzustellen wie ein Kind, daß die Hände vor die Augen hält und sagt "Ich kann euch nicht sehen, dann könnt ihr mich auch nicht sehen.", macht das Leben ja viel bequemer. Und im Falle eines Falles kann man dann ja auch ganz bequem mit dem Finger auf die bösen Erwachsenen zeigen, die einen mißbraucht (Malware-Mafia) oder -- schlimmer noch -- nicht schon vorher auf Schritt und Tritt vor dem Ungemach beschützt (AV-Sw-Hersteller; Recht+Gesetz) haben.
Software kann prinzipbedingt Malware erst erkennen, wenn sie schon auf dem eigenen Rechner ist. Sie ist daher niemals dazu geeignet Infektionen zu verhindern, sondern kann im besten Falle lediglich die mit einer Infektion einhergehenden Komplikationen auf ein Mindestmaß zu beschränken.
Leute, die sich daher lieber "mit Gummi" (d.h. ohne JavaScript und Cookies) im Internet bewegen, hinzustellen als könnten diese nicht 1+1 zusammenzählen, ist m.E. gar nicht lustig, sondern verunglimpfend.
Zweitens:
Webseiten im Allgemeinen und 'Web-Applikationen' im Besonderen sollten mit einem "degrade gracefully" auf das nutzerseitige Nichtvorhandensein von technischen Voraussetzungen reagieren; und zwar mindestens mit einer entsprechenden Information a la: "Ohne $Technik_A und $Technik_B funktioniert diese Seite nicht so, wie sie soll."
'Beliebt' sind leider auch immer wieder Seitenweichen, bei denen man -- sogar nachdem der gewünschte und eigentliche Seiteninhalt schon vollständig übertragen und nutzerseitig sogar schon vollständig gerendert wurde !! -- aufgrund des Fehlens von angeblich unabdingbar lebensnotwendigem JavaScript oder Cookies gleich wieder vor die Tür gesetzt wird, indem man auf eine "Dein Browser gefällt uns nicht" Du-kommst-hier-nicht-rein-Seite weitergeleitet wird.
Zugänglichkeit zu Informationen ist keine Spezialfunktionalität, die man "hintendrauf" für Behinderte strickt, sondern der Sinn und Zweck des WWW! Und jedes mal wenn man Hürden vor den Informationszugang aufstellt, dann schließt man Leute aus und begibt sich auf eine Insel. Web heißt schließlich, an dem anzuknüpfen, was ist.
Und wenn man schon keine Web-Seite macht, sondern sich mit einer Anwendung-auf-Browser-Plattform (sog. 'Web-Applikation') eine Insel baut, dann sollte der Türsteher wenigstens einen brauchbaren Hinweis von sich geben, warum man nicht hereingelassen wird.
Von Cornelius Weiss am Di, 4. November 2008 um 10:49 #
Die Einwände von kw und Patrick sind uns durchaus bekannt und sie sind auch berechtigt.
Es kommt allerdings wie immer drauf an, wie viel Sicherheit das Unternhemen braucht und bezahlen kann.
Wir sehen hier Prinzipiell zwei Szenarien um die Sicherheit zu erhöhen: 1. Intranet / Internet Physikalisch getrennt. Intranet Anwendungen wie Tine sind nur im Intranet erreichbar. Das ist vermutlich die sicherste Option. Allerdings hat nicht jede Firma das Geld jedem Mitarbeiter zwei Rechner auf den Schreibtisch zu stellen. Auch die Probleme echte Nutzdaten ins interne Netz zu bekommen, sind nicht ganz ohne. Wer allerdings sehr hohe Sicherheitsanforderungen hat, wird nicht umherkommen so vorzugehen.
2. Tine nur im Prsim benutzen. Der Anwender kann cookies und javascript in seinem normalen browser ruhig ausstellen, da tine nur via prsim ,also wie eine normale Anwendung, benutzt wird. Dieser Ansatz löst schon mal die von Patrick und kw erwähnten Probleme. Die Lösung ist sehr kostengünstig einzuführen. Allerdings bleiben die 'normalen' Probleme bestehen die halt immer da sind wenn Rechner direkt im Internet stehen und somit verlohren gehen können.
Ich würde es sogar schon nutzen, wenn ich meine Adressen auch irgendwie hinein bzw. heraus bekommen würde.
Vorzugsweise per CSV Dateien mit einstellbarem Mapping und Filter für den Export, z.B. für Mailings.
Aber trotzdem, das Projekt ist auf dem besten Weg eine ernstzunehmende Groupware zu werden.
Gratulation und nur weiter so!
@hjb: Wie kann man eigentlich Tine2.0 ohne javascript benutzen? SCNR
Alex
Fenster im Fenster hören sich technisch erstmal ganz gut an, stoßen von der Benutzbarkeit aber ganz schnell an ihre Grenzen. 3 Kontakte auf einmal aufgemacht und schon müssen wir unser eigenes Windowhandling implementieren. Und bei einem Dualscreen möchte man auch gerne mal die Kontakte so bearbeiten, das sie die Hauptansicht nicht verdecken. also auf dem anderen Screen haben.
Im Zeitalter von Google Gears und HTML 5 kannst Du davon ausgehen, das gar kein Javascript zusätzlich übertragen werden muss wenn ein neues Fenster geöffnet wird. Selbst ohne diese Sachen machen die Browser einen "If-Modified-Since" Request, so das auch da nur sehr wenige Daten übertragen werden müssen.
Und ganz besonders wichtig ist für uns eine Syncronisierung für diverse Geräte oder zumindest in Outlook um von dort weiter in die Geräte zu syncronisieren. Das haben wir mit eGroupware komplett aufgegeben. Alle möglichen Lösungen hatten wir probiert, aber waren nicht für den Produktivbetrieb nutzbar.
Zum Thema Synchronisation findest Du hier ein aktuelles Statement: http://lars.kneschke.de/index.php?/archives/2008/10/29.html
Wir benutzen egroupware schon seit Urzeiten und auch das Programm hat sich langsam in eine benutzbare Richtung entwickelt. Davor haben wir kurzzeitig phprojekt eingesetzt, dass sehr schnell war und zudem einen Zeittracker für Projekte hatte, den wir intensiv benutzt haben. Schön war, dass man ohne grosses Brimborium ein kleines Projekt erstellen konnte und ein Start-Stop drücken konnte (Nachtragen ging auch) Aber das war super. Ausserdem die Verknüpfungen der einzelnen Bereiche (Termin-Email-Info) die ja mittlerweile auch in egroupware vorhanden ist. Meiner Meinung nach unverzichtbar.
Demo funktioniert nicht.
Als erstes kommt ein weißer Bildschirm.
Wenn man dann JavaScript einschaltet, dann kommt ein Anmeldefenster mit vorgegebenen Nutzerdaten. Dann kommt sekundenlang ein JavaScript-gesteuertes Subfenster "bitte warten" mit Rollbalken. Das verschwindet dann wieder. Es kommt keine Meldung. Und die Anmeldemaske erscheint wieder.
Fühlt sich an wie virulenter Softwareschrott. Da fühle ich alle meine Vorurteile gegen PHP-Anwendungen wieder bestätigt.
Finger weg!
(also -man)
Sehr lustig.
Standardmäßig mit JavaScript und Cookies auf "an" im Internet herumzulaufen ist schlicht grob fahrlässig, was die Aspekte Sicherheit und Privatsphäre angeht.
Daß die Masse der Internetnutzer diese grobe Fahrlässigkeit entweder wissentlich (als vorgeblich unausweichliches Übel) oder unwissentlich akzeptiert, ändert nichts am Sachverhalt.
Und bei der Durchdringungsquote des Internets bei PCs und anderen 'Gadgets' einerseits und der Finesse und kriminellen Energie der Internet-Mafia andererseits ist die eigene Sicherheit letztlich auch immer die Sicherheit der anderen Netznutzer! ...Heutzutage mehr denn jemals zuvor.
Aber sich gegenüber solchen Gefahren hinzustellen wie ein Kind, daß die Hände vor die Augen hält und sagt "Ich kann euch nicht sehen, dann könnt ihr mich auch nicht sehen.", macht das Leben ja viel bequemer. Und im Falle eines Falles kann man dann ja auch ganz bequem mit dem Finger auf die bösen Erwachsenen zeigen, die einen mißbraucht (Malware-Mafia) oder -- schlimmer noch -- nicht schon vorher auf Schritt und Tritt vor dem Ungemach beschützt (AV-Sw-Hersteller; Recht+Gesetz) haben.
Software kann prinzipbedingt Malware erst erkennen, wenn sie schon auf dem eigenen Rechner ist. Sie ist daher niemals dazu geeignet Infektionen zu verhindern, sondern kann im besten Falle lediglich die mit einer Infektion einhergehenden Komplikationen auf ein Mindestmaß zu beschränken.
Leute, die sich daher lieber "mit Gummi" (d.h. ohne JavaScript und Cookies) im Internet bewegen, hinzustellen als könnten diese nicht 1+1 zusammenzählen, ist m.E. gar nicht lustig, sondern verunglimpfend.
Zweitens:
Webseiten im Allgemeinen und 'Web-Applikationen' im Besonderen sollten mit einem "degrade gracefully" auf das nutzerseitige Nichtvorhandensein von technischen Voraussetzungen reagieren; und zwar mindestens mit einer entsprechenden Information a la: "Ohne $Technik_A und $Technik_B funktioniert diese Seite nicht so, wie sie soll."
'Beliebt' sind leider auch immer wieder Seitenweichen, bei denen man -- sogar nachdem der gewünschte und eigentliche Seiteninhalt schon vollständig übertragen und nutzerseitig sogar schon vollständig gerendert wurde !! -- aufgrund des Fehlens von angeblich unabdingbar lebensnotwendigem JavaScript oder Cookies gleich wieder vor die Tür gesetzt wird, indem man auf eine "Dein Browser gefällt uns nicht" Du-kommst-hier-nicht-rein-Seite weitergeleitet wird.
Zugänglichkeit zu Informationen ist keine Spezialfunktionalität, die man "hintendrauf" für Behinderte strickt, sondern der Sinn und Zweck des WWW!
Und jedes mal wenn man Hürden vor den Informationszugang aufstellt, dann schließt man Leute aus und begibt sich auf eine Insel. Web heißt schließlich, an dem anzuknüpfen, was ist.
Und wenn man schon keine Web-Seite macht, sondern sich mit einer Anwendung-auf-Browser-Plattform (sog. 'Web-Applikation') eine Insel baut, dann sollte der Türsteher wenigstens einen brauchbaren Hinweis von sich geben, warum man nicht hereingelassen wird.
Von daher: kw hat recht.
Mit besten Grüßen
Es kommt allerdings wie immer drauf an, wie viel Sicherheit das Unternhemen braucht und bezahlen kann.
Wir sehen hier Prinzipiell zwei Szenarien um die Sicherheit zu erhöhen:
1. Intranet / Internet Physikalisch getrennt. Intranet Anwendungen wie Tine sind nur im Intranet erreichbar.
Das ist vermutlich die sicherste Option. Allerdings hat nicht jede Firma das Geld jedem Mitarbeiter zwei Rechner auf den Schreibtisch zu stellen. Auch die Probleme echte Nutzdaten ins interne Netz zu bekommen, sind nicht ganz ohne. Wer allerdings sehr hohe Sicherheitsanforderungen hat, wird nicht umherkommen so vorzugehen.
2. Tine nur im Prsim benutzen. Der Anwender kann cookies und javascript in seinem normalen browser ruhig ausstellen, da tine nur via prsim ,also wie eine normale Anwendung, benutzt wird.
Dieser Ansatz löst schon mal die von Patrick und kw erwähnten Probleme. Die Lösung ist sehr kostengünstig einzuführen. Allerdings bleiben die 'normalen' Probleme bestehen die halt immer da sind wenn Rechner direkt im Internet stehen und somit verlohren gehen können.
LG Cornelius / Tine 2.0
> 2. Tine nur im Prsim benutzen.
Ich vermute es handelt sich um einen Fipptehler und gemeint war: wiki.mozilla.org/Prism