Event Skinning
Last updated
Last updated
Now we're getting somewhere: the section where you build the landing page exactly the way you want it to look.
There are two configuration options for landing pages:
Generation 2 - a predefined/fixed layout with a large hero image across the top
Generation 3 - use a WYSIWYG tool to build the entire page the way you want it
Generation 2 landing pages are deprecated and will be removed from the product in December 2024. Please use Generation 3 landing pages for all new events.
With this option you have all of the power and all of the responsibility! Build the custom landing page of your(boss') dreams with as much (or as little) content, color, and design as you wish. Want a huge image? Go for it (please don't). Want wildly colored centered text? Have at it (also please don't). Want to put the entire content from the paper invitation on the web? Go for it! Just don't forget to check what it looks like on a small screen. No more are you required to embed a header image -- but we suspect a good number of you will still continue to do so.
Inner pages of registration are lightly styled using one of an array of pre-packaged wrappers. A wrapper defines the header (above the content) and footer (below the content) on the page. These wrappers are not used on the landing page, since you control the entirety of that page - and we mean it.
That said, even the most inventive event managers need a little help - and to make it a little less repetitive, we've made it possible for you to clone the landing page from another event and also implemented a very helpful feature called Landing Page Templates.
Much like Message Templates for the mail module, Landing Page Templates can be used as a base from which to start a new custom Landing Page, but later edits to the template will not update existing Landing Pages.
When granted the appropriate role (ems:landing-template:edit), templates can be created and edited by navigating to Events > Landing Page Templates in the admin sidebar.
Each template needs a name and a folder. Be thoughtful in your naming and organization to make finding the desired template easier when creating landing pages.
In addition to all of the features and functionality you've come to expect from the WYSIWYG editor, we also have a variety of merge tags to automate dropping in certain pieces of text and functionality that you'll need for every event.
{{event_name}} injects the event name
{{event_time}} injects a human-friendly read out of the time span for which the event runs
{{refund_deadline}} injects the refund deadline (in the event's local time zone)
{{location_name}} injects the name of the event location
And lastly, every event will need a series of buttons to proceed from its landing page to the registration process, or the who's coming page, or the RSVP/decline page. We call this the action bar. We support two orientations, horizontal and vertical, which should accommodate all landing page design needs.
{{actionbar_horizontal}}
{{actionbar_vertical}}
Styling the action bar is possible, but must be shared and consistent across all event landing pages. Keep reading for details.
The best thing about landing pages is their flexibility.
The second best thing about landing pages is that they are versioned. Every time you click the save button, we'll save a new revision of your content. Need to roll back a change you don't want any more? Restore the previous version from the landing page's history view. Make mistakes knowing full well you've got a net under you.
You can find information on the currently approved version, and any drafts since that approval, on the event setup page, above the list of activities.
The third best thing about landing pages is that we require an approval before the content is used on the landing page. You can think of it as a strict separation between creation and approval, or you can think of it as an opportunity to make the change and then preview it live before approving it for display to constituents. Either way, it's really useful.
Want to copy in the landing page from a prior event? No problem! On the event setup page, click the "Copy from another event" button. This loads a dialog window prompting you to search for the event. Once you select an event, you need to choose which landing page version you want to copy. You can select the last approved version, the last version (even if it's an unapproved draft), or select a specific version number.
At any time, you can reset to any one of the landing page templates by opening the landing page editor and clicking the "Load Template" button. This will present you with the list of templates. Selecting one of them and submitting the form will create a new version of your landing page, with the template content. This action does not carry any other landing page edits forward; you get only what was in the template at the moment it was loaded.
The action bar consists of the buttons to start registration, indicate you can't attend, and (if activated) the who's coming list. Because these buttons - and those deeper within the registration process - should be on brand, we've implemented a very simple color spec tool for you to use.
When granted the appropriate role (system:colors), you can navigate to System > Colors in the admin sidebar and modify the button styles for event registration. Choices made here affect both the event landing page and the interior registration pages.
There is a live preview of what your changes will look like, including hover states.
Colors must be specified as 6-character hexidecimal values with a leading #. The border, border-radius, padding, and font size fields accept all valid values for their respective CSS properties. E.g. border: 2px solid #808080, and padding: 5px 2em, and border-radius: 30px 0 because we know that colors alone don't cover the full scope of what your style guide generally specifies.
Once a constituent has entered the registration flow we shift into a distraction-free posture. What this means for your build process is that the inner pages are surrrounded by a more straightforward wrapper instead of a pile of design. This feature makes it possible to have wrappers made specially for campus partners to satisfy their design needs without being overly bland or causing their branding to affect other events.
Wrappers consist of header and footer HTML content that we'll put before and after the registration workflow on each of the interior pages. Wrappers also affect the Who's Coming and RSVP/decline pages.
Only AlumnIQ staff can manage wrappers—for now. If you need to create one, please file a ticket! We'll do our faithful best to match your existing sitewide header/footer in our environment.
Generation 3 skinning features make use of 1 existing role, and adds 3 new roles.
The role ems:skinning grants access to all of the WYSIWYG features of designing landing pages for a single event.
The role ems:skinning:approve grants access to preview and approve designed landing pages. Some schools may choose to grant this permission to everyone that gets ems:skinning, if you trust the skin designers to get everything right. On the other hand, if you might allow less trusted users (such as club representatives) to design landing pages but you want Alumni Relations staff to have final approval before designs are made public, you have that option.
The role ems:landing-template:edit grants access to the landing page template editor, allowing the user to create and manage reusable templates for landing pages.
Lastly, the role system:colors grants access to the System > Colors screen, where you can control the colors and other similar attributes used to style the ActionBar buttons on event landing pages. Changes made here affect all events.
