#1810 closed enhancement (fixed)
Better formatting for FAQ
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | Plugin Directory | Keywords: | has-patch |
Cc: |
Description
The current FAQ is fine but I think it could be improved.
Let's format the section in a special way (not the default, like Description), removing the "read more" entirely, and showing only the questions by default. Each one could be expanded to reveal the answer. Attaching a rough mockup of how this could look.
Attachments (4)
Change History (34)
This ticket was mentioned in Slack in #meta by sam. View the logs.
9 years ago
#3
@
9 years ago
Yes. Do exactly what that screenshot shows, but with a bit more elegant design patterns. :)
This ticket was mentioned in Slack in #meta by obenland. View the logs.
9 years ago
#5
@
9 years ago
I've built a prototype of this FAQ here:
http://codepen.io/mapk/full/MeggqL/
It's pretty much inline with the mockup from @samuelsidler but with some minor spacing and padding details.
#7
@
9 years ago
The more correct method to do this would be to parse the FAQ prior to markdown occurring, which you can see in the upgrade_notice
section above the proposed change in 1810.diff, I'm not entirely sure why screenshots are being parsed afterwards though..
You would then expose it as a Readme\Parser::$faq[ $question ] => $answer
property on the object, CLI\Parser
would then be responsible for storing it however you wanted, which could be a <dl>
in the post content, or as custom meta fields (as we do with screenshots, etc).
Whichever way you approach it, it's worth remembering that not all FAQ's are using <h4>
's some use <h3>
(members
) and others use <strong>
(share-this
), some include free form data before the headings (wp-user-avatar
), others (cookie-notice
) just include a paragraph, and then there's those who use free-form "invalid" formats (wpremote
&jquery-updater
).
Those plugins were just me opening a bunch of random plugins in the database and looking at their post_content, I'd say it was a 50% hit rate on "edge cases" while looking for examples. Ignoring, truncating, or reformatting plugins like this is fine, we just need to plan that out before we parse stuff.
#8
follow-up:
↓ 10
@
9 years ago
Second attempt: 1810.2.diff, it just uses the blob of text if it can't find questions.
I'm not sure how to mark it up properly and keep it in post content other than in Readme\Parser
, given that the uploader uses it too?
This ticket was mentioned in Slack in #meta by obenland. View the logs.
9 years ago
#10
in reply to:
↑ 8
;
follow-up:
↓ 11
@
9 years ago
Replying to obenland:
I'm not sure how to mark it up properly and keep it in post content other than in
Readme\Parser
, given that the uploader uses it too?
Not sure how that's an issue myself.. If you duplicate stuff into the uploader from the parser, expect to have to duplicate new stuff over..
#11
in reply to:
↑ 10
@
9 years ago
Replying to dd32:
If you duplicate stuff into the uploader from the parser, expect to have to duplicate new stuff over..
I don't, the uploader just passed the readme to be parsed.
This is the part I don't understand:
CLI\Parser
would then be responsible for storing it however you wanted, which could be a <dl> in the post content
I assume you meant CLI/Import
? So in the Importer you would take the Readme\Parser::$faq
array and format it into a list there?
#14
@
8 years ago
Please do not shout at me :-( text-transform: uppercase;
feels quite aggressive. Otherwise the accordion is :thumbsup:.
#16
follow-ups:
↓ 17
↓ 21
@
8 years ago
@obenland Thanks for 1810.2.diff I decided to pretty much go in the same direction as you did there.
After a lot of tweaking of the functions to parse the majority of readme edgecase formats I could find, and also not breaking the parsing of the upgrade_notice
for quite a few plugins I ended up with [3827].
For an example of what happens when there exists freeform data prior to the Q&A section, wp-table-reloaded is the first example I could find. In the event there's freeform data at the end of the Q&A, we have no way to detect that and include it in the last question.
Freeform data at present includes a lot of numbered and ordered lists, paragraphs directing people elsewhere, and even random non-FAQ material. I decided to just display that as-is anyway as parsing it wasn't really possible.
I'd suggest that the FAQ should get a readmore link added to it if no <dl>
is present within the section - for consistency sake, and to prevent long FAQ's (which we can't parse) taking over the screen.
I'm going to kick off a job to reparse all plugins, it'll probably take a day or so to complete.
#17
in reply to:
↑ 16
@
8 years ago
Replying to dd32:
wp-table-reloaded is the first example I could find.
Thanks for that, WP Table Reloaded is great bad example! :)
Once the job has finished we can close this ticket by removing the shim in wporg-plugins' functions.php
.
#18
@
8 years ago
After looking at the example here: https://wordpress.org/plugins-wp/jetpack/ we need to make sure the arrow icon aligns with the top line of the Question, even when the question is two lines.
Please do not shout at me :-( text-transform: uppercase; feels quite aggressive. Otherwise the accordion is :thumbsup:.
I think the uppercase works well here because it separates these questions stylistically from the other text on the page.
This ticket was mentioned in Slack in #meta by mapk. View the logs.
8 years ago
#21
in reply to:
↑ 16
@
8 years ago
Replying to dd32:
I'm going to kick off a job to reparse all plugins, it'll probably take a day or so to complete.
Just to follow up, this completed a few days ago. @obenland can you remove any shims and make sure things seem right to you?
#22
@
8 years ago
- Owner set to obenland
- Resolution set to fixed
- Status changed from new to closed
In 3834:
This ticket was mentioned in Slack in #meta by obenland. View the logs.
8 years ago
#24
follow-up:
↓ 25
@
8 years ago
Disagree that ALL CAPS works well there. They're really difficult to read like that. I'd prefer no text-transform, and the Blue accent color since they are links that have an action associated with them.
See screenshot here:
https://www.dropbox.com/s/3jq1jh42e778mz5/2016-08-24%2017_29_54-Plugin%20Directory%20%E2%80%94%20Free%20WordPress%20Plugins.png
I didn't dare re-open, but I think it's worth reconsidering.
#25
in reply to:
↑ 24
;
follow-up:
↓ 26
@
8 years ago
Replying to webdevmattcrom:
Disagree that ALL CAPS works well there. They're really difficult to read like that. I'd prefer no text-transform, and the Blue accent color since they are links that have an action associated with them.
I'm open to using Sentence case instead with these (it is easier to read). But I'm not convinced that the blue text is the best solution.
#26
in reply to:
↑ 25
@
8 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Replying to mapk:
But I'm not convinced that the blue text is the best solution.
Perhaps 80% of the black text color then?
This ticket was mentioned in Slack in #meta by obenland. View the logs.
8 years ago
#28
@
8 years ago
- Keywords has-patch added
Added patch 1810.3.diff to remove uppercase for dl elements.
#1833 was marked as a duplicate.