At least for SQL Server related questions, constraining a response to be GUI only is a good way to get downvoted. The documentation for commands is well, documented. If I want to restore my database, I would type RESTORE somesuchnonsense
and anyone who wants to go read the fine manual could understand what the options mean and what I've done. If I encounter an error, one of the first things I'm going to be asked is what have I done. If I tell you I clicked here, here and here, that doesn't tell me what command you've issued. Furthermore, did you know the resulting command that is built by the GUI is dependent upon the version of the GUI being used and not the target version of SQL Server?
Case in point, the creation of an SQL Agent Job on a 2008 machine that has an SSIS job step. If I used the 2008 version of the GUI to build a job, the default job step was fine. When I used the 2012 (RC) SSMS and created the "same" job, it would append /CALLERINFO SQLAGENT
to my job step. That's innocuous right? Except that CALLERINFO was not a valid option for dtexec in 2008. To make matters worse, when I would use the 2008 SSMS interface to view the job definition, I wouldn't even see the CALLERINFO parameter there because it just ignored it. It was only when I scripted out the job to see the underlying commands I noticed the discrepancy. How many hours did I waste trying to hunt that down? I prefer not to think about it.
Think of it this way, there are some tasks where you don't really need to know what's going on. People at McDonalds push a button and down go the fries in hot oil. A timer goes off an out they come. Do you want to be the first person to go to the dentist where they push a button to fire up root-canal-o-matic? No, because maybe you really only needed a cleaning and they didn't notice which button they accidentally pushed.