Under construction: Improved functionality of the More screen

Set of changes to the "More" screen to make it more functional. Features that have been realized are listed in BetterMoreRealizedFeatures.

Feature	Spec	Impl	Scheduled
Set new topic parent
Move this to a separate template setparent.tmpl, so that in a large web the More page will load more quickly	100%	0%	DakarRelease
If a parent is set, write "The current parent is:"	100%	0%	DakarRelease
... and show the parent name (link to topic)	100%	0%	DakarRelease
In the dropdown list, select the parent (to be implemented in DropdownWithSelectedValue)	100%	0%	DakarRelease
UseLessStepsToReparentATopic	100%	0%	DakarRelease
Restore topic option
Add dropdown list with restore button, see example attachment	100%	0%	DakarRelease
Provide feedback screen (template), see example attachment	100%	0%	DakarRelease
Total: 7	100%	0%	DakarRelease
			DakarRelease

Contributors:
-- ArthurClemens - 19 Jul 2003
-- PeterThoeny - 31 Mar 2004

Discussions

Code changes to create a more usable More (oopsmore) page

I wanted to make some little changes to my More page. I can illustrate this best with a screenshot:

1. Shown is the current parent topic (note that this is not a link).
2. The dropdown shows again the current parent (preselected), and makes it possible to select a new parent.

To make this possible, I propose these changes:

• RenderMetaInOtherTemplates
• RenderParentWithoutLink

and would like to discuss:

• DropdownWithSelectedValue

-- ArthurClemens - 07 Sep 2003

This looks very intuitive!

It can be done when HandleMetaTagsInHandleCommonTags is implemented.

-- PeterThoeny - 08 Sep 2003

Has anyone tried to reparent a topic in Codev? This dropdown list is far too long! There must be a better method!

A possibility is an input field that gets filled by selecting a link in a pop-up. But you need to do extra validating then...

-- ArthurClemens - 08 Sep 2003

Well this is so simple it made me blush. Just add a size parameter to the select tag:

<select name="topicparent" size="10">

This will look like:

This is a small addition that will make twiki.org much more usable.

-- ArthurClemens - 03 Oct 2003

Peter, can we implement this on twiki.org? Will make reparenting a lot easier.

-- ArthurClemens - 26 Oct 2003

OK, first step is done, the selector showns now 10 entries. Also in TWikiAlphaRelease.

Pending: Show the current parent topic

-- PeterThoeny - 26 Oct 2003

For a large web it takes ages before the More page is loaded, because the contents of the select box is so big. For performance, setting the parent hould be moved to a separate page.

-- ArthurClemens - 05 Dec 2003

I added some enhancements discussed in TrashButton. This is work in progress, the spec is not solidified yet.

The changes are in TWikiAlphaRelease and TWiki.org.

-- PeterThoeny - 31 Mar 2004

-- ArthurClemens - 18 Jul 2004

It would really add to the usability if More had a revert to previous revision function that created a new revision based on a previous one like a lot of other Wiki's. This would be particularly useful of public sites that suffer vandalism.

As an interface all it would need would be a drop down of revision numbers from 1.1 to the previous to current revision (only for topics on or older than 1.3) and a revert button.

Alternatively, when viewing a previous revision there could be a revert link, possibly with a confirm page.

-- SamHasler - 22 Jul 2004

I agree that this would be more user friendly. But isn't there a danger that this "reverting" becomes an easy target for vandalism? Instead of editing or deleting content, just revert the topic to some previous version?

-- ArthurClemens - 22 Jul 2004

Yes, but since it always creates a new revision anyone else can always revert it back again. That's the beauty of it.

-- SamHasler - 22 Jul 2004

OK, then I agree this would be a good enhancement. I have added your proposal to the table above.

Wireframe of Restore topic options:

I've pushed this feature to Dakar, because 1 week is a bit short considering the other changes should/would still be implemented.

Is there an easy way to add a total calculation of progress done in the edit table?

-- ArthurClemens - 23 Jul 2004

I wub you Arthur. That's exactly how I envisioned it with the reverse sorting. I aggree that Restore is better than Revert, and I didn't expect this feature to make it into Cairo.

One thing the feature should avoid would be repeat viewings of the success page creating subsequent revisions. The URL to the success page should contain the revision number to restore and the target revision and a new revision should not be created if that revision already exists. This also stops someone removing an edit without having read it (although the edit would still be in the rev history). Are there any other race contitions or interaction that need to be covered?

When I said "only for topics on or older than 1.3" my intention was that the section wouldn't appear on the more page if not needed, or alternatively a message saying something like "This topic is only at revision 1.1 so there are no previous topics to restore". I neglected to think of the 1.2 case which chould simply have a label of 1.1 for the revision instead of the drop down.

I added the totals/gauges from the CairoRelease table and altered the total count, even if having it is a bit frivolous, to be $EVAL($ROW(-1)-$LISTSIZE($LISTIF($FIND(*, $item),$LIST($ABOVE())))). If anyone has a more elegant way of doing the count I'd like to see it.

-- SamHasler - 24 Jul 2004

Modularization aspects

I am interested in some kind of generic approach that will allow plugins to introduce their own sections in "More". For example, a notifier plugin would allow people to subscribe to the topics using "More" page. This should be possible by allowing notifer to provide its templates; a "More" master template simply includes templates from all plugins.

-- VinodKulkarni - 23 Jul 2004

I concur - I wanted this for MaxImageSizePlugin

-- MartinCleaver - 23 Jul 2004

I wanted this for managing Access Controls for the topic. One day, we will have EDITCELL on arbitrary information (not necessarily a table!), it will be allow us multiple selections, ... !

Here is a futuristic overview of interaction: The template will include all XyzPluginSettingPreferences topics. These topics would have capability to change settings standard locations (depending on permissions) - topic, topic's parent (or a group of topics which share configuration), web, user's Home, and so on. The settings workflow would be standardized across all the topics. The actions generated (such as "rename topic", "spell check" or whatever) will be mapped to plugins' "action_xyz" routines. This is more like a simplified action map approach that we find in Struts and other devel environments.

-- VinodKulkarni - 23 Jul 2004

For the "No child topics" I did a small enhancement to META:SEARCH: I accepts now a default parameter. TWikiVariables doc is updated.

-- PeterThoeny - 26 Jul 2004

I defer the parent changes ("The current parent is" text; select current parent in dropdown list) to DakarRelease. %META{}% is currently not available in oopsmore, only in template text. This needs more time to design and code.

-- PeterThoeny - 26 Jul 2004

Does "Add Form" belong on the More page?

-- MartinCleaver - 27 Oct 2004

It can belong to More as long as the link/button is not removed from the Edit page. Plus, when it is added to More, you should provide a direct link to edit the form table. The same arguments count here as in MoveFormButton, see my comment of 07 May 2004 - link/buttons should be put in the context where they will be needed.

-- ArthurClemens - 28 Oct 2004

Since several of the items in the table at the top are scheduled for DakarRelease, I'm changing the proposed release to Dakar.

See also CloneTopicLinkUnderMore

-- CrawfordCurrie - 15 Feb 2005

Arthur, what is going on about this?

-- CrawfordCurrie - 14 Apr 2005

Nothing yet. If I read back the topic, its all specification, no implementation. To be effective, the feature list should be separated into separate FeatureRequest topics.

-- ArthurClemens - 14 Apr 2005

each of the features in the table should be spun off unto their own pages; i've started with UseLessStepsToReparentATopic

-- WillNorris - 30 May 2005

One cosmetic chance regarding the new revision numbering in Dakar: reduce the 1.1 entries to 1 only.

-- FranzJosefSilli - 22 Jun 2005

bumped to EdinburghRelease (although, as state above by both ArthurClemens and myself, each feature should be separated into a separate FeatureRequest topic)

-- WillNorris - 08 Jul 2005