OTRS 2.4 Fork?

[Andre Bauer]

Aufgrund der aktuellen Entwicklungen bei OTRS 3.0, mehren sich bei uns die Stimmen, die Version 2.4.x zu forken, um weiterhin ein OTRS zu haben, mit dem man schnell und produktiv arbeiten kann.

Derzeit werden unserer Meinung nach beim neuen Design zu viele Kompromisse eingegangen, nur um z.B. mobile Touchscreen Devices wie Iphone/Ipad usw. richtig ansprechen zu können. Der Großteil der alteingesessenen OTRS Nutzer, die aber weiterhin am PC arbeiten, müssen mit den dadurch entstehenden Einschränkungen leben, was wir nicht hinnehmen wollen.

Viele andere Funktionen benötigen jetzt auch mehr Klicks, um überhaupt zum Ziel zu kommen, was den neuen Ajax Eyecandy Funktionen geschuldet ist, die viele nützliche Menüs behindernd verbergen oder sogar gänzlich abschaffen. Letztendlich verlangsamt das OTRS 3.0.x Design den gesamten Workflow erheblich, was letztlich wieder zu mehr Kosten führt.

Daher überlegen wir OTRS auf Grundlage der Version 2.4.x mit dem bekannten Theme zu forken. Webspace, SVN, Bugtracker werde ich dafür gern bereitstellen.

Wir wollen so ein Projekt aber nicht allein stemmen. Auch an weiteren Entwicklern fehlt es derzeit noch.
Ich möchte daher hiermit anfragen, ob und wer daran überhaupt Interesse hat oder ob wir die Einzigen sind, die das kommende 3.0 Design nicht praxistauglich finden?

Zur Zeit haben wir (ich und 1 weiterer Entwickler) folgenden Plan:

- Schaffung der nötigen Infrastruktur (Website, Wiki, Forum, Bugtracker, SVN)
- Namensfindung (Vorschläge?)
- erste Version auf Basis von OTRS 2.4.8 bzw. 2.4.x CVS
- ?

Wir sind für weitere Ideen und Vorschläge offen...

[Daniel Obee]

Leider bin ich mit der Evaluierung noch nicht soweit, dass ich mir eine endgültige Meinung bilden könnte. Daher hier nur ein paar Überlegungen dazu:

* Mein grundsätzlicher Eindruck von der 3.0 Oberfläche ist ähnlich: Auch wenn sich die Oberfläche erst mal schneller anfühlt, einige Standardfunktionen verstecken sich hinter Menüpunkten oder Listen und dafür werden Dinge, deren Nutzen (zumindest für uns) fragwürdig ist, nach vorne geholt.
* Meine Erfahrungen mit der "ViewLink" Suche zeigen, dass OTRS nicht unbedingt für den Einsatz mit 2,5 Mio Tickets entwickelt wird. Ich konnte die 3.0 noch nicht im Großeinsatz testen. Meinen Befürchtung: Durch die ganzen Ajax-Funktionen fliegt uns bei unserer Datenmenge das System um die Ohren.
* Forken ist ein brutaler Einschnitt in die Entwicklung eines Open Source Systems. Entwicklungs- und Supportressourcen werden geteilt, was umso schwerer wiegt, wenn eine 'Nischen'-Programmiersprache wie Perl benutzt wird.
* Wenn schon forken, dann wohin? Schon jetzt gibt es mindestens zwei sich teilweise in den Anforderungen widersprechende Nutzungen: die ITSM/ITHelpdesk zentrierte und die Kundenservice-zentrierte. Es macht m.E. wenig Sinn, beide Entwicklungsstränge in beide Richtungen zu entwickeln. Nehmen wir noch Change Management hinzu, sind wir bei zig Einzellösungen.
* Gibt es keine Möglichkeit, die Oberfläche (oder eine verbesserte Variante) der 2.4 als Theme/Skin zu programmieren? Die Änderungen unter der Haube halten sich meines Wissens nach in Grenzen. Es müsste also eigentlich möglich sein, ein Theme zu entwickeln, ähnlich des CiCS der Cape-IT. Damit würde man den Anschluss an die Core-Entwicklung nicht verlieren.

Alles erst mal nur Gedanken dazu. Insbesondere auch, da noch nicht klar ist, wie lange das OTRS eine derart zentrale Rolle in unserer Kundenservice Infrastruktur spielen wird (und kann).

Gruß
Daniel

[Andre Bauer]

Ja, ich weiß, dass ein Fork die letzte Möglichkeit sein sollte und auch Nachteile mit sich bringt.

So wie ich die Antworten auf einige meiner 3.0 Enhancement Requests deute, werden weiterhin die Bedürnisse einiger weniger Nutzer über die der Langzeitnutzer gestellt.
Die ganze usability Studie geht mir zu sehr an der Praxis vorbei. Ein Problem was mir auch schon bei den Designern unserer Programm aufgefallen ist, die halt keine Ahnung von der eigentlich Anwendung haben.
Das Design Büro war mit Martin ja bei uns in der Firma und wunderte sich noch über den "exzessiven" Gebrauch von Textbausteinen.
Das Ergebnis ist nun, dass Textbausteine nur noch über ein Dropdwon nutzbar sind. Für uns ein klarer Rückschritt. Wir hatte uns eigentlich eher Verbesserungen erhofft, wie z.b. vom Agenten verwaltbare Textbausteine.

Beim Theme wollen wir auf jeden Fall beim Standard 2.4.x bleiben. Bei dem Cape IT Design gefällt mir das Menü nicht so. Das ähnelt ja schon stark der 3.0.

Ich muss zugeben, über ITSM / Changemanagement hab ich mir gar keine Gedanken gemacht, da wir das nicht nutzen.
Auf diese Teile würde ich bei einem Fork verzichten wollen und mich ausschließlich auf OTRS konzentrieren.

Die Geschwindigkeit ist bei uns auch ein Thema, seit wir unsere CustomerDB angebunden haben.
Das liegt imho aber hauptsächlich an: http://bugs.otrs.org/show_bug.cgi?id=4732
Das wäre auch eine der ersten Sachen, die ich bei einem Fork angehen wollen würde.

Die Idee mit dem 3.0 kompatiblen 2.4 Theme klingt nicht schlecht. So blöd es klingt ist das aber erst mal mehr Entwicklungsaufwand als ein Fork.

[ferrosti]

Ich bin gerade dabei einen Upgrade Path von 2.2.4 (mit ITSM, aber ungenutzt) auf 3.0b (ohne ITSM) auf einem Testsystem vorzubereiten.

Von der Demo der 3.0b, die online ist bin ich recht begeistert, auch wenn einige Steps, genau wie ihr es beschreibt um einiges mehr an Zeit kosten.
Meine Idee bisher war allerdings ausgehend vom 3.0er Release auf dem Framework aufbauend einen Backport zu machen, welcher eben die alten Funktionalitäten wieder einbindet. In das 3.0er Framework bin ich bisher allerdings noch gar nicht eingestiegen und kann daher den Aufwand nicht abschätzen.
In meiner Situation ist bei den ganzen Anpassungen in unserem System das Upgrade von 2.2 auf 2.4 mit ebensoviel Aufwand verbunden, wie mit einem Upgrade auf 3.0 mit Anpassungen (eigener Programmierung).

Meine Idee wäre daher: In der Community ein 3.0er Paket zu erstellen, welches die Funktionalität der 2.4 in die 3.0 integriert.

Ich hoffe man kann meinen wirren Gedankengängen folgen?

[Daniel Obee]

Zum Thema Textbausteine wollte sich OTRS mal mit mir in Verbindung setzen. Wir haben bereits vor einiger Zeit ein Modul entwickeln lassen, das auf dem FAQ Modul basiert, Textbausteine aber Queue-abhängig zur Verfügung stellt. Ich hängs mal an, vielleicht ist es ja ungefähr das, was Du suchst.

Es war zumindest mal im Gespräch, eine Community Version davon bauen zu lassen. Leider hat sich seit dem niemand mehr bei mir gemeldet.

Im Laufe der Zeit hab ich selbst ein paar einfache Usability-Änderungen gemacht, wie z.B. Settings und LogOut in die rechte obere Ecke zu verbannen und einige Dashboardänderungen. Einen Instant-Statistik gibt's jetzt auch. Dadurch läuft es jetzt auch für die Agents recht rund.

Ich neige daher auch ein wenig zum 'Konservatismus', der einen zu der alten Oberfläche tendieren lässt. Kenn ich, mag ich, mach ich besser. Das Cape-IT Theme war für mich nie eine Alternative, sondern sollte nur als Beispiel herhalten. Zu bunt und dann auch wieder sehr auf ITHelpdesk ausgerichtet.

@ferrosti: wir haben die 2.4 zwar schon, aber ansonsten kann ich deinen Ausführungen sehr gut folgen. Vor einem Update auf die 3.0 graust es mir, zumal im deutlich 5-stelligen €-Bereich portiert werden müsste. (Ich bin Produkt Manager, kein Programmierer oder SysOP. Dass ich an Kleinigkeiten im OTRS rumpfusche ist ein Hobby , das ich mir von Zeit zu Zeit während meiner Arbeitszeit gönne.) Die Frage wäre halt, was die Zukunft von OTRS 3.0 noch so bringt. Bisher waren die Updates im Allgemeinen doch recht wertvoll.

Gruß
Daniel

[Andre Bauer]

Danke für das Plugin aber wir haben inzwischen eine Browsererweiterung, die es den Agenten erlaubt eigene Antworten zu verfassen und miteinander zu tauschen. Leider ist die nicht Plattformunabhängig, daher hatte ich noch auf Verbesserungen in 3.0 gehofft...

Also eventuelle machts auch Sinn sich für ein and 3.0 angepasstes 2.4 Theme zusammen zu tun.

Am besten wäre es ja, das 2.4 Theme stünde standardmäßig auch in 3.0 zur Auswahl...

[Daniel Obee]

... die es den Agenten erlaubt eigene Antworten zu verfassen und miteinander zu tauschen...

Genau das war der Grund das Teil damals programmieren zu lassen. Wenn man wie wir mit externen Call Centern arbeitet, dann sind sich unkontrolliert verbreitende Textbausteine der Stoff für Alpträume.

2.4 als wählbares Theme wäre natürlich ein Traum...

Gruß
Daniel

[ferrosti]

Textbausteine führen wir auch gerade ein, allerdings mit einer Fremdsoftware.
Bei der OTRS Einführung war auch eine Entwicklung von Textbausteinen auf Basis der FAQ im Gespräch, wurde dann aber runter priorisiert.

Es wundert mich, dass die Jungs bei OTRS die Designwünsche der Kunden nicht dem entsprechend aufgreifen. Fragt sich nur, ob das einfach nicht gewollt ist oder ob der Informationsfluss vom Consulting zur Entwicklung manchmal hakt.

Wie auch immer, ich migriere erst einmal auf dem Testsystem zu 3.0b. Dann werde ich mal sehen, was man da machen kann.

[_mg_]

Hi.

Die Diskussion fing ursprünglich in einem Bugzilla-Bug an, hier der Link: http://bugs.otrs.org/show_bug.cgi?id=5911. Dort habe ich gerade eine Antwort verfasst, die ich hier auch in Auszügen wiedergeben möchte:

- It is true that the focus of the default agent skin of OTRS 3+ is not the
power user managing a high ticket load.
- However, we DO want to support power users as well, for example with
possibilities to turn special features on by configuration.
- We listened to your reports and integrated changes because of them, such as
- New Ticket masks are now no popup windows any more
- There is now the possibility to configure shortcuts in the toolbar above
the main navigation. These allow you one-click access to arbitrary menu items,
which is even faster than opening a menu on mouse over. There is also, still,
the possibility to use keyboard shortcuts to open the menu items directly.
- We made it possible to create own skins for OTRS. (see
http://doc.otrs.org/developer/3.0/en/ht ... html#skins for details) All
aspects of the GUI which can be controlled via CSS can be changed by providing
some CSS, and perhaps images, as part of a new skin (without changes to the
DTLs). This allows you to create a skin which gives OTRS a completely different
look and feel, for example reducing whitespace areas, making tables rows
smaller, repositioning the main navigation et al.

I believe that many of the changes you desire can be achieved by creating a
skin for "power users" and applying some configuration changes.

We are still interested in _constructive_ cooperation, as I said in another bug
report. It would also be a possibility to ship another skin as part of OTRS.

Die Türen bei OTRS sind offen, allerdings wird sich der Fakt, dass der "default"-Skin nicht speziell auf Poweruser abgestimmt ist, nicht ändern. Über die Aufnahme eines zusätzlichen Skins können wir gern reden.

Zum Thema Textbausteine kann ich leider nichts sagen.

Bitte lasst mich wissen, inwiefern überhaupt Interesse besteht, an diesen Themen zusammen mit OTRS zu arbeiten. Ob und inwieweit wir an der Planung für die Fertigstellung der 3.0 noch etwas ändern können, müsste ich intern abklären.

Herzliche Grüße,
_mg_

[ferrosti]

Es wundert mich, dass der Fokus bei OTRS nicht (mehr) auf den Power Usern liegen soll. Für alle anderen lohnt sich doch eher ein kleineres TRS. Gerade die Anfragen hier im Forum zeigen doch, dass Erweiterungen in der Richtung gefragt sind.

Ich habe gerade wenig Zeit mich auf die Suche zu begeben
- Gibt es ein zentrales _Forum_ , wo rein über die Entwicklung der 3.0 diskutiert werden kann (habe leider aus der Firma keine Möglichkeit auf die NG zuzugreifen bzw. zu posten)

BTW: Ich verstehe diesen Thread nicht als Abkehr vom 3.0er Zweig, sondern als Diskussion um eine einfache Erweiterung großer, bestehender Systeme. Dies ist für mich der eigentliche Inhalt und nicht die Bildung eines Forks, auch wenn die Überschrift das so darstellt.

[Andre Bauer]

Hallo Martin

Natürlich besteht von unserer Seite (Magix) Interesse, weiter mit OTRS zu arbeiten. Ein Fork wäre für uns nur die letzte Möglichkeit, weiter unsere gewohnten Workflows anzuwenden.
Wir wollen uns halt alle Türen offen halten und prüfen, wie andere User zu der Thematik stehen.

Eine weiteres Theme (bzw. einfach das alte von 2.4) für Power User, dass alle alten Funktionen enthält und wieder sparsamer mit dem Platz umgeht, wäre super und würde von unserer Seite eindeutig vor einem Fork präferiert werden. Dass dies nicht das Standard Theme wäre, ist kein Problem für uns. Es muß halt nur die Möglichkeit geben umzuschalten.

Bisher hatte ich diese Möglichkeit nicht gesehen.

Man könnte zwar, wie von die vorgeschlagen, ein eigenes Theme entwickeln, jedoch bin ich bis jetzt immer am besten gefahren, wenn ich nur die Standardfunktionen verwende. Patches oder eigene Themes machen dauerhaft nur Arbeit bei der Pflege eines Systems und verhindern meist die zeitnahe Migration auf das nächste Major Release oder sogar das einspielen von sicherheitskritischen Updates.

Grüße
André

[Daniel Obee]

Sinnvollerweise sollte man sich da mal in Ruhe zusammensetzen. Nach meinen Erfahrungen im 'Modding' der 2.4 sind es oftmals nur sehr kleine Änderungen, die viel bringen. Allerdings gibt es auch ein paar ernste Themen, die deutlich in den Core reinreichen:

- die MySQL Index Problematik, die m. E. sehr leicht zu lösen wäre, indem man in der SysConfig die Felder der externen Datenbank als 'lowered' definiert und dann entsprechend abfragt
- die vermaledeite Suche im AgentLinkObject
- die mangelhafte Möglichkeit bestimmte Verwaltungsaufgaben an Teamleiter zu delegieren, ohne ihnen gleich Adminrechte gewähren zu müssen (MiniAdmin ist da nicht ausreichend)

Letztlich wird es in einem ernstzunehmenden Umfeld immer die Notwendigkeit von kleineren Anpassungen, aber auch das Budget dafür geben. Ich habe nur manchmal das Gefühl, es wird durch die Mehrfachentwicklung dieser Anpassung ohne eine sinnvolle Standardaufnahme das System ausgebremst. Verschiedene Themen (und deren teuer bezahlte Nischen-Lösungen) tauchen immer wieder auf, und OTRS hinkt trotzdem genau an diesen Stellen hinterher.

Beispiele: Textbausteine, verknüpfbare Freitextfelder in Abhängigkeit voneinander, Mehrsprachigkeit der Freitextfelder, intelligentes Mailrouting anhand von Keywords, Textvorschläge anhand von Keywords, verschiedene Dashboardmodifikationen, automatische Zeiterfassung... es gibt so viele.

Ich bin wirklich ein Fan von dem System, stehe aber inzwischen vor einem gewissen Rechtfertigungszwang, da andere Lösungen bei etwa gleichem Kapitaleinsatz unter Umständen mehr Funktionalität bringen. Spätestens wenn der nächste Portierungs-KV mit einer 5-stelligen Summe auf dem Schreibtisch des Chefs liegt, wird es wieder spannend.

BTW: Ich verstehe diesen Thread nicht als Abkehr vom 3.0er Zweig, sondern als Diskussion um eine einfache Erweiterung großer, bestehender Systeme. Dies ist für mich der eigentliche Inhalt und nicht die Bildung eines Forks, auch wenn die Überschrift das so darstellt.

Sehe ich ähnlich. Bzw. auch als einen Versuch, ein wenig Lobbyarbeit für die Arbeitstiere unter den OTRS Systemen zu machen. Die stellen zwar vielleicht nicht die Masse der Systeme und schön müssen sie auch nicht sein - aber im Endeffekt sind sie es, die die Musik machen.

Gruß & schönen Feierabend
Daniel

[Mike_B]

Hi André,

(Bitte entschuldigung, ich finde es sehr schwer Deutsch zu reden...)

I'm sorry to hear that you feel a bit disappointed about the OTRS 3 product in some places.

Doing a fork and maintaining it successfully is very resource intensive. I understand that you don't really like some of the features in version 3. So far I saw you mentioned the template selection for replying on a ticket (which is now in a drop-down instead of a list) and the issue that mysql queries are lowered when using a customer backend so indexes are not used.

To be honest, I feel it would be MUCH less effort and MUCH more a route to success if you would put the energy into solving that issue in OTRS3 or 2.4 instead of your 2.4.x fork, right? It's not that we would hate it if the LOWER issue is fixed, or if there would be a configuration option to show a list of templates instead of a drop-down in the ticket zoom window.

That said, of course we also see lots of people using OTRS for handling lots and lots of tickets (higher ticket volume, lower difficulty per ticket then the 'internal help desk' scenario. We really feel also these types of scenarios should be able to use OTRS; and are always open for suggestions, code contributions, discussions and stuff like that.

--
Mike

[Andre Bauer]

Hallo Mike

Wie gesagt, sollten sich die verschiedenen Probleme in OTRS 3 lösen lassen, werden wir es gern verwenden. Das einfachste wäre wohl, wenn der 2.4 Style auch in 3.0 verwendbar wäre.

Für uns allein ein eigenes 3.0 Theme zu pflegen ist uns aber zu viel Arbeit. Dann lieber zusammen mit einer Community einen Fork weiter entwickeln.

Grüße
André

[Mike_B]

Hallo Mike
Für uns allein ein eigenes 3.0 Theme zu pflegen ist uns aber zu viel Arbeit. Dann lieber zusammen mit einer Community einen Fork weiter entwickeln.

I'm sorry but I really can't see how forking and maintaining the fork would be less effort than contributing enhancements to the OTRS 3 codebase.

Also, if you're really keen on having a 2.4-like and/or speed-oriented theme, and it's too much work to do alone (which I can understand), you can also think about making that a community effort, right?
--
Mike

[Andre Bauer]

I'm sorry but I really can't see how forking and maintaining the fork would be less effort than contributing enhancements to the OTRS 3 codebase.

Das hängt davon ab, wie man die Sache angeht. Forken geht relativ schnell und das Betreuen des Projektes ist für mich nebenbei machbar. Kommt zum Forum und Wiki eben noch ein SVN und ein Bugtracker dazu...

OTRS 2.4.x mit einem bereits bestehenden, funktionierenden Theme zu forken ist für mich also erst mal weniger Arbeit als für 3.0 ein komplett neues zu entwickeln, dass ich dann bei jedem Update von 3.0 neu anpassen muss.

Die Weiterentwicklung des Forks sehe ich dann als Communityprojekt.

Ich denke also das wäre durchaus machbar und sinnvoll, wenn wir mit der 3.0 nicht mehr arbeiten können.

[Mike_B]

I'm really sorry, but forking is not about getting a bug tracker and a source code control system and a forum and a mailing list. It's much more. For companies to adopt your fork, they have to have trust that you are actually a sustainable project with an active group of developers. Otherwise they'll be stuck in some time with a piece of software that once was a great idea.

The OTRS.org project exists now for nearly 10 years, and has a global company behind it, with a group of dedicated developers working on the source code on a daily basis.

And even if I see that you like some things to be different about OTRS and especially v3, I really think that it's just a waste of time, effort and talent if you would decide to fork 2.4. Of course I can see that you want to stick on 2.4 until 3 has been extended with some of the stuff you are looking for (easier menus, template lists instead of drop-downs), I can even see how you would like to create a package that contains fixes just for you or a smaller group of people, but that's just customizations, and very much different from a complete fork.

BTW did you look at Martin Gruner's suggestion of creating separate buttons for phone tickets, queue view and such? That's just a simple configuration which can bring you some of the stuff you now feel are much more difficult because they're one click more in comparison with 2.4.

--
Mike

[Andre Bauer]

There are much more things we dont like in 3.0 (examples in the bugtracker bugs 5908, 5909, 5910, 5911, 5912).

The 3.0 theme is a no go for us. It wastes space and is slower to use. We dont want to use it even if its slightly adjusted.

I can understand that you dont like the idea of a fork but this is the decession of the people behind.

[ferrosti]

So wie ich das im Moment sehe geht OTRS mit der 3.0 den Weg, den Windows von XP zu Windows 7 gemacht hat.
Ich habe mein IT System gerade in einer Testumgebung von 2.2 auf die 3.0 gebracht und werde anfangen zu testen, entwickeln und Wünsche einzubringen. Leider bin ich kein Entwickler und traue mir nicht zu meinen Code ins SVN zu bringen.

IMHO wäre es sinnvoller eine "3.0 Power User Community" einzurichten, als einen 2.4er Fork abzuspalten. Sicherlich ist der initiale Aufwand um einiges höher. Wenn ich aber den Fokus auf die nächsten drei Jahre lege, dann bietet das komplette AJAX Framework mit einem Poweruser Theme mehr Komfortabilität als ein 2.4er Fork.
Bisher habe ich nur ein wenig in die 3.0 geschaut und finde sie von den Klicks her aufwändiger, von der Response Time jedoch deutlich besser. Dies ist für mich einer der Gründe auf der 3.0 aufzusetzen und nicht die 2.4er abzuspalten. Ein weiterer wichtiger Aspekt ist der Support durch die xxx. Für einen Fork wird dieser nicht erfolgen können. Und ich bin froh, wenn etwas nicht läuft jemanden anrufen zu können und mich auszuweinen.

@Mike
Ich finde den Bugtracker für eine "Wishlist" eher suboptimal. Wäre es möglich hierfür eine andere Anlaufstelle wie ein Forum etc. zu geben?

[Mike_B]

@Mike
Ich finde den Bugtracker für eine "Wishlist" eher suboptimal. Wäre es möglich hierfür eine andere Anlaufstelle wie ein Forum etc. zu geben?

Sure, I can feel your pain. Actually we're internally testing out a new piece of software to gather ideas and that has nice things as voting and commenting. If it does what we want it to (and it seems like it does) then we'd be bound to make it publicly available in probably a couple of weeks or so.
--
Mike

[Mike_B]

IMHO wäre es sinnvoller eine "3.0 Power User Community" einzurichten, als einen 2.4er Fork abzuspalten. Sicherlich ist der initiale Aufwand um einiges höher. Wenn ich aber den Fokus auf die nächsten drei Jahre lege, dann bietet das komplette AJAX Framework mit einem Poweruser Theme mehr Komfortabilität als ein 2.4er Fork.

+1 - I'd really be open to get features for power users - to the extent that you're missing them today - into OTRS 3.x.
--
Mike.

[Andre Bauer]

Ich finde den Bugtracker für eine "Wishlist" eher suboptimal. Wäre es möglich hierfür eine andere Anlaufstelle wie ein Forum etc. zu geben?

Wir hatte hier so etwas im Forum schon mal. Hat sich aber nicht bewährt, da es hier und im Bugtracker parallel gepflegt werden musste.
Daher der Verweis auf den Bugtracker. Ich glaube da ist es auch besser aufgehoben, da es die erste Anlaufstelle für Leute ist, die z.b. nicht ins Forum schauen.

[Daniel Obee]

Wie wäre es denn mit Getsatisfaction oder Uservoice? Beides sehr brauchbare Tools, wenn es um das Erfassen von Requests geht...

[Mike_B]

Wie wäre es denn mit Getsatisfaction oder Uservoice? Beides sehr brauchbare Tools, wenn es um das Erfassen von Requests geht...

Yeah, it's similar to that.
--
Mike.

[Johannes]

Hi,

ich geb hier auch mal meinen Senf dazu.
<Achtung pers. Meinung>
Ich hab, direkt nachdem ich das 3.0 DEMO Image Online gestellt hatte, viele Anfragen per Mail zum Design und Usability.
Ich habe da bisher nicht drauf reagiert um mir selber eine objektive Meinung bilden zu können.

Kurz ich mag es nicht. die Gründe wurden oben zur genüge erläutert.
Kurz: mir ist es zu langsam und hat zuviel Grafik Elemente.
Ein paar Kern Features in der Statistik oder der Queue<->Firma Zuordnung wären mir pers. lieber gewesen.

Wir haben aktuell 2 Studenten hier die ein wenig mit dem Theme experimentieren und versuchen das mit den neuen "Features" zu vereinen und in unseren Corporate Look zu bringen. Das ganze ist sehr an das urspr. CAPE IT Theme angelehnt. Auch die Textbausteine der Cape-IT haben wir in einer angepassten Variante im Einsatz. Ich kann ja einem MA, der seit 1 Jahr mit der 2.4.x Oberfläche (angepasst auf CI und Bedürfnisse) arbeitet, nicht einfach das Standard 3.0 hinpacken und sagen "mach mal".
</Achtung pers. Meinung>

Generell stellt sich mir eine Frage. Wie lang wird der 2.X Stamm (>2.4) noch supportet und mit Updates versorgt?

Einen Fork halte ich für mehr als problematisch. Ob die Community, so groß sie auch sein mag, stark genug ist das zu stemmen, wage ich zu bezweifeln. Wir werden ja nicht zum Upgrade gezwungen, von daher sehe ich die Migration 2.4.x noch als "Spiel" Projekt nicht als Pflicht.

Die Features hauen mich in 3.0 eh nicht vom Hocker.

Gruß

Hannes

[Mike_B]

Generell stellt sich mir eine Frage. Wie lang wird der 2.X Stamm (>2.4) noch supportet und mit Updates versorgt?

Hi Hansi,

(again, please excuse me for my English)

OTRS support contracts support up to the last 2 minor releases. This means that 2.4 will be supported until we create 3.2 (because then 3.2 and two versions back, 3.1 and 3.0, are supported). So for now you'll be perfectly safe. And if needed, we can always arrange custom contracts.
Also, we will still port back any security fixes. Of course any new features will be added to OTRS 3.0 (or more probably 3.1) so you will not benefit from them as long as you stay on 2.4. That said, I guess it is a pretty sensible decision to only start upgrading to v3.x if there is enough benefit (feature- or otherwise) to do so for you. This can mean that this is only when we release a version 3.1 with tons of great features

hth

Mike

[Johannes]

Make no mistake here,
genrally we want to upgrade our OTRS to 3.x but actually the user interface is horrible to use. If you want to be fast you need a clear frontend and no "web 2.0" markup. Design has to follow the function and not vice versa.

An OTRS Developer day would be fine...some OTRS developer, some customer and some beer...
This would be a good base to talk about the new 3.x release.

What all should keep in mind is, that OTRS earns money with support and custom contracts for adjustments. So this release produces much effort to the customers and the employees. I dont want to know what our adjustments to the theme, tweaks to some functions and the small features we had added in 2.4.x would cost in 3.x :D

Lets wait what our students can do...

Greetz...

P.S.
Looking forward to 3.1 beta

[Andre Bauer]

Also wie der Text aus dem 3.0.1 Release Note zustande kommt würde mich jetzt mal interessieren?

You will benefit from quicker access to relevant

informations, a higher transparency and increased efficiency in

your daily work. OTRS Help Desk 3.0 was designed based on a huge

variety of interviews with power users from different industries

Quicker Access???
increased efficiency???

Das stimmt imho nicht. Vielleicht kann ja noch mal jemand die Verbesserungen am Design so erklären, dass auch mir sich die Vorteile erschließen

OTRS 3.0 ist leider (noch?) kein Tool für Poweruser.

Naja. Warten mir mal auf 3.1...


P.S.: Wieso wurde das 3.0 Stable Release eigentlich vorgezogen?
War das nicht für Anfang Dezember geplant?

Edit: Habs gefunden: http://otrs.org/news/2010/otrs_3-0-launch/

[Johannes]

*unterschreib*

[ferrosti]

Ich weiß gar nicht wo ihr das Problem seht?
Die Menüs öffnen auch per MouseOver, kann man in der Config einstellen.
Wenn ich nur auf einer Queue arbeiten will, dann mache ich das über das Dashboard. ich selektiere mir die jeweilige Queue für "Meine Queues" und arbeite dann über "Neue Tickets" oder wie auch immer ich das brauche, indem ich im jeweiligen DashBoard Modul eben auch auf "Meine Queues" eingrenze.
Wo ist das Problem?

[Andre Bauer]

Ich weiß gar nicht wo ihr das Problem seht?

Dann ließ bitte den kompletten Thread + verlinkter Bugreports.

Wenn ich für meine gewöhnten Workflows in 3.0 mehr Zeit benötige als in 2.4, ist das nun mal ein Rückschritt.

[Johannes]

Ich weiß gar nicht wo ihr das Problem seht?
Die Menüs öffnen auch per MouseOver, kann man in der Config einstellen.
Wenn ich nur auf einer Queue arbeiten will, dann mache ich das über das Dashboard. ich selektiere mir die jeweilige Queue für "Meine Queues" und arbeite dann über "Neue Tickets" oder wie auch immer ich das brauche, indem ich im jeweiligen DashBoard Modul eben auch auf "Meine Queues" eingrenze.
Wo ist das Problem?

*persönliche Meinung*
Das Problem liegt in der Struktur der UI.
Das mag für deinen Fall grade passen. Ist auch schön zu hören, nur leider nutzen einige OTRS direkt über Queues analog einer Ordnerstruktur, bzw mit fixen Worklows die halt schnell gehen müssen.

Das ganze Ajax Geraffel macht die Sache jetzt nicht unbedingt angenehmer, schneller und kompatibler.
Wenn ich da als Bsp. an eine früher verwendete Voxtron Agentel Integration denke, die könnte man mit der 3.0 klemmen weil die integrierte Browser Engine zu lahm ist dafür. Liegt jetzt nicht zwingend an OTRS sondern an Voxtron, sollte man aber auch auf der Liste haben.

In der Firma für die ich arbeite und das OTRS betreue, nutzen wir es primär im Customer Support. Da führt mich kein Weg zur 3.0. Unser aktuelles 2.4.x in direkter Konkurrenz zur 3.01 ist vom Speed und den Funktionen weit vorn. Allein die Lesbarkeit der einzelnen Felder ist zum ******.

Wie überall wird auch bei in Zeiteinheiten pro Ticket gerechnet. Und da sollte der Trend ehr zu weniger als zu mehr gehen.

Die Anpassungen, um 3.x auf ein gleiches Niveau zu bringen wie unser 2.4x werden gut Zeit und Nevern kosten.
Technisch sollte es soweit ich das überblicke halbswegs gleich bleiben.
Mittlerweile nutzen wir relativ viele Post/Pre Filter Module für unsere komplexeren Abläufe, wenn sich hier nicht soviel geändert hat passt es zumindest auf der Ebene.

Evtl. kann Cape IT hier mit Ihren tollen Modulen helfen...aber ich glaub den Jungs glüht auch der Kopf.

Kurz: es kann gut aussehen, muss aber auch funktionieren und anpassbar bleiben.

Ggf. sollte die Community (nat. nur bei Bedarf) ein Oldschool Theme bauen

*/persönliche Meinung*

[ferrosti]

Ich habe vor zwei Wochen die 3.0b5 einem unserer Kundenservice Manager vorgestellt und der war sehr begeistert.
Sicherlich kann ich verstehen, dass die Arbeitsweisen absolut unterschiedlich sind und in Euren Fällen die neue Oberfläche dann auch sehr hinderlich sein kann. Meiner Meinung nach bringt die integrierte YUI in der Bedienung Geschwindigkeitsvorteile. Klickwege und gewohnte Arbeitsweisen sind grundverschieden, da gebe ich Dir natürlich Recht.
Ich komme allerdings von dem Ansatz her, dass die 3.0 ein grundsätzlich anders aufgebautes System sein soll. Dass die OTRS Entwickler hier erst eine Basis aufbauen, auf der dann customized werden kann finde ich absolut normal und auch richtig. Wie bei SuSE 9.0 muss man ja nicht unbedingt die X.0 einsetzen, es zeigt aber in welche Richtung es sich bewegt. Vielleicht wird erst die 3.1 für die Poweruser interessant.

Ich fände Eure Zeit in einem 2.4er Fork auf die nächsten zwei Jahre gerechnet 'verschwendet' (ist das falsche Wort, mir fällt leider gerade kein geeignetes ein). Wenn WIR als Community uns ordentlich an ein Customizing der 3.0 machen würden, dann wäre IMHO unsere Arbeitskraft wesentlich sinnvoller genutzt.

Die OTRS Wishlist ging meiner Meinung nach komplett am Ziel vorbei. Was User da an Schwachsinn geposted haben geht auf keine Kuhhaut mehr. Nach der ersten Woche hätte man quasi einen Aufnahmestopp machen müssen.

Wie immer, meine .02€

[Boity]

2.4 als wählbares Theme wäre natürlich ein Traum...

Full ACK - mehr kann man nicht dazu sagen !


Aktuell OTRS 3 Current im produktiv Einsatz ist ein Graus.

[wurzel]

Hallo,

ich hab OTRS 3.0.x angeschaut und finde Themes schöner, und ingesamt auch leichter zu bedienen. Das 2.4er find ich manchmal doch wie soll ich sagen "umständlich."

Von daher kann ich die Aufregung garnicht verstehen Ich hab zwar zu Beginn ein paar Sachen nicht auf Anhieb gefunden, aber jetz kann ich flüssig damit arbeiten.

'n wählbares 2.4er als Theme wäre aber sicher 'ne gute Alternative.

viele Grüße
Flo

[dschulz]

Ich sehe forks generell als gute Option aber bei einem Projekt wie OTRS erscheint mir das nicht sinnvoll.

Ich denke schon, dass sich die von PowerUsern gewünschten Features in OTRS 3 integrieren lassen, aber das erfordert etwas Koordination und Mitarbeit der OTRS Group.

Wichtig wäre mir hier zum einen ein schlankes, möglichst JS-freies, Webinterface das auch in alten Browsern und mit niedrigen Auflösungen vernünftig bedienbar ist.

Weiterhin wäre da natürlich noch einen Reihe von Performance-Problemen unter der Haube die ich schon in einem anderen Thread angesprochen habe (http://forums.otrs.org/viewtopic.php?f=34&t=6206).

[Schojo]

Dem Ganzen kann ich nur voll und ganz zustimmen. Ticketbearbeitung dauert im Schnitt um die 10 Sekunden länger was bei 80 Tickets pro Tag und 3 Agents schon irgendwann was ausmacht.

Dieses Klicki-Bunti Interface mag vielleicht zeitgemäß sein, aber auch wie du sagtest die Anpassungen für die iPhone Nutzer (...) lassen alle Anderen im Regen stehen.

Ich würd euch auf jeden Fall unterstützen wo es nur geht!

[ferrosti]

Ich würde gerne mal zu einer sachlichen Analyse übergehen, wo bis auf die Klickwege runtergebrochen wird, wo sich diese Zeitverluste her ergeben.
Wenn ich versuche die 3.0 genauso wie die 2.3 (mit 2.4 habe ich keine Erfahrung) zu bedienen, dann dauert es länger, das stimmt. Gerade mit dem Dashboard und geänderten Abläufen funktioniert das Bearbeiten aber wiederum wunderbar, jedenfalls in unserem Umfeld.

Kann der Nächste bitte mal einen Thread im 'Developers' Bereich dazu aufmachen und die Wege genauer darlegen?