Closed Bug 505425 Opened 15 years ago Closed 15 years ago

[ForumUX] Improve the "ask new question" form

Categories

(support.mozilla.org :: Forum, task, P1)

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: djst, Assigned: paulc)

References

()

Details

(Whiteboard: sumo_only)

Attachments

(6 files, 1 obsolete file)

Some things that should change:

* Walk the user through the process by giving contextual examples of good and bad ways of asking a question
* Add (link to?) explanation about what extensions are and how to find out which ones are running
* Use jQuery-style popups for explanations
* Remove the forum thread listing below the form
* Rename "Post" to "Submit Question" or similar
* Remove "Preview" (end users won't use it)
* Make "Cancel" less emphasized than "Submit Question" - e.g. a big green "Submit Question" and a normal button or link for "Cancel"

Note: this bug was just filed for the record -- we need a mockup before someone (i.e. Paul ;)) can implement it.
What priority should this have?
Assignee: nobody → paul.craciunoiu
I made a text mockup of the kinds of fields I think we need here: https://wiki.mozilla.org/Support/ForumUX/PRD/New_Question_Form but it REALLY needs some UI/UX/UE feedback and a proper mockup.  I'd call it a p2 but let's hold on doing anything on this bug until we get some more input.
Assignee: paul.craciunoiu → neilio
(posting this to the bug so it's public)

Here's the final "page" of the "ask a question" form.

Hidden details:
http://snaps.beatnikpad.com/askaquestion1-20090821-154457.png

Expanded details:
http://snaps.beatnikpad.com/askaquestion2-20090821-154657.png

I just need to finish off the "success!" page that tells users their question was submitted, plus some things they can do now (view your question on the site, go back to the home page, .etc.). Also, I want to have a bit of text in here to give the user an idea of what exactly happens next - that the questions are answered by volunteers, etc. 

Basically we should set expectations here so that the user doesn't expect that their question is going to be immediately answered.

Any suggestions?
Blocks: 512386
I've started work on this and it's looking good. I've got the multi-step form basic functionality done (JS only) and it feeds in real search results.

However, retrieving the search results is a mess using the current search code. Realizing that, I'll do the two bugs in parallel (this and bug 501880), so the patch for this will depend on that one.

Just a quick note: after talking to Cheng a while back, part of this issue also includes administration UI for the first step (options) along with the last step (fields to fill in). Filed bug 512386 for this latter aspect.
Depends on: 501880
(From email, posting for public record and feedback)

Here's a mockup of how this could work.

http://snaps.beatnikpad.com/warning-20090824-212633.png

Here's how the user flow would work in this situation:

1. The user fills out the form, but doesn't fill in the extension field.
2. The user clicks on "submit your question"
3. This balloon pops up with the warning text in it. The "submit your question" button becomes greyed out and inactive to give the user a hint that they can't resubmit their question using that button.
4. If the user hits "yes", their question is submitted as is.
5. If the user hit's "no" or clicks into the extensions field the original balloon with the "how to get your installed extensions" instructions appears[1], taking the place of this warning balloon.

[1]:http://snaps.beatnikpad.com/q2-20090824-141255.png

This design is also how we can handle error messaging (the description field is blank, the email isn't valid, etc.), but in those cases there are no "yes/no" buttons, and the focus is automatically place into the field that has the error.

We technically could use a javascript alert here, but by using a custom in-page widget like this it helps alleviate the typical knee-jerk reaction many users have to immediately dismiss the alert without actually reading what it says.

Thoughts?
Neil:

Those mock-ups look great.  It would definitely make the new topic form more user-friendly and inviting.
Here are the required images for the gradient and overlay backgrounds as well as annotated screenshots with font sizes, colours, etc. The font sizes are mostly a guide only - I assume we're going to size pixels using units that allow for resizing, but the sizing should help give some context on the sizing differences.

As discussed in IRC, I think we should use border-radius for the rounded corners and drop-shadow for drop shadows - I'm not concerned if IE doesn't get all of the bells and whistles.

Let me know if there are any questions.
Priority: -- → P1
Thanks Neil! Reassigning to Paul for implementation.
Assignee: neilio → paul.craciunoiu
Attached image Success screen
Sorry about that - I thought this "question successfully submitted" screen was part of that bundle but evidently not.
Attached image 16x16 feed icon
Just in case you don't have one, here's a 16x16 feed icon.
Attached patch giant patch (again), v1 (obsolete) — Splinter Review
Finally done!
Another giant patch. Sorry for being so late on this team, I've been on and off during the weekend and then realized there was way more to do than I thought. I'll try to detail here all the major aspects to watch out for.

To set this up. Instructions:
* To set it up on the "Ask a question" page, add this to that page's wiki content:
---
{DIV(class=forumquestion)}[tiki-ask_a_question.php?forumId=1|Ask a New Question]{DIV}
---

* You will need the image submit-button-bg.png from advanced search (just in case you're wondering why the submit button isn't themed)
* The other images are attached by Neil. I didn't use overlay-bg and warning-bg, chose transparency only, instead. The rest are being used, however. See attachment 396803 [details], images/ folder

* If using minify, make sure mozaskaq.css and forumquestion.js are added to minify (I added them in the advanced search patch so I didn't do it again here).

* This patch creates 2 symlinks (!!!) for forumquestion.tpl -- original is in mozkb/, others in mozfr/ and mozgn/ (former is the tiki-view_forum theme, latter is the AAQ theme). Watch out for those nasty symlinks when patching.

It looks like this patch only modifies 2 existing files (except minify) ;) low damage in case things blow up!

What it does:

* Adds a multi-step form as per Neil's mockups and annotated images. I used the links to various screenshots in this bug, starting with those at http://people.mozilla.com/~nlee/mockups/sumo/askaquestion/v1/ and continuing with the attachment.
* The form is added on "Ask a question" page (and translations) as well as on the tiki-view_forum.php page (to direct old users using that link to the new form).
* Depends on patch from bug 512386
* Step 1: choose from a list of radio options. Enforced through JS to choose one in order to proceed to next step. This branches out, depending on option:
** If allow_continue is false, the next step will be the last, and a description __MUST__ be provided. This description is shown with a <<Prev button
** Otherwise, if there is a description, it will be displayed on step 2
** After either step 2 or step 1 (depending on description), the next step is the search, step 3
* Step 3, search step: includes an ajax call to tiki-newsearch.php that loads a JSON object (from the advanced newsearch patch). The results are followed by a link to the search page, which opens in a new window. The results themselves also open in a new window. I made this call based on the fact that we don't want the user to lose their form progress -- since most users are unaware of the Ctrl+click feature.
* Step 4 is the final step, and includes a list of generated form fields  (generously provided as part of James' implementation of bug 512386) + the default ones.
* The default ones are:
** extensions (has warning)
** details (os, version, plugins) -- sniffed
*** code for sniffing these is copied from former forum_advanced_post.tpl
** name/email (anonymous, has warning) or username (logged in)
** captcha (anonymous, has warning)
* The generated ones are much more interesting. They take any html attribute from the admin. There is also an option for adding a text block (no input element) to explain things about the form.
* The form and warning should play fairly nice with window resizing in terms of height. The width I haven't tested much, but 750px should be acceptable for most people's screenres nowadays.
* After the form submission, you are taken to step 5, the "success" step. This looks as in Neil's mockup and does what it should: attachment 397760 [details]

* Without Javascript, the link simply takes you to a page with the form, where (as per Cheng's specs), you are given the same default elements, but no dynamically generated ones. Instead, there is a "description" textarea for adding all the information. No sniffing of os/version/plugins is done. The radio buttons from step 1 are available, though. For this form, I added a nice warning system (using an array), which makes the warnings be displayed at the top if submission fails. This is much better than having to click "back" if you miss something (it is also the drupal_set_message() way, basically).
* As with most recent patches, I've been trying to make this work regardless of how the relative URLs are set. I had to test this for Ask a question vs tiki-view_forum.php and it's great.

Nitpicks:
a) Warnings might need more work
* For the warning, the triangle doesn't go outside the window because I honestly have no idea how to do that cross-browser easily. Since time is important, I decided not to do it. Feel free to fix it :)
* The warnings are also not flexible to any form element as of yet. Currently, the only warnings are for extensions, captcha and email address. Adding more wouldn't be too hard, but it's not readily available.
b) Search
* The number of search results can be easily changed (there's a URL parameter), but it is hard coded in the JS form.
c) CSS
* Although most of the CSS is in em-s and %, some jQuery features require pixels (or so I think).
d) Invasion of tiki.tpl approach for wiki pages.
* For this, I'm really not sure if there's any better solution. I spoke to marclaporte and this seems to be the only option for our version (there are some more for newer versions). It is worth noting that this approach wouldn't scale for multiple wiki pages, so we won't be able to just add the form anywhere with the above embedded {DIV}

I think that's it. I tested this patch on a new dump (applied advanced search patch first), and it worked -- hope I didn't miss anything! This needs A LOT of testing. Also note that I haven't tested watch notifications very much. I'll also attach my test SQL dump and JSON object output to help with the review. At least this is only ~2k lines instead of ~6k like advanced search :)
Attachment #400968 - Flags: review?(laura)
Attachment #400968 - Flags: review?(james)
Attached file SQL dump for testing
Attachment #400968 - Flags: review?(james) → review+
Comment on attachment 400968 [details] [diff] [review]
giant patch (again), v1

This looks really good. Cww had some concerns about some of the text but functionally, it's working great.
'Knowing what extensions you have installed is valuable troubleshooting information' without telling them how to get that info is pretty worthless.  Can we say something like:

'Knowing what extensions you have installed is valuable troubleshooting information.  To find your extensions, go to the the *Tools* menu, select *Add-ons* and select the *Extensions* tab.'
Attachment #400968 - Flags: review?(laura)
r51674 / r51676
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Attached patch committed diffSplinter Review
For posterity, this is the actual patch, including the changes from comment 15.
Attachment #400968 - Attachment is obsolete: true
Some images were left out, added in r52077
Verified FIXED; neither bug 501880 nor bug 517269 are 1.4 blockers, and I've already filed a few spinoff bugs while testing this.
Status: RESOLVED → VERIFIED
Blocks: 505432
Whiteboard: sumo_only
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: