Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

Since it seems to me, that a lot of people still need sidebar workarounds, I would be interested to learn about the use-cases, experienced challenges and (most important) possible strategies to avoid them by using different approaches. This is related to the methods discussed here: End of javascript sidebar hacks?

In my experience there are a few extremely important and constantly repeating patterns, which to my knowledge are still very hard to be solved using more official techniques. I will also contribute my own top-N use-cases, which are mostly related to UX and UI concerns. You are very welcome to add your own scenarios as answers and add comments on how you would avoid a workaround. My dream would be to team-elaborate strong and repeatable solution-patterns for the most common use-cases.

Finally I would be interested in the experiences of all of you who participate in the Aura pilot, which hopefully could make this kind of workarounds obsolete.

share|improve this question

4 Answers 4

Use Case: Embedded Visualforce Page on Layout

My top1 is to embed Visualforce Pages on standard layouts with a dynamic height of 100% of it's content instead of a fixed height in px - which can not be anticipated in most cases at design-time. This happens quite often if you display dynamic data like tables or lists with variable content. Within the supported functionality, you end up either with huge empty screen-areas or scrollbars inside scrollbars or both and as an result with a very poor UX. This is a well-known limitation: https://success.salesforce.com/ideaView?id=08730000000BpiMAAS but open for 6+ years. Default Situation

Workaround

Injecting a addEventListener("message",...) into the top-frame and using postMessage() to request an iframe resize. Typically you will repeat postMessage() everytime when the iframe content changes or when the iframe will be resized (this happens because of it's 100% width by default when users change the window size). The pattern is simple, only a few lines of code.

There is even a public listed App which is using this workaround: https://appexchange.salesforce.com/listingDetail?listingId=a0N30000004cEEyEAM - I didn't check if it still works after the recent summer'14 enhancements to html-areas. But it's an unmanaged package and reading End of javascript sidebar hacks? you can easily fix it.

I remember the App as quite bulky. Since the pattern is very simple, a rebuild from scratch will take only a few lines of code.

Result

As expected, the resizing happens seamless and without issues. UX and Look&Feel is almost perfect. You can use this pattern for multiple Iframes on a single layout. Adjusted Situation

Avoid Strategy

Override the the entire View by a Visualforce Page. This is a very radical and non-cooperative approach. Downsides:

  • loss of customizability
  • if you want to install 2 apps which both come with overrides for e.g. Opportunity, you can only use the vf-page provided by one.
  • you loose the Force.com Quick Access Menu
share|improve this answer
    
How does this work if you can no longer inject javascript in to the main page? I thought that was the whole point of this exercise - to get around that limitation. –  Ryan Elkins Jul 30 at 22:29
    
@RyanElkins : the use cases here show requirements and possible solutions using the workaround. It still works salesforce.stackexchange.com/questions/38918/…. But what I'm also looking for are alternatives. At least, if there are any. I mean if I could solve this dynamic-hight-issue in a way which is officially supported, I would obviously prefer the official solution. These kind workarounds are created after we have tried everything "official" we know about before. But maybe there is a way. Or a way comes up by a new release. We want to know. –  Uwe Heim Aug 22 at 9:56

Use Case: Wide Input Controls for Edit and Inline-Edit

By default the inputs on record edit pages are very small. This comes because there is no with set and the browser comes up with a default width of about 140px. Even on small screens with 2-column layouts the UX is very poor. E. g. longer Account or Opportunity names are not fully readable without moving the cursor inside of the edit. Long textfields make text hard to read and edit and a lot of scrolling is necessary. All this while vast amounts of screenspace are wasted for the background. Nearly the same applies to inline-edits. Default Layout

Default Inline-Edit

Workaround

Inject JS or CSS to set width:100% for all inputs, selects and textareas. Additionally add few exceptions for rare places where 100% width can't be used (e.g. column-picker for manage campaign member)

Result

The results are amazing. With less then 10 lines of CSS the usability of all salesforce pages enhances dramatically. The fluid width smoothly adapts to small and large screens. No screen-space is wasted. Looks less cluttered. Adjusted Layout

Adjusted Inline-Edit

Avoid Strategy

Use Grease-Monkey to inject local JS/CSS. Donwsides:

  • Huge effort for all clients.
  • Does not work on IPad in full-site mode.
share|improve this answer

Here's a few more use cases for having to go to hackerama land.

1. Run Assignment Rules Box on Page layouts This is located at the bottom of the "Edit Page" layout, it cannot be moved, it has little if any explanation, users can click it, unclick it - firing off assignment rules that may or may not be
necessary. This should be a standard - moveable field that can be placed in strategic places on a page - related to other fields that are used for Assignment purposes. Making it selectable on an inline basis would also be a help - but I'd do backflips if I could get SFDC to include some incredibly useful and leading edge functionality in place - that would allow me to "move a field" on a page layout.

  1. Removing Buttons from Related Lists - Case Object - the email related list has a button called "Send Email" This cannot be removed. It can be removed on every other object, just not cases. Seriously. Also, this Send an Email button takes a user to a different email sending process using a completely hard coded template with it's own buttons that cannot be removed. It also
    changes the From: email address to that of the user - rather than the main emailtocase address which means that customers then would be replying to an email address that is not going to attach an update to the case thread - ugly stuff.
  2. There are literally dozens of these types of things sprinkled everywhere in the application and most of them seem like they are just plain lazy errors from SFDC's developers.
share|improve this answer

Use Case: Override Quote View

It seems to be not possible to override to View of Quotes. The Override is the typical official solution pattern when it comes to embedding of custom vf-pages on layouts and you need more features like dynamic-height or top-window-reload. Now on Quotes, the override option as avoid-pattern is not present. enter image description here

Workaround

Inject a JS and trigger window.location.href of the pattern https://*.salesforce.com/0Q0???????????? for quote view and reroute them to your custom vf-page providing record-id as parameter.

Result

As expected

Avoid Strategy

Unknown

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.