Patch

Comments

One of my users tried to attach to the TWiki.FileAttachment page after he figured that he needed to click on the "attachment" heading row of the attachment table, so I agree that non-clarity is a problem here.

I think the use of buttons (like KoalaSkin uses for the Save button (but curiously not for the edit button)) might enhance usability here. Maybe Arthur or Torben can comment?

Side remark on the save problem: HTML forces a newline after a form, so it is easy to use buttons
for the layout if they are all in the same form, i.e., handled by the same script, which is
the case of save with savemulti, hence the name

Using a button for edit would thus need to either be kept for only edit (and not attach, etc...),
or have one "wrapper-script" decoding the different actions to be done: edit/attach...

But, in my experience, if people care about their tools enough to use acces keys, they already
dropped IE for a better browser... (half joking there)

It is not technically difficult to code, but I am a bit reluctant to have too much things differing in the non-skin part between the standard release and the KoalaSkin. I guess it is another reason to find a way to have BetterDefaults as soon as possible

To remove the header label makes sense, since you cannot sort rows when they all have the same content. But visually the gap in the header row is a bit awkward.

This table is also used on the Attachment page, where the link for the attachment becomes 'view' (see below). The header label could be omitted also here, but I think the header 'Action' fits here (perhaps better).

Making the 'Edit' link a button would make things obvious, but also visually very heavy. Likewise the links at the bottom of the topic ('topic action') are also not buttons. Although you could try using CSS as on this gnustep wiki. In the end I prefer just a plain link.

So in all, I vow for changing the link label 'action' to 'edit', but to keep the header label 'Action'.

As noted in BetterAttachmentTableForCairoRelease, 'edit' makes it sound like you can edit the attachment itself (which would be very cool!) rather than manage the file's metadata. In any case, I do think 'edit' is preferable to 'action'. 'Modify' and 'Administer' might work too, with my personal preference going to 'modify'.

I would like 'manage' not 'edit' (i.e. you are doing various 'admin' type things to the attachment, rather than editing the attachment itself. Particularly with attachment icons for common file types, people would naturally expect 'edit' to mean 'edit the attachment', just as Edit on a TWiki page means 'edit the page'.

'Modify' is rather like edit, and 'administer' would be just about OK, but is longer than 'manage'.

I think the ambiguity with 'edit' can be solved by placing the link at the far right of the table. There, 'edit' points to the whole row instead of to the attachment itself. This becomes similar to 'edit table' with the EditTablePlugin.

Well, by reading the arguments on this page, I must say that I now think 'update' (or 'change', or 'modify', or... something short?) would be the better word, as I agree that having 2 "Edit" links doing different things (Edit page contents or change metadata of attachement).

I don't think relocating the 'edit' link helps disambiguate it, since the problem is that people will think that this means 'edit this file' (by analogy with 'edit this page'). Something like 'manage' or 'administer' is at least not a synonym of 'edit' (i.e. not 'update' or 'modify') and describes the operation better - like file management in the OS, as opposed to file editing.