Re: [Ag Meinungsfindungstool] [STATUSINFO] 17.09.2012 AG MFT Mumbletreffen

[Alexander Praetorius <alexander.praetorius AT serapath.de>]

2012/9/18 marc <marc AT merkstduwas.de>

Ahoi,

die gestrige Mumble Sitzung stand im Zeichen der Re-Kapitulation.
Das Protokoll findet ihr unter
http://meinungsfindungstool.piratenpad.de/2012-09-17-Notizen

WAS IST PASSIERT?

Wo steht die AG MFT aktuell und was sind unsere bisherigen Ergebnisse?

Diese Fragen wurden bereits in den letzten Tagen immer dringlicher, denn
'Slash' hat angefangen thematisch verwandte AGen und auch einzelne Personen
anzuschreiben, um auf unsere AG aufmerksam zu machen. Dabei entstand der
Eindruck, dass es leicht zu Missverständnisse über die Zielstellung der AG
MFT kommen kann.

Entsprechend haben wir gleich versucht 'Thomas von der Elbe', der zum ersten
mal beim MFT Mumble dabei war, einen Schnelleinstieg zu verpassen. Wir
hätten das aufzeichnen sollen! Thomas kommt aus der Votorola Ecke
(http://wiki.piratenpartei.de/Liquid_Democracy/Votorola) und hat uns das
dahinterliegende Prinzip erläutert.

Oh cool, Thomas war da??? :-) Verdammt, warum konnte ich gestern nicht.
@Thomas
Falls du den Verteiler mitliest, schöne Grüße :-)

 

[...]

Sobald 'die Grundidee' abgestimmt ist, wird das Business-Entity-Model
(Geschäftsobjektmodell) in einer Version 1.0 abgestimmt (Schritt 3.1.1).

Die Abstimmung sollte erst nach der BEGRÜNDUNG der "Geschäftsobjekte" stattfinden. 

 

Nachfolgend wird zu jedem Geschäftsobjekt eine Begründung formuliert,
weshalb diese Entität im Modell enthalten ist (Schritt 3.1.2). Damit ist die
strukturelle Beschreibung in einer ersten Version abgeschlossen.

Nach der Begründung sollte die Abstimmung stehen, nicht davor.

 

Um auch die funktionalen Aspekte erfassen zu können, werden wir im
darauffolgenden Schritt 3.2 ein grobes Use-Case-Model (Anwendungsfallmodell)
erstellen, welches in späteren Iteration verfeinert wird.

Sowohl Business-Entity- als auch Use-Case-Model werden anhand des qKonsens
modelliert. Ziel der Modelle ist es gemeinsame (Framework) und getrennte
(Plug-In) Entitäten und Funktionalitäten zu identifizieren. Wir müssen
überlegen in wieweit es sinnvoll wäre weitere Diskussionsmethoden (BasDeM,
DisQussion, Votorola) als Plug-Ins zu modellieren,

Bevor man anfängt Plug-Ins zu modellieren, wäre es vielleicht super die Entwickler von BasDeM, DisQussion und Votorola mal einzuladen, gegebenenfalls weitere, damit diese ihr Konzept vorstellen. Ich glaube sowas kann allgemein sehr inspirierend sein und sollte aufgezeichnet werden.
Quasi eine "Mumblesitzung" oder mehrere, in denen die Konzepte vorgestellt um dann im Wiki für interessierte verlinkt zu werden.
Ich glaube nämlich spontan nicht, das Votorola so direkt mit BasDeM oder DisQussion vergleichbar ist.

 

um eine bessere
Vorstellung von den Gemeinsamkeiten zu erhalten. Dies sollten wir nach
unseren weiteren Erfahrungen richten.

Im Schritt 3.2.1 werden weitere Verfeinerungen z.B. durch Aktivitäten- oder
Sequenzdiagramme und Abgrenzungen durch Komponenten- und Systemdiagramme
modelliert.

Bis hierher sollte alles noch weitgehend technologieneutral gehalten sein
und die rein sachliche/inhaltliche Sicht auf das Diskussionssystem bilden.
Die Grundidee und die UML Modelle bilden dann die Basis um für konkrete
Implementierungen den Kontext der Anforderungen zu definieren und die User
Stories formulieren zu können. Im optimalen Fall schaffen wir es zu den
einzelnen User Stories auch Test Cases oder Akzeptanzkriterien zu
definieren. All dies zusammen bildet dann das Pflichtenheft /
Anforderungskatalog / Spezifikation - however you name it.

Was mir daran nicht gefällt ist der typische Ansatz über User Storys bzw. Use Cases, usw... und die dazugehörigen Modellierungen in den entsprechenden UML Dialekten. Ich denke was wir brauchen ist ein "Interface Driven Developement".
Um im "User Interface" keine Elemente zu vergessen mag die Modellierung in UML hilfreich sein, aber man sollte niemals vergessen, dass für den "User" das System nicht mehr und nicht weniger ist als das "User Interface" mit dem er interagiert.
Alles andere ist nicht existent für den User.
Es gilt diese Schnittstelle so zu optimieren, dass all die Theorie darin abgebildet wird. Was nicht darin abgebildet wird ist irrelevant für den User und kann nach belieben implementiert werden... diese Überlegungen sind nicht so relevant für uns als AG MFT.

Ich würde deshalb vorschlagen mit "Mockups" zu beginnen, egal ob als, als Powerpointpräsentation, als HTML5-Seite, als Vektorgrafik, als Pixelgrafik, als Flashanimation, ... usw...  meinetwegen auch auf Papier gemalt um dann zu filmen oder fotografieren um eine animierte Sequenz daraus zu machen.

Wir sollten einen solchen "User Interface Driven" Prototyp entwickeln, der alle wesentlichen Elemente abbildet und Plugins erlaubt.
Dann kann es natürlich eine entsprechende abgewandelte Version für jedes Plugin geben.


Wenn wir das NICHT machen, dann kommt am Ende eine verwirrende oder umständlich benutzbare Benutzeroberfläche heraus, die vielleicht alle Funktionen abbildet, aber die von Usern nicht akzeptiert wird. Das Problem sehe ich immer und immer wieder, egal ob bei Liquid Feedback, bei Adhocracy oder auch bei Votorola und es nervt extrem. Das Votorola-Team gibt sich zwar Mühe und es gibt Fortschritte, aber es fehlt der profesioneller Mediengestalter.

Einen solchen kann man unter Umständen ersetzen, wenn sehr viele Augen Verbesserungsvorschläge für das User Interface liefern und wir uns regelmäßig AG-Fremde einladen die eine Meinung abgeben sollen.

 

Ich habe versucht nach bestem Wissen und Gewissen die gestrige Mumble
Sitzung wiederzugeben. Sollte ich etwas entscheidendes vergessen oder falsch
wiedergegeben haben, bitte ich dies zu entschuldigen und ggf. umgehend zu
melden/korrigieren.

Fragen, Anregungen, Hinweise und Kritik sind jederzeit auf der ML gerne
gesehen ;o)


Cheers
marc

Vielen Dank :-)