First of all, it is not a good Quartz practice to pass anything else than primitive Java data types in the Quartz JobDataMap. See "Only Store Primitive Data Types In the JobDataMap" section in Quartz Best Practices.
Without diving into too much detail, when it comes to QuartzDesk, you should stick to using Strings only. This allows you to edit job data map parameters in the GUI as you already found out. In your Quartz jobs, you can then use the conversion methods provided by the Quartz JobDataMap API to automatically convert Strings onto Booleans, Integers, Doubles, etc. See all those getXYZFromString(String key) conversion methods - they exist in the Quartz API for a good reason.
As for passing object references (Spring bean references) in the job data map params, this is very bad idea because:
You are exposing yourself to all types of Java serialization/versioning issues when upgrading your app code. Please note that Quartz JobDataMaps get serialized by Quartz (at least when you use the JDBCJobStore).
You cannot edit Java object references in the QuartzDesk GUI or any other GUI that I know of. How would this work? Would you expect a combo loaded with all alive Java objects that exist in the JVM? IMO, this is not quite feasible.
If you need to inject Spring beans into your Quartz jobs, you may use some sort of an AutowiringSpringBeanJobFactory job factory implementation described here.
If you need a more dynamic solution that enables your Quartz jobs to pick and invoke Spring beans dynamically based on the passed job data map parameter values, then maybe you can pass Spring bean names (i.e. Strings) rather than Spring bean references in your job data maps. You can then configure your SchedulerFactoryBean to inject the Spring application context to the SchedulerContext that you can access in the execute method of your jobs (JobExecutionContext.getScheduler().getContext()). Your jobs can then look up the relevant Spring beans (whose names are passed in the job data map) in the injected Spring application context. You will probably want to use some sort of an abstract job base class that encapsulates the Spring bean lookup logic so that your jobs can invoke something like:
<T> T getSpringBean( JobExecutionContext jobExecCtx, String beanName, Class<T> beanType )
I am sorry for being a bit verbose, but I felt this needed a somewhat broader explanation.