Apex Code Development You need to sign in to do that
Don't have an account?
larkinrichards Wizards & Event Page Overrides
I've been designing and experimenting with a wizard that is built around events and I've run into a number of problems that I can't seem to fix without compromising usability. Let me give you an overview of what I'm trying to make, the solutions I've tried, and the pros and cons of each.
Here’s our basic user story for this feature:
A user should log the number and type of items(promotional or otherwise) given to the attendees of an event. Additionally, the items available to be given change over time (sometimes weekly).
The easiest and quickest solution(which was implemented a while ago) was to add a number of custom fields to the Event for the quantity of each item distributed. The data gathered from this solution suggests that it is information that is quite valuable and that people are happy to enter it. As items are added and removed on a weekly basis, this requires constant maintenance of the event object, layouts, and related reports.
So when we wanted to track an additional field per item distributed, going with a more robust, relational database-y way of logging items distributed seemed like the way to go. I created two new sObjects: an Item(representing the different items we can distribute), and a Distributed Item(representing the distribution of a qty of a specific Item to a specific Contact on a specific day).
On a visualforce page w/ a custom controller, we can query the Item table to find available items and present them to a user so that they can enter how many of each item were distributed, as well as the date the items were distributed. This page then saves this data as a set of Distributed Item records. This code is all easy to write and works flawlessly as an isolated feature.
My first plan to expose this to users was to add a custom button to events to “log items distributed.” It’s a simple solution and it works fine. However, placing this page another click away from the edit screen means it is another thing the user has to remember to complete and another step to train on. In all likely-hood, having this information a click away would likely mean it is not always entered. Ideally, this system would work like the old event page does: a list of items that can be distributed, displayed as just another section of the event edit page.
The problem comes when we try to integrate this additional functionality into the flow the user goes through to set up or edit an event. If you override the event edit and new event pages, you lose some core pieces of default user interface: the datetime pickers for startDate/endDate, the ability to invite additional contacts or users, and the ability to see the availability of the invited users. It’s possible to use a datetime picker from various js libraries, but as it is not (yet) possible to programmatically create EventAttendee records, that functionality is completely lost. And to add insult to injury, because you are overriding the page you are faced with the chore of recreating the page layouts and their assignment which had previously been so easy to set up with the Salesforce clicks-not-code functionality.
Given the loss of the ability to add additional attendees and the time intensive task of hardcoding the various pagelayouts and their assignments to different profiles/recordtypes, this was not a reasonable idea.
The next thing I thought about was a bit more roundabout: overriding the URL parameter ‘successURL’ to always bring the user to the basic visualforce page for logging the items distributed. The best way to do this is to implement a ‘eventHook’ page that overrides the create and edit pages for an event. This page would rewrite the successURL parameter with the url for the itemdistribution page, and then redirect the user to a non-overridden edit/new page with the corrected url.
This is actually a pretty good solution - it maintains all of the basic salesforce functionality lost by a direct override, and if you want to turn on and off the item distribution page for different recordtypes/profiles you can very easily update the eventHook controller. The one difficulty is you lose some contextual information that would speed up the interaction. For instance, if you create an event you are S.O.L. if you want to reliably carry forward the ActivityDate or WhoId from the event to the distribution page. This means that after saving the event, the user may sometimes have to manually re-enter the date of the event and the attendees on the item distribution page, and the reason for why it would sometimes be pre-filled and other times not be pre-filled is not made clear to the user.
The only thing we’ve successfully done is change the landing page after saving an event - while this serves as a nice reminder for a user and does seem better than having them click a separate button on the event to log the items distributed, it’s still a **bleep**ty interaction because we’re (occasionally) forcing a user to double enter a date and user, and it’s another page they have to load.
Ideally, I’d love a way to encapsulate the entire interaction in one page and be able add features without having to give up so much of the default salesforce functionality. Any solution discussed above ultimately seems like a dirty hack to me. Any ideas?
Here’s our basic user story for this feature:
A user should log the number and type of items(promotional or otherwise) given to the attendees of an event. Additionally, the items available to be given change over time (sometimes weekly).
The easiest and quickest solution(which was implemented a while ago) was to add a number of custom fields to the Event for the quantity of each item distributed. The data gathered from this solution suggests that it is information that is quite valuable and that people are happy to enter it. As items are added and removed on a weekly basis, this requires constant maintenance of the event object, layouts, and related reports.
So when we wanted to track an additional field per item distributed, going with a more robust, relational database-y way of logging items distributed seemed like the way to go. I created two new sObjects: an Item(representing the different items we can distribute), and a Distributed Item(representing the distribution of a qty of a specific Item to a specific Contact on a specific day).
On a visualforce page w/ a custom controller, we can query the Item table to find available items and present them to a user so that they can enter how many of each item were distributed, as well as the date the items were distributed. This page then saves this data as a set of Distributed Item records. This code is all easy to write and works flawlessly as an isolated feature.
My first plan to expose this to users was to add a custom button to events to “log items distributed.” It’s a simple solution and it works fine. However, placing this page another click away from the edit screen means it is another thing the user has to remember to complete and another step to train on. In all likely-hood, having this information a click away would likely mean it is not always entered. Ideally, this system would work like the old event page does: a list of items that can be distributed, displayed as just another section of the event edit page.
The problem comes when we try to integrate this additional functionality into the flow the user goes through to set up or edit an event. If you override the event edit and new event pages, you lose some core pieces of default user interface: the datetime pickers for startDate/endDate, the ability to invite additional contacts or users, and the ability to see the availability of the invited users. It’s possible to use a datetime picker from various js libraries, but as it is not (yet) possible to programmatically create EventAttendee records, that functionality is completely lost. And to add insult to injury, because you are overriding the page you are faced with the chore of recreating the page layouts and their assignment which had previously been so easy to set up with the Salesforce clicks-not-code functionality.
Given the loss of the ability to add additional attendees and the time intensive task of hardcoding the various pagelayouts and their assignments to different profiles/recordtypes, this was not a reasonable idea.
The next thing I thought about was a bit more roundabout: overriding the URL parameter ‘successURL’ to always bring the user to the basic visualforce page for logging the items distributed. The best way to do this is to implement a ‘eventHook’ page that overrides the create and edit pages for an event. This page would rewrite the successURL parameter with the url for the itemdistribution page, and then redirect the user to a non-overridden edit/new page with the corrected url.
This is actually a pretty good solution - it maintains all of the basic salesforce functionality lost by a direct override, and if you want to turn on and off the item distribution page for different recordtypes/profiles you can very easily update the eventHook controller. The one difficulty is you lose some contextual information that would speed up the interaction. For instance, if you create an event you are S.O.L. if you want to reliably carry forward the ActivityDate or WhoId from the event to the distribution page. This means that after saving the event, the user may sometimes have to manually re-enter the date of the event and the attendees on the item distribution page, and the reason for why it would sometimes be pre-filled and other times not be pre-filled is not made clear to the user.
The only thing we’ve successfully done is change the landing page after saving an event - while this serves as a nice reminder for a user and does seem better than having them click a separate button on the event to log the items distributed, it’s still a **bleep**ty interaction because we’re (occasionally) forcing a user to double enter a date and user, and it’s another page they have to load.
Ideally, I’d love a way to encapsulate the entire interaction in one page and be able add features without having to give up so much of the default salesforce functionality. Any solution discussed above ultimately seems like a dirty hack to me. Any ideas?