You are here: Foswiki>Tasks Web>Item13965 (25 Sep 2016, GeorgeClark)Edit Attach

Item13965: Unfortunate UX difference between EditRow and EditTable

pencil
Priority: Enhancement
Current State: Confirmed
Released In: n/a
Target Release: n/a
Applies To: Extension
Component: EditRowPlugin
Branches:
Reported By: VickiBrown
Waiting For:
Last Change By: GeorgeClark
When using EditTablePlugin, an editable table always shows the "Edit" button, even to guests (users who are not logged in).

When using the EditRowPlugin, this is not the case.

The UI difference causes this change to the user experience:

With EditTable
  1. User views page and sees table
  2. User clicks "Edit"
  3. Clicking Edit causes Wiki to prompt with a login dialog
  4. user either
    • logs in and edits the table (or)
    • cannot log in, registers, emails the admin, etc

With EditRow
  1. User views page and sees table
  2. User has no idea that the table is editable
  3. User does not know what to do

Use Case - I sometimes create "signup" sheets and similar pages that guests to my Wiki can update. The Editable Table is on its own page; the wrapper content is INCLUDEd from another page. Guests are given a guest ID that allows them CHANGE access to this page only, not the entire wiki.

See cfcl...BrainScanning for an example.

-- VickiBrown - 17 Feb 2016

Here are also installations where wants:
  • display only the "plain table" to WikiGuest - without disturbing with the "edit-button" (for example in a closed sites, where the registering to public is disabled), but the simple table view is wanted.
  • and show the edit button only to already logged-in users
Maybe some preference, such:
  • Set ERP_GUEST_BUTTONS = yes
or like... smile

-- JozefMojzis - 18 Feb 2016

I think part of the problem is that ajax can't authenticate, or at least it would be a lot more complex to have the javascript prompt the user to login, as well as less secure having javascript handle password prompting. EditRowPlugin does its work asynchronously with ajax, so rather than a redirect to login, it just "wouldn't work". I'm not sure what a good solution would be to get back the traditional behaviour.

-- GeorgeClark - 18 Feb 2016

Perhaps the plugin could include a check for whether the user is/is not authenticated and produce a simple graphic that indicates this is an editable table if you're logged in?

Or even if it can't do the authentication itself, could it include a link to %LOGIN% ?

(FYI I added a Use Case and link to the main description above)

-- VickiBrown - 18 Feb 2016
 

ItemTemplate edit

Summary Unfortunate UX difference between EditRow and EditTable
ReportedBy VickiBrown
Codebase 2.0.3
SVN Range
AppliesTo Extension
Component EditRowPlugin
Priority Enhancement
CurrentState Confirmed
WaitingFor
Checkins
TargetRelease n/a
ReleasedIn n/a
CheckinsOnBranches
trunkCheckins
masterCheckins
ItemBranchCheckins
Release02x01Checkins
Release02x00Checkins
Release01x01Checkins
Topic revision: r5 - 25 Sep 2016, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy