[JS] Image geen valid drop target in IE > 5.0?

[B-Man]

Hallo,

Context: HTML WYSIWYG editor m.b.v. de designmode property van IE.

Probleem: In IE 5.0 (standaard win2k install) kan ik een plaatje over een ander plaatje draggen, en krijg dan netjes de "valid-drop-target"-cursor: pijltje, vierkantje en een plusje geloof ik.
In IE5.5 en IE6.0 werkt dit niet meer. Als ik een plaatje over tekst drag krijg ik de valid cursor, als ik nu echter over een ander plaatje drag, krijg ik een invalid-drop-target cursor? (cirkeltje met lijn erdoor).

Aangezien ik niet aan ieder element in mijn editor een ondragenter wil koppelen, heb ik een ondragenter gekoppeld aan het BODY element in mijn editor. Deze wordt ook getriggerd als ik over een child van het BODY element drag.

Met google geen bruikbare resultaten over dit onderwerp. MSDN biedt ook geen oplossing. Ik heb gezocht op "ie ondragenter image" "ie drag image" "ie valid drop" enz, zonder een antwoord te vinden op mijn vraag.

Weet iemand hier een oplossing voor?

[Bosmonster]

Ehh.. leg ook eens uit wat je ermee wilt? Waarom wil je een plaatje in een editor op een ander plaatje draggen.. de logica ontgaat me even.. vooral vanuit gebruikersperspectief dan

[WvdWest]

Ik ben het met Bosmonster eens. Sterker nog, ik denk dat dit een "bug" is die eruit gehaald is. Zo voorkom je dat je een plaatje over een ander plaatje plakt. Je zal dus eerst het oude plaatje moeten verwijderen. Bescherming van de gebruiker.

[B-Man]

De editor laat de gebruiker "tags" naar plaatjes en links slepen. Achter de schermen worden de tags visueel getoond door plaatjes. Bij het opslaan van het document vervangt de editor alle plaatjes van tags door de daadwerkelijke tags.

Werkt een stuk gebruiksvriendelijker dan letterlijk de tags kloppen, en de kans op fouten is veel kleiner.

Maarre: terug naar mijn vraag: ik wil een "tag" dus ook in IE >5.0 op een plaatje kunnen droppen, om er achter de schermen een van mijn tags aan toe te kennen.

[B-Man]

WvdWest: waarom zou dit een "bug" zijn: tuurlijk, _standaard_ moet hier een "no drop" cursor verschijnen, maar waarom zou een programmeur dit niet kunnen overriden?

Zoals je in mijn vorige post kunt lezen heb ik een valide reden om dit te willen. Feitelijk drop ik het plaatje niet, maar voeg ik een plaatje in direct voor het drop target. Maar ja, die actie moet ik natuurlijk wel kunnen triggeren...

[Bosmonster]

hehe.. een soort What-You-See-Is-Far-From-What-You-Get editor? Vreemd interactie model als je het mij vraagt.. maar goed ik heb geen oplossing voor je probleem (tenzij je probleem je vreemde interactie model is )

(een gebruiker die 'tags', waarvan een gebruiker dus al niet eens weet wat het zijn, moet 'slepen', wat een ongebruikelijke actie is voor een onervaren gebruiker, naar dingen waar die wat mee gedaan wil hebben).

Het idee van dat een tag 'om' een element heenstaat is voor jou als html-kundige misschien logisch, als gebruiker is dat compleet onlogisch. Die wil van een plaatje of stukje tekst gewoon een link maken. Dus hetgene selecteren waar die wat mee wil en vervolgens een knop indrukken om er iets mee te doen.

Jaja.. interaction design is vaak veel simpeler dan je denkt

[ Voor 60% gewijzigd door Bosmonster op 30-05-2003 15:26 ]

[B-Man]

Waarom vreemd? Het werkt in mijn ogen juist intuitief:
Stel: de gebruiker wil een hyperlink toevoegen aan een plaatje. Wat denk je dat ze liever doen:
a) schakelen naar de broncode mode, plaatje opzoeken, hyperlink eromheen zetten (als ze al weten hoe dat moet)
of
b) sleep het hyperlink icoontje vanuit de toolbar naar het image, drop, en voila, er staat een hyperlink omheen...

Aangezien dit -zeker in deze context- erg handig is, wil ik dit gewoon kunnen maken. Ik vind het werkelijk _krom_ als dit niet meer mogelijk zou zijn in IE > 5.0.

Om het wat visueler te maken even een voorbeeld met drag&drop naar een hyperlink:
Stap 1, drag icoontje vanuit toolbar (wit opgelicht):


Stap 2, gedropt op een hyperlink, icoontje verschijnt netjes ernaast. Tevens kan de tag nu bewerkt worden door deze aan te klikken. Het is dus echt een UI-element van de editor, niet "zomaar" een plaatje.

[ Voor 5% gewijzigd door B-Man op 30-05-2003 15:34 ]

[Bosmonster]

Uhh.. je vergeet de mogelijkheid om gewoon het plaatje aan te klikken en er een tag van te maken

Nadelen van 'jou' methode:

- drag/drop is niet intuitief voor onervaren gebruikers. Zeker als je naar tekst wilt draggen Moet je dan eerst wat selecteren en dan ernaar draggen ofzo
- Je hebt geen WYSIWIG meer, want je ziet allerlei voor de gebruiker nutteloze informatie (iconen) in je content staan.
- Een gebruiker denkt niet in 'tags' en die 'markers' voor tags zeggen hem dus niks.
- drag/drop acties.. dus je moet eerst wat selecteren, dan wat draggen en droppen en dan weer klikken om te wijzigen. Al die acties kun je samenvatten in: selecteren en klikken op de normale methode. Scheelt je als gebruiker een hoop acties dus

[ Voor 20% gewijzigd door Bosmonster op 30-05-2003 15:38 ]

[B-Man]

Bosmonster schreef op 30 mei 2003 @ 15:23:
hehe.. een soort What-You-See-Is-Far-From-What-You-Get editor? Vreemd interactie model als je het mij vraagt.. maar goed ik heb geen oplossing voor je probleem (tenzij je probleem je vreemde interactie model is )

(een gebruiker die 'tags', waarvan een gebruiker dus al niet eens weet wat het zijn, moet 'slepen', wat een ongebruikelijke actie is voor een onervaren gebruiker, naar dingen waar die wat mee gedaan wil hebben).

Het idee van dat een tag 'om' een element heenstaat is voor jou als html-kundige misschien logisch, als gebruiker is dat compleet onlogisch. Die wil van een plaatje of stukje tekst gewoon een link maken. Dus hetgene selecteren waar die wat mee wil en vervolgens een knop indrukken om er iets mee te doen.

Jaja.. interaction design is vaak veel simpeler dan je denkt

hmmm, dat zijn we dan niet met elkaar eens... Kijk: ik -als programmeur- noem het "tags", voor de gebruiker hebben de beestjes andere namen:
"te monitoren link opnemen"
"verwijzing naar aanmeldingsscript"
"link om gegevens te wijzigen"
...etc...

Dit is een front-end voor een systeem waarachter een java server draait die de "tags" vervangt door content.
[link id=345] wordt vervangen door een lap content.

Om nu de gebruiker letterlijk [link id=345] te laten typen vind ik absoluut niet gebruikersvriendelijk. De id=345 is een database id, die code _zien_ ze niet eens.

Daarom is dit in mijn ogen dus veel handiger: willen ze dat een klik op een plaatje geregistreerd wordt, dan slepen ze er een "registreer kliks" icoontje naar het element dat gemonitored moet worden.

Er zit een berg functionaliteit achter van jewelste, waar de gebruiker wel toegang toe wil hebben, en moet kunnen hebben, maar de tekstueel veel te complex wordt om met de hand te bewerken. Vandaar deze oplossing.

Maar goed, ik wijk helemaal van het probleem af.

[Bosmonster]

Je bent me kwijt wat dat betreft...

Kun je geen container om de image zetten, zodat je misschien dragt naar een span ipv een image?

[B-Man]

Bosmonster: dat zal allemaal wel, maar uit ervaring blijkt dat gebruikers dit een hele vooruitgang vinden ten opzicht van de methodieken die jij beschrijft, ja "been there, done that".

Als ik niet voor ze visualiseer dat link A wel gemonitored wordt, en link B niet, hoe moeten ze dan ooit zien of een link gemonitored wordt? Enige manier is dan de broncode bekijken, en daar snappen ze vaak helemaal niets van.

Volgens mij snap je mijn systeem niet helemaal, a la, nog een concreet voorbeeld dan

Men neme een link:

code:

<a href="blabla.html">dit is een link</a>

De gebruiker wil dat het systeem een klink op deze link registreert... Dat betekent dat er een complexe URL opgegeven moet worden, naar een script dat de kliks registreert.
De gebruiker kent deze link niet, en kan deze dus niet handmatig invoeren.
Oplossing:

code:

<a href="[link id=345]">Dit is een link</a>

De javaserver vervangt deze "tag" automatisch door de gewenste hyperlink.

Ik doel dus niet op HTML-"tags", maar custom tags "[tag xyz]".
Aangezien deze _in_ de HTML code staan, en voor de gebruiker cryptisch zijn, geef ik ze visueel weer m.b.v. icoontjes. De gebruiker kan vervolgens op zo'n icoontje klikken, aangeven dat er (bijvoorbeeld) toch niet naar "blabla.html" doorverwezen moet worden, maar naar "bla2.html", de tag wordt automatisch bijgewerkt (bijvoorbeeld [link id=346]).

Hoop dat het zo wat duidelijker is.

[B-Man]

Bosmonster schreef op 30 May 2003 @ 15:44:
Je bent me kwijt wat dat betreft...

Kun je geen container om de image zetten, zodat je misschien dragt naar een span ipv een image?

Misschien dan mijn post hierboven wat verhelderend werkt?

Wat ik wil voorkomen is dat ik onnodige HTML toevoeg, aangezien ik deze bij het opslaan van het document weer eruit moet zien te filteren, het is immers extra code voor de editor, die niets te maken heeft met de HTML van de gebruiker.

Kijk: de gebruiker wil een mail opmaken (het is een mail-systeem), plakt HTML code opgemaakt in een andere editor in deze editor, en sleept wat icoontjes om "systeem-hotspots" aan te geven: welke zaken moeten door het systeem vervangen worden? Zo zie je in mijn screenies ook personalisatie "tags".

[B-Man]

Hier nog een screenshot van de editor als ik mijn "tag"-herkenning uitzet, dan zie je het verschil:



Zoals je ziet, is de kans op typefouten groter voor bijvoorbeeld personalisatie: stel dat ze ipv "voornaam" "voornam" typen: het werkt niet, help! Nu droppen ze gewoon de personalisatie-tag, en het werkt.
Tevens zie je hier een "blote" (haha) [link]-tag. Nogmaals, uit ervaring blijkt dat de gebruiker liever het icoontje ziet, erop kan klikken, en dan in de toolbar wijzigingen kan aanbrengen, dan dat ze naar een stukje tekst kijken dat ze niet snappen.

[B-Man]

Naja, door al dat uitleggen (pff haha) ben ik erachter hoe ik het wel kan laten werken....

tadaaa:

Door ook onDragOver af te vangen, en hier het standaard gedrag uit te schakelen...
(in code: de returnValue property van het event op false instellen).

-- Overigens nog even voor de goede orde (ahem):
Er zit een uitgebreide handleiding bij de editor, die de icoontjes verklaard. Tevens zijn er niet zoveel acties nodig als bosmonster eerder noemde om een tag te "plaatsen" en zit een functie achter onDrop die op een intelligente manier bepaald waaraan een tag gekoppeld moet worden. De code is zelfs in staat om een hyperlink te plaatsen, indien dit nodig is voor een correcte werking van een tag. Als klap op de vuurpijl wordt de gebruiker ook nog netjes gevraagd of dit gedaan mag worden.

[ Voor 52% gewijzigd door B-Man op 30-05-2003 16:13 ]