Feature #2736
closedEnable Rich Text for Profile Fields
80%
Description
As pointed out by Chris during the Commons meeting on Friday, we should adopt a format where:
1. Rich text (including HTML and the TinyMCE editor) is enabled by default on profiles so that people can add formatting and links to their Profiles/CVs
2. Since enabling rich text conflicts with the ability to drag and drop profile fields, we should have a system where one clicks a "reorder" button to disable rich-text editing and reorder fields
Would love to see this in 1.5.1 if possible.
Files
Related issues
Updated by Boone Gorges over 11 years ago
- Target version set to 1.5.1
- Estimated time set to 10.00 h
This is likely to take a significant rearchitecting of the page. I'll put it into the 1.5.1 milestone as you've requested, but it's probably that there will not be time to complete it by then.
Updated by Matt Gold over 11 years ago
but . . . but it was so easy for me to imagine this feature, so it must be easy to build!
No worries on the milestone. I do think we should have it on our roadmap sooner rather than later if possible, though.
Updated by Boone Gorges over 11 years ago
- Target version changed from 1.5.1 to 1.5.2
Updated by Boone Gorges over 11 years ago
- Target version changed from 1.5.2 to 1.5.3
I've done some more research and prototyping, and I think I'll be able to get around the moving-iframes-around-the-DOM issue by using HTML5's contentEditable property instead. There are a couple existing libraries to make rich editors in this way - https://github.com/bergie/hallo is the one I've had the most success with - but integrating it properly with the new Commons profiles is proving to take a lot of work. I have to do proper browser-sniffing with fallback on textareas, and because contentEditable means that data is no longer stored in a proper HTML form, I have to write some custom JS to make the profiles actually saveable.
I'm hopeful that I'll be able to have something in the next week or so, which'll then need to be tested by the team to ensure reasonable cross-platform performance. I'm going to put it into 1.5.3 in hopes that all this can be finished by then.
Updated by Matt Gold over 11 years ago
Awesome. Thanks for your work on this, Boone.
Updated by Chris Stein over 11 years ago
+1 thanks, for putting in the work on this.
Updated by Boone Gorges about 11 years ago
- Target version changed from 1.5.3 to 1.5.4
This is not done, so I'm moving it to the next release.
Updated by Boone Gorges about 11 years ago
- Target version changed from 1.5.4 to 1.5.5
Updated by Boone Gorges about 11 years ago
- Target version changed from 1.5.5 to 1.5.6
Updated by Boone Gorges about 11 years ago
- Target version changed from 1.5.6 to 1.5.7
Updated by Boone Gorges about 11 years ago
- Target version changed from 1.5.7 to 1.5.8
Updated by Boone Gorges about 11 years ago
- Target version changed from 1.5.8 to 1.5.9
Updated by Boone Gorges about 11 years ago
- Target version changed from 1.5.9 to 1.5.10
Updated by Boone Gorges about 11 years ago
- Target version changed from 1.5.10 to 1.5.11
Updated by Boone Gorges about 11 years ago
- Target version changed from 1.5.11 to 1.5.12
Updated by Boone Gorges almost 11 years ago
- Target version changed from 1.5.12 to 1.5.13
Updated by Boone Gorges almost 11 years ago
- Target version changed from 1.5.13 to 1.6
Updated by Boone Gorges almost 11 years ago
- Category name changed from BuddyPress (misc) to Commons Profile
Updated by Boone Gorges almost 11 years ago
- Category name changed from Commons Profile to Public Portfolio
Updated by Boone Gorges almost 11 years ago
- Status changed from Assigned to Testing Required
- % Done changed from 0 to 80
- Estimated time changed from 10.00 h to 30.00 h
This issue ended up being extremely complex. It required a full rewrite of the Profile javascript, and an extensive refactoring of much of the plugin.
That said, the first pass is ready to test on http://cdev.gc.cuny.edu. Log in and go to your profile edit page to check it out.
The workflow for some profile editing actions has been changed just a bit in response to some of the technical changes. I've tried to add some visual clues to help users along. I'm not going to give any more information than that, because I would like to get unvarnished opinions :)
(The update appears to have broken RSS widgets for the moment - please do not try to add or edit this widget type on cdev at this time.)
Updated by Matt Gold almost 11 years ago
Looks really great to me, Boone. I ran into two small errors:
1. I was editing one field and didn't realize I still had it open before clicking inside another field to edit it. Nothing happened until I realized that I could do only one at a time, and so would need to save changes on the first field. I worry that some people might not realize that, so maybe we should throw an alert?
2. I copied/pasted html content from the web into the publications box. Italicized text carried through on past -- it looked to be italicized in the editing box. But when I saved changes, the italicized formatting did not show up on the page.
Two other concerns:
- I wonder whether we should put some limits on the size of the headers so that they aren't bigger than the section headers on the left side of the page, though.
- how will searchable keywords across Commons profiles work now (or won't they work?)?
Nice work and sorry this turned out to be so complicated. I think that people will really love it!
Updated by Boone Gorges almost 11 years ago
Thanks very much for the feedback, Matt. The fact that you didn't mention anything about the actual mechanisms of figuring out what needed to be edited, how to enter editing mode, etc means that the design cues I put into place must be fairly natural :)
I was editing one field and didn't realize I still had it open before clicking inside another field to edit it. Nothing happened until I realized that I could do only one at a time, and so would need to save changes on the first field. I worry that some people might not realize that, so maybe we should throw an alert?
I'd thought of the same thing, but hadn't implemented anything yet. An alert is pretty inelegant, IMO. Instead I've gone for a little "pulse" cue. Try it and let me know if you think it's obvious enough. https://github.com/cuny-academic-commons/cac-advanced-profiles/commit/5e43b0dee8b32651e65557fd52daf2f37e51d61b
I wonder whether we should put some limits on the size of the headers so that they aren't bigger than the section headers on the left side of the page, though.
I have made the H1, H2, and H3 relative sizes make more sense. https://github.com/cuny-academic-commons/cac-advanced-profiles/commit/0d4bda8a7b5976d7f678c07c30573aa376f1dcce
how will searchable keywords across Commons profiles work now (or won't they work?)?
The auto-linking seemed more awkward with the new editing mode than with the old, so I'd disabled it. (Manual [brackets] continue to work as usual.) I've just reenabled it so you can see for yourself whether you like it: https://github.com/cuny-academic-commons/cac-advanced-profiles/commit/b45b7e1f513064ee3e3617e3efff081738b50161
I copied/pasted html content from the web into the publications box. Italicized text carried through on past -- it looked to be italicized in the editing box. But when I saved changes, the italicized formatting did not show up on the page.
Updated by Matt Gold almost 11 years ago
Thanks, Boone. I'm now cheating by looking at the two interfaces side-by-side so that I can see the differences. I agree that the design cues you put into place are intuitive and are working well!
simultaneous editing conflict:
I think the pulse cue is nice; the only problems is that since the header is fixed, it's easy to scroll down after clicking inside a text box. When you scroll enough so that the active text box can no longer be seen because it's "under" the fixed header, you can't see the pulse. I'm not sure how serious that issue is; I'd like to hear what others think.
H1 sizes
I think they should still be smaller if possible, so that the H1 is, max, as big as the text that appears in the left column
searchable links
Man, I'd hate to lose the ability to have those links available to search across the interests of academic members, since that was always part of our discussions about the serendipity of the network (allowing people to discover others who share interests, etc). Can we do something special with the academic interest field so that terms separated by commas automatically become linked not on the individual profile page, but rather on the people listing page ( http://commons.gc.cuny.edu/members/ )?
Updated by Boone Gorges almost 11 years ago
I think they should still be smaller if possible, so that the H1 is, max, as big as the text that appears in the left column
Can you please post a screenshot of what you see? I'm seeing H1 as being significantly smaller. Please also do a hard refresh.
Can we do something special with the academic interest field so that terms separated by commas automatically become linked not on the individual profile page, but rather on the people listing page
You'll have to clarify what you mean by this. The functionality has generally worked like this: comma-separated terms on individual user profiles linked to http://commons.gc.cuny.edu/members?s=searchterm. What would it mean for this to happen on the people listing page? Also, I did reenable auto-linking on cdev profiles, so nothing has been lost; did you test to see whether it works for you?
Updated by Matt Gold almost 11 years ago
- File alignment issue-profile-editing-view.png alignment issue-profile-editing-view.png added
- File alignment issue - profile-presentation-view.png alignment issue - profile-presentation-view.png added
- File formatting-buttons-over-blue-remove-button.png formatting-buttons-over-blue-remove-button.png added
Hi Boone -- do you want all bug reports on this new system on this ticket? Because I just did something that screwed things up. Screenshots attached, both in edit mode and presentation mode. What's happening is that the text in the top field is aligned center and can't get aligned flush left. I think I did this by clicking a whole range of formatting buttons -- ordered list, bulleted list, then header 1, then justify left/right/center, then p. Now the text won't become flush left and it looks like some formatting code is spilling over to the next field. You can see this live on the Text Student account on cdev.
Also, the formatting buttons appear over the blue "remove" button; it might be better to move the buttons left a bit.
header issue
yes, you're right -- hard refresh fixed this. Thanks. Still don't think an H1 will look good here, but I guess it's fine to give people the option.
searchable links.
I guess that with the new vision of the profiles as public presentational spaces, it may not make sense to make an individual's academic interests searchable links across the entire membership. I do think it is important for us to retain the ability to search/click across member interests, though, so let's discuss that in a separate ticket.
Updated by Matt Gold almost 11 years ago
So, I think that you should disable auto-linking on the presentational profile, at least.
Updated by Boone Gorges almost 11 years ago
formatting buttons appear over the blue "remove" button;
Fixed in https://github.com/cuny-academic-commons/cac-advanced-profiles/commit/a1d54e081a1bec0243fd980b855b486c3bcedba0. Moving left didn't work so I left more vertical space.
I think that you should disable auto-linking on the presentational profile
I'm going to open a separate ticket for your markup issue. If we're generally happy with the implementation, I'd like to think about closing this ticket and opening separate tickets for new issues.
Updated by Chris Stein almost 11 years ago
- File OK-Cancel-Message.png OK-Cancel-Message.png added
Boone, thanks for taking the time to work on this and Matt thanks for the comments. This is going to be a great addition.
Boone, I'm going to list some comments here but if you want me to make separate tickets for anything let me know.
Buttons in Toolbar¶
Matt, with the h1 there are two things here. One is the size of the font. That is easily fixed with CSS and we can adjust that in a separate ticket if need be to get it right. The other is what people will understand. Really these are just giving people the ability to have 3 levels of titles. For the time being I think h1, h2,h3 are the best options as the numbers make sense (it might be wierd to have h2,h3,h4, where's the 1?).
From a web perspective I agree with leaving out Underline (can be confused with a link).
I'm guessing the one we'll get requests for is a button to add images. I'm also guessing that adds a lot more complexity and is something we should not do at this time.
Toolbar Position¶
Boone, I think you may have addressed this but adding my observations in case there are any differences. I found that the JS set the width of the div.halootoolbar to 558px. This caused the h3 button to break to the next line for me. If it was changed to 565px then all was fine.
I also found if I added a margin-top to the div that contains the edit area then the buttons would sit on top of it which is where I expected them See Margin-Top-Buttons.png (in next post, hit submit by accident and can't add image).
I added 80px but could be a little less:
#cacap-edit .cacap-click-to-edit.editing {
margin-bottom: 50px;
margin-top: 80px;
}
Academic Interests as Links¶
Agree that we should open separate ticket to discuss.
Pulse Cue¶
Generally I like the cue. I do see Matt's Point that it is possible a use will miss the cue if they are editing something near the top and then scroll down to click on something near the bottom. I suppose you could move them back up the page, but I'm hesitant to do that and if we did do it the movement should animate and not just jump them up.
Another idea is to add a message next to the OK and Cancel buttons that explains they need to click one before moving on to edit another section. See OK-Cancel-Message.png
Errors when adding Free Entry¶
I found some errors when trying to add a Free Entry section
I found on the first addition I was only able to edit one of the fields. Steps to replicate
1. Add Free Text
2. Click to edit Title
3. Click OK
4. Try to click to edit textarea, cannot enter.
5. Click Save Changes (for entire profile)
6. Click to Edit Profile
7. Now can edit both Free Text Fields
Also if you edit the textarea first it does not get the rich text buttons
1. Add Free Text
2. Click to edit textarea
3. You can add text but the rich text options are not there
3. Click OK
4. Try to click to edit Title, cannot enter.
5. Click Save Changes (for entire profile)
6. Click to Edit Profile
7. Now can edit both Free Text Fields and the rich text options appear
Updated by Chris Stein almost 11 years ago
Attached is the missing image for the Buttons with margin-top added to the div.
Also adding a formatting issue. The positions List has a margin left that can probably be removed to bring it in line with the other sections. see Positions-List-Margin-Left.png
Updated by Boone Gorges almost 11 years ago
Thanks, Chris. It sounds as if the direction here is mostly good, so I'm going to spin off your remaining issues into separate tickets where they won't get lost.
The positions List has a margin left that can probably be removed to bring it in line with the other sections
This was already fixed locally but I had not yet pushed it up. It is ready to test on cdev.
Updated by Boone Gorges almost 11 years ago
- Status changed from Testing Required to Resolved
New tickets:
I'm guessing the one we'll get requests for is a button to add images. I'm also guessing that adds a lot more complexity and is something we should not do at this time.
Toolbar Position
Academic Interests as Links
Pulse Cue
Errors when adding Free Entry
==
I'm marking this ticket as Resolved. Please open separate tickets for new issues. Thanks for the help.