In diesem Beitrag möchten wir einige Vorteile der JavaFX-Bibliothek erläutern, die besonders im Bezug auf das Userin­terface eine Rolle spielt.
Als einer der wichtigen Vorteile der JavaFX Bibliothek gilt die Möglichkeit der Nutzung von Styles (CSS), die uns aus dem WWW bekannt sind.
Dadurch verliert sich die Abhän­gigkeit zu der Bibliothek Look & Feel. Man kann jedoch selbst das Aussehen der Appli­kation bestimmen, was auch ziemlich flexibel und schön möglich ist. Die Gestaltung kann dynamisch erfolgen, eine Animation beinhalten oder auch 3D Grafik.
Durch die Benutzung der Style-Konzeption ist es nun möglich, die Appli­ka­tionen mit so genannten „Skins“ zu erstellen, durch die das Aussehen der Appli­kation komplett von der Business­logik losgelöst wird und mehr Indivi­du­altät erhält. Solche indivi­du­ellen Skins können sogar separat von einem Designer erstellt werden.

Erstellen wir ein einfaches Beispiel eines Dialog­fensters mit einem Button:

public class JavaFXDialog1 extends Application {
    @Override
    public void start(Stage stage) {
        final VBox vbox = new VBox();
        final Button button = new Button("test");
        vbox.getChildren().addAll(button);
        final Scene scene = new Scene(vbox, 150, 100);
        stage.setScene(scene);
        stage.show();
    }
  
    public static void main(String[] args) {
        launch(args);
    }

avafx and css styles 1

Styles kann man unter­schiedlich anwenden:
1) Unmit­telbar im Code, um z.B. die Schrift­farbe in dem Button zu ändern:

button.setStyle("-fx-text-fill: red");

avafx and css styles 2

2) Mit Hilfe einer CSS-Datei, auf die die Klasse Scene ausge­richtet werden soll:
Dafür wird eine Datei mit der Erwei­terung .css erstellt und unter dem Projekt­ver­zeichnis abgelegt, z.B. /css/styles.css.
Inhalt der Datei:

.button {
    -fx-text-fill: blue;
}

Dabei ist es sehr wichtig, die Entwick­lungs­um­gebung so einzu­richten, dass sie diese CSS-Dateien beim Bilden der Appli­kation auch mitkopiert.
Unter IntelliJ IDEA wird es beispiels­weise folgen­der­maßen gemacht:

avafx and css styles 3

Nun ist alles fertig, um die Style-Datei einzubinden:

scene.getStylesheets().add((getClass().getResource("/css/styles.css")).toExternalForm());

Wir starten das Projekt und bekommen folgendes Dialogfenster:
avafx and css styles 4

Instruktion .button in der CSS-Datei sagt aus, dass nun alle Knöpfe eine blaue Schrift­farbe haben werden:

final Button button1 = new Button("button1");
final Button button2 = new Button("button2");
vbox.getChildren().addAll(button1, button2);

avafx and css styles 5

Und was, wenn das nicht das ist, was wir brauchen? Was, wenn wir einen konkreten Knopf definieren wollen?
3) Abhilfe schafft die userbe­zogene Definition des Knopf-Styles:
In styles.css schreiben wir:

.button1 {
    -fx-text-fill: green;
}

Und im Code:

button1.getStyleClass().add("button1");

Das Dialog­fenster sieht so aus:
avafx and css styles 6

Nun haben alle Knöpfe, die mit der Style-Klasse verbunden sind, grüne Schrift­farbe, wobei die Methode add() uns dabei Hinweise gibt, dass wir mehrere von solchen Styles hinzu­fügen können, wodurch verschiedene Element­ei­gen­schaften erweitert, vorde­fi­niert oder überladen werden.
4) User-Style kann man auch durch den so genannten ID definieren:

In der styles.css schreiben wir:

#button2 {
    -fx-text-fill: yellow;
}

Und im Code:

button2.setId("button2");

Als Ergebnis bekommen wir folgendes Dialogfenster:

avafx and css styles 7

D.h. alle Elemente mit der gleichen ID sehen gleich aus.

Was kann man sonst noch Inter­es­santes mit den Styles machen?

Styles können auch die so genannten Verhal­ten­st­rigger bearbeiten, die aus der XAML Welt kommen.
Wenn wir bei dem Beispiel mit dem Knopf bleiben, gehören zu diesen Triggern solche Ereig­nisse der GUI wie Fokus, Selektion, Mousedown, Mouseover usw. also alles, was man nicht im Dialog­fenster haben möchte. Es beinhaltet nur den Buisiness­login bei den kunden­sei­tigen Änderungs­wün­schen und es wird nur die CSS-Datei geändert und nicht die Logik.
So kann man z.B. mit der folgenden CSS-Definition die Farbe des Knopfes ändern, wenn der User mit der Maus darüber fährt.

.button:hover {
    -fx-background-color: orange;
}

So sieht das Dialog­fenster bei Mouseover aus:

avafx and css styles 8

Wie bereits oben erwähnt, führt das zum gleichen Verhalten von allen Button-Klassen. Mit diesem Code:

.button1:hover {
    -fx-background-color: orange;
}

werden die Trigger nur für die Elemente angewendet, die auf die Klasse «button1» verweisen.

Diese Vorge­hens­weise kann man bei vielen Trigger anwenden, bei Knöpfen gibt es z.B. auch noch foused, selected oder presset.

Leider kann das nicht direkt im Code genutzt werden:

button.setStyle(":hover -fx-text-fill: red");

Vielleicht wird diese Möglichkeit in der Zukunft durch JavaFX Developer realisiert.

Wozu brauchen wir das alles? Im Internet kann man noch eine Reihe an Beispielen finden, die deutlicher sind als dieses. Das Ziel des Beitrags war nicht, diese zu kopieren. Uns geht es darum, dass die Konzeption von Syles und Trigger  auch für den eigenen Bedarf erweitert werden kann, das ist für uns von Interesse.

Als Beispiel können wir folgende Ausgangs­si­tuation betrachten:
wir wollen mit JavaFX eine visuelle Kompo­nente umsetzen, die für die Auswahl der Größe einer im Text einge­fügten Tabelle dienen soll. Das Aussehen der Kompo­nente, das Farbschema, die Größe usw., sollen dabei kein Bestandteil der Business­logik der Kompo­nente sein, sondern über eine externe CSS-Datei konfi­gu­rierbar sein.

Das sollte ungefähr so aussehen:

avafx and css styles 9

Der User geht mit dem Mauszeiger über die Tabelle und sieht seine ausge­wählten Elemente, in dem Fall eine Tabelle mit 7 x 8 Zellen. Beim Klick auf die Kompo­nente sollte die Auswahl an das Programm übermittelt werden, um eine entspre­chende Tabelle einzufügen.
Sicherlich kann man auf die Auswahl über den Code reagieren, aber was wenn der eine Kunde eine bestimmte Farbe bevorzugt, der andere aber ganz andere Farben bevorzugt? Möglich ist auch, dass das Farbschema durch ein «Skin» oder sonst wie vorde­fi­niert wird – was dann?

Hier wird nur eine Kompo­nente für die Zellen­se­lektion benötigt, um deren Aussehen es an dieser Stelle aber nicht gehen soll.

Hier können wir auf das voran­ge­gangene Beispiel mit dem Trigger «hover» für den Button anknüpfen. Der wirkt aller­dings für jede Zelle, wenn man mit dem Mauszeiger über sie fährt. Die Zellen, die der Mauszeiger verlassen hat, entsprechen dem Trigger nicht mehr und fallen somit aus der Auswahl. Wie können wir den gesamten Bereich ausge­wählt behalten?

Für die Lösung dieser Aufgabe wird ein eigener Trigger erstellt, der auf eine bestimmte Eigen­schaft des Objektes reagiert, z.B. «bin im Diapason der Selektion» oder inRange, die wir folgen­der­maßen in der CSS-Datei definieren können:

.MyCell:inRange {
    -fx-border-width: 0.5;
    -fx-border-color: #ffffff;
    -fx-background-color: lightskyblue
}

An der Stelle muss man aber sagen, dass dies ist keine einfache Aufgabe ist. Zudem ist die Lösung für die JavaFX Versionen 1.7 und 1.8 gänzlich unter­schiedlich. Für die Lösung in der Version 1.7. sind wir auf die Nutzung einer Menge der depre­cated-Methoden angewiesen.

Für den Anfang schauen wir uns die Kompo­nente an:

public class JavaFXDialog2  extends Application {
    @Override
    public void start(Stage stage) {
        final VBox vbox = new VBox();
        final GridPaneEx table = new GridPaneEx();
        table.init(10, 10);
        final Label label = new Label();
        label.setMaxWidth(Double.MAX_VALUE);
        label.setAlignment(Pos.CENTER);
        label.setTextAlignment(TextAlignment.CENTER);
        label.setStyle("-fx-padding: 3 0 5 0");
        label.textProperty().bind(table.text);
        vbox.getChildren().addAll(label, table);
        final Scene scene = new Scene(vbox, 350, 300);
        scene.getStylesheets().add((getClass().getResource("/css/styles.css")).toExternalForm());
        scene.setFill(null);
        stage.setScene(scene);
        stage.show();
    }
 
 
    public static void main(String[] args) {
        launch(args);
    }
 
 
    private void fireCreateTable(final int cols, final int rows){
        System.out.println("cols = " + cols + ", rows = " + rows);
    }
 
 
    protected class GridPaneEx extends GridPane {
  
        public final StringProperty text = new SimpleStringProperty("cancel");
        private int cols;
        private int rows;
  
        public GridPaneEx(){
            this.setOnMouseExited(new EventHandler() {
                @Override
                public void handle(MouseEvent mouseEvent) {
                    text.setValue("cancel");
                    deselectAll();
                }
            });
        }
  
        public void init(final int cols, final int rows){
            getChildren().clear();
            this.cols = cols;
            this.rows = rows;
            for (int col = 0; col < cols; col++){
                for (int row = 0; row < rows; row++){
                    final Button rect = new Button();
                    rect.setMinSize(30, 10);
                    add(rect, col, row);
                    final int selectedCol = col;
                    final int selectedRow = row;
                    rect.setOnMouseMoved(new EventHandler() {
                        @Override
                        public void handle(MouseEvent mouseEvent) {
                            selectRange(selectedCol, selectedRow);
                            text.setValue((selectedCol + 1) + " x " + (selectedRow + 1));
                        }
                    });
                    rect.setOnAction(new EventHandler() {
                        @Override
                        public void handle(ActionEvent actionEvent) {
                            fireCreateTable(selectedCol + 1, selectedRow + 1);
                            deselectAll();
                        }
                    });
                }
            }
            deselectAll();
        }
  
        private Node getNodeFromGridPane(int col, int row) {
            for (Node node : getChildren()) {
                if (GridPane.getColumnIndex(node) == col && GridPane.getRowIndex(node) == row) {
                    return node;
                }
            }
            return null;
        }
  
        private void selectCell(int col, int row, final boolean select){
            final Node node = getNodeFromGridPane(col, row);
            if (select){
                node.setStyle("-fx-border-width: 0.5; -fx-border-color: #ffffff; -fx-background-color: lightskyblue");
            } else {
                node.setStyle("-fx-border-width: 0.5; -fx-border-color: #000000; -fx-background-color: #ffffff");
            }
        }
  
        public void deselectAll(){
            for (int col = 0; col < cols; col++){
                for (int row = 0; row < rows; row++){
                    selectCell(col, row, false);
                }
            }
        }
        private void selectRange(int selectedCol, int selectedRow){
            deselectAll();
            for (int col = 0; col <= selectedCol; col++){
                for (int row = 0; row <= selectedRow; row++){
                    selectCell(col, row, true);
                }
            }
        }
    }
}

Besonders inter­essant ist die Methode selectCell, in der die Zellen­färbung unmit­telbar im Code reali­siert wird:

Für normale Zellen:

node.setStyle("-fx-border-width: 0.5; -fx-border-color: #000000; -fx-background-color: #ffffff");

Für Zellen im ausge­wählten Bereich:

node.setStyle("-fx-border-width: 0.5; -fx-border-color: #ffffff; -fx-background-color: lightskyblue");

Weil es in der Aufga­ben­be­schreibung steht, dass klare Farben­zu­weisung unmöglich ist, versuchen wir die mit Hilfe eines eigenen Styles in styles.css zu definieren:

#MyCellNormal {
    -fx-border-width: 0.5;
    -fx-border-color: #000000;
    -fx-background-color: #ffffff;
}
 
 
#MyCellInRange {
    -fx-border-width: 0.5;
    -fx-border-color: #ffffff;
    -fx-background-color: lightskyblue
}

Und in der Methode selectCell:

private void selectCell(int col, int row, final boolean select){
            final Node node = getNodeFromGridPane(col, row);
            if (select){
                                node.setId("MyCellNormal");
            } else {
                                node.setId("MyCellInRange");
            }
        }

Schon besser, nicht war? D.h. wenn der Kunde mit der Farbwahl unzufrieden sein sollte, kann man sie direkt in der Datei styles.css ändern. Die Logik der Kompo­nente bleibt dabei unverändert.

Aller­dings gibt es eine noch elegantere Lösung der Aufgabe: Platzieren wir in styles.css noch zusätzlich 2 Sytles:

.MyCell {
    -fx-border-width: 0.5;
    -fx-border-color: #000000;
    -fx-background-color: #ffffff;
}
 
 
.MyCell:inRange {
    -fx-border-width: 0.5;
    -fx-border-color: #ffffff;
    -fx-background-color: lightskyblue
}

Das bedeutet, dass die Zellen sich auf den Style «MyCell» orien­tieren und wenn der Trigger «inRange» greift, analog zu «hover» oder «presset», ändert sich die Farbe entsprechend.
Aber wie bringen wir der Zelle bei, den Trigger zu starten?
Da wir in unserem Beispiel für die Zellen, Button-Elemente nutzen, ist es erfor­derlich ihr Verhalten in der so genannten Pseudo-Klasse neu zu definieren. In JavaFX 1.7 wird das so gemacht:

protected static class RangeButton extends Button {
        public RangeButton(){
            getStyleClass().add("MyCell");
        }
 
 
        private BooleanProperty inRange = new BooleanPropertyBase() {
 
 
            @Override
            protected void invalidated() {
                impl_pseudoClassStateChanged("inRange");
            }
 
 
            @Override
            public Object getBean() {
                return RangeButton.this;
            }
 
 
            @Override
            public String getName() {
                return "inRange";
            }
        };
 
 
        public boolean isInRange() {
            return inRange.get();
        }
 
 
        public void setInRange(boolean value) {
            inRange.set(value);
        }
 
 
        private static final long IN_RANGE_PSEUDOCLASS_STATE = StyleManager.getInstance().getPseudoclassMask("inRange");
 
 
        @Override
        public long impl_getPseudoClassState() {
            long mask = super.impl_getPseudoClassState();
            if (isInRange()) mask |= IN_RANGE_PSEUDOCLASS_STATE;
            return mask;
        }
    }

Wie wir sehen, sind alle Methoden «…Pseudo­Class…» – deprecated.
Jetzt nutzen wir statt Button unseren RangeButton. Und die Methode selectCell sieht nun so aus:

private void selectCell(int col, int row, final boolean select){
            final Node node = getNodeFromGridPane(col, row);
            ((RangeButton)node).setInRange(select);
        }

D.h. die Änderung der Feldei­gen­schaft «InRange» führt dazu, dass der Style-Trigger greift und die Farbe der ausge­wählten Zellen sich entspre­chend ändert.
Das ist genau das, was wir brauchen!
In JavaFX 1.7 funktio­niert das. In JavaFX 1.8 ist das leider verboten. Der Code ist nicht mehr kompi­lierbar sobald JVM 1.8 hinzu­ge­schaltet wird.
Was bietet uns dann die neue Version an der Stelle?
Wie bereits erwartet, wurden die depre­cated Methoden entfernt und die Archi­tektur verein­facht. Jetzt reicht es daher aus, wenn wir folgendes tun:

protected static class RangeButton extends Button {        protected final PseudoClass pcInRange = PseudoClass.getPseudoClass("inRange");
 
 
        public RangeButton(){
            getStyleClass().add("MyCell");
        }
 
 
        protected final BooleanProperty inRange = new BooleanPropertyBase() {
 
 
            @Override
            protected void invalidated() {
                pseudoClassStateChanged(pcInRange, getValue());
            }
 
 
            @Override
            public Object getBean() {
                return RangeButton.this;
            }
 
 
            @Override
            public String getName() {
                return "inRange";
            }
        };
 
 
        public boolean isInRange() {
            return inRange.get();
        }
 
 
        public void setInRange(boolean value) {
            inRange.set(value);
        }
    }

Alles funktio­niert wie bisher.
Man kann den Code noch etwas vereinfachen…:

protected static class RangeButton extends Button {
        protected final BooleanProperty inRange;
        public RangeButton(){
            getStyleClass().add("MyCell");
            final PseudoClass pcInRange = PseudoClass.getPseudoClass("inRange");
            inRange = new SimpleBooleanProperty();
            inRange.addListener(new ChangeListener() {
                @Override
                public void changed(ObservableValue<? extends Boolean> observable, Boolean oldValue, Boolean newValue) {
                    pseudoClassStateChanged(pcInRange, newValue);
                }
            });
        }

…und die Methode entspre­chend ändern:

private void selectCell(int col, int row, final boolean select){
            final Node node = getNodeFromGridPane(col, row);
            ((RangeButton)node).inRange.setValue(select);
        }

Zusam­men­fassung: Mit Hilfe der beschrie­benen Lösung auf JavaFX ist es möglich, spezielle userbe­zogene Eigen­schaften der Kompo­nenten zu erstellen und diese mit den Styles zu verknüpfen,. Das ist besonders bequem, wenn die Anfor­derung besteht, die Business­logik komplett von der GUI zu abstrahieren.

Bei der Entwicklung einer Software sind Tests zur Quali­täts­si­cherung ein sehr wichtiger Arbeits­ab­schnitt. Hierbei werden verschiedene Sicher­heits­aspekte einer erstellten und weiter­ent­wi­ckelten Software durch unter­schied­liche Sicher­heits­an­for­de­rungen berück­sichtigt. Dabei spielen Tests im Risiko­be­reich, ein mögliches Keyword-Driven Testing oder Data Driven Testing mit verschie­denen Verfahren und Teststufen eine wichtige Rolle. Diese Tests werden stets vor einer endgül­tigen Abnahme und Freigabe zur Nutzung durch­ge­führt. Im Rahmen der Quali­täts­si­cherung wird dabei zwischen analy­ti­schen und konstruk­tiven QS-Maßnahmen unter­schieden. Weiter­lesen

Sammlung der statis­ti­schen Infor­ma­tionen über die Dokumente

In einem Dokumen­ten­ver­wal­tungs­system werden in der Regel Verträge, Versi­che­rungen, Rechnungen und Belege, E‑Mails und Faxe unter­ge­bracht und nach Wichtigkeit sortiert. Wird ein Workflow Management einge­führt, werden die Arbeits­ab­läufe, die in einer Organi­sation etabliert sind, eventuell auch organi­sa­ti­ons­über­greifend festgelegt. Dies setzt aber voraus, dass die Prozess­ab­läufe schon vor der Einführung des Systems festgelegt und analy­siert werden. Aus diesem Grund ist eine Festlegung der Workflows erfor­derlich, auch für die Abläufe der elektro­ni­schen  Bearbeitung. Erst wenn alles festgelegt ist, kann auch die Festlegung der daten­schutz­recht­lichen Sicher­stellung der Bearbei­tungswege garan­tiert werden. Erst wenn die komplette Bearbeitung elektro­nisch durch das Workflow-Management gesteuert wird, sind die Arbeits­ab­läufe vor der Nutzung dieses Systems hervorzuheben.

Welche DMS Software wird auf dem Markt angeboten?

Es bieten sich unter­schied­liche Software-Systeme für die Dokumen­ten­ver­waltung an. Zum einen sind es die kommer­zi­ellen Software­an­gebote, zum anderen gibt es die freien Software Systeme für DMS. Diese bieten sich als gebüh­ren­freie Open-Source Lizenzen an. Die freie Software kann von jedem Unter­nehmen selbst instal­liert und genutzt werden. Es gibt aller­dings auch Anbieter, die sich auf diese freie Software spezia­li­siert haben und auf der Basis der freien Software Dienstleistungen erbringen, die wiederum ihrer­seits kosten­pflichtig sind. Bei den freien Systemen ist vorteilhaft, dass diese den Bedürf­nissen des Anwenders angepasst werden können und Fehler auch automa­tisch behoben werden können – dadurch kann das Inves­ti­ti­ons­vo­lumen um ein Vielfaches gesenkt werden. Das so freiwer­dende Budget kann für wichtigere Anpas­sungen genutzt werden. Es stehen folgende Software Systeme zur Verfügung:

Freie Software Programme

Alfresco ist eine Community Edition, Agorum core – open,
Bitfarm-Archiv, LogicalDOC ist ebenfalls eine Community Edition,
Nuxeo EP, PLMWORX, Open-Xchange

Die Kommer­zi­ellen Software Programme

Alfresco (Enter­prise Edition), Agorum core (Pro), BSCW, dotiga, Document Control Center
Fabasoft Folio, Elektro­ni­scher Leitz Ordner, LogicalDOC (Enter­prise Edition), Main Pyrus DMS,
Microsoft Share­Point Server besitzt nur Teilfunk­tionen eines DMS, IBM FileNet, Xerox DocuShare

Sollte man selber eine DMS-Software entwi­ckeln oder besser eine bereits bestehende Software nutzen?
Wenn man die Software-Entwicklung beherrscht, steht dem sicherlich nichts im Wege, aber in der Regel bietet sich eine günstige und anpassbare DMS Software durchaus an. Freie Software bietet sehr viele Vorteile.
Es besteht aber auch die Möglichkeit, sich eine eigene Software von einem Unter­nehmen bezie­hungs­weise einem Software-Entwickler erstellen zulassen. Diese kann dann natürlich auch genau auf die Bedürf­nisse und die Arbeits­ge­wohn­heiten des Unter­nehmens angepasst werden. So müssen sich die Mitar­beiter nicht umstellen und können ihre gewohnten Arbeits­weisen beibe­halten. Das wiederum ist aber auch mit den freien Software Systemen möglich. Letztlich ist es eine echte Kosten-Nutzen-Frage.

Fortsetzung folgt.

Wenn die Software oder eine Website nicht mehr den Anfor­de­rungen entspricht oder neue Produkte oder Produkt­pa­letten aufgelegt werden, müssen sowohl kleine Start-up-Firmen als auch große Unter­nehmen eine Entscheidung treffen: Wie und durch wen ist die IT-Entwicklung in Zukunft zu regeln? Durch IT-Outsourcing lässt sich bei der Neu- und Weiter­ent­wicklung hausin­terner Software oder auch beim Erstellen einer reprä­sen­ta­tiven Website viel Zeit und Geld sparen. Weiter­lesen

Wer mobile Endgeräte wie Smart­phone oder Tablet nutzt, nutzt immer auch mobile Anwen­dungen, Apps genannt. Diese kleinen Programme die für die unter­schied­lichen Benut­zer­ober­flächen wie iOS, Android, Windows Phone oder ein Black­berry geschrieben wurden, können den Alltag erleichtern. Wir verraten Ihnen, in welchen Lebens­be­reichen das am besten klappt.  Weiter­lesen

Die Aufwands­schätzung gehört in der IT-Branche als fester Bestandteil zu einer umfas­senden Voraus­planung dazu, denn Erfolg einer Projekt­arbeit kann maßgeblich davon abhängen. Deshalb muss bereits früh eine realis­tische Aufwands­schätzung durch­ge­führt werden, um basierend darauf maßgeb­liche Entschei­dungen für den Projekt­ablauf zu treffen. Auf diese Weise können unren­table Projekte schneller einge­stellt werden, um Kosten und Ressourcen zu sparen, während man in rentable Projekte frühzeitig inves­tiert kann. Erfahren Sie hier, wie wir die Aufwands­ein­schätzung angehen. Weiter­lesen

Eine Anfor­de­rungs­spe­zi­fi­kation schafft die Basis für die Entwurfs­phase. Sie definiert klar Kunden­wünsche für das zukünftige IT-System und ist unerlässlich im weiteren Entwick­lungs­prozess von IT-Projekten. Im Lastenheft werden die Anfor­de­rungen präzise ausfor­mu­liert. So sollte es auch sein, denn wenn eine Anfor­de­rungs­spe­zi­fi­kation unklar definiert wird, kann dieser Umstand schwer­wie­gende Folgen haben, da die Qualität einer Anfor­de­rungs­spe­zi­fi­kation starken Einfluss auf die Qualität des zu entwi­ckelnden Projekts hat.

Weiter­lesen

Neben dem hinglänglich bekannten Platz­hirsch Microsoft Office, hat sich eine mittler­weile beacht­liche Vielzahl an Office-Alter­na­tiven auf dem Markt etabliert. Und: Etliche davon werden sogar kostenlos angeboten. Zu den bekann­testen Microsoft-Alter­na­tiven zählen OpenOffice, Libre­Office, ThinkFree Office, Kingsoft Writer Free, SoftMaker FreeOffice sowie iWork und NeoOffice für Macintosh. Vor allem OpenOffice und Libre­Office sind sehr für den alltäg­lichen Büroeinsatz zu empfehlen.

Cloud­ba­sierte Office-Anwendungen

Anstatt ein Office-Programms zu kaufen, bietet sich auch die Alter­native, entspre­chende Software in einem Abonnement-Modell teils kosten­pflichtig online zu mieten. Im Gegensatz zu desktop­ori­en­tierten Programmen setzt die cloud­ba­sierte Variante eine konstante Online-Verbindung voraus, was aber gleich­zeitig den Vorteil hat, dass Dokumente sogar von mehreren Personen gleich­zeitig, direkt im Browser bearbeitet werden können. Vorteilhaft ist darüber hinaus auch die ständige Verfüg­barkeit aller Dokumente auf jedem inter­net­fä­higen Rechner. Außerdem ist die Funktionen- und Menüauswahl bei diesen Anwen­dungen meist auf das Wesent­liche beschränkt, damit auch Einsteiger schnell damit zurecht­kommen. Zu den führenden Office-Cloud-Anbietern zählen Google Drive (ehemals Google Docs), Microsoft 365, ThinkFree oder auch Live Documents. Speziell für Mac-User dürfte das in iCloud integrierte Büropro­gramm iWork inter­essant sein.
Als nachteilig kann sich bei Online-Office-Programmen erweisen, dass, sofern kosten­pflichtig, nach Ablauf des Abonne­ments nicht mehr genutzt werden können und im Umfang weniger als Desktop-Programme anbieten. Abschre­ckend können vielfach auch die Sicher­heits­kon­zepte wirken, da die Kontrolle über die eigenen Daten ungewiss ist und sie dem Cloud-Anbieter, oft auf auslän­di­schen Servern, überlassen werden müssen. Zudem besteht die Gefahr, dass ein Anbieter vom Markt verschwindet, wodurch dann auch kein Zugriff auf die Daten mehr besteht. Mögliche Risiken, die bei Auswahl des Office-Programms mit bedacht werden sollten.

Darstellung und Kompatibilität

Bei komplexem, umfang­reichem Layout, gibt es bei den Text- und vor allem bei den Präsen­ta­ti­ons­pro­grammen von OpenOffice und Libre­Office hin und wieder Darstel­lungs­pro­bleme bei der Bearbeitung von Microsoft Office-Dokumenten. Zwar wurden etliche Darstel­lungs­fehler, wie beispiels­weise die korrekte Übertragung von Aufzäh­lungen, inzwi­schen behoben. Doch eine exakt identische Darstellung ist immernoch nicht grund­sätzlich möglich. Bei den cloud­ori­en­tierten Anwen­dungen per App sind obendrein Dokumente mit vielen Bildern und Fußnoten mit der korrekten Anzeige relativ schnell überfordert.
Bei einigen, vor allem älteren Programmen, treten Kompa­ti­bi­li­täts­pro­bleme auch unter den Datei­for­maten auf. So muss beispiels­weise in Microsoft Office beim Speichern eines docx-Dokuments beachtet werden, dass die Datei aufgrund mangelnder Abwärts­kom­pa­ti­bi­lität (also Kompa­ti­bi­lität zu älteren Programmen) nicht in älteren Word-Dokumenten (z.B. Word 2003) korrekt geöffnet werden kann.

Was ist eine Machbar­keits­studie und welchen Zweck erfüllt sie? Bei jedem Projekt zur Software­ent­wicklung ist es notwendig, die Erfolgs­aus­sichten im Rahmen der Durch­führ­barkeit zu prüfen und Lösungs­an­sätze zu schaffen. In diesem Bereich siedelt sich die Machbar­keits­studie an und führt zur authen­ti­schen wirtschaft­lichen Beurteilung eines Projekts.

Die Machbar­keits­studie als Effizienz-Analyse

Ob ein Projekt für den Auftrag­geber den angestrebten Nutzen und Mehrwert erbringt oder anhand der Machbar­keits­studie mangelnde Effizienz aufzeigt, lässt sich vor der eigent­lichen Reali­sierung erkennen. Der primäre Sinn dieser Analyse ist es, Fehlin­ves­ti­tionen zu vermeiden und einen Lösungsweg zu finden, der unter möglichst günstigen Kondi­tionen und bei gleich­zeitig bester Leistung zum gewünschten Ergebnis führt. Eventuelle Risiken im Projekt werden vorab erkannt und können dementspre­chend idealer­weise ausge­schlossen werden. Die Machbar­keits­studie setzt sich aus den eigent­lichen Analysen und im zweiten Schritt aus deren Bewer­tungen zusammen. Sie dient dem Auftrag­geber als Entschei­dungs­hilfe anhand von Fakten, die alle Chancen und Risiken dokumen­tiert und eine Orien­tie­rungs­emp­fehlung gibt. Kosten und Nutzen werden mit gleicher Aufmerk­samkeit bedacht und führen zu einer Bewertung, die dem Auftrag­geber Vorteile erbringt und in der Software­ent­wicklung zur Reali­sierung ohne unbekannte und während der Projekt­phase auftre­tende Risiken führt.

Nutzen und Budge­tierung im Fokus

Indivi­duelle Software für Unter­nehmen geht mit einem nicht immer günstigen Budget einher und muss dementspre­chend kalku­liert und in Präzision geplant werden. Ist die Idee entstanden und soll in ein Projekt umgesetzt werden, beginnt die Suche nach dem günstigsten und besten Lösungsweg. Durch die Machbar­keits­analyse werden manuelle Fehler in der Bewertung ausge­schlossen und sich auf Fakten und Daten berufen, die mathe­ma­ti­scher Berechnung und logischen Prozesse entspringen. Sämtliche Risiken und Chancen eines Lösungs­an­satzes und des fertig gestellten Projekts sind vorab ersichtlich, wodurch der Auftrag­geber sich für oder gegen einen Lösungsweg in der Software­ent­wicklung entscheiden und die Machbar­keits­analyse als sichere Empfehlung und Entschei­dungs­grundlage betrachten kann.

Im Bereich der Software­ent­wicklung im Kunden­auftrag können Fehlent­schei­dungen mit hohen Kosten und enormen Risiken einher­gehen. Die Machbar­keits­analyse schließt solche Probleme aus und ist eine Basis, anhand derer ein Projekt geplant, kalku­liert und mit maximaler Funktio­na­lität effizient umgesetzt werden kann.

Das Arbeiten mit Software ist in den letzten Jahrzehnten für die meisten Menschen zu einem ganz gewohnten und auch wichtigen Teil ihres Alltags geworden. Egal ob wir im Internet surfen, Briefe oder E‑Mails schreiben oder am Arbeits­platz mit firmen­in­ternen Programmen konfron­tiert sind, der sichere Umgang mit Software wird heutzutage erwartet und voraus­ge­setzt. Proble­ma­tisch wird es erst, wenn eine Software für einen Menschen eine Barriere darstellt. Farben werden schlecht oder gar nicht erkannt, Töne nicht gehört oder Texte können nicht gelesen werden. Die barrie­re­freie Software­ent­wicklung setzt genau dort an.

Was ist barrie­re­freie Softwareentwicklung?

Programme, die für jeden Menschen mit körper­licher oder geistiger Einschränkung geeignet sind, werden barrie­re­freie Programme genannt. Eine körper­liche Einschränkung kann das limitierte oder nicht vorhandene Sehver­mögen sein, hier müssen Alter­na­tiven für den regulären Text gefunden werden. Bei Menschen ohne Hörver­mögen können akustische Signale zum Beispiel beim E‑Mail Eingang nicht genutzt werden. Menschen mit einer Rot-Grün-Sehschwäche müssen andere Farben angeboten werden. Auch Senioren kommen mit barrie­re­freier Software oft besser zurecht, hier muss zum Beispiel auf die vermin­derte Reakti­onszeit und größere Texte oder die Anwend­barkeit einer Bildschirmlupe geachtet werden. Fremd­spra­chige Personen haben oft Probleme mit dem Textver­ständnis. Hier können automa­tische Überset­zungen oder eine verein­fachte Semantik helfen.

Was ist wichtig?

Barrie­re­freie Software­ent­wicklung muss die verschie­densten Aspekte von Programmen berück­sich­tigen. Je nach Software und Zielgruppe ist das zum Beispiel die Orien­tierung des Textes oder eine Ersatz­be­schreibung für Multi­me­dia­in­halte. Auch Farben und Kontraste müssen überprüft und eventuell anpassbar sein. Texte und das Layout müssen in den unter­schied­lichsten Größen eindeutig erkennbar und erfassbar sein. Besonders wichtig ist auch die Dynamik des Programms: Ist die Software über die Maus und die Tastatur steuerbar? Kann man womöglich eine Steuerung über die Stimme ermög­lichen? Auch Elemente zur Navigation und Orien­tierung müssen konsistent umgesetzt werden, mögli­cher­weise sind hier auch zusätz­liche Elemente nötig.

Wie wird Software auf Barrie­re­freiheit überprüft?

Für Entwickler ist es wesentlich einfacher, die Barrie­re­freiheit im Vornherein zu imple­men­tieren, als sie später einzu­fügen. Bereits entwi­ckelte Programme können mit Hilfe von mehreren Richt­linien überprüft werden. Besonders drei Leitfäden haben sich hier in der Praxis bewährt:

    1. Die DIN EN ISO 9241–171 Leitlinien für die Zugäng­lichkeit von Software
    2. Die Entwickler-Richt­linien von IBM (Developer Guidelines)
    3. Die Richt­linien für barrie­re­freie Webin­halte des World Wide Web Consortium

Die Überprüfung eines Programms ist aber immer noch „Handarbeit“. Es gibt bis heute keine eigen­stän­digen Programme, die dies leisten könnten. Während der Test auf die Kompa­ti­bi­lität mit der Tastatur relativ einfach durch­zu­führen ist, sind manche Aspekte von Software im Nachhinein nur schwer auf barrie­re­freies Arbeiten zu überprüfen. Dazu gehören alle Anfor­de­rungen, die im Quellcode der Program­mierung schwer oder gar nicht mehr zu finden sind, wie zum Beispiel das Versehen einer jeden Schnitt­stelle oder Elements mit einem spezi­fi­schen Namen.