<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Kommentare zu: Web 2.0, Communities, Benutzerdaten, SektionEins und die Sicherheit</title>
	<atom:link href="http://hasematzel.de/2007/05/web-20-communities-benutzerdaten-sektioneins-und-die-sicherheit/feed/" rel="self" type="application/rss+xml" />
	<link>http://hasematzel.de/2007/05/web-20-communities-benutzerdaten-sektioneins-und-die-sicherheit/</link>
	<description>Oliver Schwarz über Web-Entwicklung, Accessibility, Usability und das Internet</description>
	<lastBuildDate>Mon, 05 Sep 2011 11:52:29 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1</generator>
	<item>
		<title>Von: Hasematzel</title>
		<link>http://hasematzel.de/2007/05/web-20-communities-benutzerdaten-sektioneins-und-die-sicherheit/#comment-986</link>
		<dc:creator>Hasematzel</dc:creator>
		<pubDate>Thu, 24 May 2007 09:04:23 +0000</pubDate>
		<guid isPermaLink="false">http://hasematzel.de/blog/2007/05/23/web-20-communities-benutzerdaten-sektioneins-und-die-sicherheit/#comment-986</guid>
		<description>@Siegfried:Ja, ich bin Deiner Meinung. Ich hätte eine parallele Terminologie zu &quot;release early, release often&quot; wählen sollen. Denn so, wie es manche Portale meiner Kritik im Beitrag nach umsetzen (aus welchen Entscheidungen auch immer), heisst der genutze Prozess eher: &quot;release early, patch often&quot;. Der unterschiedliche Ansatz wird da deutlicher. Gegen einen generellen frühen Release ist nichts einzuwenden, solange man die Umstände des Releases im Detail beschreibt.Dabei darf man sich nicht auf das &quot;Beta&quot;-Icon verlassen. Hier wird eine Erwartungshaltung beim Benutzer erzeugt, dem das &quot;Beta&quot; gar nicht auffällt, sondern der eine vollfunktionale und sichere Umgebung erwartet, insbesondere dann, wenn er sensible Daten in die Hände des Anbieters gibt (Kreditkarteninformationen, Bankverbindung, sogar E-Mailadressen).Manche Portalentwickler und Geschäftsidee-Propheten sollten da vielleicht noch einmal mit einem closed-beta-Prinzip beginnen, wofür auch die entsprechende Infrastruktur vorgehalten werden muss (Forum, Chat, Ticket-System) und dessen Feedback sich auch transparent in Patches und Releases im Versionierungssystem verfolgen lassen muss.Der Buzz, den man erzeugt(en will), kann mit einer &quot;closed beta&quot; dabei durchaus ausreichend erzeugt werden, denn das ist m. E. eines der wichtigsten, aber auch fragwürdigsten Absichten eines frühen Releases als Beta: Blogeinträge und Google Juice, möglichst positiv.Gut, wenn&#039;s klappt ;)</description>
		<content:encoded><![CDATA[<p>@Siegfried:Ja, ich bin Deiner Meinung. Ich hätte eine parallele Terminologie zu &#8220;release early, release often&#8221; wählen sollen. Denn so, wie es manche Portale meiner Kritik im Beitrag nach umsetzen (aus welchen Entscheidungen auch immer), heisst der genutze Prozess eher: &#8220;release early, patch often&#8221;. Der unterschiedliche Ansatz wird da deutlicher. Gegen einen generellen frühen Release ist nichts einzuwenden, solange man die Umstände des Releases im Detail beschreibt.Dabei darf man sich nicht auf das &#8220;Beta&#8221;-Icon verlassen. Hier wird eine Erwartungshaltung beim Benutzer erzeugt, dem das &#8220;Beta&#8221; gar nicht auffällt, sondern der eine vollfunktionale und sichere Umgebung erwartet, insbesondere dann, wenn er sensible Daten in die Hände des Anbieters gibt (Kreditkarteninformationen, Bankverbindung, sogar E-Mailadressen).Manche Portalentwickler und Geschäftsidee-Propheten sollten da vielleicht noch einmal mit einem closed-beta-Prinzip beginnen, wofür auch die entsprechende Infrastruktur vorgehalten werden muss (Forum, Chat, Ticket-System) und dessen Feedback sich auch transparent in Patches und Releases im Versionierungssystem verfolgen lassen muss.Der Buzz, den man erzeugt(en will), kann mit einer &#8220;closed beta&#8221; dabei durchaus ausreichend erzeugt werden, denn das ist m. E. eines der wichtigsten, aber auch fragwürdigsten Absichten eines frühen Releases als Beta: Blogeinträge und Google Juice, möglichst positiv.Gut, wenn&#8217;s klappt ;)</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Siegfried</title>
		<link>http://hasematzel.de/2007/05/web-20-communities-benutzerdaten-sektioneins-und-die-sicherheit/#comment-985</link>
		<dc:creator>Siegfried</dc:creator>
		<pubDate>Thu, 24 May 2007 07:49:18 +0000</pubDate>
		<guid isPermaLink="false">http://hasematzel.de/blog/2007/05/23/web-20-communities-benutzerdaten-sektioneins-und-die-sicherheit/#comment-985</guid>
		<description>Das Problem dabei ist nicht die &quot;release early, release often&quot; Methode, sondern der Missgriff, daß man diese Methode mit der in anderen Methoden üblichen Geheimhaltung verbindet. Diese Methode basiert auf der Idee, daß Feedback die Qualität steigert. Voraussetzung dafür ist natürlich volkommene Offenheit. Ansonsten wird das absurd. Mit Offenheit hingegen wird so eine Entwicklung dann, analog zum &quot;user generated content&quot;, ein &quot;user supported development&quot;. Eine durchaus wünschenswerte Sache. Wer natürlich diese Methode mit hektischen Releases aus marketingtechnischen Gründen verwechselt, sollte sich nicht wundern, wenn er gründlich auf die Nase fällt.</description>
		<content:encoded><![CDATA[<p>Das Problem dabei ist nicht die &#8220;release early, release often&#8221; Methode, sondern der Missgriff, daß man diese Methode mit der in anderen Methoden üblichen Geheimhaltung verbindet. Diese Methode basiert auf der Idee, daß Feedback die Qualität steigert. Voraussetzung dafür ist natürlich volkommene Offenheit. Ansonsten wird das absurd. Mit Offenheit hingegen wird so eine Entwicklung dann, analog zum &#8220;user generated content&#8221;, ein &#8220;user supported development&#8221;. Eine durchaus wünschenswerte Sache. Wer natürlich diese Methode mit hektischen Releases aus marketingtechnischen Gründen verwechselt, sollte sich nicht wundern, wenn er gründlich auf die Nase fällt.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Markus</title>
		<link>http://hasematzel.de/2007/05/web-20-communities-benutzerdaten-sektioneins-und-die-sicherheit/#comment-984</link>
		<dc:creator>Markus</dc:creator>
		<pubDate>Wed, 23 May 2007 18:16:06 +0000</pubDate>
		<guid isPermaLink="false">http://hasematzel.de/blog/2007/05/23/web-20-communities-benutzerdaten-sektioneins-und-die-sicherheit/#comment-984</guid>
		<description>Ein wichtiger Hinweis, der Pflichtlektüre aller Web 2.0-Planer sein sollte. Danke dafür.</description>
		<content:encoded><![CDATA[<p>Ein wichtiger Hinweis, der Pflichtlektüre aller Web 2.0-Planer sein sollte. Danke dafür.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

