Fritz!Load - Neues Konzept

[chromax]

Ich denke bevor man die "neue Tapete" angeht muss das Konzept erst mal stimmen. Die gewachsenen Strukturen sind oft für "alte Hasen" völlig klar, aber gerade für Neueinsteiger kann man das Interface vereinfach. Auch wäre ein Umstieg auf eine Oberfläche mit Ajax, JS und HTML 5 und dessen konzeptionellen Vorteilen wichtig.

Da fritzLoad nicht wenig Funktionen hat, die auch noch miteinander interagieren (und manche kenne ich auch nicht) ist die Konzeption hier recht komplex.
Ich habe ein paar Ideen als Wireframe (in Flash) zusammengesetzt. Fehlerfrei ist es freilich nicht.

Hier kann man es sehen Konzept 01

Hauptnavigation

Die Tabs zu den Instanzen (hier stellt sich die Frage ob man Instanzen führen muss!?) zeigen den Status der Instanzen an. So wird eine Monitor-Instanz theoretisch überflüssig weil alles immer zu sehen ist. Eine Übersicht zum Unrar Status fehlt noch.
Die Subnavigation ist nach dem Vorgang geordnet. Links einfügen, Downloaden, Links ins Archiv ist der normale Vorgang. Upload bildet eine Ausnahme, wird aber nicht besonders gekennzeichnet. Das wäre vielleicht sinnvoll.
Hier wäre zum schnellen Wechsel (und weil es cool ist) ein Slider wünschenswert.

Steuerung

Die Steuerelemente sind wie unten in der einfacheren Version als Play, Stop und Kill. Die "Alles xxx" Varianten sind als Dropdown schnell erreichbar "versteckt".

Hauptfenster
Die Download-Liste ist mehr im Stil vom JDownloader und bietet mehr Übersicht ohne Verschachtelung. Generell ist die Frage ob man wirklich Files und Unrar in einer extra Übersicht braucht oder ob man diese Fenster intelligent zusammenführen kann. So ist die Unrar aktivierung direkt neben der Datei anwählbar. Der Status der Dateien wird links mit einfacher Sprache angezeigt und der User bekommt nur die nötigen Informationen.


Weitere Informationen können durch ein Accordeon angezeigt werden.


Footer
Der Footer zeigt den restlichen freien Speicher der Festplatte.


Links einfügen

Wie bisher, nur ohne Extra Buttons für jeden Vorgang. Die Idee ist es die Voreinstellungen nicht in den Configs zu verstecken, sondern einen schnellen Überblick zu bieten ohne den aktuellen Stand zu verlassen. Daher hab ich eine Lightbox gewählt.



Es stecken viele Überlegungen dahinter und trotz das noch nicht viel zu sehen ist, ist die Konzeption hier von sehr zeitaufwändig und komplex. Einige Buttons fehlen noch, weil ich diese nicht Einordnen und nutzen kann. Z.B. bin ich FreeUser und kenne mich mit Uploads und Credits nicht aus. Die technische Machbarkeit ist zudem noch ein anderes Thema!






_________________________________________________________________________________________________________
Älterer Beitrag:


Sehr frühe Version. (Englisch)

Fullscreen

Konzeptionelle Änderungen:

Ich denke das Otto-Normal-User mit Files (oder in der deutschen Version "Dateien") besser klar kommt. Protokoll hin oder her.

Die "Monitor" Instanz sollte auch so heissen wie man es sofort versteht. Die Farbkugeln im Tab sind ein Ampel System zur schnellen Übersicht. Rot - Kein Download, Gelb - Download aktiv, warte auf Verbindung, Grün - Download läuft.

Bereits gelernte Symbole. Play = Start, Stop = Stop, X = Kill. Optionen wie "ClearallHistory" oder "KillAll" beziehen sich auf alle Instanzen und gehören demnach unter "All". Alle Optionen ab der Navigationsleiste beziehen sich auf die aktuelle Instanz. Der Text rechts beschreibt den aktuell gehoverten Button - nur eine Alternative zum "Text neben Symbol" oder Tooltip. Der leuchtende Ring (noch nicht richtig ausgearbeitet) sollte dann anzeigen das die aktuelle Option aktiv ist. Also wenn ich Stop klicke, leuchtet der Ring so lange bis alles tatsächlich gestoppt ist.

Ich hab mich immer zuerst gefragt warum es "Neu" und "Links" gibt. Von der Logik her kopiere ich meine Links in Links. Daher hab ich einfach das Wording geändert. Bei einem Namen wie "Link-Inspektor" assoziiert man sofort das da was gemacht wird. (z.B. Quelltext reinkopieren und untersuchen lassen).

Weitere Änderungen im Wording. Abgearbeite Links hab ich "History" genannt wie bei z.B. Getright. Die beiden Protokollarten sind unter einem Punkt "Protocol". Innerhalb dieses müsste es dann möglich sein zwischen den beiden Arten "Detailreich" und "Detailarm" zu wechseln. (Falls überhaupt nötig zwei Detailstufen zu haben)

Das einige Dinge fehlen sind mir bekannt, wie gesagt ist es eine frühe Version. Aber da ich schon gesehen habe das die Mastertester Version schwierig umzusetzen war, mache ich mir wenig Hoffnungen das es unproblematisch umsetzbar ist. Zudem hab ich akuten Zeitmangel...leider.


_________________________________________________________________________________________________________
Älterer Beitrag:

Hallo,

ich habe bereits einen unfertigen Entwurf, aber komme nicht umhin konzeptionell ein paar Dinge zu überdenken. Mir ist klar das bei solchen Projekten viele Inkonsistenzen historisch gewachsen ist. Simples Beispiel ist die nicht einheitliche Sprache. "enabled" oben, aber dann wieder "hinzufügen" auf den Buttons. Aber das ist weniger ein Problem.

Jedenfalls ist es wichtig, um die Fragen im Forum niedrig zu halten, das System so einfach wie möglich zu halten und alles aus der Anfängerbrille zu betrachten. Sicher winken die Entwickler ab: "Alles total logisch", aber das sieht man vielleicht nur so wenn man es entwickelt hat und die Story dahinter kennt.

Jedenfalls hab ich erst mal ein paar Fragen:

01: Warum heisst dieser "Filemanager" - FTP?
02: Wozu gibt es zwei Log-Bereiche?
03: Was ist "clearallhistory" und "clearall" ?
04: Ich habe keinen Premium Account, was für einen Unterschied macht diese Checkbox?
05: Was genau bedeuten diese unterschiedlichen Hinzufügen Buttons?
06: Kann man diese Option nicht automatisch immer aktiv lassen ohne dem User eine Wahl zu lassen? Gäbe das einen Nachteil?
07: Ändern sich diese Protokolle auch mal oder ist das eine feste Information?
08: Ganz blöde Frage, warum heißt die Instanz "M" ?

 

[Bifiman]

Gegenfrage: Warum wird das hier "Neues Skin" genannt, wenn du hier doch den alten, ganz normalen, abbildest? Und warum schreibst du das nicht einfach in den vorhandenen FritzLoad Thread?

Was deine Fragen angeht, soweit ich antworten weiß oder vermute:
1. Der heißt vermutlich FTP, da es auf dem FTP Protokoll basiert oder zumindest so ähnlich funktionieren soll.
2. Das eine ist ein sehr rudimentäres Logfile wo sehr viele Einzelheiten aus dem laufenden Betrieb von FL gespeichert sind, das andere listet nur (dafür übersichtlich) den Status der versuchten Downloads auf.
3. Wie es der Name schon sagt: "Clearallhistory" löscht die gesamte "History", das heißt die Logdateien aller Instanzen. "Clearall" löscht die History (Logdateien) sowie alle Linklisten (Links, Fertig)
4. Wenn du kein Premium nutzt, kann dir die Box wohl egal sein. Wenn man Premium Daten eingegeben hat, kann man hier an und abstellen, ob diese genutzt werden sollen.
5. "Hinzufügen" fügt den oder die neuen Links am Ende der aktuellen Linkliste ein. "Hinzufügen Priorität" fügt sie am Anfang der Linkliste ein, so dass sie zuerst geladen werden (vor dem was schon drin war). "Hinzufügen Instanzen" teilt die Links automatisch auf die verschiedenen Instanzen auf, je nachdem wie das in der Config konfiguriert ist (Anbieter<->Instanz).
6. Ich weiß nicht welchen Hintergrund das Ding genau hat, hab ich nie verwendet.
7. Die Protokolle unter "Unterstützte Hoster" ändern sich natürlich durchaus mal, wenn ein Filehoster seine Seite verändert.
8. Weil das die Monitor-Instanz ist (Übersicht über alle anderen Instanzen).

 

[ukvideo]

@chromax
Es ist schon lustig das hier zu lesen.
Du willst

konzeptionell

eine neue Variante Fritzload entwickeln, weil die alte

Inkonsistenzen

hat und hast nicht mal
1. das neuste Relaise
2. die Funktionen überhaupt getestet.

Hier ist eigentlich der richtige Platz für deine Fragen

 

[chromax]

Gegenfrage: Warum wird das hier "Neues Skin" genannt, wenn du hier doch den alten, ganz normalen, abbildest? Und warum schreibst du das nicht einfach in den vorhandenen FritzLoad Thread?

1. Weil ich am neuen Skin bereits konzeptionelle Veränderungen vorgenommen habe und erst mal ein paar Dinge verstanden haben möchte, bevor ich es zeige. Aber ich denke ich zeige es schon so.

2. Weil ich solche Dinge nicht in einen 400 Post langen Thread klären möchte mit hunderten Zwischenposts über völlig andere technische Dinge. Das wäre doch Unsinn.

Ansonsten Danke für die Antworten.

 

[TomTomNavigator]

Da du Webdesign (~und Design im weiteren Sinne) anscheinend beruflich machst (hab mir mal erlaubt mich auf deiner Website ein bisschen umzusehen) bin ich wirklich sehr auf das Ergebnis gespannt, wobei der neue, aktuelle Skin von Mastertester wirklich schon sehr nice ist.

 

[chromax]

@chromax
Es ist schon lustig das hier zu lesen.
Du willst eine neue Variante Fritzload entwickeln, weil die alte hat und hast nicht mal
1. das neuste Relaise
2. die Funktionen überhaupt getestet.

Hier ist eigentlich der richtige Platz für deine Fragen

Schön das ich dich belustigen konnte.

1. Da es hier um grundlegende Funktionalitäten geht ist das unwichtig.
2. Selbstverständlich bin ich Grafikdesigner und kein Entwickler und kenne nicht alles bis ins Detail. Wenn ich keinen Premium Account habe und die Doku löchrig ist, muss ich mir helfen lassen.

Aber genau dafür gibt es ein Forum, nämlich um Hilfe zu bekommen. Denn ich kann nur einen Teil der großen Aufgabe leisten und ohne die Hilfe der Entwickler oder erfahrener User werde ich das nicht schaffen. Aber Leute wie du schaffen es unheimlich einen zu motivieren.

Soweit ich weiß ist das Ticketing System um Fehler zu melden. Und es geht hier nicht um Fehler und Probleme. Aber wenn hier ein Thread offen ist, wird auch niemandem weh getan.

 

[chromax]

Danke, siehe oben. Ne early-beta-nightly 0.02 Version. Ganz früh.

 

[Joe82]

Also, ich finde Mastertesters Skin sehr schön weil er sich so an den orginalen FritzBox Skin anlehnt. Dies fehlt mir bei deinem etwas. Andererseits wäre es dann ja nicht mehr Kreativ, worauf es beim erschaffen von Skins ja ankommt. Insgesamt gefällt mir aber dein Skin sehr gut, da er, zumindest aus meiner Sicht, sehr gute Vereinfachungen mit sich bringt.
Außerdem finde ich es gut das du einen eigenen Tread erstellt hast, denn in dem FritzLoad Tread geht sowas schnell unter finde ich. Allerdings solltest du den Tread nicht einfach neuer Skin nennen sondern dem Skin einen Namen geben. So kann auch später bei Entwicklung eines weiteren neuen Skins noch die Übersichtlichkeit gewährleistet werden.

/OT on
Allgemein finde ich, dass Treads mit mehreren 100 Seiten (Fritz!Load Tread) wenig sinnvoll sind. Da würde eine Unterteilung in Unterpunkte Sinn machen, ähnlich wie es bei Freetz und bei S2F ist.
/OT off

 

[TomTomNavigator]

Nett. Bisschen Apple Einfluss kann man fast erkennen ;-) (im positive Sinne)
Mit der Übersichtlichkeit und Einfachheit ist das eben immer so eine Sache, wenn man Fritz!Load schon seit der ersten Version nutzt findet man sich wirklich super zurecht, aber ich denke Nutzer die erst einsteigen haben ähnliche Verständnisprobleme wie du, chromax. Deshalb finde ich den selbsterklärenden Aspekt wirklich genial. Mal abwarten was da noch so kommt.

 

[Ceikor]

Ist zwar schon etwas älter der Thread aber wollt mal fragen wie weit du bist? Mir persöhnlich gefällt dieses Skin auch und sieht auch übersichtlicher aus.

 

[chromax]

Sorry, aber durch Umzug und Arbeit ist es mir etwas aus dem Fokus geraten. Ich werde versuchen etwas Zeit zu finden. Die aktuelle frischzellenkur finde ich nicht schlecht, daher hab ich das etwas vernachlässigt.

Ich hab auch noch keinen Plan wie ich es umsetzen muss, damit es funktioniert. Was ich aus den bisherigen Threads lesen konnte ist die GUI fest verdrahtet und nicht so einfach zu ersetzen.

 

[TelefonSparbuch]

Hallo chromax,

bin jetzt erst auf diesen Thread aufmerksam geworden.
Es gibt noch so vieles, was verbessert und vereinheitlicht werden müsste. Da wir eine etwas beschränkte Programmierumgebung haben, ist nicht alles so simpel umzusetzen, wie man es in anderen Programmiersprachen gewohnt ist.

Generell sollte man eine einheitliche Sprache und Symbolik absprechen, die möglichst in allen Skins abbgebildet wird. Deutsch und Englisch ist zu sehr vermischt.

Eventuell soll das Projekt lokalisiert werden (aber wer pflegt dann die Sprachfiles), wie soll es umgesetzt werden (Ausgaben mit printf, so dass auch Wortumstellungen bei Variableneinbettungen möglich sind...?) - auf jeden Fall noch mal viel Arbeit bis das Gerüst dafür steht...

Derzeit wird der Logstatus aus der Logdatei via Javascript erstellt. Wenn nun ein neuer Skin auf Flash setzt, so ist die Frage ob die Javascript Bibliotheken noch verwendet werden können.

Generell würde ich eher auf einen HTML Skin setzen (von der Bedienung empfinde ich mittlerweile den Keule Skin als gelungener). Das hätte den Vorteil, dass Verbesserungen allen Skins zu gute kommen - auch die Frage wieviele Layout-Skins wir benötigen (da diese zum Teil getrennte Sourcen haben - die gepflegt werden müssen). Mir wäre lieber vielleicht nur 2 Layouts zu unterstützen, oder besser nur einen flexiblen CSS/Javascript Skin, wo die Designer sich in den CSS/Script Dateien austoben dürfen.

Das mit den Instanzen war aus der Not geboren und hat sich als recht hilfreich erwiesen. Darauf aufbauend könnte man nun auch über eine Instanz nachdenken, die die Prozesse steuert, die mit warten beschäftigt sind und die Prozesse die Downloaden (entsprechend auch die Hosterdownloads verteilt...). Eine 7390 kommt ohne weiteres mit 8 aktiven Instanzen zurecht. Entsprechend könnte man die Logik im Skin überdenken.

Die Fehlermeldungen müssen unbedingt vereinheitlicht werden, hier macht derzeit jedes Hosterplugin wie es gerade beliebt (da müsste man sich über passende Fehlercodes oder passende Lösungen absprechen, die die bekannten Fehler abbildet).

Dann auch die Frage ob man das Projekt nicht auch auf weitere Hardware Umgebungen anpassen kann (Linux/Apache, ...) um dadurch den Entwicklerkreis zu erhöhen...

 

[chromax]

;-)

Eines vorweg, ich möchte keine tote Technik (Flash) für die GUI einsetzen. Das ist ein Wireframe und Flash hilft nur es zu animieren und Abläufe besser verständlich zu machen. Ich hätte auch mit Papier und Bleistift arbeiten können und alles textlich festhalten können. Aber gerade dynamische Dinge muss man sehen und man selbst entdeckt auch oft Denkfehler in Abläufen. Daher greife ich für Wireframes zu Flash. Das Endergebnis wird natürlich HTML5 und jQuery.

Ich denke auch das die Abstimmung eines der größten Probleme ist. Wir sitzen ja nicht in einem Raum und arbeiten 8 Stunden am Projekt. Ich kann aus meiner Perspektive nur frische Ideen vorgeben (zur diskussion), Designs liefern und ein CSS Frontend schreiben. Aber das Ding zum Leben bringen ist schließlich weitaus komplexer. Ein getrenntes Skin mit CSS wäre (wie bei nahezu allen Programmen mit Themes) die beste Lösung. Vielleicht wird das Skinning für fritzLoad für viele Interessanter, wenn die Hürden klein sind.

Die Instanzen könnte man kippen, wenn man in der Hauptübersicht die Downloads (wie bei JDownloader) in Gruppen fassen könnte. Schön wäre dann auch eine automatische Gruppierung nach Hoster, Größe, Dateiname. Was dann aber wichtig wäre (das fehlt JD) ist eine Schnellfilter-Funktion um alle aktiven Download schnell zu erfassen ohne sich durch Gruppen zu wühlen.

Gut, über die technische Basis kann ich nichts sagen.

 

[roadman17]

Dass du Flash nur verwendest um schnell etwas visualisieren zu können, habe ich mir schon gedacht.
Meiner Meinung nach braucht man auch keine Instanzen. Sie waren nur eine schnelle Möglichkeit um parallele Downloads einzubauen. Außerdem können sie für zeitgesteuerte Downloads sorgen, um Happy Hours und so was auszunutzen. Das könnte aber auch alles mit einer zentralen Downloadliste gehen, die dann aber vermutlich nicht mehr eine einfach Textdatei mit Links ist, sondern auch Zeitangaben, Prioritäten und Ähnliches enthalten kann.
Wie es aussieht willst du die Logik der Oberfläche verändern. Für die Realisierung wäre es günstig ein nahezu fertiges Ziel vor Augen zu haben und danach erstmal die wichtigsten Funktionen umzusetzen. Da dies unter Umständen länger dauert, kann die neue Oberfläche zusätzlich zur aktuellen erstellt werden und erst wenn sie fertig ist, die "alte" Oberfläche entfernt werden.

 

[TelefonSparbuch]

Vermutlich wird man die Instanzen beibehalten, nur eben sind die Instanzen nicht mehr fest bestimmten Hostern zugeordnet (es gibt x Instanzen die parallel agieren dürfen und y Instanzen, die aktiv download dürfen). Solch eine Lösung ist mit einigen Signaldateien schnell umgesetzt (oder jeder Hoster bekommt eine eigene Instanznummer). Das birgt auch einige Nachteile, aber in anbetracht der Möglichkeiten der Bash vermutlich am einfachsten zu überschauen und der Programmcode der geändert werden muss ist gering.

Um sich an die Funktionalität des neuen Skins heranzutasten, muss man sicherlich auf beiden Seiten einiges an der Logik und unter Umständen auch an den internen Abläufen was ändern. Daher sollte wir die einzelnen Punkte festhalten und vielleicht getrennt diskutieren um den Überblick zu wahren. Eventuell wäre es praktischer dafür in ein anderes Forum zu wechseln (Sourceforge-Projekt hat ein eigenes Forum - kenne aber dessen Schwächen nicht) oder dies in das Ticket-System auszulagern.

 

[Joe82]

Ich habe mal ein paar Anmerkungen zur Koordintion:

Ich würde es gut finden, wenn es hier im Forum einen eigenen Unterpunkt unter Modifikationen für Fritz!Load geben würde. Denn ein 300 Seiten Tread hilft niemandem. Ein Unterforum sollte doch nicht so schwierig zu erstellen sein. So könnte man auch weiterhin hier im Forum diskutieren und Ergebnisse festhalten.

Freetz bietet die Möglichkeit einen uMurmur Server laufen zu lassen. So hätte man einen Gratis Server auf dem alle erstmal miteinander Sprechen können um eine klare Linie zu haben. So könnte man denke ich auch die Umsetzung erheblich beschleunigen. Die Absprachen könne man danach ja immer noch im Forum festhalten. Aber eventuell hilft das.

LG Joe

 

[TelefonSparbuch]

Da es derzeit Überlegungen gibt, das Download-Modul abzuändern (Paralleler Download über ein zentrales Modul), steht auch die Datenhaltung zur Debatte. Entsprechend wäre es gut, wenn möglichst alle Ideen und Vorschläge über benötigte Daten für eine neue Oberfläche auch hier festgehalten werden: https://sourceforge.net/apps/trac/avmload/ticket/1482