JVerein

Hallo miteinander,

ich habe jetzt schon bei einigen Funktionen gesehen, dass es eine Diskrepanz gibt zwischen dem, wie und für was sie gedacht sind, und wie sie benutzt werden. Das führt bei Änderungen dann zwangsläufig zu Problemen, man übersieht Anwendungsfälle.

Die Bankdaten stehen unter "Zahlung", dienen also dem Einzug von Gebühren etc. Entsprechend benötigt man sie nur bei Lastschrift, ansonsten können sie ausgeblendet werden. Nicht zuletzt durch die SEPA-Regelungen sind dort auch diverse Informationen gespeichert, die für eine Überweisung zum Mitglied irrelevant sind (man benötigt kein Mandat), und dagegen sprechen, die Felder als Adressbuch zu nutzen.
Gleichzeitig ist es natürlich praktisch, zur Erstattung von Auslagen etc. die Bankdaten auch für Überweisungen an das Mitglied am Mitglied (und nicht losgelöst) zu speichern.
Dass eingetragene Zahlungs-Bankdaten automatisch im Hibiscus-Adressbuch landen, legt letzteres auch nahe (die Funktion kannte ich noch garnicht). Allerdings sollte dies dann auch in der GUI entsprechend klar strukturiert sein (und eben nicht unter "Zahlung" stehen).
Die Bankverbindung von Nicht-Mitgliedern, denen man regelmäßig etwas überweisen muss, kann wiederum logischerweise nur in Hibiscus verwaltet werden. Somit kann man auch argumentieren, dass Zahlungsempfänger grundsätzlich über Hibiscus verwaltet werden, der Import aus JVerein ist dann einfach ein nettes Zusatzfeature (was aber offensichtlich zu Irritiationen führen kann).

Ich habe mich vor ein paar Wochen erstmalig intensiv mit JVerein beschäftigt und kann aus der Erfahrung heraus sagen, dass es einige Dinge gibt, die man als neuer Benutzer komisch findet. Man kommt schon damit zurecht und arrangiert sich mit manchem, da JVerein sehr vieles mehr als ausreichend löst und kostenlos ist - für mich und meinen Verein ist es eine super Lösung. Wenn man JVerein allerdings als ein Produkt ansieht, würde ich sagen, müsste man konzeptionell manches überarbeiten und polieren, um es konsistenter zu machen. Dadurch würde es für Neueinsteiger intuitiver und bei der Produktauswahl attraktiver werden. Dies erfordert aber auch ein richtiges Produktdesign mit einer expliziten Anforderungs-/Produktspezifikation (was soll das Produkt können, und eine Abgrenzung was nicht) - auf der Basis kann man dann auch Änderungen planen und diskutieren. Allerdings ist es durchaus legitim, wenn Heiner mit dem jetzigen Weg fortfährt, der für 80% der Benutzer befriedigend ist.

Viele Grüße und Frohes Neues!
Tobias

Hallo Tobias,

vielen Dank für deine Anmerkung. Ich habe den Thread jetzt mal umbenannt, da er komplett vom Thema abgedriftet ist.

mal ein paar Anmerkungen dazu:
- ist der Anspruch der Entwickler und der Benutzer auf 80% stehen zu bleiben?
- darf ich zukünftig bei Auffälligkeiten diese hier melden oder soll ich sie gleich ignorieren?
- ist es möglich an dem Programm vernünftig weiter zu arbeiten oder wird das gleich im Keim erstickt ?

PS: bitte lest auch mein Vorstellung im separaten Themenbereich
http://www.jverein.de/forum/viewtopic.php?f=3&t=1743

Stefan

Hallo Tobias,

ich leide sicher unter einer bestimmten "Betriebsblindheit". Allerdings habe ich auch ein Problem damit, wenn JVerein-Neulinge ohne sich mit dem Thema beschäftigt haben, lange Listen mit Änderungswünschen aufstellen (Mein altes Programm ist Mist aber das neue Programm muss so aussehen wie das Alte).

In JVerein/Hibiscus gibt es sicher auch einige Dinge, die einfach so gewachsen sind. Beispielsweise das von dir angesprochene Thema mit den Bankverbindungen. Ursprünglich gab es in JVerein die Bankverbindung des Mitgliedes für die Lastschrift. Später hat Olaf dann in Jameica die Möglichkeit angeboten, das Jameica-Plugins über ein Interface Daten für das Jameica-Adressbuch bereitstellen. Anschließend kamen die zusätzlichen Adressen (Spender, Lieferanten/Trainer ....). Dann gab es vor 2 oder 3 Wochen hier im Forum den Wunsch, die Pflichtfeldkennzeichnung für Bankverbindungen so zu ändern, dass sie nur bei Basislastschriften existiert, die du dann so umgesetzt hast, dass alle Bankverbindungsdaten ausgeblendet werden. Das wiederum hier im Forum zu Diskussionen führte.

Wenn man JVerein allerdings als ein Produkt ansieht, würde ich sagen, müsste man konzeptionell manches überarbeiten und polieren, um es konsistenter zu machen. Dadurch würde es für Neueinsteiger intuitiver und bei der Produktauswahl attraktiver werden. Dies erfordert aber auch ein richtiges Produktdesign mit einer expliziten Anforderungs-/Produktspezifikation (was soll das Produkt können, und eine Abgrenzung was nicht) - auf der Basis kann man dann auch Änderungen planen und diskutieren.

Dazu noch etwas Hintergrundwissen: JVerein wurde von mir ursprünglich zur Erledigung meiner Aufgaben als Kassierer einer DLRG-Ortsgruppe entwickelt. Später habe ich es dann als OpenSource zur Verfügung gestellt. Es war nie geplant, daraus ein kommerzielles Produkt zu machen.

Für das Produktdesign müsste man zunächst die Zeit finden. Danach muss es auch noch realisiert werden. Ich bin mir sicher, dass es anschließend weiterhin 20 % der Benutzer gibt, die das Design als ungewöhnlich und verbesserungsfähig kommentieren.

Meine Erfahrung aus 8 Jahren JVerein-Entwicklung ist, dass es mindestens soviele Vorgehensweisen bei der Erledigung der Vereinsaufgaben gibt, wie es Vereine gibt. Zum Teil liegt das an der Vielfältigkeit der Vereine, an den unterschiedlichen Größenordnungen und natürlich an der Kreativität der Vereinsvorstände. Das läßt sich schwer in ein Schema pressen.

Mein Vorschlag ist, dass die insbesondere die Newcomer aber auch die alten Hasen Tutorials zur Verfügung stellen. Darin kann ausgiebig beschrieben werden, wie JVerein im konkreten Einzelfall genutzt wird. Daran können sich dann die JVerein-Einsteiger orientieren.

Ich bin gerne bereit, die Benutzerfreundlichkeit von JVerein zu optimieren. Allerdings müssen die Dinge auch mit Jameica/SWT ... machbar sein und der Aufwand muss vertretbar sein oder es muss sich ein JVerein-Nutzer finden, der diese Aufgaben übernimmt. Wichtig ist dann auch, dass die zur Verfügung gestellten Entwicklerversionen zeitnah von vielen JVereinern getestet und kommentiert werden. Die Kommentare nach Freigabe der Version sind schlicht und einfach zu spät.

Heiner

Hallo miteinander,

ich hoffe, beide Seiten konnten sich in meinem vorigen Beitrag wiederfinden.

Stefan, ich denke als Informatiker kennst Du die 80/20er-Regeln. In einem Hobbyprojekt stellt sich sicherlich die Frage, ob man den Aufwand für die restlichen 20% auf sich nehmen will, oder ob man sich nicht übernimmt und verzettelt. Das betrifft nicht unbedingt den hier ursprünglichen Änderungswunsch, aber einige andere Themen die sich im Forum finden.

Heiner, die Geschichte von JVerein kann ich nachvollziehen. Sie zeigt sich aber auch in der Software, was vor allem Neueinsteigern auffällt.

Eine Anregung für den Release-Prozess: Aktuell scheint es ja so, dass es vor allem kurz vor einem Release Entwicklerversionen zum Download gibt. Der Release von 2.6.0 und 2.6.1 kam dann recht unvermittelt. Ich hätte mir einen Release-Candidate gewünscht, den Interessierte testen können, mit Hinweis auf die Neuerungen und Fixes. Die Version 2.6.0 empfand ich als zu unreif.

Viele Grüße,
Tobias

Hallo,

zum Thema 80/20 noch die Anmerkung von mir, dass es sicher eine Frage der eigenen Position und der eigenen Anforderungen. Ich bin mir sicher, dass für einige Nutzer bereits 100 oder 120 % erfüllt sind. Ähnlich wie z. B. den Office-Produkten wird oft nur ein Teil der Funktionen benötigt.

Zum Release-Prozess: Für die Version 2.6 gab es Entwicklerversionen von Jan.-Dez. 2013. Auf die es zu SEPA sicher einige Rückmeldungen und Diskussionen gab. Den Rest haben nur wenige getestet. Bei der Version 2.6.1 handelt es sich um ein Bugfix-Release. Da habe ich vorher Entwicklerversionen nur direkt an einzelne Nutzer geschickt, die Probleme berichteten. Es wird noch die Version 2.6.2 zum Thema SEPA-Sammellastschriften geben. Danach geht es an die Version 2.7.

Für die Version 2.7 habe ich mir das Thema Datenbankschicht vorgenommen. Momentan wird ein Jameica-Interner O/R-Mapper eingesetzt. Mit dem gibt es aber Performance-Probleme inbesondere bei MySQL. Momentan experimentiere ich mit Hibernate.

Noch einmal: Ich habe nichts gegen konstruktive Kritik. Davon lebt dieses Projekt. Ich sperre mich nicht gegen eine Weiterentwicklung und gegen eine Restrukturierung von JVerein. Allerdings habe ich, wie bereits mehrfach geschrieben, ein Problem, wenn jemand die ersten Gehversuche mit JVerein macht und gleich alles Infrage stellt.

Wie wäre es, wenn ihr beiden (Tobias und Stefan) ein entsprechendes Konzept erarbeitet, dass dann hier diskutiert wird. Bei der Umsetzung könnt ihr beiden Informatiker dann sicher auch behilflich sein.

Heiner

Hallo Heiner,

die 80/20 beziehen sich nicht nur auf Benutzer, sondern auch auf Interessenten. Da JVerein (und auch sonst keine Software) alles kann und allen gerecht wird, werden sich einige Interessenten gegen JVerein und für eine andere Lösung entscheiden. Das ist aber auch kein Problem und noch weniger ein Vorwurf! Für mich selber ist JVerein eine deutliche Verbesserung gegenüber meiner alten Software.

Für Konzeptarbeit werde ich keine Zeit haben, mein Urlaub ist nun um. Deswegen schreibe ich ja auch, dass man sich gegen diesen Aufwand entscheiden kann.

Zu Releases: Wie wäre es, einen Release-Candidate bereit zu stellen, und dazu eine Test-Checkliste? Die Test-Checkliste wäre eine Sammlung der Funktionen und Anwendungsfälle, ganz simpel als Tabelle im Wiki. Sie muss nicht gleich vollständig sein, sondern könnte mit der Zeit immer weiter ausgebaut werden. Damit hätten wir einen Testplan. Ich erstelle mal ein Beispiel, dann kannst Du schauen, ob Du es sinnvoll findest.

Wenn wir schon bei generellen Themen sind: Ich würde mir automatisierte Tests (v.a. Unit-Tests) wünschen.

Viele Grüße,
Tobias

Hallo Tobias,

Zu Releases: Wie wäre es, einen Release-Candidate bereit zu stellen, und dazu eine Test-Checkliste? Die Test-Checkliste wäre eine Sammlung der Funktionen und Anwendungsfälle, ganz simpel als Tabelle im Wiki.

Wenn du was lieferst, nehme ich das gerne ins Wiki auf.

Heiner

Hallo Tobias, hallo Heiner,

ich habe jetzt wieder ein klein bisschen Zeit mit zu diskutieren.
Die Umstellung der Daten auf JVerein hat etwas Aufwand in Anspruch genommen.

Aber nochmal zur Verdeutlichung:
Ich habe mich FÜR JVerein entschieden, d.h. ich bin der Meinung, daß das Programmpaket schon eine gute Grundlage ist.

Als Newbie stolpere ich allerdings auch gerade über jede kleine Unschönheit. Das ist für mich auch kein großes Problem, da ich als Informatiker mit den Zicken der Computer und deren Software umgehen kann. Aber schön ist es für andere Newbies nicht. Und ihr könntet das Chance nutzen, das Programm weiter zu entwickeln. Ich bin in diesem Fall nichts anderes als ein Tester. Ich hatte z.B. im alten Programm nach einigen Jahren nach der Übernahme festgestellt, daß Beiträge vergessen wurden einzuziehen. Grund: ein Feld war nicht auf semantisch korrektem Wert. Dadurch sind uns Beiträge durch die Lappen gegangen. Der vorherige Kassier hat das nicht gemerkt. Das ist bei jedem Programm ungeschickt. Das lässt sich sicher auch nicht verhindern. Aber es sollte minimiert werden können, eventuell durch einfache Gegenproben. In JVerein ist mir das jetzt fast auch passiert, aber ich habe den Beitragsvorschau/einzug mit alter SW verglichen.

Ansonsten: ihr habt natürlich alle überwiegend Recht. Ich wollte hier nur die Unschönheiten festhalten und zur Diskussion bringen. Ich bin der Meinung, daß diese nur Kleinigkeiten sind und in jeder Version zur Korrektur gebracht werden können. Dabei habe ich nicht gesagt, wer das machen soll und wann das gemacht werden soll.

Zur Konzeptsache: ich habe nicht ganz verstanden wie du dir ein Konzept vorstellst:
solltest du ein Konzept für eine gänzlich neue Version mit anderer Struktur meinen, so muß ich ebenfalls sagen fehlt mir momentan die Zeit. Für Ergänzungen und Änderungen bzw. Fehlerkorrekturen sollte immer Platz und Möglichkeit sein. Ansonsten möchte ich dir folgendes Vorgehen/Konzept für "Wünsche" vorschlagen:
- Ein Wunsch (welcher Art auch immer) wird hier als Thread durch ein User gestartet
- handelt es sich um ein Verständnis-Problem, erklärt der Entwickler (heiner, ...) die Hintergründe --> daraus resultiert aber das Handbuch ist ev. unverständlich oder zu mager, somit im Handbuch Ergänzungen
- sind es wirklich Änderungen/Ergänzungen/Korrekturen so diskutieren die Benutzer über für und wieder, Auswirkungen, Entwickler moderiert hier "nur"
- Nachfragen an den Ersteller über genauere Hintergründe des Wunsches sind natürlich erlaubt
- Grundsatz: Jeder "Wunsch" hat auch seinen Hintergrund und somit auch seine Berechtigung
- Die Entwickler (heiner,...) äussern Vorstellung/Konzept über Realisierung
- bei keinem Widerspruch kann dies in ein Feature bei einem nächsten Release überführt werden
- das Handbuch bekommt hinreichend Erweiterung über speziell dieses Feature
- jede zukünftige Änderung, die ein Feature direkt betrifft, kann somit im Handbuch erkannt werden und wird ev. konfigurierbar gemacht oder als Vorhanden realisiert
- Alternativ könnte man auch ein "echtes" Lastenheft und eine Realisierungspezifikation parallel laufen. Das ist meiner Meinung nach aber über Wiki so nicht realisierbar und wahrscheinlich auch recht aufwändig.

heiner: daß du übrigens darüber nachdenkst an grundsätzlichen Teilen im Programm zu arbeiten, zeigt mir zumindest, daß du aktiv daran arbeitest. Das ist sehr schön.
Ansonsten hätte ich mal die Frage: hast du einen Download-Zähler deiner Release-Files ? Wie oft werden diese Dateien gedownloaded ?
D.h. wieviele Verein nutzen das Programm noch ? Die Liste unter Vorstellung der Vereine oder die Liste der angemeldeten User ist sicher nur eine Hausnummer. Es ist nicht bekannt, wieviele Benutzer wieder von JVerein weg sind und ihren Account nicht mehr benutzen.
Außerdem würde ich mich freuen, wenn viele Benutzer hier sich auch mal zu diesem Thema äußern. Es wäre einfach mal interessant, wenn hier ein allgemeiner Tenor erkennbar wäre.
Auch noch zu dem Thema: altersabhängige Beiträge. Es sieht nicht gut aus, wenn du Benutzer vergraulst und anschliessend das Feature doch auf ein Art und Weise realisierst. Mit obigem Ablauf und genügend Zeit um Benutzern eine Chance zu geben, wäre meiner Meinung nach jeder zufrieden.

Ich hier nochmal deutlich sagen, daß JVerein eine gute Grundlage ist und deine Arbeit (heiner) und natürlich auch die anderen beteiligten Entwickler sehr schätze. Ich hätte dies sicherlich in dem Umfang bis dato nicht gemacht.

Stefan

Hallo Stefan,

Zur Konzeptsache: ich habe nicht ganz verstanden wie du dir ein Konzept vorstellst:

Eine vollkommene Neukonzeption und Neuentwicklung ist utopisch. Wie schon alleine dieser Thread zeigt, fehlt allen Leuten die Zeit. Realistisch ist eine sanfte Migration in eine verständlichere Version. Diesen Job kann ich allerdings nicht übernehmen, da ich als Entwickler die existierende Lösung für verständich halte.

Dein Vorschlag zur Ergänzung des Handbuchs finde ich gut. Wenn du möchtest, schicke ich dir Zugangsdaten zum Wiki.

- Ein Wunsch (welcher Art auch immer) wird hier als Thread durch ein User gestartet

Das wird schon so gemacht.

- handelt es sich um ein Verständnis-Problem, erklärt der Entwickler (heiner, ...) die Hintergründe --> daraus resultiert aber das Handbuch ist ev. unverständlich oder zu mager, somit im Handbuch Ergänzungen

Auch das wird gemacht.

- sind es wirklich Änderungen/Ergänzungen/Korrekturen so diskutieren die Benutzer über für und wieder, Auswirkungen, Entwickler moderiert hier "nur"

Das funktioniert eher weniger. Es gibt oftmals Themen, die nur ein oder zwei Leute interessieren.

- sind es wirklich Änderungen/Ergänzungen/Korrekturen so diskutieren die Benutzer über für und wieder, Auswirkungen, Entwickler moderiert hier "nur"
- Nachfragen an den Ersteller über genauere Hintergründe des Wunsches sind natürlich erlaubt
- Grundsatz: Jeder "Wunsch" hat auch seinen Hintergrund und somit auch seine Berechtigung

Damit habe ich ein Problem. Ich werde in die Rolle des Auftragnehmers gedrängt. Das wäre bei einem kommerziellen Produkt in Ordnung. Bei einem Hobby-OpenSource-Projekt eher nicht.

- bei keinem Widerspruch kann dies in ein Feature bei einem nächsten Release überführt werden
- das Handbuch bekommt hinreichend Erweiterung über speziell dieses Feature
- jede zukünftige Änderung, die ein Feature direkt betrifft, kann somit im Handbuch erkannt werden und wird ev. konfigurierbar gemacht oder als Vorhanden realisiert
- Alternativ könnte man auch ein "echtes" Lastenheft und eine Realisierungspezifikation parallel laufen. Das ist meiner Meinung nach aber über Wiki so nicht realisierbar und wahrscheinlich auch recht aufwändig.

Wenn sich immer entsprechende Kapazitäten (Entwicklung, Dokumentation, Test) finden, wäre das ein guter Weg.

heiner: daß du übrigens darüber nachdenkst an grundsätzlichen Teilen im Programm zu arbeiten, zeigt mir zumindest, daß du aktiv daran arbeitest. Das ist sehr schön.

Ich investiere fast jeden Tag meine Freizeit in dieses Projekt.

hast du einen Download-Zähler deiner Release-Files ? Wie oft werden diese Dateien gedownloaded ?

Die Version 2.4.2 wurde bei Sourceforge rund 12.500 mal heruntergeladen. Bei Computerbild steht der Zähler auf 10.075 (seit 6.7.2012, nicht versionsscharf).

Auch noch zu dem Thema: altersabhängige Beiträge. Es sieht nicht gut aus, wenn du Benutzer vergraulst und anschliessend das Feature doch auf ein Art und Weise realisierst. Mit obigem Ablauf und genügend Zeit um Benutzern eine Chance zu geben, wäre meiner Meinung nach jeder zufrieden.

Bei der ursprünglich von verschiedenen Nutzern gewünschten Vollautomatik habe ich meine Meinung nicht geändert. Die zur Zeit realisierte Teilautomatik habe ich von einem anderen Benutzer übernommen.

An der Stelle auch noch der Hinweis, dass ich ursprünglich gegen eine Nutzung der externen Mitgliedsnummer für Zwecke der Bildung der SEPA-Mandatsreferenz war. Nach längerer Diskussion habe ich von einem Benutzer einen entsprechenden Patch übernommen.

D.h. wieviele Verein nutzen das Programm noch ?

Glaubst du wirklich, dass soviele abspringen? Die Resonanz, die ich bekomme ist überwiegend positiv.


Heiner

Hallo Heiner,

kannst Du mir bitte auch Wiki-Zugangsdaten schicken? Dann kann ich auch die Doku zur Emailkonfiguration anpassen.

"Grundsatz: Jeder "Wunsch" hat auch seinen Hintergrund und somit auch seine Berechtigung"
Dem würde ich zustimmen. Klar, manchmal ist der Benutzer zu schlampig, liest die Doku nicht und will 1:1 das tun, was er in seinem alten Programm getan hat. Oftmals zeigt es aber fehlende Funktionen, mangelnde Dokumentation oder eine inkonsistente/nicht-intuitive Bedienung.
Daraus entsteht noch kein "Auftrag" für Dich, aber als Anregung sollte es ernst genommen werden.

Viele Grüße,
Tobias