Edgewall Software
Modify

Opened 6 years ago

Closed 5 years ago

#11076 closed enhancement (fixed)

Consistent placement of Cancel buttons

Reported by: Ryan J Ollos <ryan.j.ollos@…> Owned by: Ryan J Ollos
Priority: lowest Milestone: 1.0.2
Component: general Version: 1.0-stable
Severity: trivial Keywords:
Cc:
Release Notes:

The Cancel buttons are consistently placed to the right of other submit buttons on all forms, and the Remove selected items buttons are placed to the right of Save changes buttons on the admin pages.

API Changes:

Description (last modified by Ryan J Ollos)

For most Trac pages, the Cancel buttons are consistently placed on the right.

Wiki edit:

Milestone edit:

Report edit:

The right seems the natural place to place Cancel. However, on the admin panels, Cancel is placed on the left. I suggest moving the position of the buttons on the admin panels to be consistent with the rest of Trac.

Admin Components Edit::

Patch is on the way.

Attachments (6)

AdminComponentEdit.png (2.8 KB ) - added by Ryan J Ollos <ryan.j.ollos@…> 6 years ago.
WikiEdit.png (4.3 KB ) - added by Ryan J Ollos <ryan.j.ollos@…> 6 years ago.
MilestoneEdit.png (3.0 KB ) - added by Ryan J Ollos <ryan.j.ollos@…> 6 years ago.
ReportEdit.png (2.6 KB ) - added by Ryan J Ollos <ryan.j.ollos@…> 6 years ago.
t11076-r11689-1.patch (7.6 KB ) - added by Ryan J Ollos <ryan.j.ollos@…> 6 years ago.
Patch against r11689 of the trunk.
CssRules.png (9.9 KB ) - added by Ryan J Ollos <ryan.j.ollos@…> 6 years ago.

Download all attachments as: .zip

Change History (21)

Changed 6 years ago by Ryan J Ollos <ryan.j.ollos@…>

Attachment: AdminComponentEdit.png added

Changed 6 years ago by Ryan J Ollos <ryan.j.ollos@…>

Attachment: WikiEdit.png added

Changed 6 years ago by Ryan J Ollos <ryan.j.ollos@…>

Attachment: MilestoneEdit.png added

Changed 6 years ago by Ryan J Ollos <ryan.j.ollos@…>

Attachment: ReportEdit.png added

comment:1 Changed 6 years ago by Ryan J Ollos <ryan.j.ollos@…>

Description: modified (diff)

comment:2 Changed 6 years ago by anonymous

Consistency is good.

I would like to suggest changing the buttons to be consistent with AdminComponentEdit.png though. I can't speak for other platforms such as Windows or Linux but in OS X it seems the "Cancel" button always is always left of the "Okay" button or whatever button there is to affirm an action.

Last edited 5 years ago by Ryan J Ollos (previous) (diff)

comment:3 Changed 6 years ago by Christian Boos

Milestone: 1.0.2

On Windows, it's also very common to have the Cancel button on the right, like in most places already in Trac. So fixing it for the components admin panel seems the right thing to do.

Changed 6 years ago by Ryan J Ollos <ryan.j.ollos@…>

Attachment: t11076-r11689-1.patch added

Patch against r11689 of the trunk.

comment:4 Changed 6 years ago by Ryan J Ollos <ryan.j.ollos@…>

t11076-r11689-1.patch makes changes to the following pages to place the Cancel button to the right of the other submit buttons:

  • Wiki delete
  • Report delete
  • Ticket delete
  • Wiki rename
  • Milestone delete
  • Component/Milestone/Enum/Version/Repository edit

Instances of Cancel:

(t11076)user@debian-wheezy:~/Workspace/t11076$ grep -R --exclude-dir=.svn "_('Cancel')" .
./trac-trunk/trac/admin/templates/admin_enums.html:            <input type="submit" name="cancel" value="${_('Cancel')}"/>
./trac-trunk/trac/admin/templates/admin_components.html:            <input type="submit" name="cancel" value="${_('Cancel')}" />
./trac-trunk/trac/admin/templates/admin_milestones.html:            <input type="submit" name="cancel" value="${_('Cancel')}"/>
./trac-trunk/trac/admin/templates/admin_versions.html:            <input type="submit" name="cancel" value="${_('Cancel')}"/>
./trac-trunk/trac/ticket/templates/milestone_delete.html:        <input type="submit" name="cancel" value="${_('Cancel')}" />
./trac-trunk/trac/ticket/templates/report_edit.html:            <input type="submit" name="cancel" value="${_('Cancel')}"/>
./trac-trunk/trac/ticket/templates/milestone_edit.html:          <input type="submit" name="cancel" value="${_('Cancel')}" />
./trac-trunk/trac/ticket/templates/report_delete.html:          <input type="submit" name="cancel" value="${_('Cancel')}"/>
./trac-trunk/trac/ticket/templates/ticket_change.html:      <input type="submit" name="cancel_comment" value="${_('Cancel')}"
./trac-trunk/trac/versioncontrol/templates/admin_repositories.html:            <input type="submit" name="cancel" value="${_('Cancel')}"/>
./trac-trunk/trac/wiki/templates/wiki_rename.html:          <input type="submit" name="cancel" value="${_('Cancel')}"/>
./trac-trunk/trac/wiki/templates/wiki_edit_form.html:      <input type="submit" name="cancel" value="${_('Cancel')}" />
./trac-trunk/trac/wiki/templates/wiki_delete.html:          <input type="submit" name="cancel" value="${_('Cancel')}" />
./trac-trunk/trac/templates/attachment.html:            <input type="submit" name="cancel" value="${_('Cancel')}" />
./trac-trunk/trac/templates/attachment.html:              <input type="submit" name="cancel" value="${_('Cancel')}" />
./trac-trunk/tracopt/ticket/templates/ticket_delete.html:            <input type="submit" name="cancel" value="${_('Cancel')}"/>
./trac-trunk/tracopt/ticket/templates/ticket_delete.html:            <input type="submit" name="cancel" value="${_('Cancel')}"/>

comment:5 Changed 6 years ago by Remy Blank

Just remember that the first button (i.e. here the leftmost) will be activated when pressing ENTER in a text input field. For wiki pages, previewing in that case is a natural thing to do. For edits, it's probably fine to save on ENTER. For deletes, however, I would say that the safe thing to do should be to cancel (although in ticket_delete.html it's a non-issue, as there's no text input).

comment:6 Changed 6 years ago by Christian Boos

Ah right, I remember that we discussed it before (#6521). I didn't realize the default was depending on the order… Isn't there a better way? Well, apparently not. Maybe we could indeed use a bit of CSS to move the Cancel button to the right.

comment:7 Changed 6 years ago by Remy Blank

I still think a few of the admin panels could have their "Save" buttons moved to the left as default. It happened to me more than a few times that I edit something, press ENTER only to cancel the edit. We just have to be careful in the few cases where data loss could happen.

comment:8 in reply to:  7 Changed 6 years ago by Ryan J Ollos <ryan.j.ollos@…>

Replying to rblank:

I still think a few of the admin panels could have their "Save" buttons moved to the left as default. It happened to me more than a few times that I edit something, press ENTER only to cancel the edit.

I agree that Save when pressing enter is the more expected behavior. It's also the behavior that currently exists for Milestone edit and Report create. Perhaps a more descriptive info message would help too though. For example, when renaming a component and changing it's owner, we currently see:

close Your changes have been saved.

We could show the exact changes that were just saved:

close Your changes to component1 have been saved:
  • Name changed from component1 to component3.
  • Owner changed from somebody to nobody.

Related: #11080.

We just have to be careful in the few cases where data loss could happen.

If we all agree with putting the Cancel on the right for the admin pages, it looks like we have only one possible case of "data loss":

  • Wiki delete: no input elements.
  • Report delete: no input elements.
  • Ticket delete: no input elements.
  • Wiki rename: new_name text input and redirect checkbox; this case seems similar to the admin panels.
  • Milestone delete: Press enter while the retarget checkbox is the active element, milestone will be deleted.

It looks like Milestone delete is the only case to worry about.

Changed 6 years ago by Ryan J Ollos <ryan.j.ollos@…>

Attachment: CssRules.png added

comment:9 Changed 6 years ago by Ryan J Ollos <ryan.j.ollos@…>

Replying to Ryan J Ollos <ryan.j.ollos@…>:

  • Milestone delete: Press enter while the retarget checkbox is the active element, milestone will be deleted.

Another note about this: clicking on the checkbox and then pressing enter doesn't activate the first form button on submit. You must tab to the checkbox element and press enter.

I haven't had any luck using CSS to reorder the buttons without having them also float to the right. Besides coming up with a way to reorder the buttons using CSS, it seems like there are a few options here:

  • Disable submit when hitting enter on the checkbox using JavaScript.
  • Do nothing since this is a corner case that is unlikely to cause many users an issue.
  • Reorder the buttons with JavaScript.

Changes so far:

comment:10 in reply to:  9 Changed 6 years ago by Ryan J Ollos <ryan.j.ollos@…>

Replying to Ryan J Ollos <ryan.j.ollos@…>:

Replying to Ryan J Ollos <ryan.j.ollos@…>:

  • Milestone delete: Press enter while the retarget checkbox is the active element, milestone will be deleted.

Another note about this: clicking on the checkbox and then pressing enter doesn't activate the first form button on submit. You must tab to the checkbox element and press enter.

This same behavior currently exists on the admin ticket view panels. For example, on the Admin Component panel:

  1. Tab to the checkbox for component1.
  2. Press the Spacebar to check the box.
  3. Press Enter.

component1 will be deleted. It seems like we should swap the order of Remove select items and Apply changes.

comment:11 in reply to:  9 Changed 6 years ago by Ryan J Ollos <ryan.j.ollos@…>

Replying to Ryan J Ollos <ryan.j.ollos@…>:

Note that it's not exactly the same as the first patch, since I haven't applied the change to the Milestone delete page, pending a decision on how to deal with that one.

comment:12 Changed 6 years ago by anonymous

cant you just add a "confirm to delete / are you sure" popup/messagebox?

comment:13 Changed 5 years ago by Ryan J Ollos

Description: modified (diff)

comment:14 Changed 5 years ago by Ryan J Ollos

Owner: set to Ryan J Ollos
Status: newassigned
Version: 1.0-stable

To summarize a few things from this ticket:

  • I'll defer the enhancement described in comment:8 to another ticket.
  • The issue with the Milestone delete page that is described in comment:8 is no longer relevant because the Retarget checkbox is being removed (comment:38:ticket:5658).

I've prepared the proposed changes for review in rjollos.git:t11076.

One side note regarding the small bit of CSS refactoring first proposed in comment:9. The milestone class is only used on a few pages:

(t11076)user@ubuntu:~/Workspace/t11076$ grep -R --exclude-dir="tests" "class=\"milestone\"" .
./teo-rjollos.git/trac/ticket/templates/milestone_delete.html:    <div id="content" class="milestone">
./teo-rjollos.git/trac/ticket/templates/roadmap.html:        <div py:for="idx, milestone in enumerate(milestones)" class="milestone">
./teo-rjollos.git/trac/ticket/templates/milestone_view.html:    <div id="content" class="milestone">
./teo-rjollos.git/trac/ticket/templates/milestone_edit.html:    <div id="content" class="milestone">

After inspecting all of those pages, I found that:

  • The .milestone .date selector was not being used because the .milestone .info .date matches for the applicable elements on the pages where the milestone class is used.
  • The first of the two .milestone .description selectors could be deleted, because the second overrides the first.

In both cases, it appears the duplication of the selectors was just overlooked when the first of the two selectors was modified in [1251].

comment:15 Changed 5 years ago by Ryan J Ollos

Component: admin/webgeneral
Release Notes: modified (diff)
Resolution: fixed
Status: assignedclosed

Committed to 1.0-stable in [11882:11883] (merged to trunk in [11886]), followed by a minor refactoring in [11884:11885] (merged to trunk in [11887]).

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Ryan J Ollos.
The resolution will be deleted.
to The owner will be changed from Ryan J Ollos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.