Project

General

Profile

Bug #4200

Create a Site, Error Message

Added by Samantha Raddatz over 6 years ago. Updated about 6 years ago.

Status:
Resolved
Priority name:
Normal
Category name:
Blogs (BuddyPress)
Target version:
Start date:
2015-06-25
Due date:
% Done:

0%

Estimated time:

Description

When creating a new site, there is no indication of whether a domain name is already being used. In order to find out if the chosen name is available, the user has to submit the form. The page that loads has two lines indicating a problem, the first simply says there was a problem with the form and the second tells the user that the site already exists. Both appear in the same font, color and text size as the rest of the lines on the page, so the error is not obvious.

Bold and make this text red to make the error message more apparent to the user.

2createsite.png (119 KB) 2createsite.png see 1.3, arrow Samantha Raddatz, 2015-06-25 09:53 AM
step2_screenshot.png (134 KB) step2_screenshot.png Samantha Raddatz, 2015-08-04 10:22 AM

History

#1 Updated by Samantha Raddatz over 6 years ago

  • Tracker changed from Bug to Design/UX

#2 Updated by Boone Gorges over 6 years ago

  • Category name changed from User Experience to Blogs (BuddyPress)
  • Status changed from New to Assigned
  • Assignee changed from Boone Gorges to Daniel Jones
  • Target version set to 1.9

Dan, can you try to make this more beautiful? If you really wanted to get fancy, you could do some realtime checking (via ajax) of the availability of a domain. There's probably an existing plugin you could steal this from. It would also be a decent improvement for BuddyPress.

#3 Updated by Daniel Jones over 6 years ago

Think I've got a solution here: https://github.com/cuny-academic-commons/cac/commit/de7d819f3a1ed51d0cf0266f620c61c3d5801f08

I decided to go with an AJAX check, which I added to a JS function that was already hooked to every keystroke on the URL for blog creation pages (both in and out of groups). I didn't end up messing around with the errors, and instead just disabled the forms when the entered URL wasn't unique. I add the error in red text beneath the URL field.

Let me know if this works!

#4 Updated by Boone Gorges over 6 years ago

Looks pretty good - thanks, Dan! A couple small things -

- Use die() instead of wp_die() here. wp_die() shows an HTML page, which we don't want to send as part of the AJAX request.
- Make sure you check `isset( $_GET['url'] )` before setting it to a variable, or you'll fill our error logs :)
- We can save some overhead by passing `false` to the second argument of `get_blog_details()`
- We shouldn't be running AJAX requests on every keyup - we're going to DOS ourselves ;) I'd suggest moving this stuff out of check_blog_name() and into its own callback, which should be triggered on blur, or after 1000 milliseconds of no typing, or something like that.

#5 Updated by Daniel Jones over 6 years ago

Good calls all around - thanks Boone! https://github.com/cuny-academic-commons/cac/commit/58c1b37dc5fed82196682cf712cc81d529325a7d

While working on those pieces I also discovered a couple differences between the markup for the Group Blog options page on groups creation vs. group admin, which meant a couple more changes. Let me know if this works!

#6 Updated by Boone Gorges over 6 years ago

This looks great, Dan. The one UI suggestion I'd make is as follows. If you enter a bad address, the "Sorry" message appears. If you then go back and change to a new address, the "Sorry" message sticks around until after the AJAX request has completed, which could be a second or two. This feels a little confusing. Can we hide the message as soon as the user starts editing the bad address? Like maybe an onfocus event, so that clicking back into the text field to edit will make it go away?

#7 Updated by Daniel Jones over 6 years ago

Yep that makes a lot of sense to me! What I did here: https://github.com/cuny-academic-commons/cac/commit/d7f5557fafefda7d7defd7bbd0084d6ba6ca790b is remove the error message on focus, but still leave the form disabled, so that way someone can't just click back into the input and press enter and find the old confusing error messages. So they'll still have to click away from the input for it to check to see if the URL is unique and re-enable the form. Does that sound alright?

#8 Updated by Boone Gorges over 6 years ago

  • Assignee changed from Daniel Jones to Samantha Raddatz

This looks great, Dan - thanks!

Sam, I'm assigning this to you so that you can review the changes for flow. I've pulled them to cdev so you can play with it.

#9 Updated by Samantha Raddatz over 6 years ago

I tried to create a new group and group site to see the changes here, but it wouldn't let me click 'Next step' on the Settings page (step 2) to continue.

#10 Updated by Daniel Jones over 6 years ago

Oops you are quite right Sam! I think I fixed the problem now.

#11 Updated by Samantha Raddatz over 6 years ago

Hi Dan, that button is still not working for me... tried it on Chrome, Safari, and Firefox.

#12 Updated by Samantha Raddatz over 6 years ago

Nice update, this problem seems to be working now on cdev.

#13 Updated by Boone Gorges about 6 years ago

  • Status changed from Assigned to Resolved

Looks like we're good here.

Also available in: Atom PDF