anarcat did a great cleaning on all not available tasks, but now people believe they can't delete any site at all, because the delete task is completely hidden. It should be inactive but visible, like before.

CommentFileSizeAuthor
#11 settings.png28.11 KBmig5
#6 tip.png44.32 KBmig5
#5 tip.png48.67 KBmig5

Comments

anarcat’s picture

anarcat commented

So that was a usability decision that was made after talking with a few people here at Koumbit and on IRC, and it seemed to us that having the disabled delete button yields more questions than anything because it's disabled... "Why is it off? How can I turn it on?"

When you just see a "disable" button, you hit that, and then it disables your site. Then you see: "aaah, i can also delete sites, cool!"

The only other usability improvement i could see here would be to allow deletion of sites directly. But basically, right now, disabled tasks are not visible, now sure it's worth it creating an exception just for delete?

omega8cc’s picture

omega8cc commented

While I agree that it isn't worth to create an exception just for delete task, it is still confusing now. Maybe we could add a text/tip below the tasks table with something like "To delete this site, please disable it first".

[EDIT] The problem is - most of people will not try to hit Disable, they are sending a support request asking "Why I can't delete any site?!"

Anonymous’s picture

Anonymous (not verified) commented

So it's a battle between usability (why can't I click these buttons) and documentation (how do I delete a site, the button isn't there)

I'd sooner have no Delete button and good documentation/tooltip explaining why, than unclickable buttons and tooltips saying 'please ignore these buttons, you can't click them' :)

So let's go the route of a friendly tooltip, perhaps in the site view under the task list saying something along the lines of 'Tip: to delete a site, you must first Disable it.'

Anonymous’s picture

Anonymous (not verified) commented

Or, as anarcat said, simply allow deletion of a site without disabling it (isn't enforcing a mandatory Disable, something we'd call 'policy' in any other situation)

Anonymous’s picture

Anonymous (not verified) commented
StatusFileSize
new tip.png48.67 KB

What do we think of the attached?

Feel free to do better - my design is even worse than my code..

Anonymous’s picture

Anonymous (not verified) commented
StatusFileSize
new tip.png44.32 KB

Slight improvement, smaller icon

shaneonabike’s picture

shaneonabike commented

The other suggestion when we talked about this at Koumbit was the following:

* Enable the Delete and Disable
* When users click on Delete a ModalFrame appears and says "You have to disable your site before deleting it. Are you sure you want to... Disable and Delete?"

I believe that would solve the issue of providing all functionality and still make the interface usable and clear. I agree that it could be confusing if buttons are hidden/appear (for consistency sake this isn't a good usability model).

Thoughts?

I do like the Tooltip but also think that with the functionality above we could just work around this issue maybe.

Anonymous’s picture

Anonymous (not verified) commented

So, just so I understand it fully, the 'Disable and Delete' would kick off two tasks at once? first the disable and then the delete? That seems fine too.

The more I think about it, the more I wonder why we don't just allow a direct delete without the disable. Both tasks run a Backup of the site anyway. 'Disable' is a purely cosmetic thing, enforced to probably to stop people deleting sites accidentally, but we already have the Are you Sure? dialogue, and people can restore from the backup that is made if they screw up. It's policy we're dictating here in my opinion.

Or we could 'silently' disable the site in the provision-delete task first, like we do with the backup.

Anonymous’s picture

Anonymous (not verified) commented

Vertice and I discussed this and I think a compromise has been reached: we'll introduce a configurable setting 'Require Disable before Delete?' in /admin/hosting/settings (a new area for non-feature-specific configurations)

It'll be on by default, and the Delete button will be missing, but if unchecked, the Delete task will appear and won't require a Disable first.

Everyone happy with that?

omega8cc’s picture

omega8cc commented

Wow. That is more than I expected. Sounds perfect to me. Thanks!

Anonymous’s picture

Anonymous (not verified) commented
StatusFileSize
new settings.png28.11 KB

Here's a screenshot of the proposed settings. It wraps up some other 'hidden' variables that exist in our code that we've never had a UI for, too.

The cron stuff only shows if the 'Cron' feature is enabled

omega8cc’s picture

omega8cc commented

Looks great!

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Fixed

Pushed to Git.

Also incidentally fixed a bug in the wget cron method, which could never have worked til now..

anarcat’s picture

anarcat commented

seems fine to me.

shaneonabike’s picture

shaneonabike commented

Sounds awesome! But does this mean that if a "Disable" is required first that we can invoke the two tasks as suggested above - sorry i wasn't clear on that part of the discussion.

Anonymous’s picture

Anonymous (not verified) commented

No, if a 'Disable' is required first, they are two separate tasks as per the existing behaviour.

If Disable is not required first, you can just go ahead and run the Delete task even if the site is 'enabled'.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

  • Commit d1272bd on 6.x-2.x, 7.x-3.x, dev-ssl-ip-allocation-refactor, dev-sni, dev-helmo-3.x by mig5: 
    try and fix the horrible hosting_task_menu_access confusion by cleaning...

  • Commit d1272bd on 6.x-2.x, 7.x-3.x, dev-ssl-ip-allocation-refactor, dev-sni, dev-helmo-3.x by mig5: 
    try and fix the horrible hosting_task_menu_access confusion by cleaning...