[xwiki-dev] Proposal for full-editing mode

[Laurent Lunati]

Hello,

another idea :

a css swicther

The new css will hide all other element and reorganize the layout


laurent

Le 25 juin 07 à 16:08, evelyne24 at gmail.com a écrit :

> Hello all,
>
> First of all, thank you for your replays and please forgive my  
> short absence....I was left without electricity and Internet for a  
> few days because a  short storm.
>
> Sergiu has given me the task to implement a fullscreen editing  
> mode, similar to WYSIWYG or WIKI and I thought about it and found  
> several solutions,
> each one with advantages and disadvantages.
> I will present them now and I would like to receive some feedback  
> from you, to know which of the solutions
> (or maybe other solution if none of mines is good enough) will be  
> better.
>
>
> Ideeas for a new way of editing in xwiki (like WYSIWYG and WIKI in  
> FULLSCREEN)
>
> ---------------------------------------------------------------------- 
> -----------
>
> Ideea no. 1: A button in the editor itself, like in FCK editor
>
> ---------------------------------------------------------------------- 
> -----------
>
> Sample here: http://www.fckeditor.net/demo   (the one next to Help  
> button)
>
> Advantages:
>
> 1. it doesn't need any other graphical implementation in xwiki  
> (like a new tab for instance), because xwiki has already 2 rows of  
> tabs
>
> 2. with a good, expressive icon it can be easily spotted by the user
>
> 3. it's very easy and intuitive to use, even for a non-initiated  
> user (specially with a tooltip); the user can use tabs to move to  
> the button, if he doesn't have a mouse
>
> 4. it can appear anywhere the editor toolbar is needed, therefore  
> allowing full editing for all those cases (not only for wysiwyg and  
> wiki...)
>
> 5. can be more impressive with a nice transition animation
>
> 6. it covers all the area in xwiki (no elements visible like  
> panels, header etc, otherwise it will not be fullscreen editing, it  
> will be just like
> the existing WYSIWYG editing mode)
>
> 7. by reducing the size of the textarea, the user is brough back to  
> normal wysiwyg editor and has access to other elements in  
> xwiki...like panels...
> just like in the existing editing mode.
>
> Disadvantages:
>
> 1. it's depedent of the editor toolbar
>
> 2. in order to save or cancel or save and continue, the user has to  
> reduce the size by pressing the same button and then press the  
> submit button(save, cancel...)
>
>
>
> ---------------------------------------------------------------------- 
> -----------
>
> Ideea no. 2: Two small buttons, in the corner of both WYSIWYG and  
> WIKI editor, just like in Gmail (composing), which opens a new  
> fullscreen window with
> the editor, the textarea and save, cancel...buttons
>
> ---------------------------------------------------------------------- 
> -----------
>
> Advantages:
>
> 1. the user can have acces to other xwiki elements (panels...) in  
> the parent window
>
> 2. independent of the editor itself
>
> 3. pretty intuitive to use
>
>
> Disadvantages:
>
> 1. when the new window is opened, the parent window must be  
> redirected to the view mode -> reloading the page
>
> 2. if the user clicks cancel, to edit again he must press Edit  
> (WYSIWYG or WIKI) and then press the little button on the tab -> 2  
> reloadings
>
> 3. what happens if the user opens twice the same editor? the  
> modifications from one must be seen in all other open editor ->  
> quite difficult to implement
>
> 4. harder to implement
>
> 5. a button like this can be placed in each tab (wysiswyg and wiki)  
> and it a new tab is added in xwiki which supports full screen  
> editing, the button
> has to be place in it too.
>
>
> ---------------------------------------------------------------------- 
> -----------
>
> Ideea no. 3: Resizable textarea
>
> ---------------------------------------------------------------------- 
> -----------
>
>
> Advantages:
>
> 1. the user can resize the textarea as much as he wants, not  
> necessarily fullscreen
>
> 2. pretty easy to use, but only if the user has a mouse to drag the  
> textarea
>
>
>
> Disadvantages:
>
> 1. the resizing of the textarea can damage the xwiki interface (all  
> the page has to be resized) -> pretty nasty distorsions
>
> 2. the user will have to scroll down a lot to see the footer if the  
> textarea is resized a lot.
>
>
>
> ---------------------------------------------------------------------- 
> -----------
>
> Ideea no. 4: Like the no. 1 except that when pressed, the button  
> will open a floating pane with a nice animation, that will cover  
> about 60% -70% of the page
> which will contain only a resizable textarea, the editor and the  
> save, cance,..buttons, while the rest of the page will be covered  
> by a translucent blocking background (similar to those which appear  
> when you have to fill in the username and password in order to  
> access something).
> When the user finishes editing and presses one of the buttons, the  
> panel closes and the text is put back in the tab from which the  
> editor button was pressed
> (i.e wysiwyg or wiki or other tab that has the editor)
>
> ---------------------------------------------------------------------- 
> -----------
>
> Advantages:
>
> 1. advantages of no. 1 and the fact that will be more spectaculous  
> (with a nice effect)
>
>
> Disadvantages:
>
> 1. same as no. 1 (dependent of editor etc..)
>
>
> So, these are my ideas for now... I would like to know which seems  
> more appealing to you and also, if you have other opinions, ideeas...
>
> Thanks,
>
> Evelina Slatineanu
>
>
>
>
> --
> You receive this message as a subscriber of the xwiki- 
> dev at objectweb.org mailing list.
> To unsubscribe: mailto:xwiki-dev-unsubscribe at objectweb.org
> For general help: mailto:sympa at objectweb.org?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/ 
> wws

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xwiki.org/pipermail/devs/attachments/20070626/484be837/attachment.html