Ich arbeite seit der Version FrontPage 97 intensiv mit Microsoft
FrontPage; ich habe damit diverse Projekte realisiert und bin mit diesem
Tool weitestgehend zufrieden, es arbeitet stabil und zuverlässig,
ausserdem beherrsche ich es und kenne die Limitierungen sehr gut.
Ich mache keinen Hehl daraus, dass ich ein klassischer Windows- Admin
bin; ich habe die gesamte Entwicklung von Windows 3.0 bis Windows .NET
Server 2003 vollständig und aktiv miterlebt und jahrelang mit Microsoft-
Produkten erfolgreich gearbeitet (die Gründe für mein Interesse an
GNU/Linux spielen an dieser Stelle keine Rolle). Ab Windows NT hat sich
dieses Betriebssystem für mich als stabile Desktop- und Serverplattform
erwiesen, die ich auch im beruflichen Umfeld erfolgreich nutzen konnte;
GNU/Linux dagegen war für mich nur in Ausnahmefällen für den produktiven
Einsatz nutzbar.
Daher war es für mich naheliegend und schon fast zwingend, die Web-
Präsenz Kefk Network unter einem extern gehosteten Windows- Server und
die Entwicklung mit Windows- Tools zu realisieren.
FrontPage bietet konzeptionelle eine Art Integrated Development
Environment (IDE) für die Web- Entwicklung; alle benötigten Tools,
vom Erstellen und Bearbeiten von Text über das Definieren und Verwalten
der Site- Struktur bis hin zu Grafikbearbeitung und Link- Management
sind unter einer Oberfläche zusammengefasst. Dieses typische Windows-
Konzept widerspricht dem in der UNIX- Welt Üblichen: Hier werden
Aufgaben fast immer durch eine Verkettung von kleinen Tools (Toolchain)
erledigt; Ausnahmen wie GNU
Emacs, Anjuta,
KDE Studio etc.
bestätigen auch hier natürlich die Regel.
FrontPage verwaltet Dateien und Verzeichnisstrukturen quasi
projektorientiert in sogenannten Webs, beispielsweise ist das
Kefk Network ein solches; diese Web können Unterwebs enthalten, die
sogannenten Nested Subwebs; sein solches Web bildet Kefk Network
GNU/Linux. Der Arbeitskontext in FrontPage bezieht sich immer das das
jeweils geöffnete Web bzw. Subweb.

Screenshot: Öffnen eines FrontPage Webs.
Ein Web kann im lokalen Dateisystem liegen oder auf einem entfernten
Webserver mit installierten FrontPage Server Extensions (FPSE);
für FrontPage ist es vollkommen egal, aus welcher Quelle die Webs
stammen.

Screenshot: Microsoft FrontPage mit einem geöffneten Web.
Standardmässig arbeitet man in FrontPage in der sogenannten "Normal"-
Ansicht, einem Pseudo- WYSIWYG- Editor, der schnell und funktional ist,
aber natürlich keinesfalls an die Funktionsvielfalt von
GNU Emacs oder
Microsoft Word heranreicht. Interessanterweise beschreitet Microsoft
hier einen ausserordentlich intelligenten Weg und versucht gar nicht
erst, ein pixelgenaues Layout zu forcieren, wie dies die
Konkurrenzprodukte Adobe GoLive! und vor allem Macromedia
Dreamweaver mit sehr zweifelhaften Ergebnissen tun. Stattdessen
arbeitet man strukturiert, wie dies auch mit etwas Selbstdisziplin in
Microsoft Word möglich ist: Die »Absatzformate« werden in einem
externen Stylesheet definiert und in die HTML- Dateien eingebunden; im
FrontPage- Editor stehen sie dann jederzeit über ein Pulldown- Menü
sowie alternativ über Tastatur- Shortcuts und Dialogboxen zur Verfügung.
Die "Normal"- Ansicht stellt die HTML- Seite in etwa so dar, wie sie
im Web aussehen könnte; durch Vergrössern oder Verkleinern des Editor-
Fensters kann man auch mit dem Aussehen von Seiten bei anderen
Bildschirmauflösungen herumspielen. Man gewöhnt sich so recht rasch
daran, die Seiten nicht für bestimmte Pixelmaße zu designen, sondern sie
eben so flexibel wie möglich zu halten.

Screenshot: Der WYSIWYG- Editor ("Normal"- Ansicht) von
Microsoft FrontPage mit einer geöffneten HTML- bzw. ASP-Seite.
Wer etwas mehr vom Code sehen will, kann die Darstellung von Tags
aktivieren, wie dies aus den SoftQuad- Produkten HoTMetaL
und XMetaL hinlänglich bekannt ist. Natürlich sind diese
visualisierten Tags anklickbar und kontextsensitiv; ein Doppelklick auf
das <p>- Tag ruft beispielsweise einen Dialog für
Absatzformatierungen auf. Ich mag diese Ansicht nicht besonders, da ich
sie unübersichtlich finde -- und ausserdem versuche ich, die Dokumente
so strukturiert wie möglich zu bauen; FrontPage unterstützt dies,
ermöglicht aber auch jederzeit das Einfügen von unerwünschten Tags wie
<FONT>. Wie dem auch sei, die Möglichkeit für beide
Arbeitsweisen ist vorhanden, es liegt beim Benutzer, sich für eine davon
zu entscheiden.

Screenshot: Die "Normal"- Ansicht von Microsoft FrontPage mit
einer geöffneten HTML- bzw. ASP-Seite und aktivierter Anzeige von Tags.
Wichtiger als die Anzeige von Tags ist für mich der Code-Editor
("HTML-Ansicht"); jederzeit kann man mit <Strg> + <Bild hoch>
bzw. <Strg> + <Bild runter> zwischen den Darstellungmodi
wechseln; mit FrontPage kann man weitestgehend ohne Maus arbeiten, was
die Arbeit natürlich enorm beschleunigt. Natürlich unterstützt die Code-
Ansicht auch Syntax- Highlighting und die meisten grundlegenden
Editierfunktionen.

Screenshot: Die "HTML"- Ansicht (Code- Editor) von Microsoft
FrontPage mit einer geöffneten HTML- bzw. ASP-Seite und Syntax-
Highlighting.
Last but not least verfügt FrontPage selbstverständlich auch
über eine Preview- Funktion; dafür wird -- wie sollte es anders sein --
natürlich der Internet Explorer genutzt. I.d.R. braucht man diese
Preview- Funktion nicht, da die Pseudo- WYSIWYG- Ansicht eigentlich
immer das zeigt, was man eben sehen muss; dynamische Inhalte aus
Skripten oder Datenbankquellen sieht man aber erst, wenn der Content
live von einem entsprechend konfigurierten Webserver abgerufen wird.

Screenshot: Die "Vorschau"- Ansicht von Microsoft FrontPage
mit einer geöffneten HTML- bzw. ASP-Seite nutzt den Internet Explorer.