Welche Aktionen sollten als nächstes beim openWIM-System durchgeführt werden?
<2015-04-21>
r
...
|
(Zwischen-)Ziele: |
A) Öffentlicher Testbetrieb: | B) Öffentlicher Launch: | C) Ordentlicher Betrieb: | D) Verbesserter Betrieb: | E) Beispielhafter Betrieb: | F) Zukünftiger Betrieb: | |
| \_Vorgänge mit den Zielen: | () |
() | () | ()(ohne Nutzung alter DBs) | () | () | |
| 1. Nutzer-Zufriedenheit: | |||||||
| . |
a. Verständliche Nutzerschnittstelle: | => Die Logo-Bereiche aller Projekte sind fixiert. => Das SCHLIESSEN der Dialoge funktioniert ordentlich => BP-Lumia-Problem ist eingekreist und gefixt. |
§ => openWIM funktioniert mit allen zeitgemäßen Browsern. Bei den restlichen Browsern wird ein passender Hinweis dargestellt. |
§ => Auch ältere Browser oder solche mit abgeschalteter Script-Ausführung müssen Dokumente (im Simpel-Modus) anzeigen können. => Die Obj-GLiederung im Nav-Drawer ist besser ausgebaut. => Die Projekt-Statuszeile wird auch bei Smartphones (bei Aufruf der Produktionsseite) nicht umgebrochen. |
=> Es ist gut erkennbar, dass ein Login aktiv ist. Alle Optionen, die ohne Login unsichtbar sein sollen, sind ausgeblendet. => Das "Logout" ist sauber gelöst und kommuniziert. |
... | ... |
| . | b. Gute Funktionalität: | ... | § => Geschlossene Objekt-Dialoge können erneut aufgerufen werden. § => Alle Drawer werden ordentlich aus- und eingefahren. § => Im Editor gehen beim Hin- und Herschalten in die Quellcode-Ansicht KEIN mehr verloren. ___________ => Der Objektparameter-Editor ist mit den neuesten Dialog-Verfahren realisiert |
§ Bei Nicht-wimXML/XHTML -Texten (beispielsweise im unformatierten Teaser) machen DoubleQoute- und Apostroph-Zeichen Probleme. Sie werden anscheinend beim Speichern im Server vom XML-encodeten " bzw. ' in Einzelzeichen zurückgewandelt und bewirken, dass das Speichern scheitert. § => Geschlossene Objekt-Dialoge können erneut aufgerufen werden. => Der Themenbusch zum jeweiligen Projekt ist ausreichend vollständig und strukturiert ausgebaut. => HTML-Menüs wurden durch expandierbare WIM-Widgets abgelöst, die auch von Mouseover ausgelöst werden können. => => Dokumente können besser bearbeitet werden. |
=> E-Mail-Adressen und Urls werden im Klartext erkannt und anklickbar gemacht. => Dialoge verarbeiten die AutoCloseAt -Parameterangabe |
=> Bei ausreichender Privilegierung: Der <RETIRED> -Bereich eines Objektes kann aufgeräumt werden. Dafür alle Änderungen eines anzugebenden Zeitraums zusammenfassen. | ... |
| . | c. Kurze Reaktionszeiten: |
... | ... | => projectObj.latestPublished enthält nur Objekte die zum Projekt gehören => Falls machbar, wird der Rechenzeit-Fresserei vom Chrome und Internet Explorer wirksam begegnet. |
... | ... | ... |
| . | d. Gute Hilfestellungen: |
... | ... | ... | ... | ... | ... |
| . | e. Gute inhaltliche Darstellungen: | ... | ... | ... | ... | ... | ... |
| . | f. Weiteres: | ... | ... | ... | ... | ... | ... |
| 2. Betreiber-Zufriedenheit: | |||||||
| . | a. Gute Akzeptanz bei den Zielgruppen: | ... | ... | ... | ... | ... | ... |
| . | b. Gute Suchmaschinenplatzierungen: | ... | ... | => Suchmaschinen können die openWIM-Dokumente und Themen abrufen (Simpel-Modus). ... |
... | ... | ... |
| . | c. Geringe Betriebskosten: | ... | ... | ... | ... | ... | ... |
| . | d. Hohe Robustheit: | ... | => Nichtöffentliche Rubriken sind für unberechtigte Nutzer auch wirklich nicht zugreifbar - für Berechtigte dagegen schon. => Das Monitoring der Projekte funktioniert minimal, damit auffällige Störungen - besonders auch kurz nach Inbetriebnahme - schnell entdeckt und beseitigt werden können. |
... | ... | ... | ... |
| . | e. Gute Nutzungsübersicht: | ... | ... | ... | ... | ... | ... |
| . | f. Weiteres: | ... | => Verständliche Richtlinien und Begründungen für die konkrete Gestaltung der Internetpräsenzen (KAG, ...) | ... | ... | ... | ... |
| Provider-Zufriedenheit: | |||||||
| . | a. Effektive Laufzeitüberwachung: | ... | ... | ... | ... | ... | ... |
| . | b. Einfache Leistungsabrechnung: | ... | ... | ... | ... | ... | ... |
| . | c. Weiteres: | ... | ... | ... | ... | ... | ... |
| Entwickler-Zufriedenheit: | |||||||
| . | a. Die Dokumentation ist gut verwendbar: | ... | ... | => Zu "allen" Objekt-Parametern gibt es Spezifikationen, die ihren Datenwert und die Zugriffs-Regeln definieren. Auch wird festgelegt, welche Parameterwerte immer gesetzt sein müssen. ... |
=> Alle noch eingetragenen Teaser-Titel-Parameter werden automatisch entsorgt. => Zu allen Schnittstellen gibt es eine funktionale Spezifikation und Beschreibung, die thematisch ordentlich verknüpft ist (eigene Info-Rubriken?). Sowohl top-down als auch bottom-up auswählbar. Sowohl zu den "stabilen" Funktionalitäten als auch zu den ungefestigten und gewünschten. => Zu allen Funktionen und Verfahren gibt es Ablauf-Spezifikationen. Beginnend mit den oft genutzten? Mit eigener Info-Rubrik? => ... |
... | ... |
| . | b. Das System bietet ausreichende Funktionalität: | => Alle "ShowDialog"-Aufrufe sind auf neuestem Stand (außer Editor) ... |
=> Geänderte Vorgaben und Anforderunge werden systematisch(er) abgearbeitet. => Dialogbereiche funktionieren ordentlich:
|
=> Bei allen Aufrufen von convertAndInsertHTML und insertHTML ist $NoResizeEvent gesetzt, wenn es Sinn macht. => Alle "zusammenklappbaren" Bereiche sind so organisiert, dass der "zuzuklappende" Bereich stets seine vorgegebene Höhe bzw. Breite beibehält. Das "Zuklappen" geschieht ausschließlich durch Verkleinern des Darstellungsbereichs (mit Einstellung overflow:hidden; ), der den zusammenklappbaren Bereich umfasst. => Die Objektdaten (und BACKEND-Datenbasen) sind in "Originär", "Abgeleitet" und "Dynamisch" aufgeteilt. => Bei SPACEs werden die initialen WidgetSpecs-Angaben "sequentialisiert" und als "Wünsche" vom SPACE abgearbeitet. Das koordinierenden Modul könnte auch nach dem Setup im Prinzip weitere "Wünsche" senden. Später geänderte WidgetSpecs müssen in einzelne "Änderungswünsche" sequentialisiert werden. Die Umsetzung der WidgetSpec-Wünsche regelt jedoch ausschließlich das SPACE-Modul. Es entscheided anhand seiner lokalen Randbedingungen und des allgmeinen Regelwerks für SPACE-Module. Auch von den im SPACE eingetragenen Modulen können Änderungswünsche zu ihrer EIGENEN Darstellung angemeldet werden. Diese werden wiederum im SPACE koordiniert und (unter anderem) in Vorgaben für eingebettete Module umgesetzt. Diese Änderungswünsche beziehen sich meist nur auf einzelne Parameterwerte der Modulspezifikation der eingebetteten Widgets, können aber indirekt Auswirkungen auf die Vorgaben aller eingebetteten Widgets haben. => Im Client sowie beim FRONTEND- und BACKEND-Server stehen getObjParams -Handler bereit und lösen alle getData ab. =>... |
=> Es sind "Group"-Objekte nutzbar, die Zusammenstellungen von (Info-)Objekten nach außen hin wie ein einzelnes Objekt repräsentieren. Die Gruppenmitglieder müssen einen Backlink haben. Einsatz bei Compound-Dokumenten, News-Listen, ... => Es sind "Aufgabe"-Objekte verfügbar:
|
=> Über einem Nachfrage/Angebot-Markt (demand- and supply-mechanism) können für ein Projekt zu erbringende Leistungen vereinbart werden.
... |
... |
| . | c. Weiteres: | ... | ... | ... | ... | ... | ... |
...
Themen hierzuAssciated topics: