Designtagebuch:

.article {
line-height: 1.35;
font-family: Arial,Helvetica;
font-size: 1.15em;
}

body {
font-family:Arial,Helvetica,sans-serif;
font-size:76%;
}

Irgendwie funktioniert diese Art der Schriftdefinition bei meinen Versuchen nicht. Notfalls findet einfach eine Größe von 10pt Verwendung. Schriftarten sind noch nicht ausgewählt. Eine passende (Fallback-) Lösung für Linux muss auch bedacht werden.

» Errorcode
» Timestamp
» URL
» Query-String
» Referrer
» Evtl. Protokoll
» User Agent (um z.B. den Google-Bot identifizieren zu können)
» Username (normaler Besucher wäre anonymous)

Das Backend bekommt dann auch einen Punkt, um diese Informationen einsehen zu können. Diese werden dort als Tabellen mit eigenen Selektierungsmöglichkeiten und als Diagramme (als Balkendiagramm mit Zeitachse und vl. im Kontext zu alles Requests) dargestellt.

// Copyright 2006-2007 javascript-array.com
 
var timeout	= 500;
var closetimer	= 0;
var ddmenuitem	= 0;
 
// open hidden layer
function mopen(id) {
	// cancel close timer
	mcancelclosetime();
 
	// close old layer
	if(ddmenuitem) {
		ddmenuitem.style.visibility = 'hidden';
	}
 
	// get new layer and show it
	ddmenuitem = document.getElementById(id);
	ddmenuitem.style.visibility = 'visible';
}
 
// close showed layer
function mclose() {
	if(ddmenuitem) {
		ddmenuitem.style.visibility = 'hidden';
	}
}
 
// go close timer
function mclosetime() {
	closetimer = window.setTimeout(mclose, timeout);
}
 
// cancel close timer
function mcancelclosetime() {
	if(closetimer) {
		window.clearTimeout(closetimer);
		closetimer = null;
	}
}
 
// close layer when click-out
document.onclick = mclose;

Zur entsprechenden Website springen »

Und das ganze noch als Multi-Level Menü »

» Excel-Datei mit Versionsplanung - 2009-07-07

Überlegt werden muss hierbei noch, wo die (Content-) Aktionen und der Strukturbaum platziert werden. Die Farbgebung wird warscheinlich auch nicht diesen Rot-Ton haben, sondern eher richtung Blau tendieren. Weitere Anleihen könnten aus dem Wordpress Backend gezogen werden. Eine Andere Möglichkeit wäre, einen sauberen Head-Bereich zu schreiben (der dann auch so aufgeteilt bleiben kann, wie bisher) und den Editier-Bereich direkt auf den Weißen Grund zu packen. Dann würden lediglich die Boxen auf der rechten Seite ein entsprechendes Aussehen bekommen. Lediglich die Anzeige von Tabs würde dann wohl etwas schwieriger werden.

Momentaner Favorit als Backend-Vorlage ist dieses erste Design hier. Chancen haben aber auch die anderen Vorlagen bzw. eine Kombination aus diesen Designs.

• http://wordpress.tg81.de/wp-content/uploads/2009/06/1_homepage.jpg
• http://s3.envato.com/files/132486/04_Main%20page%20-%20Table%20-%20Blue.jpg
• http://farm4.static.flickr.com/3172/3102442630_b18709ea34.jpg?v=0
• http://farm4.static.flickr.com/3128/3102442324_2356f3bf99.jpg?v=0

• Photoshop-Dateien eines Wordpress-Admin-Themes
• Liferay Screenshots

Ajax-Funktionalitäten

Die Link, die zwischen den Kategorien umschalten werden keien Ajax-Links sein. Lediglich die Aktionen (z.B. beim Editieren) werden Ajax Funktionalitäten haben.

Sprach Pakete

Generell sind verschiedene Sprachpakete eine gute Idee. Problematisch wird dabei die Lesbarkeit des Quellcodes. Daher prüfen, ob Sprache Pakete erst für spätere Versionen implementiert werden.

Formular- / Aktionsbuttons

Buttons sollen ähnliche Optik haben wie bei Wordpress. Evtl. können auch auf der last.fm Seite Anleihen gemacht werden. Grundlegend sollen die Buttons Abgerundete Ecken haben (nicht ganz rund wie Wordpress) und einen grauen Farbverlauf als Hintergrund. Der Hover-Effekt wird den Rahmen verdunkeln. Spezielle Buttons können auch Hintergründe haben, die zusätzlich zum Verlauf noch eine Icon-Grafik eingebaut haben.

RSS-Feeds

Das Backend wird einige Informations-RSS-Feeds anbieten. Z.B. die Übersichten aus dem Dashboard oder die Aktionshistorie (wer macht wann was an welchem Dokument, …).

Dokumenttypen / Seitenlayouts

Soll das System seine Seiten Dokumenttyp-Bezogen (ala WGA) aufbauen oder Standard-Layouts bieten, die dann mit Inhalten gefüllt werden können (ala Liferay)?

Vorteil der Dokumenttypen:

• Einfachere Entwicklung, da nur die eigentlichen Dokumenttypen gebaut werden müssen
• Einfachere Umsetzung der Content-Pflege im Backend, da nicht dynamisch verschiedene Komponenten mit verschiedenen Funktionen, Edit-Möglichkeiten, Kollektionen, … berücksichtigt werden müssen.
• Keine Funktionen zur Sortierung / Anordnung der Komponenten (im Backend) nötig.
• Einfacher für Benutzer. Auswahl beschränktsich auf  “Neues Dokument > Dokumenttyp XYZ > Los”

Trotzdem die einzelnen Dokumenttypen mit Grafiken oder Vorschau-Funktionen ausstatten, sodass direkt eine Rückmeldung bzw. Information im Backend da ist. Diese Vorschau-Funktion könnte sich (bei der Auswahl des Dokumenttyps) an Liferay orientieren (Siehe Grafik).

Problem hierbei ist, dass die Dokumenttypen (weil sie ja frei programmiert werden können) kein Standard-Aussehen haben. Daher könnte man pro Dokumenttyp eine Vorschau-Grafik hochladen (mit festen Maßen) und für alle Dokumenttypen ohne Vorschau eine Standard-Platzhalter-Grafik einbinden. Die Informationen bei der Auswahl könne/sollen enthalten: Die Grafik, den Namen des Dokumenttypes, die Beschreibung (sofern vorhanden) und die Anzahl an editierbaren Feldern.

In der Administration soll ein Dokymenttyp als Standard ausgewählt werden können. Dieser wird dann in der Auswahl automatisch vorselektiert. Zu prüfen ist, ob beim Anlegen neuer Typen eine Vorschaugrafik und das passende (Start-) Modul ausgewählt werden kann oder ob auch ein Formular zum Hochladen dieser Dateien verfügbar ist. Da die Dateien im Theme abgelegt werden, sollte das Hochladen der Dateien vielleicht nur per FTP möglich sein. Da die von der Website herunterladbaren freien Standard-Themes alle einen ähnlichen Aufbau haben werden (zumindest innerhalb ihrer Themengruppe) werden dort die Dokumenttyp-Definitionen auch gleich aussehen.

Datei-Anhänge

Möglichkeit schaffen, auf de mServer bereits existierende Dateien als Dateianhang zu importieren. Große Archive o.ä. sind per Browser nicht komfortabel hochzuladen. Diese werden mittels FTP auf den Server geschoben und sollen trotzdem an Dokumente anhängbar sein.

Design und Bedienkonzept

Trotz aller bereits getroffenen und zu erwartenden Entscheidungen kann/soll das Bedienkonzept ähnlich zu dem von Liferay sein. Auch die Optik könnte der von Liferay nachempfungen werden (momentan favorisiert). Anstatt Punkten wie “Neue Anwendung” könnte hier dann “Neue Seite” oder so gewählt werden. Hierbei könnte man in den bereits oben Beschriebenen Dialog einen Schritt einfügen, in dem im Strukturbaum die Stelle für die neue Seite gewählt wird. Alternativ kann man auch permanent einen Strukturbaum einblenden und über diesen oder über eine passende Schaltfläche “Neue Unterseite” das Erstellen regeln. Beste Möglichkeit ist wohl “Neue Unterseite”.

Hauptmenü im klassischen Stil über der Website:

Über dem Hauptmenü findet sich noch das Logo und ein Suchfeld.

• Home
• News
• Leistungen oder Unser Profil o.ä.
• Referenzen
• Partner
• Dokumentation
• Support
• Kontakt

Navigation innerhalb des Produkt-Teasers bzw. Eyecatcher:

Der Produkt-Teaser bzw. Eyecatcher liegt mittig und gut sichtbar in der Seite und enthält ein Verkaufsbild (z.B. ein Produkt-Karton des CMS, wie er im Laden zu finden sein könnte), etwas einleitenden Text und einige direkte Links.

• Features
• Screenshots
• Demo
• Downloads

Der Punkt Download führt zu einer Seite, auf der entweder das CMS heruntergeladen werden kann oder alle Informationen zur Nutzung des CMS zu finden sind (Bezahlung, etc). Dazu kommt ein Bereich mit freien Downloads wie z.B. fertige Websites (Designs und DB-Dump mit Basis-Infos). Diese Websites können einerseits selber Design sein, in Zusammenarbeit mit Andre entstehen oder (wenn erlaubt) von OSWD.org bezogen sein. Die (mögliche) Download-Sektion des CMS an sich wird eine Unterteilung in die einzelnen Versionen bieten und von dort aus auch Links auf das jeweilige Change-Log etc. Auch die Website-Designs werden ein Flag auf die benötigte bzw. die möglichen CMS-Versionen enthalten.

Weitere Inhalte:

Zwischen dem Eyecatcher und dem Fußzeilenmenü kommt dann der eigentliche Inhalt, welcher in mehrspaltigem Design dann Sachen wie Infotexte, Ankündigungen, News-Links und ausgewählte oder zufällige Referenzen zeigt. Zudem soll ein Kontakt-Bereich prominent platziert sein, über den Informationen eingeholt und Auftragsanfragen gestellt werden können.

Fußzeilenmenü unterhalb der Seite:

• Sitemap
• Impressum
• Kontakt

Generelles Design und Aufteilung der Seite:

Das Design der Seite könnte sich an www.flickr.com orientieren. Eine “Busines-Grafik” oben rechts, daneben ein Logo oder ein Produkt-Karton. Dies soll nicht ganz so hoch wie bei Flickr sein. In der zweiten Reihe dann ein Info-Text zum System mit Link-Buttons “Features”, “Demo”, “Get It”, “Dokumentation” und rechts daneben 3 - 6 Thumbnail-Links mit Screenshots vom System. Unterhalb dann ein Bereich, in dem News gezeigt werden. Möglicherweise eine als Reaser und daneben ein paar Link-Headlines. Ganz am Schluss vor dem Footer kann man noch eine Reihe mit Referenz-Thumbnail-Screenshots anzeigen. Das Problem hierbei könnte die Platzierung der Navigation und Suche sein. Die Suche könnte im Headerbereich unter dem Logo zu finden sein. Die Effektive Breite der Seite soll 1000px betragen und zentriert angezeigt sein. Für die Unterseiten mit mehr Text müsste das Layout vl. ein wenig angepasst werden, sodass weniger Platz durch grafiken verbraucht wird.

Alle wichtigen Bereiche der Seite sollen über eigene URL-Pfade erreichbar sein. Z.B. www.domain.tld/support. Die Online-Demo wird in einer eigenen Subdomain verfügbar sein: demo.domain.tld.

Der Bereich Support wird ebenfalls einen eigenen Bereich bekommen. Ob dies eine Subdomain oder ein Unterverzeichnis wird, hängt von der eingesetzten Technik ab. Da es warscheinlich in der Seite integriert wird und dadurch auch im CMS-Backend editierbar sein wird, fällt die Wahl wohl auf ein Verzeichnis. Die Editier-Funktionen werden sich aber Enthalten sein sollen hier erste Infos zu Problemlösungen, ein Ticketsystem und später vielleicht ein Forum (Sinnfrage muss noch geklärt werden). Das Ticketsystem wird durch ein Browser-Interface die einzige Schnittstelle für Fehlerkommunikation. Alle Problem-Reports von Kunden sollen hier per Browser eingehen. Nach Update durch Bearbeiter kann dann eine Status-Mail versendet werden. Datei-Uploads sollen hier ebenfalls möglich sein. Kunden bekommen einen oder mehrere Logins zusammen mit dem CMS, sobald dies gekauft wird. Eine Ticketsuche soll für Kunden die möglichkeit bieten, alle eigenen Tickets und für Sachbearbeiter alle insgesamt vorhandenen Tickets zu durchsuchen.

Login-Bereich:

Einige Inhalte evtl. nur für Kunden sichtbar machen. Diese könnten umfassen: Support, Download (von Themes und Updates), Persönliches Website-Menü (vl. Quicklinks genannt), An- & Abmelden von Newsletters, Feedback-Möglichkeit für Wünsche und Anregungen.

Online Dokumentation:

Die Einstiegsseite der Online-Dokumentation soll untereinander Links mit kurzem Infotext für die Bereiche “Installation”, “Getting Startet” oder “First Steps”, “Das Backend” und “Entwicklung” enthalten. Unterhabt von “Das Backend” finden sich dann separat Informationen zum Content-Editing und zur Administration und unterhalt von “Entwicklung” z.b. finden sich dann Tutorials, kleine Beispiele zu speziellen Anwendungsfällen und eine API-Referenz. Die API-Referenz enthält keine system-eigenen Komponenten, die nur im Admin-Interface o.ä. genutzt werden sondern alles, was für den “normalen” Entwickler gedacht ist. Das Design der Details-Seiten soll für die API-Referenz eine Liste o.ä. der einzelnen Packete und Komponenten enthalten. Die anderen Seiten mit vornemlich Volltext-Inhalten sollen ähnlich wie bei einem Blog oder einem Wiki entweder eine Table-of-Contents am Anfang haben und/oder Seitenweise weiterschaltbar sein. Da die Online-Dukomentation die einzige Doku sein wird, sollen sämtliche Themen on-the-fly zu PDFs generiert werden können (bei weiterschaltbaren Seiten werden alle mit einer Table-of-Contents in einem PDF zusammengefasst). Die Admin- und die Entwicklerdokumentation könnten auch ein Cheat-Sheet enthalten, welches ebenfalls on-the-fly in ein PDF umgewandelt werden kann.

Zusätzlich zu den “Standard-Inhalten” könnte sich ein Blog / eine Infoserie ala Focus-on-WGA in der Dokumentation befinden. Man könnte auf der Startseite den neuesten Eintrag anteasern und weitere verlinken. Damit würde dann die Linke Spalte versehen, die rechte Spalte würde Links zu den einzelnen Dokumentationsinhalten beinhalten.

Das Design der Seite könnte sich an diese Beispiele anlehnen:

1. Typo-Light Website
2. http://www.solucija.com/preview/Internet_Broadcast
3. http://www.eblogtemplates.com/wp-content/uploads/2008/03/revolution-business-med.jpg

Die folgenden beiden Screenshots sind momentan Favoriten. Vorstellbar wäre ein Headbereich mit Logo, Suchfeld und Navigation, dann der Eyecatcher/Promo-Bereich mit Produktbox o.ä. als Bild und dann 3-spaltig der Content. Spalte 1 könnte Unternehmensnews enthalten (2 Stück und dann ein Link auf das News-Archiv oder so), Spalte 2 enthält eine Linkliste auf die letzten Entwickler- / Release-News und Spalte 3 enthält ein paar Thumbnails mit Screenshots des CMS. Alternativ können diese Thumbnails auch Referenzen sein und die Scrennshot-Thumbnails mit im Head-Bereich sein und dort per Javascript “weitergeblättert” werden. Diese Variante wird im Moment favorisiert. Die Entwiclker- / Release-News könnten dann auch auf das geplante Blog / die geplante Infoseite (ala Focus-on-WGA) verlinkten (Hierzu wäre eine Kollektion nötig, nicht bloß ein Navigator). Die zweite der unteren beiden Screenshots hat leicht die Nase vorn.