Feature Proposal: Direct interaction with attachments

Motivation

For Foswiki 1.1 would like to introduce one improvement of the larger "redesigning topic interactions".

Currently you need to click on "Manage" in the attachment table to change properties or upload a new file. The user has to know what is behind "Manage". It is also one click away.

Description and Documentation

By providing shortcuts for each attachment, the user can bypass this screen and change settings on the view page. Each action can show a small, dedicated form on a lightbox layer.

To reduce clutter, the shortcuts are only visible when hovering over an attachment row.

This user interaction requires (or invites) a new, roomier interface, similar to search results (as proposed in a different request). The sort options have moved from table headers to the top row.

Other options are to choose a normal layout (as shown), a condensed layout (only the titles) and an image layout (showing the actual images at a max size).

Examples

Mouse hover over attachment row, revealing the action links:

Lightbox overlay to upload a new file:

Impact

This interaction will rely heavily on javascript (jquery). AJAX would not be necessary if we use a js-based template for each form.

Ideally the page would not be reloaded after each interaction. How can we achieve this?

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: CarloSchulz, ArthurClemens - 18 Mar 2010

Discussion

It would be really cool if users just had to click the description or the filename to make it a seamless in-line edit. I suppose for rename, there would be a submit button titled "rename" once you enter "edit mode" for that field. But maybe we should save that stuff for when we have a generic solution for in-line edit of all things...

It's really easy to use a topic to populate a modal dialogue dynamically. I have done this in the jqui for TagMePlugin. Just a matter of passing parameters contenttype=text/plain;skin=plain;section=foo;blah=blah in the URL. It's a little flawed but you can get the basic idea if you visit http://wiki.trin.org.au/ and hit the "Tags" link in the very top left. The resulting modal dialogue is populated from http://wiki.trin.org.au/System/TagMeAjaxHelper

This might avoid some page view bandwidth overhead on the initial view, but on the other hand, it remains to be seen if that would be significant.

It would be nice to get a highly visible UI improvement into 1.1 as a selling point.

-- PaulHarvey - 19 Mar 2010

Here's a screenshot of the upcoming release of UploadPlugin which is using plupload:

Another point. The attachments widget should offer a way to access former versions of an attachment, for instance by having a twisty under the list entry saying "Older versions".

-- MichaelDaum - 19 Mar 2010

I think a major work would be to handle login through the dialog.

-- ArthurClemens - 01 Apr 2010

This proposal is passed by 14-day rule.

But as I do not see any checkins yet for this, and I also see a great deal of work, I assume this is a 2.0 scope work.

We are past the official feature freeze date now, and any new features not yet started and reasonably implemented will have to be deferred.

Because of Easter holidays I assume many of you would like to spend the days off on some programming I I give you till Monday the 5th if you have the work ready to checkin.

But if you expect this to take many weeks, please defer to 2.0. It is not a killer feature we cannot live without

-- KennethLavrsen - 01 Apr 2010

Yes, deferred to 2.0.

-- ArthurClemens - 21 Apr 2010

This work is basically superseded by TopicInteractionPlugin. Arthur, could you please review this proposal again and compare it with work done in that extension?

I am not sure we need to reinvent the thing again, so I revert this proposal from accepted to investigation.

-- MichaelDaum - 28 May 2012

How can a proposal for a core feature be superseeded by one of your plugins? People rarely want to install a plugin which also does a lot of other stuff?

If Arthur still wants to do this, we can't just revert an old acceptance decision. There are many features spread around in misc more or less maintained plugins.

Personally I am very hesitant of installing plugins that alter user interface because I have burned myself too many times in the past where I upgraded either Twiki or Foswiki and then I had to wait sometimes months before the author found the time to update the plugin. Plugins that are depending on skin templates and CSS often end in this situation. Especially plugins that have a single developer.

I think most will prefer that the feature that has been proposed here becomes part of the pattern skin or whatever skin we have in 2.0 and in a way that we can trust that is also works in 2.0.1 or 2.1.0 or 3.0.

Or are you proposing to add TopicInteractionPlugin as a default plugin with 2.0? Have I missed such a proposal topic?

It makes sense to ask Arthur to confirm he is going to do it as the number of accepted but never implemented proposals is piling up. And if he is no longer committed then the proposal needs to be parked. That goes for several proposals

-- KennethLavrsen - 28 May 2012

I had a look at the plugin during the Foswiki meetup at CERN last November. It does do a lot of things proposed above, and more. My concern is the skinnability or integration with skins, at which I will take a new look.

My own implementation in base skin is delayed, so it makes sense to see if code can be copied over, and otherwise make it a default plugin. If that is the case this will need a new feature request.

-- ArthurClemens - 28 May 2012

I think that this can either be rejected, or parked.

• TopicInteractionPlugin could potentially become a default plugin
• The developer has left, so we have no developer.

Marking it rejected, no developer.

-- Main.GeorgeClark - 27 Jul 2015 - 01:17