About Design

This page contains an archive of all entries posted to /blog/wvk in the Design category. They are listed from oldest to newest.

Coding is the previous category.

Hardware is the next category.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.31

Main

Design Archives

October 26, 2007

System-Statusanzeige

Zu jeder ordentlichen Serververwaltungssoftware gehört natürlich auch eine Anzeige der wichtigsten Systemeigenschaften. Da mir gestern Abend soo langweilig war, habich dann auch prompt mal ein paar Statusanzeigen für Consolvix geschrieben. Natürlich alles schön Ajax-based, sprich die Anzeigen verändern sich im 5-10-Sekundentakt.

Viel Mehr gibt's dazu eigentlich nicht zu schreiben, denn ein Bild sagt mehr als 1024 Worte:

snap11.png
Admin-Startseite: Das wichtigste auf einen Blick, sprich Auslastung und Speicherverbrauch (aufgeschlüsselt nach Verwendung)

snap10.png
Syslog: zeige die letzten Einträge von /var/log/syslog an

snap12.png
Der aktuelle Prozessbaum, optional mit Anzeige der PIDs (wer erkennt hier die Ausgabe von pstree? keks)

snap14.png
Die Anzeige des freien/belegten Plattenplatzes, im wesentlichen eine grafisch aufgearbeitete Version von df.

Sollte demnächst mal wieder Langeweile aufkommen, wird diese "Toolbox" sicherlich noch erweitert werden (Vorschläge von zukünftigen Nutzern dieser Software sind willkommen!)

October 31, 2007

Ein Bisschen GUI muss sein...

Aus nicht weiter beschreibenswürdigem Anlass wurde ich heute mal wieder auf das schon länger nicht mehr von mir benutzte Programm Kommander aufmerksam. Für die nicht-KDE-Benutzer unter euch (O_o, ich fürchte hier tun sich gerade Abgründe auf... ;-)): Das ist ein tolles Programm um mal eben schnell GUIs für Konsolenprogramme, einfache (OK, gerne auch komplizierte) scriptbasierte Anwendungen und dergleichen mehr zu schreiben. Nachdem ich lange damit herumgespielt hatte und dabei die Innereien von KDE (genauer genommen die DCOP-Schnittstelle, eine einfach nur wundervolle Sache!) näher kennen gelernt hatte, kam ich auf die Idee, die mir schon vor ewigen Zeiten mal gekommen war: eine einfache GUI für script/generate zu schaffen. Nun mag das trivial klingen -- und das ist es auch. Tja, was gibt's mehr zu sagen... So sieht dat Dingen aus:

snap16.png

Und hier kann man sich dat Dingen herunterladen (yepp, I'ts GPLed): Download Rails Helper.

Und Aufrufen kann man dat Dingen mit:

kmdr-executor rails-helper.kmdr

Außerdem kann man das in KDE's hübsche Entwicklungsumgebung KDevelop als Menüpunkt einbinden, sodass man immer nur zwei Klicks oder eine Tastenkombination davon entfernt ist:

snap15.png

Zur Erklärung der trivialen GUI: "name" durch den Namen des zu erstellenden Controllers/Models/Scaffolds/Migration ersetzen, im Falle von Controller oder Scaffold bis zu 6 Methodennamen eingeben (die Felder werden sonst ausgeblendet, also selbsterklärender geht nicht...) und "GENERATE" aufrufen -- in der Konsole (da wo auf dem Screenshot noch nichts steht) landet die Ausgabe von script/generate.

Das war's mal wieder für heute! Gute Nacht und bis zum nächsten Mal ;-)

November 25, 2007

Abgerundete Ecken

So, nach einer ereignisreichen Woche bin ich nun zurückgekehrt und kann endlich wieder einmal mit etwas Inhalt an dieser Stelle dienen. Es gibt momentan wenig Großartiges zu berichten, darum stelle ich einfach mal eine kleiner helper-Funktion vor, die mir schon seit langem das Leben mit Web 2.0 leichter macht. Nein, es handelt sich dabei nicht um "fancy Ajax"-Funktionalität, sondern um etwas anderes was mit dem W2.0-Hype exponentiell zuzunmehmen scheint: abgerundete Ecken bei "Boxen". Es gibt jede Menge Möglichkeiten, so etwas umzusetzen. Ich hab mich für die folgende Methode entschieden.

Als erstes benötigt man eine Hintergrundgrafik, die folgendermaßen zerschnitten wird:

text3159.png

Dabei ist zu beachten, dass der Hintergrund bei den abgerundeten ecken nicht transparent ist, sondern dem Seitenhintergrund entspricht -- Da sich die Bilder nachher überlappen, würde der ganze Effekt sonst verloren gehen.

Als nächstes definiere man sich für jedes DIV, das mit den runden Kanten versehen werden soll, ein solches Konstrukt:

<div class="rro">
  <div class="rru">
    <div class="rlo">
      <div class="rlu">
        <div class="rounded_content">
          Hier kommt der Inhalt rein!
        </div>
      </div>
    </div>
  </div>
</div>

Das Stylesteet ergänze man um folgende Zeilen:

.rro {
    display: block;
    max-width: 580px;
    background:url("/images/roundedbox_ro.png") top right no-repeat;
    margin:  .2em;
    padding: 0;
}

.rlo {
    background:url("/images/roundedbox_lo.png") top left no-repeat;
    margin:  0;
    padding: 0;
}

.rru {
    background:url("/images/roundedbox_ru.png") bottom right no-repeat;
    margin:  0;
    padding: 0;
}

.rlu {
    background:url("/images/roundedbox_lu.png") bottom left no-repeat;
    margin:  0;
    padding: 0;
}

.rounded_content {
    padding: .4em .4em;
}

Da es aber unheimlich umständlich ist, jedes Mal diese Batterie an DIVs hinzuschriben, habe ich folgende funktion in ApplicationHelper definiert:

module ApplicationHelper
  def rounded_corners(id = nil, &block)
    content = capture(&block)
    concat(content_tag_string(:div,
      content_tag_string(:div,
        content_tag_string(:div,
          content_tag_string(:div,
            content_tag_string(:div, content, :class => 'rounded_content'),
            :class => 'rlu'),
          :class => 'rlo'),
        :class => 'rru'),
      :class => 'rro', :id => id),
    block.binding)
  end
end

Will man nun in einer View eine Box mit abgerundeten Ecken darstellen, geht das ganz einfach so:

<% rounded_corners 'mein_abgerundetes_dingsda' do %>
  Hier kommt der Inhalt rein!
<% end %>

Und der Rest wird von Ruby gemacht. Ist das nicht hübsch? :)

December 7, 2007

Ein Desktop für den Admin

Bei der Suche nach einer vernünftigen Startseite für den Ober-Admin meiner Applikation bin ich nun etwas weiter gekommen. Noch bin ich weit weg von einem einheutlichen und einleuchtenden "Workflow", aber eigentlich liegt das Haupt-Augenmerk der Diplomarbeit ja auch auf der Kern-Infrastruktur (OK, da gehört eigentlich aucht die Oberflächen-Infrastruktur zu, denke ich...). Jedenfalls fragte ich mich:

  • Was muss ein Admin (also ich ;-)) auf seriner Einstiegseite sehen?
    • eine Übersicht über die häufigsten Aktionen (Kunden anlegen, FTP-&Emailkonten anlegen, ...)
    • eine Übersicht über die Systemauslastung/Resourcenverbrauch
    • eine Liste mit anstehenden Aufgaben (Kundenanfragen, Systempflege,... -- NICHT Teil deser Arbeit!)
    • bestimmt noch mehr... also was noch?

  • Was muss ich NICHT auf der Startseite sehen?

    • Gute Frage!

Da sicher jeder Admin andere Vorlieben hat, habe ich ein kleines Experiment angefangen, was bislang ganz gut läuft: Es gibt jetzt einen Admin-Desktop mit Icons die zu den o.g. Aufgaben verlinkt sind. Außerdem gibt es eine beliebig einstellbare Anzahl sog. "Applet-Felder", auf die man die (meisten) Icons draggen&droppen kann, um sie als "Applet" darzustellen:

snap28.png

Beispielsweise kann man in einem Feld den Speicherverbrauch im Auge behalten, während man in einem anderen Feld einen Kunden anlegt (alles schön per Ajax). Oder, plausibler, ich lege einen Kunden an, währenddessen ruft ein anderer Kunde an der gerne sein Kennwort neu gesetzt haben will -- statt nun ein neues Browserfenster zu öffnen, kann ich also "Kennwort ändern" auf ein freies Applet-Feld ziehen und die Aufgabe dort erledigen ohne die andere aus dem Auge zu verlieren...

snap29.png

Ein weiterer kleiner Vorteil ist, dass man seine Startseite nun relativ frei einteilen kann. Und ja, natürlich werden die "Applets" gespeichert, d.h. wenn man die seite verlässt und später wieder aufruft, erscheinen alle Applets wieder an der Stelle wo man sie vorher hingepackt hat (momentan ist das noch an die Session gebunden, das kann man aber genausogut persistent in die Datenbank auslagern).

Natürlich kann man auch einfach die Icons anklicken um zu einer nicht-AJAX-Basierten Version der Aktionen zu kommen.

Bäume und Navigation

Ich hatte mir neulich überlegt, für gewisse Aufgaben in meiner Applikation eine Baum-Navigation zu bauen. Philipp hatte dereinst die Idee geäußert, alle Kunden als hauptknoten darzustellen, dann darunter aufklappbar deren bezogenen Leistungen wie HTTP-Hosts, FTP- und Email-Konten und darunter deren Details... An sich eigentlich eine ganz gute Idee, so dachte ich mir, aber ziemlich aufwändig in der Umsetzung. Und als ich dann dieser Tage mich an die Umsetzung wagen wollte, da bin ich auf einen sehr überzeugenden Artikel gestoßen: Why is a tree view a poor navigational choice in software applications?. Diese Liste schien mir recht überzeugend. Der nächste Artikel befasst sich darum auch mit Alternativen: Tree View Removal Surgery. Sehr toll.

Ansonsten gilt zu sagen: Ich würde mich gerne mal mit einem Usability-/UI-Spezialisten unterhalten, denn ich merke dass ich von gutem Oberflächendesign nicht besonders viel Ahnung habe...

January 4, 2008

Desktop-Icons die Zweite + Navigation

Gerade fiel mir etwas auf, was schon lange implementiert ist, wozu ich aber noch kein Wort geschrieben habe (vermutlich eingeschüchtert durch die vielen gut gemeinten Ermahnungen, ich solle mich mehr um's Innenleben als um die Oberfläche meiner Software kümmern...).

Richtig geraten, es geht um die Oberfläche. Vor einiger Zeit hatte ich das Konzept der Deskop-Icons, die man per Drag&Drop auch als Applets einsetzen kann. Nun schien das einigen Menschen nicht sehr intuitiv und bei anderen funktionierten entweder die Links oder das Drag&Drop, deswegen gabs dort ein paar Änderungen:

  • Es wird nun unterschieden zwischen normalen "Navigations"-Icons und Applet-Icons. Applet-Icons sind nicht mit einem Link belegt und können per Drag&Drop auf die Applet-Flächen auf dem Desktop gezogen werden. die anderen Icons sehen ähnlich aus, liegen aber auf einer separaten Fläche und können nur angeklickt werden (sind also "gepimpte" Links).
  • Nicht alle Funktionen können als Applet aufgerufen werden. Bislang wurde im Aufruf einer Aktion als Applet bei der proxy-Funktion (callfunctionas_applet(controller, action)) aus einem fest verdrahteten Array gelesen, ob die verlangte Funktion als Applet angezeigt werden kann. Jetzt kann über den Klassen-Methodenaufruf callable_as_applet :action1, :action2, ... pro Controller festgelegt werden, welche Aktionen als Applets angezeigt werden können.
  • Navigations-Icons werden nicht mehr fest verdrahtet vie vorher, sondern dynamsich aus der Datenbank geladen. Der Administrator kann selbst bestimmen, welche URI er mit welchem Icon verbinden will, welcher Text und Tooltipp es haben soll, in welchem Modul und bei welchen Benutzer-Typen es angezeigt werden soll (momentan sind dies: admin, user, reseller). Um ein Desktop-Icon im Controller ein @icon = ConsolvixDesktopIcon.find XYZ und in der View <%= desktop_icon @icon %>.
  • Navigations-Icons erscheinen nicht nur bei /XXX/index auf dem "Desktop" von XXX, sondern auch bei /XXX/YYY als Navigationseintrag (siehe Bild)


Jedes Desktop-Icon entspricht auch einem Haupt-Navigationseintrag für das jeweilige Modul. Desktop-Applets sind nun von den anderen Icons getrennt.


Auf Modul-Index-Seiten kann z.B. wieder ein Modul-Desktop mit Aktionen für den aktuellen Kontext angezeigt werden


Im Kontext einer Resource (z.B. Clients) wird immer eine Liste von zur Verfügung stehenden Elementen angezeigt. Im Kontext eines Elements wird eine Liste mit zur Verfügung stehenden Aktionen ausgeklappt.

April 27, 2009

Rails I18n heiß diskutiert

Die halbherzig implementierte I18n-API des Rails 2.3-Frameworks bedarf dringend einer grundlegenden Überarbeitung, wenn Rails es einmal ernsthaft in Großunternehmen schaffen soll. Ich hoffe, dass am Ende die Vernunft siegen wird und Gettext es in den Rails-Kern schafft. Ein Versuch der Evangelisierung und eine angeregte Debatte zu dem Thema findet zur Zeit auf der Rails Core-Googlegroup statt. Kommentare und Einsichten sind willkommen!