Feature #5735

[Workbench] Edit box for project description should be bigger

Added by Bryan Cosca over 6 years ago. Updated over 6 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Radhika Chippada
Category:
Workbench
Target version:
Start date:
05/01/2015
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
0.5

Description

Background

Edit box is woefully small. See picture. Ironically the rendered Description tab looks more reasonable when the content is not tiny: the edit box should encourage the user to write lots of useful content.

Proposed solution

Fill the entire tab with the text entry box, instead of putting it in a popup. Perhaps this involves using "inline" mode in x-editable, and adding some CSS?

The "Save" button should be at the top (so it's visible immediately, even when the textile content is long).

These might not be strictly necessary to bundle here, but could be relevant:
  • Use an "Edit" button instead of the pencil icon.
  • Use a "Save" button instead of a checkmark icon, and "Cancel" instead of an "x" icon.

larger_edit_description.png (24.1 KB) larger_edit_description.png Bryan Cosca, 04/15/2015 03:16 PM

Subtasks

Task #5891: Review branch: 5735-edit-description-box-sizeResolvedRadhika Chippada

Associated revisions

Revision cb418175
Added by Radhika Chippada over 6 years ago

closes #5735
Merge branch '5735-edit-description-box-size'

History

#1 Updated by Tom Clegg over 6 years ago

  • Target version set to 2015-05-20 sprint

#2 Updated by Tom Clegg over 6 years ago

  • Subject changed from Larger edit description box to [Workbench] Edit box for project description should be bigger
  • Description updated (diff)
  • Category set to Workbench

#3 Updated by Tom Clegg over 6 years ago

  • Story points set to 0.5

#4 Updated by Radhika Chippada over 6 years ago

  • Assigned To set to Radhika Chippada

#5 Updated by Radhika Chippada over 6 years ago

Notes about the update:

  • The edit button for project description is now displayed on top of textarea; uses btn-primary with pencil on left; 10 rows of display area with inline editing;
  • I did not update Ok and Cancel button icons to use text. This is managed by x-editable global templates http://vitalets.github.io/x-editable/docs.html#global and is set application-wide in editable.js. I could not see how we can change these only for the inline-editable and not everywhere else and hence left it as is.
  • I also could not figure out how to change the placement of the Ok and Cancel buttons to either the top or bottom of the textarea (just for this inline-textarea). Hence, I let them be on the right hand side of textarea and used 98% of page for the editable instead (css).

#6 Updated by Radhika Chippada over 6 years ago

  • Status changed from New to In Progress

#7 Updated by Brett Smith over 6 years ago

Reviewing 13e4bac

The new CSS will set 98% width for any inline X-Editable component. I'm concerned that this could surprise future developers who might try to use an inline editable. Is it possible to constrain this CSS further so it only applies to project description editing?

The existing code in render_editable_attribute expects htmloptions[:btnplacement] to be a symbol. The new conditional branch looks for the string 'top'. For consistency, please change this, and the call in _show_description.html.erb, to the symbol :top.

Thanks.

#8 Updated by Radhika Chippada over 6 years ago

Thanks Brett. Yes, limiting the inline css config to description is a good idea and I made those updates.

#9 Updated by Brett Smith over 6 years ago

Reviewing e146ad3. The changes address the previous issues, so thanks much for that.

The span tag is generated with all of the attributes included in htmloptions. Now that we're adding several button options to htmloptions, they're being rendered as (invalid) attributes on the span tag. For example, working on a development API server loaded with test fixtures, modifying the description for "A Project" has a span tag like this:

<span id="zzzzz-j7d0g-v955i6s2oi1cbso-description-1430770175757123" class="editable editable-textile editable-done-setup editable-pre-wrapped" [ data attributes] btntext="Edit" btnplacement="top" btnclass="primary" tabindex="-1" style="display: inline-block;">

Is there a good way to prevent these key-value pairs from being rendered as attributes on the span tag?

Thanks again.

#10 Updated by Radhika Chippada over 6 years ago

Brett: added a new "nonhtml_options" parameter to render_editable_attribute method definition and moved all the btn* attributes into it. Please take another look. Thanks.

#11 Updated by Brett Smith over 6 years ago

Reviewing 6e10831. This seems really great. Thanks for sticking it through. Just one small thing from here: this is also a preexisting bug, but now that we have the infrastructure to clean things up, it would be good to move the tiptitle option from htmloptions to nonhtml_options (since it's not a verbatim HTML attribute either, just like the btn-related ones). There are only a couple of templates using it (_index_jobs_and_pipelines.html.erb and _show_contents_rows.html.erb in app/views/projects/), so making the switch should not be difficult. If that's a straightforward change you can go ahead and merge with it. Thanks.

#12 Updated by Radhika Chippada over 6 years ago

Converted tiptitle to nonhtml_option.

#13 Updated by Radhika Chippada over 6 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Applied in changeset arvados|commit:cb41817568900d52d3768a91f703f04696f6b702.

Also available in: Atom PDF