Party , Bars und Diskotheken ???
Rico
- meinung
Hallöchen,
würde mich über eine Bewertung freuen, negative Kritiken bitte mit einem WARUM bzw. Verbesserungsvorschläge. Wer keinen Bock hat, wechselt einfach zu nächsten Thread :-)..
Cu Rico
[link]http://www.kadiba.de/party/[/link]
..uups, det war wohl nix
der link ist besser:
-> Kaum macht man's richtig, dann gehts :-)
Hi,
der link ist besser:
-> Kaum macht man's richtig, dann gehts :-)
Jo, dann steigt auch die Lust zum hinklicken >:)
Aus dem Bauch heraus:
1. Inhalt
a) Bilder: Warum sind die Eingangsbilder so....besoffen?
Es gibt einen haufen Leute, die auch ohne gestauchten oder
gezerrten Blickfeld Spass haben :)
b) Für eine partyseite fehlt das absolut wichtigste:
Wo sind die Szene-News? Die Gerüchteküche?
Ohne sowas ist das nichts weiter als ein Terminkalender.
2. Design/Technik
a) Ieeehh.. Frames. Alte Technik...Ist denn schon wieder 1998 ?
Wozu tust du den Seiten das an?
b) Es fehlen ausreichend Metatags.
c) Es gibt keine robots.txt
d) Es gibt kein FavIcon
e) Dein Impressum ist nicht ausreichend und daher abmahngefährdend
f) Vali mag dich nicht: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.kadiba.de%2Fparty%2F&doctype=HTML+4.01+Frameset&charset=iso-8859-1+(Western+Europe)
g) Bei den festen wird beim Anklicken eines Festes ein neues Fenster
mit selbigen Inhalt geöffnet. Sieht wie ein Bug aus.
Mehr fällt mir auf Anhieb nichte in.
Ciao,
Wolfgang
Hi,
zu 1a) Designerbilder :-)
zu 1b) kommt doch noch alles, dazu benötigt man doch Moderatoren die aus der stadt kommen. erstmal starten und dann ausbauen !
zu 2a) bei frames gehen die meinungen eeeh auseinander. mich nervt bei den "modernen" framelosen seiten, das die menueeinträge beim scollen dann immer oben sind, also nich immer verfügbar. aber das ist nicht das einzige. die technik wird in 2 jahren wieder der hit sein, genau wie die plastischen buttons. so ist das doch immer
zu 2b) mag sein, google reagiert eeh nicht drauf
zu 2c) kommt alles noch, hat ja noch keine eigene domain
zu 2d) ist ne gute idee, jedenfalls für den IE
zu 2e, 2f) danke für den Tip
zu 2g) jo, ist noch kein link in der db drin, die seite wird noch verändert
Hi
zu 2a) bei frames gehen die meinungen eeeh auseinander. mich nervt bei den "modernen" framelosen seiten, das die menueeinträge beim scollen dann immer oben sind, also nich immer verfügbar.
Stört es _dich_ oder deine Besucher? Muss ein Menü denn immer sichtbar sein und so wertvollen Bildschrim-Platz einnehmen?
aber das ist nicht das einzige. die technik wird in 2 jahren wieder der hit sein, genau wie die plastischen buttons. so ist das doch immer
Ist es relevant, welche Technik der "Hit" ist? IMHO kommt es darauf an, dass mit der jeweiligen Technik der Inhalt am besten transportiert werden kann. Das können Frames IMO nunmal nicht (mehr?) so gut wie andere Techniken.
Fabian
Hallöle
Stört es _dich_ oder deine Besucher? Muss ein Menü denn immer sichtbar sein und so wertvollen Bildschrim-Platz einnehmen?
Als Designer geh ich erstmals immer von mir aus und dann erfrage ich (wie z.B.) hier die Meinungen anderer. Es ist z.B. besser das Menü und das Login immer sofort zur Verfügung zu haben um ein ständiges hin und herscrollen zu Vermeiden. Die Ausrede, die Browser unterstützen es nicht, zählt auch nicht mehr. Es muss nicht ständig nachgeladen werden (wobei das wohl die browser mit dem chache allein managen). Wir haben keine Menüanpassungen, so dass es auch unsinnig wäre, ständig das menü bzw. pix zu laden. der Druckbereich pro frame unterteilt, wer will schon das menü auf dem ausdruck bzw. es müssen keine extra druckseiten generiert werden. mir fallen da noch mehr vorteile ein, leider kein nachteil.
Ist es relevant, welche Technik der "Hit" ist?
Wieso Technik? Gestaltung, Design und Raumaufteilung, davon ist doch die Rede oder? Technik ist HTML, CSS, Javascript, TCP/IP und Java
IMHO kommt es darauf an, dass mit der jeweiligen Technik der Inhalt am besten transportiert werden kann. Das können Frames IMO nunmal nicht (mehr?) so gut wie andere Techniken.
Versteh ich nicht. Transportiert wird alles gleich, HTML mit TCP/IP, nur das der Browser auf unserer Eintiegsseite 4 HTML-Seiten laden muss, bei einer normalen nur 1 HTML-Seite, dafür aber die Datenmenge für darauf folgende Seiten reduziert wird. Ist aber eeh bei den Datendurchsätzen unerheblich.
Hallo rico,
Es ist z.B. besser das Menü und das Login immer sofort zur Verfügung zu haben um ein ständiges hin und herscrollen zu Vermeiden.
In welcher logischen Relation/Verbindung stünden die Menüeinträge mit dem jeweiligen Dokument?
Es muss nicht ständig nachgeladen werden
Wie löst du das Problem der eindeutigen Quellenbezeichner (daraus entstehen die Link- und Bookmarkprobleme)?
Wie verhinderst du, dass die Dokumente außerhalb des Framesets aufgerufen werden - willst/musst du es überhaupt verhindern oder sind die Dokumente gewissermaßen »selbstgenügsam«? Was zum Henker mache ich auf diesem Planeten? Wie definierst du in deinem Projekt »Ressource«, wie ist ein Unterdokument in den Kontext der Site eingebunden? Wie löst du Sekundärnavigationen und mehr als einfach untergeordnete Rubriken?
Wir haben keine Menüanpassungen
Wie sieht die Verzeichnisstruktur deiner Site aus? Was davon bildet das genannte Menü ab? Wie gibst du dem Besucher Orientierung, wie erkennt der Besucher die aktuelle Position?
es müssen keine extra druckseiten generiert werden.
Folglich sind die Dokumente außerhalb ihres Kontexts vollständig?
mir fallen da noch mehr vorteile ein, leider kein nachteil.
http://www.subotnik.net/html/frames.html
http://www.greatbelow.de/html/frames.html#C3
http://www.guppi.de/frames.shtml
</archiv/2002/10/27370/>
</archiv/2002/10/27752/#m150924> und Links
nur das der Browser auf unserer Eintiegsseite 4 HTML-Seiten laden muss
Welche Aufgabe haben die drei Frames?
bei einer normalen nur 1 HTML-Seite, dafür aber die Datenmenge für darauf folgende Seiten reduziert wird.
Wie würde deine Navigationsstruktur auf Unterdokumenten aussehen, wie würdest du die Sitehierarchie abbilden? Wie begegnest du Clients/Hypertextagenten, welche Frames aus Bedienbarkeitsgründen deaktiviert haben oder sie komplett nicht unterstützen? Wie sieht der Navigationspfad in diesem Falle aus?
Grüße,
Mathias
Hi!
Als Designer geh ich erstmals immer von mir aus und dann erfrage ich (wie z.B.) hier die Meinungen anderer. Es ist z.B. besser das Menü und das Login immer sofort zur Verfügung zu haben um ein ständiges hin und herscrollen zu Vermeiden. Die Ausrede, die Browser unterstützen es nicht, zählt auch nicht mehr.
Es gibt CSS postition:fixed um Elemente im Ansichtsfenster zu fixieren. Nur versteht es eine einzige Browserengine von 5 (KHTML,Gecko,Opera,ICEBrowser,IE) nicht, nämlich der IE.
der Druckbereich pro frame unterteilt, wer will schon das menü auf dem ausdruck bzw. es müssen keine extra druckseiten generiert werden.
Quatsch. Dafür gibt es CSS. Du kannst unterschiedliche CSS für unterschiedliche Ausgabemedien definieren. Für Printmedien setzt du halt die display-Eigenschaft des Menüs auf none.
Im übrigen werden sich Benutzer von nicht framefähigen Benutzeragenten sehr freuen, das man keine Navigation zur Verfügung hat.
Ist es relevant, welche Technik der "Hit" ist?
Wieso Technik? Gestaltung, Design und Raumaufteilung, davon ist doch die Rede oder? Technik ist HTML, CSS, Javascript, TCP/IP und Java
Und Frames sind seit XHTML1.0 Strict per default nicht mehr Teil der HyperText Markup Language.
Gruß Herbalizer
Hallo Herbalizer,
Und Frames sind seit XHTML1.0 Strict per default nicht mehr Teil der HyperText Markup Language.
Worauf willst du hinaus? Frames waren nie Bestandteil der Strict-Variante von HTML. XHTML 1.0 besitzt eine Frameset-Variante und eine Transitional-Variante, welche auf Frameset-Unterseiten verwendet werden kann (aufgrund des target-Moduls). Ein XHTML 1.0-Frameset kann »strictly conforming« sein. Ich wüsste nicht, was sich zwischen HTML 4 und XHTML 1.0 diesbezüglich geändert haben sollte. Frames sind weiterhin unter denselben Bedingungen wie vorher offiziell Teil der (nun Extensible) Hypertext Markup Language. Es gibt im Grunde nicht *eine* Hypertext Markup Language, es gibt verschiedene gleichwertige und untereinander mehr oder weniger kompatible und im Web verwendbare. Selbst wenn XHTML 2 und XFrames erscheinen, sind die dann obsoleten HTML 4- beziehungweise XHTML 1.0-Frames weiterhin ein Bestandteil der Hypertext Markup Language, es wird weiterhin Autoren geben, welche diesen Recommendations gemäß Dokumente verfassen und weiterhin authoring tools und user agents geben, welche diese Technik unterstützen.
Mathias
lange Rede kurzer Sinn: genau wegen dieser ungereimtheiten habe ich versucht rauszubekommen ob es nur Modeerscheinungen sind. Der einzige Nachteil den ich bisher bei Frames rauslesen konnte, entsteht beim zugriff über suchagenten, aber das klappt bei z.B. google wunderbar (Frameset steht immer als erster sucheintrag).
Hallo Fabian,
Muss ein Menü denn immer sichtbar sein und so wertvollen Bildschrim-Platz einnehmen?
Sofern dies eine argumentative Frage sein soll, womit argumentiert sie? (»Zahlen wir nicht schon genug Steuern?!«)
IMHO kommt es darauf an, dass mit der jeweiligen Technik der Inhalt am besten transportiert werden kann. Das können Frames IMO nunmal nicht (mehr?) so gut wie andere Techniken.
Wieso und in welcher Hinsicht können sie es nicht? Was meinst du mit »transportieren«? Auf welchen Inhalt trifft das zu? Wieso eventuell »nicht mehr«? Was hat sich geändert?
Mathias
Hallo Mathias,
Wieso und in welcher Hinsicht können sie es nicht? Was meinst du mit
»transportieren«? Auf welchen Inhalt trifft das zu? Wieso eventuell »nicht
mehr«? Was hat sich geändert?
Definiere »geändert«!
MI
...
Was hat sich geändert?
Definiere »geändert«!
I. »Weißt du noch wie's früher war? / Früher war alles schlecht. / Der Himmel grau, die Menschen mies / die Welt war furchtbar ungerecht.«
II. »You feel a shaking on the ground / A billion candles burn around / Is it your birthday?«
III. »You could be sitting taking lunch«.
M.