Menu
▾
▴
Re: [Tiki-devel] Done : New modes to manage wiki pages - to be shown and viewed in ui, need probably some help before commit 10.x
|
From: Bernard T. <bty...@tr...> - 2013-02-28 00:33:40
|
Hi,
jonny, LP
As I began to tell about to LP (answered yesterday), we have not the
same view of problems not on solution.
I have a view reflected from users and some ergonomics proposals (and
demo), you think about the strategy of the development and about the
technical tools.
We don't tell about the same things, with not well defined roles (for me)
For future I agree completely with jonny answer about tools and the
implicit induced ergonomy.
But the problem that I have is :
-------------------------------
- the users say "edit" wiki page is nothing done, edit is Ok (not full
Wysiwyg with remaining bugs but never mind), but we don't know what we
edit, we cannot have a way of work in updating documents from
admin-structures, list of pages or others.
The lonely quite available mode is to showpages and edit the save which
goes back to top of structure need to show the new page (from where ? we
have to note on a paper... when we work systematically for a review)
- when you edit a wiki page you have a partial title (true title is the
full wiki path), no idea of categories set etc... if it is a wiki page
we have even not the title of the structure...
- we want to have in edit mode the same data environment than show.
- we want to go back when saved or not, to the previous panel :
- go to show, so be able to see the modified wiki page in his
structure context and make navigation into structure
- go back to admin-structures (often we have to edit pages for
categories, or copyright, we don't need to spend time to show page, then
return by main menu to structure and structure management... so much
time lost for not useful operation which take time repeatedly without aim)
- go back to page list at the right page to make a repeated
check or translation, tips etc... for example (not to show, call list
page from menu, then find again the page and go on)
So what I have done : develop from the current version with which I was
working a new ergonomy.
See it (on the server of the site) can give ideas and suggest critics.
After, but only after, we can say : what we do, when how ?
Jonny have seen what I meant and propose best technical elements of
solutions for future.
But the problem is first the functionalities and priorities. It is not
pleasant if the user which nows others wikis says "unusable for our
production" you (tiki) do many things, sometimes fantastic, but no one
is well finished, even the kernel of functionalities. Too much work to
get well done applications : if it was only some css, it is nothing but
the ergonomy of wiki baaahhh...
We become crazy we have job to do (not two minutes to change a data of a
page or correct a typo, twenty seconds).
It is the reason why I took my full weekend to do these changes.
Now you (not you Jonny) can refuse to see how it works.
I think that the content is not so major as development, because what is
written as new is not large, it is not new code, it is a use of existing
code. The lonely problem was to find the right place for new commands
(and urls), add some elements in http query.
It changes many things in ergonomy but it is not a "new development". It
was rearrange pieces.
I offers the code and the demo, you do what you want with, it is your
problem.
For my own I keep it.
As I uses 10.x (it is 10.3 now ?)
Best regards
Trebly
Note : I made duration test, to load actually a page with my server
(without any calendar see the thread please) To show a full page of
structure I have 6.00s with edit it is 8.55s.
I uses now xdebug profiler which will allow optimization.
_____________________________________________________________
On 26/02/2013 15:05, Jonny Bradley wrote:
>
>
> Hi Bernard, LP and all
>
> Generally, i agree with Louis Philippe if i understand correctly. In fact i would vote for removing the edit tab from tracker items to reduce load etc and have that accessed by AJAX only when asked for.
>
> Also hoping we can move towards inline/in-place editing (via services presumably) for wiki pages - maybe that would serve the same sort of purpose for you Bernard?
>
> jonny
>
>
>
> On 26 Feb 2013, at 12:40, Louis-Philippe Huberdeau wrote:
>
>> First thing. Major changes go in trunk. Not stable releases.
>>
>> Second. I do not think merging show and edit is a smart move. It does not bring any usability advantage. If anything, always loading the edit form in a separate tab increases the weight of the page and slows things down, reducing the experience quality for the average reader.
>>
>> Modularity should not be added by extracting code into include files, especially not by adding more files into the root.
>>
>> I would support moving edit page to a set of services, splitting it into preview, edit, and probably a few other things it does.
>>
>> Just merging the files brings no technical benefit, other than increasing the complexity of those already horrible files.
>>
>> --
>> LP
>>
>> On Feb 25, 2013 10:25 PM, "Bernard TREMBLAY" <bty...@tr...> wrote:
>> Hi,
>>
>> I have published here a mail on 02/21
>>
>> For future version ? : Wiki_pages show and edit - navigator - proposals
>> for simplifications
>>
>> This is done.
>>
>> I was not sure at all to reach the aim.
>> Because there are a lot of modifications on near 15 php, tpl, css, an
>> icon... from root but too smarty_tiki,
>> I have tested a lot and not found any problem, but may be there are
>> effects that I have not seen. I have to test all the translation
>> functions and the corresponding configurations of prefs. Too there are
>> prefs on wiki management to test. No reason to get problem I believe
>>
>> I think to four steps :
>> -----------------------
>> 1- Who is ready to make an evaluation send a mail to get access to my
>> server as redactor
>> 2- After evaluation of ui, I will set all the component to the
>> experimental branch
>> 3- Who is concerned can either merge with his version and test, either
>> simply look at code.
>> 4- After the OK I commit the content of the experimental branch to 10.x
>>
>> What does this enhancement
>> --------------------------
>> 1- From any point when you launches edit to a wiki page you reach an
>> enhanced page
>> a - looks like tiki-showpage for header
>> b- contains as center data the full editpage and all his functions
>> c- the end of page after special bottom for edit is the same as
>> showpage (index.php)
>>
>> 2- From this page you can launch : "view page" (not preview which is a ever)
>>
>> 3- When you save you go to showpage on the current page (as previously)
>> but the edit button (actions in header - action icon edit in of
>> tiki-wiki_topline just replace the showpage by editpage
>>
>> What is the interest :
>> ----------------------
>> 1- you can switch quickly from show-mode to edit mode without
>> environment change
>> 2- From wiki breadcrumb you can navigate and naturally edit immediately
>> and go back to navigation (previously editpage had no header to navigate
>> so to go back from editing a page to another, as described in my
>> previous mail, you had to launch again any access to edit from root
>> menu... this was not normal because they where thing to do it into page
>> edit but they could not function)
>> 3- From edit_mode enhanced option to reach back any point.
>>
>> How it is done :
>> ----------------
>> Mainly :
>> 1- the tiki-editpage.php and .tpl are no more used (keep while exist
>> call not updated)
>> 2- The tiki-show_page.php is a little modified (name could be changed)
>> too tiki-editshow...
>> 3- tiki-editpage has been widely reduced to a tiki-editpage-v2-inc.php
>> and tpl
>> 4- if $_request['editpage'] new param in query is set to 'Y' index.php
>> will prepare the edit data before display
>> 5- tiki-showpage.tpl if edit_mode validated merges the edit display else
>> display data <div id="page_data"> as usual.
>>
>> Details :
>> ---------
>> 1- new href syntax from tiki-admin_structures.php
>> (structures_toc-leaf.tpl modified)
>> 2- new href syntax from pages list.
>> 3- new buttons in page edit mode : "Save and show" "Save and continue"
>> 4- option box (after a preview) : After save go to : admin-structures,
>> pages-list (this allow to make quickly changes in pages from
>> admin-structures : goto edit and return immediately to admin-structures
>> or to pages list
>> 5- Edit page buttons changed every where and syntax of href which is
>> always index.php?<page_name>&pagedit=Y (or N)
>> 6- New icon created "page-watch" which avoid confusions with "magnifier"
>> 7- Add icon button to go back to showpage mode from edit, because of
>> existence of new option "save but stay editing"
>>
>>
>> Evolution :
>> ----------
>> The editpage data and the content $parsed to display will be exchanged
>> as blocks with the server replacing just the content.
>> Now when we flip from edit to show and versus we reload the whole page.
>> The flip will be immediate with this way of managed the content (note
>> same way as jqgrid). Change href of elements of page using DOM which
>> generates request for new content to server. Then send simply $parsed or
>> $midpage_edit, anything else.
>>
>> I can assure that it is sympathetic to have the whole top of wiki browse
>> (cats, tags, actions), all tiki-wiki_structure_bar.tpl and
>> tiki-wiki_topline.tpl during edition
>> and for the links and category management categobjects.tpl
>>
>> Best regards
>>
>> Trebly
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb
>> _______________________________________________
>> TikiWiki-devel mailing list
>> Tik...@li...
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb_______________________________________________
>> TikiWiki-devel mailing list
>> Tik...@li...
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> TikiWiki-devel mailing list
> Tik...@li...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
|